rabbitMq保证消息不丢失

1.设置消息持久化到磁盘，防止节点挂了造成内存中的消息丢失。必须要满足一下三点设置：

　　1） Exchange 设置持久化

　　2）Queue 设置持久化

　　3）Message持久化发送：发送消息设置发送模式deliveryMode=2，代表持久化消息

 

2.消息重回队列+ack手动确认机制：当消息没能成功ack时，消息会重新回到rabbitmq队列，重新消费，如果需要保证消息实时消费，可以开启多消费者抢占消息，保证某个消费者挂了，另外消费者还在消费。

 

3.搭建集群HA模式：

　　1）单节点模式：最简单的情况，非集群模式，节点挂了，消息就不能用了。业务可能瘫痪，只能等待。
　　2）普通模式：默认的集群模式，某个节点挂了，该节点上的消息不能用，有影响的业务瘫痪，只能等待节点恢复重启可用（必须持久化消息情况下）。
　　3）镜像模式：把需要的队列做成镜像队列，存在于多个节点(消息内容仅仅存在某一个节点上面，不会存在所有节点上面，所有节点仅仅存放消息结构和元数据)。

 

4.消息补偿机制

　　方案1：消息落库，延时补发。投放消息的同时，把消息序列化到DB中，如果投放成功了，则到DB中设置消息投放成功标识。投放失败则不管了。有另外线程扫描DB，获取没投放成功的消息重试投放，成功则修改投放成功标识到DB，重试n次后还是失败则设置投放失败标识到DB。该方案缺点是频繁DB操作，消耗资源严重，不适合高并发业务。

　　方案2：二次投递。抽象出一个消息重调服务，生产者发消息时发送两条，一条发送到消费者(即时发)，一条发送到重调服务(延时几分钟后发)。当消费者接收到即时消息，成功消费后会立即发送成功消费消息到重调服务，重调服务保存成功消费记录。当重调服务受到延时的消息后，先到消费记录看该消息是否成功消费了，有则忽略，没有则推送消息到生产者，重新走一遍流程，直到消费成功为止(或者多少次后放弃该消息)。该方案DB操作少，适合高并发，但必须实现消息消费幂等性。