スケーラブルな.NETPub/Subメッセージングを使用 NCache

録画されたウェビナー
RonHussainとEdwardBatorによる

このウェビナーでは、高トラフィックの .NET アプリケーションに強力な Pub/Sub メッセージングを使用し、パフォーマンスのボトルネックを克服する方法を学びます。 NCache は、.NET用のスケーラブルな分散キャッシュであり、Pub/Subメッセージング機能の豊富なセットを提供します。

弊社のシニア ソリューション アーキテクトが、すべての Pub/Sub 機能とその使用例を説明し、それらを .NET アプリケーションに組み込む方法を示します。

このウェビナーの内容は次のとおりです。

• Pub/Sub メッセージング全般の概要
• 理解する NCache Pub/Sub 機能
• での Pub/Sub のセットアップ NCache
• .NET アプリで Pub/Sub を実際に使用する
• による Pub/Sub メッセージングのデモ NCache
• NCache Pub/Sub の高可用性とスケーラビリティ

今日のトピックは .NET アプリケーション内のメッセージングに関するもので、次を使用します。 NCache 製品例として。 主な焦点となるのは、 Pub/Subメッセージング。 パブリッシャー・サブスクライバー・モデル。 なぜそれが重要なのでしょうか? 具体的にどこで使用するのか、そしてその理由は NCache .NET に表示される他のオプションと比較して、より適切です。 .NET core アプリケーション? したがって、カバーしなければならないことがたくさんあります。 早速始めましょう。質問がある場合は、エディが提案したように、質問回答タブを使用して、必要なだけ質問してください。 それでは、早速始めましょう。

Pub/Sub とは何ですか?

最初のいくつかのスライドは、イントロ部分に焦点を当てています。 Pub/Sub とは何ですか? 誰もが知っていると思いますが、完全を期すために、Pub/Sub メッセージング パラダイムについて説明します。

つまり、パブリッシャーサブスクライバーモデルです。 これには主に XNUMX つのコンポーネントがあります。 メッセージを送信するパブリッシャーがあり、それらのメッセージを通信チャネルにブロードキャストします。 次に、メッセージを受信する別のアプリケーションであるサブスクライバーがあり、パブリッシャーとサブスクライバーの中間コンポーネント内の通信、バス、ブローカー、サービス、プロセスがあり、これらのメッセージをパブリッシャーからサブスクライバーに中継するのに役立ちます。 場合によっては、メッセージを保存したり、メッセージを処理したりできます。 これは時間ベースである場合もあれば、受信者に基づいている場合もあります。

Pub/Sub はどのように機能するのでしょうか?

したがって、使用を計画するときに調整できるさまざまなオプションがあります。 ただし、一般に、典型的な Pub/Sub メッセージング プラットフォームに共通するいくつかのガイドラインやルールがいくつかあります。 疎結合です。 パブリッシャーとサブスクライバーは、相互に依存することなく独立して作業できます。 お互いをまったく意識しない場合もありますが、システムは問題なく動作するはずです。 全体的な考え方は、パブリッシャーがメッセージを通信チャネルに送信するだけで、通信チャネルがそれらのメッセージを中継し、サブスクライバーがそれらのメッセージを受信するというものです。 パブリッシャーはアイデンティティやサブスクライバー アプリケーションに関する情報を知る必要はなく、同様にサブスクライバーもパブリッシャー情報が何であるかを知る必要はありません。 メッセージを処理するだけで済みます。これが主な関心点であり、全体的な考え方は、各コンポーネントが独立して動作するということです。 パブリッシャーは通信チャネルやサブスクライバーに依存せず、またその逆も同様です。

ほとんどのパブリッシャー サブスクライバー モデル、Pub/Sub モデルでは、トピック、チャネル、ストリームを含めることができ、関心を分離することができます。 これらはメッセージを分離するために使用されます。 したがって、単純な単一の目的を果たす同様の性質のメッセージを特定のトピックに配置することができ、Pub/Sub メッセージング パラダイム内で複数のトピック、複数のストリーム、複数のチャネルを持つことができ、それらのメッセージを受信できます。 パブリッシャーがトピックに接続すると、それらのメッセージが特定のトピックに送信され、サブスクライバーも通信チャネル内のトピックに接続してそれらのメッセージを受信できます。このトピックベースのアプローチを使用すると、まったく問題なく動作します。

これは、アーキテクチャの詳細を強調した図です。

トピックがあります。これは通信チャネルであり、これはサブスクライバー アプリケーションを持つパブリッシャー アプリケーションです。 複数の発行者が存在する可能性があります。 同様に、複数のサブスクライバーが存在する可能性があり、通信チャネル内で複数のトピックを持つこともできます。 たとえば、注文処理情報を扱うトピックを 2 つ作成できます。 顧客情報などを扱う別のトピックがある可能性があります。 したがって、メッセージの目的とメッセージのタイプに基づいて、これが負荷要件になります。メッセージをトピックに分散すると、このサブスクライバーはトピック A に接続され、サブスクライバー 3 はトピック A に接続されます。したがって、パブリッシャはこれらのメッセージを送信し、それぞれのトピックに接続されているサブスクライバは、それらのメッセージを問題なく受信します。

Pub/Sub の一般的な使用例

さて、それでは次に進みます。 Pub/Sub の一般的な使用例は何ですか? この Pub/Sub メッセージング パラダイム全体はかなり前から市場に存在しており、多くの高トラフィック アプリケーションでも使用されています。 トラクションがたくさんあります。

そのため、主に、非同期データ処理を処理する Pub/Sub メッセージングの恩恵を受けるバックエンド システムがあります。 それは、ワークフロー、バックグラウンド タスク、必要な手順、実行中の計算などです。 したがって、バックエンド システムは主にこのメッセージング プラットフォームを使用します。

チャット アプリケーション。これはゲーム業界の可能性があります。ゲーム業界では、数百万のユーザー、ユーザー向けに送信される数百万のメッセージを処理している可能性があります。 たとえば、当社のお客様の XNUMX 人は、ゲーム サイトでさまざまなトーナメントが開催されているときに、情報共有に Pub/Sub を使用していました。 そのため、トーナメントに関連する多くの情報をユーザー間で共有していました。

金融業界、電子商取引、あらゆる予約、公的に公開されており、バックエンドの注文処理や予約処理を行う必要があるか、一般にアプリケーションのさまざまなコンポーネント間の相互作用を提供する必要があります。

オートメーションおよび製造プラント。 しかし、通常、それは最も重要なユースケースである可能性があり、技術的なユースケースである可能性があります。 マイクロサービス 使用事例。 ここでは、大きなアプリケーションを表すさまざまなマイクロサービスが存在しますが、これらのコンポーネントは単一の独立した目的を果たします。 これらのマイクロサービスの通信層を実装するのは非常に困難です。 再びマイクロサービスとして機能する別の通信チャネルが必要になります。この通信チャネルは、他のマイクロサービスに対しても同様の機能を持ちません。これが、独立したマイクロサービス層を持ちたい場合の全体的なアイデアであり、マイクロサービス インスタンスは互いに独立しています。 XNUMX つのインスタンスは単一の目的を実行し、別のインスタンスに依存しません。また、その逆も同様です。 したがって、アプリケーション内にマイクロサービスがあるマイクロサービス アプリケーションの場合、通信チャネルの実装は非常に難しく、複雑になり、多くの依存関係があるため、速度も低下します。 したがって、通信チャネルがプラットフォーム自体によって管理され、マイクロサービスがパブリッシャーおよびサブスクライバーとして機能し、相互に情報を共有する Pub/Sub メッセージング プラットフォームを使用することは非常に理にかなっています。 したがって、これにより、独自の通信チャネルを使用するマイクロサービス プラットフォーム アプリケーションである Pub/Sub でよく見られる負荷とアーキテクチャの問題が軽減されるはずです。 この問題を軽減するには、Pub/Sub を使用する必要があります。

問題: Pub/Sub プラットフォームのスケーラビリティの問題

Pub/Sub プラットフォームは数多くありますが、通常はボトルネックが存在するため、それについて次に説明します。 当社には典型的な従来型のメッセージング プラットフォームがあります。 建築的な面では非常に優れています。 メッセージを送信すると、そのメッセージはすべての購読者に送信され、すべてが正常に動作します。 ただし、通常、これは負荷が低い場合には非常にうまく機能します。 ユーザーが少なくなると、負荷が減り、リクエストの数やアプリケーションに送受信されるメッセージの数も減ります。 負荷に関して言えば、たとえば、アプリケーションの負荷が増大すると、ユーザー数が多くなり、多くの処理が発生し、パブリッシャーからサブスクライバーへのメッセージングの負荷も多くなります。通常、従来のメッセージングではデータベースなどのプラットフォームでは、それらがボトルネックになります。 これを説明する図を次に示します。

パブリッシャーアプリケーションとサブスクライバーがあります。 これは、Web アプリケーション、一部の .NET、または .NET Core バックエンド。 いくつかのワークフロー。 あらゆる種類の .NET または .NET Core データベースやメッセージング キューなどの従来の一括プラットフォームに接続されたアプリケーション、さらには Java アプリケーション。 まず第一に、これらはメモリ内ストアほど高速ではありません。 したがって、それはあなたが解決する必要があるものです。 しかし、主な問題は、メッセージングの負荷が増大し、多数のユーザーがいると、メッセージングの負荷がプラットフォーム自体を停止させる可能性があるため、処理が遅くなり始めることです。これは、プラットフォーム自体が単一のソースであるためです。 アプリケーションによる負荷の増加に対応するためにサーバーをさらに追加する機能はありません。

それが主な問題であり、エンドユーザーへの影響は何でしょうか? たとえば、メッセージがタイムリーに中継されず、時間がかかり、それがアプリケーション側の遅延の原因となっていました。 たとえば、エンド ユーザーは処理が完了するのを待っていましたが、その処理は Pub/Sub モデル プラットフォームに依存しており、プラットフォームが遅かったとします。 したがって、これはエンド ユーザーのリクエストにも影響を及ぼし、たとえばミリ秒または数秒の遅延が発生した場合、ビジネスを失うことになります。それはエンド ユーザーに影響を与える可能性があり、ひいてはビジネスにも影響を与えることになります。これは管理が非常に困難です。アプリケーション アーキテクチャ内の何かを変更して問題を解決することは不可能だからです。 データベース層を含むアプリケーション アーキテクチャの外側に問題があります。 では、その特定のシナリオにどのように対処すればよいのでしょうか?

解決策：インメモリ分散キャッシュ

解決策は非常に簡単で、自然に分散されているメモリ内 Pub/Sub メッセージング プラットフォームを使用します。 NCache。 超高速であることが、従来のメッセージング プラットフォームとは一線を画しています。 機能が少ないかもしれない、それは認めます。 以来、 NCacheの主な焦点は、オブジェクト キャッシュ、データ キャッシュ、セッション キャッシュを備え、データとストレージの処理とパフォーマンスの向上にあります。 Pub/Sub は機能の XNUMX つです。 Java メッセージング サービス、MSM キューなど、より複雑なメッセージング キューなどの製品があります。 しかし、何がそうさせるのか NCache これらの製品とは別に、 NCache インメモリです。 そのため、起動が超高速です。

したがって、たとえばユーザーが XNUMX 人いて、メッセージング負荷の数が少ない場合、それらのユーザーは従来のメッセージング プラットフォームと比較して超高速なエクスペリエンスを体験することになります。 つまり、メモリ内にあります。 したがって、これは大きな利点であり、そのメッセージング プラットフォームをホストする複数のサーバーがあります。 チーム サーバーが論理容量に結合されてメッシング プラットフォームを形成し、その上に Pub/Sub メカニズムが実装されていることがわかります。 したがって、パブリッシャー アプリケーションはこのキャッシュに接続でき、キャッシュ内に個別のトピックを含めることができます。 これがどのように機能するか、最終的にはサブスクライバーについて説明します。サブスクライバーはパブリッシャーにもなり得ます。サブスクライバーは、によって提供される同じ通信チャネルにも接続されます。 NCache 分散キャッシュの形式で、その通信チャネルがすべての通信関連情報をパブリッシャーとサブスクライバーに提供します。 これにはメッセージを中継することができ、さまざまな種類の探索、さまざまな種類の永続性、および後で強調するさまざまな機能が含まれる可能性があります。

このプラットフォームの良い点は、必要なだけサーバーを追加でき、ここで見られるようにプラットフォームがスケーラビリティのボトルネックになることを心配する必要がないことです。 したがって、これはスケーラビリティのボトルネックではなくなりました。 サーバーをその場で追加することができ、XNUMX 台から XNUMX 台のサーバーにすると XNUMX 倍に増加し、XNUMX 台​​から XNUMX 台にすると、処理できるリクエストの数と、XNUMX 秒あたりに処理できるメッセージの数の容量がほぼ XNUMX 倍になります。パフォーマンスは犠牲になりますが、メッセージ配信の線形スケーラビリティが向上し、アプリケーション側で非常に役立ちます。 エンドユーザーにとっては、アプリケーションとユーザーの応答時間の短縮、待ち時間の短縮、およびスループットの高さが大きなメリットとなります。

ここまでで何か質問はありますか？ これは、使用を検討する必要がある理由について説明します。 NCache 従来との比較、および従来の Pub/Sub メッセージング プラットフォームの問題点は何ですか。 ここまでで何か質問はありますか？ 次のいくつかのスライドでは、アーキテクチャの詳細に焦点を当てます。 NCache Pub/Sub メッセージングについて説明し、その後、その一部として提供されるさまざまな機能について説明します。 こんにちはロン、質問があります。 利用可能な監視オプションは何ですか? わかりました、それは次のことに関するものだと思います NCacheはい、これはもう一つのプラスで、このために最後にセグメントが並んでいます。 しかし、その部分まで待って、製品の実践的なデモを提供し、その一環としてモニタリング機能もお見せできれば非常に良いと思います。 したがって、その部分に到達したら、この質問を再検討します。 大丈夫だといいのですが。

NCache Pub / Subメッセージング

さて、 NCache Pub/Sub メッセージング。 ここで見たものとよく似ています。 これは、従来の Pub/Sub メッセージング プラットフォームです。 ここではアーキテクチャの内訳を示します。 が提供するメッセージングチャネルがあります NCache ここにはサーバーのチームがあり、そのメッセージング チャネル内にはトピック 1、トピック 2、そして任意の .NET であるパブリッシャーがあります。 .NET Core アプリケーションと、やはり任意の .NET または .NET Core、それに接続されている Java アプリケーションも同様です。

このために専用のキャッシュを作成でき、メッセージは通常の Pub/Sub メカニズムを使用して通信チャネルから中継され、メッセージはパブリッシャーからサブスクライバーに送信されます。 これは簡単なコードスニペットです。

Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
...
                
Cache cache = NCache.InitializeCache("PubSubCache");

ITopic orderTopic = cache.MessagingService.CreateTopic("orderTopic");

Message orderMessage = new Message(payload);

// Publish message to all registered subscribers
// Register delivery failure notification

orderTopic.Publish(orderMessage, DeliveryOption.All, true);

目的のオブジェクトであるペイロードを構築し、キャッシュを初期化するということを理解していただくために、それに接続し、名前を付けると、次のようになります。 キャッシュクラスターを作成する 異なるサーバーを使用する場合は、トピックを作成するか、既存のトピックに接続します。 トピックはチャネルであり、同様のメッセージ用の別個のメディアであり、メッセージを作成して公開すればそれで終わりです。 基本的な使用例としては非常に簡単です。

サブスクライバー側では、やはりトピックに接続するか、新しいトピックを作成してから、create subscription メソッドを使用してサブスクライバーになる必要があります。その後、メッセージが受信されるたびに呼び出されるコールバックがあり、これは非同期呼び出しです。 -戻る。

Cache cache = NCache.InitializeCache("PubSubCache");

ITopic productTopic = cache.MessagingService.GetTopic(topicName);

ITopicSubscription prodSubscriber = prodTopic.CreateSubscription(MessageReceived);

private void MessageReceived(object sender, MessageEventArgs args)
{
 // Perform operations
}

実践的なデモ

すぐに製品のデモをお届けする必要があります。デモを行った後は、はるかに理解しやすいと思います。 この一環として、監視オプションについてもお答えします。 わかりました。それでは、すぐに先に進んで、 NCache マネージャー ツールがインストールされます。

キャッシュを作成する

新しいキャッシュを作成してみます。

PubSubCache という名前を付け、最後に Windows Win を追加します。 すべてのキャッシュに名前を付ける必要があります。 Pub/Sub キャッシュには、アプリケーションにとって意味のある名前を付けることができます。 キャッシュを作成できますが、 NCache Windows 環境、Windows サーバー、および Linux サーバー上にキャッシュを作成できます。また、Windows モノラル リリースも用意されており、これも利用できます。 したがって、Linux では次のようにする必要があります。 .NET Core Windows では、.NET と同様に使用できます。 .NET Core のリリース NCache。 そこで、Windows サーバーを使用することにします。 複数のサーバーをリクエスト処理能力に貢献させたいため、パーティション レプリカ キャッシュを選択します。

したがって、パーティション分割およびパーティション分割レプリカは非常に優れたオプションです。 パーティション キャッシュを使用すると、複数のサーバー上でデータをパーティション分割できます。一方、パーティション レプリカはパーティションに似ていますが、バックアップも備えています。 したがって、それは完全にあなた次第です。 メッセージを本質的に重要なものにしたい場合、XNUMX つのサーバーがダウンした場合、通信チャネルにまだあるメッセージを失いたくない場合は、パーティション化されたレプリカを使用できます。それ以外の場合は、パーティション化されたキャッシュのパフォーマンスがより特殊です。 。

他に XNUMX つのトポロジがありますが、それらは小規模な構成用であり、 NCache 建築ウェビナー これらのトポロジに関するすべての詳細を非常に効果的にカバーしています。 したがって、これらのトポロジについてさらに詳しく知る必要がある場合は、これらの Web セミナーにアクセスし、ウェビナーを確認することをお勧めします。 すべてをシンプルにしていきます。 レプリケーション オプションとして [非同期] を選択します。

これは、アクティブなパーティションと別のサーバー上のバックアップの間にあり、ここでキャッシュ クラスターをホストするサーバーのチームを指定します。 最初は XNUMX 台から始めることができますが、前述したように、いつでもサーバーを追加できます。 ちなみにこれはTCPポートです。 間のあらゆるコミュニケーション NCache は TCP/IP を通じて駆動され、サイズはサーバーごとのサイズです。 したがって、メッセージングの負荷とデータの負荷に基づいて、アプリケーションに適切なサイズを構成することをお勧めします。 すべてをシンプルにしておきます。 このキャッシュを自動起動で開始すると、サーバーが再起動されるたびにキャッシュが自動的に開始され、それだけで済みます。

このキャッシュの構成は非常に簡単です。次に、アプリケーションを実行する方法を説明しますが、それに進む前にもう XNUMX つの手順が必要です。 それも始まって​​いるので、少し時間がかかりますが、それでは、どうぞ。

統計を監視する

それで、監視オプションに関する質問がありましたが、今すぐそれに取り組むべきだと思います。 自分のボックスをクライアントとして追加し、そこからパブリッシャーおよびサブスクライバー アプリケーションを実行します。 これらは、このキャッシュにアクセスできる任意のサーバーから実行することもできます。 私のボックスをクライアントとして追加したので、それは本質的にクライアントボックスです。 別のボックスを追加し、そこからアプリケーションを実行することもできます。 マネージャー ツールで使用できる統計ウィンドウ オプションがいくつかあることに気づきましたが、Pub/Sub の場合は最初に行うこととして、 NCache モニター ツールを使用してから、特に Pub/Sub に使用できるカウンターのいくつかも紹介します。

たとえば、これは私の Pub/Sub ダッシュです。 先に進みます、これは NCache インストールに付属するモニターツール NCache。 必要だと思います、1×3が良いです。 さて、まず第一に、トピックの統計があることに気づいたでしょう。 次に、XNUMX 秒あたりに公開されるメッセージ (メッセージ数) を取得し、XNUMX 秒あたりのメッセージの有効期限を取得します。 それは良いことだと思います。 ちなみにさらに追加することもできます。 ここには多数のカウンターがあり、さらに PerfMon カウンターも利用可能です。 これらも有効にしてから、アプリケーションを実行してこれがどのように機能するかを示します。 カウンタを示すだけです。監視ツールも PerfMon カウンタを使用しています。 つまり、ここで見ているものはモニターでも利用でき、その逆も同様です。 さて、準備は完了です。 ということで、ここにもカウンターがいくつかあります。 たとえば、メッセージ数、XNUMX 秒あたりの配信期限切れなどです。 したがって、数値ビュー、数値ビューが表示され、さらにグラフィック ビューもモニターに表示されます。

パブリッシャーを運営する

ここで、インストールに付属しているアプリケーションを実行しますが、必要なだけメッセージを公開できるように、少し調整しました。 つまり、これはパブリッシャー用のアプリ構成であり、次にコンシューマーであるサブスクライブ用のアプリ構成です。 さて、それではこのアプリケーションを実行します。 まず、発行者アプリケーションを起動し、これがどのように機能するかを示します。 これを見直してみましょう。保存していないかもしれません。 わかりました、ループを付ける必要があるので少しお待ちください。 実はループがあるんです。 よし、デバッグしてみよう。 したがって、このキャッシュに接続するための情報がありません。 それで、これを理解しましょう。 箱も追加しましたので、ご容赦ください。 この問題をすぐに解決させてください。数分かかります。 追記しましたが、もしかしたらタイプミスがあったかもしれません。 さあ、どうぞ。 間違ったキャッシュ名を指定していました、悪かったです。 ここで名前を確認してみましょう。 パブサブキャッシュウィンです。

昨日のキャッシュ名を使用していましたが、これはデモキャッシュでした。 それは起こります。 わかりました、すぐに修正できてよかったです、そうでなかったら大惨事になっていたでしょう。 それで、私たちは大丈夫だと思います。 したがって、これはプログラム (publisher.exe) を起動し、XNUMX 個のメッセージを公開します。 同じメッセージを何度も投稿しています。 この時点ではパブリッシャーは開始されていますが、サブスクライバーはまだ開始されていません。 それでは、モニタリングの詳細を説明します。

もちろん、これに関連していくつかのリクエストが来ています。 でも気づいたら、私の話題がありました、それは10という名前です。

アイテムがそこにあり、有効期限が経過すると、メッセージが期限切れになっていることがわかります。有効期限を 10 分以上設定していると思います。 これからさらにいくつか公開していきたいと思います。 ここに追加のアイテムが 20 個あるはずです。 つまり、合計 XNUMX アイテムとなり、メッセージ数が増加していることがわかります。

これがグラフであり、Windows パフォーマンス モニターでも同じオプションが表示されます。サイズとメッセージ数は 20 から 12 になっています。 主に、有効期限が切れているものがあるためです。 すでにその一環として有効期限を減らしていると思います。 メッセージ数が正しく表示されていないと思います。モニターによると、これは 20 であるはずです。

サブスクライバーの実行

購読者の協力を得てこれを確認してみましょう。 受信するメッセージの数を見てみましょう。ちなみに、デモが完了したらコードを紹介します。

したがって、既存のメッセージを取得することになっていますが、すべてのメッセージをランダムな方法で取得していると思います。 これはメッセージの非同期呼び出しです。 メッセージがその順序で配信されることは保証されません。 したがって、後の段階で最初のメッセージを受信することができます。

ここに戻ってくると、メッセージ数がゼロになります。 このカウンター、もう一度見直してみましょう。 これが特定のトピックのメッセージを表しているのか、それとも公開されているメッセージ全体を表しているのかはわかりません。 さて、これで表示されるはずの正しい値が表示されていません。 それらのメッセージは受け取られたと思います。 したがって、これを達成するにはサブスクライバーを閉じる必要があります。 別のサブスクライバーを実行するつもりです。 メッセージが複数のメッセージに配信されていることがわかりましたので、最後にコード例を示します。 さらにいくつかのメッセージを入力し、それを続けると、サブスクライバー側で、このメッセージが 10 件のメッセージを受信し、さらにこのメッセージがさらにいくつか受信したことがわかります。 配信オプションが XNUMX つある場合は、これらすべての購読者にメッセージをブロードキャストするか、任意の購読者にメッセージをブロードキャストするかを選択できます。 そうですね、どちらが受信したかに基づいて、メッセージもキャッシュから期限切れになります。 以上、簡単なデモでした。 ここで、メッセージを公開するために何が必要かについて詳しく説明します。 トピック側の特徴は何ですか？ パブリッシャー側の機能とサブスクライバー側の機能は何ですか? この時点でご質問がございましたら、お知らせください。 これらの質問に今すぐお答えしたいと思います。そうでない場合は、先に進んで、物事の詳細なアーキテクチャ面を説明します。

の主要な Pub/Sub インターフェイス NCache

これらは、内部の主要なインターフェイスです NCache.

ご用件

話題があります。 繰り返しますが、これはコミュニケーションのためのチャネルです。 これにはサブスクライバーのリストが含まれており、パブリッシュされたメッセージを接続されているサブスクライバーに中継します。

メッセージ

次に、メインのペイロードであるメッセージがあります。 関心のある地点、購読者にとっての関心のあるオブジェクト。 シリアル化可能なペイロードです。 それはあらゆるオブジェクト、配信したいメッセージ、正確にはあらゆるデータである可能性があります。

Publisher

パブリッシャーはメッセージをパブリッシュするアプリケーションであり、オプションの配信ステータス通知も受け取ることができます。 配信ステータスはオンにすることを選択できますが、これは以前に決定されたか、前述したように、パブリッシャーはメッセージが配信されるのを待つ必要はありません。 それは先に進むことができます。 したがって、オプションの配信ステータスは、必要に応じてオンにすることも、オフにすることもできます。

加入者

購読者は、特定のトピックに自分自身を登録し、すべてのメッセージを取得します。

それでは、これらを XNUMX つずつ確認して、今説明したすべての内容を図に示します。

パブリッシャーはメッセージの作成、イベントの登録、メッセージの送信、メッセージのトピックと保存、サブスクライバーの保存とメッセージの送信を行います。 購読者は購読すると、メッセージ通知を受け取ります。

NCache Pub/Sub トピック インターフェイス

それでは、トピックのインターフェイスを確認してみましょう。 したがって、まず最初に、 NCache Pub/Sub トピックを作成すると、既存のトピックに接続したり、トピックを削除したりすることもできます。 それでは、このインターフェースに何が関係しているのか見てみましょう。 したがって、ここでこの発行者にアクセスする場合は、まずプログラムに移動する必要があります。このプログラム内でキャッシュ名を取得していることに気づくでしょう。 トピック名を取得しています。トピック名は任意のトピックで、ランダムなメッセージであるメッセージ カウンターを取得しています。次に、publisher.start メソッドを実装しています。その中には、キャッシュを初期化しています。つまり、キャッシュに接続し、トピック作成インターフェイスを取得します。ここに戻ってくると、IMessagingService が表示されます。 それでは、ここで簡単にお見せしましょう。

IMessagingService Interface for managing Topics in NCache

namespace Alachisoft.NCache.Web.Caching
{
    public interface IMessagingService
    {
        ITopic CreateTopic(string topicName);
        void DeleteTopic(string topicName);
        ITopic GetTopic(string topicName);
    }
}

IMessagingService インターフェイスには、CreateTopic メソッド、トピックを削除する DeleteTopic メソッド、そして GetTopic があります。 これらを一つずつ確認していきましょう。 したがって、メッセージング サービスではトピックを作成するか、既存のトピックに接続するだけです。 実際に行うことは、必要に応じて、メッセージ配信や配信失敗通知を有効にすることもできます。 たとえば、ここでコールバックを設定すると、そのコールバックを呼び出すことができますが、これはオプションです。 有効にしたくない場合は、これは必ずしも必要ありません。 したがって、前に述べたように、メッセージ配信通知はオプションであるため、必須として有効にする必要はありません。 それは完全にユースケース次第ですが、これらを有効にしたい場合は、そのまま実行してください。

次に、このアプリケーションのカスタム メソッドであるパブリッシュ メソッド、このラッパーがあり、その中で実際に行っていることは、メッセージを構築し、次に topic.publish メッセージを使用することです。 したがって、これはメッセージ、つまりトピックを返します。 ここで簡単に説明すると、そのトピックへのハンドルのようなもので、次に topic.publish が実際のメソッドです。 これは ITopic インターフェイスであり、名前があり、メッセージ数、有効期限を設定できます。これについては後ほど説明します。また、トピックの削除、メッセージ配信の失敗、およびトピックに関するコールバックもいくつかあります。次に、トピックのサブスクリプションを取得し、そのトピックにメッセージをパブリッシュすることもできます。これが私が紹介したかった最初の方法です。topic.publish を使用して、配信オプションがあることに気付いた場合は、良い。 必須として全員に配信することも、いずれかに配信することもできます。 これはメッセージ レベルであり、そのトピックに配信または送信されるメッセージの配信オプションです。そしてここにオプションの最後のブール値があります。これを確認してみましょう。これが何を示唆しているのでしょうか? これについては、失敗通知を受け取るかどうかを指定します。 したがって、この場合はこれを true に設定していますが、オフにすることもでき、オフにした場合は、それに応じてパブリッシャー側でコールバックが呼び出されます。

ここでは XNUMX つの方法を見てきました。 トピックを作成すると、同様にトピックを取得することもできます。 したがって、これは代わりに使用できる別の方法です。 ただし、これを初めて実行するので、トピックの作成を使用し、トピックにメッセージを公開し、必要に応じてトピックを削除することもできます。 これらはシナリオの一部であり、ご覧のとおり、これらのスライドでは同じ例を並べて示しています。

Create Topic: Code snippet to create a new topic in distributed cache

string cacheName = "pubSubCache";
string topicName = "orderTopic";

Cache cache = NCache.InitializeCache(cacheName);

cache.MessagingService.CreateTopic(topicName);

したがって、トピックを削除すると、トピック削除コールバックが呼び出され、トピック削除コールバックからエンドユーザーや公開する必要のある情報を通知できます。

Delete Topic: Deletes an existing Topic distributed

string cacheName = "pubSubCache";
string topicName = "orderTopic";

Cache cache = NCache.InitializeCache(cacheName);

cache.MessagingService.DeleteTopic(topicName);

OnTopicDeleted callback: If registered, it will be triggered upon the Delete Topic call.

using (Subscriber subscriber = new Subscriber())
{
// Subscribes on it, using the provided cache-Id and the topic-name.

subscriber.OnTopicDeleted = TopicDeletedCallback;
}

static void TopicDeletedCallback(object sender, TopicDeleteEventArgs args)
{
 Console.WriteLine("Topic '{0}' deleted.", args.TopicName);
}

NCache パブリッシュ/サブスクライブ メッセージ インターフェイス

メッセージング インターフェイスを見てみましょう。ここでは、メッセージ無効化オプション、メッセージ受信通知、失敗または受信、失敗通知があり、その一部として暗号化と圧縮がサポートされていることについて説明します。 そこで、IMessage インターフェイスを見てみましょう。 そこで、ここにメッセージがあります。

namespace Alachisoft.NCache.Runtime.Caching
{
    public class Message : IMessage
    {
        public Message(object payload, TimeSpan? timeSpan = null);

        public static TimeSpan NoExpiration { get; }
        public string MessageId { get; }
        public TimeSpan? ExpirationTime { get; set; }
        public object Payload { get; }
        public DateTime CreationTime { get; }
    }
}

その一環として何が利用できるのか見てみましょう。 まず第一に、TimeSpan があります。NoExpiration を選択することも、ここで TimeSpan ExpirationTime をメッセージ オプションとして指定することもできます。ここに戻ってきたら、時間ベースの有効期限を設定していることに気付いた場合は、それについても、これがここで伝えられており、期限があることに気づいた場合は。 したがって、これはプログラム自体によって呼び出されます。 それで、私たちは与えます 「TimeSpan.FromMinutes(5)」。 したがって、これは基本的に、配信されなかったトピックは、サブスクライバーが存在しない場合、またはサブスクライバーが切断された場合、そのメッセージは指定された期間通信チャネルに留まるということを意味します。 これは一種の永続化ですが、メッセージを無期限に永続化するのは Pub/Sub プラットフォームに反するため、一定時間メッセージを永続化し、その後ストア自体を消去するタイムベースが適切なオプションです。 これらのメッセージは通信チャネルからも個別に期限切れになることはなく、この期限切れはトピック レベル自体で発生する可能性があります。 トピック自体に有効期限を設定したり、メッセージに個別の有効期限を付加したりすることもできます。 つまり、これはあなたが行うことであり、ところで、パブリッシャーとサブスクライバーが接続されている場合、パブリッシャーはメッセージをパブリッシュし、それらはすぐに中継されます。 有効期限が切れるのを待ちません。 メッセージが配信された場合、それは保持されません。 したがって、メッセージが配信されると、メッセージはすぐにキャッシュから削除されます。 つまり、有効期限を設定する方法です。

次に、メッセージに関する受信通知も表示されます。 これらは以前にお見せしたものです。 たとえば、配送状況を確認できます。 「パブリッシャー.メッセージ配信失敗」 通知を受け取ると、メッセージや成功ステータスをメッセージから生成することもできます。 したがって、これはこの一部としてオンにできる別のオプションであり、メッセージの暗号化と圧縮も実行でき、これはコード変更のないオプションです。 すべてはキャッシュによって行われるため、必要なのはキャッシュ自体にアクセスしてオプションに移動することだけです。 NCache 自体。 したがって、圧縮を有効にし、右クリックしてホット適用構成を選択できます。

圧縮は、サイズが大きいオブジェクトに対して行われます。 メッセージのペイロードのサイズが大きいため、圧縮を自動的にオンにする必要があり、暗号化もここでの別のオプションです。 暗号化を有効にする必要があり、そのためにはまず通信チャネルを停止し、キャッシュを停止してから暗号化を有効にする必要があります。 選択できるプロバイダーは多数あり、すべてのメッセージは暗号化されてから発行者と購読者に送り返されます。 それが簡単だったことを願っています。 メッセージの例はここにあります。

//Payload containing OrderId to be sent in message

Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
payload.ShipAddress = "59 rue de l'Abbaye";
payload.ShipCity = "Reims";
payload.ShipCountry = "France";

//Create message with payload and expiration time set to 150 seconds

Message message = new Message(payload);
message.ExpirationTime = new TimeSpan(0, 0, 150);

order を使用し、メッセージを作成し、有効期限を設定してから、 「トピック.パブリッシュ」 そしてそのメッセージを適切なトピックに提供します。

メッセージ受信通知

ということで、メッセージ受信通知。 加入者側でもそれを示したいと思います。

Callback invoked when a message is published on the topic

string cacheName = "pubSubCache";
string topicName = "orderTopic";

Cache cache = NCache.InitializeCache(cacheName);

//Get Order topic
ITopic orderTopic = cache.MessagingService.GetTopic(topicName);

//Register subscribers for Order topic

ITopicSubscription ordSubscriber = orderTopic.CreateSubscription(messageReceivedCallback);

private void messageReceivedCallback(object sender, MessageEventArgs args)
{
              //perform operations
if (args.Message.Payload is Order ord)
   {
              //perform operations
   }

サブスクライバーの観点からは、キャッシュに接続して開始するだけで済みます。 を使用してトピックに接続します 「_cache.MessagingService.GetTopic」。 これは、先ほど紹介した方法です。または、トピックが存在する場合はそれを作成し、コールバックでメッセージを受信できるサブスクリプションを作成します。これがメッセージ受信コールバックです。 それはプログラムのここにあるべきだと思います。 メッセージ受信コールバック。 したがって、これはメッセージを受信するたびに呼び出されます。 これで、ここでの例は完了です。

ステップバイステップ: メッセージをトピックに公開する

ということで、もう一度一歩ずつ。 Pub/Sub キャッシュ クラスターを初期化し、専用のトピックを作成するか、既存のトピックに接続します。 必要に応じてメッセージ配信イベントを登録します。これはオプションです。 メッセージを作成し、別のトピックに公開します。 有効期限を有効にし、必要に応じて配信オプションを有効にします。これは、それを正当化するのに役立つコードです。

public void PublishMessages()
{
string cacheName = "pubSubCache";
string topicName = "orderTopic";
Cache cache = NCache.InitializeCache(cacheName);
ITopic orderTopic = cache.MessagingService.CreateTopic(topicName);

//Register message failure notification
orderTopic.MessageDeliveryFailure += FailureMessageReceived;

//Register topic deletion notification
orderTopic.OnTopicDeleted = TopicDeleted;

//Payload to be sent in message
Order payload = new Order();
payload.OrderID = 10248;
payload.OrderDate = new DateTime(2015, 07, 04);
payload.ShipName = "Vins et alcools Chevalier";
payload.ShipAddress = "59 rue de l'Abbaye";
payload.ShipCity = "Reims";
payload.ShipCountry = "France";

//Create message with Order and expiration time set to 150 seconds
Message orderMessage = new Message(orderPayload);
orderMessage.ExpirationTime = new TimeSpan(0, 0, 150);

//Publish message to all registered subscribers
//and register message delivery failure notification
orderTopic.Publish(orderMessage, DeliveryOption.All, true);

そして、サブスクライバー側でキャッシュに接続し、既存のトピックを取得するか、新しいトピックを作成します。 メッセージ受信用のトピックのサブスクリプションを作成します。 非同期イベントとなる受信用のイベントを登録し、トピックからサブスクライブを解除し、必要に応じて削除し、イベントをトピックの一部にすることができます。

NCache Pub/Sub のモニタリング

次のいくつかのスライドでは、監視の側面に焦点を当てます。 これらを全体的に見直してみましょう。 PerfMon カウンターのサポート内の基本的な詳細についてはすでに説明しました。 NCache, ダッシュボード内にはさまざまなオプションがあります。 別のダッシュボードを作成しましょう。

これらをすべて追加してみましょう。 したがって、いくつかのトピック統計もあります。 たとえば、すでに示したトピック統計があります。 トピック数、所有するトピックの数。 メッセージ数。 メッセージ ストア サイズ。トピックの合計サイズとバイト数であり、これは能力構築にとって非常に重要です。 配信または公開されているメッセージの数を把握したい場合は、XNUMX 秒あたりに公開されたメッセージと XNUMX 秒あたりに配信されたメッセージをドラッグ アンド ドロップすると、メッセージの有効期限ステータスとその一部を取得できます。 さて、これらはカウンターの一部です。 サンプル アプリケーションをもう一度実行すると、これらすべてのアクティビティが表示されるでしょう。 Enter キーを複数回押して負荷を加え続けます。ここに戻ってくると、すべてのアクティビティが表示されます。

メッセージは 220 件あります。 この時点でのトピック数は 1 です。 メッセージ数は約 220 です。メッセージ ストアのサイズも表示されます。 メッセージが公開されています。 しかし、配信されたメッセージはなく、期限切れのメッセージもありません。サブスクライバーを実行するだけで、処理は非常に速くなり、それらのメッセージも同様に受信されることがわかります。 ほら、私がここに戻ってきたら、ここでもアクティビティが見られるはずです。 メッセージも受け付けております。

これでプロセスが完了しました。これらのカウンターをログに記録して、容量を確認したり、そこに存在する全体的なトピック、そこにあるメッセージ、ストアのサイズ、それらのメッセージの有効期限も確認したりできます。また、それに基づいて必要なだけトピックを作成できます。私の要件に基づいて。 同じカウンターは Windows PerfMon でも利用できます。 したがって、ここには同じセットがあり、さらにいくつかの PowerShell コマンドレットもあります。 たとえば、ここのドキュメントにアクセスしたら、すぐに開いてみましょう。 したがって、PerfMon カウンター、 NCache モニターおよび PowerShell コマンドレット。 場合によっては、ツールに頼りたい場合もあります。 そのため、その目的のために、ドキュメントと PowerShell ガイド内を使用できます。すぐに検索できるかどうか見てみましょう。 一般的なリンクが示されているので、ここでいくつかの監視オプションを見てみましょう。 「Get-Topics」は、キャッシュ名に基づいてトピック名を取得できる PowerShell コマンドレットです。 たとえば、ここで PowerShell を開いたとします。 このコマンドを使用できます。こちら側で開いてみましょう。これで明らかです。 わかりました。たとえば、ここで任意のボックスから実行できます。その場合、pubSubCachewin がキャッシュの名前になります。 それは私に何も与えません。 pubSubCachewin ではないと思うので、サーバー自体で実行する必要があります。 私のトピックは、サブスクライバー、パブリッシャー、メッセージ数です。

私のボックスから作業を開始する理由は、キャッシュが存在する場所を知るために IP アドレスが必要だからです。 そのため、PowerShell 側には、必要に応じて統計を表示できるツールがいくつかあります。 これでデモ部分は完了です。 ご質問がございましたら、お知らせください。 アーキテクチャに関する詳細や、このコミュニケーション チャネルの一部として提供されるものについては、最後の方で少し時間をかけて説明するつもりです。 NCache メッセージングプラットフォームとしての役割とその理由 NCache よりフィットしますか？

分散キャッシュアーキテクチャ

まず第一に、 NCache オープンソースです。 したがって、オープンソース バージョンでも Pub/Sub を開始でき、Pub/Sub を利用できます NCache。 線形にスケーラブルであることが第一のポイントであり、それ以前にインメモリであるという点が、パフォーマンスのみを求め、最初から高負荷要件を求めていないアプリケーションにとって重要な点です。 したがって、パフォーマンスに問題がある場合は、 NCache これも、従来の Pub/Sub メッセージング プラットフォームと比較してより適切です。

これは直線的に拡張可能であり、本質的には、必要な数のサーバーを追加できることを意味します。 サーバーは XNUMX 台あれば十分です。 しかし、容量に達した場合、容量は次のような影響を受ける可能性があるため、 NCache サーバーも同様です。 データベースで最初に発生した問題。 私たちはそんなことを言っているのではありません NCache この問題は見られないでしょう。 XNUMX 台のサーバーでは容量に達する可能性があり、さらに多くのサーバーを使用することもできますが、サーバーを増やすことで容量が追加される可能性もあります。 たとえば、これら XNUMX つのサーバーが最大値に達しており、アプリケーションの負荷要件や負荷が高いことが前もってわかっているので、それが適切なタイミングです。 したがって、サーバーを追加して、より適切な容量計画を立てることで、この問題を回避できます。 そのため、さらに多くのサーバーをその場で追加でき、直線的に拡張できる点が利点です。

XNUMX 番目の重要な特徴は、必要に応じてレプリケーションのサポートも可能であり、これにより信頼性が確保されることです。 すでに可用性が高く、サーバーがダウンしてもエンド クライアントに影響はなく、パブリッシャーやサブスクライバーのプラットフォームは問題なく機能します。 キャッシュ クラスター内に XNUMX つのノードが残っている限り、Pub/Sub プラットフォームは稼働し続けます。なぜこれができるのでしょうか? 本質的に動的であるため、可用性が高くなります。

これは、100% ピアツーピア アーキテクチャのキャッシュ クラスターです。 これにより、必要なだけサーバーを追加でき、それらのサーバーは本質的に独立しています。 これらは負荷を分散することでリクエスト処理能力に貢献しますが、100% 独立した能力で機能します。 サーバーがダウンしても、新しいサーバーが追加されても、キャッシュには影響しません。 そのためにプラットフォームを停止する必要はありません。 動作を継続できるため、クライアントを停止または再起動する必要はありません。 これが従来のソースの問題であり、サーバーがダウンした場合、残っているノードの使用を開始するためにクライアントを再起動する必要がある場合があります。 したがって、これは本質的に動的であり、クライアントは自動的に調整し、クラスター自体は自己修復メカニズムにより 100% の稼働率になります。 サーバーが追加されると、クラスターは新しく追加されたサーバーに負荷を分散し、同時にクライアントに通知することでそれに合わせて調整します。

同様に、メンテナンスの場合やサーバーがダウンする場合、サーバーがダウンするか障害が発生しても、キャッシュ クラスターは稼働したままになります。 これが機能し、実行時にクライアントに通知されるようにするには、100 つの生き残ったノードが必要です。 接続フェイルオーバーのサポートは、クライアント側のプロトコルに組み込まれています。 そのため、クライアントは障害を検出するとフェイルオーバーし、自動的にサバイバル ノードの使用を開始します。これにより、キャッシュ側とそれに接続されているエンド クライアントの稼働率が 100% 保証されます。 つまり、本質的にはダイナミックなのです。 100% ピアツーピア アーキテクチャです。 接続フェイルオーバーのサポートが組み込まれており、クラスターは内部で自己修復します。 これはプロトコルに組み込まれたメカニズムです。 これにより、XNUMX% の稼働率、つまり可用性の高いキャッシュ シナリオが保証されます。

キャッシュ トポロジ: パーティション化されたキャッシュ

通信チャネルのトポロジ。

Pub/Sub プラットフォームではデータをパーティショニングできます。 データをサーバー 1 とサーバー 2 でパーティション化することができます。これらはメッセージを表すデータ要素です。 したがって、サーバー 1 によっていくつかのメッセージが配信され、サーバー 2 によっていくつかのメッセージが配信されます。配信アルゴリズムに基づいて完全にランダムであり、パブリッシャーとサブスクライバーはすべてのサーバーに接続されます。 したがって、一部はサーバー 1 に接続され、一部はサーバー 2 に接続されますが、各サーバーは実際にはすべてのサーバーに接続していることに気付きますが、一部のメッセージはサーバー 1 によって配信され、一部のメッセージはサーバー 2 によって配信されます。前方へ。 したがって、メッセージの負荷は分散され、これは奇抜な方法で実行されます。メッセージの処理、メッセージの保存、有効期限のために、これらすべてのサーバーのメモリ容量が完全に利用され、また、それらの計算能力も論理容量に結合されます。同じように。 したがって、これらすべてのサービスはリクエスト処理能力に貢献します。これが、サーバーを追加するとシステムからより多くの能力が得られる理由です。そのため、パーティション操作レプリカ​​ トポロジを使用することをお勧めします。する必要があります。

キャッシュ トポロジ: パーティション レプリカ キャッシュ

これはパーティション レプリカ キャッシュであり、バックアップもサポートされています。

サーバー 1 にアクティブ パーティション、(サーバー) 2 にバックアップがあります。したがって、すべてのサーバーがアクティブ パーティションと、他のサーバーのレプリカである別のサーバーのバックアップ パーティションを作成します。 サーバー 1 はサーバー 2 のアクティブ バックアップ、サーバー 2 はサーバー 3 のアクティブ バックアップ、サーバー 3 はサーバー 1 のアクティブ バックアップであり、サーバーがダウンした場合でもクラスターはこれを管理できます。 サーバー 1 がダウンした場合、サーバー 1 のバックアップはサーバー 2 上にあったため、このバックアップがアクティブ化され、サーバー 2 と 3 にマージされ、クラスターが自動的に修復して、サーバー 2 のバックアップがオンになっている 1 ノードのアクティブ バックアップ、アクティブ パッシブ メカニズムが形成されます。サーバー 2 のバックアップはサーバー 1 上にあります。また、エンドユーザーにとっては完全にシームレスです。 エンドユーザーがその影響を受けることを心配する必要はありません。 つまり、100% の稼働率で NCache これらすべてを保証します。

さて、これでプレゼンテーションは終わりに近づいてきました。 最後の方で皆さんが抱くかもしれない質問のいくつかに焦点を当てたいと思いますので、お知らせください。 ということで、この時点でエディに引き渡します。 エディ、ここから拾えます。 改めて、お時間をいただきまして誠にありがとうございました。 有益であれば幸いです。次回のウェビナーでまたお会いできることを楽しみにしています。 それまでの間、既存のウェビナーを確認する必要がある場合は、オンラインで確認したばかりです。 alachisoft.com/リソース もう一度思い出させてください、 NCache は、今日市場で最大のパフォーマンスを実現する唯一のネイティブ アプリケーションです。 またお会いできるのを楽しみにしています。 ありがとう。

次はどうする？

• NCache 詳細
• ダウンロード NCache
• パーソナライズされたLIVEデモをリクエストする