程序重启RocketMQ消息重复消费

最近在调试RocketMQ消息发送与消费的Demo时，发现一个问题：只要重启程序，RocketMQ消息就会重复消费。

那么这是什么原因导致的，又该如何解决呢？

经过一番排查，发现程序使用的RocketMQ客户端版本是3.6.2，而测试环境安装的RocketMQ环境的版本是4.1.0。原来是客户端和服务器端版本不一样导致的，消息并没有最终被消费，即没有ACK消息确认，只要程序重启就会重复消费。

解决方案：RocketMQ客户端版本使用与服务器端的同一版本，即4.1.0版本。

划重点：使用RocketMQ的时候，客户端与服务器端一定要使用相同的版本。

原文地址：https://www.cnblogs.com/dushenzi/p/9368671.html

时间： 2024-11-08 17:21:20

程序重启RocketMQ消息重复消费的相关文章

【troubleshooting】记一次Kafka集群重启导致消息重复消费问题处理记录

因需要重启了Kafka集群,重启后发现部分topic出现大量消息积压,检查consumer日志,发现消费的数据竟然是几天前的.由于平时topic消息基本上无积压,consumer消费的数据都是最新的,明显是consumer在重新消费之前已经消费过的数据. 处理方法:将Kafka topic中consumer已经消费的offset值设置为最大值步骤如下:1.从Kafka查询出目前堵塞的topic消息队列中,最大的offset值(其实从Kafka的管理页面上也可以看到这值):命令:./kafka-r

rocketmq消息重复推送的问题

最近,在公司的测试环境,遇到个问题,每次重启应用重启后,原来消费过的消息又被重复推送了一遍,消费者和生产者代码如下: package com.tf56.queue.client; import java.util.concurrent.TimeUnit; import com.alibaba.rocketmq.client.exception.MQBrokerException; import com.alibaba.rocketmq.client.exception.MQClientExcep

关于MQ的几件小事（三）如何保证消息不重复消费

1.幂等性 幂等(idempotent.idempotence)是一个数学与计算机学概念,常见于抽象代数中. 在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同.幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果的函数.这些函数不会影响系统状态,也不用担心重复执行会对系统造成改变.例如,"setTrue()"函数就是一个幂等函数,无论多次执行,其结果都是一样的.更复杂的操作幂等保证是利用唯一交易号(流水号)实现. 简单来说,幂等性就是一个数据

关于RocketMQ消息消费与重平衡的一些问题探讨

其实最好的学习方式就是互相交流,最近也有跟网友讨论了一些关于 RocketMQ 消息拉取与重平衡的问题,我姑且在这里写下我的一些总结. 关于 push 模式下的消息循环拉取问题 之前发表了一篇关于重平衡的文章:「Kafka 重平衡机制」,里面有说到 RocketMQ 重平衡机制是每隔 20s 从任意一个 Broker 节点获取消费组的消费 ID 以及订阅信息,再根据这些订阅信息进行分配,然后将分配到的信息封装成 pullRequest 对象 pull 到 pullRequestQueue 队列中

RocketMQ(消息重发、重复消费、事务、消息模式)

RocketMQ基础:https://github.com/apache/rocketmq/tree/rocketmq-all-4.5.1/docs/cn 分布式消息系统作为实现分布式系统可扩展.可伸缩性的关键组件,需要具有高吞吐量.高可用等特点.而谈到消息系统的设计,就回避不了两个问题: 消息的顺序问题 消息的重复问题 RocketMQ作为阿里开源的一款高性能.高吞吐量的消息中间件,它是怎样来解决这两个问题的?RocketMQ 有哪些关键特性?其实现原理是怎样的? 关键特性以及其实现原理 一.

如何保证消息不被重复消费?(如何保证消息消费时的幂等性)

首先就是比如rabbitmq.rocketmq.kafka,都有可能会出现消费重复消费的问题,正常.因为这问题通常不是mq自己保证的,是给你保证的.然后我们挑一个kafka来举个例子,说说怎么重复消费吧. kafka实际上有个offset的概念,就是每个消息写进去,都有一个offset,代表他的序号,然后consumer消费了数据之后,每隔一段时间,会把自己消费过的消息的offset提交一下,代表我已经消费过了,下次我要是重启啥的,你就让我继续从上次消费到的offset来继续消费吧. 但是凡事总

Kafka消息保证不丢失和重复消费问题

使用同步模式的时候,有3种状态保证消息被安全生产,在配置为1(只保证写入leader成功)的话,如果刚好leader partition挂了,数据就会丢失.还有一种情况可能会丢失消息,就是使用异步模式的时候,当缓冲区满了,如果配置为0(还没有收到确认的情况下,缓冲池一满,就清空缓冲池里的消息),数据就会被立即丢弃掉. 在数据生产时避免数据丢失的方法: 只要能避免上述两种情况,那么就可以保证消息不会被丢失.就是说在同步模式的时候,确认机制设置为-1,也就是让消息写入leader和所有的副本.还有,

Kafka在高并发的情况下，如何避免消息丢失和消息重复？kafka消费怎么保证数据消费一次？数据的一致性和统一性？数据的完整性？

1.kafka在高并发的情况下,如何避免消息丢失和消息重复? 消息丢失解决方案: 首先对kafka进行限速, 其次启用重试机制,重试间隔时间设置长一些,最后Kafka设置acks=all,即需要相应的所有处于ISR的分区都确认收到该消息后,才算发送成功 消息重复解决方案: 消息可以使用唯一id标识 生产者(ack=all 代表至少成功发送一次) 消费者 (offset手动提交,业务逻辑成功处理后,提交offset) 落表(主键或者唯一索引的方式,避免重复数据) 业务逻辑处理(选择唯一主键存储到R

Kafka重复消费和丢失数据研究

Kafka重复消费原因 底层根本原因:已经消费了数据,但是offset没提交. 原因1:强行kill线程,导致消费后的数据,offset没有提交. 原因2:设置offset为自动提交,关闭kafka时,如果在close之前,调用 consumer.unsubscribe() 则有可能部分offset没提交,下次重启会重复消费.例如: try { consumer.unsubscribe(); } catch (Exception e) { } try { consumer.close(); }