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过期 队列达到最大长度