我试图澄清亚马逊的 SQS 死信队列到底在做什么。
根据http://aws.typepad.com/aws/2014/01/amazon-sqs-new-dead-letter-queue.html
死信队列- SQS 队列的 ARN（Amazon 资源名称），将接收在消费者接收到最大数量后未成功处理的消息。
这听起来不是更像毒药队列吗？关键区别在于消费者确实收到了消息。死信是指消息可能很好，但可能由于服务中断而无法传递。http://www.eaipatterns.com/DeadLetterChannel.html
这听起来像是多次成功接收消息，但处理消息失败，我理解这是毒消息队列的含义。
消息总线与队列
死信模式在普通旧队列的上下文中是否具有不同的含义？由于 SQS 只是一个队列，而不是消息总线，因此它不负责传递消息。相反，它等待消息被拾取（请求）。所以传统的死信模式并不真正适用，因为没有消息总线试图传递消息并且无法找到接收者。
SQS 可以像消息总线一样工作吗？
有没有办法通过 SQS 设置通道和侦听器，而不是显式轮询队列中的消息？
好问题。
死信通道的具体工作方式取决于特定消息传递系统的实现，如果它提供的话。该通道可以称为“死消息队列”或“死信队列”。通常，安装了消息传递系统的每台机器都有自己的本地死信通道，因此无论消息死在什么机器上，它都可以从一个本地队列移动到另一个本地队列，而没有任何网络不确定性。这也记录了消息死在哪台机器上。当消息传递系统移动消息时，它还可能记录消息应该被传递的原始通道。
...尚不清楚是否真的有区别。我理解您所说的“毒药队列”是什么意思，并且您对 SQS 的工作原理的理解是正确的。从语义上讲，DLQ 和 PQ 之间的区别——电子邮件风格中的“无法投递”与“毒药”——我并不清楚。也许 PQ 是 DLQ 的一种风格。
FWIW，ActiveMQ 的重新传递策略使用与 SQS 相同的 DLQ 定义——混合 DLQ/PQ。
SQS 可以像消息总线一样工作吗？
SQS不能，但是有类似的产品可以。
SNS（Simple Notification Service）是一个广义的发布-订阅主题系统。SNS 允许您创建主题，然后注册接收推送通知的订阅者。目前，推送通知可以采用 HTTP/S、电子邮件、SMS、SQS 和移动设备推送通知的形式。
SNS 有一个相当健全的 HTTP/S重试策略，但不支持 DLQ 或 PQ AFAIK。
IronMQ 是另一个 REST-ful 消息队列服务，它比 SQS 功能更全。（真正的 FIFO 消息排序、更长的延迟等，但遗憾的是消息大小更小。）推送队列允许您设置推送“订阅者”，然后在任何时候将新消息放入队列时接收 HTTP POST。
如果 IronMQ 无法传递消息——HTTP POST 超时，或者你的端点返回除了 a 之外的任何内容2xx——那么它将重试传递。如果重试次数用完，它会将消息放入错误队列——在这种情况下是 DLQ 和 PQ 的组合。
这可能与您在托管服务中接近真正的“ESB”一样接近。
当然，还有真正的开源 ESB 和 SOA 框架—— MULE、ServiceMix等等——但我对你想要做的事情知之甚少，无法在那里提出任何建议。:)
在大多数情况下，我不确定区分DLQ和PQ是否必要。事实上，我发现这个定义相当武断。对于大多数事务性消息传递实现，如果消息在指定的重试次数内没有成功从队列中消耗掉，它会转到DLQ. 为格式错误的消息设置一个单独的队列意味着您现在只有两个位置来查找未成功处理的消息，两个异常队列用于监控或操作注意事项，以及一些看起来可能属于其中一个的消息百分比队列（想到批处理场景）。
不，它的行为不像活动的 ESB。根据定义，简单队列服务很简单。有一个“至少一次”的交付保证，但除此之外，它几乎没有做出任何承诺。
它仅设计用于轮询/长轮询。您可以有多个队列，每个队列用于不同的目的，但单个队列非常简单，并不旨在为多个功能提供服务或提供高级逻辑。SWF 可能会提供您想要的，但您可能需要实现 ESB。