• Facebook
  • Twitter
  • Youtube
  • 裏地付き
  • RSS
  • ドキュメント
  • 比較
  • ブログ
  • ダウンロード
  • お問い合わせ
ダウンロード
目次を表示/非表示

キャッシュ内の Pub/Sub メッセージング: 概要

このPublish/Subscribe(Pub/Sub)メッセージングパラダイムは、送信者(パブリッシャー)と受信者(サブスクライバー)を直接結合することなく、複数のアプリケーション間でメッセージを交換するための中間チャネル(トピックと呼ばれる)を提供します。パブリッシャーアプリケーションは、トピックを介してサブスクライバーアプリケーションにメッセージを送信します。すべてのPub/Subモデルは通信にチャネルを必要とするため、 NCache トピックの媒体として機能し、パブリッシャーはトピックにメッセージをパブリッシュします。サブスクライバーはトピックを介して通知としてメッセージを受け取ります。 NCache メッセージバスとして、アプリケーションは直接結合することなく高い可用性と拡張性を実現し、パブリッシャーは数千のサブスクライバーにイベントをリアルタイムでブロードキャストできます。分散キャッシュに加えて、 NCache 専用の Pub/Sub メッセージング キャッシュ.

重要

次の理由から、専用の Pub/Sub キャッシュをお勧めします。

  • 立ち退き: キャッシュにメッセージとキャッシュ アイテムが含まれている場合、キャッシュ アイテムを頻繁に削除すると、サブスクライバーに転送する前にメッセージが削除される場合があります。

  • 状態転送: 状態転送は、各キャッシュ アイテム操作にコストを追加します。 メッセージは頻繁にパブリッシュ、リレー、期限切れになるため、この繰り返しのアクティビティは状態転送をトリガーするため、コストがかかることがわかります。

分散アーキテクチャでPub/Subメッセージングを使用する理由

リアルタイム イベントでは、イベント ドリブンの分散アーキテクチャ内のさまざまなアプリケーション間で通知を共有する必要があります。 Pub/Sub パターンを使用すると、パブリッシャーはイベントをサブスクライバーと共有できるため、目的のイベントの発生時に必要な処理が行われます。

例えば、サブスクライバーのグループが注文の配送状況を追跡するために、注文の発送詳細に関する情報に関心を持っているとします。そのため、彼らは注文詳細のメッセージを中継するトピックをサブスクライブします。パブリッシャーがトピックにメッセージをパブリッシュすると、サブスクライバーは通知を受け取り、注文詳細を含むメッセージを受信し、各自で処理することができます。

コアコンポーネント NCache パブリッシュ/サブスクライブモデル

の基本コンポーネント NCache パブリッシャー サブスクライバー (Pub/Sub) モデルは以下にリストされており、後で詳しく説明します。

  • トピック: メッセージが公開される場所。

  • 出版社: Topic/Topics にメッセージを公開するアプリケーション (Web アプリケーション、デスクトップ アプリケーション、マイクロサービス)。

  • 加入者: Topic/Topics からメッセージを受信することに関心のあるアプリケーション。

  • サブスクリプション: サブスクライバが意図したメッセージを受信するために作成された対象エンティティ。

  • 本文: パブリッシャーがトピック経由で送信し、サブスクライバーが受信する実際のデータ オブジェクト。

パブリッシュサブスクライブ NCache

のトピック NCache

パブリッシャーはトピックにメッセージをパブリッシュします。サブスクライバーはトピックを購読してメッセージを受信します。このトピックは分散形式で存在します。 NCacheそのため、その作成はすべてのクラスタノードで行われます。メッセージストアは、パブリッシャーがキューにパブリッシュする実際のデータオブジェクトを格納します。また、内部的には、サブスクライブしているすべてのサブスクライバーのリストとパブリッシャーのリストを管理します。 ITopic/Topic インターフェイスが容易に トピック作成, トピック取得, トピックの削除。 あなたがすることもできます トピックを非同期的に削除する トピックが削除されるまで待機する必要がなくなります。

お願い

トピックと基礎となるメッセージの分散特性により、スケーラビリティが向上します。

メッセージがトピックに公開されると、トピックはイベントを発動し、トピックはそれをサブスクライバーの好みに基づいて中継します。 メッセージ配信オプション 必要に応じてメッセージを取得できるようにします。次の図は、パブリッシャーとサブスクライバーの中間チャネルとしてのトピックの役割を示しています。

のPubSubトピック NCache

お願い

一時的にサブスクライバーが切断され、その後自動的に再接続された場合、サブスクリプションや障害イベント通知など、トピックに関連するすべての情報が、サブスクライバー側で中断することなくトピックに再登録されます。

トピックの優先順位

NCache トピックレベルの優先度を導入し、トピックの重要度に基づいて相対的な優先度を割り当てることができます。重要なメッセージを発行する必要がある場合は、優先度の高いトピックを作成できます。これにより、それらのメッセージが最初に配信されます。同様に、重要度の低いメッセージを発行する場合は、優先度の低いトピックを作成できます。キャッシュはこれらのメッセージを最初に削除します。 トピックレベルの優先度 重要なメッセージの配信を優先するため、トピック作成時にこのチェックボックスをオンにします。

重要

トピックの優先度はトピックの作成時にのみ指定でき、後で変更することはできません。

トピック削除通知

トピック削除通知を受け取るには、アプリケーションは OnTopicDeleted イベントトピックが削除されると、キャッシュ内のすべてのメッセージと関連メタ情報が削除されます。そのため、サブスクライバーとパブリッシャーは、以下の理由により、この削除に関する通知を受け取ります。

  • サブスクライバーは、登録されたトピックからの受信メッセージを待機している可能性があります。トピックが削除されると、サブスクライバーはイベント通知を通じてそれに応じて実行を処理し、無限の待機状態を回避できます。
  • パブリッシャーは、存在しないトピックにメッセージを送信することを回避し、保留中のメッセージと将来の実行をそれに応じて処理できます。

メッセージをトピックにパブリッシュする

パブリッシャーは次のことができます トピックにメッセージを公開する トピック名を指定することで、メッセージを非同期かつ一括で発行し、アプリケーションのパフォーマンスを向上させることができます。パーティション化されたキャッシュは、クラスタ全体にメッセージを分散します。メッセージルーティングでは、すべてのメッセージに一意のIDが付けられます。 MessageID パブリッシャー側、およびのハッシュ コード MessageID メッセージを格納するクラスタ ノードを決定します。 NCache パブリッシャーがメッセージのパブリッシュ中に次のプロパティを使用できるようにします。

お願い

NCache XNUMX 回の呼び出しで大量のメッセージを公開して、パフォーマンスとメモリ使用量を改善できます。

  • メッセージ配信オプション: パブリッシャーは、メッセージを XNUMX 人のサブスクライバーに配信するか、パブリッシュ時にすべてのサブスクライバーにブロードキャストするかを決定できます。 メッセージ配信オプション.

  • メッセージの有効期限: パブリッシャーは、次のことができます。 メッセージの有効期限を設定する キャッシュ内のメッセージの存続期間を制御します。 有効期限については、 メッセージ のセクションから無料でダウンロードできます。

  • メッセージ配信失敗通知: パブリッシャーは次のことができます MessageDeliveryFailure に登録する 特定のメッセージの配信に失敗した場合に通知を受け取る。 これらの配信失敗のシナリオについては、 サブスクリプションへのメッセージの割り当てと配信 のセクションから無料でダウンロードできます。

重要

メッセージ配信失敗通知は、有効期限のあるメッセージのみを対象としています。

  • トピック削除通知: パブリッシャーが登録できる トピック削除通知 トピックが削除された後、対応するメッセージが不当に公開されるのを防ぐためです。

トピックを購読する

加入者アプリケーションは、次のことができます。 トピックメッセージを購読する サブスクリプションを通じて、関心のあるトピックに自身を登録します。Pub/Subでは、サブスクリプションは特定のトピックに対するサブスクライバーの関心を表します。

お願い

新しいノードがキャッシュ クラスターに追加され、状態転送がトリガーされた場合、すべてのサブスクリプションとメッセージおよびキャッシュ データが新しいノードにレプリケートされます。

NCache トピック名またはパターンを指定してトピックを購読することができます。詳細については、 購読方法. さらに、設定することもできます メッセージ配信モード サブスクリプションの作成中に同期または非同期として。 NCache は、次に説明する複数のタイプの Pub/Sub サブスクリプションを提供します。

サブスクリプションとその種類

でのサブスクリプション NCache 次のタイプに分類できます。

の耐久性と非耐久性のサブスクリプション NCache

耐久性のある

お願い

永続サブスクリプションは名前付きサブスクリプションです。

で 耐久性のあるサブスクリプションキャッシュは、アプリケーション/マシンのシャットダウン、アプリケーションの再起動、またはネットワーク障害による接続の切断が発生した場合でも、サブスクライバーがメッセージを見逃さないことを保証します。したがって、永続サブスクリプションは、サブスクライバーの切断と再接続による影響を受けません。

お願い

永続サブスクリプションは、サブスクライバーが適切にサブスクリプションを解除しない限り削除されません。

サブスクライバーが切断された場合、そのサブスクライバー宛てのメッセージは、サブスクライバーが再加入するか、メッセージが期限切れになるまでサーバー上に保存されます。永続サブスクリプションは、サブスクライバーが適切に登録解除しない限り、サブスクライバーの切断時に自動的に削除されません。永続サブスクリプションはさらに以下のように分類されます。

  • 共有: 共有の永続的なサブスクリプションとは、複数のサブスクライバーが名前付きサブスクリプションを共有することを意味します。共有サブスクリプションに割り当てられたメッセージは、ラウンドロビン方式でサブスクライバー間で負荷分散されます。サブスクライバーがネットワークを離れた場合でも、メッセージはアクティブなサブスクライバーに配信され続けます。したがって、サブスクライバーが割り当て後に正常または突然離れた場合、そのサブスクライバーに割り当てられたメッセージは他のアクティブなサブスクライバーに再割り当てされます。

    重要

    共有サブスクリプションは、永続サブスクリプションでのみサポートされます。

    共有サブスクリプションでは、サブスクリプションはトピック上に残り、すべてのサブスクライバーがサブスクリプションを解除するまでサブスクリプションを解除することはできません。つまり、アクティブなサブスクライバーが 1 人でもいる限り、サブスクリプションはアクティブなままになります。

  • 排他的: 排他的永続サブスクリプションとは、サブスクリプションに対して一度に登録されるアクティブなサブスクライバーが 1 つだけであることを意味します。サブスクライバーが適切に登録解除された場合、排他的サブスクリプションは新しいサブスクライバーに割り当てることができます。サブスクライバーが突然登録解除された場合、アイドル時間を待ってから新しいサブスクリプション要求が受け入れられます。割り当てられたメッセージは、サブスクライバーがいなくても常にそこに残ります。

非耐久性

で 非永続サブスクリプションサブスクライバーは、接続が維持されている間、自分宛てのメッセージのみを受信します。サブスクライバーがネットワークから離脱した場合、切断期間中はパブリッシュされたメッセージは受信されません。非永続サブスクリプションは、デフォルトで排他的(Exclusive)です。

重要

サブスクライバー アプリケーションを再起動すると、サブスクライバーのメッセージが失われます。

また、非永続サブスクリプションは、サブスクライバーがネットワークを離れると自動的に削除されます。つまり、そのサブスクライバーが再度参加するか、接続を再度確立すると、新しいサブスクリプションと見なされます。

恒久サブスクリプションの有効期限

また、ご購読はいつでも停止することが可能です 永続サブスクリプションの有効期限を設定する 一定期間の非アクティブ期間の後、例えば、アクティブな購読者が長期間いない場合などです。購読の有効期限が切れると、この購読に割り当てられたメッセージは、 DeliveryOption これらのメッセージの。

お願い

サブスクライバがポーリングまたはその他のアクティビティを実行するたびに、サブスクリプションの有効期限がリセットされます。

非アクティブなサブスクリプションの処理

お願い

非永続サブスクリプションのみが非アクティブとしてマークされ、これは永続サブスクリプションには適用されません。

一定の非アクティブ期間を待った後、サブスクリプションに対してアクティブなサブスクライバーがいない場合、サブスクリプションは期限切れと見なされます。 加入者が非アクティブ期間中に切断された後に再加入すると、割り当てられたメッセージを受信できるようになります。

重要

サーバー側でのメモリ過負荷を回避するために、非アクティブなサブスクリプションを処理する必要があります。

非アクティブ期間を待った後、サブスクリプションは期限切れになり、割り当てられたメッセージは他のサブスクリプションに再割り当てされます。 メッセージの再割り当ては、メッセージの配信オプションによって異なります。

  • サブスクリプション A に割り当てられたメッセージの配信オプションが ALL に設定されており、サブスクリプション A の有効期限が切れる前にすでに別のサブスクリプション B に割り当てられている場合、再割り当ては必要ありません。

  • サブスクリプションに割り当てられたメッセージの配信オプションが ANY に設定されており、サブスクリプションの有効期限が切れた場合、割り当てられたメッセージは常に他のサブスクリプションに再割り当てされます。

メッセージ

メッセージには、パブリッシャーによって送信され、トピックを介してサブスクライバーに配信される実際のデータオブジェクトが含まれます。パブリッシャーがトピックにメッセージをパブリッシュすると、登録されているサブスクライバーには、関心のあるメッセージがパブリッシュされたことが通知されます。複数のメッセージがある場合、それらは特定のトピックのキュー内に順番に格納されます。ここでは、サブスクリプションへのメッセージの割り当て、メッセージの配信、および確認応答メカニズムについてさらに詳しく説明します。

お願い

同じメッセージを複数のトピックに割り当てることができます。これは自動生成された ID によって一意に識別されます。

サブスクリプションへのメッセージの割り当てと配信

最初は、メッセージはサーバー側で割り当てられていません。すべてのサブスクリプションは、 DeliveryOptionサブスクリプションの割り当てが発生すると、サブスクライバーは通知を受け取ります。その後、サブスクライバーはポーリングメカニズムを実装して複数のメッセージを一括取得し、サーバー側のオーバーヘッドを削減します。メッセージを受信した後、サブスクライバーは確認応答を送信し、メッセージは配信済みとみなされます。

お願い

メッセージを受信するサブスクライバーがいない場合は、メッセージはトピックに保存されます。最初のサブスクライバーがトピックにサブスクライブすると、メッセージが割り当てられ、最初のサブスクライバーに配信されます。

メッセージ配信オプション

発行者は、メッセージの配信オプションを指定して、メッセージを単一の購読者に配信するか、配信時にすべての購読者に一斉送信するかを決定する必要があります。配信成功の定義は、指定された配信オプションによって異なることに注意することが重要です。2つの配信オプションと、それに対応する配信成功の基準については、以下で説明します。

  • すべて: 登録済みの購読者全員がメッセージを受信します。メッセージは、すべての購読者が受信確認を完了した時点で削除されます。

  • どれでも: 単一の登録済み加入者がメッセージを受信します。 割り当てられたサブスクライバが確認応答を送信しない場合、メッセージは次のサブスクライバに再割り当てされます。 確認応答を送信した場合、メッセージは正常に配信されたとみなされます。

お願い

指定された配信オプションに従ってメッセージが正常に配信されると、そのメッセージはキャッシュから削除されます。

メッセージの保存と配布

キャッシュ内でのメッセージの保存と配布の重要な側面は次のとおりです。

  • メッセージはトポロジに基づいてノード間で分散されます。

  • パーティション レプリカ トポロジとパーティション化トポロジでは、ハッシュ ベースの分散が使用されます。

  • レプリケート トポロジの場合、メッセージはクラスター化キャッシュのすべてのノードにレプリケートされます。 ただし、コーディネーター ノードはメッセージ操作を担当します。

  • ミラー トポロジの場合、メッセージはアクティブ ノードにパブリッシュされ、それに応じてパッシブ ノードに複製されます。

  • メッセージ ストアがエビクションに近づいている場合は、メッセージ ストアがいっぱいになり、エビクションが開始されたことを示すイベントがログに記録されます。

  • メッセージには、キャッシュ メモリのオーバーヘッドがあります。 したがって、キャッシュ サイズを計算する際には、メッセージ サイズを考慮する必要があります。

メッセージの動作

ここでは、次の場合に予想されるメッセージの動作について説明します。

  • キャッシュのクリア時: キャッシュがクリアされると、メッセージはキャッシュ アイテムと一緒に削除されます。

  • キャッシュの再起動時: キャッシュのクリアと同様に、キャッシュを再起動するとキャッシュの内容もクリアされます。これには、すべてのトピックとそこに含まれるメッセージも含まれます。

  • 立ち退き: If 立ち退き Pub/Sub キャッシュで有効になっている場合、最初にデータが削除され、次にメッセージが削除されます。

  • 暗号化と圧縮: If 暗号化 (NAIST) と キャッシュレベルで設定されている場合、トピックメッセージのペイロードにも適用されます。

  • 状態遷移: 状態転送の場合、メッセージがクラスター内の別のノードに移動すると、メッセージが最終的に保存されるノードが配信を担当します。

メッセージ配信失敗通知

重要

メッセージ配信失敗通知を登録している発行者は、有効期限のあるメッセージが購読者に配信される前に期限切れになった場合に通知を受け取ります。

メッセージがどのサブスクライバーにも割り当てられない、または配信されない場合、それは失敗とみなされます。これは、サブスクライバが存在しないか、ネットワーク障害により非アクティブになっている場合に発生する可能性があります。このようなシナリオでは、パブリッシャーは次のことができます。 登録メッセージ配信失敗通知配信失敗通知は有効期限が切れたメッセージにのみ適用されることに注意してください。メッセージがいずれかのサブスクライバーに配信される前に有効期限が切れた場合、メッセージの配信は失敗したとみなされます。

お願い

トピックに対して複数のパブリッシャーが存在する場合、失敗通知は、失敗通知を登録したアクティブなパブリッシャーのいずれかに配信されます。

メッセージの有効期限

キャッシュ アイテムと同様に、パブリッシャーは次のことができます。 メッセージの有効期限を設定する。メッセージは有効期限が過ぎるとすぐにキャッシュから期限切れになり、同じクリーニング間隔メカニズムが使用されます。

メッセージの有効期限によって、メッセージがキャッシュに保持される時間が決まります。 配信に関係なく、メッセージが配信されない場合は、有効期限後に削除されます。 有効期限が切れる前にメッセージが正常に配信された場合、メッセージは有効期限を待たずにキャッシュから削除されます。

注文したメッセージ

NCache メッセージの順序がクライアント側で維持される順序付きメッセージをサポートするようになりました。パブリッシャーは 順序付けられたメッセージを発行する メッセージのチャンクにシーケンス名を指定することで、順序付けされたメッセージが配信されます。その後、順序付けされたメッセージは、公開された順序と同じ順序で購読者に配信されます。順序付けされたメッセージのチェーンでは、シーケンス文字列は同じである必要があります。シーケンス文字列を使用することで、ロケーションアフィニティメカニズムを使用してすべてのメッセージが同じノードに存在します。順序付けされたメッセージの重要な特性は次のとおりです。

お願い

同期配信モードは、順序付けられたメッセージに使用できます。

  • 同じシーケンスのパブリッシャーからのメッセージは、単一のキャッシュノードに存在します。

  • Status DeliveryOption が Any に設定されている場合、同じシーケンスのすべての順序付けされたメッセージが同じサブスクライバに配信されます。 特定の加入者が接続を失ったり利用できなくなった場合、この目的のために新しい加入者が再割り当てされます。 ただし、 DeliveryOption が [すべて] に設定されている場合、同じシーケンスのすべての順序付けされたメッセージがすべてのサブスクライバに配信されます。

  • 状態転送の場合、順序付けられたメッセージは順序を失い、順序を維持せずに公開される可能性があります。

  • 順序付けされたメッセージは、公開APIの同期モードを使用してのみ公開できます。 バルクおよび非同期API呼び出しはサポートされていません。

監視

NCache Pub/Sub トピックの統計を監視し、さまざまな観察を行う機能を提供します パフォーマンスカウンター この点については、Pub/Subトピックのアクティビティとステータスは、 WindowsPerfMonカウンター (NAIST) と コマンドラインツール.

信頼性と高可用性

NCache メッセージ配信の確認応答メカニズムを実装します。メッセージは、以下の条件に基づいて正常に配信されるまでメモリに保持されます。 少なくともXNUMX回の配達 基準。 したがって、 NCache 分散アーキテクチャでの Pub/Sub メッセージングのメッセージ配信の信頼性を保証します。

さらに、最大 XNUMX つのノードのフォールト トレランス パーティション-レプリカトポロジ Pub/Sub Messaging ストアの可用性を高めます。 ノードが何らかの理由でクラスターを離れた場合、レプリカにはメッセージのバックアップがあります。

このセクションの内容

Pub/Subトピック
Pub/Subモデルのトピックを作成、取得、削除する方法を説明します。 NCache.

メッセージをトピックにパブリッシュする
トピックの作成方法と、トピックへのメッセージの投稿方法について説明します。

トピックを購読する
トピックをサブスクライブして、興味のあるメッセージを受信する方法について説明します。

Pub/Subイベント
キャッシュとアプリケーション全体で発生するさまざまなイベントについてパブリッシャーとサブスクライバーに通知する Pub/Sub イベントについて説明します。

お問い合わせ

電話

+1 214-619-2601   (米国)

+44 20 7993 8327   (英国)

 
Eメール

sales@alachisoft.com

support@alachisoft.com

NCache
  • エディションの比較
  • NCache アーキテクチャ
  • ベンチマーク
ダウンロード
価格
遊び場を試してみる

デプロイメント
  • クラウド (SaaS & ソフトウェア)
  • オンプレミス
  • Kubernetes
  • デッカー
技術的なユースケース
  • ASP.NETセッション
  • ASP.NET Core セッション
  • Pub / Subメッセージング
  • リアルタイムASP.NET SignalR
  • インターネットのもの(IoT)
  • NoSQLデータベース
  • ストリーム処理
  • Microservices
資料
  • 雑誌の記事
  • サードパーティの記事
  • 記事
  • 動画
  • ホワイトペーパー
  • 作品
  • トーク
  • ブログ
  • ドキュメント
顧客のケーススタディ
  • お客様の声
  • Customers
サポート
  • デモを予約
  • フォーラム(Googleグループ)
  • ヒント
会社
  • リーダーシップ
  • Partners
  • ニュース
  • イベント
  • Careers
お問い合わせ

  • 英語中国語(簡体字)仏語ドイツ語イタリア語日本語韓国語ポルトガル語スペイン語

  • お問い合わせ
  •  
  • サイトマップ
  •  
  • 利用規約
  •  
  • プライバシーポリシー
©著作権 Alachisoft 2002 - . All rights reserved. NCache はダイヤテック株式会社の登録商標です。
トップに戻る