开始

image.png
先来回忆消息流转的过程

image.png
在哪些环节消息的收发和流转可能流转可能会出现问题

首先这一块，消息真的发出去了吗，如果这个链接有问题。消息根本就没发上去。业务不就异常了吗？
image.png
所以我们需要一个机制，需要RabbitMQ确认消息发送了。
image.png
所以需要消息的确认机制。
image.png
消息真的被路由了吗？
image.png
确认消息被正确的路由了。
image.png

消息端处理的过来了吗

如果消费端的处理能力太差，而我们的队列几秒钟就发来一万条消息，一会又发来1万条消息，导致这个队列的消息越积越多，消费端处理消息一条的处理，导致我们RabbitMQ积压的消息越来越大，最后挤爆。
image.png
也就是这么多的消息不要同时推送给我接收端，要一条条的推，或者几条几条的推。或者按照一定的速率或者按照一定的要求来推。这就是消费端的限流机制。
image.png

消费端的处理异常

如果消费端有异常，有bug，业务崩溃，我们的发送端也不会知道。Message Broker也不知道。Message Broker只知道消息没读完就挂了。
image.png
之前我们都是消费端自动签收
image.png

image.png
所以又引入了消费端确认机制。
image.png

队列爆满怎么办？

如果消费端，处理的很慢，队列里面的消息全积压在一块。积压了很多，导致RabbitMQ会被挤爆，就会异常，整个业务就跑不下去了。
image.png
整个业务就跑不下去了。
image.png
默认情况下 会永存在这个队列里，除非它被消费走。如果消费者放弃了 或者消费者处理的慢。那就像一个大坝水库，挤压在MQ里面。越来越多。
image.png

新的机制，叫做，消息过期时间，防止消息大量的积压。
image.png
如果不想消息删除，就需要配合后面的机制。

转移过期消息

过期删除的消息就再也不见了。业务也异常了 ，跑步下去了。

image.png

死信队列。

image.png

总结

image.png

结束