RabbitMQ高级特性都不会，凭什么要涨薪？
RabbitMQ高级特性都不会，凭什么要涨薪？
RabbitMQ高级特性
（1）ACK（confirm机制）
（2）如何保证消息百分百投递成功
（3）幂等性
（4）return机制
（5）限流
（6）重回队列
（7）TTL
（8）死信队列
高级特性：
1. ACK（confirm机制）
1.1 什么是Confirm机制
概念：
Pro发送消息到Broker,Broker接收到消息后,产生回送响应 Pro中有一个Confirm Listener异步监听响应应答
步骤：
消息的确认 Pro投递消息后,如果Broker收到消息,则会给Pro一个应答
Pro接收应答 用来确定这条消息是否正常地发送到Broker,该法也是消息可靠性投递的核心保障!
1.2 Confirm机制流程图
1.3 实现Confirm机制
在channel上开启确认模式：$channel->confirm_select();
在channel上添加监听：$channel->wait_for_pending_acks();监听成功和失败的返回结果，根据具体的结果对消息进行重新发送、或记录日志等后续处理。
2 保证消息的百分百投递成功
2.1 Producer 的可靠性投递
2.1.1 要求
保证消息的成功发出
保证MQ节点的成功接收
发送端收到MQ节点(Broker) 确认应答
完善的消息补偿机制
在实际生产中，很难保障前三点的完全可靠，比如在极端的环境中，生产者发送消息失败了，发送端在接受确认应答时突然发生网络闪断等等情况，很难保障可靠性投递，所以就需要有第四点完善的消息补偿机制。
2.1.2 解决方案
2.1.2.1 方案一:消息信息落库,对消息状态进行打标(常见方案)
将消息持久化到DB并设置状态值,收到Consumer的应答就改变当前记录的状态.
再轮询重新发送没接收到应答的消息,注意这里要设置重试次数.
方案流程图
缺点是：在第一步需要更新或者插入操作数据库2次
优化：不需要消息进行持久化 只需要业务持久化
3 幂等性
3.1 什么是幂等性
用户对于同一操作发起的一次请求或者多次请求的结果是一致的
比如数据库的乐观锁,在执行更新操作前,先去数据库查询version,然后执行更新语句,以version作为条件,如果执行更新时有其他人先更新了这张表的数据,那么这个条件就不生效了,也就不会执行操作了,通过这种乐观锁的机制来保障幂等性.
3.2 Con - 幂等性
3.2.1 什么是Con - 幂等性
在业务高峰期最容易产生消息重复消费问题,当Con消费完消息时,在给Pro返回ack时由于网络中断,导致Pro未收到确认信息,该条消息就会重新发送并被Con消费,但实际上该消费者已成功消费了该条消息,这就造成了重复消费.
而Con - 幂等性,即消息不会被多次消费,即使我们收到了很多一样的消息.
3.2.2 主流幂等性实现方案
3.2.2.1 唯一ID+指纹码
核心:利用数据库主键去重
唯一ID:业务表的主键
指纹码：为了区别每次正常操作的码，每次操作时生成指纹码；可以用时间戳+业务编号或者标志位（具体视业务场景而定）
优势：实现简单
弊端：高并发下有数据库写入的性能瓶颈
解决方案 根据ID进行分库分表算法路由
4 Return机制
4.1 什么是Return机制
Return Listener用于处理一些不可路由的消息。也是生产段添加的一个监听。
我们的消息生产者，通过指定一个Exchange和Routingkey，把消息送达到某一个队列中去，然后我们的消费者监听队列，进行消息处理操作。
4.2 图解Return机制
5 限流机制
5.1 Con - 限流机制
减压
限流设置API
$channel->basic_qos($prefetchSize, 20, $global);
prefetchSize: 单条消息的大小限制，Con通常设置为0，表示不做限制
prefetchCount: 一次最多能处理多少条消息
global: 是否将上面设置true应用于channel级别还是取false代表Con级别
6 Con - ACK & 重回队列机制
6.1 ACK & NACK
当我们设置autoACK=false时,就可以使用手工ACK方式了,其实手工方式包括了手工ACK与NACK。
注意：如果由于服务器宕机等严重问题,我们就需要手工 ACK 保障Con消费成功
6.2 重回队列
重回队列是为了对没有处理成功的消息,将消息重新投递给Broker
重回队列,会把消费失败的消息重新添加到队列的尾端,供Con继续消费
一般在实际应用中,都会关闭重回队列,即设置为false
7.1 什么是TTL
TTL(Time To Live),即生存时间
RabbitMQ支持消息的过期时间，在消息发送时可以进行指定
RabbitMQ支持为每个队列设置消息的超时时间，从消息入队列开始计算，只要超过了队列的超时时间配置，那么消息会被自动清除。
8 死信队列机制
8.1 什么是死信队列
DLX - 死信队列(dead-letter-exchange) 利用DLX,当消息在一个队列中变成死信 (dead message) 之后,它能被重新publish到另一个Exchange中,这个Exchange就是DLX.
8.2 死信队列的产生场景
消息被拒绝(basic.reject / basic.nack),并且requeue = false 消息因TTL过期 队列达到最大长度
