我对消费者的一些奇怪行为有疑问。
最近我们在生产环境中遇到了奇怪的情况。两个不同微服务上的两个消费者被一些消息卡住了。第一个保存了来自rabbitMQ 队列的20 条消息，第二个保存了2 条消息，但他们没有处理它们。这些消息在 RabbitMQ 中显示为 Unacked 两天。就在这两个微服务重新启动时，他们才回到就绪状态。当时消费者接收这些消息时，整个程序每小时处理数千条消息，所以基本上我们的 Saga 和所有消费者都在工作。当这些消息回到就绪状态时，它们会在一秒钟内得到处理，所以我认为它们没有问题。
消息由 Saga 发布到 Exchange，除了这两个卡住的消费者之外，我们还有 EventLogger 消费者订阅了所有消息，并且这个 EventLogger 正常处理了这 22 条消息（来自他自己的队列）。此外，我们已经将 Application Insights 连接到消费者，并且没有关于这两个消费者接收这 22 条消息的信息（有关于通过 EventLogger 接收它的信息）。
前几天，我们在测试环境中的一条消息中遇到了同样的问题。
最近我们将项目中的 MassTransit 版本从 6.2.0 版更新到 7.1.6 版，在此之前，我们没有注意到消费者有任何类似问题，但这可能只是巧合。我们还有重试、重新投递、断路器和内存发件箱机制，但我认为这不是问题，因为消费者甚至没有开始处理这 22 条消息。
您对这些消费者会发生什么有什么建议吗？
答案 0 :(得分：0)
通常，当消息被 RabbitMQ 传送到 MassTransit 后，消费者甚至没有开始消费时，这可能是从容器中解决消费者的问题，例如对另一个支持服务（数据库、日志）的依赖服务器、文件、网络连接、设备等）。
消息在代理上仍未得到确认，因为到消费者的传输/交付机制正在等待资源变得可用。如果该时间段的日志中没有任何内容表明资源存在问题，则很难知道是什么原因阻止了这些消息的使用。一旦服务重新启动，它们最终就会被消耗，这一事实似乎表明消息内容本身没有问题。
监控缺乏消息消耗（以及可能相关的队列深度增加）将表明这种情况已经发生。如果再次发生，我会增加日志记录详细级别，以查看问题是否再次发生，然后可以识别。