RabbitMQ一般情况很少丢失,但是不能排除意外,为了保证系统高可用,我们必须作出更好完善措施,保证系统的稳定性。
1、消息持久。
2、confirm 机制
3、ACK确认机制
4、设置集群镜像模式
5、消息补偿机制
6、死性队列
第一:消息持久化
RabbitMQ 的消息默认存放在内存上面,如果不特别声明设置,消息不会持久化保存到硬盘上面的,如果节点重启或者意外crash掉,消息就会丢失。
所以就要对消息进行持久化处理。如何持久化,下面具体说明下:
要想做到消息持久化,必须满足以下三个条件,缺一不可。
1) Exchange 设置持久化
2)Queue 设置持久化
3)Message持久化发送:发送消息设置发送模式deliveryMode=2,代表持久化消息
经过这样的设置,当RabbitMQ接受到消息然后持久化完成后,即使MQ挂了,重启后也可以从磁盘恢复queue和消息。但是还要注意一种情况:RabbitMQ接收到了消息,但是还没来得及持久化到磁盘,自己就挂了。此时,会导致MQ内存里的一点点数据丢失,但是这个概率是很小的。
我们可以配合生产者的confirm机制来解决上述问题
第二:消息生产者confirm 机制
开启 confirm 模式,在生产者中设置开启 confirm 模式,每次发送的消息都会添加一个唯一的 id,然后如果写入了 RabbitMQ 中,RabbitMQ 会回传一个 ack 消息,告诉你说这个消息 ok 了。如果 RabbitMQ 没能处理这个消息,会回调一个 nack 接口,告诉你这个消息接收失败,你可以重试。而且你可以结合这个机制自己在内存里维护每个消息 id 的状态,如果超过一定时间还没接收到这个消息的回调,可以重发。
第三:ACK确认机制
多个消费者同时收取消息,比如消息接收到一半的时候,一个消费者死掉了(逻辑复杂时间太长,超时了或者消费被停机或者网络断开链接),如何保证消息不丢?
这个使用就要使用Message acknowledgment 机制,就是消费端消费完成要通知服务端,服务端才把消息从内存删除。
这样就解决了,及时一个消费者出了问题,没有同步消息给服务端,还有其他的消费端去消费,保证了消息不丢。
第四:设置集群镜像模式
我们先来介绍下RabbitMQ三种部署模式:
1)单节点模式:最简单的情况,非集群模式,节点挂了,消息就不能用了。业务可能瘫痪,只能等待。
2)普通模式(主备模式):默认的集群模式,某个节点挂了,该节点上的消息不能用,有影响的业务瘫痪,只能等待节点恢复重启可用(必须持久化消息情况下)。
3)镜像模式:把需要的队列做成镜像队列,存在于多个节点,属于RabbitMQ的高可用方案
为什么设置镜像模式集群,因为队列的内容仅仅存在某一个节点上面,不会存在所有节点上面,所有节点仅仅存放消息结构和元数据。
高可用三种策略模式:
1)同步至所有的节点
2)同步最多N个机器
3)只同步至符合指定名称的节点
第五:消息补偿机制
消息补偿机制需要建立在消息要写入数据库日志,发送日志,接受日志,两者的状态必须记录。
然后根据数据库日志记录检验消息发送消费是否成功,不成功,进行消息补偿措施,重新发送消息处理。
第六:死性队列
当消费者处理失败多次(程序报错或者业务报错),将消息转入死性队列,防止组塞,转入死性队列后,让死性队列消费者消费
可了解地址如下:RabbitMQ消息丢失解决方案之confirm实现_四颗石头的博客-CSDN博客
RabbitMQ的消息丢失解决方案_慕课手记