亚马逊SQS死信队列:它真的是死信还是毒药？

Question

我正在试图澄清亚马逊的SQS死信队列究竟在做什么.

据http://aws.typepad.com/aws/2014/01/amazon-sqs-new-dead-letter-queue.html

死信队列 - SQS队列的ARN(亚马逊资源名称),它将接收消费者收到最大数量后未成功处理的消息.

这听起来不像Poision Queue吗？关键的区别在于消费者确实收到了消息.当信息可能正常,但无法传递时,可能是由于服务中断而导致死信.http://www.eaipatterns.com/DeadLetterChannel.html

其中,因为这听起来像被成功地接收到该消息多次,但处理消息失败,这是我理解是有害消息队列的含义.

消息总线与队列

死信模式在普通旧队列的上下文中有不同的含义吗？由于SQS只是一个队列,而不是消息总线,因此它不负责传递消息.相反,它等待拾取(请求)消息.因此传统的死信模式并不真正适用,因为没有消息总线尝试传递消息而无法找到收件人.

SQS可以像消息总线一样吗？

是否有办法通过SQS设置通道和侦听器,而不是显式轮询来自队列的消息？

Answer 1

好问题.

基于您引用的规范来源的定义(为清晰起见,删除了引文):

Dead Letter Channel的具体工作方式取决于特定的消息传递系统的实现,如果它提供了一个.该通道可称为"死信息队列"或"死信队列".通常,安装消息系统的每台机器都有自己的本地死信通道,这样无论机器上的消息是什么,它都可以从一个机器移动本地队列到另一个没有任何网络不确定性.这也记录了消息死亡的机器.当消息传递系统移动消息时,它还可以记录消息应该被传递的原始信道.

......目前尚不清楚是否真的存在差异.我明白你的意思是"毒药队列",你对SQS如何运作的理解是合理的.在语义上,DLQ和PQ之间的区别 - 电子邮件风格与"毒药""无法传递" - 对我来说并不清楚.也许PQ是DLQ的味道.

FWIW,ActiveMQ的重新传递策略使用与DLQ相同的定义 - 混合DLQ/PQ - 与SQS一样.

SQS可以像消息总线一样吗？

SQS不能,但有类似的产品可以.

1. 亚马逊SNS

   SNS(简单通知服务)是一种通用的发布 - 订阅主题系统.SNS允许您创建主题,然后注册接收推送通知的订阅者.目前,推送通知可以以HTTP/S,电子邮件,SMS,SQS和移动设备推送通知的形式出现.

   SNS 对HTTP/S 有一个非常合理的重试策略,但不支持DLQ或PQ AFAIK.

2. IronMQ的推送队列

   IronMQ是另一种REST-ful消息排队服务,比SQS功能更强大.(真正的FIFO消息排序,更长的延迟等等,但可悲的是更小的消息大小.)推送队列允许您设置推送"订户",然后在新消息被放入队列时接收HTTP POST.

   如果IronMQ无法传递消息 - HTTP POST超时,或者您的端点返回除-a之外的任何内容2xx- 那么它将重试传递.如果它没有重试,那么它会将消息放入错误队列 - 在这种情况下组合DLQ和PQ.

   这可能与您在托管服务中获得真正的"ESB"非常接近.

当然,那里有真正的开源ESB和SOA框架 - MULE,ServiceMix等等 - 但我不太了解你要做什么才能在那里做出任何推荐.:)

Answer 2

在大多数情况下，我不确定是否有必要区分DLQ和。PQ事实上，我发现这个定义相当随意。对于大多数事务性消息传递实现，如果消息在指定的重试次数内未成功从队列中消耗掉，则会转到DLQ. 为格式错误的消息设置单独的队列意味着您现在只有两个位置来查找未成功处理的消息，两个异常队列来监视或操作注意事项，以及一定比例的消息看起来可能属于其中之一队列（想到批处理场景）。