オーランド コード キャンプ 2019
ASPを最適化する.NET Core 分散キャッシュによるパフォーマンス
イクバル・カーン
プレジデント＆テクノロジーエバンジェリスト
ASP.NET Core トラフィックの多いWebアプリケーションの開発で急速に普及しています。 ASPを最適化する方法を学ぶ.NET Core オープンソースの .NET 分散キャッシュを使用することで、速度を低下させることなく極端なトランザクション負荷を処理できるパフォーマンスを実現します。 この講演の内容は次のとおりです。
- ASPの概要.NET Core パフォーマンスのボトルネック
- 分散キャッシュの概要と、分散キャッシュによるパフォーマンスの問題の解決方法
- アプリケーションのどこで分散キャッシングを使用できますか
- いくつかの重要な分散キャッシュ機能
- オープンソースを使用した実践例 NCache 分散キャッシュとして
ASP を最適化する方法について説明します。.NET core パフォーマンスを向上させるための手法として分散キャッシュを使用するつもりです。 NCache この例のように。
ASP.NET Core 人気のある (トラフィックの多いアプリ)
誰もが知っているASP.NET core 新しいです .NET core、クリーンで軽量なアーキテクチャ、クロスプラットフォーム、オープンソースであり、これがますます多くの人々が ASP に移行する主な理由になりつつあります。.NET core.
また、巨大なレガシー ASP.NET ユーザー ベースがあり、特に ASP.NET MVC アプリケーションを使用している場合は、ASP に移行する必要があります。.NET core は非常に簡単です。 MVC でない場合は、もちろん、書かなければならないコードがたくさんあります。 これらすべてが、ASP のおかげであなたもここに来ていると確信しています。.NET core Web アプリケーションを実行するための .NET の主要な選択肢です。
ASP.NET Core スケーラビリティが必要
したがって、ASPを使用している場合は、.NET core 交通量の多い状況で使用されることが増えています。 トラフィックが多いということは、通常、顧客向けアプリケーションがあることを意味します。 あなたはオンライン ビジネスかもしれませんし、小売ビジネスかもしれません。 さまざまな業界、ヘルスケア、電子政府、ソーシャルメディア、オンライン賭博、ギャンブルなど、考えられるすべてのものが含まれています。 最近は誰もがオンラインです。 だから、誰でも！ WebアプリケーションASPがある場合.NET core ASPを意味するものが使用されています.NET core スケーラブルである必要があります。
スケーラビリティとは何ですか？
それはどういう意味ですか？ 定義だけさせてください。皆さんもよくご存じだと思いますが、完全を期すために、用語の定義だけをしておきます。
つまり、スケーラビリティとは、ユーザーが XNUMX 人いるアプリケーションの応答時間が非常に優れている場合、それをクリックすると XNUMX ～ XNUMX 秒以内にページが戻ることを意味します。 次に、XNUMX、XNUMX、または XNUMX 人のユーザーに対して同じ応答時間を達成できれば、アプリケーションはスケーラブルであると言えます。 それができない場合は、拡張性がありません。 XNUMX 人のユーザーに対して高いパフォーマンスが得られない場合は、コードをどのように記述したかについて他の議論を行う必要があります。 ただし、あなたのアプリケーションは優れたアルゴリズムと優れたアプローチで開発されており、ユーザーが XNUMX 人いる高性能アプリケーションであると仮定します。 では、ピーク負荷時にどのようにしてパフォーマンスを向上させるのでしょうか?
線形スケーラビリティとは何ですか?
したがって、XNUMX から XNUMX、さらには XNUMX まで増加できる場合、それは線形スケーラビリティと呼ばれます。
そして、それを実現する方法は、負荷分散環境ではご存知のとおり、ASP をデプロイすることです。.NET core アプリケーションにロード バランサーを追加すると、さらに多くのサーバーが追加されます。 したがって、サーバーを追加すると、トランザクション容量、XNUMX 秒あたりのリクエスト数の容量が直線的に増加します。 それが達成できれば、同じパフォーマンスを達成できるでしょう。 そして、これが今日の話の目標であり、ピーク負荷下でもこの高いパフォーマンスを達成できるようにしたいと考えています。 したがって、ピーク負荷時に高いパフォーマンスが得られない場合、またはリニアなアプリケーションがない場合は、どこかにボトルネックがあることを意味します。 したがって、特定のしきい値を超えるとすぐに、さらにボックスを追加しても問題はありません。 実際には、どこかにアプリケーションを妨げるボトルネックがあるため、処理が遅くなる可能性があります。 したがって、非線形スケーラビリティになることは絶対に避けるべきです。
スケーラビリティが必要なアプリはどれですか?
要約すると、どのようなタイプのアプリケーションがスケーラブルである必要があるでしょうか?
明らかにASP.NET core それが私たちが話していることです。 また、ASP.NET アプリがユーザーであることを意味する Web アプリである Web サービスがある場合もあります。 Web サービスはやはり Web アプリです。 ユーザーは他のアプリです。 マイクロサービスは比較的新しい概念であり、サーバー側アプリケーションにも当てはまります。 もちろん、これにはアプリケーション全体の再構築が必要になります。 どのようにそれを行うかについては説明しません。 私がタイプ アプリケーションについて言及しているのは、皆さんが行っていること、または会社が行っていることをこれにマッピングできるかどうかをマッピングできるようにするためです。 そして最後に、多くの一般的なサーバー アプリケーションです。 これらのサーバー アプリケーションはバッチ処理を実行している可能性があります。 たとえば、大企業の場合、銀行の場合は、バックグラウンドでバッチ モードやワークフロー モードで多くのことを処理する必要がある場合があり、それらがサーバー アプリです。
スケーラビリティの問題と解決策
したがって、これらのさまざまな種類のアプリケーションはすべて、スケーラビリティに対応できる必要があります。つまり、増加するトランザクション負荷を速度を低下させることなく処理できる必要があります。 したがって、明らかにスケーラビリティの問題が存在します。そうでなければ、このような会話は行われないでしょう。 すべてが順調であれば、良いニュースは、アプリケーション層、つまり ASP が問題ではないということです。.NET core 問題はアプリケーションではなく、データストレージです。 扱っているデータが何であれ、それがパフォーマンスのボトルネックを引き起こしているかどうかは問題ではありません。 そして、それはリレーショナル データベース、メインフレームのレガシー データ、その他の大量のデータです。 興味深いことに、 NoSQL database多くの状況ではそれができないため、常に答えが得られるわけではありません。 NoSQL database リレーショナル データベースを放棄して新しい SQL データベースに移行するか、 NoSQL database これは、技術的および非技術的なさまざまな理由により実行できません。 そして、移動できない場合は、 NoSQL database、何が良いのですか？ 右？
したがって、私が焦点を当てているのは、図にあるリレーショナル データベースを使用してこの問題を解決する必要があるということです。なぜなら、前述したように、リレーショナル データベースはさまざまな理由で使用する必要があるからです。 そして、そこから抜け出せないのであれば、 NoSQL database多くの状況では答えになりません。
分散キャッシュの展開
したがって、リレーショナル データベースを引き続き使用し、代わりにアプリケーションに分散キャッシュをデプロイする必要があります。
外観は次のとおりです。 したがって、同じアプリケーション層があることがわかりましたら、トランザクションの負荷が増大するにつれて、そこにサーバーをさらに追加できます。 これらの多く、たとえば Web アプリや Web サービスの場合、それらは通常、すべての Web サーバーがユーザーから均等な負荷を受けられるようにするロード バランサーの上にあります。 サーバー アプリケーションの場合、アプリケーションの性質によっては、ロット バランサーがない場合もあります。 しかし実際には、サーバーはどんどん追加できますが、ここに存在するデータベースは XNUMX つだけです。 そして、私が言ったように、いくつかのことがあるかもしれません NoSQL database 一部の小規模な専門データについては同様ですが、データの大部分は依然としてリレーショナルです。 したがって、目標は間にキャッシュ層を配置することであり、分散キャッシュは基本的に XNUMX つ以上のサーバーのクラスターであり、これらのサーバーは低コストのサーバーです。 これらはハイエンドのデータベース タイプのサーバーではなく、すべてがメモリに保存されます。
なぜ記憶にあるのでしょうか？ なぜなら、メモリはハードディスクよりもはるかに高速だからです。 アプリケーションのパフォーマンスがさらに向上する必要がある場合は、これについて明確にする必要があります。 SSD であろうとその HDD であろうと、ハードディスクはあなたを死に至らしめます。 記憶の中に行かなければなりません。 すべてをメモリに保存する必要があります。そうしないと、必要なパフォーマンスが得られません。 そして、それは分散キャッシュに行くかどうかに関係なく、メモリ内がストレージです。 したがって、分散キャッシュには XNUMX つ以上のサーバーがあります。 これはクラスターを形成します。クラスターという言葉は、すべてのサーバーがクラスター内の他のサーバーを認識し、リソース、メモリ、CPU、ネットワーク カードをプールしていることを意味します。 つまり、これら XNUMX つのリソースが XNUMX つの論理容量にまとめられます。
メモリ。すべてのサーバーに RAM が搭載されているため、お客様が使用している典型的な構成は 16 ～ 32 ギガの RAM と各キャッシュ サーバーです。 最小値は 16、つまり 16 ～ 32 の間をお勧めします。そして、32 を超える代わりに、たとえば 64 ギガまたは 128 ギガの RAM を各ボックスに搭載すると、メモリが増えるほど CPU の容量を増やす必要があります。もっとガベージコレクションをしなければなりません。 .NET は GC を使用するため、ガベージ コレクションが増えると CPU が増えることになり、そうでないとガベージ コレクションがボトルネックになります。 したがって、16 つのボックスで 32 ギガを使用するよりも、範囲が 128 ～ XNUMX で、大きくならず、単にボックスの数が多い方が良いでしょう。 つまり、それが記憶です。
CPUは明らかに8番目のものです。 繰り返しになりますが、一般的な構成は約 16 コアのボックスです。 一部のハイエンド展開では約 8 コアが使用されますが、XNUMX ボックスあたり XNUMX コアで十分です。 先ほども言いましたが、低コストのサーバーです。 そして、もちろんネットワーク カードです。なぜなら、ここからここに送信されるデータはすべてネットワーク カードを通じて送信されるからです。 アプリケーション層では、明らかにキャッシュ サーバーよりも多くのアプリケーション サーバーが存在します。 繰り返しになりますが、通常、推奨される比率は XNUMX 対 XNUMX または XNUMX 対 XNUMX です。 XNUMX つのアプリケーション サーバーと XNUMX つのキャッシュ サーバー (少なくとも XNUMX つのキャッシュ サーバー)。 つまり、ここに XNUMX つのアプリケーション サーバーがある場合、それらには XNUMX 枚のネットワーク カードがあり、XNUMX 対 XNUMX の比率のネットワーク カードにデータを送信します。
つまり、ネットワーク カードについては、キャッシュ サーバーに少なくとも 10 枚のギガビットまたは XNUMX ギガビットのネットワーク カードが必要です。 それ以外は、それらをまとめる必要があります。最小値として XNUMX つから始めて、XNUMX つを最大にすると、何が起こるかというと、それを sub にしてアプリケーションを実行することになります。 すべてが非常に高速に実行されるか、負荷テストを行っている可能性があります。 すべてが超高速で実行され、負荷が増加します。 突然、サーバー側で CPU やメモリの消費量が増加し、応答時間が遅くなり始めます。 これがリレーショナル データベースで起こることですが、ここで XNUMX 番目のボックスを追加すると、突然別の大きな軽減が得られ、再びスループットが向上し、さらに多くのトランザクションを追加できるようになり、ピークに達し始めます。アウトしてから XNUMX 番目のボックスを追加します。
このようにして、この画像は増加し続けますが、これがボトルネックになることは決してありません。サーバーはどんどん追加できるため、ボトルネックになることはほとんどありません。 そして、ここでサーバーを追加すると、このキャッシュにさらに追加するだけになりますが、データベースではこれを行うことはできません。 ここで、8020 負荷を置きます。 実際には、キャッシュから読み取られるデータがますます増えていくため、90% のトラフィックがキャッシュに送られ、10% がデータベースに送られることになります。 キャッシュが処理しなければならない他の側面については後で説明しますが、これは基本的に画像であり、これが分散キャッシュが必要な理由です。
分散キャッシュの使用
わかった！ それでは、次に進みましょう。 これで、 分散キャッシュ あなたのアプリケーションで最初に頭に浮かぶ疑問は、「それでは何をすればよいでしょうか?」ということでしょう。 どうやって使用すればいいですか？ したがって、分散キャッシュを使用できる主なカテゴリは XNUMX つあります。
他にもありますが、ここでの議論のほとんどは、本当にハイレベルな XNUMX つです。
アプリのデータキャッシュ
XNUMX つ目はアプリケーション データのキャッシュです。 これが今まで私が話してきたことです。 データベース内にどのようなデータがあっても、それを私はアプリケーション データと呼んでいますが、データベースにアクセスしないようにキャッシュすることになります。 さて、これらのそれぞれについて、アプリケーション データ キャッシュの問題の本質は、データが XNUMX つの場所に存在することであることに留意してください。 キャッシュとデータベース。 そして、データが XNUMX つの場所に存在する場合、何が問題になる可能性があるでしょうか? 同期がずれています! うん！ そのため、データが同期しなくなる可能性があります。 したがって、データとキャッシュがデータベースと同期していない場合、多くの問題が発生する可能性があります。 最初から XNUMX 万ドルを XNUMX 回引き出すこともできましたが、それはとしましょう... それが私の頭に浮かぶ最初の問題です。
この問題を処理できないキャッシュや分散キャッシュは、読み取り専用データに制限されることを意味します。 ただし、いわゆる参照データです。 そして、このようにしてキャッシュは、読み取り専用データをルックアップ テーブルにキャッシュするものとして理解されるようになりました。 ルックアップ テーブルはデータの約 10% を占めます。 一部のアプリケーションでは、これは平均的なアプリケーションにすぎません。 データの 90% はルックアップ データではありません。 それはトランザクションデータです。 それは顧客、活動、注文などすべてです。 したがって、これらすべてをキャッシュできない場合、たとえばデータの 10% については、実際には公平な割合を超えてルックアップが実行される可能性があります。 つまり、その 10% によって 30% のメリットが得られる可能性がありますが、データベースに保存する必要があるデータの 70% がまだ残っていることになります。 しかし、すべてのデータをキャッシュできれば (それが快適な場合にのみ可能になります)、本当のメリットが得られるでしょう。
ASP.NET Core 特定のキャッシュ
XNUMX 番目のユースケースまたは XNUMX 番目の使用方法は、私が ASP と呼んでいるものです。.NET core 特定のキャッシュには XNUMX つの方法があります。 XNUMX つは最も一般的に理解されているセッションです。 ASP.NET には ASP がありました.NET core それらを持っています。 彼らはここに滞在するためにここにいます。 セッションを使用すべきではないと主張する人もいますが、セッションがなくなることはないと思います。 使用しても問題はありません。 唯一の問題は、どこに保管するかということです。 ASP.NET では常にそれが問題でした。 Microsoft が提供したストレージ オプションはどれも問題だらけでした。 そのため、当時の唯一の選択肢は分散キャッシュを使用することでした。幸いなことに、ASP.NET の時代にはカスタム オプションとしてプラグインできました。 ASPで.NET core、Microsoft には組み込みがないか、スタンドアロンのインメモリのようなイメージがありますが、すぐに I分散キャッシュ または、サードパーティの分散キャッシュにプラグインできるカスタム セッション プロバイダー NCache.
XNUMX つ目はセッション、XNUMX つ目は応答キャッシュです。 応答キャッシュについて知らない人はいないと言いたかったのですが、それは良い質問方法ではありません。 応答キャッシュは出力キャッシュの新しいバージョンに似ていますが、より標準ベースです。 これはキャッシュできるページ出力であり、後で説明しますが、これはキャッシュしたり、そのミドルウェアとして分散キャッシュをプラグインしたりできるものでもあります。
そして XNUMX 番目は、ライブ Web アプリであるシグナルまたはアプリケーションがあるかどうかです。 ライブ Web アプリとは、たとえば、すべての株価変動を常に伝達する必要がある株式取引アプリケーションがあり、数十万のクライアントがいる場合に使用するアプリです。 これらはすべて接続されているため、キャッシュ層またはアプリケーション層への接続が維持されます。 これは、Web リクエストごとに新しいソケット接続が開かれる通常の HTTP とは異なります。 ここでは、ソケット接続は開いたままになり、イベントはサーバーから伝播されます。 つまり、SignalR では、トランザクションが多く、ユーザー数が多い場合、負荷分散された Web フォームが必要になりますが、ソケットは開いたままなので、すべてのサーバーが独自のクライアントと通信することになりますが、今ではすべてのサーバーが独自のクライアントと通信します。クライアントまたはすべてのサーバーには異なるクライアントのセットがあるため、データを共有する必要があります。 つまり、そのデータはバックプレーンを通じて共有され、そのバックプレーンは... そこで分散キャッシュを接続します。 その「特定」の詳細については説明しません。 最初の XNUMX つについては説明しますが、XNUMX つ目については説明しません。
さて、ASPについて具体的に説明していきますが、.NET core 特定のキャッシュとは、データがキャッシュ内にのみ存在することです。 これはデータベースに登録しないでくださいと言っていたことです。 必要がない。 これは一時的なデータです。 必要なのは 20 分、30 分、2 時間、XNUMX 時間など、その後はデータを消去する必要がある場合のみです。 では、一時的なデータであればキャッシュ内にのみ存在する必要があり、データがキャッシュ内にのみ存在し、それがメモリ内キャッシュである場合、何が問題になる可能性があるでしょうか? データはすべてメモリ内にあるため、失われる可能性があります。 メモリは揮発性です。 したがって、優れた分散キャッシュはそのような状況に対処する必要があり、当然、レプリケーションが必要になります。
Pub/Subメッセージングとイベント
XNUMX 番目の使用例は、多くのアプリケーションがワークフロー タイプの操作を実行する必要があることです。 マイクロサービスはその好例です。 マイクロサービスはトピックではなく、ASP であっても、アクティビティを調整する必要があります。.NET core アプリケーションではそれを行う必要がある場合があります。 それで、 pub/subメッセージング これは別の方法です。繰り返しますが、これらすべてのボックスがこの冗長メモリ内インフラストラクチャに接続されるインフラストラクチャが整備されていることに注意してください。 では、Pub/Sub メッセージングにも使用してみてはいかがでしょうか?
以上が XNUMX つの一般的な使用例です。 したがって、これらは使用すべきXNUMXつの方法です NCache メリットを最大化したい場合は、分散キャッシュを使用します。
ハンズオンデモ
そこで、実際にどのように使用するかを説明する前に、分散キャッシュがどのようなものかを実際に示したいと思います。 環境として Azure を使用するつもりです。 NCache。 そして、これは簡単なデモです…
環境のセットアップ
ということで、Azureにログインしました。 XNUMX つの VM がありますが、これもすべてです .NET core.
つまり、Azure には XNUMX つの VM があります。 これらのうち XNUMX つをキャッシュ サーバー VM として使用します。基本的には、これら XNUMX つです。Windows クライアントと Linux クライアントを XNUMX つずつ使用します。 それで、もしあなたが持っているなら、 .NET core Linuxをサポートします。 あなたが持っている場合 .NET core これをアプリケーションとして Linux にデプロイするとよいでしょう。 さて、次の場合には、 NCache繰り返しますが、私はマーケティングをしているわけではありません NCache。 しかし、次の場合には NCache、それは .NET core そのため、Windows または Linux のサーバーとクライアントの両方で実行できます。
わかった！ さあ、入ってみましょう… それで、私はこのクライアント、Windows クライアント ボックスにログインしています。 そこで、自分用のキャッシュを作成してみます。
クラスター化キャッシュの作成
そこで、このツールを使用します NCache NCache マネージャー 実際にはオープンソースには付属していません。 これに相当するコマンドラインがありますが、ここでは単に怠けているだけです。 だから、私はちょうど使うつもりです NCache マネージャーですが、機能は同じです。 機能は変わらないのでそのまま起動しました NCache マネージャー。 新しいキャッシュを作成するとします。 キャッシュに名前を付けました。 すべてのキャッシュには名前が付けられます。 これをデータベースへの接続文字列として考えて、トポロジを選択します。 トポロジについては説明しませんが、これらすべてのニーズを処理できるようにするためにキャッシュが何を行う必要があるかについては、最後のほうで説明します。 したがって、パーティション レプリカ キャッシュ トポロジを使用することにします。 非同期レプリケーション。 最初のキャッシュ サーバーを追加します。 10.0.0.4 と 5 番目のサーバーは XNUMX です。つまり、XNUMX つのキャッシュ サーバーがあります。 すべてデフォルトのままにしておきます。 私は立ち退きや他のすべてのことをするつもりです。
次に、10.0.0.6 つのクライアントを指定します。 7 と XNUMX。ここに来て、キャッシュを開始します。 したがって、これをデータベースと同じように考えてください。XNUMX つのサーバーではなく、クラスターを構成する複数のサーバーがあり、キャッシュ サーバーのクラスターを作成してからクライアントを割り当てます。 クライアントを実行するだけでよいため、クライアントを割り当てる必要はありませんが、より柔軟性が得られるため、ここではこれを行っています。
ストレスのシミュレーションとキャッシュ統計の監視
次に、クライアントをテストしてみます。 ということで、私がクライアントです。 10.0.0.6だと思います。 私がどれなのか確認させてください。私は 10.0.0.6 だと思います。 来て！ 繰り返しになりますが、Azure 仮想ネットワーク内ですべてを実行しているため、クライアントは実際にはアプリケーション サーバーであり、キャッシュはすべて一緒になっています。 の場合には NCache あなたはこれをから得たかもしれません azure marketplace。 つまり、.6 は Windows クライアントです。 そこで、PowerShell を起動して、表示できることを確認します。 わかった！ わかった！ したがって、このクライアントがキャッシュと通信しようとしており、各キャッシュ サーバーで XNUMX 秒あたり約 XNUMX 件のリクエストを実行していることがわかります。 もう少し負荷を加えましょう。 別の PowerShell を開いて、クライアントの別のインスタンスにストレスを加えます。 これで、サーバーあたり約 XNUMX から XNUMX まで増加することがわかります。
さあ、やってみましょう…実際にやります…そこで、ここでコマンド プロンプトを開きました。 Linux ボックスにログインさせてください。 おっとっと！ そしてごめんなさい！ そこでPowerShellを起動します。 のクローンの部分ライブラリをインポートする必要があります NCache そして、同じストレス デモ キャッシュを実行するので、次のことを行います… これを行う前に、ご覧のとおり、サーバーごとに約 XNUMX ～ XNUMX のキャッシュを実行し、キャッシュと通信する Linux ベースのクライアントとしてこれを追加します。そして突然、サーバーごとにほぼ XNUMX のリクエストが発生しました。
つまり、1 台のサーバーで XNUMX 秒あたり約 XNUMX 件のリクエストを実行しています。 先ほども言いましたが、負荷をどんどん追加していき、XNUMX つのボックスを最大にすると、XNUMX つ目のボックスを追加し、さらに XNUMX つ目のボックスを追加します。 とても単純ですが、これもシミュレーションです。 ストレステストツールのような実物です。 したがって、これは念頭に置いておかなければならないことです。 ここでは実際のキャッシュを続けます。 ストレステストプログラムです。 バイト配列のように入力するだけです。 XNUMXkのデータが入ると思います。 それは追加し、更新し、取得します。 つまり、実際のアプリケーションをシミュレートし、先ほど説明した読み取りと書き込みの比率を確認するために変更できるパラメーターを備えています。 そして、これは私たちが提供するツールです NCache, 実際に自分の環境でテストできるようになります。 それで、その方法を見るには、 NCache 実際にアプリケーションを移行するのに多くの時間を費やす前に、実際に実行されます。 早速見ていきましょう。 それを実行していると思います。
ASP.NET Core セッションストレージ
キャッシュがどのようなものであるか、クライアントを追加する方法、キャッシュにさらに負荷を加える方法について見てきましたが、これは非常に簡単です。 したがって、キャッシュを使用する最も簡単な方法は、キャッシュにセッションを置くことです。 そして、セッションではできることが XNUMX つあります。
IDistributedCache プロバイダーを使用することもできます。 まあ言ってみれば NCache が XNUMX つあります。 指定したらすぐに NCache IDistributeCache、ASP として.NET core セッションのストレージとして使用し始めます。 では、実際にその一部をお見せしましょう。 このASPを持っています.NET core 応用。 ここでわかるように。 私の構成サービスでは、これを指定しており、makeと言っています NCache 私の分散キャッシュプロバイダー。 したがって、これを行うとすぐに、標準セッションを使用し始めます。これらの標準セッションは、現在使用している IDistributedCache を使用します。 NCache。 したがって、どのような分散キャッシュ プロバイダーを使用していても、必要なのはこれだけです。 ご覧のとおり、非常に小さなコードを変更するだけで、アプリケーション全体が自動的に、すべてのセッションがすぐに分散キャッシュに置かれます。
public IConfigurationRoot Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
// Add framework services.
services.AddMvc();
//Add NCache as your IDistributedCache so Sessions can use it for their storage
services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
//Add regular ASP.NET Core sessions
services.AddSession();
}そして、私たちがこれまで見てきたことの XNUMX つは、多くのお客様がデータベースにセッションを保存しているときに問題が発生し、次のようなものをプラグインすることです。 NCache 効果は瞬時に現れ、顕著な改善が瞬時に得られます。 最小限の努力で最大の利益が得られます。 もちろん、アプリケーションのダイレクト キャッシュもあるからです。
と思うのでいくつか省略します… したがって、セッションを指定する方法は複数あります。 XNUMX つは IDistributedCache で、XNUMX つ目は実際にカスタム セッション プロバイダーを使用できることです。 NCache もあり、やはりこれらはすべてオープンソースです。 次に、応答のキャッシュについても、同じことを行います。 あなたが指定します NCache 分散キャッシュとして機能し、自動的に応答キャッシュのキャッシュになります。 これ以上詳しくは説明しません。
ASP.NET Core アプリのデータキャッシュ
この話題についてもう少し基礎に触れていただきたいと思います。 したがって、アプリケーション データのキャッシュを行う場合は、セッションとは異なり、実際には API プログラミングを行う必要があります。 エンティティフレームワークコアを実行している場合を除きます。
したがって、たとえば次の場合、 NCache、やはりオープンソースで、EFコアプロバイダーがあります。 そこで、EF コアの拡張メソッドを実装しました。 それで、実際にプラグインすることができます NCache open source 通常の EF コア クエリを使用し、最後にキャッシュから、データベースからなどと言うことができます。これは、自動的にキャッシュを開始する単なる拡張メソッドです。 これにより、何をキャッシュするか、何をキャッシュしたくないかを完全に制御できます。 ぜひ見てみてください。 それは本当に強力な方法です。
EF コアを使用している場合は、これをお勧めします。 どのASPでもそうだと思いますが、.NET core アプリケーションでは、特に EF コアは古い EF よりもはるかに優れたアーキテクチャであるため、すべてのデータベース プログラミングは EF コアを通じて実行する必要があります。 それが一つの方法です。
もう一つは、実際に作ることができるということです。 IDistributedCache API またはインターフェイスを使用すると、XNUMX つのキャッシュ ソリューションに固定されない柔軟性が得られますが、コストがかかります。 とても基本的なことです。 入力は取得のみで、基本的には削除もあります。 それくらいです。 そして、私たちが話したすべてのこと、キャッシュをデータベースと同期した状態に維持できない場合、それらすべてが失われます。 したがって、これらすべての機能を活用したい場合は、実際にそれらすべてをサポートする API を使用する必要があります。 繰り返しになりますが、オープンソース キャッシュにコミットすることになるため、通常はその方が簡単ですが、アプリケーションのダイレクト キャッシュ、API は非常に単純で、キーと値があります。 値はあなたのオブジェクトです。
キャッシュを最新に保つ
さて、キャッシュを最新の状態に保つにはどうすればよいかという話題に移りましょう。 本当に貴重な情報ですよね？ 職業はなんですか？
さて、ほぼすべての分散キャッシュが最初に行うことは、有効期限です。 絶対的な表現をしているんですね。 キャッシュに何を入れても、XNUMX 分後にキャッシュから削除すると言います。 したがって、XNUMX 分以内に保持するのが安全です。XNUMX 分以内に、他の人が更新できるのは私だけになると思います。 それで、 NCache それを持っています、他の人もそれを持っています。 一時的…セッションなどの一時的なデータにはスライド式があり、使用が完了した後、一定時間タッチされなかった場合、たとえばセッション、ユーザーが 20 分間非アクティブな状態が続いた後にログアウトすると、セッションが終了します。有効期限が切れます。 したがって、同じことが起こります。 有効期限、ほとんどの人が持っています。
次はデータベースとの同期キャッシュです。 これは、キャッシュにデータベースを監視させる機能です。 つまり、実際には…何かを追加するときに、 NCacheたとえば、次のような SQL 依存関係を持つことができます。 NCache 監視するために。 SQL の依存関係とは、使用する SQL サーバーの ADO.NET 機能です。 SQL 依存関係により、SQL ステートメントまたはストア プロシージャを指定できるようになります。 NCache SQL サーバー データベース、その特定のデータ セットを監視します。 そして、そのデータ セットに変更が発生すると、SQL サーバーは通知します。 NCache キャッシュによってそのデータがキャッシュから削除されるか、その同期とリードスルー機能を組み合わせると、データが再ロードされます。 したがって、キャッシュされた顧客オブジェクトがあり、それが SQL 依存関係であり、その顧客が顧客のトランザクション データであるデータベース内で変更されたとします。そのため、頻繁に変更されることになります。 リードスルーを使用して、式または式のいずれかで自動的にリロードできます。 データベースの同期.
さて、突然キャッシュがデータの監視を担当するようになりました。 これを行うには XNUMX つの方法があります。SQL 依存関係、DB 依存関係、シールは CLR ストアド プロシージャです。 詳細には立ち入りません。 私たちのウェブサイトにアクセスして読むことができます。 しかし、繰り返しになりますが、最も重要なことは、機能としてデータベースとのキャッシュの同期がない場合、使用できるデータは読み取り専用の静的データに限定されるということです。 そして、それによって全体が制限され、このキャッシュを非リレーショナル データ ソースと同期することもできます。
そして XNUMX つ目は、リレーショナル データをキャッシュする可能性があるということです。ほとんどの場合、XNUMX 対多、XNUMX 対 XNUMX の関係を持つリレーショナル データをキャッシュすることになります。 たとえば、XNUMX 人の顧客が複数の注文を行っているとします。 顧客を削除すると、データベースから削除した可能性があるため、注文もキャッシュに残らないはずです。 したがって、それを行わない場合、アプリケーションはこれらすべてを行う必要がありますが、ASP.NET キャッシュ オブジェクトにはキー依存関係機能と呼ばれる機能があります。 NCache は、複数のキャッシュ項目間に XNUMX 対多または XNUMX 対 XNUMX の関係を持たせ、一方が更新または削除されると、もう一方も自動的に削除されるようにする機能を実装しました。 したがって、これら XNUMX つのことを組み合わせることで、キャッシュを常に最新の状態に保ち、データベースとの一貫性を保つことができます。 これにより、データのキャッシュを開始できるようになります。 ということで、これが第一のメリットです。
リードスルーとライトスルー
XNUMX つ目は、リードスルーとライトスルーを使用できる場合、アプリケーションが簡素化されることです。
先ほども述べたように、リードスルーは自動リロードのためにリードスルーを組み合わせることができます。これは、リードスルーがなければアプリケーションでは実行できないことです。 そして、再度ライトスルーを行うと、キャッシュを更新でき、特に権利を持っている場合はキャッシュがデータベースを更新できます。ここでもパフォーマンスの話ですよね。 したがって、すべての更新をデータベースに対して行う必要があります。 そうですね、更新はキャッシュからの読み取りに比べて遅くなります。 では、キャッシュへの更新を委任して、私がキャッシュを更新すると言ったら、代わりにデータベースを更新しに行ってはどうでしょうか。 それが安全であることはわかっています。なぜなら、私たちは結果整合性モデルに取り組むつもりです。分散システムとは、あなたが犠牲を払うか、一貫性に対してもっと寛大になり、結果整合性モデルを採用するというものです。 つまり、キャッシュが更新されてデータベースが更新されないため、この時点では一貫性がありませんが、数ミリ秒以内に更新されることになります。 また、一部のデータではそれを行うことができませんが、多くのデータではそれが可能です。
したがって、右後ろで実行すると、突然更新も超高速になり、アプリケーションはデータベースの更新コストを負担する必要がなくなります。 キャッシュが機能するのは、分散キャッシュであり、それをバッチとして吸収できるためであり、他にもあります。 したがって、これを開始すると、大量のデータをキャッシュできるようになります。
データのグループ化
データをキャッシュすると、さらに多くのデータがキャッシュされ、キャッシュはデータベースと同じくらい豊富になります。つまり、ほぼすべてのデータがキャッシュされることになります。
ほぼすべてのデータをキャッシュする場合、キー値だけでは検索するのに十分ではありません。 物事を検索できなければなりません。 AppFabric ちなみに、以前はグループとサブグループ、タグという名前のタグがありました。 NCache open source 持っています AppFabric ラッパー。 さて、手に入れた方は、 AppFabric に移動できます NCache 無料のものとして。 したがって、グループ化するとデータを簡単に取得できるようになります。
データの検索
SQL 検索を使用すると、都市がニューヨークであるすべての顧客を教えてください、などの情報を見つけることができます。 したがって、今度はキャッシュ内でデータベース タイプのクエリを実行します。 なぜ？ キャッシュに大量のデータが含まれていないためです。
インメモリがますます増えているため、パラダイム全体が変化しています。 繰り返しますが、データベースがマスターです。 したがって、キャッシュには一時的な期間のみ保持されます。