我正在考虑为一组服务用来相互通信的队列实现一个死信队列。
一直萦绕在我脑海中的是它如何解决未处理消息的问题。
在我看来，消息不会在以下两种情况之一中处理：
- 由于消息本身的某些原因(比如格式不正确(，无法处理消息本身
- 接收消息的应用程序没有处理消息的能力
在场景1中，将消息保持在死信队列中不会有任何作用。应用程序仍然无法处理它。
在场景2中，应用程序还需要以某种方式处理死信队列中的消息。但是，如果它没有能力处理来自主队列的消息，为什么它有能力从第二个队列中提取工作呢？
我一定有什么东西不见了。
死信队列的目标不是将其视为同一订阅者从中读取的辅助队列。相反，它是一个发送意外无法处理的消息的地方。出现这种情况的主要原因有两个：
- 发布消息中存在错误(您的场景#1(
- 订阅者的行为已经改变，现在它无法处理以前可以处理的消息
理想情况下，当设置死信队列时，他们还会根据已发布到此队列的消息设置警报。然后，在一些单独的过程中，他们通过订阅死信主题的订阅来查看消息，以确定为什么无法处理这些消息。如果消息不正确，则订阅服务器的所有者可以联系发布服务器的所有者来修复消息(如果需要(。
如果消息是正确的，并且订阅服务器中的错误阻止了它们的处理，那么可以修复订阅服务器。一旦修复，消息可以重新发布到原始主题，以便固定订户可以拾取它们，或者可以使用seek来重播消息。
由于缺乏处理能力而被传递到死信队列的消息(因此正在拦截它们或让ack截止日期到期(与#2类似，这意味着需要增加订阅者的容量，并可能将流控制设置为与订阅者可以处理的级别一致的级别。然后，人们会重新发布或使用seek来再次获取消息。