パブリッシュ/サブスクライブパターン

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ではソフトウェアアーキテクチャパブリッシュ・サブスクライブすること、メッセージングパターンの送信者のメッセージがあれば、出版社と呼ばれるが、加入者と呼ばれる、特定の受信機に直接送信するメッセージをプログラムが、代わりにその加入者の知識がなくてもクラスにパブリッシュされたメッセージを分類していません、 あるかもしれません。同様に、サブスクライバーは1つ以上のクラスに関心を示し、関心のあるメッセージのみを受信します。発行者が存在するかどうかはわかりません。

パブリッシュ/サブスクライブは、メッセージキューパラダイムの兄弟であり、通常、より大規模なメッセージ指向ミドルウェアシステムの一部です。ほとんどのメッセージングシステムは、APIでpub / subモデルとメッセージキューモデルの両方をサポートしています例:Javaメッセージサービス(JMS)。

このパターンは、より優れたネットワークスケーラビリティとより動的なネットワークトポロジを提供し、その結果、発行者と発行されたデータの構造を変更する柔軟性が低下します。

メッセージフィルタリング

パブリッシュ/サブスクライブモデルでは、サブスクライバーは通常、パブリッシュされたメッセージ全体のサブセットのみを受信します。受信および処理するメッセージを選択するプロセスは、フィルタリングと呼ばれますフィルタリングには、トピックベースとコンテンツベースの2つの一般的な形式があります。

トピックベースのシステムでは、メッセージは「トピック」または名前の論理チャネルに公開されています。トピックベースのシステムのサブスクライバーは、サブスクライブしているトピックに公開されたすべてのメッセージを受信します。出版社は、購読者が購読できるトピックを定義する責任があります。

コンテンツベースのこれらのメッセージの属性またはコンテンツが加入者によって定義された制約に一致する場合、システムは、メッセージは加入者のみに配信されます。サブスクライバーは、メッセージを分類する責任があります。

一部のシステムは、2つのハイブリッドサポートしています。パブリッシャーはトピックにメッセージを投稿し、サブスクライバーは1つ以上のトピックへのコンテンツベースのサブスクリプションを登録します。

トポロジ

多くのpub / subシステムでは、パブリッシャーは中間メッセージブローカーまたはイベントバスメッセージを投稿し、サブスクライバーはそのブローカーにサブスクリプションを登録して、ブローカーにフィルタリングを実行させます。ブローカーは通常、ストアアンドフォワード機能を実行して、パブリッシャーからサブスクライバーにメッセージをルーティングします。さらに、ブローカーはルーティングの前にキュー内のメッセージに優先順位を付ける場合があります

サブスクライバーは、ビルド時、初期化時、または実行時に特定のメッセージに登録できます。 GUIシステムでは、サブスクライバーは、ビルド時間の登録に対応するユーザーコマンド(ボタンのクリックなど)を処理するようにコーディングできます。一部のフレームワークおよびソフトウェア製品は、XML構成ファイルを使用してサブスクライバーを登録します。これらの構成ファイルは、初期化時に読み取られます。最も洗練された代替手段は、実行時にサブスクライバーを追加または削除できる場合です。この後者のアプローチは、たとえば、データベーストリガーメーリングリスト、およびRSSで使用されます

データ配信サービス(DDS)ミドルウェアは、途中でブローカーを使用していません。代わりに、pub / subシステムの各パブリッシャーとサブスクライバーは、IPマルチキャストを介して相互にメタデータを共有します。パブリッシャーとサブスクライバーはこの情報をローカルにキャッシュし、共有認識での互いの検出に基づいてメッセージをルーティングします。事実上、ブローカーレスアーキテクチャでは、パブリッシャーからサブスクライバーへの効率的な分散ルーティングを可能にするオーバーレイネットワークを構築するためにパブリッシュ/サブスクライブシステムが必要です。Jon Kleinbergは、効率的な分散ルーティングにはナビゲート可能なスモールワールドトポロジが必要であることを示しました。このようなスモールワールドトポロジは通常、分散型またはフェデレーション型のパブリッシュ/サブスクライブシステムによって実装されます。[1]ローカリティ対応のパブリッシュ/サブスクライブシステム[2]は、短距離で低コストのリンクを介してサブスクリプションをルーティングするSmall-Worldトポロジを構築し、それによってサブスクリプションの配信時間を短縮します。

歴史

早い公に説明パブ/サブシステムの一つは、1987年に記述イシスツールキットの「ニュース」のサブシステムであったコンピューティング機学会活用論文で(ACM)オペレーティングシステムの原理会議シンポジウム(SOSP '87)、」仮想の同期中に分散システム。123-138" 。[3]

利点

緩い結合

出版社は加入者とゆるく結びついており、彼らの存在を知る必要さえありません。トピックに焦点を当てることで、パブリッシャーとサブスクライバーはシステムトポロジを知らないままでいることができます。それぞれが、互いに独立して通常どおりに動作し続けることができます。従来の密結合のクライアントサーバーパラダイムでは、サーバープロセスが実行されていない間、クライアントはサーバーにメッセージを投稿できません。また、クライアントが実行されていない限り、サーバーはメッセージを受信できません。多くのpub / subシステムは、パブリッシャーとサブスクライバーの場所を分離するだけでなく、それらを一時的に分離します。このようなpub / subシステムを使用するミドルウェアアナリスト使用する一般的な戦略は、パブリッシャーを停止して、サブスクライバーがバックログ(帯域幅調整)。

スケーラビリティ

Pub / subは、並列操作、メッセージキャッシング、ツリーベースまたはネットワークベースのルーティングなどを通じて、従来のクライアントサーバーよりも優れたスケーラビリティの機会を提供します。ただし、特定のタイプの密結合の大容量エンタープライズ環境では、システムとしてスケールアップして、pub / subインフラストラクチャを共有する数千のサーバーを備えたデータセンターになると、現在のベンダーシステムはこの利点を失うことがよくあります。これらのコンテキストでの高負荷下でのpub / sub製品のスケーラビリティは、研究上の課題です。

一方、エンタープライズ環境の外では、pub / subパラダイムは、単一のデータセンターをはるかに超えるボリュームへのスケーラビリティを証明しており、RSSAtomなどのWebシンジケーションプロトコルを介してインターネット全体の分散メッセージングを提供しますこれらのシンジケートプロトコルは、ローエンドのWebサーバーでさえ(潜在的に)数百万の個別のサブスクライバーノードにメッセージをシンジケートする機能と引き換えに、より高い遅延と配信保証の欠如を受け入れます。

短所

pub / subシステムで最も深刻な問題は、主な利点の副作用です。つまり、パブリッシャーとサブスクライバーの分離です。

メッセージ配信の問題

pub / subシステムは、確実な配信など、特定のアプリケーションが必要とする可能性のあるより強力なシステムプロパティを提供できるように注意深く設計する必要があります。

  • pub / subシステムのブローカーは、指定された時間メッセージを配信するように設計されている場合がありますが、すべてのサブスクライバーによるメッセージの正常な受信の確認を受信したかどうかに関係なく、配信の試行を停止します。このように設計されたpub / subシステムは、確実な配信などを必要とする可能性のあるアプリケーションへのメッセージの配信を保証できません。このようなパブリッシャーとサブスクライバーのペアの設計の緊密な結合は、そのような確実な配信を実現するために、pub / subアーキテクチャーの外部で実施する必要があります(たとえば、サブスクライバーに受信メッセージの公開を要求することによって)。
  • pub / subシステムのパブリッシャーは、実際には聞いていないのに、サブスクライバーが聞いていると想定する場合があります。工場では、機器が問題や障害をサブスクライバーに公開して、それらの問題を表示およびログに記録できるpub / subシステムを利用する場合があります。ロガーに障害が発生した場合(クラッシュ)、機器の問題の発行者は必ずしもロガーの障害の通知を受け取るとは限らず、エラーメッセージはpub / subシステム上のどの機器によっても表示または記録されません。これは、クライアント/サーバーシステムなどの代替メッセージングアーキテクチャの設計上の課題でもあります。クライアント/サーバーシステムでは、エラーロガーに障害が発生すると、システムはエラーロガー(サーバー)の障害の兆候を受け取ります。ただし、クライアント/サーバーシステムは、冗長ログサーバーをオンラインにするか、フォールバックログサーバーを動的に生成することによって、その障害に対処する必要があります。これにより、クライアントとサーバーの設計だけでなく、クライアント/サーバーアーキテクチャ全体が複雑になります。ただし、pub / subシステムでは、既存のロガーと完全に重複する冗長ロギングサブスクライバーをシステムに追加して、システム上の他の機器に影響を与えることなくロギングの信頼性を高めることができます。 pub / subシステムでは、機器の問題メッセージロギングの基本機能を実装した後、確実なエラーメッセージロギングの機能を段階的に追加できます。pub / subシステムでは、機器の問題メッセージロギングの基本機能を実装した後、確実なエラーメッセージロギングの機能を段階的に追加できます。pub / subシステムでは、機器の問題メッセージロギングの基本機能を実装した後、確実なエラーメッセージロギングの機能を段階的に追加できます。

pub / subパターンは、パブリッシャーノードとサブスクライバーノードの数が少なく、メッセージ量が少ない小規模なネットワークに適しています。ただし、ノードとメッセージの数が増えると、不安定になる可能性が高くなり、pub / subネットワークの最大スケーラビリティが制限されます。大規模なスループットの不安定性の例は次のとおりです。

  • 負荷の急増—加入者の要求がネットワークスループットを飽和させた後、メッセージ量が少ない期間(ネットワーク帯域幅が十分に活用されていない)
  • 速度低下-ますます多くのアプリケーションがシステムを使用するにつれて(別々のpub / subチャネルで通信している場合でも)、個々のサブスクライバーへのメッセージボリュームフローが遅くなります

ブローカー(サーバー)を使用するpub / subシステムの場合、ブローカーがサブスクライバーにメッセージを送信するための引数は帯域内であり、セキュリティの問題が発生する可能性があります。ブローカーは、間違ったクライアントに通知を送信することに騙され、クライアントに対するサービス拒否要求を増幅する可能性があります。ブローカー自体は、作成されたサブスクリプションを追跡するためにリソースを割り当てるため、過負荷になる可能性があります。

ブローカーに依存しないシステムでも、サブスクライバーは、受信が許可されていないデータを受信できる場合があります。許可されていない発行者は、pub / subシステムに誤ったメッセージや有害なメッセージを導入する可能性があります。これは、メッセージブロードキャストまたはマルチキャストするシステムに特に当てはまります。 暗号化(例:トランスポート層セキュリティ(SSL / TLS))は、不正アクセスを防ぐことはできますが、許可された発行元による有害なメッセージの導入を防ぐことはできません。クライアント/サーバーシステムなど、pub / sub以外のアーキテクチャも、悪意を持って動作する許可されたメッセージ送信者に対して脆弱です。

も参照してください

参考文献

  1. ^ a b Chen、Chen; Tock、Yoav; Girdzijauskas、Sarunas(2018)。「BeaConvey:スモールワールドネットワークでのトピックベースのパブリッシュ/サブスクライブのためのオーバーレイとルーティングの共同設計」分散型およびイベントベースのシステムに関する第12回ACM国際会議の議事録-DEBS'18ニュージーランド、ハミルトン:ACM Press:64–75。土井10.1145 /3210284.3210287ISBN 9781450357821S2CID  43929719
  2. ^ ラヒミアン、ファテメ; Le Nguyen Huu、Thinh; Girdzijauskas、Sarunas(2012)、Göschka、Karl Michael; Haridi、Seif(eds。)、 "Locality-Awareness in a Peer-to-Peer Publish / Subscribe Network"、Distributed Applications and Interoperable Systems、Springer Berlin Heidelberg、7272、pp。45–58、doi10.1007 / 978-3 -642-30823-9_4ISBN 9783642308222
  3. ^ Birman、K。; ジョセフ、T。(1987)。「分散システムでの仮想同期の活用」。オペレーティングシステムの原則に関する第11回ACMシンポジウムの議事録-SOSP'87pp。123–138。土井10.1145 /41457.37515ISBN 089791242XS2CID  7739589

外部リンク