Hug*_*ugo 5 architecture publish-subscribe dead-letter
我正在考虑为一组服务用来相互通信的队列实现一个死信队列。
一直萦绕在我脑海中的是它如何解决未处理消息的问题。
在我看来，在以下两种情况之一中不会处理消息：
在场景 1 中，按原样将消息保留在死信队列中不会执行任何操作。应用程序仍然无法处理它。
在场景 2 中，应用程序还需要处理来自死信队列的消息。但是，如果它没有能力处理来自主队列的消息，为什么它有能力从第二个队列中获取工作呢？
一定有什么东西我失踪了。
死信队列的目标不是将其视为同一订阅者从中读取的辅助队列。相反，它是发送意外无法处理的消息的地方。造成这种情况的主要原因有两个：
理想情况下，当人们设置死信队列时，他们还会根据已发布到该队列的消息设置警报。然后，在某个单独的过程中，他们通过订阅死信主题的订阅来查看消息，以确定无法处理它们的原因。如果消息不正确，则订阅者的所有者可以联系发布者的所有者来修复消息（如果需要）。
如果消息正确并且订阅者中的错误阻止了消息的处理，那么就可以修复订阅者。一旦修复，消息就可以重新发布到原始主题，以便固定订阅者可以接收它们，或者可以使用搜索来重放消息。
消息由于缺乏处理能力而被传递到死信队列（因此取消它们或让确认截止日期到期）类似于#2，并且意味着需要增加订阅者的容量，并且可能将流量控制设置为与订阅者可以处理的内容一致的级别。然后，人们可以重新发布或使用“寻求”来再次取回消息。