南フロリダコードキャンプ2017
分散キャッシングを使用した.NETアプリケーションのスケーリング
イクバル・カーン
プレジデント＆テクノロジーエバンジェリスト
.NETアプリケーションでは、トランザクションの負荷が増大するため、データベースまたはストレージのボトルネックが発生する可能性があります。 ボトルネックを取り除き、分散キャッシングを使用して.NETアプリケーションをスケーリングする方法を学びます。 この講演の内容は次のとおりです。
- .NETアプリケーションのスケーラビリティのボトルネックの概要
- 分散キャッシングの説明と、それがパフォーマンスの問題をどのように解決するか
- アプリケーションのどこで分散キャッシングを使用できますか
- 分散キャッシュのいくつかの重要な機能
- 分散キャッシュを使用した実践例
今日は、分散キャッシュを使用して .NET アプリを拡張する方法について説明します。 この話はそれに関するものではありません NCache。 参考にさせていただきますが、 NCache しかし、主な目的は、何が問題なのか、そしてそれをキャッシュでどのように解決できるのかを説明することです。
スケーラビリティとは
わかった！ 完全を期すために、すでにご存知かと思いますが、いくつかの定義を説明します。まず、スケーラビリティとは何かを定義しましょう。 スケーラビリティは高性能ではありません。 高いパフォーマンスとは、ユーザーが XNUMX 人いる場合に非常に優れた応答時間を実現するものであり、それが高いパフォーマンスです。 スケーラビリティとは、ピーク負荷時にも同じ高いパフォーマンスを維持できるかどうかを指します。 したがって、XNUMX 人のユーザーに対してアプリケーションのパフォーマンスが高くない場合は、別の問題が発生します。 私たちがそこで解決できる以上のものがあります。
線形スケーラビリティ
次に、線形スケーラビリティとは何ですか。 線形スケーラビリティは、むしろ展開の定義です。
アプリケーションをマルチサーバー環境にデプロイする場合、たとえば、負荷分散された環境がある場合、単にサーバーを追加してトランザクション容量を増やすだけであれば、アプリケーションは線形にスケーラブルになります。 したがって、1500 つのサーバーで 500 人のユーザーがいる場合、XNUMX 番目のサーバーがあり、たとえば XNUMX 人のユーザーが得られ、さらにサーバーを追加すると、それぞれ XNUMX 人のユーザーが得られます。 仮定の話ですが、これは線形スケーラビリティです。 それを達成できれば、それが目標です。そうすれば、問題に遭遇することはなくなります。あなたは、そのためにここに来たのは、その問題に対処するためだったと確信しています。
非線形スケーラビリティ
非線形スケーラビリティは、その問題を解決するためにより高価なハードウェアやより多くのサーバーを購入できないアプリケーション アーキテクチャを持っていることの正反対です。
根本的なボトルネックがいくつかあるため、サーバーやアプリケーションを追加すると、一定期間はパフォーマンスやトランザクション容量が向上しますが、その後はサーバーを追加しても実際には速度が低下します。 したがって、非線形スケーラビリティは絶対に必要ありません。
スケーラビリティが必要なアプリケーションの種類は何ですか?
これらは通常、サーバー側のアプリケーションです。
これらは Web アプリケーション、ASP.NET、Web サービス WCF、あらゆる IoT アプリケーションのバックエンドである可能性があります。 さまざまな IoT デバイスが何らかのバックエンドと通信しています。 これはビッグ データ処理アプリケーションである可能性がありますが、ビッグ データ処理は Java アクティビティに近いものです。 Hadoop のおかげで、.NET はそれほど大規模なビッグ データ処理ではありませんが、ビッグ データ処理を行う場合は、このカテゴリに当てはまらない他のサーバー アプリケーションをスケールする必要があることは間違いありません。 つまり、大量のバッチ処理を行っている可能性があります。大企業の場合は、深夜まで、または翌営業日までに一定数の更新を取得する必要があるかもしれません。また、顧客が増えるにつれて、何百万もの顧客がいる場合は、当然、それを拡大する必要があります。
したがって、これらのバックエンド アプリケーションであっても、良い例の XNUMX つは、顧客、銀行、顧客がある口座から別の口座に資金を送金する場合であり、通常、夜間にバックエンドでバッチ モードで処理されます。 したがって、契約上、一定の期間内にそれを完了する必要があります。 したがって、これらすべてのアプリケーションにスケーラビリティがなければ、大きな問題が発生します。
スケーラビリティの問題とは何ですか?
幸いなことに、アプリケーション層には問題はありません。 これらのアプリケーションのほとんどを持っている場合、アプリケーション層にサーバーを追加しても、大きな問題はありません。 問題はデータストレージです。 また、私がデータ ストレージという言葉を使用するときは、リレーショナル データベース、つまりメインフレームのレガシー データを意味します。 そこにデータの大部分が存在し、アプリケーションと同じように拡張することができません。 今、 NoSQL databaseユースケースの XNUMX つはスケールすることですが、問題は NoSQL databaseそしてまた、 NoSQL database 私たち自身が呼んだ NosDB。 オープンソースのデータベースです。 したがって、次の制限は、 NoSQL database メインフレームやリレーショナル データベースからデータを移動する必要があるため、すべてのデータをそこに移動することはできませんが、技術的、ビジネス的などさまざまな理由で実行できない場合があります。
したがって、リレーショナル データベースは今後もメインのマスター データ ソースであり続けることになります。 大量の新しいデータを入れることができるユースケースはたくさんあります。 NoSQL databaseそうすれば、スケーラビリティのボトルネックが解決されます。 ただし、ほとんどの場合、それはデータのサブセットに対してのみ実行できます。 データの大部分は依然としてリレーショナル データベースまたは従来のメインフレーム データ ソースに保存する必要があります。 したがって、解決しなければならない問題が何であれ、このスケーラビリティに関しては、リレーショナル データベースや従来のメインフレームを使用し続けながら解決する必要があります。 そして、そこで実際に分散キャッシュがその問題を解決します。 これにより、ボトルネックをすべて解消しながら、リレーショナル データベースのメインフレーム データを引き続き使用できるようになります。
分散キャッシュの展開
これが、リレーショナル データベースのレガシー データである場合、アプリケーションとデータベースの間にキャッシュ レイヤーを置くことができる図です。
これを実行すると、頻繁に使用するデータのキャッシュが開始されます。 また、約 80% の場合、データベースにアクセスする必要さえありません。 また、キャッシュは分散キャッシュであるため、サーバーをどんどん追加でき、アプリケーション層と同じように拡張できます。 したがって、ここには少なくとも XNUMX つのキャッシュ サーバーがあり、アプリケーション層とキャッシュ層の間で XNUMX 対 XNUMX または XNUMX 対 XNUMX の比率を維持します。 この比率は、操作の性質に応じて変化する可能性があります。 たとえば、Web アプリケーションがある場合、ユーザーがクリックするたびに数百回のキャッシュ呼び出しが行われる場合、もちろん比率は変わりますが、ほとんどの場合、何百回もキャッシュ呼び出しを行うことはありません。
一般的なキャッシュ サーバーは、単なる低コストのサーバーです。 これは Web サーバー タイプの構成、デュアル CPU、クアッドコア タイプのボックスで、大量のメモリを搭載しています。 メモリが多いということは、16 ～ 32 ギガがかなり標準的であり、通常は必要のない 32 ギガ以上です。 最大 64 ギガバイトのお客様も多数いらっしゃいますが、各ボックスにさらに多くのメモリを搭載するのではなく、単にボックスを追加することをお勧めします。 その理由は、各ボックスに搭載するメモリが増えるほど、より強力なプロセッサが必要になり、その結果、ボックスが意図しないデータベースのように見え始めるためです。 これをできるだけ低コストに抑えたいと考えています。
さて、分散キャッシュは、すべてのアプリケーションに設置するインフラストラクチャです。 したがって、ほぼ一般的なインフラストラクチャであるデータベースがあるのと同じように、新しいベスト プラクティスは、メモリ内に分散キャッシュを設けることです。 インメモリとも言います NoSQL キー値ストア。 そして、それをインフラストラクチャおよびアーキテクチャ アプリケーションの一部として使用すると、常にこのストアにアクセスできるようになります。 したがって、データベースにアクセスする前にストアを確認します。 そのインフラストラクチャを構築すると、すべてのアプリケーションが自動的にスケーラブルになります。 したがって、データベースがボトルネックになることを心配する必要はありません。 そして、スケーラビリティまたはスケーリングできないことに関する最大の問題は、ビジネスが多くのアクティビティを行っているときであるということです。
あなたが航空会社で、ハワイ向けの特別プロモーションを行ったとしましょう。 水曜日にはわかりませんが、誰もがあなたのウェブサイトにログインしてチケットを購入し始めます。 それで、彼らはフライトを検索し、チケットを購入しようとしていますが、以前のXNUMX倍ほどのトラフィックがあり、突然サイトの速度が低下し、クラッシュする可能性があり、もちろんクラッシュする可能性があります、データベースが過負荷になった場合、たとえ許容範囲を超えて速度が低下したとしても、人々が離れていくだけなので、ビジネスへのコストは非常に高くなります。 したがって、ビジネスがより多くのアクティビティを実行したい、ビジネスを生み出すことができるが、アプリケーション内で処理できないという状況が決して起こらないように、スケーラビリティを計画する必要があります。 そして、適切なインフラストラクチャがあれば、そのような問題は決して起こりません。
分散キャッシュを使用する必要がある理由について説明しているところです。 どのような問題が解決されるのか、実際の使用方法について詳しく説明します。 より多くのメモリを搭載することに加えて、前述したように、通常はデュアル CPU、クアッド コア構成、それぞれ 2 ギガビット以上の XNUMX 枚のネットワーク カードを搭載します。 の場合には NCache これらは Windows ボックスです。 Redis これらは Linux ボックスであり、.NET アプリケーションを使用しているか Java アプリケーションを使用しているかに応じて異なります。 ここでは .NET に焦点を当てますが、Java にも分散キャッシュがあります。 彼らはそれらをインメモリ データ グリッドと呼び、.NET 側では分散キャッシュと呼ばれます。
分散キャッシュの一般的な使用例
わかった！ IT の観点だけでなく、より重要な開発の観点からも、ベスト プラクティス インフラストラクチャの一部として分散キャッシュが必要な理由をある程度構築できたので、次はアプリケーションを設計します。 最初に頭に浮かぶ疑問は、このキャッシュをどのように使用するかということです。 どのような使用例がありますか? どこで使用すればよいですか? つまり、どのような種類のアプリケーションを使用するかはわかっていますが、どのような種類のデータをキャッシュするのでしょうか?
したがって、主に XNUMX つのカテゴリがあります。 XNUMX つ目は誰もが理解している、アプリケーション データのキャッシュです。
アプリケーションデータのキャッシュ
つまり、アプリケーション データ キャッシュでは、データベースに存在するデータをキャッシュしているのです。これが、先ほど説明したことです。 したがって、これを行うと、実際にはデータのコピーが XNUMX つ作成されることになります。 XNUMX つはマスターへのデータベース内にあり、もう XNUMX つは一時コピーであるキャッシュ内にあります。 それが起こったとき、主な懸念は何ですか? コピーが XNUMX つあると何が問題になるでしょうか? 同期が失われる可能性があります。 実際、これが人々の心の中にある非常に大きな恐怖なのです。キャッシュを何に使うのかと尋ねると、ほとんどの人が、読み取り専用データなら大丈夫、トランザクション データには賭けられないと答えるのです。それがうまくいかなかったらどうなるからです。 私の顧客が同じ口座からそのお金を XNUMX 回引き出した場合はどうなりますか?
トランザクション データをキャッシュできない場合、参照データはデータの 80 パーセントか 70 パーセントに過ぎないため、分散キャッシュの価値はかなり低下します。 データの 80 パーセントまたは 30 ～ XNUMX パーセントは、顧客、アカウント、アクティビティ、トランザクション データ、おそらく XNUMX 秒ごと、XNUMX 分ごとに変化するデータ、キャッシュに保持できる可能性のあるデータです。とてもとても短い時間。 したがって、トランザクション データにキャッシュを使用できない場合は、実際に制限されていることになります。 したがって、優れた分散キャッシュでは、キャッシュとデータベースが常に同期していることが保証される必要があります。 そのため、キャッシュが常にデータベースと同期しているという安心感が得られれば、実質的にすべてをキャッシュできるようになり、実際に多くのゲームが表示されるようになります。
そして、それについてさらに詳しく説明します。
ASP.NET固有のキャッシュ
XNUMX 番目の使用例は、ASP.NET アプリケーションがある場合で、キャッシュできる ASP.NET 固有のものがあります。 そして、このカテゴリの良い点は、Microsoft がキャッシュをプラグインするだけのフレームワークを備えているため、ユーザー側でプログラミングを行う必要がないことです。 XNUMX つ目はセッション状態です。 すべての ASP.NET アプリケーションには、ほぼセッション状態が必要です。 これを使用しないように特別にプログラムされている人もいますが、これは良い考えではありません。 セッションを使用すると、作業がずっと楽になります。
セッションはキャッシュの候補として非常に適しています。セッションをデータベースに保存すると、データベースが BLOB を保存するように設計されていないという同じ問題に遭遇するためです。これがセッションです。 そのため、パフォーマンスが非常に遅くなり、さらに重要なことに、スケーラビリティが失われます。 アプリケーション データのキャッシュを行うのと同じ理由で、セッションもデータベースに入れないようにする必要があります。 それらを分散キャッシュに置きたいと考えています。
XNUMX つ目はビューステートです。 MVC フレームワークを使用していない場合、または古い ASP をまだ使用している場合.NET framework 次に状態を表示します。 ビュー ステートが何なのか知らない人のために説明すると、ビュー ステートとは、生成されてブラウザに送信されて戻ってくる、XNUMX バイトほどの小さい場合もあれば、数百キロバイトにもなる暗号化された文字列です。ポストバックを行うとき。 ということで、かなり高額な旅行になります。 もちろん、より多くのデータが送信されるため、パフォーマンスが低下します。 また、アプリケーションをホストする場合、これより上のパイプが無料ではないため、帯域幅のコストも増加します。 したがって、顧客が Web アプリケーションにアクセスすると、帯域幅の料金を支払うことになります。 つまり、ビューステートに、ユーザーや顧客が実行する何百万ものリクエストやトランザクションを掛けると、発生したくない追加コストが膨大になります。 したがって、これはキャッシュの非常に良い候補です。 したがって、それをサーバーにキャッシュし、小さなキーを送信するだけで、次回ポスト不良が発生したときにキーが返され、ページが実行される前にビューステートがキャッシュからフェッチされます。
XNUMX 番目は、ASP の別の部分である出力キャッシュです。.NET framework ページの出力が変わらないのであれば、なぜ次回実行する必要があるのでしょうか? ページを実行するたびに、CPU、メモリ、データベースを含むその他すべてのリソースが消費されるためです。 したがって、ページ全体またはページの一部である可能性がある最後の実行の出力を返すだけの方がはるかに優れています。 したがって、これら XNUMX つすべてに対して、プログラミングを行わずに分散キャッシュを接続するだけです。 それでは、それをお見せします。 しかし、この問題の性質はアプリケーションとは大きく異なります。
申請データにはデータのコピーが XNUMX つありましたね。 つまり、問題は同期でした。 ここでは、コピーが XNUMX つだけあり、それがメモリ内ストアに保存されています。 では、そのようなものをメモリ内ストアに保持し、それが唯一のコピーである場合、最大の懸念事項は何でしょうか。 それも！ または、サーバーがダウンした場合、そのキャッシュが失われるだけです。 したがって、これらはすべてキャッシュに保存されます。 ちょうど私が通過したのと同じ航空会社を想像してみてください。完璧な航空会社の組み合わせを見つけるのに XNUMX 分を費やし、送信を押しようとしたところでセッションが失われ、Web サーバーがダウンしたばかりなので良い経験ではありませんでした。
では、インメモリがあり、その懸念がある場合、その問題をどのように解決しますか? 冗長性があります。 データのコピーが複数あります。 したがって、優れた分散キャッシュではデータ レプリケーションを実行できる必要があります。 インテリジェントかつ高パフォーマンスの方法でデータをレプリケーションしないと、キャッシュの有用性は再び大幅に低下します。
イベントを介した実行時データ共有
XNUMX 番目の使用例は、ほとんどの人が知らないか、より一般的になり始めているものですが、この非常にスケーラブルなインメモリ インフラストラクチャを使用できるということです。 これは、イベントを介した実行時のデータ共有に使用できます。メッセージングのようなものですが、そのはるかに簡略化されたバージョンであり、単一のデータセンター タイプの環境で、複数のアプリケーションにキャッシュを使用させる方法として使用できます。データ共有の Pub/Sub タイプ。 したがって、あるアプリケーションがキャッシュに何かを入れてイベントを発生すると、そのデータに関心のあるコンシューマがそのイベントを受信し、そのデータを利用できるようになります。
したがって、それをデータベースに置いたり、MSM キューに入れたりするのではなく、独自の目的を持つ状況をタイプ化します。 キャッシュは MSM キューに代わるものではありませんが、多くの状況において、イベントベースのデータ共有を行うための非常にシンプルで、特に高速でスケーラブルなインフラストラクチャです。 したがって、実行時に相互にデータを共有する必要がある複数のアプリケーションがある必要がある場合は、これを機能、非常に重要な機能として考慮する必要があります。
ASP.NET固有のキャッシュ
ASP.NET キャッシュとそれを行う方法を簡単に説明します。 とてもとてもシンプルなので、実際に使ってみます。サンプルコードをいくつか用意しました。 たとえば、私がこの ASP.NET アプリケーションを持っているとします。 次の場合は、web.config にアクセスするだけです。 NCache そしてまた、すべてのキャッシュでほぼ同じになります。 最初に行う必要があるのは、アセンブリを追加することです。 したがって、このアセンブリはセッション状態プロバイダーです。 それで、ASP.NET framework 分散キャッシュが実装する必要があるセッション状態プロバイダー インターフェイスがあります。 NCache がそれを実装しており、これによりアセンブリがアプリケーションに読み込まれます。
したがって、それが完了したら、次に行う必要があるのは、セッション状態タグに移動することです。 実際、モードがカスタムであることを確認し、タイムアウトが希望どおりであることを確認してください。 の場合には NCache あとはこの行を入れるだけです。 他のキャッシュにも同様の種類の情報があります。 それで、あなたはただ... NCache 必要なのは、キャッシュに名前が付けられていることを確認することだけです。それが何を意味するのかを実際に説明します。 ただし、アプリケーションにこれだけの変更を加えるだけで、基本的にセッションの保存を開始できます。 したがって、アプリケーション層のすべての web.config でその変更を行い、もちろんキャッシュが存在することを確認します。 それが完了したら、実際にセッションをキャッシュに保存し始めることができます。
実践的なデモ
キャッシュ クラスターについて簡単に説明します。 たとえば、これらの Azure VM があり、キャッシュ サーバー VM と同様にデモ 1 とデモ 2 があり、デモ クライアントはアプリケーション サーバーのようなものです。 つまり、それがクライアントです。 キャッシュ クライアントはアプリケーション サーバー ボックスです。 それで、私はこれから…
キャッシュクラスターを作成する
そして、ログインしました。たとえば、デモクライアントにログインしたので、次の場合にこれを使用します。 NCache そして再びこのツールを使用します NCache マネージャー。 グラフィカルツールです。 キャッシュを XNUMX か所から設定できます。 ここに来て、新しいクラスター化キャッシュを作成すると言います。 すべてのキャッシュの名前は次のとおりです。 NCache。 そこで、キャッシュにデモ キャッシュという名前を付けます。 これらのプロパティの詳細については説明しません。レプリケーション戦略として、パーティション化されたレプリカを選択します。 そして、非同期レプリケーションを選択します。 初めてのキャッシュサーバーを作成します。 ここで二次キャッシュサーバーを作成します。 そこで、XNUMX ノードのキャッシュ クラスターを構築します。 私はただすべてを選ぶつもりです。 つまり、これはキャッシュ クラスターが形成される TCP ポートであり、ポートの競合がある場合は変更できます。 キャッシュ サーバーがキャッシュに使用するメモリの量を指定します。 私はこれを XNUMX つのギグとして捉えていますが、もちろん、あなたのギグはそれ以上のものになるでしょう。
たとえば、これが何を意味するのかを簡単に説明します。 この部分だけ行きます。
したがって、これをキャッシュ サーバーと考えてください。これには別のキャッシュ サーバーがあります。 したがって、ここにはパーティション 1 が存在します。 パーティション 1 は本質的にバケットのコレクションです。 パーティション 2 には専用のボックスが付いています。 それで、次のような場合があります NCache 約 1 個のバケットが、いくつのパーティション間で分散されます。 すべてのサーバーには 2 つのパーティションがあり、すべてのサーバーでそのパーティションが別のサーバーにレプリケートされます。 したがって、サーバーが 3 台ある場合は、パーティション XNUMX がここにバックアップされていることがわかります。 パーティション XNUMX がここにバックアップされます。 パーティション XNUMX がここにバックアップされます。 次の場合、レプリカはアクティブになりません。 NCache。 これらは、メイン パーティションがダウンした場合にのみアクティブになります。
したがって、ここで指定しているのはパーティションのサイズです。 したがって、パーティション レプリカの場合、ここでたとえば 1 ギガを指定すると、実際にはパーティションに 1 ギガ、レプリカに 1 ギガが使用されます。 ということで、合計2公演。 したがって、たとえば 16 ギガのメモリがある場合、オペレーティング システムやその他のプロセス用に約 16 ギガまたは 13 ギガを残し、残りを使用できるようにします。 したがって、32 ギガの場合は 29 ギガを簡単に使用できます。 それで、半分と半分をしてください。 つまり、これは 14 ギガのパーティション サイズで、もちろん XNUMX ギガにすることもできます。また、XNUMX ギガを省略すると、XNUMX ギガ半、XNUMX ギガのパーティション サイズになります。 また、より多くのストレージが必要な場合は、管理が容易になるため、単にサーバーを追加するためにメモリを追加するのではなく、より多くのストレージが必要になります。 これにより、物事のスケーラビリティが大幅に向上します。 それでは、ここで次に進みます。
次は私の立ち退き方針です。 それらの詳細については説明しません。 そして、クライアント ノードを追加します。 それが完了したら、キャッシュを開始します。 これからキャッシュを開始します。この部分をお見せしたかったのは、それが残りの話の意味になるからです。 したがって、これら XNUMX つのキャッシュ ノードが起動されます。
ストレスのシミュレーションとキャッシュ統計の監視
そこで、たくさんの監視ツールを開き、ストレス テスト ツールと呼ばれるこのツールを実際に実行してみます。
コマンドラインです。 これは、実際にキャッシュ上でアクティビティを開始するコンソールです。 これで、アプリケーションをシミュレートしているようです。 したがって、これを見ると、アプリケーションはセッションをキャッシュに入れており、すべてのセッションは 177 つのオブジェクトです。 それで、あなたは追加しています。 したがって、キャッシュ数は 172 になり、このボックスでは 35 と XNUMX になります。つまり、ほぼ均等になるため、別の場所にバックアップしたほうがよいでしょう…
これはここにバックアップされています、これはここにバックアップされています。 したがって、ご覧のとおり、レプリケーションは自動的に行われます。 アプリケーションでは心配する必要はありません。 やったことは、このクラスターを作成することだけで、アプリケーション層では Web.config を変更するだけで、残りはすべて自動的に行われます。 もちろん、これを監視することもできますが、キャッシュには名前が付けられています。 したがって、この場合はキャッシュにデモ キャッシュという名前を付けました。 名前を付けることができ、実際には複数のキャッシュを持つことができます。 私たちが顧客で見た最も一般的な構成は、XNUMX つのキャッシュがあるというものです。 XNUMX つのキャッシュは、オブジェクト キャッシュと呼ばれます。 つまり、これがメインのトランザクション キャッシュになります。 XNUMX つのキャッシュはセッション キャッシュと呼ばれます。 したがって、すべてのセッションがそのキャッシュに入れられます。 XNUMX 番目のキャッシュは参照キャッシュと呼ばれます。 そのため、より多くの参照データを参照キャッシュに入れることになります。
また、トランザクション データと参照データに対して別のキャッシュを作成する理由は、参照データの場合、キャッシュするクライアント キャッシュと呼ばれるこの機能を使用するためです。
クライアントキャッシュによるパフォーマンスのさらなる向上
実際に飛び回っているので、混乱していたらご容赦ください。 参考データをお持ちでしたら、実はもう一つ後戻りさせていただきます。 分散キャッシュを使用する前は、ASP.NET キャッシュ オブジェクトを使用していました。 ASP.NET キャッシュ オブジェクトはローカル InProc キャッシュでした。 申請プロセス内で、超高速でしたね。 自分のヒープにデータを保存している場合、そのパフォーマンスに匹敵するものはありません。 分散キャッシュに入るとすぐに違います。自動プロセス キャッシュです。 人々はあなたのパフォーマンスが実際に低下していることに気づいていません。
最初は当惑して、「パフォーマンスが向上するはずだったのに、ASP.NET キャッシュのせいでパフォーマンスが低下した。オブジェクトをシリアル化する必要があるため、今はずっと遅くなった」と言う顧客がたくさんいます。 大きなオブジェクトがある場合、シリアル化は非常に大きなコストであり、特定のキャッシュとは関係なく発生するコストです。 また、プロセス キャッシュの外に出るとすぐに、パフォーマンスはローカルの InProc キャッシュよりも大幅に遅くなります。 ただし、データベースよりも高速です。 データベースよりもほぼ 10 倍高速ですが、InProc キャッシュよりはほぼ 10 倍遅いと言えるでしょう。
つまり、人々はその InProc キャッシュのメリットを得ようとするのです。 それほど頻繁に変更されないデータには、クライアント キャッシュと呼ばれる機能があります。 特に Java 側ではこれをニアキャッシュと呼ぶ人もいます。
この機能は本質的にはローカル キャッシュです。 これは、InProc ASP.NET キャッシュのようなものです。 これはアプリケーション プロセス内に存在するか、InProc ほど高速ではないものの、キャッシュ層に移動するよりは高速な単なるローカル OutProc キャッシュにすることもできます。 ただし、違いは、このキャッシュがキャッシュ層について認識していることです。 このクライアント キャッシュはキャッシュの上にあるキャッシュであり、同期されます。 したがって、先ほど説明した最大の問題、つまりキャッシュとデータベースの同期をどのように維持するかについて心配する必要はありません。 これで、データのコピーが XNUMX つできました。 XNUMX つはデータベースに、XNUMX つはキャッシュ層に、もう XNUMX つはクライアント キャッシュにあります。 もちろん、クライアント キャッシュはキャッシュ層のサブセットです。 キャッシュ層はデータベースのサブセットです。 しかし、それが何であれ、同期する必要があります。 したがって、クライアント キャッシュを持つことにより、これは再び InProc となり、シリアル化された形式ではなくオブジェクト形式で内容を保持します。 それをヒープ上に保持します。 したがって、ローカル InProc ASP.NET キャッシュ オブジェクトと同じ利点が得られますが、このクライアント キャッシュは小さなサブセットになるため、スケーラビリティの他のすべての利点も得られます。 どのくらいの大きさにするかを指定できます。 その閾値を超えることは決してありません。
したがって、各クライアント キャッシュに 32 ギガがあり、キャッシュ層に XNUMX ギガがあり、データベースにはおそらくそれよりもはるかに多くのギガが存在する可能性があります。 とにかく、移動期間なのでライブを XNUMX 回行うだけでも、ですよね？ だから、あなたが何をしていても、あなたは続けます。 一部のデータは長期間保持され、一部のデータはおそらく数分間保持されますが、その間は何百回も呼び出しを行うため、キャッシュ層に移動する必要がなく、もちろんキャッシュ層に移動する必要もありません。データベースに行きます。 したがって、クライアント キャッシュを有効にすると、非常に強力な機能になります。 これを行うと、より多くの参照データが得られます。 したがって、次の場合には、 NCacheでは、構成変更を通じてクライアント キャッシュを指定できます。 特別なプログラミングはありませんが、特定のキャッシュにマップされます。 そのため、当社のお客様は通常 XNUMX つのキャッシュを持っています。 オブジェクト キャッシュ、セッション キャッシュ、参照キャッシュ。 参照キャッシュにはクライアント キャッシュが使用されますが、他の XNUMX つは使用されません。
クライアントキャッシュの設定が簡単
では、なぜセッション キャッシュを使用してクライアント キャッシュを実行しないのでしょうか? 実際にはパフォーマンスが低下するためです。 その理由は、より多くの読み取りと書き込みを実行する場合にのみ改善されるためです。 なぜなら、書き込みの場合はどうなるでしょうか? ここに書き込みを行い、次にここに書き込みを行い、次にデータベースに書き込みを行います。 つまり、XNUMX か所で書き込みを行っていることになります。 したがって、さらに書き込みを行う必要がある場合は、何の価値も追加されません。 コピーを更新してから、これのみを更新すると、他のすべてのクライアント キャッシュに自身を更新するように通知されます。 これは更新の遅延です。XNUMX ～ XNUMX ミリ秒の遅延というわけではありませんが、クライアント キャッシュの場合は依然として更新の遅延です。 クライアント キャッシュ間のレプリケーションはありません。 クライアント キャッシュは、それ自身をキャッシュ層とのみ同期し、キャッシュ層は更新を他のクライアント キャッシュに伝播します。 他のキャッシュにそのデータがある場合のみ。 クライアント キャッシュの場合、各クライアント キャッシュには使用パターンに基づいて異なるデータが含まれるためです。
クライアントキャッシュを使用する場所
それで、話を戻しましょう。参照データの場合、すべてのクライアント キャッシュには独自のデータ セットがあります。つまり、1 ～ 1000、500 ～ 1500 などとします。 したがって、それぞれの間にいくつかの重複がありますが、同一のコピーではありません。 共通しているのは、それらはすべてこのキャッシュのサブセットであるということです。 したがって、このキャッシュ内の項目番号 (たとえば 700) を更新すると、キャッシュ内で更新が行われ、キャッシュは他のどのクライアント キャッシュにその項目があるのかを認識し、それらの項目はすぐに他のキャッシュで更新されます。 ただし、全員がそれを持っている場合に限ります。 したがって、クライアント キャッシュの場合は同一のコピーではないため、実際にはレプリケートされません。 セッションの場合、私が実際に説明しようとしていたのは、セッションの場合、クライアント キャッシュとクラスター化キャッシュの XNUMX か所を更新する必要があるということですが、セッションでは読み取りと書き込みが XNUMX 回ずつ行われるため、追加の価値はありません。 したがって、Web リクエスト時には、書き込みを行ったページの最後に読み取りを行います。
したがって、書き込みは XNUMX か所で行う必要があり、読み取りはクライアント キャッシュで行われることになります。 したがって、クライアント キャッシュをセッションやその他の書き込み集中型の操作で使用すると、実際にはパフォーマンスが低下しますが、読み取り集中型の操作に使用すると、パフォーマンスが大幅に向上します。 それは意味がありましたか？
したがって、分散キャッシュの最大の価値、つまり高速かつ最大のものはセッション状態です。 ほぼすべてのアプリケーションにそれがあります。 XNUMX ノードのキャッシュ クラスターを作成したところ、どれくらいの時間がかかるかがわかりました。たとえば、 NCache。 したがって、キャッシュ クラスターを作成するのは非常に簡単です。もちろん、テストなどを行う必要があります。 でも、本当に簡単です。 エンジニアリングの努力は必要ありません。 エンジニアリングの労力がなければ、スケジュールへの対処がはるかに簡単になります。 健全性テストを行うだけで済みます。 分散キャッシュの使用を開始する場合は、最初のステップとしてセッション状態に分散キャッシュを使用してから、すぐに説明するオブジェクト キャッシュに飛び込むことを強くお勧めします。
アプリケーションデータのキャッシュ
以上、セッション キャッシュについて説明しました。 早速、アプリケーション データのキャッシュについて見ていきましょう。 典型的なものは次のとおりです NCache API は、ASP.NET キャッシュによく似たもので、接続があることがわかります。
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();Employee employee = (Employee) cache.Get("Employee:1000");
Employee employee = (Employee) cache["Employee:1000"];
bool isPresent = cache.Contains("Employee:1000");cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);
cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);
cache["Employee:1000"] = employee;
Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");したがって、名前に基づいてキャッシュに接続し、その名前でキャッシュを作成するだけです。 だからこそ、それが何を意味するのかを理解してもらうために、私はそのデモンストレーションを行ったのです。 そして、このキャッシュ ハンドルは、データベース ハンドルを保存するのと同じように保存するものです。 そして、そのキャッシュ ハンドルを使用して Cache.Get を実行します。 すべての Get、すべての操作にはキーがあります。 次の場合、キーは文字列です。 NCache 次に、そのキーを使用して行う内容に基づいてキーをフォーマットします。 したがって、個々のオブジェクトの場合は、クラス名、場合によっては属性名と値のみを指定することをお勧めします。 そして、それを手に入れることができます。 つまり、Get と Get.Contains、Add、AddAsync があります。 非同期とは、待機しないことを意味します。
さて、何が起こるかというと、その下でクライアント側で逆シリアル化が行われます。 それで、クライアントは Cache.Add を実行します。たとえば、オブジェクトを与えるとします。それは従業員オブジェクトで、標準の .NET シリアル化またはカスタムのいずれかに基づいてシリアル化されます。 NCache 連載化。 そして、それをバイト配列に作成し、そのバイト配列をキャッシュに送信します。 NCache 特定の属性にインデックスを付ける必要がある場合があるため、それ以上のことを行います。 それらの値を抽出します。 はい、そうなります。 それは。 それはすぐに。 うん！ キャッシュするすべてのオブジェクトはシリアル化を行う必要があります。
したがって、アプリケーションをオンにするとすぐに例外がスローされます。 ASP.NET キャッシュ オブジェクトを使用している場合は、シリアル化する必要はありません。 したがって、ほとんどすべてをキャッシュできますが、多くの場合、独自のオブジェクトはシリアル化が簡単かもしれませんが、サードパーティを使用している可能性があります。 たとえば、以前はデータ テーブル オブジェクトがシリアル化されていませんでしたが、現在はシリアル化されているとします。 したがって、シリアル化できないサードパーティのオブジェクトを使用している場合は、制御することができません。 したがって、分散キャッシュを使用する場合は、それらを捕捉することはできません。 の場合には NCache、これらのオブジェクトを識別できる独自のカスタムシリアル化があります。 NCache 次に、実行時にシリアル化コードが作成され、メモリ内でコンパイルされます。 したがって、シリアル化できないオブジェクトも使用できるようになります。 しかし、この連載はすぐに行われます。 したがって、適切なシリアル化を使用していない場合、アプリケーションは動作しません。
Async は基本的に、キャッシュが更新されるまで待機しないことを示します。 それで、私は続けることができます。 キャッシュがこれを追加すると信じています。 したがって、データの整合性の問題で更新が失敗する可能性があるデータベースのロックは解除されません。 キャッシュにはデータの整合性の問題はありません。 クラッシュが発生した場合にのみ失敗します。 メモリがなくなったり、何か他のことが起こったとき。 したがって、追加するものはすべてキャッシュに追加される可能性が高いため、ほぼ安心できます。 したがって、Async はさらに強力な機能を提供します。 ご覧のとおり、API は非常に単純です。
キャッシュを最新に保つ
では、アプリケーション データのキャッシュを行う場合、キャッシュを最新の状態に保つにはどうすればよいでしょうか? これは本当に本当に重要です。 キャッシュにはさまざまな方法があります。
時間ベースの有効期限の使用
有効期限。ほぼすべてのキャッシュが有効期限をサポートします。 すべてのアイテムに対してこの指定を取得する絶対的な有効期限があります。これは、キャッシュ内に保持されるのに快適だと感じる期間です。これは、15 秒から、数時間、数日、数週間までの範囲です。 そして、それはアプリケーションデータのキャッシュのためです。 キャッシュとデータベースを同期するためのものではない、スライディング有効期限と呼ばれる別の有効期限があります。 掃除用です。 それで、その ASP.NET、私たちが話したすべての一時データ、では、そのデータを使い終わったらどうなるでしょうか? 掃除について心配する必要はありません。 したがって、スライド式の有効期限を指定して、このデータをこの期間誰も使用しない場合、たとえばセッションが 20 分間の場合、その 20 分間誰もセッションを使用しない場合は、キャッシュからデータを削除することができます。 ということで、これはもう大掃除です。
有効期限切れのリスクは何ですか? 有効期限は実際には推測です。 XNUMX分もあれば大丈夫だと思いますが、特に他のアプリケーションや他のプロセスがデータベースを更新している場合、その時間内に誰もデータベース内のデータを更新しないという保証はありません。 したがって、有効期限は限られた使用例でのみ有効です。
データベースの依存関係の使用
もう XNUMX つの非常に重要な機能は、データベース内で予期しない、または予測できない更新が行われる可能性があることです。 その場合、キャッシュにはデータベースと同期する機能が必要です。 したがって、キャッシュはデータベースについて認識している必要があります。 これはデータベースのクライアントとなり、データベースの変更を監視する必要があります。 ADO.NET には SQL 依存関係と呼ばれる機能があります。 誰かそれを見たことがありますか？
つまり、SQL 依存関係とは何ですか NCache SQL サーバーまたは Oracle データベースのクライアントになるために使用されます。 したがって、SQL サーバーの場合は、SQL 依存関係である SQL サーバーの ADO.NET 機能を使用できます。 NCache データベースからイベントを取得するために使用します。 キャッシュ、 NCache データベースのクライアントになります。 イベントを受信し、それに基づいて独自の処理を実行します。 イベントがない場合もあります。 したがって、db2 または MySQL を使用していた場合、それらにはイベントが存在しないとします。 したがって、キャッシュはポーリングを実行できる必要があります。 NCache ポーリングベースもサポートしています。 したがって、同じことを行い、この項目をキャッシュにキャッシュし、これがこのテーブルのこの行にマップされると言いました。 NCache はポーリングを実行し、データが変更された場合は、再度キャッシュから削除するか、新しいコピーをリロードします。 しかし、この機能により、非常に快適になります。
繰り返しますが、私が話していたのと同じことは、キャッシュが常にデータベースと同期していることを確認する必要があるということです。 有効期限は、ユースケースのごく一部の場合にのみ十分です。
したがって、自動リロードを行わないとキャッシュミスが発生します。 したがって、SQL 依存関係が発生すると、それが削除されます。 NCache キャッシュから項目を削除します。 したがって、アプリケーションがそれを必要とする場合、キャッシュミスとなり、データベースから新しいコピーを取得する必要があります。 多くの電子商取引アプリケーションで頻繁にデータが読み取られるため、データベースの負荷を増加させる必要がないためにキャッシュ ミスが発生したくない場合は、実際には SQL 依存関係を使用します。この機能はリードスルーと呼ばれます。
実際には、いくつかのコードをお見せする必要があります。そうしないと、非常に退屈になってしまいます。 それでは、早速お見せしましょう。 したがって、非常に単純なコンソール アプリケーションを作成しました。 の場合には NCache、ここにいくつかのアセンブリを追加するだけです。 それで、あります NCache。ランタイムと NCache。ウェブ。 次に、これら XNUMX つの名前空間を指定し、キャッシュに接続してキャッシュ ハンドルを取得し、オブジェクトを作成して Cache.Add を実行します。 そして、キーを指定します。 これは良いキーではありません。 変更するつもりでしたが、キーには実際の値が含まれているはずです。 したがって、Cache.Add を実行し、オブジェクトを指定します。
この場合、絶対有効期限として 10 分も使用しています。 したがって、絶対有効期限を指定するだけです。 これをキャッシュに追加するのはこれだけです。 次回必要になったときは、Cache.Get を実行して同じキーを指定するだけで、オブジェクトが返されます。 絶対的な有効期限については非常に簡単です。 スライド式有効期限についても同じことができます。 ただし、絶対値を指定する代わりに、20 分や XNUMX 分などの間隔を指定する必要があります。 SQL の依存関係について説明したいと思います。 それはどのようなものか。 そこには！ したがって、同じ種類のアプリケーションです。 ここでこれら XNUMX つを追加し、名前空間を指定するだけで済みます。その後、それらをキャッシュに追加するときに、SQL 依存関係を指定します。
その定義に戻ってみましょう。 したがって、これをここでキャッシュに追加します。 それで、前回お見せした鍵を持っています。 ここでは、オブジェクトを追加する代わりに、Cache 項目を追加します。 それは NCache 構造。 したがって、実際のオブジェクトを保存し、SQL 依存関係も保存します。 それで、 NCache キャッシュ依存関係オブジェクトがあります。 そこで、新しい SQL キャッシュの依存関係を作成します。 それは NCache SQL サーバーの SQL 依存関係に内部的にマップされるクラス。 したがって、接続文字列を渡します。接続文字列は SQL サーバー接続文字列であり、それに SQL ステートメントを渡します。 したがって、ここで私の場合は、製品 ID が私の値である select this を指定しました。 したがって、それを製品テーブルの XNUMX 行にマッピングするだけです。 そして、これだけ特定して、私は今言いました NCache SQL サーバーのクライアントになります。 また、データベース内でこの行が変更された場合は、この項目を削除します。
したがって、SQL ステートメントが何であるかによって異なります。 したがって、シーケンス メソッドに行が XNUMX つだけ含まれている場合は、XNUMX 行だけを実行するようにマップされ、そのようになります。 通常、これでは結合を実行できず、これが ADO.NET の SQL 依存関係機能の制限ですが、単一テーブルの場合はこれを簡単に実行できます。 それで、それがあなたが行う方法です...
SQL サーバーには SQL ブローカーと呼ばれるものがあります。 したがって、実際には、SQL サーバー側にデータ セットまたはデータ構造を作成して、これらのデータ セットを監視します。 したがって、作成するすべての SQL 依存関係により、SQL サーバーはデータ セットを監視するためのデータ構造を作成します。 そして、それに基づいて SQL 通知が送信されます。
したがって、これは SQL サーバー側で構成する必要があります。これはセキュリティの問題でもあるため、DB が SQL サーバーの構成に関与する必要がありますが、非常に簡単です。 つまり、サーバー上ではプログラミングなどは必要なく、構成だけが必要です。 すべての処理はクライアント側で処理されます。
リードスルーとライトスルー
わかった！ これで SQL の依存関係が完了しました。 このアイテムをキャッシュから削除したくない場合は、リードスルーを通じてリロードできることを示したかったのです。 したがって、リードスルーも非常に強力な機能です。
リードスルーはサーバー側のコードです。 実際には、リードスルーはキャッシュ クラスター上で実行されるコードです。 したがって、実際にコードを登録すると、そのコードがキャッシュ クラスター上で実行されます。 ビといいます NCache。 そして、既読スルーの価値…まず既読スルーがどのようなものかを示して、その価値が何であるかを説明します。つまり、なぜ既読スルーをしたいのかということです。 典型的な読み上げは次のようになります。 IReadThrough インターフェイスです。 データ ソースに接続できるように InIt を実行します。 もちろん、破棄を実行すると、ソースからのロードが行われます。 キーを渡し、アイテムをキャッシュして返すことを期待します。 したがって、キャッシュ項目にはオブジェクトと、その中に有効期限やその他のものを指定できるその他のものが含まれています。 非常にシンプルなインターフェース。
これを呼び出すのは、 NCache したがって、このインターフェイスを実装し、アセンブリを登録します。 の場合には NCache、アセンブリをキャッシュに登録し、Cache.Get を実行し、その項目がキャッシュに存在しない場合、キャッシュは実際には、 NCache は、リードスルーを呼び出してデータ ソースから取得します。 データ ソースはデータベース、メインフレーム、その他のデータ ソースである可能性があります。 したがって、リードスルーを行うことで、アプリケーションが認識するデータをキャッシュに常に保持することができます。 つまり、それが利点の XNUMX つです。
XNUMX 番目の利点はリロードです。つまり、実際にリードスルーを組み合わせることができます。 そのため、アイテムがキャッシュから削除される予定で、とにかく再度リロードするだけなので削除したくない場合は、有効期限切れやデータベース同期時に行うことができます。 では、そのようにしてキャッシュにリロードさせてみてはいかがでしょうか。考えてみてください。キャッシュには何百万ものアイテムがあり、それらは常に期限切れになります。 そのように設定されているからです。 また、電子商取引と非常にトラフィックの多いアプリケーションがあり、何かの有効期限が切れるたびに、それに対する大量の同時リクエストが発生します。 それらはすべてデータベースに保存されます。 そのため、データベース トラフィックが理由もなく突然増加しました。たとえそれがキャッシュに必要でなかったとしてもです。
したがって、これが常に発生し続けるため、キャッシュがあるにもかかわらず、データベース トラフィックが大幅に急増することになります。 つまり、リロードするということは、キャッシュから削除されないことを意味します。 ただ更新されるだけです。 したがって、アプリケーションがデータベースにアクセスされることはありません。 彼らは、あなたがそれを更新するまで、古いコピーを取得し続けます。 そこで、キャッシュがあったにもかかわらず、期限切れやデータベースの同期によってデータベース トラフィックが大量に急増していた問題を、突然削除するか、対処することになりました。 したがって、リードスルーを通じてキャッシュにこれをリロードさせることで、本当に非常に強力になります。
もちろん、リードスルーのもう XNUMX つの利点は、データベース アクセスの多くがキャッシュによって行われるようになるため、アプリケーション層を一元化し、簡素化できることです。 したがって、同じデータにアクセスする複数のアプリケーションがある場合、キャッシュ層内でデータ アクセスを真に一元化できます。 もちろん、すべてのデータに対してこれを実行することはできませんが、多くのデータに対しては実行できます。
ライトスルーはリードスルーと同じように機能します。 ライトスルーに行きましょう。 同じように動作します。 ライトスルー プロバイダー (これも InIt) が破棄され、ロードの代わりにデータ ソースへの書き込みが行われ、別の種類の一括書き込みが行われます。 ライトスルーの利点の XNUMX つは、すべてを一元化できるというリードスルーと同じです。 XNUMX 番目の利点は、ライトビハインドを実行できることです。これは、前述したように、データベースよりも XNUMX 倍高速にキャッシュを更新し、キャッシュにデータベースの更新を依頼することです。 また、ライトビハインドは基本的にライトスルーと同じですが、非同期方式で実行されます。 作成されて処理されるキューです。 そのキューは次の場合にも複製されます。 NCache。 したがって、いずれかのサーバーがダウンしても、更新が失われることはありません。 しかし、ライトビハインドによってアプリケーションは実際に高速化されます。つまり、すべての読み取りをキャッシュすることですでに高速化されているからです。 したがって、読み取りの約 70 ～ 80% が現在、またはトランザクションがキャッシュに送られることになります。 書き込みも高速化してみませんか? 後書き方式で実行できる場合、非同期書き込みを行う余裕がある場合。 データの機密性が高くて余裕がない場合は、ライトスルーを実行すると、コードの一元化という最初のメリットしか得られません。 パフォーマンスが高速になるという XNUMX 番目の利点は、非同期を実行できる場合にのみ得られます。
まとめ
全体的な考え方は、キャッシュを開始するときに、ここでの単なるキー値であるキャッシュについて考えないでください、つまり、これの全体的な目的は、まず、分散キャッシュが本当に必要であることを理解してもらうことでした。インフラストラクチャとアプリケーションのアーキテクチャ。 アプリケーションを拡張したい場合は、使用するキャッシュ製品に関係なく、これを組み込む必要があります。つまり、それを持っている必要があります。 現在、.NET ユーザーにとって市場にあるオプションは次のとおりです。 NCache これはオープンソースであり、商用でもあります。 あるよ Redis Microsoft は少なくとも Azure 上で利用できるようにしました。 Azure ではマネージド キャッシュ サービスですが、それ以外ではインストールする必要があり、オープンソースのサポートされていないバージョンを使用しない限り、主に Linux にインストールされます。 Java 側には、キャッシュに関するオプションがさらにたくさんあります。 それで、それがまず第一でした。
理解する必要がある XNUMX 番目の目標は、単純なキー値ではありません。 あらゆる種類のデータをキャッシュし、あらゆる種類の状況に対処できるようにすることで、真のメリットが得られるようにしたいと考えています。 そして、実際には時間がなくなってしまったので、他の部分にさえ触れていません。たとえば、実行時のデータ共有をどのように行うか、アーキテクチャ上で確認すべき点は何かなどです。キャッシュは常に動的であるため、設定を行うことができます。 それはデータセンターの一部であり、実稼働環境の一部です。 したがって、実行時に変更を加えられないキャッシュは、選択するのに適したキャッシュではありません。 そうなると、ダウンタイムがたくさん発生することになります。弊社のお客様の中には、ダウンタイムを年に XNUMX 回設定しているお客様もいらっしゃいます。 したがって、非常に高い可用性を備えているため、顧客の中にはそれさえもてない人もいます。
彼らは、キャッシュ自体をダウンタイムなしで新しいバージョンにアップグレードしたいと考えています。 つまり、それはビジネス要件によって異なります。 しかし、現在では多くの人が複数のデータセンターを所有しているため、これらすべてを考慮する必要があります。 少なくとも DR の目的で、さらに地理的な負荷分散の目的で、それがある場合は、データベースがレプリケートされることを期待しますよね?
では、なぜキャッシュが複数のデータセンターをサポートできないのでしょうか? なぜなら、キャッシュでできることが少なくなればなるほど、実行しなければならない作業が増えるからです。 それが肝心なことです。 アプリケーションのニーズは変わらないため、キャッシュはそれに対応する必要があります。 ですから、これらすべてを心に留めておいてください。
それで、次の比較があります NCache & Redis.
どちらもオープンソースです。 NCache Enterprise Edition もあります。 したがって、基本的に .NET の場合は、 NCache とてもうまくフィットします。 の中に NCache, N は .NET の略で、要するに、私たちが .NET にどれだけコミットしているかを意味します。