参考:朱忠华老师的著作:Rabbit实战指南
1.channel参数mandatory设置为true,当消息没有找到任何队列的时候,可以返回给客户端。
2.备份交换机(AE)的设置、避免消息丢失。AE和mandatory同时存在的时候、只有AE生效
3.DLX (dead-letter-exchange)死信交换器,死信队列
进入条件:消息被拒绝(basic.reject/basic.Nack)并且设置request参数为false
消息过期
队列达到最大长度
4.使用RPC调用。使用回调队列的时候,服务端必须要对correlationId进行幂等设计。
5.TTL和死信队列的使用。保证消息不丢失。(延迟队列)
6.持久化设置:常用的交换机和队列。重要的消息要进行持久化设计
持久化:将消息随机写入磁盘的效率很低、对于可靠性不是那么高的消息可以不采用持久化处理提高整体的吞吐量。(可靠性和吞吐量之间做权衡)
7、消息不丢失的一些设置。
7.1(针对重要的消息、将autoAck参数设置为false,并进行手动确认。)
7.2关键业务队列需要设置镜像队列:解决MQ刷盘的过程中出现宕机,导致消息丢失的场景。
8、生产者确认机制:确保生产者发送的消息已经发送到MQ、
推荐使用:异步或者批量confirm的方式、
批量confirm方式的问题在于遇到RabbitMQ服务器端返回的bacis.nack后需要重发批量的消息导致的性能降低。
异步confirm方式编程模型代码量设计上较为复杂。
9、消费者:
9.1 消费分发:
消息负载严重的时候,创建更多的消费者消费消息:
用过channel.basicQos(int perfetchCount)限制信道上的消费者所能保持的最大未确认消息的 数量。避免集群消费者中。消费能力不一致导致的问题。(对于拉模式的消费方式无效)
9.2 消息顺序性
需要业务房使用MQ之后做进一步的处理。比如在消息体内添加全局有序标识、类似 sequenceID的使用
9.3 弃用QueueingConsumer
建议在消费的时候尽量去继承DefaultConsumer的方法,不要使用QueueingConsumer的方式、
10、消息传输保障
10.1消费者开启pulisher confirm机制。确保消息可以传输到RabbitMQ中
2. 消息生产者需要配合使用mandatory参数或者AE确保消息已经到队列中
3、消息和队列都需要进行持久化处理。以确保RabbitMQ服务异常后导致消息丢失
4、消费者在消费消息的时候同事需要将autoAck设置为False。然后通过手动确认的方式进行确认消息已经正确消费了、以避免在消费端引起不必要的消息丢失
5.业务方根据吱声的业务特性进行去重、比如业务消息本身具备幂等性,或者借助Redis等其他产品进行去重处理。