激活 RabbitMQ 磁盘或内存警报时 spring-cloud-stream-rabbit-binder 如何工作？

Question

版本：

Spring-cloud-stream-starter-rabbit --> 2.1.0.RELEASE

RabbitMQ --> 3.7.7

二郎 --> 21.1

---

(1) 我在 github 上创建了一个示例 mq-publisher-demo 和 mq-subscriber-demo 存储库以供参考。

内存警报激活时

发布者：能够发布消息。

订阅者：看起来订阅者正在批量接收消息，几乎没有延迟。

磁盘警报激活时

发布者：能够发布消息。

订阅者：看起来，在激活磁盘警报时订阅者没有收到消息。但是一旦警报被停用，订阅者就会收到所有消息。

消息是否在某处缓冲？

这是预期的行为吗？ （因为我期待 RabbitMQ 将停止接收来自发布者的消息，并且一旦任何警报被激活，订阅者将永远不会收到任何后续消息。）

(2) Spring Cloud Stream document 如下所述。 这是否意味着上述行为？ （避免死锁并保持发布者发布消息）

从 2.0 版开始，RabbitMessageChannelBinder 将 RabbitTemplate.userPublisherConnection 属性设置为 true，以便非事务性生产者避免消费者出现死锁，如果缓存连接因代理上的内存警报而被阻塞，就会发生这种情况。

(3) 我们是否也有类似的 Disk alarm 来避免死锁？

(4) 如果生产者的消息不会被RabbitMQ接受，那么是否可以从spring-cloud-stream向发布者抛出特定的异常（说警报被激活并且消息发布失败)?

我对spring-cloud-stream中的这些警报有点陌生，请帮助我理解清楚。谢谢。

Answer 1

消息是否在某处缓冲？

是的，当设置资源警报时，消息将被发布到网络缓冲区。

• 小消息需要一些时间来填满网络缓冲区，然后 阻止发布者。
• 较小的网络缓冲区大小将阻止发布者 很快。

Answer 2

最好在 rabbitmq-users 谷歌组上询问有关 RabbitMQ 本身（以及 Spring 使用的 Java 客户端）行为的问题；这就是 RabbitMQ 工程师们常去的地方。

(2) Spring Cloud Stream 文档如下所述。这是否意味着上述行为？

所做的更改是，如果生产者被阻止生产，消费者仍然可以消费。

（4）如果生产者的消息不会被RabbitMQ接受，那么是否可以从spring-cloud-stream向发布者抛出特定的异常（说警报被激活并且消息发布失败）？

默认情况下发布是异步的；您可以启用事务（这会大大降低性能；或者在生产者上启用错误，如果启用发布者确认并返回，您将在错误通道上收到异步消息。