Rabbitmq-幂等性

最新推荐文章于 2024-10-11 23:02:06 发布
原创 最新推荐文章于 2024-10-11 23:02:06 发布 · 512 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#rabbitmq

幂等性是确保同一操作多次执行结果一致的概念，常用于解决消息重复消费问题。例如，在数据库中通过主键ID和指纹码实现去重，避免在高并发场景下消息重复处理。当消费者接收到消息时，先检查数据库中是否存在相同指纹码，若不存在则执行业务逻辑，存在则忽略。此方法简单但可能面临数据库写入瓶颈，可通过分库分表解决。

1. 概念

  • 用户对于同一操作发起的一次请求或者多次请求的结果是一致的，比如在mysql数据当中的乐观锁就可以用来保障幂等性。
  • 在业务高峰期最容易产生消息重复消费问题，比如当消费者消费完消息时，在给生产者返回ack时由于网络中断，导致生产者未收到确认信息，该条消息就会重新发送并被消费者消费，但实际上该消费者已成功消费了该条消息，这就造成了重复消费。而幂等性，即消息不会被多次消费，即使我们收到了很多一样的消息。

2. 解决方案：唯一ID+指纹码

  • 在消费者消费前先去数据库查询这条消息的指纹码标识是否存在，没有就执行insert操作，如果有就代表已经被消费了，就无需任何处理
  • 核心思想：数据库主键id去重
  • 唯一ID：业务表的主键id
  • 指纹码：为了区别每次正常操作的码，每次操作时生成指纹码；可以用时间戳+业务编号或者标志位（具体视业务场景而定）

3. 优劣势

  • 优势：实现简单
  • 劣势：高并发场景下有数据库写入瓶颈（解决方案：根据ID进行分库分表算法路由）
RabbitMQ解决幂等性问题
Rk的博客
10-13 2360
幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的。如果一个插入操作的消费者，插入完成之后的代码发生了异常，这样就抛出异常，然后rabbitmq就会使用重试机制，这样这个消费者就会不断的往数据库里插入该订单数据，这样就会产生多条同样的订单数据，造成结果不一致的。如果消费者处理消息时，因为代码原因抛出异常是需要从新发布版本才能解决的，那么就不需要重试，重试也解决不了该问题的。存放到死信队列或者是数据库表记录、后期人工实现补偿。
【RabbitMQ】如何保证消息消费时的幂等性+如何处理消息丢失的问题
柠檬树
08-24 3652
一、如何保证消息消费时的幂等性 这个问题可以等价于如何保证消费不被重复消费？为什么在消费队列里消费到了重复的数据。 1、kafak消费端可能导致的重复消费问题 消费者准备提交offset，但还没有提交的时候，消费者进程被重启了。那么此时已经消费过的数据offset还没有提交。kafka也就不知道你消费了offset=153的那条数据。 消费者一旦重启，马上会找kafka说：哥们，把我上次消费到的那条数据之后的数据给...
RabbitMQ如何保证消息幂等性
HereIcome的博客
06-17 2693
用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生副作用。举个简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额发现多扣钱了，流水记录也变成了两条。在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是再相应客户端的时候也有可能出现网络中断或者异常等等。1. RabbitMQ自动重试机制。
RabbitMQ 消息顺序、消息幂等、消息重复、消息事务、集群
weixin_33785108的博客
06-12 2165
1. 消息顺序 场景：比如下单操作，下单成功之后，会发布创建订单和扣减库存消息，但扣减库存消息执行会先于创建订单消息，也就说前者执行成功之后，才能执行后者。 不保证完全按照顺序消费，在 MQ 层面支持消息的顺序处理开销太大，为了极少量的需求，增加整体上的复杂度得不偿失。 所以，还是在应用层面处理比较好，或者业务逻辑进行处理。 应用层解决方式： 1. 消息实体中增加：版本号 & 状态机 &...
RabbitMQ 之 幂等性
weixin_42926863的博客
09-20 2463
RabbitMQ、幂等性
rabbitmq-test:rabbitmq测试
03-26
- **幂等性设计**：确保即使消息重复发送，系统也能处理。 - **确认模式**：开启`channel.confirmSelect()`，确保消息被正确发送。 - **使用工作队列**：当有大量并发任务时，可以使用工作队列分发任务，提高处理...
RabbitMQ 之 幂等性 | 优先级队列 | 惰性队列
weixin_73616913的博客
07-03 1516
用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。举个最简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额发现多扣钱了，流水记录也变成了两条。在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是再响应客户端的时候也有可能出现网络中断或者异常等等。
【RabbitMQ】幂等性、顺序性
weixin_73060900的博客
09-25 1443
对幂等性以及顺序性进行简单概述
第十三章 RabbitMQ之消息幂等性
Calvin的博客
10-11 1403
实际项目开发中，我们在提交表单时，很多时候可能会重复提交表单，这个时候我们通过token令牌等唯一标识来解决，第一次提交页面将缓存中的唯一标识删除，后面再重新提交时缓存中的标识已经被删了因此重复提交失败。结合业务逻辑，基于业务本身做判断。以余额支付业务为例，我们要在支付后修改订单状态为已支付，应该在修改订单状态前先查询订单状态，判断状态是否是未支付。我们在消息消费的过程中也会存在同样的问题，即如何来保障所有业务在接收RabbitMQ消息时保证业务的幂等性，避免消息重复消费呢？
RabbitMQ（幂等性、优先级队列、惰性队列）
friggly的博客
11-07 1827
RabbitMQ（幂等性、优先级队列、惰性队列）知识补充！
九、RabbitMQ的其他知识点
白羊座的橙子
03-12 351
在海量订单生成的业务高峰期，生产端有可能就会重复发生了消息，这时候消费端就要实现幂等性，这就意味着我们的消息永远不会被消费多次，即使我们收到了一样的消息。指纹码:我们的一些规则或者时间戳加别的服务给到的唯一信息码,它并不一定是我们系统生成的，基本都是由我们的业务规则拼接而来，MQ 消费者的幂等性的解决一般使用全局 ID，每次消费消息时用该 id 先判断该消息是否已消费过。但实际上消费者已成功消费了该消息，造成了消息的重复消费。消息者在消费MQ中的消息时，MQ已把消息发送给消费者，2）队列中代码添加优先级。
rabbitmq实现幂等性操作
zhiyikeji的博客
04-15 5892
文章目录 1.场景描述1.1 场景11.2 场景22.原理3.实战开发3.1 建表3.2 集成mybatis-plus3.3 集成RabbitMq3.3.1 安装mq3.3.2 springBoot集成mq3.4 具体实现3.4.1 mq配置类3.4.2 生产者3.4.3 消费者 1.场景描述 消息中间件是分布式系统常用的组件，无论是异步化、解耦、削峰等都有广泛的应用价值。我们通常会认为，消息中间件是一个可靠的组件——这里所谓的可靠是指，只要我把消息成功投递到了消息中间件，消息就不会丢失，即消息肯定会至少
RabbitMQ消息幂等性之全局唯一ID
热门推荐
weixiaohuai的博客
07-21 1万+
一、简介 消息幂等性，其实就是保证同一个消息不被消费者重复消费两次。当消费者消费完消息之后，通常会发送一个ack应答确认信息给生产者，但是这中间有可能因为网络中断等原因，导致生产者未能收到确认消息，由此这条消息将会被 重复发送给其他消费者进行消费，实际上这条消息已经被消费过了，这就是重复消费的问题。 如何避免重复消费的问题？ 消费者端实现幂等性，意味着我们的消息永远不会消费多次，即使我们收到...
RabbitMQ 幂等性概念及业界主流解决方案
weixin_44048532的博客
01-24 1万+
一、什么是幂等性 可以参考数据库乐观锁机制，比如执行一条更新库存的 SQL 语句，在并发场景，为了性能和数据可靠性，会在更新时加上查询时的版本，并且更新这个版本信息。可能你要对一个事情进行操作，这个操作可能会执行成百上千次，但是操作结果都是相同的，这就是幂等性。 二、消费端的幂等性保障 在海量订单生成的业务高峰期，生产端有可能就会重复发生了消息，这时候消费端就要实现幂等性，这就意味着我们的消...
RabbitMQ幂等性概念及业界解决方案（六）
weixin_46378497的博客
03-01 654
一、什么是幂等性 可以参考数据库乐观锁机制，比如执行一条更新库存的 SQL 语句，在并发场景， 为了性能和数据可靠性，会在更新时加上查询时的版本，并且更新这个版本信 息。可能你要对一个事情进行操作，这个操作可能会执行成百上千次，但是操作 结果都是相同的，这就是幂等性。 比如，我们执行一条更新库存的sql语句：update table set count = count -1 where id = ...
RabbitMQ 应用问题 - 消息幂等性保障（思路）
weixin_42947972的博客
04-05 398
RabbitMQ 应用问题 - 消息幂等性保障 幂等性指一次和多次请求某一个资源，对于资源本身应该具有同样的结果。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。 在MQ中指，消费多条相同的消息，得到与消费该消息一次相同的结果。 版本号机制 每次发送带version 并且每次执行version = version+1 那么但第二次的时候version将比对不成功,这样就避免重复消费了! ...
RabbitMQ如何保证幂等性
向着高亮的地方
11-30 2952
幂等性是分布式系统设计中的一个重要概念，是在做系统或者接口设计时要着重考虑的问题，尤其像支付宝、银行、互联网金融等涉及钱的系统，既要高效，数据也要准确，绝对不能出现多扣款，多打款等问题，幂等性的设计就显得更为重要了。 本文我们就先来解释一下什么是幂等性？然后再看一下在MQ中怎么保证幂等性？ 一、什么是幂等？ 幂等性的实质是：对于一个资源，不管你请求一次还是请求多次，对该资源本身造成的影响应该是相同的，不能因为重复相同的请求而对该资源重复造成影响。注意关注的是请求操作对资源本身造成的影响，而不是请求资源
RabbitMQ的幂等性、优先级队列和惰性队列
哥的时代，为你保驾护航
03-18 7860
一、幂等性1、概念2、消息重复消费3、解决思路4、消费端的幂等性保障5、唯一 ID+指纹码机制6、Redis 原子性二、优先级队列1、使用场景2、如何添加3、实战三、惰性队列1、使用场景2、两种模式3、内存开销对比以上就是RabbitMQ的幂等性、优先级队列和惰性队列的相关知识点，希望对你有所帮助。
rabbitmq业务幂等性
最新发布
02-20
### RabbitMQ 中实现业务幂等性的方法 为了确保消息不会因为重复投递而影响业务逻辑，必须设计合理的机制来保证业务的幂等性。通常的做法是在接收到每条消息时记录其唯一标识符，并在后续处理过程中检查该标识符是否已经被处理过。 #### 使用全局唯一的 Message ID 一种常见的做法是利用消息本身的 `message_id` 或者自定义字段作为唯一键[^1]： ```java public void processMessage(DeliverCallback deliverCallback, String consumerTag, Delivery message) { String messageId = new String(message.getProperties().getMessageId()); if (isProcessedBefore(messageId)) { channel.basicAck(message.getEnvelope().getDeliveryTag(), false); return; } try { // 处理业务逻辑 handleBusinessLogic(new String(message.getBody())); // 记录已处理的消息ID markAsProcessed(messageId); // 手动确认消息已被成功处理 channel.basicAck(message.getEnvelope().getDeliveryTag(), false); } catch (Exception e) { // 如果失败，则拒绝这条消息并设置重新排队标志为true channel.basicNack(message.getEnvelope().getDeliveryTag(), false, true); } } ``` 此代码片段展示了如何通过检查消息ID防止重复执行相同的操作。一旦发现之前已经处理过的消息就立即返回而不做任何额外的工作；而对于新到达的消息，在完成相应的业务操作后将其状态更新为“已处理”，最后再向RabbitMQ 发送 ACK 确认信号表示一切正常[^2]。 #### 数据库事务配合乐观锁控制 另一种方式则是借助数据库层面的支持——比如采用版本号或时间戳来进行冲突检测，从而达到幂等的效果。具体来说就是在每次尝试修改数据前先读取当前最新的一版记录，并比较其中包含的时间戳/版本号与预期相符后再提交更改。如果不一致则说明有其他进程抢先一步完成了相同的变更，这时可以选择放弃本次请求或是重试直到成功为止[^5]。 例如可以在订单表中增加一个 version 字段用于追踪每一次的状态变化情况: | order_id | status | created_at | updated_at | version | |----------|------------|--------|---------| | 1001 | processing | 2023-09-18T14:25:00Z| 2023-09-18T14:26:00Z | 1 | 当需要更新某个特定订单的状态时，SQL语句可能看起来像这样： ```sql UPDATE orders SET status='completed',updated_at=NOW(),version=version+1 WHERE order_id=? AND version=? ``` 这里的关键在于最后一个条件部分，它确保了只有当现有记录确实处于我们所期望的那个版本时才会真正触发 UPDATE 操作。否则的话查询将不会匹配到任何行，也就意味着此次更新被忽略了。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值