今天来学习一下RabbitMQ的高级特性：
消息如何保证100%的发送成功？
什么是生产端的可靠性投递？
- 保证消息的成功发出
- 保证MQ节点的成功接收
- 发送端收到MQ节点（Broker）确认应答
- 完善的消息进行补偿机制
生产端可靠性投递
- 消息落库，对消息状态进行打标
消费端-幂等性保障
- 业界主流的幂等性操作：业务唯一ID或指纹码机制，利用数据库主键去重
生产端特性
理解confirm消息确认机制
- 消息的确认，是指生产者投递消息后，如果broker收到消息，则会给我们的发送者一个应答
- 生产者进行接收应答，用来确定这条消息是否正常的发送到broker，这种方式也是消息的可靠性投递的核心保障
如何实现Confirm确认消息
- 第一步，在Channel上开启确认模式：channel.confirmSelect()
- 第二步，在Channel上添加监听：addConfirmListener，监听成功和失败的返回结果，根据具体的结果对消息进行重新发送，或记录日志等待后续处理
Return消息机制
- Return Listener用来处理一些不可路由的消息
- 我们的消息生产者，通过Exchange和RoutingKey，把消息送达到某一个队列中去，然后我们的消费者监听队列，进行消费处理操作
- 但是在某些特定的情况下，如果我们在发送消息的时候，当前的Exchange不存在或者指定的路由key路由不到，这个时候如果我们需要监听这种不可达的消息，就要使用Return Listener
- 在基础API中有一个关键的配置项：Mandatory，如果为true，则监听器会接收到路由不可达的消息，然后进行后续处理，如果为false，那么broker端自动删除该消息
消费端特性
消费端限流
- RabbitMQ提供了一种qos（服务质量保证）功能，即在非自动确认消息的前提下，如果一定数目的消息（通过基于Consume和channel设置的Qos值）未被确认前，不进行消费新的消息
消费端ACK和重回队列
消费端的手工ACK和NACK
消费端的重回队列
- 消费端重回队列是为了对没有成功处理的消息，把消息重新传递给Broker
TTL消息和死信队列
TTL消息
- TTL是Time To Live的缩写，也就是生存时间
- RabbitMQ支持消息的过期时间，在消息发送时可以进行指定
- RabbitMQ支持队列的过期时间，从消息入队列开始计算，主要超过了队列的超时时间配置，那么消息会自动的清除
死信队列
死信队列：DLX（dead Letter Exchange） 利用DLX，当一个消息在一个队列中变成死信（dead message）之后，它能被重新publish到另一个Exchange，这个Exchange就是DLX
- 消息变成死信有以下几种情况：
- 消息被拒绝（basic.reject/basic.nack）并且requeue=false
- 消息TTL过期
- 队列达到最大长度
DLX也是一个正常的Exchange，和正常的Exchange没有区别，它能在任何队列上被指定，实际上就是某个队列的属性
