Amazon SQS Dead Letter Queue：本当にデッドレターですか、それとも毒ですか？
AmazonのSQSDead LetterQueueが正確に何をしているのかを明確にしようとしています。
http://aws.typepad.com/aws/2014/01/Amazon-sqs-new-dead-letter-queue.html によると
Dead Letter Queue-消費者が最大数受信した後に正常に処理されなかったメッセージを受信するSQSキューのARN（Amazonリソース名）。
それはPoisionQueueのように聞こえませんか？主な違いは、消費者がメッセージを受信したことです。デッドレターとは、メッセージに問題がない可能性があるが、おそらくサービスの停止が原因で配信できない場合です。 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またはPQAFAIKをサポートしていません。
IronMQは、SQSよりも少し完全な機能を備えたもう1つのRESTフルメッセージキューイングサービスです。 （True FIFOメッセージの順序、遅延が長くなるなどですが、残念ながらメッセージサイズは小さくなります。）プッシュキューを使用すると、プッシュ「サブスクライバー」を設定できます。プッシュ「サブスクライバー」はHTTPを受信しますPOST新しいメッセージがキューに入れられるときはいつでも。
IronMQがメッセージの配信に失敗した場合（HTTP POSTがタイムアウトした場合）、またはエンドポイントが
2xx以外のものを返した場合）、配信を再試行します。再試行すると、メッセージがエラーキュー（この場合はDLQとPQの組み合わせ）に配置されます。これはおそらく、マネージドサービスで真の「ESB」に到達するのと同じくらい近いでしょう。
もちろん、真のオープンソースESBとSOAフレームワーク-- [〜＃〜] mule [〜＃〜] 、 ServiceMix など-しかし、そこで何らかの推奨を行うためにあなたが何をしようとしているのか、私にはほとんどわかりません。:)
ほとんどの場合、DLQとPQを区別する必要があるかどうかはわかりません。実際、この定義はかなり恣意的だと思います。ほとんどのトランザクションメッセージングの実装では、指定された再試行回数内にメッセージがキューから正常に消費されない場合、メッセージはDLQに送られます。不正な形式のメッセージ用に個別のキューがあるということは、正常に処理されていないメッセージを探すための2つの場所、監視または運用上の考慮事項のための2つの例外キュー、およびメッセージの一部がいずれかに属しているように見えることを意味します。キュー（バッチ処理のシナリオが思い浮かびます）。
いいえ、アクティブなESBのようには動作しません。 Simple Queue Serviceは、定義上単純です。 「少なくとも1回」の配達保証がありますが、それを超えると、約束はほとんどありません。
ポーリング/ロングポーリング専用に設計されています。それぞれが異なる目的を果たす複数のキューを持つことができますが、単一のキューは非常に単純であり、複数の機能を提供したり、高度なロジックを提供したりすることを目的としていません。 SWFは必要なものを提供する場合がありますが、ESBを実装する必要がある可能性があります。