第4章 AMQP
AMQP は、メッセージを確実に送受信するためのオープンインターネットプロトコルです。これは、複数のソフトウェアベンダーや主要な機関によりサポートされます。AMQP 1.0 は 2012 年に OASIS 標準と 2014 年に ISO 標準になりました。
- セッション多重化機能のあるフレーム化プロトコル
- ピアツーピアおよびクライアントサーバー接続に対応
- 標準タイプシステムでロスレスデータ交換を実現
- フロー制御、ハートビート、およびリソース制限を提供して分散システムの信頼性を強化
- 領域効率の高いバイナリーエンコーディングおよびパイプを使用してレイテンシーを軽減
4.1. AMQP 配信の保証
解決用の AMQP モデルは、メッセージ配信のライフサイクルに基づいています。リンクの最後には、メッセージ転送を表すエンティティーが作成され、しばらくの間存在し、最後に「settled」になります。Settled になると、完了を待たずに次に進めます。配送ライフサイクルには、約 4 つのイベントがあります。
- 配信が送信側で作成される。
- 配信が受信側で作成される。
- 配信が送信者に設定される。
- 配信が受信側で設定される。
送信側と受信側が同時に動作しているため、これらのイベントはさまざまな順序で発生する可能性があります。また、これらのイベントの順序により、メッセージ配信の保証が異なります。
At-most-once 配信
At-most-once 配信は、「presettled」または「fire and forget」配信とも呼ばれます。
- 配信が送信側で作成される。
- 配信が送信者に設定される。
- 配信が受信側で作成される。
- 配信が受信側で設定される。
この設定では、送信側が配信を解決 (つまり、完了を待たずに実行) してから、受信側に到達し、配信中に問題が発生した場合には、送信側は再送信するためのベースがありません。
このモードは、定期的なセンサーデータなど、一時的にメッセージが損失しても許容できるアプリケーションや、また、アプリケーション自体が障害と再送信を検出できるアプリケーションの場合に適しています。
at-least-once 配信
- 配信が送信側で作成される。
- 配信が受信側で作成される。
- 配信が受信側で設定される。
- 配信が送信者に設定される。
この設定では、受信側が受信した時点で配信を解決し、送信側は、受信側が解決した時点で、配信を解決します。配信中に問題が発生すると、送信側は再送信できます。ただし、受信側がすでに配信について完了を待たずに次に進んでいるので、再送信すると、メッセージの配信が重複してしまいます。アプリケーションは一意のメッセージ ID を使用することで重複を除外できます。
