複数の高トランザクション サーバー アプリケーションが相互に通信する必要がある環境では、アプリケーションに最適な通信チャネルを見つけることが重要です。パブリッシャー/サブスクライブ (PubSub) モデルは、アプリケーションに通信プラットフォームを提供する場合に最も一般的な方法の 1 つです。これらのメディアの共通点は誰もが知っています。複数のクライアントがメッセージをパブリッシュし、複数のクライアントがメッセージをサブスクライブできます。これはすべて、非常に分離された方法で行われます。つまり、パブリッシャはメッセージをサブスクライブしているクライアントに直接展開しません。代わりに、メッセージ バスが、すべてのクライアントが通信する中間チャネルとして使用されます。
つまり、PubSub メッセージングは、パブリッシャーもサブスクライバーも互いの ID について何も知らない方法です。
ここで、発行者と購読者の数が増加すると何が起こるかを考えてみましょう。この数値が大きいほど、メッセージングの負荷が大きくなります。この状況により、PubSub プラットフォームがスケーラビリティのボトルネックを引き起こすことになり、分離されたメッセージング インターフェイスを導入する主な目的が果たせなくなります。
pub / subの一般的な動作を継承するだけでなく、他の多くの機能を簡単に追加できるソリューションを見てみましょう。 高速で非常にスケーラブルな方法。
NCache 詳細 NCache Pub /Sub-Docs スケールパブ/サブメッセージング-ウェビナー
使い方 NCache インメモリPubSub
NCache .NETアプリケーション用に、高速で柔軟性があり、最も線形にスケーラブルな分散キャッシュを提供します。
使い方 NCache アプリケーションを外出先で拡張することを計画している場合、イベント駆動型の PubSub プラットフォームが非常に有益であることが証明されるためです。システム内でのボトルネックの発生を防ぎます。
ここに NCache アプリケーションのメッセージングバスとして機能します。
NCache Pub/Sub実装の中間インターフェースとして機能します。 この図は、XNUMXつだけでなく複数のクライアントが一度にXNUMXつまたは複数のトピックにサブスクライブできることを示しています。
任意の数のアプリケーションがキャッシュに接続して、メッセージの公開を開始できます。 NCache サーバー。 これらのメッセージは、要件に応じてさまざまなクライアントによってサブスクライブされます。 終えた NCache、公開されたメッセージをすべてのサブスクライバーが受信するか、XNUMX人のサブスクライバーだけが受信するかを決定できます。 そうすることによって、 NCache .NETサーバーアプリケーションのメッセージングバスとして機能します。
NCache 詳細 Pub / Sub NCache Pub/Subイベント
簡単な PubSub の例 NCache
私が世界中のプレーヤーによって使用されているオンラインゲームアプリケーションを持っていると仮定しましょう。 私のアプリケーションには、音声通信だけでなくランタイムメッセージも組み込む機能があります。 複数のプレーヤーが、チャネルに対して、および自分のチームプレーヤーに対して同時にメッセージを送信します。
ゲームをプレイするプレイヤーの数を考えると、メッセージの負荷は非常に大きくなります。 ここで必要なのは、ゲームのパフォーマンスを向上させる通信インターフェイスです。 そしてこれのために、私は好む NCache 私のゲームのメッセージバスとして。
以下は、サーバーアプリケーションがメッセージを公開および受信できるシナリオを実装するために使用するスニペットです。 このコードは、トピックを取得し、それに対してメッセージを公開する方法を示しています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
// Precondition: Cache is already connected // Get the topic ITopic teamChat = cache.MessagingService.GetTopic("RuntimePlayerComms"); // Create the object to be sent in message // Get information of the player through player ID Player teamLeader = FetchInfo(1); // Create the message var newChatMessage = new Message(teamLeader); // Set the expiration time of the message newChatMessage.ExpirationTime = TimeSpan.FromSeconds(60); // Publish the message with delivery option set to All subscribers teamChat.Publish(newChatMessage, DeliveryOption.All, true); |
トピックに対してメッセージが公開されると、サブスクライバーはそのトピックに対してサブスクリプションを作成してメッセージを受信します。 次のコードは、サブスクライブするアプリケーションが特定のトピックをサブスクライブして、目的のメッセージを受信する方法を示しています。
1 2 3 4 5 6 7 8 9 |
// Precondition: Cache is already connected // Get the topic ITopic teamChat = cache.MessagingService.GetTopic("RuntimePlayerComms"); // Create and register subscribers for the topic // MessageReceived is the callback through which the message is delivered ITopicSubscription subscriber = teamChat.CreateSubscription(MessageReceived); |
NCache 詳細 メッセージを公開する メッセージを購読する
これまで、私が話していたのはpub / subの一般的な動作だけでしたが、実際に知っておく必要があるのは、余分な長さです。 NCache あなたのニーズを満たすために行きます。
私が以前に叫んだそれらの「他の機能」が何であるか疑問に思っていますか? によって独占的に提供される機能を正しく理解しましょう NCache.
排他的永続サブスクリプション
通常、クライアントがトピックをサブスクライブする場合、そのサブスクリプションは非永続サブスクリプションと呼ばれます。つまり、クライアントがサーバーから切断されると、そのサブスクリプションはすべて失われます。
NCache 永続的なサブスクリプションを提供します。 この場合、サーバーとクライアント間の接続が切断されても、そのクライアントのサブスクリプションはすべてそのまま残ります。 したがって、クライアントが再接続されると、サブスクライバーが切断されている間に公開されたすべてのメッセージを受信します。
アプリケーションでこのシナリオを実行する方法は簡単です。 アプリケーションに次のコード行を追加して、排他的な永続サブスクリプションを実装します。
1 2 3 4 5 6 7 8 |
// Create and register subscribers for the topic // MessageReceived callback is specified // The subscription policy is Exclusive IDurableTopicSubscription subscriber = teamChat.CreateDurableSubscription("RuntimePlayerComms", SubscriptionPolicy.Exclusive, MessageReceived, TimeSpan.FromMinutes(20)); |
接続が有効である限り、新しいクライアントはそのサブスクリプションにサブスクライブできません。 この接続が切断された場合、メッセージは保持され、接続が再確立されると、メッセージはクライアントに送信されます。 これは、メッセージが失われないようにするために行われます。
NCache 詳細 Pub / Sub NCache 耐久性のあるサブスクリプション
共有永続サブスクリプション
排他的なサブスクリプションとは別に、耐久性は共有サブスクリプションによっても達成できます。 このタイプのサブスクリプションでは、複数のクライアントがXNUMXつのサブスクリプションにサブスクライブできます。 これは、負荷分散の目的を果たします。
共有サブスクリプションは、ラウンドロビン方式を使用して、接続されているすべてのクライアントにメッセージを送信します。 したがって、クライアントが切断された場合でも、メッセージは残りのサブスクライバー間で配信され続けます。
サブスクリプションに接続されているクライアントがXNUMXつでもある限り、サブスクリプションはアクティブなままです。 次のコードは、私のオンラインゲームアプリケーションが共有の永続サブスクリプションを実装する方法です。
1 2 3 4 5 6 7 8 9 |
// Create and register subscribers for the topic // MessageReceived callback is specified // The subscription policy is Shared IDurableTopicSubscription subscriber = teamChat.CreateDurableSubscription("RuntimePlayerComms", SubscriptionPolicy.Shared, MessageReceived, TimeSpan.FromMinutes(20)); |
デフォルトでは、これらのサブスクリプションは排他的であり、サブスクリプションごとにXNUMXつのサブスクライバーのみを許可します。
パターンベースのサブスクリプション
名前付きサブスクリプションをXNUMXつずつサブスクライブする代わりに、現在および今後のすべてのトピックを一度にサブスクライブするパターンが提供される場合があります。 これに対応するために、 NCache パターンベースのサブスクリプションを提供することにより、クライアントを容易にします。 この方法により、提供されたパターンに該当するXNUMXつまたは複数のトピックを簡単にサブスクライブできます。
でサポートされているワイルドカードの種類を知る NCacheの PubSub サブスクリプションについては、を参照してください。 NCache のドキュメント パターンベースのサブスクリプション.
以下は、ゲームアプリケーションでパターンベースのワイルドカードを使用する方法のスニペットの例です。
1 2 3 4 5 6 |
// Only ? * [] wildcards supported string topicName = "team*"; string subscriptionName = "TeamPlayersComms"; // Get the topic ITopic teamChat = cache.MessagingService.GetTopic(topicName, TopicSearchOptions.ByPattern); |
なぜ NCache PubSub用ですか?
なぜ賛成するのか NCache、あなたは尋ねるかもしれませんか? 上手… NCache is
- インメモリソリューションであるため高速です。
- 実行時にサーバーを追加できるため、線形にスケーラブルです。 いつでも。
- クライアントの介入なしにデータを動的に自動リバランスするため、柔軟性があります。
私の見立てでは、 NCache アプリケーション内のメッセージ通信に対応するための最良の、最もスケーラブルな、そして最速の方法を提供します。 事実 NCache はメモリ内の分散キャッシングソリューションであり、メッセージのロードによって発生する可能性のあるボトルネックに対処するのに十分です。 さて、これはあなたがあなたの.NETアプリケーションで必要とするお互いに有利な状況です。