目标
- 实现一个在相对恶劣的条件下,依旧保证消息百分百投递或消费的消息队列。
存在的挑战及简易方案
- 1.你说百分百投递,万一你mq挂了,怎么投递?
使用镜像队列
- 2.那要是网络不稳定,消息没有送到exchange或者没有送到queue怎么办?
conform模式 和 return模式 配合消息重发的线程池重发消息
- 2.1.消息发送至某一台mq,但是这台mq突然停电,来不及同步到其他镜像队列怎办?
消息持久化至硬盘,消息重启恢复
- 2.2.如果消息刚到内存,还没来及固化到硬盘,此时发生故障,导致消息丢失怎么办?
这次消息是真的丢失了,但是有补偿机制
- 2.1.消息发送至某一台mq,但是这台mq突然停电,来不及同步到其他镜像队列怎办?
- 3.消息执行(消费)失败,或者消费后消息没有发送至队列怎办?
(1)发送消息时,除了发给消费端,还发给了补偿端做消息登记。 (2)消费端消费后,会把消息发送到补偿端进行同步。 (3)补偿机制会在间隔时间内重新发消息到补偿端,获取消息状态,要么重发,要么关闭。
- 4.那万一生产端多发了消息,或者补偿机制多发了消息,怎么保证幂等消费?
redis分布式锁:Redisson实现消息幂等
- 5.大流量进入mq的时候,来不及消费怎么办?
mq有削峰填谷的算法
- 6.上述百分百投递保障和单节点相比,对性能影响有多大?
测试方案: (1)镜像队列在不同宕机条件下的消息可达性测试 (2)单节点和百分百投递队列的性能对比测试。
- 7.消息队列的类是交由spring管理的单例,如何保证在多处引用的时候,不会引起线程安全问题
将scope改成request
实现架构图
实现步骤
- 消息送达后客户端后,先进行消息落库(数据库a),作为日后查验(消息补偿)的凭据
- 消息同时传递至2条mq队列,一条用于缓存信息,后续进行消费(大流量下进行削峰填谷),另一条用于补偿机制获取消息,进行消息查询和重发的,落库至(数据库b)
- 服务端消费后的消息回执发送到队列,补偿机制进行数据更新(数据库b)
- 消费端的delay线程对刚才的消息进行query,补偿机制根据query次数决定是重发消息还是等待消息。
测试架构图
测试案例设计
- 编写一个客户端程序,使用封装好的百分百投递的jar包来传递消息,对外暴露一个接口。
- 使用jmeter发压,通过Nginx负载到两个客户端程序的接口上,分别测试一千条数据、一万条数据、十万条数据的完成时间和投递成功率。
- consumer端使用一个接口来接受数据,并用线程sleep 5毫秒来模拟线程处理数据。
- 等到consumer端不在处理数据后,查看数据库的消息落库情况和消息消费情况
- 消费时间公式:
- 消费时间 = consumer端最后一条数据打印出来的时间 - 开始发压时间,
- 这里可以测试 镜像队列、单节点、消息固化和非固化的投递效率。
- 消息投递保障率:
- 查询数据库落库的数据 / 发压的数据,
- 查询数据库完成消费的数据 / 发压的数据,
- 两者取最小值,就是消息投递保障率。
未完待续