publish-subscribeとは? 一つのメッセージ、多数のリスナー

publish-subscribe (pub/sub) は、パブリッシャーがトピックにメッセージを発行し、任意の数のサブスクライバーがそのコピーを受け取るメッセージングパターンです。

pub/subは、単純なキューのファンアウト版のいとこのような存在です。パブリッシャーは特定のコンシューマーに送るのではなく、トピックに発行し、そのトピックのすべてのサブスクライバーが自分のコピーを受け取ります。パブリッシャーは誰が聞いているかを一切知らないため、プロデューサーに触れずに新しいコンシューマーを追加するのが容易です。

ファンアウトの仕組み

パブリッシャーは名前付きのトピックにメッセージを発行します。ブローカーは各サブスクライバーにコピーを配信します。サブスクライバーは独立しており、一つが遅かったり停止していたりしても他に影響を与えず、各自が自分のスケジュールでメッセージを処理します。

pub/sub対キュー

単純なキューは各メッセージを一つのコンシューマーに配信しますが、pub/subは各メッセージをすべてのサブスクライバーに配信します。作業を分配するにはキューを、多くの当事者が関心を持つ事実を放送するにはpub/subを使います。

疎結合に優れる理由

パブリッシャーはサブスクライバーの知識を必要としません。
新しいサブスクライバーはパブリッシャーを変えずに追加できます。
サブスクライバーは独立して障害を起こし復旧します。
イベント駆動の設計に自然に対応します。

ファンアウトのテスト

CIでpub/subを検証するとは、一つのイベントを発行すると期待されるすべてのサブスクライバーが起動することをアサートすることです。それには通常、実際のブローカーと、非同期配信を慎重に待つことが必要で、単一のリクエスト/レスポンスのテストよりも手間がかかります。

スキーマは共有の契約

多くのサブスクライバーが同じメッセージを消費するため、そのスキーマは全員との契約です。発行されるメッセージへの破壊的変更は複数のコンシューマーを一度に壊しうるので、独立したデプロイの前に後方互換のあるイベントスキーマが不可欠です。

ウォームなrunnerでの非同期テスト

pub/subのテストは非同期配信を待ち、しばしばブローカーを起動するため、同期テストより時間がかかります。ウォームなrunner (Latchkeyが提供するようなもの) は、その実時間コストを抑えます。

重要なポイント

publish-subscribeは、各メッセージをトピックのすべてのサブスクライバーに配信します。
パブリッシャーと、それを聞くコンシューマーを完全に疎結合にします。
発行されるメッセージのスキーマは、すべてのサブスクライバーにまたがる共有の契約です。