NCache アーキテクチャ

録画番組
ロン・フセイン、ザック・カーン著

今日のウェビナーは以下に基づいて行われます NCache アーキテクチャ。ここでは、分散キャッシュの概要と、分散キャッシュが .NET および .NET Core。 一般的な使用例、分散キャッシュ アーキテクチャ、クラスタリングの詳細、および NCache、ただしキャッシング全般。 このウェビナーでは、いつでも GoToWebinar の質問タブで質問することができます。ご都合に合わせて質問タブをご覧ください。 そして、一度質問を書いていただければ、プレゼンテーション中にそれを取り上げて、ロンまたは私が答えることができます。 また、このセッションの最後には、他に寄せられた質問に答えるために少し時間がありますが、楽しい時間を過ごせることを楽しみにしています。

それでは、早速、ロンにそれを渡して、始めましょう。 とてもよかった、ありがとう、ザック。 それで、皆さん、先ほどザックが言ったように、今日のトピックは次のとおりです。 NCache 建築。 このウェビナーでは、その方法について詳しく説明します。 NCache クラスタリングは機能するか、選択できる最も一般的なトポロジは何か、およびクラスタリングの主な利点の XNUMX つ NCache アプリケーションのユースケースに関して。 それらのユースケースとそれを最大限に活用する方法は何ですか? NCache サーバーアプリケーション内で?

だから、みんなに私の画面を見てもらいたいと思っています。 それについてすぐに確認できれば、すぐに取り掛かります。 はい、できれば大丈夫だと思います。 ほら、そうだと思います。 うん、良さそうだね。 完璧。 さて、それでは早速始めましょう。

スケーラビリティの問題

さて、それではまず何を定義しましょう NCache は？ そのためには、スケーラビリティの問題とは何か、そしてどのように問題があるのか​​を定義する必要があります。 NCache スケーラビリティの問題を解決できます。 したがって、アプリケーションをデプロイする一般的なサーバー アーキテクチャでは、アプリケーションがデプロイされるかどうかに関係なく、通常は複数のインスタンスまたは複数のサーバーになります。 したがって、アプリケーション層は非常にスケーラブルなものであると言っても過言ではありません。

アプリケーション層にはサーバーをいくつでも追加できます。 複数のアプリケーション サーバーまたは Web サーバーが同じアプリケーションをホストしている場合でも、Web フォームやアプリ フォームを構築できますが、それらはチームで動作し、リクエストの負荷を相互に分割します。 また、マイクロサービス アーキテクチャを含む新しいアーキテクチャに移行すると、より多くの計算やリクエスト処理能力を必要とするアプリケーション サービスやマイクロサービスを個別にスケールすることができます。

したがって、アプリ層は非常に拡張性があります。 直線的に拡張可能です。 成長するにつれて、より多くのリクエスト負荷を処理できるようになります。 この問題は、リレーショナル データベースなどのデータベースを扱うときに発生します。 これらのアプリケーションはすべて、スケーラビリティのレベルに関係なく、常にバックエンド データベースと通信する必要があるためです。 そして、バックエンド データベースと通信するとき、それは通常単一のソースです。 そして、それはあまり拡張性がありません。 保管に非常に適しています。 大量のディスク リソースを確保できます。 したがって、ストレージの利点を活用できます。 しかし、アプリケーションに巨大なトランザクション負荷があり、それがデータベースのトランザクション負荷に変換されると、データベースが停止する傾向があります。 そして、それが主な問題であり、アプリケーションがリクエストの処理に苦労しているところです。 スケーラブルではなく、エンド ユーザー エクスペリエンスも損なわれます。

NoSQL databaseはこの問題をある程度解決します。 SQL データベースを使用することもできますが、そのためには、リレーショナル データベースの使用を停止し、SQL データベースの使用を開始するようにアプリケーションを再構築する必要があります。 NoSQL database そして、それは大きなプロジェクトです。 それで、 NoSQL スケーラビリティの問題を常に解決できるとは限りません。

ソリューション： NCache 分散キャッシュ

では、これが起こったとき、私たちは何をすべきでしょうか？ 解決策は非常に簡単です。次のようなメモリ内分散キャッシュが必要です。 NCache。 まず第一に、これはメモリ内で行われるため、アプリケーションのパフォーマンスが向上することが最大のメリットです。 リレーショナル データベースと比較して超高速です。 そして、主な利点は、線形にスケーラブルであることです。 通常は単一ソースであるデータベース サーバーとは異なります。 NCache 複数のサーバーに存在できます。 これにより、 キャッシュクラスター 複数のボックスで実行できます。 そして、ご存知のとおり、要件やニーズが増大し、アプリケーション層から処理する必要があるリクエスト処理能力がさらに必要になる場合は、実行時にキャッシュ クラスターにサーバーを追加できます。

についての良いこと NCache リレーショナル データベースに加えて使用するということです。 バックエンド データベースであっても、従来のデータ ソースに代わるものではありません。 これは、アプリケーションのパフォーマンスを向上できるように既存のデータ ソースを補完するものです。 アプリケーションのリクエスト処理能力を向上させることができます。 また、アプリケーション側の成長に合わせて、キャッシュ クラスター内のサーバーの数をいつでも増やすことができます。これは、これらのサーバーはクラスター内のサーバーであり、チームとして機能するためです。 結果として、線形のスケーラビリティを実現するような方法で、リクエストの負荷を相互に分割することができます。 それで、 NCache は線形にスケーラブルなモデルであり、非常に使いやすいです。 デプロイメント アーキテクチャがどのように機能するかについて説明します。 したがって、一般的に大規模な実稼働環境では、次のようになります。 NCache 次のようになります:

大量のサーバーが存在することになります。 これらは Windows または Linux サービスであり、次のような方法で設計されています。 NCache アプリケーションとデータベースの間に位置します。 たとえば、XNUMX つまたは XNUMX つから始めることもできます。 NCache サーバーを最大 XNUMX つまたは XNUMX つまで拡張できます NCache サーバー、およびさまざまな種類のアプリケーション (ASP.NET や ASP など).NET Core Web アプリ、.NET、または .NET Core サービス、または .NET/.NET Core サーバーアプリ。 あるいは、Java や Node.js である可能性もあります。 したがって、これらのアプリケーションも分散キャッシュを利用できます。

NCache それ自体は .NET/ で書かれています.NET Core。 Windows だけでなく Linux ボックスでも実行できます。 同様に、アプリケーションはどのプラットフォーム上でも問題なく動作します。 通常、次のものをお勧めします。 NCache 専用のセットアップ サーバー上で、 NCache、リソースの性質を専用にするため、 NCache。 そして、アプリケーション サーバーは別の層にあります。 そのため、アプリケーション専用のリソースも確保できます。 ただし、別の展開オプションもあります。小規模な構成の場合は、 NCache 同じボックス上にあり、そこでアプリケーションも実行されます。 つまり、それは常に可能性です NCache。 ただし、前述したように、図に示すように、別のキャッシュ層を用意することをお勧めします。 その後 NCache アプリケーションとデータベースの間に位置します。 ここでの考え方は、アプリケーション内で最も頻繁に使用するデータをすべてキャッシュするということです。 参照データまたはトランザクション データである可能性があります。 「参照」とは、読み取りがより集中的に行われるデータを意味し、「トランザクション」とは、書き込みだけでなく読み取りも集中的に行われるデータを意味します。 そして、どのデータをキャッシュするかがわかったら、そのデータを「作業セット」と呼ぶことができます。 初めて、そのデータをデータベースから取得し、データベース内に追加することもできます。 NCache そして、後続の通話は次の方法で処理できます。 NCache データベースへの高価な移動を節約できるだけです。 これは通常「キャッシュ アサイド」パターンと呼ばれるもので、加えた変更はすべてキャッシュに伝播され、その後データベースにも伝播されます。 また、データベースはキャッシュ内に存在せず、常にデータベースからフェッチして内部に保持します。 NCache ただし、常に最初にキャッシュを確認します。 したがって、キャッシュ内でデータを見つけた場合は、データベースに行く必要はなく、その時点から戻ります。

リードスルー / ライトスルー

これの代替アプローチは、ここでは点線で表されている「リードスルー」または「ライトスルー」を使用することです。 NCache にはこれを自動化できる機能があり、「キャッシュスルー」オプションがあり、読み取りの場合は「リードスルー」、書き込みの場合は「ライトスルー」と呼ばれます。 これは、常にキャッシュをメイン ソースとして使用し、キャッシュ上にリードスルー ハンドラーとライトスルー ハンドラーを実装し、バックエンド データ ソースの更新を担当するような方法で機能します。 そのため、どのような読み取り操作を実行しても、データが存在しない場合は、プロバイダーに基づいてデータベースにシームレスに移動し、アプリケーション用に取得し、アプリに戻って内部に保存します。 NCache。 更新の場合、アプリケーションから呼び出したモデルに応じて、同期または非同期のアプローチでキャッシュとデータベースが更新されます。

そこで、リードスルー、ライトスルー、キャッシュ パターンについてさらに詳しく説明しますが、大まかな導入イメージを示すために、次のようになります。 NCache サーバー フォームに展開され、複数のアプリケーションまたはアプリケーション フォームに接続できます。 NCache さらに、分散キャッシュを利用して、メモリ アクセスによりアプリケーションのパフォーマンスを向上させることができます。 また、キャッシュ層に複数のサーバーを配置すると、線形のスケーラビリティが得られます。 それが明確であったことを願っています。 ご質問がございましたらお知らせください。 幸いなことに、現時点では何もないようなので、安心して続行してください。 とても良い。

NCache スケーラビリティの数値

そこで次にお話しますのは、 NCacheのスケーラビリティの数値。 先ほども言いましたが、 NCache アプリケーションのスケーラビリティの問題を解決できます。 それで、 NCache それ自体は線形にスケーラブルです。 したがって、アプリケーション層がスケーラブルであり、線形スケーラブル モデルを通じてデータベースのボトルネックが解決されているため、参考として利用できるいくつかの数字を次に示します。 これらは QA 環境で実施したベンチマーク テストであり、CPU と RAM を実際に拡張して高負荷状況で使用できるように、高い CPU と RAM を搭載したサーバーを使用しました。 最初は XNUMX 台のサーバーで開始し、XNUMX 台のサーバーでアプリケーションの負荷を増やし続けました。 すぐに、一連のサーバーの CPU と RAM の容量が限界に達し、別のサーバーを追加することになりました。

それが経験則です。 既存のキャッシュ サーバーを引き続き使用できる場合は、まず XNUMX つのキャッシュ サーバーから始めます。 NCache これら 1 台のサーバーのハードウェア容量が最大になっていることがわかり、CPU が最大になっているか、RAM が最大になっている場合、それがスケールアウトする必要があるかどうかを選択するポイントです。キャッシュ クラスターに 2 番目のサーバーを追加する必要があります。 これはまさに私たちが平均 1 キロバイトのオブジェクト サイズで行ってきたことです。アプリケーションの負荷は増加し続け、サーバーの数は増加し続けました。 指定されたサーバーのセットが最大値に達するまで。 そして、これは一時的なデータではありませんでした。 これは実際のアプリケーション データですが、QA ラボでシミュレートされました。 したがって、XNUMX 台のサーバー、XNUMX 台、XNUMX 台、XNUMX 台、最大 XNUMX 台のサーバーを使用すると、平均 XNUMX キロバイトのオブジェクト サイズで XNUMX 秒あたり XNUMX 万件のリクエストを処理できました。

つまり、読み取りと書き込みの組み合わせが一貫してキャッシュに適用されていました。 したがって、全体として、2 秒あたり XNUMX 万リクエストのスループットが達成されました。 そして同時に、パフォーマンスに妥協することはありません。 したがって、スループットは XNUMX 秒あたりのリクエスト数が多いというだけではありません。 ただし、個々のリクエストのレイテンシも維持される必要があり、超高速である必要があります。 これに関するビデオデモンストレーションとホワイトペーパーが当社の Web サイトで公開されています (ここをクリック）。 そして、それはあなたも見直すことができるものです。

分散キャッシュの一般的な使用法

さて、一般的な使用例のいくつかについて話しましょう NCache.

• アプリのデータキャッシュ

  最も重要な使用例は、アプリケーション データのキャッシュです。 アプリのデータキャッシュ。 これはバックエンド データベースから取得されるデータです。 データベースはディスクベースであるため一般に低速であり、それに比べて RAM は高速なソースであることはすでにわかっています。 もう XNUMX つの問題は、トラフィックが多い場合にデータベースが停止する傾向があることです。 トランザクション負荷が高く、サーバーが XNUMX 台の場合、アプリケーション側で必要なパフォーマンスが得られないことが予想されます。 したがって、次を使用してアプリケーション データをアプリケーション内にキャッシュすることは非常に意味があります。 NCache。 とてもシンプルです。 あなたが使う NCache API を使用すると、単純にキャッシュを呼び出すことができます。 キャッシュ初期化 API を呼び出してキャッシュに接続します。 キャッシュに接続したら、「」を呼び出すことができます。キャッシュ.追加、キャッシュ.更新、キャッシュ.削除'または'キャッシュ.取得' キャッシュからデータを取得します。 そこで、最後にいくつかの例を紹介します。 ただし、ここでの考え方は、参照データであれトランザクション データであれ、どのようなデータでも複数回読み取ることになると考えられるということです。 参考データとしては、 NCache 変更を取得するためにデータベースに戻る必要がないため、多くの価値が追加されます。

  

  つまり、キャッシュ内のデータは長期間使用できることになります。 そして、からのデータを使用している間、 NCache、バックエンドデータベースにアクセスする必要はありません。 これにより、アプリケーションのパフォーマンスが向上します。 また、スケーラビリティも得られます。 NCache それに比べて拡張性があります。

  したがって、すべての参照データをキャッシュすることは非常に直感的ですが、トランザクション データの一部または大部分もキャッシュすることをお勧めします。 私たちの経験では、XNUMX 回または XNUMX 回読み取るデータであっても、複数回読み取るデータはキャッシュすることをお勧めします。 データベース内でデータが変更されている場合でも、その変更後に複数回 (XNUMX 回または XNUMX 回) 読み取る場合、そのデータをキャッシュすることは非常に意味があり、キャッシュする必要がなくなります。バックエンドデータベースに移動します。 そして、機能が組み込まれています NCache これにより、データベースとの 100% の同期も可能になります。 それはあなたも常に考慮できることです。

  ロン、主に次のような簡単な質問がありました。
  常にネットワーク経由でクラスター化キャッシュにアクセスする必要がありますか? ネットワークの問題によりアプリケーションが動作しなくなるのではないかと心配です。 データの一部をローカルに維持する方法はありますか?

  通常、デフォルトのデプロイメントでは、 NCache 別々のボックスに入れてから、アプリケーションも別のボックスに入れますよね? それで、いつ NCache これは TCP プロトコルに基づいているため、ネットワーク呼び出しです。 「クライアント キャッシュ」と呼ばれる機能があります。これは、アプリケーション ボックス上にあるローカル キャッシュです。 また、場合によっては、本当により多くのパフォーマーが必要で、ネットワークによって引き起こされるいかなるレイテンシーも絶対に避けたい場合は、「インプロセス」にすることもできます。これは、アプリケーション プロセス内に配置することを意味します。 したがって、それが発生すると、データのサブセットが自動的にクライアント キャッシュ内に取り込まれます。 したがって、プロセス間の通信が節約されます。 また、ネットワーク通信やネットワークのオーバーヘッドも節約できます。 したがって、機能があります。 これについては、トポロジの説明に移ってから説明します。 そこで、もう少し詳しく説明しますが、簡単に概要を説明すると、これがクライアント キャッシュの仕組みです。 これは、アプリケーションが存在するのと同じボックス上にあるキャッシュです。 そして、ここでの考え方は、クライアント キャッシュを有効にしている場合、頻繁にネットワークにアクセスする必要がないということです。 また、これはコードを変更しなくても機能します。 それで、それが質問の答えになることを願っています。 さらに質問がある場合はお知らせください。 うん、いいですね。 ロン、それを奪ってください。 とても良い。

• ASP.NET＆ASP.NET Core キャッシング

  次の使用例は、 NCache Web アプリケーション内にあります。 ユーザー データのキャッシュにはいくつかの要件がありますよね? そして、通常は ASP.NET または ASP です。.NET Core セッション状態。 このデータは一時的なデータであるため、データベースには属しません。 これはユーザーが構築するデータであり、ユーザーがアクティブである間はアプリケーション スコープ内に留まります。 場合によっては、履歴の観点からデータをデータベースに保存することもありますが、ほとんどの場合、データはユーザーに属します。

  したがって、Microsoft ASP.NET または ASP.NET Core セッション。 ステートサーバーを使用できるオプションはいくつかあります。インプロセスで使用できます。データベースサーバーを使用できます。これらにはすべて問題があります。 たとえば、インプロセスは単一障害点です。 スティッキーセッション負荷分散を使用する必要があります。 ASP.NET State Server もまた単一障害点であり、スケーラブルではありません。 データベースはオプションであり、バックアップできるため、やはり単一点障害ではありませんが、場合によっては単一点障害になる可能性がありますが、速度が遅く、拡張性がありません。 それで、ここで何をすべきでしょうか？ もう一度、使用を検討してください NCache ASP.NET および ASP の場合.NET Core セッション状態のキャッシュ。 弊社のプロバイダーを接続することで機能します。 これはコードを変更する必要のないオプションですが、プラグインするとすぐに NCache アプリケーション内で、 NCache がメインのセッションストレージになります。 そして、ここでのアイデアは、RAM ベースなので超高速になるということです。 複数のサーバーがあるため、非常に拡張性があります。 そして、その中で、 NCacheプレゼンテーションに進み、トポロジについて説明すると、次のことが理解できるでしょう。 NCache レプリケーションを利用したバックアップがあります。 そして、セッションデータはユーザーデータですよね？ つまり、データは、一度失われるとユーザーやビジネスに影響を与えるため、どのような状況でも失いたくないデータです。 したがって、レプリケーションを使用すると、データもバックアップされます。

  

  それで、得られる利点を列挙する必要があるとしたら、まず第一に、インメモリ アクセスによりアプリケーションのパフォーマンスが向上することです。 セッション キャッシュ用のアプリケーションをサポートする複数のサーバーがあるため、非常にスケーラブルです。 それに加えて、高可用性とデータ信頼性の機能が組み込まれています。 そのため、万が一の場合でもセッション データの損失やアプリケーションのダウンタイムは発生しません。 NCache サーバーがダウンします。 また、スティッキー セッションの負荷分散を使用する必要もなくなりました。 NCache 共有エンティティです。 リクエストは任意の Web サーバーに送信できます。 いつでもデータを見つけることができます NCache 当社のプロトコルに基づいています。 つまり、コードを変更することなく、これらすべてを行うことができます。

  ここでの別の使用例では、ASP.NET Web フォームを使用している場合にビューステートをバンドルすることもできます。 ここでビューステートもキャッシュされます。 ビューステートが重くなります。 多くの帯域幅を消費します。 これはリクエストとレスポンスのパケットの一部となり、常にブラウザに送り返されます。 実際にそこで使用されることはありませんが、クライアント側のブラウザに保存されるものです。 ポストバックすると、ビューステートがサーバー側に戻されます。 それで、 NCache、サーバー側でビュー ステートをキャッシュできるようにすることで、ペイロードに重いビュー ステートが関連付けられることがなくなります。 それによりパフォーマンスが向上します。 ただし、ビュー ステートはブラウザ側で常に保存されるものです。 ただし、サーバー側の必要な場所に保持しておくと、アプリケーション全体の動作が向上することがわかります。 実際の要求および応答パケットには重いビュー ステートが付加されていないため、帯域幅を消費することはもうありません。 また、ビューステートはサーバー側に保存され、その上に暗号化とセキュリティ機能をセットアップできるため、非常に安全になります。 これはコード変更不要のオプションでもあります。 ただし、これは従来の Web フォームにのみ適用されます。 したがって、ASP.NET Web フォーム アプリケーションをお持ちの場合は、ビュー ステートのキャッシュも考慮することをお勧めします。

  そして、ASP.NET と ASP があります。.NET core 応答のキャッシュ。 したがって、静的なページ、またはページ内の静的なページ部分については、それらのページ出力をキャッシュすることを検討する必要があります。 そしてASPでは.NET core、選択できる応答キャッシュ オプションがあり、これもコード変更不要のオプションです。 これに加えて、ASP.NET と ASP もあります。.NET Core SignalR Backplane。 Web フォームで SignalR を使用している場合、バックプレーンが必須となるためです。 ファイル システムやデータベースなどの一般的なバックプレーンには、先ほど説明したスケーラビリティとパフォーマンスのすべての課題が存在する可能性があります。 と NCache、舞台裏で非常に信頼性の高いメッセージング システムを使用しているため、超高速で、非常にスケーラブルで信頼性の高いものになります。 したがって、これらは ASP.NET または ASP で活用できるユースケースの一部です。.NET Core 分野の様々なアプリケーションで使用されています。

ザックの話に移る前に。 質問が投稿されていると思います。 うん。 それで、質問は基本的にデフォルトでDBと言うことから来ました。 それで、あなたの質問の最中に、私はあなたがそれを終えるまで待ちたかったのですが、質問は基本的に尋ねています。 念のため、質問について詳しく説明していただけますか？

こんにちは、ロンです NCache バックグラウンドプロセスとしてデータベース内のデータを同期するオプションを備えたメモリ内キャッシュにデータを保存するという要件がある場合、データ公開の目的にも適していますか? そしてできる NCache デフォルトでメモリキャッシュとデータベース間の同期メカニズムを処理しますか?

はい、それはとても良い質問です。 高度なケースでは、これは常に要件となる可能性があります。 これは XNUMX つの方法で機能します。 XNUMX つは、アプリケーションが次からのデータを使用していることです。 NCacheですが、データはデータベースに存在します。 つまり、これら XNUMX つの異なるソースは、読み取りと書き込みの目的で同期する必要があります。 ここで、接続されているアプリケーションが NCache そしてデータベースは、内部のデータを変更する責任を負う唯一のアプリケーションです。 NCache およびデータベースでは、読み取りスルーと書き込みスルーを使用することをお勧めします。 はい、これは要件に応じて非同期または同期の方法で実行できます。 したがって、実際に何が起こるかというと、データを取得しようとするたびに、 NCache それがキャッシュに存在せず、キャッシュしたい場合は、自動的に read-through を呼び出し、コードに基づいてバックエンド データベースから読み取ります。 同様に、データがデータベースから取得され、キャッシュ内のデータを更新したらすぐにそのデータをデータベース内で更新する必要がある場合、その場合はライトスルーを利用します。 ライトスルーもライトビハインドできるようになりました。つまり、内部でデータを更新する必要があります。 NCache また、ライトスルー ハンドラーを使用してデータベースに保存することもできます。 また、それを非同期で呼び出したい場合は、ライトビハインドを使用できるため、バックグラウンドで実行できます。 しかし、またしても、 NCache そしてあなたのアプリケーションがそれを担当します。 NCache がコードを呼び出しており、アプリケーションがそれを呼び出しています。

別の状況としては、データベース内のデータを直接変更している他のアプリケーションがあり、アプリケーションがそれを認識していない可能性があります。 したがって、その場合、実際にはデータベース同期機能を使用する必要があります。 カスタムの依存関係を考え出す必要があります。 ご存知のとおり、SQL Server にはチェーン通知があります。 データベースの依存関係があります。 したがって、データベース内の変更をキャプチャする同期機能が多数あります。 NCache 自動的に。 また、再びリードスルーを使用でき、内部のデータをリロードできます。 NCache 同じように。 まとめると、 NCache ご存知のとおり、両方の状況に対処できます。内部の何かを変更する唯一のエンティティがアプリケーションである場合のどちらかです。 NCache およびデータベース、またはキャッシュを使用しているアプリケーションの範囲外でデータベースが変更される可能性がある状況。

したがって、両方のシナリオがカバーされており、 NCache このような場合には、100 件の同期を知っているオプションが提供されます。 メモリ キャッシュについて話している場合、通常、メモリ キャッシュは ASP.NET でも機能します。 しかし、あなたが言及しているのであれば、 NCache メモリキャッシュとして使用できるので、質問にはすでに答えています。 それで、さらに質問がある場合はお知らせください。そこから受け付けます。

• Pub / Subメッセージング

  いいですね。 先に進むことができると思います。 もちろん。 さて、次は Pub-Sub メッセージングについて説明します。 ご覧のように、 NCache すでにアプリケーション間で共有されていますね。 したがって、これはデータ要件に使用できるエンティティです。 データを追加できます。 そこからデータを取得できます。 パフォーマンスとスケーラビリティの利点を得ることができます。 NCache。 次を使用してこのユースケースを拡張できます NCache メッセージングプラットフォームとしても。 それで、 NCache メッセージングは​​非常に強力です NCache。 これは非同期のイベント駆動型メカニズムであり、複数のアプリケーションが相互にメッセージング要件やアプリ調整要件を推進できます。 複数のアプリケーションが相互に通信する必要がある場合、通信を構築するのは困難です。 したがって、集中管理されたエンティティに依存する必要があります。 NCache その実体です。 また、メッセージングのサポートにより、XNUMX つのアプリケーションでデータやメッセージを追加できるオプションが提供されます。 NCacheそして、それらのメッセージは、相手側のすべてのサブスクライバ、つまり、それらのメッセージを必要とする他のアプリケーションに伝播することができます。

  

  同様に、これもデータ駆動型メッセージである可能性があります。 たとえば、データが追加、更新、または削除されると、それについて通知が届きます。 これらはカスタム アプリケーション メッセージまたはデータ駆動型メッセージである可能性があるため、内部にデータが入力される両方の領域をカバーします。 NCache 他のアプリケーションにそれを認識させたい場合は、それを通じてメッセージング要件を推進できます。 あるいは、あるアプリケーションが別のアプリケーションと通信する必要があるカスタム メッセージングやアプリケーション駆動型メッセージングの場合もあります。 これもまた、インメモリ スケーラブル モデルに基づいています。 信頼性の高いレプリケーション オプションも利用できます。 これは、トピックの概念と、複数のアプリケーションが接続されるメッセージ ブローカーの概念を持つ従来の Pub-Sub メッセージング プラットフォームに基づいています。 したがって、パブリッシャー アプリケーションとサブスクライバー アプリケーションを定義できます。 パブリッシャー アプリケーションは、メッセージをパブリッシュします。 NCache その後、これらすべての加入者に送信されます。 そして、購読者は自分のメッセージを送信することもできます。 NCache は、これらの異なるアプリケーション間の通信プラットフォームとして機能します。

• 全文検索（分散Lucene）

  最後に、全文検索という別の使用例があります。 したがって、アプリケーションがあり、全文検索要件を次から実行する必要がある場合、 NCacheの場合は、Lucine.NET ベースの全文検索機能の使用を検討してください。

  通常、Lucene API はスタンドアロンであることがわかります。 そうですね、複数のサーバー上で拡張できます。 NCache メモリ内にインデックスをロードする機能も提供します。 それで、 NCache ディスクベースのインデックスを使用しますが、実際には、複数のサーバーを使用してストレージとリクエスト処理能力を拡張できます。 したがって、ディスクベースではありますが、それでもデータベース上の単一ソースよりも優れています。 大量のトランザクション負荷がある場合、各サーバーが独自のインデックス リクエストのセットを担当することになるためです。 したがって、非常に拡張性が高くなります。 それは非常に信頼性も高いでしょう。 これはアシスト ストアであるため、シーン インデックスに関しては、永続性自体が機能です。 NCache。 内部に保存するあらゆるデータ NCache ディスク上に永続化することも、一部のデータベース プロバイダーに基づいて、一部のデータベース上に永続化することもできます。 ただし、Lucene は、 NCache ユースケースの性質上、データを永続化する必要があるため、RAM ではなくディスクが使用されます。

  

それが簡単だったことを願っています。 以上が使用例の一部でした。 繰り返しになりますが、これらの使用例には多くの機能があります。 あらゆる種類のアプリケーション、アプリケーション内の特定の要件は、オブジェクト キャッシュ機能とセッション キャッシュ機能を使用して完全に処理できます。

ちょっと質問なのですが、ロン。
MySQL データベースと同じように、キャッシュ内のデータにアクセスする方法はありますか? キャッシュ データに対して SQL クエリを実行できるようにしたいと考えています。 それをしてもいいですか？

確かに。 NCache まず、SQL 検索と LINQ クエリをサポートします。 したがって、単純に接続できるアプリケーションを作成する能力がある場合は、 NCacheをクリックしてから、条件ベースの検索を実行します。これは、条件ベースの検索を作成する際に利用できる簡単なオプションです。 たとえば、次のすべての製品を選択できます。 製品.価格 は 10 より大きく 100 未満です。または、カテゴリに基づいてすべての製品を検索することもできます。 地域に基づいて顧客を見つけることができます。 したがって、SQL ベースの検索または LINQ ベースの検索を思いつくことができます。 NCache キャッシュからデータを取得します。 それは XNUMX つの選択肢です。

もう XNUMX つのオプションは、LINQ Pad 統合です。 したがって、アプリケーション開発を行わずにデータを視覚化したいだけの場合、LINQ Pad を使用すると、LINQ クエリを実行できる簡単な方法が得られ、LINQ クエリを実行してデータを視覚化できます。

そして、今後のリリースでは、XNUMX 番目のオプションとしてデータ分析ツールを提供します。 そこで、キャッシュ内に存在するデータを監視できる自動化された方法、つまり監視ツールを提供します。 また、GUI からこれらの条件ベースの検索オプションが提供されるため、これはパイプラインにあるものです。 要件が完了し、開発作業が完了しました。 それは次のリリースの一部になると思います。

間違いなくそのすべてを楽しみにしています。 完璧。 うん。 とても良い。 今のところは大丈夫だと思う、ロン。 興味深い質問がいくつかあったので、いくつかの質問は最後に取っておきますが、はい、続けましょう。 もちろん。

自己修復動的クラスター

そこで、次に動的キャッシュ クラスターについて詳しく説明します。 NCache TCP IP ベースのキャッシュ クラスタリング プロトコルに基づいています。 これは独自に実装されたキャッシュ クラスタリングです。 この件に関しては、サードパーティまたは Windows クラスタリングは使用していません。 これは 100% 独自のプロトコルです。 .NET で書かれており、 .NET Coreつまり、これは次の点で非常に便利であることがわかります --- TCP ソケットも .NET であり、 .NET Core に基づいています。 100% ピアツーピア アーキテクチャなので、単一障害点はありません。実行時にサーバーを追加または削除できます。キャッシュやそれに接続されているクライアント アプリケーションを停止する必要はありません。したがって、実行中のキャッシュ クラスターに動的に変更を加えることができ、 NCache それについては何の問題もありません。 サーバーを追加すると、クライアントは実行時に通知を受けるため、このサーバーがもう存在しない、現在はキャッシュ クラスターの一部であることが自動的にわかり、追加のサーバーの使用が開始され、クラスターが自動的に調整されます。 同様に、サーバーを削除すると、他のサーバーはこのサーバーが完全になくなったことを検出します。 クライアントに通知し、クライアントは失われたサーバーの使用を停止します。 接続フェイルオーバーのサポートがあり、これもクライアント側に構築されているため、サーバーがダウンすると、クラスターがクライアントにそれを認識させ、接続をフェイルオーバーして、残っているサーバーの使用を開始します。サーバー。

したがって、いずれの場合も、クラスター内の変更はクライアントに伝播されます。 クライアントはインテリジェントであり、キャッシュ クラスターの状態を常に認識しています。 したがって、レプリケーション サポートも組み込まれているため、ダウンタイムやデータ損失が発生しないことが保証されます。 それで、 NCache 可用性が高く、レプリケーションのおかげで信頼性も非常に高くなります。 アプリケーション側で 100% の稼働時間を確保し、アプリケーションを中断することなく、使い続けることができます。 NCache.

キャッシングトポロジ

次に、キャッシュ トポロジについて説明します。 それが私がカバーしたい主な部分です。 XNUMX つのオプションからお選びいただけます。 最初のオプションも小規模な構成用です。 これらは、キャッシュを構成する方法を決定します。

ミラーリングされたキャッシュ

したがって、ミラーリングされたキャッシュ トポロジを使用してキャッシュを構成するオプションがあり、その仕組みは最大 XNUMX 台のサーバーのみで動作します。 これらのサーバーの XNUMX つがアクティブ サーバーとして機能し、すべてのクライアントがそこに接続されます。 もう一方のサーバーはパッシブ サーバーとして機能し、バックアップとして機能します。バックアップは次の方法で実行されます。 NCache。 このトポロジは、一度構成すると、自動的にアーキテクチャに従います。 基本的に、これがアクティブになるか、これがパッシブになるかを定義する必要はありません。これは次のように定義されます。 NCache 自動的に。 しかし、それを実行すると、実際に起こることは、すべてのクライアント アプリケーションがアクティブなサーバーに接続し、そこからデータの読み書きを行うことになります。 アクティブ サーバー上にあるデータはすべて、非同期ミラーリング オプションを通じてパッシブ サーバーにバックアップされます。 したがって、クライアントはアクティブを更新して返すため、クライアント アプリケーション側ではレプリケーションのコストは発生しません。 クライアント アプリケーションは超高速になります。 舞台裏では、 NCache バックアップを更新する必要があります。 そして、バックアップが存在するのには重要な理由があります。サーバー XNUMX がダウンした場合、バックアップ サーバーはアクティブ サーバーとして自動的に更新され、クライアントは接続をフェイルオーバーして、新しくアクティブになった以前のバックアップ サーバーの使用を開始します。 そして、最初のサーバーが復帰すると、キャッシュ クラスターにすでにアクティブなサーバーがあるため、アクティブ ノードとしてではなく、バックアップ ノードとして再び参加します。 これらすべてがアプリケーションに対してシームレスに実行されます。 サーバーが追加されたとき、またはサーバーが失われたときに、介入を行う必要はありません。

このトポロジは、書き込みだけでなく読み取りにも非常に適しています。 したがって、参照には適しており、トランザクション データには適していますが、最大で XNUMX 台のサーバーしかなく、その XNUMX 台のサーバーのうち、特定の時点でアクティブになるサーバーは XNUMX 台だけであるため、容量の問題があります。 したがって、信頼性の高いデータを備えた小規模な構成の場合、キャッシュがオプションの XNUMX つになる可能性があります。

複製されたキャッシュ

次に、1 番目のオプションは複製されたキャッシュです。 これも小規模な構成向けです。 これは、すべてのサーバーがアクティブになるように機能します。サーバー 2 とサーバー 2 が両方ともアクティブであることがわかります。 クライアントは異なるサーバーに分割されているため、図に示すように 2 つのクライアントがある場合、そのうちのいくつかはサーバー XNUMX に接続し、いくつかはサーバー XNUMX に接続します。そうです、これら XNUMX つはサーバー XNUMX に接続され、これらはサーバー XNUMX に接続されます。サーバーXNUMX。

これは自動的に行われます。 接続バランスは内部に組み込まれるものです NCache。 すべてのサーバーはアクティブですが、各サーバーにはキャッシュのコピーがあります。 したがって、サーバー 1 にあるデータが何であれ、コピーがサーバー 2 にあり、このコピーは同期更新の助けを借りて維持されます。 したがって、100 つのサーバーで実行する更新は、同期呼び出しで他のサーバーに適用する必要があります。つまり、クライアントはその操作全体が完了するまで待機することになります。 いずれかのサーバーで操作が失敗した場合、操作全体がロールバックされます。 これにより、すべてのサーバーで 1% 同期されたコピーが実現されます。 これは信頼性の点で非常に優れていますが、読み取りが集中するユースケースでは、より多くのデータのコピーや、さまざまなサーバーからのより多くのコピーがあるため、サーバーの数が増えるほど、読み取り容量が増加します。リクエストを処理するサーバーが増えるためです。 ただし、お気づきのとおり、同期アップデートがあるため、書き込み操作はすべてのサーバーに適用する必要があります。 したがって、書き込み容量の小さい構成に適しています。 サーバーが XNUMX つまたは XNUMX つある場合は、同じ操作を XNUMX 回または XNUMX 回適用する必要があるため、立ち上がりパフォーマンスに悪影響を及ぼす可能性があります。 したがって、このトポロジは、小規模な構成の参照データ シナリオでより推奨されます。 読み取りに関してはスケーラブルですが、書き込みに関してはそれほどスケーラブルではありませんが、非常に信頼性があります。 これにより、いずれかのサーバーが失われた場合、たとえばサーバー XNUMX が失われた場合でも、これらのアプリケーションがフェイルオーバーして生き残っているサーバーの選択を開始し、キャッシュのコピーが存在するため、データの損失やダウンタイムが発生しないため、高可用性とデータの信頼性がもたらされます。すでに利用可能です。

パーティション化キャッシュとパーティションレプリカキャッシュ

次のオプションは、パーティション化されたキャッシュを使用してキャッシュを構成することを選択できることです。 現在はパーティション化されており、パーティション レプリカは、ご存知のとおり、最も一般的なトポロジです。 パーティション化されたキャッシュを使用すると、使用可能なサーバー ノード間でデータを分散できます。 たとえば、1 つのサーバーがあり、データがある場合、データの半分はサーバー 2 に送信され、データの半分はサーバー XNUMX に送信されます。データ分散も一部です。 NCache。 これはアプリケーションが行うことではなく、実行時にアプリケーションによって自動的に行われます。 インテリジェントな分散マップとハッシュ アルゴリズムがあり、それによってどのデータがどのサーバーに送信されるかが決まります。

したがって、これに基づいて、アプリケーションはキャッシュ クラスター内のすべてのサーバーにデータを均等に分散することになります。 データが均等に分散されるようになったので、リクエストの負荷も均等に分散されます。 したがって、これにより、サーバーの数に基づいて、より多くの読み取りおよび書き込み容量が得られます。 サーバーが XNUMX 台ある場合は、XNUMX 台のサーバーがチームで動作することになります。 また、XNUMX 台から XNUMX 台に増加すると、読み取りおよび書き込みリクエストを処理するサーバーの数が増えます。 したがって、読み取りと書き込みのスケーラビリティが向上します。 したがって、直線的にスケーラブルな方法で、サーバーを追加するとさらにスケーラビリティが向上します。 データが分散されるため、サーバーを追加するとメモリ リソースもプールされ、すべてのサーバーのストレージが一緒にプールされることになります。 したがって、サーバーが XNUMX 台ある場合、サーバーの容量は XNUMX 台になります。 XNUMX 台目または XNUMX 台目のサーバーを追加すると、サーバーの数だけ容量が増加します。 したがって、全体的な容量がプールされるため、キャッシュ クラスターにサーバーを追加すると、直線的に増加します。

読み取り、書き込みに非常に適しており、参照およびトランザクション データに対して非常にスケーラブルです。 このトポロジの唯一の欠点は、バックアップがないことです。 サーバーを失うと、そのパーティションも失われます。 したがって、そのような場合には、バックエンド データベースからそのデータを構築する方法が必要になります。 したがって、主な目標が高いパフォーマンスを達成することであり、パフォーマンス中心のアプリケーションであり、データベースに戻る余裕がある場合 (これは一般的なケースです)、依存する必要はありません。 NCache 高可用性とデータの信頼性を実現するため、他のすべてのトポロジと比較して最高のパフォーマンスが得られます。

しかし、高可用性が必要な場合は、データの信頼性要件も満たす必要があります。 NCache, レプリカ キャッシュのパーティションと呼ばれる、より優れたトポロジがあります。 現在、全体的なアーキテクチャは、レプリカを強化したパーティション化とまったく同じになっています。各サーバーにはデータのパーティションがありますが、各サーバーは 1 つのパーティションを維持します。 クライアントが接続されているアクティブなデータ パーティションと、別のサーバーのバックアップ パーティションです。 サーバー 2 はアクティブで、そのバックアップは 2 にあり、サーバー 1 はアクティブで、そのバックアップは XNUMX にあります。また、同期または非同期バックアップ オプションを選択できます。 非同期でレプリカのパーティションを選択した場合、クライアントはアクティブなパーティションを更新して戻り、その操作がクライアント上で完了した後、 NCache バックグラウンドでバックアップ パーティションを更新します。 同期を選択すると、クライアント アプリケーションはトランザクション操作としてアクティブとバックアップを更新します。 いずれにしても、同期の方が明らかに信頼性が高く、非同期の方が高速です。 しかし、どちらにしても、 NCache ご存知のとおり、いずれかのサーバーがダウンしてもバックアップ トポロジがアクティブになり、データの損失やアプリケーションのダウンタイムが発生しないような方法でデータの信頼性を処理できます。 右。

それでは、3 台のサーバーを使用したこのトポロジを簡単に説明します。 したがって、読み取りの高性能、書き込みの高性能、読み取りと書き込みの線形スケーラビリティのすべての利点が得られます。 それに加えて、スケーラビリティ、高可用性、データ信頼性の利点も得られます。 サーバーがダウンしても、データの損失やアプリケーションのダウンタイムは発生しません。

デモ

それが明らかだといいのですが。 ここでデモ環境に行き、これらのキャッシュ トポロジを構築する方法を簡単に説明し、次にキャッシュ クラスターをすばやくテストする方法も説明します。 ただし、ご不明な点がございましたら、お知らせください。 簡単に思い出していただきたいのですが、私たちが示しているすべてのことは、お客様の環境で、特定のユースケースに合わせてハンドホールディング セッションやテクニカル サポート セッションで行うこともできます。 したがって、ウェビナー後であっても、ここで議論するすべてのことについては、チームとして皆さんと協力して、それがどのように機能するかを実証できることを嬉しく思います。

質問に関して言えば、最後にぴったりの質問がありました。 そのうちの XNUMX つはあなたのお気に入りの XNUMX つです。
アプリケーションのキャッシュに Hazelcast を使用することについては、多くの議論が行われてきました。 どういうことですか NCache Hazelcast はそうではないということですが?

わかった。 まず第一に、それはもっと議論です。 NCache 実際には .NET で書かれており、 .NET Core、したがって、次のような場合に推奨されるプラットフォーム NCache Windowsです。 良い点 NCache それは、.NET だけでなく、Windows や Linux でも実行できるということです。 したがって、プラットフォームと互換性はそれをサポートします NCache これを実現できる製品は他にありません。 これが最初の部分であり、使用する予定のプラットフォームを考慮している場合には、これを選択することをお勧めします。 もう XNUMX つの違いは、皆さんもぜひ調べてみることをお勧めします。 比較ページ、そこにも非常に良い素材が見つかるでしょう。 しかし、これを簡単に要約すると、 NCache オブジェクト キャッシュのサポートには、他の製品にはまったく欠けている多くの機能があります。 たとえば、SQL 検索など、内部で利用できる精巧な機能セットが用意されています。 NCache。 キャッシュローダーとキャッシュリフレッシャーがあります。 これらは完全に独自の機能です。 NCache。 .NET を実行する機能を備えたリードスルーおよびライトスルー ハンドラー .NET Core サーバー側のコード、これは絶対にユニークな機能です。 NCache、リストは続きます。 ご存知のとおり、いくつかの機能はサーバー側でカスタマイズできます。 それらは以下でのみ利用可能です NCache そして、アプリケーションの観点から見ると、他の製品には欠けている機能がたくさんあります。 したがって、皆さんも比較ページをチェックすることをお勧めします。 いくつかの比較、機能ごとの比較が公開されており、それについてのより詳細な情報が得られます。

これは間違いなく私たちのお気に入りの質問です。それがウェビナーであろうと技術ソリューションであろうと、それは Hazlecast かもしれないし、Scala かもしれません。 Redisでも、本当にありがとう、ロン。 はい、大丈夫だと思います。 続けてください。 もちろん。

新しいクラスター化キャッシュを作成する

そこで、新しいクラスター化キャッシュを作成して、製品の簡単なデモを行ってみましょう。 これをテストキャッシュと名付けましょう。 そうですね、少しここに移らせていただきますが、少々お待ちください。 わかった。

以上、XNUMX つのキャッシュ トポロジについて説明しました。 ここでは、非同期レプリケーション オプションを備えた最も推奨されるレプリカ キャッシュのパーティションを使用することにします。 これらすべてのデフォルトをそのまま使用します。

次に、GUI ツールを使用してキャッシュを構成するのがいかに簡単かを説明します。 これは Web マネージャーですが、PowerShell コマンドレットを使用してすべてを実現することもでき、必要に応じてこの展開も自動化することもできます。 サーバー XNUMX を追加します。 NCache がインストールされています。 次に、サーバー 2 を追加します。つまり、私の 2 つのボックスには次のようなものがあります。 NCache 2 ギガのサイズでセットアップすることになります。 したがって、ここでの私のアイデアは、それぞれ 2 ギガのキャッシュ サイズを使用して 2 ノードのキャッシュ クラスターを作成するということです。 つまり、2 つのサーバーで合計 XNUMX つのギグが行われます。 NCache はすでにインストールされています。 次に、ボックスを使用してこのキャッシュ クラスターに接続します。

TCPパラメータ。 これは、設定後に設定する必要があるポートです。 デフォルトのままにするか、ファイアウォールが影響を与えないポートを指定します。

暗号化と圧縮を設定する必要がある場合は、この画面が表示されます。 そのままにしておきます。 次を選択してください。 キャッシュがいっぱいになった場合のエビクションは、ユーザーが選択できるものです。 XNUMX つのオプションは、キャッシュが書き込み操作をまったく受け付けないことです。 「キャッシュがいっぱいです」というエラーが表示されます。 他のオプションは、エビクションを設定し、これらのアルゴリズムに基づいて、実行時にキャッシュから一部の項目を削除することです。 したがって、優先度、使用状況に基づいて、最近使用されていないアイテムや頻繁に使用されているアイテムを削除でき、アイテムの XNUMX% がキャッシュから削除されます。 このキャッシュは終了時に開始し、サーバーが再起動するたびに自動で開始されるようにします。 NCache サーバーが再起動すると、停止されているキャッシュを再起動できます。

終了を選択します。それで終わりです。 キャッシュ クラスターのセットアップは非常に簡単です。 そして少しすると、このキャッシュが開始される別のビューが表示され、そこから監視と管理の詳細が表示されます。 キャッシュ構成に関する詳細なビデオがいくつかありますので、ご質問がある場合は、今すぐお知らせください。そうでない場合は、それらのビデオを参照することもできます。

クラスターの監視を選択すると、別のダッシュボードが開き、キャッシュを完全に監視できるようになります。 完全に接続されたキャッシュ クラスター、リクエスト スループット カウンター、レイテンシ カウンター、さらに追加、フェッチ、更新カウンターも表示されます。 同様に、CPU とメモリの使用状況、キャッシュがいっぱいの状況も表示されます。

また、クライアント用のダッシュボードと、サーバー側とクライアント側のダッシュボードが表示されるレポート ビューもあります。 現時点では接続されているアプリケーションはありませんが、このテストストレスボタンを使用して負荷をシミュレートする方法があります。 したがって、この test-stress を呼び出すことで、キャッシュ クラスター上でダミー ロードやアクティビティを開始できます。 これを実行するとすぐに、1 つのクライアントが接続されていることがわかります。このトポロジではデータが分散される必要があります。 したがって、一部のデータはサーバー 2 に送信され、一部のデータはサーバー XNUMX に送信されます。したがって、このクライアントは両方のサーバーを均等に使用しています。 リクエストが両方のサーバーに届いていることがわかり、両方のサーバーでキャッシュ サイズが増加しています。

両方のサーバーにアクティブ パーティションとバックアップ パーティションも表示されています。 レイテンシ カウンタを簡単に示してみると、私の操作に関する限り、ミリ秒未満、さらにはマイクロ秒のレイテンシです。 クライアント ダッシュボードにはクライアント側の統計が表示されており、同様にサーバー側の統計を示すレポートもあります。

ロン 質問があります。実際、いくつかの質問が寄せられました。そのうちの XNUMX つは次のとおりです。
立ち退きの推奨事項は何ですか? そして、少なくともエビクションが必要な場合は、次のことを待ってください。エビクションがオフになっている場合、キャッシュ サイズを増やすか減らすことができますか?

もちろん。つまり、エビクションはユースケースに基づいて設定する必要があるということですね。データが追い出されても構わないものであれば、そうです。キャッシュがいっぱいになった場合、エビクション自体によって一部のデータが削除されます。理想的な状況は、そんなことをする必要がなく、キャッシュが十分な容量内にあることです。したがって、キャッシュがいっぱいにならないように、キャッシュに十分なサイズまたは十分なメモリを与えます。しかし、そうなった場合、ご存知のとおり、満杯になる点に達します。その場合、データがバックエンド データベースからいつでも再構築できるものであれば、エビクションを有効にすることをお勧めします。たとえば、ASP.NET セッションの場合、エビクションをオンにすることはお勧めしません。新しいユーザーのためのスペースを確保するために一部のユーザーを削除することになり、すべてのユーザーが重要なデータを持っているからです。したがって、これは、どのようなシナリオでも失いたくないデータです。したがって、これらのシナリオでは、キャッシュ サイズを増やすことをお勧めします。キャッシュ サイズが十分な大きさになるように計画し、キャッシュ サイズがいっぱいになった場合に備えてください。 NCache 実行時にキャッシュ サイズを変更できます。 これは編集できます。それに基づいて設定を増やし、実行中のキャッシュに保存できます。 したがって、これは非常に適用可能であり、実行時のキャッシュ サイズが増加します。

他に何かご質問は？ これで解決したようです。デモンストレーションを完了できるよう、最後にいくつか保存しておきます。 もちろん。 デモ環境に戻って、クライアントを追加できます。たとえば、私のボックスをクライアントとして追加できます。これは、私のボックスから実行できるサンプル アプリケーションの簡単な概要です。 たとえば、これは GitHub からも入手できますので、検索すると NCache GitHub ではいくつかのサンプルを参照できます。そこからサンプルの XNUMX つを抽出しました。 したがって、アプリケーション内で実際に行う必要があるのは、この NuGet パッケージをインクルードすることです。 Alachisoft.NCache.SDK、興味があれば アプリデータのキャッシュ、これは検討すべきサンプルです。 そして、これに基づいて、これを追加すると、アプリケーション内にいくつかのリソースを含めることができます。

これにはすでにいくつかのライブラリが含まれています。 NCache、この新しい NuGet パッケージの一部として。 そして、次を使用してこの参照を含めます。 Alachisoft.NCache。クライアント。 も追加 ランタイム.キャッシュそうです。それに基づいてキャッシュ ハンドルを定義でき、その中には多数のメソッドがあります。 たとえば、キャッシュを初期化する方法を説明します。 実際にこの中に入ってみましょう。 我慢してください。 大変なんです。 とにかく、何らかの理由で実際に中に入ることができません。箱自体に問題があると思います。 とにかく、API は非常に直感的です。 パワーポイントからお見せしましょう。 このサンプルは実際にそれを使用していますが、コードにステップインすることができないため、デモンストレーションすることができません。 それは私にさせてくれません。

これはキャッシュ ハンドルであり、私が示したかったコード部分です。 CacheManager.GetCache キャッシュに接続できるようになります。 その後、電話をかけることができます キャッシュ.取得 実際にキャッシュからデータを取得します。 同様に、次のように呼び出すこともできます キャッシュ.追加 or キャッシュ.AddAsync キャッシュにレコードを追加し、キャッシュ内のデータを追加および更新する upsert と同様に挿入します。同様に、次のように呼び出すことができます。 キャッシュ.削除.

したがって、この サンプル ダウンロードしてキャッシュに対して実行できるものが利用可能です。 あなたがしなければならないことは、アプリケーション側からキャッシュをポイントすることだけです。 たくさんの設定があります。 キャッシュの名前と IP をインラインで指定することも、この NuGet パッケージがプロジェクトに含まれる client.ncconf に依存することもできます。 そこで、いくつかのリソースを簡単にお見せすると、実際には多くのファイルが追加されています。ここにあるこのファイルは、キャッシュに接続できるようにするファイルです。 つまり、すでに「democache」に接続できています。 これを実行すると、キャッシュに対して何らかのアクティビティが実行され、キャッシュ操作が開始されます。

同様に、さらにいくつかのオプションを提供する別のサンプルがあります。たとえば、次のような質問がありました。 中を探して NCache、 右。 したがって、ここでこのサンプルを使用することをお勧めします。 SQL検索用です。 これは再び GitHub からダウンロードされ、再び検索を使用し、サンプル データがあり、SQL を使用して検索を呼び出します。 そして、ここにも同じような機能がたくさんあり、サンプルは非常に直感的です。 項目を挿入してから、名前タグを使用してクエリを実行したり、定義されたインデックスまたはプロジェクションを使用してクエリを実行したりできます。

残念ながら、環境問題のため、これらの手法について詳しく説明することはできませんが、ここでもまた、これらを使用するための優れた参照点として役立ちます。 NCache アプリケーション内でキャッシュを使用する必要があるアプリケーション、またはアプリケーション内で検索するユースケースがあるアプリケーションから。

クライアントキャッシュ

についての別の質問がありました クライアントキャッシュしたがって、このトポロジはコード変更不要のオプションでもあります。 内部のデータベースからキャッシュしたすべてのデータ NCache、クライアント キャッシュを使用してさらにキャッシュできます。 これは、別のキャッシュの上にあるキャッシュです。 コードを変更しなくても動作します。 これはクラスター化キャッシュを備えた同期キャッシュであるため、データの一貫性の問題はありません。 同期は次のように行われます。 NCache。 XNUMX つのクライアント キャッシュで行われた更新は、必ずクラスター化キャッシュに伝播され、次に他のクライアント キャッシュに伝播され、キャッシュ内ですべての同期が管理されます。 書き込みがそれほど多くない参照データのシナリオでは、これは非常に推奨されるオプションです。

WANレプリケーション

同様に、 NCache また、持って WANレプリケーション。 アクティブ/パッシブ トポロジとアクティブ/アクティブ トポロジがあります。 そのため、ブリッジ キャッシュを介して、キャッシュ データ全体を XNUMX つのデータ センターから別のデータ センターに複製できます。 Bridge 自体はアクティブなパッシブ サーバー上にバックアップされるため、ソース キャッシュとターゲット キャッシュがあり、DR シナリオやデータセンター間でのデータの一方向レプリケーションまたは東から西への移行が行われます。東から西への移行、または XNUMX つのアプリケーションからのデータが必要で、それをターゲット アプリケーションで使用する必要がある場合などです。 したがって、キャッシュ データ全体を XNUMX つのデータ センターから別のデータ センターに転送できます。

もう XNUMX つのオプションはアクティブ-アクティブです。 この例では、両方のサイトがアクティブになっているため、サイト XNUMX はサイト XNUMX にデータを転送し、サイト XNUMX はサイト XNUMX にデータを転送しています。 繰り返しますが、これはコード変更のないオプションです。 それは単なる構成です。 ブリッジを設定したら、XNUMX つのキャッシュを接続し、 NCache が引き継ぎ、それらのキャッシュ間でデータのレプリケーションを開始します。

また、これはマルチアクティブ/アクティブ トポロジにも拡張されるため、サイトが XNUMX つだけである必要はなく、すべてのサイトが相互にデータを転送する XNUMX つ、XNUMX つ、または XNUMX つのサイトにすることもできます。 それで、 NCacheの機能は、実際にすべてのサイトのデータを一度に同期することができます。 ちなみに、これは非同期で行われるため、アプリケーション側やユーザー側でレプリケーションのコストが再び発生することはありません。 アプリケーション上で行われます。 ここにもクライアント アプリケーションが接続されています。 この WAN レプリケーションによるパフォーマンスの低下は見られません。 それは舞台裏で行われます NCache。 ご質問がございましたらお知らせください。 この時点でプレゼンテーションと機能セットを終了しましょう。 ザック、何か質問があれば言ってください。

はい、カップルがいます。 皆さん、ご辛抱いただきありがとうございます。プレゼンテーション中に疑問に思ったことがあれば、他の質問を投げ込む良い機会でもあります。 それでは、XNUMX つから始めましょう。
キャッシュが正常な状態で実行されているかどうかをどのように確認しますか? 何か通知等は来るのでしょうか？ たとえば、問題があるかどうかをどうやって知ることができるのでしょうか?

もちろん。 我々は持っています 監視および管理ツール。 したがって、視覚的に検査してクラスターの健全性を確認することが XNUMX つ考えられます。 CPU 使用率、RAM 使用率がわかります。 ベースラインがわかれば、アプリケーションが生成するリクエストの数、および一般的な使用率がわかります。 NCache これらのカウンターに基づいて、監視および管理ダッシュボードを使用して視覚的に検査できます。 そして、あらゆる状況に対するアラートを用意しています。たとえば、キャッシュの開始、キャッシュの停止、ノードの参加、離脱、キャッシュ サイズがいっぱいになったとき、またはクラスターが異常な状態になったとき (スプリット ブレインなど)、アラートがあります。これを Windows イベント ログに記録します。 また、次から電子メール アラートを設定することもできます。 NCache、あなた宛のメールも生成できます。 したがって、これは予防的な監視となり、いくつかの警告が表示されます。 NCacheここで、 NCache 警告が表示され、それに基づいてアクションを実行できます。 また、キャッシュ ログだけでなく、perfmon カウンタ ログの形式で取得された履歴データもあります。 何が問題だったのか分からず、いくつかの問題が発生した状況では、 NCache、私たちは来て参加することができ、レビューすることができます NCache ログを参照し、その場合のキャッシュの健全性を評価します。 したがって、この点に関しては、私たちが検討できる方法がたくさんあることをご存知でしょう。

いいですね。 別の質問は次のとおりです。
最新の .NET バージョンは何ですか? NCache 現在クライアントをサポートしていますか?

わかった。 通常、私たちは最新のものを使用する傾向があります .NET framework バージョン、 .NET Core。 .NET 6 は現在サポートされており、これは前提条件です。 NCache。 必須として .NET 6 が必要です NCache サーバー。 ただし、アプリケーションはどのような環境でも実行できます。 .NET framework, 3.5以降は4.0、4.5、あるいは4.7、4.8になると思います。 アプリケーションは、.NET または .NET Core フレームワーク。 これはサーバー側の制限にすぎません。 そして、新しいフレームワークの互換性がテストされるとすぐに、たとえば .NET 7 については、すでに QA ラボでテストを行っています。 したがって、承認が完了したら、それに対する公式サポートもリリースする予定です。

素晴らしい。 別の質問は次のとおりです。
キャッシュ サーバー間でクラスター化されたキャッシュの安全な量はどれくらいだと考えられますか? キャッシュ サーバー間で、たとえば 15 個のクラスター化キャッシュを作成できますか?

わかった。 初めに、 NCache 構成できるキャッシュの数に制限は適用されません。 実際、私のデモ環境を見ると、10 つのキャッシュが構成されています。 したがって、必要な数だけ作成できます。 ただし、実稼働環境では通常、XNUMX ～ XNUMX 個のキャッシュを超えないようにすることを推奨する技術的な推奨事項または容量関連の推奨事項があります。 すべてのキャッシュは個別のキャッシュ クラスターであるためです。 実際には、ストレージ、クラスタリング、通信のためのすべてのリソースが消費され、クラスタ管理のオーバーヘッドも発生します。 したがって、キャッシュの数が増えると、実際にはその環境またはその環境内で容量の問題が発生することになります。 したがって、可能であれば XNUMX ～ XNUMX 以内に留めることをお勧めします。 複数のキャッシュが必要な状況では、最大 XNUMX まで拡張できます。ただし、前述したように、これも推奨事項です。 これを強制する実際の制限はありません。 これは私たちからの汎用的な推奨事項です。

わかった。 もう XNUMX つだけ追加させてください。セッションが終わりに近づいていることはわかっていますし、Docker に他の作業があることもわかっています。
できる NCache DR レプリケーションを提供しますか?

はい、そうです。 先ほど説明した WAN レプリケーション機能、最後のトポロジは、DR、災害復旧をカバーします。 サイトはアクティブ サイトのデータとともに送信できるため、DR サイトが完全にバックアップされます。 アプリケーション側でスイッチを入れるだけです。 すべてのデータはすでにバックアップされているため、XNUMX つのデータ センターが完全にダウンしたり、メンテナンスのために自分でデータ センターをダウンさせる必要があるような状況でも、データが失われることはありません。

よし。 できる限り多くのことを達成できたと思います。 皆様、これらのセッション以外でも対応可能ですのでご了承ください。 すでに NCache。 初めての方は NCache喜んでトライアルをセットアップし、これが統合アプリケーションでどのように機能するかを説明するためのハンドホールディング セッションを開催します。しかし、何よりも、次のような場合はいつでも連絡できることを知っておいてください。に関するご質問 NCache、または製品を使用していて、サポートが必要な場合でも。 今後、たくさんの新しいものが登場し、新しいバージョンのリリースも予定されていますので、今後もこのようなウェビナーをさらに開催する予定ですので、ぜひ注目してください。

ロンに拍手。 今日はセッションのために時間を割いていただき、本当に感謝しています。次回のセッションを楽しみにしています。 皆さん、ありがとう。 ありがとう、ザック。 もちろん。 はい、皆さん。 皆様、素晴らしい一日をお過ごしください。次回のウェビナーでお会いできるのを楽しみにしています。 免責事項として、このウェビナーが終了した後、すべてが完了して塵が除去された後、ウェビナーの録画が当社の Web サイトにアップロードされる予定です。 したがって、質問に答える機会がなかった場合や、これまでに述べたポイントを再確認したい場合は、お気軽にもう一度私たちの Web サイトにアクセスして、次の内容を確認してください。録画されたウェビナー。

わかりました、それでは。 皆さんに敬意を表します。 良いものをお持ちですね。 君たちありがとう。 バイバイ。

次はどうする？

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