rabbitmq 不发送ack消息如何处理:rabbitmq可靠发送的自动重试机制
接这篇
在上文中,主要实现了可靠模式的consumer。而可靠模式的sender实现的相对简略,主要通过rabbitTemplate来完成。
本以为这样的实现基本是没有问题的。但是前段时间做了一个性能压力测试,但是发现在使用rabbitTemplate时,会有一定的丢数据问题。
当时的场景是用30个线程,无间隔的向rabbitmq发送数据,但是当运行一段时间后发现,会出现一些connection closed错误,rabbitTemplate虽然进行了自动重连,但是在重连的过程中,丢失了一部分数据。当时发送了300万条数据,丢失在2000条左右。
这种丢失率,对于一些对一致性要求很高的应用(比如扣款,转账)来说,是不可接受的。
在google了很久之后,在stackoverflow上找到rabbitTemplate作者对于这种问题的解决方案,他给的方案很简单,单纯的增加connection数:
connectionFactory.setChannelCacheSize(100);
修改之后,确实不再出现connection closed这种错误了,在发送了3000万条数据后,一条都没有丢失。
似乎问题已经完美的解决了,但是我又想到一个问题:当我们的网络在发生抖动时,这种方式还是不是安全的?
换句话说,如果我强制切断客户端和rabbitmq服务端的连接,数据还会丢失吗?
为了验证这种场景,我重新发送300万条数据,在发送过程中,在rabbitmq的管理界面上点击强制关闭连接:

然后发现,仍然存在丢失数据的问题。
看来这个问题,没有想象中的那么简单了。
在阅读了部分rabbitTemplate的代码之后发现:
1 rabbitTemplate的ack确认机制是异步的
2 这种确认机制是一种事后发现机制,并不能同步的发现问题
也就是说,即便打开了
- connectionFactory.setPublisherConfirms(true);
- rabbitTemplate.setMandatory(true);
并且实现了:
- rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> {
- if (!ack) {
- log.info("send message failed: " + cause + correlationData.toString());
- }
- });
依旧是不安全的。
rabbitTemplate的发送流程是这样的:
1 发送数据并返回(不确认rabbitmq服务器已成功接收)
2 异步的接收从rabbitmq返回的ack确认信息
3 收到ack后调用confirmCallback函数
注意:在confirmCallback中是没有原message的,所以无法在这个函数中调用重发,confirmCallback只有一个通知的作用
在这种情况下,如果在2,3步中任何时候切断连接,我们都无法确认数据是否真的已经成功发送出去,从而造成数据丢失的问题。
最完美的解决方案只有1种:
使用rabbitmq的事务机制。
但是在这种情况下,rabbitmq的效率极低,每秒钟处理的message在几百条左右。实在不可取。
第二种解决方式,使用同步的发送机制,也就是说,客户端发送数据,rabbitmq收到后返回ack,再收到ack后,send函数才返回。代码类似这样:
- 创建channel
- send message
- wait for ack(or 超时)
- close channel
- 返回成功or失败
同样的,由于每次发送message都要重新建立连接,效率很低。
基于上面的分析,我们使用一种新的方式来做到数据的不丢失。
在rabbitTemplate异步确认的基础上
1 在本地缓存已发送的message
2 通过confirmCallback或者被确认的ack,将被确认的message从本地删除
3 定时扫描本地的message,如果大于一定时间未被确认,则重发
当然了,这种解决方式也有一定的问题:
想象这种场景,rabbitmq接收到了消息,在发送ack确认时,网络断了,造成客户端没有收到ack,重发消息。(相比于丢失消息,重发消息要好解决的多,我们可以在consumer端做到幂等)。
自动重试的代码如下:
- public class RetryCache {
- private MessageSender sender;
- private boolean stop = false;
- private Map<String, MessageWithTime> map = new ConcurrentHashMap<>();
- private AtomicLong id = new AtomicLong();
- @NoArgsConstructor
- @AllArgsConstructor
- @Data
- private static class MessageWithTime {
- long time;
- Object message;
- }
- public void setSender(MessageSender sender) {
- this.sender = sender;
- startRetry();
- }
- public String generateId() {
- return "" + id.incrementAndGet();
- }
- public void add(String id, Object message) {
- map.put(id, new MessageWithTime(System.currentTimeMillis(), message));
- }
- public void del(String id) {
- map.remove(id);
- }
- private void startRetry() {
- new Thread(() ->{
- while (!stop) {
- try {
- Thread.sleep(Constants.RETRY_TIME_INTERVAL);
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- long now = System.currentTimeMillis();
- for (String key : map.keySet()) {
- MessageWithTime messageWithTime = map.get(key);
- if (null != messageWithTime) {
- if (messageWithTime.getTime() + 3 * Constants.VALID_TIME < now) {
- log.info("send message failed after 3 min " + messageWithTime);
- del(key);
- } else if (messageWithTime.getTime() + Constants.VALID_TIME < now) {
- DetailRes detailRes = sender.send(messageWithTime.getMessage());
- if (detailRes.isSuccess()) {
- del(key);
- }
- }
- }
- }
- }
- }).start();
- }
- }
在client端发送之前,先在本地缓存message,代码如下:
- @Override
- public DetailRes send(Object message) {
- try {
- String id = retryCache.generateId();
- retryCache.add(id, message);
- rabbitTemplate.correlationConvertAndSend(message, new CorrelationData(id));
- } catch (Exception e) {
- return new DetailRes(false, "");
- }
- return new DetailRes(true, "");
- }
在收到ack时删除本地缓存,代码如下:
- rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> {
- if (!ack) {
- log.info("send message failed: " + cause + correlationData.toString());
- } else {
- retryCache.del(correlationData.getId());
- }
- });
再次验证刚才的场景,发送300w条数据,在发送的过程中过一段时间close一次connection,发送结束后,实际发送数据301.2w条,有一些重复,但是没有丢失数据。
同时需要验证本地缓存的内存泄露问题,程序连续发送1.5亿条数据,内存占用稳定在900M,并没有明显的波动。
最后贴一下rabbitmq的性能测试数据:
1 300w条1k的数据,单机部署rabbitmq(8核,32G)
在ack确认模式下平均发送效率为1.1w条/秒
非ack确认模式下平均发送效率为1.6w条/秒
2 300w条1k的数据,cluster模式部署3台(8核*3, 32G*3)
在ack确认模式下平均发送效率为1.3w条/秒
非ack确认模型下平均发送效率为1.7w条/秒
3 300w条1k的数据,单机部署rabbitmq(8核,32G)
在ack确认模式下平均消费效率为9000条/秒
4 300w条1k的数据,cluster模式部署3台(8核*3, 32G*3)
在ack确认模式下平均消费效率为1w条/秒
代码地址:
rabbitmq 不发送ack消息如何处理:rabbitmq可靠发送的自动重试机制的更多相关文章
- rabbitmq 不发送ack消息如何处理: RabbitMQ 消息确认以及消息消费方处理消息时候抛出了异常以
本篇的代码使用的前面两篇文章<RabbitMQ与Spring整合之消息生产方>和<RabbitMQ与Spring整合之消息消费方>的代码,这两篇文件里配置文件的名称不正确,不可 ...
- [转载]rabbitmq可靠发送的自动重试机制
转载地址http://www.jianshu.com/p/6579e48d18ae http://www.jianshu.com/p/4112d78a8753 接这篇 在上文中,主要实现了可靠模式的c ...
- 消息队列rabbitmq rabbitMQ安装
消息队列rabbitmq 12.1 rabbitMQ 1. 你了解的消息队列 生活里的消息队列,如同邮局的邮箱, 如果没邮箱的话, 邮件必须找到邮件那个人,递给他,才玩完成,那这个任务会处理的很麻 ...
- C# 消息队列 RabbitMQ
1.引言 RabbitMQ——Rabbit Message Queue的简写,但不能仅仅理解其为消息队列,消息代理更合适. RabbitMQ 是一个由 Erlang 语言开发的AMQP(高级消息队列协 ...
- RabbitMQ,Apache的ActiveMQ,阿里RocketMQ,Kafka,ZeroMQ,MetaMQ,Redis也可实现消息队列,RabbitMQ的应用场景以及基本原理介绍,RabbitMQ基础知识详解,RabbitMQ布曙
消息队列及常见消息队列介绍 2017-10-10 09:35操作系统/客户端/人脸识别 一.消息队列(MQ)概述 消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用场景可以 ...
- (转)RabbitMQ消息队列(三):任务分发机制
在上篇文章中,我们解决了从发送端(Producer)向接收端(Consumer)发送“Hello World”的问题.在实际的应用场景中,这是远远不够的.从本篇文章开始,我们将结合更加实际的应用场景来 ...
- RabbitMQ消息队列(三):任务分发机制
在上篇文章中,我们解决了从发送端(Producer)向接收端(Consumer)发送“Hello World”的问题.在实际的应用场景中,这是远远不够的.从本篇文章开始,我们将结合更加实际的应用场景来 ...
- RabbitMQ消息队列(三):任务分发机制[转]
在上篇文章中,我们解决了从发送端(Producer)向接收端(Consumer)发送“Hello World”的问题.在实际的应用场景中,这是远远不够的.从本篇文章开始,我们将结合更加实际的应用场景来 ...
- rabbitmq 公平分发和消息接收确认(转载)
原文地址:http://www.jianshu.com/p/f63820fe2638 当生产者投递消息到broker,rabbitmq把消息分发到消费者. 如果设置了autoAck=true 消费者会 ...
随机推荐
- 【C】字符串常量和字符数组
此次博客是转载某位博主的文章,不过现在找不到了,所以先声明一下. 先贴一段代码: #include <stdio.h> int main(int argc, const char** ar ...
- Django | 执行项目下指定的脚本
1 描述 有时候会碰到这样的场景,对于一些业务升级,我需要把数据库数据做些处理,同时又想以 Django 项目的环境变量执行脚本,这个时候使用 python 脚本是再适合不过的手段了. 2 使用自带的 ...
- 动态库*.so制作
转自:http://www.2cto.com/os/201308/238936.html 在linux下制作动态库*.so. 1.linux下动态库的制作 //so_test.h #include ...
- lwip【6】LWIP使用经验
LWIP使用经验 一 LWIP内存管理 LWIP的内存管理使用了2种方式:内存池memp和内存堆mem,如图1所示. 内存池的特点是预先开辟多组固定大小的内存块组织成链表,实现简单,分配和回收速度快, ...
- 基于keepalived的nginx高可用
#nginx,keepalived安装略过 MASTER 节点配置文件(192.168.1.11) vi /etc/keepalived/keepalived.conf global_defs { # ...
- Stored Procedures CASE 用法错误
)) ) select @type=[type] from sys.objects with(nolock) where name=@ObjectName case @typ ...
- minihttp安装配置ssl和c语言实现cgi
概述:参考了大牛们的方法,结合自己的环境做了修改,主要是讲:minihttp安装配置ssl和c语言实现cgi接收字符串并且保存系统环境:centos6.5 开发版 依赖软件包: mini_httpd- ...
- 面试总结hashmap
考点: 1.hashing的概念 2.HashMap中解决碰撞的方法 3.equals()和hashCode()的应用,以及它们在HashMap中的重要性 4.不可变对象的好处 5.HashMap多线 ...
- 面试问题 ---C#中的委托
一.C#委托是什么的? 在正式介绍委托之前,我想下看看生活中委托的例子——生活中,如果如果我们需要打官司,在法庭上是由律师为我们辩护的,然而律师真真执行的是当事人的陈词,这时候律师就是一个委托对象,当 ...
- HDU - 6341 多校4 Let Sudoku Rotate(状压dfs)
Problem J. Let Sudoku Rotate Time Limit: 2000/1000 MS (Java/Others) Memory Limit: 262144/262144 K ...