摘要：
消息堆积问题 当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。 ![](https://img2023.cnblogs.com/blog/3120037/202306/3120037- 阅读全文
摘要：
当一个队列中的消息满足下列情况之一时，可以成为死信（dead letter）： 消费者使用basic.reject或 basic.nack声明消费失败，并且消息的requeue参数设置为false 消息是一个过期消息，超时无人消费 要投递的队列消息满了，无法投递 如果这个包含死信的队列配置了`dea 阅读全文
摘要：
我们都知道消息在消费者端消费的时候，如果消费端出现异常，那么它会依据spring的重试机制进行重试，达到最大重试次数后，消息会被丢弃，这是由Spring内部机制决定的。 在开启重试模式后，重试次数耗尽，如果消息依然失败，则需要有MessageRecovery接口来处理，它包含三种不同的实现： Rej 阅读全文
摘要：
默认的失败重试机制是有问题的。 当消费者出现异常后，消息会不断requeue（重入队）到队列，再重新发送给消费者，然后再次异常，再次requeue，无限循环，导致mq的消息处理飙升，带来不必要的压力： 怎么办呢？ 我们可以利用Spring的retry机制，在消费者出现异常时利用本地重试，而不是无限制 阅读全文
摘要：
RabbitMQ是**阅后即焚**机制，RabbitMQ确认消息被消费者消费后会立刻删除。 而RabbitMQ是通过消费者回执来确认消费者是否成功处理消息的：消费者获取消息后，应该向RabbitMQ发送ACK回执，表明自己已经处理消息。 设想这样的场景： - 1）RabbitMQ投递消息给消费者- 阅读全文
摘要：
我们看下之前启动idea测试消息发送的时候在后台生成的一条消息，现在已经在消息队列里面还没有被消费。 现在我们重启下RabbitMQ，执行linux命令：docker restart mq 看上图实时显示的错误信息，失去连接了，接下来刷新这个页面，可以发现这个对象没有了。 说明rabbit消息并不会 阅读全文