问题由来 假设在一个订单系统中（以火车票订单系统为例），用户A，用户B都要预定从成都到北京的火车票，A、B在不同的售票窗口均同时查询到了某车厢卧铺中、下铺位有空位。用户A正在犹豫订中铺还是下铺，这时用户B果断订购了下铺。当用户A决定订下铺时，系统提示下铺已经被预订，请重新选择铺位。在这 ...

RocketMQ 幂等性主要分为生产端和消费端幂等性 备注：这里只讨论生产者 和消费者集群部署下的情况 生产者端幂等性保证： 　　1RocketMQ 为消息生产者提供了消息查询的API，在消息发送之前，可以查询该条消息是否发送过，注意但是该方法在2020年5月之后的版本，已经被废掉 ...

前情 出现了重复消费的问题，同一个消息被重复消费了多次，导致了用户端收到了多条重复的消息，最终排查发现，是因为消费者在处理消息的方法onMessage中有异常没有捕获到，导致异常上抛，被consumeMessage捕获并判定为消费失败，从而放到了重试队列当中进行重试，下面我们就来看看 ...

之所以想聊一聊这个话题，是因为在刚开始使用rocketmq时，Consumer服务写的有问题的情况下，消息队列会重发，这是因为消费失败会导致消息被放入RETRY重试队列，根据用户配置的重试次数（默认16次）进行重试，这部分我们已经在之前的 RocketMQ存储机制与确认重传机制一文中讨论 ...

一、为什么出现消息重复 从 Product 看 Rocketmq 提供三种发送消息模式 同步发送：Producer 向 broker 发送消息，阻塞当前线程等待 broker 响应 发送结果。DefaultMQProducerImpl 中如果没有设置 超时、发送失败，就会重发。 异步发送 ...

前言 在之前的MQ专题中，我们已经解决了消息中间件的一大难题，消息丢失问题。 但MQ在实际应用中不是说保证消息不丢失就万无一失了，它还有两个令人头疼的问题：重复消费和乱序。 今天我们就来聊一聊这两个常见的问题，看看RocketMQ是如何解决这两个问题的。 为什么会重复消费 ...

消息重复消费，会造成数据混乱，特别是在涉及消费和财务系统里，此问题的解决显得尤为重要。 以kafka为例 关键字：消费端自动提交offset；写库或者redis时，先去查一下主键、key等是否存在 上图中，最顶上的文本框丢失的文字：并通知kafka当前最大offset； 最右边的文本框 ...

　　近期工作中遇到用户重复提交表单信息情况，尤其是在网络延时的情况下，用户点击提交按钮后，页面迟迟未响应，于是就会再次点击提交按钮。这样就导致产生重复数据，会对后续的业务带来一定问题。为此，查了一些资料，学习总结了下相关问题的解决思路。 　　首先，重复提交的问题，专业点的说法叫做接口幂等性问题 ...