ボストンコードキャンプ27

分散キャッシングを使用した.NETアプリケーションのスケーリング

イクバル・カーン
プレジデント＆テクノロジーエバンジェリスト

.NETアプリケーションでは、トランザクションの負荷が増大するため、データベースまたはストレージのボトルネックが発生する可能性があります。 ボトルネックを取り除き、分散キャッシングを使用して.NETアプリケーションをスケーリングする方法を学びます。 この講演の内容は次のとおりです。

• .NETアプリケーションのスケーラビリティのボトルネックの概要
• 分散キャッシングの説明と、それがパフォーマンスの問題をどのように解決するか
• アプリケーションのどこで分散キャッシングを使用できますか
• 分散キャッシュのいくつかの重要な機能
• 分散キャッシュを使用した実践例

私の名前はイクバル・カーンです。 私はテクノロジーエバンジェリストです Alachisoft。 当社はサンフランシスコ ベイエリアに拠点を置くソフトウェア会社です。 私は個人的にタンパに拠点を置いていますが、次の製品があります。 NCache。 .NET の分散キャッシュです。 今日は、分散キャッシュを使用して .NET アプリケーションを拡張する方法について説明します。 これは話ではありません NCache、スケーラビリティの問題と、それを分散キャッシュで解決する方法についてです。 あなたは何をするべきか？ どのように使用すればよいですか? ベストプラクティスにはどのようなものがありますか? 何か質問がございましたら、遠慮なく止めていただければと思います。 よりインタラクティブな議論ができるように。 始めましょう。

スケーラビリティとは何ですか？

それでは、いくつかの定義を説明しましょう。 5,000 つ目は拡張性です。 スケーラビリティはパフォーマンスではありません。 50,000 人のユーザーに対して非常に優れたパフォーマンスを発揮するアプリケーションがあるかもしれませんが、それが 500,000 人、5 人、または XNUMX 人のユーザーに対しても同じパフォーマンスを発揮する場合にのみ拡張可能です。 したがって、スケーラビリティはピーク負荷下でも非常に高いパフォーマンスを発揮します。 アプリケーションが XNUMX ユーザーに対してうまく動作しない場合は、他のトークに参加する必要があります。

線形スケーラビリティと非線形スケーラビリティ

線形スケーラビリティは、アプリケーション展開の概念に近いものです。 アプリケーションをデプロイするときに、デプロイメントにさらにサーバーを追加でき、さらにサーバーを追加することでトランザクション容量を線形的に増加できる場合、アプリケーション アーキテクチャは線形にスケーラブルになります。それ以外の場合は、非線形にスケーラブルになります。

これが意味するのは、一定の数のサーバーを追加した後、さらにサーバーを追加すると問題がさらに悪化するということです。つまり、サーバーを追加するだけでは解決できないボトルネックがアプリケーションのどこかに存在することを意味します。 非線形スケーラビリティは絶対に必要ではなく、アプリケーションには線形スケーラビリティが絶対に必要です。

スケーラビリティが必要なアプリケーションの種類は何ですか?

スケーラビリティが必要なアプリケーションの種類は何ですか? これらは ASP.NET アプリケーションです。 これらは Web サービスです。 これらは IoT バックエンドであり、やはりほとんどが Web サービスです。 これらはビッグ データ処理アプリケーションであり、.NET ではそれほど一般的ではなく、Java で実行されるアプリケーションが増えていますが、それでもなお、これらはスケーラビリティやその他のサーバー アプリケーションも必要とするアプリケーションです。 たとえば、あなたは何百万もの顧客を持つ大手銀行で働いているかもしれませんが、顧客から住所変更の電話がかかってきたり、新しいカードの発行を望んでいたり、あるカードから資金を送金したりしているかもしれません。これらのトランザクションはすべて、コンプライアンスの目的であらかじめ決められた時間枠内に処理される必要があります。 したがって、ここでもまた、時間枠内に数百万のリクエストを処理する必要がありますが、これは XNUMX 台のコンピューターからは処理できない可能性があります。 したがって、その場合でもスケーリングできる必要があります。 したがって、スケーラビリティが必要なこれらのアプリケーションがある場合、これは正しい話です。

スケーラビリティの問題

そこで、スケーラビリティの問題も定義しましょう。 スケーラビリティの問題とは何ですか? アプリケーション層は直線的に拡張されます。 Web アプリケーション ASP.NET または Web サービスがある場合があります。 その前にロード バランサーがあり、トラフィックをすべてのサーバーに均等にルーティングします。 さらにサーバーを追加しても問題ありません。 すべてが完璧にうまく機能します。 以前、データベースがボトルネックになりつつあることについて誰かと話していましたが、彼らは私の意見に同意しませんでした。 ですから、これはその議論をする良い機会だと思います。

したがって、データベース自体は超高速に実行されます。 性能的には問題ありません。 データベースは非常に賢く、独自のサーバーで多くのメモリ内キャッシュを実行しますが、スケーラビリティは設計上達成できないものです。なぜなら、たとえば、ここで 10、20、30、40、50 台のサーバーを追加できるからです。層。 ユーザー数が非常に多いため、アプリケーション層に 50 台以上のサーバーを導入しているお客様もいらっしゃいます。 あなたが大手銀行または航空会社であると想像してください。 あなたのウェブサイトには何百万人もの人々がアクセスしています。 ハワイ行きの航空券か何かについて、この大規模なプロモーションを行いました。 みんな来て、フライト検索をして、チケットを買いたいと思っています。 ここでさらにサーバーを追加しても問題ありません。 データベースは超高速に実行され、ソフトウェアも優れていますが、設計上、データベースは分散データベースではありません。 一か所に保管されています。 おそらく、アクティブ - アクティブ、アクティブ - パッシブの XNUMX つのサーバーからなるクラスターを構成することもできますが、実際には、それらはスケーラビリティよりも信頼性を重視しています。

したがって、実際にここに 10 台のサーバーを置くことはできません。 NoSQL database、それならできます。 しかし、リレーショナル データベースの場合は、SQL サーバー、Oracle、Db2、MySQL など、どれも超高速です。 メモリ内で多くの処理を実行している可能性もありますが、ますますスケールする必要があるため、ボトルネックになります。 基本的に、同時ユーザー数が 1,000 人以上になると、パフォーマンスの問題に気づき始め、5,000 人から 5,000 人、10,000 人から 1000 人へと増加するにつれて、より多くの問題が発生し始めます。 つまり、私たちが見てきたのは、ユーザーが 5,000 人いる場合はキャッシュを使用する場合と使用しない場合がありますが、ユーザーが 10,000、15,000、XNUMX 人に増加するにつれて、間違いなく苦痛を感じ、最終的にはこのようなスケーラビリティに行き着くということです。ボトルネック。

現在、リレーショナル データベースやメインフレームのレガシー データベースにはこの問題があります。 それは理由の一つです NoSQL databaseの運動が始まったのもそのためでした。 ただし、他にも利点があり、製品があります。 参考までに早速来させていただきます。 したがって、キャッシュ製品もありますが、 NoSQL 文書データベース。 ドキュメント DB と同様に、オープンソース データベースです。

そう、 NoSQL database スケーラビリティの問題はまったくありません。 しかし、それが常に答えであるとは限りません。 何故ですか？ なぜなら、それが答えになるためには、 NoSQL database すべてのデータをそこに保存してほしいと考えています。 したがって、データを NoSQL database これは、少なくともデータのその部分に対してリレーショナル データベースの使用を中止することを意味します。問題は解決されません。 したがって、多くの場合、データの一部や大部分を、 NoSQL database それが原動力となっているのです NoSQL 動き。 しかし、リレーショナル データベースやレガシー メインフレーム データは、今後も存続します。 技術的な理由とビジネス的な理由の両方から、それらはただ望むだけで済むものではありません。 したがって、解決しなければならないスケーラビリティの問題が何であれ、リレーショナル データベースを使用して解決する必要があります。 それが理由です NoSQL database 必ずしも答えになるわけではありません。

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

そして、その問題を解決する方法は、過去 XNUMX ～ XNUMX 年ほどの間に登場した新しいベスト プラクティスである、インメモリ分散キャッシュです。 これをインメモリ データ グリッドと呼ぶ人もいます。 Microsoft はかつてデータ ファブリックと呼んでいました。 ただし、彼らは定義を変更し続けています。 しかし、これはメモリ内の分散型キー/値ストアであり、現在ではアーキテクチャの重要な部分となっています。 スケーラブルなアプリケーションが必要な場合は、分散キャッシュを念頭に置いてプログラミングし、アプリケーションを開発する必要があります。 これにより、アプリケーションがボトルネックにならないようにすることができます。

では、分散キャッシュとは何でしょうか? 基本的には 8 台以上の低コスト サーバーです。 これらはハイエンドのデータベース サーバーではなく、Web サーバー タイプのボックスです。 通常は、デュアル CPU、16 コア構成が非常に一般的です。 16 GB の RAM はほぼ平均的です。 32 ～ 64 ギガがメモリのスイート スポットのようなものであることがわかります。 64ギガ以上はお客様にもお勧めしません。 このボックスをより強力にするのではなく、別のボックスを追加すると言います。 XNUMX ギガを超えると、.NET アプリケーションにはガベージ コレクターと呼ばれる処理能力が大量に消費されるためです。 したがって、メモリが多いほど、ガベージ コレクターがそのすべてのメモリを収集できるようにするためには、より高速な CPU が必要になります。

したがって、本当にハイエンドのサーバーを少数所有するよりも、より多くのサーバーを所有する方が良いのです。 信頼性が必要なので、もちろん最低 2 つです。 いずれかのサーバーがダウンしても、その後は 4 対 1 または 5 対 1 の比率になるため、通常はアプリケーション層に 2、3、4、または 5 台のサーバーが存在することになります。 最も一般的なのは 4 ～ 10 で、もちろん 10 を超える顧客もたくさんいますが、4 と 10 がこのスイート スポットとほぼ一致します。 そのために、2 サーバー クラスターを使用します。 10 個または 12 個を超えて成長すると、80 個目または 80 個目などを追加します。 また、分散キャッシュはキー値ストアであるため、分散されます。 インテリジェントな方法で複数のサーバー間でデータをレプリケートするため、信頼性が得られると同時に、レプリケーションに多くの時間を費やすことがなくなります。 たとえば、すべてのデータをすべてのサーバーにレプリケートする必要がある場合、必要のない余分な処理が大量に発生します。 したがって、実行する必要があるのは、この種のインテリジェントなレプリケーションです。 場合によっては、そのような方法でレプリケーションを行う必要がありますが、それは特殊なケースです。 したがって、分散キャッシュを導入すると、約 XNUMX% の確率でそこにアクセスすることになります。 すべての読み取りはデータベースから行われ、すべての更新と一部の読み取りはデータベースとキャッシュに対して行われます。 したがって、データベース トラフィックの約 XNUMX% をキャッシュにトラップできれば、データベースは突然非常に軽くなります。 あまりやることはありません。 そのため、何をするにしても、はるかに高速に実行できるようになります。 したがって、パフォーマンスと拡張性が向上します。

このメモリ内分散キャッシュは、 NCache、それはどうか Redis .NET 側、Java 側にはさらに多くのプレーヤーがあり、どの製品を選択しても、分散キャッシュは現在既定のベスト プラクティスです。 これをアーキテクチャに組み込む必要があります。

次に進む前に、これまでのところ何か質問はありますか? したがって、はい、XNUMX つの論理キャッシュが複数のサーバーにまたがることができます。 の場合には NCache 同じサーバー上に複数のキャッシュを持つことができます。 したがって、各キャッシュは分離の目的で独自のコンテナーになりますが、XNUMX つのキャッシュは XNUMX つのサーバーすべてにまたがることができます。 私がスパンと言うとき、それは、一部のデータが XNUMX つのサーバー上にあり、一部のデータが他のサーバー上にあることを意味し、レプリケーションはそのサーバーの別の部分であり、好みに応じて実行される場合と実行されない場合があります。 しかし、確かに、すべてのサーバーはそのキャッシュを保存するために使用され、キャッシュは一貫性を持つ必要があります。 それは常に正しくなければなりません。あるいは、最終的には正しくなければなりませんが、常に正しいことにかなり近いと言えます。 キャッシュに何を保存しても、更新する場合は、データがどこにあるかは気にせず、おそらくデータがどこにあるかさえ知りません。 わかっているのは、このクラスターには私のデータがあり、フェッチするたびにこのサーバーからデータを保存した可能性があり、その直後にここでそれを読み取ろうとしているので、同じコピーを取得できるはずだということだけです。 それができれば、これは一貫性のある、または一貫したキャッシュになります。 したがって、更新に対するデータの整合性が常に保証されます。

それはあなたの好みであり、実際にキャッシュをどのように使用するかという観点から詳しく説明します。 したがって、あなたがすべきことが XNUMX つあります。つまり、これまでの主な目標は、スケーラビリティが必要な場合は、これをアーキテクチャの一部として含める必要があることを納得させることです。

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

さて、分散キャッシュが必要であるということに同意したとしましょう。最初に頭に浮かぶ疑問は、分散キャッシュをどのように使用するかということです。 どこで使いますか？ あなたはそれを何に使っているの？ どのようなデータがそこに保存されているか、およびそのデータに関連するすべての問題。

アプリケーションデータのキャッシュ

したがって、80 つの高レベルの使用例があります。 90 つ目は、先ほどお話ししたアプリケーション データ キャッシュです。データベースにデータがあり、それをフェッチしてキャッシュします。 したがって、アプリケーション データ キャッシュの目標は次のとおりです…しかし、データベースにあまりアクセスしたくないと言いましたが、アプリケーションをスケールできるようにデータベース トラフィックを削減したいと考えています。 ただし、データは 80 つの場所に存在します。 キャッシュにもデータベースにも存在します。 それでは、データが 90 つの場所に存在する場合、最初に思い浮かぶ懸念は何でしょうか? 両者の同期。 それで、それは一貫していますか？ データの一貫性が保たれない場合、キャッシュの使用は読み取り専用データに限定されるためです。 実際、キャッシュを何に使用しますか?と尋ねると、ほとんどの人が尋ねます。 突然の反応は読み取り専用データです。 ご存知のように、リアルタイムまたは実行時に実際に変更されるデータにキャッシュを使用することに不安を感じます。 ただし、トランザクション データ (頻繁に変更されるデータという用語を使用しています) にキャッシュを使用できない場合、そのデータがおそらくデータの XNUMX% ～ XNUMX% になります。 つまり、XNUMX% ～ XNUMX% の確率でキャッシュを使用することさえできず、キャッシュさえ使用できない場合は、 NoSQL database。 必ずしも答えが見つかるわけではありません。 そして、それが答えであることを望んでいるのですから、優れた分散キャッシュは、キャッシュする内容がデータベースと一貫しているという確信を与えてくれるものでなければなりません。 そうでない場合、そのキャッシュはあなたにとって適切なキャッシュではありません。 これが最初のことであり、最初の使用例です。

ASP.NET固有のキャッシュ

XNUMX 番目の使用例は、ASP.NET アプリケーションがある場合です。

1. ASP.NETセッションキャッシング

   セッションをキャッシュに保存できます。 ご存知のとおり、セッションはほぼすべての ASP.NET アプリケーションに備わっているものです。 これらは、インプロセス モードまたは SQL サーバー モードのいずれかで保持されます。 SQL サーバーは XNUMX つの理由からセッションを保持するのに適した場所ではありません。XNUMX つはもちろん、XNUMX つ目の理由は、データベース内にデータを保持すればするほど、スケーラビリティのボトルネックが大きくなるということです。 XNUMX つ目は、セッションが BLOB として保持され、リレーショナル データベースが実際には BLOB 用に設計されていないことです。 これらは、インデックス付けや検索ができる、より構造化されたデータ向けに設計されています。 一方、分散キャッシュではキー値が、値は常に BLOB になります。 したがって、これらのセッションは分散キャッシュに非常にうまく適合します。

2. ASP.NET View State キャッシング

   XNUMX 番目のタイプの ASP.NET データは、既存の ASP.NET アプリケーションの多くがまだ使用していない MVC フレームワークを使用していない場合、 状態を表示 また、ビュー ステートは、保持されて Web サーバーからブラウザに送信される暗号化された文字列にすぎませんが、Web サーバーに戻ってくると、文字列がかなり大きくなる可能性があります。 それは簡単に数百キロバイトになる可能性があるため、多くの追加の帯域幅を消費します。 旅行にもっと時間がかかります。 これに処理する数百万のリクエストを掛けると、帯域幅の消費コストもかなり増加します。 したがって、これはサーバー側でキャッシュし、小さなキーのみを送信するのに理想的なケースです。 したがって、次回ビュー ステートが使用されるときに、キーが送り返され、ビュー ステートがキャッシュからフェッチされます。

3. ASP.NET出力キャッシュ

   ASP.NET 固有のキャッシュの XNUMX 番目の例は、ページ出力です。 ASPの一部です.NET framework これは出力キャッシュと呼ばれるもので、ページの出力が変更されない場合にその出力をキャッシュできるようにします。また、ページの出力をすべての Web サーバーに個別に保持する代わりに、分散キャッシュを使用してキャッシュすることができます。これにより、同期が必要な複数のコピーが作成されます。 したがって、これら XNUMX つの使用例または XNUMX つの例は、ASP.NET 固有のキャッシュの使用例に関するものです。

ここで、アプリケーション データのキャッシュとは異なり、問題の性質は大きく異なります。 ここでは、データはキャッシュ内にのみ存在します。 つまり、このデータはすべて他の場所には保存されなくなります。 したがって、データベースには保存されません。 したがって、データベースとキャッシュの間の同期の問題はもう発生しません。 しかし、今は別の問題があります。 メモリ内キャッシュがある場合、それがデータの唯一の保存場所になります。 最大の懸念は何ですか? それで何が問題になるのでしょうか？ それは消えます。 はい、消えてしまう可能性があります。 いずれかのサーバーがダウンし、Windows を含むサーバーが実際にダウンした場合。 したがって、サーバーがダウンするとデータが失われ、特にビューステートとセッションステートの一部は失われますが、出力キャッシュは確実に失われ、ページを再実行するだけで済みますが、この XNUMX つは異なります。 たとえば、セッション状態では、あらゆる種類のフライト検索を行った航空会社の顧客がいて、注文しようとしているときにサーバーがクラッシュしてセッションが失われ、実際にログインする必要があります。 ご存知のとおり、その顧客を失う可能性があります。 だから、絶対に負けたくないんです。 したがって、このデータが消えてしまうのは望ましくありません。 つまり、この場合、同期が大きな問題となり、それは信頼性です。

したがって、信頼性はレプリケーションによって処理されます。 レプリケーションを行わないキャッシュにはセッションを保存できません。 ちなみに、ASP.NET 固有のキャッシュの優れた点は、プログラミングが必要ないことです。 ASP内に完全に適合します.NET framework。 残念ながら、アプリケーション データ キャッシュについてはプログラミングを行う必要があります。 Java 側では、そうする必要はありません。実際には、Java の方が標準が出現しています。 JCache と呼ばれる標準があり、これをプログラムすると、サードパーティのキャッシュをプラグインするだけで、6 つのキャッシュに固執する必要がなくなります。 Hibernate などの OR マッピング エンジンを使用する場合、または .NET NHibernate の場合は、キャッシュをプラグインすることができます。 Entity Framework は、EF コアが登場するまで、または EF コアが登場する前までは、サードパーティのキャッシュを自動的にプラグインすることを許可していませんでした。 EFXNUMX 用の ADO .NET プロバイダーを実装していましたが。 これは ADO.NET レベルのキャッシュであり、クエリをキャッシュしていましたが、キャッシュしないよりは優れていますが、更新も追跡できるエンティティ レベルでのキャッシュほど強力ではありません。

Entity Framework または EFCore キャッシュ

新しい EF7 または EF Core は、より柔軟なアーキテクチャを備えています。 サードパーティのキャッシュを接続できるようになります。 したがって、EF Core に移行すると、次のような分散キャッシュをプラグインできるようになります。 NCache プログラミングなしで。 つまり、標準的なプログラミングとキャッシュ プラグインを実行しているだけです。しかし、それ以外にもやらなければなりません。 ただし、そのプラグインであっても、これから説明するすべての機能を使用できるわけではありません。 少なくとも ASP.NET 固有では、これが最も簡単な方法です。 キャッシュを導入すると、プログラミングが関与しないため、基本的な健全性テストを行うだけで、アプリケーションのパフォーマンスとスケーラビリティが突然大幅に向上します。

次に進む前に、何か質問はありますか? アプリケーションの観点からですか、それともキャッシュの観点からですか? キャッシュに関しては。 キャッシュはデータベースと同じです。 データベースを呼び出した後に例外処理が行われるのと同じです。 キャッシュ内で何か問題が発生した場合、キャッシュは例外をスローします。それをキャッチして、適切なアクションを実行する必要があります。 ただし、チェック制約やその他の参照整合性制約があるためにデータの整合性に関して更新が失敗する可能性があるデータベースとは異なり、キャッシュにはそれらの制約は存在しません。 キャッシュは、与えられたすべてのデータを受け入れます。 キャッシュの更新または操作が失敗するのは、システムに問題が発生した場合のみです。 ええ、何か壊滅的なものです。 したがって、通常の操作ではキャッシュが更新されないことを心配する必要はありません。

セキュリティ

したがって、それは使用するキャッシュ製品によって異なります。 NCache これらの機能はすべて組み込まれています。 セキュリティしたがって、キャッシュを使用するすべてのユーザーは認証/許可される必要があります。 また、暗号化などの他の多くのセキュリティも組み込まれています。そのため、使用しているアプリケーションの機密性が非常に高い場合は、キャッシュされる前にデータを暗号化することができ、余分な労力を必要とせずにキャッシュによってすべてが自動的に行われます。 なぜなら、先ほども言ったように、 NCache 金融サービス業界です。 なぜなら、彼らはオンラインバンキングをたくさん持っているからです。 そこでは多くの電子ビジネスが行われており、そのデータは非常に機密です。 したがって、それはどの製品を選択するかによって異なります。

イベントを通じた実行時データの共有

XNUMX 番目の使用例は、 イベントを通じたランタイムデータの共有。 メッセージ キューを使用するのと同じように、MSMQ は XNUMX つであり、RabbitMQ は別の XNUMX つです。 複数の場所にある分散環境向けのメッセージングに関して、さらに多くの機能を備えています。 アプリケーションがすべて XNUMX つのデータセンター内にあり、次のことを行う必要がある場合 Pub / Sub データ共有の一種である分散キャッシュは、他のメッセージ キューよりもはるかにスケーラブルです。 それほど多くの機能は備えていないかもしれませんが、それらの機能すべてが必要なわけではないかもしれません。 しかし、それははるかに速く、はるかにスケーラブルであり、それは次の場合に当てはまります。 NCache これは、この機能を提供する他の分散キャッシュにも当てはまります。 なぜなら、やはりこのクラスター全体がメッセージ バスになるからです。 したがって、ご存知のとおり、大量のアクティビティを実行している場合、イベントは複数のサーバーで処理されるため、非常に早く伝播します。また、負荷が増大した場合にはサーバーを追加できます。

最近のサーバー アプリケーションの多くにはワークフローが組み込まれています。 XNUMX つのアプリケーションが何かを実行し、それが完了すると、他のアプリケーションが別のことを実行する場合。 そこで、Pub/Sub またはプロデューサー/コンシューマーの概念が登場します。 イベント通知機能があります。 NCache この機能は 継続的なクエリ これは非常に強力な機能で、Java 側にも存在しますが、他の .NET キャッシュにはありません。

したがって、実行時のデータ共有も、分散キャッシュを介して実行することを強く検討する必要があります。これにより、他の複数の製品を組み込むよりも作業がはるかに簡素化されます。 ここでも、問題の性質は通常これと同じで、共有しようとしているデータがキャッシュ内にのみ存在するということです。 それはデータベース内に存在するかもしれませんが、別の形式で存在します。なぜなら、あなたはそれを構築し、作成し、多くのデータをまとめ、この最終または中間形式で誰かと共有しているからです。それ以外。 したがって、そのデータを失った場合は、すべてをやり直す必要があります。 したがって、セッションほど悪くはありませんが、それでもパフォーマンスに多くの影響を及ぼします。 したがって、そのデータを失いたくありません。 したがって、ここでも懸念されるのは、キャッシュが信頼できるかどうかを確認することです。

以上が、分散キャッシュが提供する XNUMX つの高レベルの使用例です。 先ほど述べたように、分散キャッシュは本質的には分散メモリ内データベース、つまりキー値ストアです。

実践的なデモ

これらの実行方法についてさらに詳しく説明する前に、分散キャッシュがどのようなものかを簡単に説明します。 これをアプリケーションで使用するとどうなるかを確認できます。 もちろん使うつもりです NCache 例として。 NCache オープンソースのキャッシュです。 そのため、お金がない場合や予算がない場合は買わずに使用することもできます。 プロジェクトがよりビジネスに敏感な場合は、もちろん Enterprise Edition を購入してください。 そこで、Azure で使用する VM をいくつかセットアップしました。 2 ノードのキャッシュ クラスターを使用するので、キャッシュ サーバーとして「demo1」と「demo2」を使用し、アプリケーション サーバー ボックスとして「demo-client」を使用します。 つまり、それが ASP.NET サーバー ボックスです。 それで、 NCache クライアントは実際にはアプリケーションサーバーです。

たとえば、デモクライアントにログインしています。 したがって、最初に新しいキャッシュを作成します。 そこで、このツールを使用します NCache マネージャー。 つまり、エクスプローラースタイルのツールです。 新しいクラスター化キャッシュを作成するだけです。 で NCache すべてのキャッシュには名前が付けられます。

ストレージまたはレプリケーション戦略を選択します。

ここで最初のキャッシュ サーバーを指定します。 XNUMX番目のものを指定してください。

続けて、サーバーが消費する必要があるメモリの量をここに示します。 あなたの場合、それはさらに多くなるでしょう。 ギグを XNUMX つだけ指定しました。

したがって、そのメモリが消費された場合は、エビクション ポリシーを指定できます。 したがって、少なくとも最近使用されたポリシーは、最も最近使用されていないアイテムの一部を削除することを意味するとします。

それで、私はそれを手に入れました。 クライアント ノードを追加します。これが私のボックスであり、キャッシュを開始します。

それで、これをどのマシンに設定しているのですか？ これはアズールです。 つまり、これら 1 つは私のデモ 2 とデモ XNUMX です。 それで、私は実際にこのボックスにログインし、使用しています NCache マネージャーがここにいて、私はここでdemo1とdemo2のクラスターを作成しています。

これで、これを開始したので、先に進み、統計を表示できます。 したがって、PerfMon カウンターのアクティビティが確認できます。 この監視ツールを起動することもできます NCache これで状況を確認できるので、ストレス テスト ツールと呼ばれるこのツールをすぐに実行します。 これにより、環境内のキャッシュをすばやくテストして、キャッシュがどのように動作するかを確認できます。

つまり、そのツールはアプリケーションのようなものです。 これを使用して、さまざまな種類の負荷、さまざまな種類の操作をシミュレートできます。 たとえば、ここでは 600 秒あたり約 700 件のリクエストを実行し、それぞれ 800 ～ XNUMX 件のリクエストを実行しています。

ここで、ストレス テスト ツールのインスタンスをもう XNUMX つ実行させてください。 つまり、負荷が XNUMX 倍になることがわかります。 したがって、アプリケーションのインスタンスをどんどん追加し続けると、キャッシュの負荷が増加し、最終的にはこれら XNUMX つのサーバーが限界に達し、その後 XNUMX つ目のサーバーを追加するだけになります。

そして、何も停止することなく、実行時にすべてを行うことができます。 それで、突然インフラストラクチャが…考えてみてください。データベースが停止し始めた場合、本当に別のサーバーを追加してその問題から抜け出すことができるでしょうか? あなたはできません。 それはその性質上、特定のデータベースに関するものではなく、すべてリレーショナル データベースであるためです。 ただし、キャッシュの場合は、別のサーバーを追加するだけで、キャッシュが機能するようになります。

ということで、キャッシュはこんな感じです。 ご覧のとおり、使用と設定はとても簡単です。 つまり、私がしなかったのはインストールだけです。 これは単なる Windows インストーラーで、それほど時間はかかりません。 したがって、XNUMX ノードのクラスターを理解するのに、それ以外には約 XNUMX 分かかりました。

これですべての設定が完了したので、実際にこのボックスで実行されているアプリケーションにこのキャッシュ名を指定できるようになります。 したがって、さらに多くのクライアント ボックスがある場合は、ここに追加し続けることになります。

これら 8 つの場合、おそらく 10 つまたは XNUMX つあるでしょう。 したがって、それらをすべて追加し、キャッシュデモキャッシュを実行すると、そこにキャッシュが利用可能になるので、あとは自分のものを更新するだけです。

キャッシュがどのようなものかを理解したところで、早速次のトピックに移りましょう。 したがって、先ほども述べたように、キャッシュを使用する最も簡単な方法は、セッションにキャッシュを使用することです。 それ、どうやったら出来るの？ つまり、ASP.NET アプリケーションがあります。 私は入って web.config を開き、XNUMX つのことを行います。 まずアセンブリを追加します。

...
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
    <compilers>
        <compiler language="c#" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" extension=".cs" compilerOptions="/d:DEBUG;TRACE" />
    </compilers>
    <assemblies>
        <add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.6.0.0, Culture=neutral, PublicKeyToken=1448e8d1123e9096" />
    </assemblies>
</compilation>
...

の場合 NCache それは、を実装するアセンブリです ASP.NETセッション状態プロバイダー。 それで、そのようにして NCache ASPに接続します.NET framework。 サードパーティのキャッシュではこれを行う必要があります。 したがって、アセンブリにその行を追加し、次にセッション タグに移動して、選択した分散キャッシュに固有のこれを指定するだけです。

...
<sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20">
    <providers>
        <add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="WebF1" cacheName="democache" writeExceptionsToEventLog="false" enableLogs="false" />
    </providers>
</sessionState>
...

の場合 NCache これをコピーするだけですが、確認する必要があることがいくつかあります。 まず、モードが「カスタム」であることを確認する必要があります。 つまり、カスタムとはサードパーティのストレージを意味するためです。 そして、「タイムアウト」で希望どおりであることを確認し、その他はすべてデフォルトのままにして、ここでキャッシュ名を指定するだけです。 したがって、単に「demoCache」である必要があります。 この変更を加えてアプリケーションを再度実行するとすぐ、または実際にはこれを保存するとすぐに、ASP.NET ワーカー プロセスがリサイクルされます。 拾うよ NCache 構成を変更すると、すべてのセッションが XNUMX つのカウントになることが突然わかります。 つまり、私たちが目にしていたすべてのカウントは、 NCache この PerfMon については、こちらをご覧ください。

したがって、これらは 540 セッションが保存されることになり、もちろんセッションを追加するとカウントは増加します。

したがって、この少しの努力で、アプリケーションをすぐに大幅に強化することができます。 同じことがビューステートにも当てはまります。 出力キャッシュの場合はもう少し構成が必要ですが、ビューステートとセッションの場合は何の努力もせずに数分で完了し、突然アプリケーションが大幅なブーストを使用します。

アプリケーション データ キャッシュの概要 (API)

それでは、この話の大部分であるアプリケーション データのキャッシュに移りましょう。 したがって、アプリケーション データのキャッシュにキャッシュを使用する必要がある場合は、その API に合わせてプログラムする必要があります。 それは、まだ標準 API が存在しないためです。 そこで、ASP.NET キャッシュ オブジェクトにできるだけ近い API を選択しました。

キャッシュ接続

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");

NCache 2005年から始まっているので、もう11年半くらい経つんですね。 ただし、見た目は ASP.NET キャッシュ オブジェクトに非常に似ています。 追加のものがいくつかあるので、キャッシュ名を使用してキャッシュに接続するとします。 キャッシュハンドルを取得します。 次に、そのキャッシュハンドルがあなたが行うために使用するものです キャッシュ.取得。 Get には Add、Insert、Remove が含まれており、その Async バージョンもあります。つまり、キャッシュが更新されるのを待つ必要はありません。もちろん、Async を呼び出すときにコールバックを指定できます。 したがって、何か問題が発生した場合にコールバックが呼び出されます。

これが適切なアプリケーションのようにビジュアルでどのように見えるかを示しましょう。 これは、標準のコンソール アプリケーションです。 キャッシュのアセンブリを参照する必要があります。 の場合には NCache、これら XNUMX つのアセンブリだけです。 Alachisoft.NCache。ランタイム、 Alachisoft.NCache。ウェブ。 ここで同じ名前空間を指定し、次にアプリケーションの先頭を指定します。ASP.NET の場合、これはおそらく グローバル.asax Init メソッドまたはアプリケーション起動メソッド内で。 ただし、ここでは、ご存知のとおり、キャッシュ名とキャッシュ名に基づいてキャッシュに接続するとします。少なくとも、 NCache これによりキャッシュが認識され、キャッシュ ハンドルが取得されます。 次に、オブジェクトを作成し、次のことを行います。 キャッシュ.追加。 キーを指定します。 これは良いキーではありません。 もっと独自性があるはずです。 ただし、キーを指定し、その値が実際のオブジェクトであるとします。

public static void Main(string[] args)
{
    try
    {
        //Initialize cache via 'initializeCache' using 'Cache Name'
        //to be initialized. 
        Cache cache = NCache.InitializeCache("demoCache");
        cache.Clear();

        //Another method to add item(s) to cache is via CacheItem  object
        Customer customer = new Customer();
        customer.Name = "David Johnes";
        customer.Age = 23;
        customer.Gender = "Male";
        customer.ContactNo = "12345-6789";
        customer.Address = "Silicon Valley, Santa Clara, California";

        DateTime calendar = new DateTime();
        calendar.AddMinutes(1);

        //Adding item with an absolute expiration of 1 minute
        cache.Add("Customer:DavidJohnes", customer, calendar, Cache.NoSlidingExpiration, CacheItemPriority.Normal);
        Customer cachedCustomer = (Customer) cache.Get("Customer:DavidJohnes");
        ...

データの有効期限

そして、この場合、 NCache ということをやっている 絶対有効期限。 それでは、本題に入ります。 そこで、キャッシュを最新の状態に保ちたいアプリケーション データ キャッシュについて話しました。 したがって、キャッシュを最新の状態に保つことができない場合は、強制的に読み取り専用データにキャッシュを使用することになります。 では、キャッシュを最新の状態に保つにはどうすればよいでしょうか? 方法は複数あります。 ほとんどすべてのキャッシュに存在する最初の方法は、絶対有効期限と呼ばれます。 ここで、これをキャッシュに保持する期間を指定します。 つまり、キャッシュに対して、私が快適に感じるのは 99 分だけだと、このデータは 90 分以上キャッシュに保持されるべきではないと思います。なぜなら、XNUMX 分以上キャッシュに保持されていた場合、他の誰かがキャッシュに保持していると思うからです。更新しようとすると、キャッシュが古くなります。 つまり、キャッシュにデータを保持する期間について、経験に基づいた推測を行っていることになります。 そしてもちろん、キャッシュするすべてのデータには、何らかの有効期限が必要です。 かなり…つまり、期限切れになることはないとほぼ想定できるデータのことを指します。つまり、期限切れはないと言えるでしょう。 ただし、XNUMX% のデータ、または XNUMX% を超えるデータには有効期限が必要です。 したがって、絶対有効期限は、経験に基づいた推測に基づいてキャッシュを最新の状態に保つものです。

と呼ばれる別の有効期限があります スライド式有効期限。 その目的は全く異なります。 同じ名前の呼び出し期限を使用しますが。 スライド式有効期限は、誰もこのオブジェクトに触らない時間が長い (たとえば 10 分間、または 20 分間) 場合に期限切れになることを示しています。 そして、これはより多くの一時的なデータに使用されます。 したがって、これは、実際にはクリーンアップを行うだけの ASP.NET 固有のデータに使用されます。 もう誰も必要としていない、と言っているのです。 したがって、ユーザーが 20 分間セッションを使用しなくなった場合は、とにかくユーザーがログアウトしたことになるので、セッションを削除します。 つまり、それはクリーンアップの有効期限です。 次に、同期の目的である絶対有効期限です。 絶対有効期限の目的は同期です。 また、10 秒、15 秒、1 分、5 分、10 分で期限切れにすることができます。 最も一般的な有効期限はおそらく XNUMX 分または XNUMX 分です。

ただし、使用期限の問題があります。 それはあなたが推測をしているということです。 これくらい長くキャッシュしても大丈夫だと思いますよ、ということですね。 ただし、保証はありません。 場合によってはあるかもしれませんが、多くの場合、保証はありません。 同じデータベースにアクセスしている別のアプリケーションがあり、そのデータを更新する場合はどうなるでしょうか。 いくつかのスクリプトが実行されている可能性があります。 したがって、そのようなことが起こるたびに、有効期限だけでは十分ではありません。 そして、データベース内の変更を監視する機能を備えたキャッシュが必要になるのはここです。

キャッシュ内にあるものとそれに対応するデータベース内にあるデータとの関連性を指定でき、キャッシュに対してこのデータセットを監視してくださいと伝えることができる場合。 このデータセットが変更された場合は、先に進み、その項目をキャッシュから削除してください。

データベースの依存関係

それがどのように行われるかを説明しましょう。 それで、という機能があります SQLの依存関係 ADO.NETでは NCache を使用します。 これにより、 NCache データベースのクライアントになります。 そして、これは SQL データベースである可能性もあれば、Oracle である可能性もあります。 その後 NCache データ セットが変更され、そのデータ セットが指定した SQL ステートメントである場合に通知するようにデータベースに指示します。 ほとんどの場合、これは、キャッシュされたこのオブジェクトの構築に使用されたテーブル内の XNUMX つ以上の行に対応します。 たとえば、ここで SQL の依存関係について説明すると、やはり同じことになります。 キャッシュハンドルがあるので、追加するときにこれを キャッシュ.追加、現在指定しているのは、次の場合です。 NCache これはキャッシュ項目と呼ばれるもので、値とその他のメタデータを含む構造のようなものです。 含まれるメタデータの XNUMX つは SQL キャッシュ依存関係と呼ばれます。 NCache サーバー側の ADO.NET SQL キャッシュ依存関係にマップするクラス。 これに接続文字列を渡し、SQL ステートメントを渡します。

private static void AddProductToCacheWithDependency(Product product)
    {
        // Any change to the resultset of the query will cause cache to invalidate the dependent data
        string queryText = String.Format("SELECT ProductID, ProductName, QuantityPerUnit, UnitPrice FROM dbo.PRODUCTS WHERE PRODUCTID = {0}", product.Id);

        // Let's create SQL depdenency
        CacheDependency sqlServerDependency = new SqlCacheDependency(_connectionString, queryText);

        CacheItem cacheItem = new CacheItem(product);
        cacheItem.Dependency = sqlServerDependency;

        // Inserting Loaded product into cache with key: [item:1]
        string cacheKey = GenerateCacheKey(product);
        _cache.Add(cacheKey, cacheItem);
    }

したがって、「Product ID が値に関係なく、Products からいくつかの列を選択する」のようなことを言います。 つまり、これはこれをマッピングしている XNUMX つの製品です。 つまり、あなたはこう言っているのです NCache この SQL ステートメントを使用するか、この接続文字列を使用してそのデータ セットを監視するか、SQL サーバーにそのデータ セットを監視するよう依頼します。 実際、このコードはここで実行されています。 なぜなら、そこが NCache です。

したがって、これはキャッシュ クラスターと通信し、キャッシュ サーバーは実際に ADO.NET 呼び出しを行い、キャッシュ サーバーはデータベースと通信してクライアントになります。 そして、通知を受け取るのはキャッシュ サーバーです。 また、データベースからデータが変更されたことが通知された場合、キャッシュ サーバーは実際にその項目をキャッシュから削除します。 つまり、その機能を組み込むことで、いつ変更されるかさえ予測できないデータをキャッシュに保存できる柔軟性が突然得られるのです。 ただし、予測できない方法で変化する可能性があることだけはわかっているので、SQL 依存関係の指定を使用できます。

これは本当に強力な機能です。 これは、キャッシュでトランザクション データをキャッシュできるようにする機能です。 常に更新を制御できず、あらゆる種類のデータをキャッシュする場合でも、そのキャッシュが実際に役立つためです。 また、基になるデータベースがデータベース通知をサポートしている場合 (SQL サーバーと Oracle の場合)、これはさまざまな方法で実行できます。サポートしていない場合は、SQL 依存関係または Oracle 依存関係機能が使用されます。 NCache 少なくとも組み込みのポーリング メカニズムがあり、それを指定することもできます。 …特別なテーブルを指定する仕組みがあります NCache それを監視し、その中で変更された行には対応するキャッシュ項目があり、それが削除されます。

XNUMX 番目のオプションは、CLR プロシージャ内から実際にキャッシュ呼び出しを行うことです。 したがって、データが変更されるたびに、キャッシュを呼び出すプロシージャを呼び出すデータベース トリガーが存在します。 また、キャッシュからデータを追加、更新、または削除することができます。 CLR プロシージャの唯一のことは、非同期呼び出しを行いたくないということです。つまり、非同期呼び出しを行いたいということです。 なぜなら、あなたが何と呼んだとしても、実際にはデータベースが逆にキャッシュのクライアントになっているからです。 つまり、ここに入る何かを更新しようとしていて、それが複製される可能性があります。 したがって、これらすべてはデータベース トランザクション内で発生しており、ご存知のとおり、データベース トランザクションはかなり早くタイムアウトになります。 したがって、非同期呼び出しを行うことで、すぐにキャッシュ呼び出しを行ってから制御を返すことができます。

以上が、キャッシュとリレーショナル データベースの同期を確実に保つ XNUMX つの方法です。 もちろん、同じロジックが非リレーショナルにも当てはまります。 データがクラウドのどこかにある場合はどうなるでしょうか? あるいはメインフレーム内にあります。 ご存知のとおり、Web メソッド呼び出しを使用して、常にそれを取得します。 次に、次の場合には、 NCache 少なくとも、コードをキャッシュ クラスターに登録するカスタム依存関係機能を使用できます。 NCache たとえば 15 秒ごとに呼び出して、データ ソースを確認して、データが変更されているかどうかを確認してくださいと言います。 存在する場合は、イベントを起動すると、同じロジックが開始されます。

それで、もう一度 キャッシュを最新の状態に保つ 分散キャッシュでは最も重要なことです。 キャッシュを最新の状態に保つことができない場合、その使用は非常に制限されてしまいます。

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

と呼ばれる別の機能があります リードスルーとライトスルー。 リードスルーは、やはり非常に便利で非常に強力な機能です。 これも基本的に、キャッシュ サーバー上で実行されるコードです。 どこですか？ ここ。 したがって、次の場合に備えてリードスルー インターフェイスを実装するとします。 NCache。 現在、リードスルー/ライトスルーは、によって実装される概念です。 NCache。 これは多くの Java プレーヤーでも実装されていますが、.NET 側で実装されます。 NCache それを持っているのは唯一のものです。 したがって、リードスルー インターフェイスは基本的にコードです。 Init メソッド、Dispose メソッドがあるため、Connect と Disconnect、そして Load メソッドがあります。

...
// Perform tasks like allocating resources or acquiring connections
public void Init(IDictionary parameters, string cacheId)
{
    object connString = parameters["connstring"];
    sqlDatasource = new SqlDatasource();
    sqlDatasource.Connect(connString == null ? "" : connString.ToString());
}

// Perform tasks associated with freeing, releasing, or resetting resources.
public void Dispose()
{
    sqlDatasource.DisConnect();
}

// Responsible for loading an object from the external data source.
public ProviderCacheItem LoadFromSource (string key)
{
    ProviderCacheItem cacheItem = new ProviderCacheItem(sqlDatasource.LoadCustomer(key));
    cacheItem.ResyncOptions.ResyncOnExpiration = true;
    // Resync provider name will be picked from default provider.
    return cacheItem;
}
...

キーが与えられ、そのキーに基づいてどこに行ってデータを取得するかを判断する必要があります。 また、データを返すだけでなく、有効期限などのメタデータの一部も一緒に返します。 既読スルーの価値は何ですか? したがって、このコードもまた、ユーザーが実装し、サーバーに登録するものです… つまり、このコードがキャッシュ サーバー上で実行されます。 以上、カスタム依存関係について説明しました。 したがって、カスタム データ ソースがある場合、それはキャッシュ サーバー上で実行されるコードであり、リードスルーもキャッシュ サーバー上で実行されるものになります。

既読スルーは何の役に立つのですか？ なぜ既読スルーを使用する必要があるのでしょうか? メリットは２つ３つあります。 第一に、すべての永続化コードを XNUMX か所に統合​​することになります。 したがって、キャッシュを使用する複数のアプリケーションがある場合、つまり、複数のアプリケーションがある場合、すべてのアプリケーションがそのコードを何度も何度も実装する必要はありません。 したがって、キャッシュ サーバー自体内に保持されます。 それが最初のメリットです。 XNUMX 番目の利点は、たとえば、期限切れやデータベースの同期によって何かを期限切れにしたときに、そのアイテムをキャッシュから削除するのではなく、リロードすればよいということです。 なぜなら、これを削除すると、次にアプリケーションがそれを必要とするときに、とにかくそれをリロードすることになるからです。 したがって、これにリードスルーをマッピングして、この項目が期限切れになった場合、または取得された場合にキャッシュがどこに問題ないかを示すことができます。自動同期であり、削除する必要がある場合は、代わりにリードスルーを呼び出します。 では、なぜ既読スルーを呼ぶのが良いのでしょうか? つまり、何が大したことなのでしょうか？ なぜアプリケーションでリロードしないのでしょうか？ そうですね、トラフィックの多いアプリケーションを使用している場合、多くのユーザーが同じデータを要求する可能性があります。 これらのアイテムは何十万個もあり、それらはすべてそれぞれのタイミングで期限切れになります。 したがって、アイテムの有効期限が切れるたびに、同じアイテムに対して数千ではないにしても数百のリクエストがデータベースにヒットすることになります。 そして、すべてが実行され、キャッシュが再度更新されます。 そのため、大量の不要なトラフィックがデータベースに送信されます。 つまり、リードスルーがあったとしても、キャッシュから離れることはありません。 常にキャッシュに残り、ある時点で更新されます。 したがって、データベースへのトラフィックは発生しません。

XNUMX 番目の機能はライトスルーで、もちろん書き込み用であることを除けば、リードスルーとまったく同じように機能します。 それでは、それをお見せしましょう。 たとえば、ここでも、Init と Dispose がありますが、今度は Write があり、実際のオブジェクトが提供され、書き込みは追加、更新、または削除のいずれかになる可能性があります。 したがって、これら XNUMX つはすべて write と呼ばれます。 したがって、その操作タイプに基づいて、データベースまたはデータ ソースを更新します。

#region IWriteThruProvider Members
public OperationResult WriteToDataSource(WriteOperation operation)
{
    bool result = false;
    OperationResult operationResult = new OperationResult(operation, OperationResult.Status.Failure);
    Customer value = (Customer)operation.ProviderCacheItem.Value;
    if (value.GetType().Equals(typeof(Customer)))
    {
        result = sqlDatasource.SaveCustomer((Customer)value);
    }
    if (result) operationResult.DSOperationStatus = OperationResult.Status.Success;
    return operationResult;
}

public OperationResult[] WriteToDataSource(WriteOperation[] operation)
{
    throw new Exception("The method or operation is not implemented.");
}

さて、ライトスルーには別の利点もあります。 コードの共通性という点では、リードスルーと同じ利点があります。 ライトスルーの XNUMX 番目の利点はライトビハインドと呼ばれます。 つまり、更新できます。 そのため、同期方式でキャッシュをすぐに更新できるライトビハインドと呼ばれる機能がありますが、データベースの更新は非同期方式で行われます。 なぜそれが良いことなのでしょうか？ そうですね、データベースが遅いからです。 したがって、データベースの更新が適時に行われることが分かっている場合、キューに入れておかない理由は予測可能です。 これはキューに入れられ、キャッシュは実際にこの操作をバックグラウンドで実行します。 そのキューは複数のサーバーにも複製されます。 したがって、いずれかのサーバーがダウンしてもキューは失われません。

すべてはスケーラビリティの観点から見るべきだと思います。 たとえそれがインメモリ データベースであっても、高速なものはすべて XNUMX つのサーバー上にあります。 したがって、より多くの更新が送信され、より多くの読み取りが送信され、データベースにかかる負荷が増加し、速度が低下します。 まさに単一点障害のようなものです。 それでおしまい。 これが本当の理由であり、これらすべてが存在する理由であり、この既存のすべてのコンテキスト内で追加の利点をすべて得ることができます。 ライトビハインド機能があった場合、突然、アプリケーションは同期方式でキャッシュを更新するだけで済みます。 キャッシュが更新されると、キャッシュは非同期方式でデータベースの更新を処理するためです。 そして、そのキューには独自の最適化機能があります。 一括更新や複製が可能です。 したがって、ライトビハインドにはパフォーマンスがあり、あなたが話した速度の部分は、リードスルーよりもライトスルーとライトビハインドに関連しています。

リードスルーも、場合によってはアプリケーションがアクセスするよりも速い場合がありますが、ライトビハインドの方が常に速いのは間違いありません。

質問は？ もう数分しか残っていない。 もう XNUMX つの機能について説明して、最後に行きます。 そのため、ASP.NET キャッシュ オブジェクトなどのスタンドアロンのインプロセス インメモリ キャッシュに慣れている人が、分散キャッシュに移行すると、多くの顧客が当社に電話して、キャッシュが確実に機能することを約束していたと言いました。実際に私のパフォーマンスが向上します。 実際に私のパフォーマンスは低下しました。 何故ですか？ 誰か推測できますか？ インプロセス キャッシュではなく分散キャッシュに移行するとすぐに、実際に速度が低下するのはなぜでしょうか。 ネットワーク遅延。 ネットワーク遅延は XNUMX です。 さらに大きな問題は、シリアライズとデシリアライズに莫大なコストがかかることです。

クライアントキャッシュまたはニアキャッシュ

では、分散キャッシュの一部は何をしているのかというと、 NCache、彼らはこれを実装します クライアントキャッシュ、ニアキャッシュと呼ぶ人もいます。 これはこのキャッシュのサブセットであり、アプリケーション サーバー内に保持されます。 In-Proc または OutProc の場合もあります。 ただし、多くの場合はインプロセスです。 したがって、同期されることを除けば、スタンドアロンの In-Proc キャッシュと同じ利点が得られます。

そして、これはより小さいサブセットなので、各サーバーが 16 ギガである可能性があるとします。これは、わずか XNUMX ギガである可能性があります。 そして、それは動く窓ですよね？ したがって、キャッシュしているものはすべて保持され、その後、古いアイテムが期限切れになるか、削除されて新しいデータがキャッシュされます。

したがって、クライアント キャッシュは実際のパフォーマンスを提供します。 アプリケーションプロセス内でデータをオブジェクト形式で保持します。 したがって、何百回または何十回もフェッチする場合は、もちろん初回は分散キャッシュからフェッチする必要があります。 おそらく、初めてデータベースから取得することになるでしょう。 分散キャッシュに移動し、次にクライアント キャッシュに移動しますが、それが完了すると、それ以降の読み取りはすべて独自のヒープ内で行われるため、超高速になります。 つまり、これは非常に強力な機能です。 ぜひ活用したいですね。

したがって、確認する必要があることがいくつかあります。 分散キャッシュは、本番環境のデータセンターで実行されるデータベースと同様です。 したがって、アーキテクチャ上の要件のいくつかを満たしている必要があります。 高可用性が必要です。 データの信頼性と拡張性を提供する必要があります。 したがって、インテリジェントなレプリケーションを実行する必要があります。

この詳細については説明しません。 覗いてみることができます。 調査はオンラインで行うことができます。 たとえば、複数のデータセンターがある場合、データベースをレプリケートすることが期待されるのに、キャッシュはレプリケートされないのはなぜでしょうか? あなたが知っている。 複数のサーバー間で同期してキャッシュを利用できるようにすべきではないのはなぜでしょうか…つまり、適切なキャッシュはそうあるべきなのです。

.NET 分散キャッシュ オプション

.NET アプリケーションを実行している場合、現時点では、キャッシュにはほぼ XNUMX つのオプションがあることがわかります。 XNUMXつは Redis Microsoft が Azure に搭載したものです。 もう一つは、 NCache。 Java 側には、先ほども述べたように、かなり優れたプレイヤーが多数います。

そこで、本当に大まかな比較をしたいと思います。

NCache は最も古い .NET キャッシュです。 2005 年から市場に出回っています。ネイティブ .NET です。 これもオープンソースです。 Redis。 Azure または Amazon の両方でも利用できます。 Redis …つまり、 には XNUMX つのバージョンがあります。 Redisによって開発されたものです。 Redis Linux 上でのみ動作する Labs。 実際、Microsoft は Azure でそのバージョンを使用しています。 そして、Microsoft が Windows に移植したバージョンですが、Microsoft 自身では使用していません。 実際、お客様から多くの苦情をいただいております。 あまり安定していません。 ただし、Azure 以外で Windows 用に所有している唯一のバージョンは、Microsoft が移植した MS Open Tech です。 ただし、それ以外に行く場合は、 Redis Linux バージョンのみが提供されます。 Azure 自体には XNUMX つの違いがあります。 NCache そしてアズールはそれです NCache 実際にはキャッシュ サーバーを VM として提供します。 したがって、サーバー側のコードをすべて自分で実行して、監視することができます。 Redis サービスとしてキャッシュを提供します。 つまり、キャッシュはブラックボックスです。 非常に単純な API を呼び出すだけです。 そして、その制限は、今説明したすべての機能を利用できないことです。 データベースの同期はどのように行うのですか? リードスルー、ライトスルー。 実際には、時間がなかったため、SQL 検索さえしませんでした。 したがって、これを行うには XNUMX つの方法があります。 これについてさらに詳しく知りたい場合は、当社の Web サイトにアクセスしてください。 詳細な比較ドキュメント。 それで、私が入るとすれば、 Redis vs NCache ここで、完全なドキュメントを見ることができます。 ダウンロードすることもできます。 これは、同社のドキュメントと当社のドキュメントに基づいて機能ごとに比較したもので、どちらがニーズを満たしているかがわかります。 質問は？ これで私の話は終わりです。 ありがとう。

依存性はありますか .NET Core Framework または .NET 4.0 で使用できますか? 良い質問。 それで、 NCache サーバーサポート .NET frameworks. 4.0以降です。 の NCache デフォルトのクライアントは .NET framework もちろん。 私たちは .NET をリリースしようとしています…。 だから私たちはASPをサポートします.NET Core。 だから、 .NET Core Linux 上で実行できますが、制限があるためまだサポートしていません。 しかし .NET Core ASP上で動作するもの.NET framework、以下は Windows、特に ASP のみ.NET Core NCache それをサポートします。 皆さん、本当にありがとうございました。

次はどうする？

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