来说消息过期(TTL)TTL成功false失败原因及配置

前言

今天来说说RabbitMQ的高级特性和消息补偿机制

1.可靠的消息传递

在消息发送者想要防止任何消息丢失或传递失败的情况时使用 RabbitMQ。

RabbitMQ 为我们提供了两种方式来控制消息传递的可靠性模式。

confirm 确认模式：当消息从生产者发送到交易所时，confirmCallback 中的确认方法将被执行。

return 返回模式：消息发送到 Exchange 后，如果消息路由到队列失败，Exchange 会执行 ReturnCallBack。

确认方式会返回{1.相关配置信息，2.交换机是否成功接收到消息，真成功假失败3.失败原因}

回退模式会返回{1.message object,2.error code,3.error message,4.switch name,5.routing key}

2.消费者ACK（消费者ACK）

ack 指Acknowledge，确认。表示消费者收到消息后的确认方式。

RabbitMQ 提供了三种确认方式：

自动确认：acknowledge=”none” 当消息被Consumer收到后，会自动确认收到，并从RabbitMQ的消息缓存中移除相应的消息。

手动确认：acknowledge=”manual” 如果出现异常，调用channel.basicNack()方法自动重发消息。

根据异常情况确认：acknowledge=”auto”。

3.消息过期（TTL）

TTL是Time To Live的全称（生存时间/过期时间）。当消息到达生存时间时ttl传输中过期是什么意思，还没有被消费，会被自动清除。

RabbitMQ可以为消息设置过期时间，也可以为整个队列（Queue）设置过期时间。

消息过期, 可以让队列统一过期, 也可以让它单独的消息过期。

4. 死信队列

Dead Letter Queue，英文缩写：DLX。死信交换（Dead Letter Exchange），当一条消息变成死信（Dead Letter）时，可以重新发送到另一个交换，这个交换就是DLX。

消息变成死信的三种情况：

1.队列消息长度达到限制；

2.消费者拒绝接收消费消息，不将消息放回原来的目标队列；

3.原队列有消息过期设置，消息在超时时间前到达被消费；

死信队列和死信交换：

死信队列和死信交换机与正常的队列和交换机一模一样, 没有任何区别 !! 

如何将队列绑定到死信交换，设置队列如下参数：

5.延迟队列

消息进入队列后不会立即被消费，只有达到指定时间后才会被消费。例如：

延迟队列是一个非常强大的功能，但是RabbitMQ不提供延迟队列功能。

可以使用：TTL（消息过期）+死信队列组合来达到延迟队列的效果。

实现流程图如下：

6.消费端限流

当系统的峰值比较高的时候，我们可以使用RabbitMQ削峰填谷，让我们系统处理的请求更加稳定

实现步骤设置akc机制为手动确认配置监控容器7.RabbitMQ应用问题（消息补偿机制）

通过前面的消息可靠性传递、ACK确认机制、死信队列，我们​​已经基本可以保证消息传递成功了！

为什么需要消息补偿机制？消息是否仍然丢失？是的，系统是在复杂的环境下，不要想的太简单，虽然以上三种方案基本可以保证消息的高可用不丢问题，但是作为一个有追求的程序员来说，绝对保证我的系统稳定ttl传输中过期是什么意思，有危机感。

例如：在将一条持久化消息保存到硬盘的过程中，当前队列节点挂了，存储节点的硬盘又坏了，消息丢失了，怎么办？

产线网络环境太复杂，太多了，需要做一个消息补偿机制！

消息补偿机制需要基于业务数据库和MQ数据库。当我们发送消息时，需要同时将消息数据保存到数据库中，并且必须记录两者的状态。然后通过业务数据库和MQ数据库的比对判断消费是否成功，采取消息补偿措施，重新发送消息处理

终于

如果看完有什么不明白的，可以在下方留言讨论。

感谢您的收看。

如果觉得文章对你有帮助，记得关注我，点赞支持！

链接：