RabbitMQ高级特性——学习笔记

消息如何保障100%的投递成功？

• 什么是生产端的可靠性投递？

  保障消息的成功发出

  保障MQ节点的成功接收

  发送端收到MQ节点（Broker）确认应答

  完善的消息进行补偿机制

• BAT/TMD互联网大厂的解决方案：

  1. 消息落库，对消息状态进行打标

step1：先将msg持久化，打上标记status=0

step2：发送信息到MQ节点

step3：收到信息

step4：修改标记为status=1

如果第三步出现问题，导致一直收到不信息，因此，需要一个定时任务，不断轮询status=0，启动step6重新发送信息，当重发次数达到上限，将状态status设置为2，标记为已丢失，由后期进行处理。

思考：在高并发的场景下是否适合？

2. 消息的延迟投递，做二次确认，回调检查（少一次DB存储）

消费端——幂等性保障

在海量订单产生的业务高峰期，如何避免消息的重复消费问题？

业界主流的幂等性操作：

• 唯一ID+指纹锁 机制：利用数据库主键去重

  select count(1) from t_order where id = 唯一ID+指纹锁
  

  好处：实现简单

  坏处：高并发下有数据库写入的性能瓶颈

  解决方案：跟进ID进行分库分表进行算法路由

• 利用Redis原子特效实现

  使用Redis进行幂等，需要考虑的问题：

  第一：我们是否要进行数据落库，如果落库的话，关键解决的问题是数据库和缓存如何做到原子性？

  第二：如果不进行落库，那么都存储到缓存中，如何设置定时同步的策略？

Confirm确认消息

机制：消息的确认，是指生产者投递消息后，如果Broker收到消息，则会给我们生产者一个应答，生产者进行接受应答，用来确定这条消息是否正常的发送到Broker，这种方式也是消息的可靠性投递的核心保障。

流程图：

如何实现Confirm确认消息？

第一步：在channel上开启确认模式：channel.confirmSelect()

第二步：在channel上添加监听：addConfirmListener，监听成功和失败的返回结果，根据具体的结果对消息进行重新发送、或记录日志等后续处理

Return消息机制

如果我们发送消息的时候，当前的exchange不存在或者指定的路由key路由不到，这个时候如果我们需要监听这种不可达的消息，就要使用Return LIstener。

关键配置项：

• Mandatory：如果为true，则监听器会接收到路由不可达的消息，然后进行后续处理，如果为false，那么broker端自动删除该消息！

消费者自定义监听

channel.basicConsume(queueName,true,new MyConsumer(channel));

创建MyConsumer类继承DefaultConsumer类，重写handleDelivery方法

消费端限流

RabbitMQ提供了一种Qos（服务质量保证）功能，即在非自动确认消息的前提下，如果一定数目的消息（通过基于consume或者channel设置Qos的值）未被确认前，不进行消费新的消息。

void BasicQo(uint prefetchSize,ushort prefetchCount,bool global);

prefetchSize：0

prefetchCount：会告诉RabbitMQ不要同时给一个消费者推送多与N个消息，即一旦有N个消息还没有ack，则该consumer将block掉，直到有消息ack

global：true\false 是否将上面设置应用于channel（简单说，就是上面限制是channel级别还是consumer级别）

但是rabbitmq暂未实现prefetchSize和global这两项，同时，prefetch_count在no_ack = false的情况下使用，在自动应答下是无效的。

消费端ACK

手工ACK和NACK

消费端进行消费的时候，如果由于业务异常我们可以进行日志的记录，然后进行补偿！

如果由于服务器宕机等严重问，那我们就需要手工进行ACK保障消费端消费成功！

消费端的重回队列

消费端重回队列是为了对没有处理成功的消息，把消息重新会递给Broker，实际应用中，都会关闭重回队列，也就是设置为false。

TTL队列/消息

TTL：Time To Live ，生存时间

RabbitMQ支持消息的过期时间，在消息发送时可以进行指定

RabbitMQ支持队列的过期时间，从消息入队列开始计算，只要超过了队列的超时时间配置，那么消息会自动的清除

死信队列

DLX：Dead-Letter-Exchange

l利用DLX，当消息在一个队列中变成死信（dead message）之后，它能被重新publish到另一个Exchange，这个Exchange就是DLX

消息变成死信有以下几种情况：

• 消息被拒绝，并且requeue = false

• 消息TTL过期

• 队列达到最大长度

死信队列设置：

设置exchange和queue，然后进行绑定，如：

Exchange: dlx.exchange
Queue: dlx.queue
RoutingKey: #

然后我们进行正常声明交换机、队列、绑定，只不过我们需要在队列加上一个参数即可：

arguments.put("x-dead-letter-exchange","dlx.exchange");