ASPのスケーリング.NET Core のアプリ NCache

録画されたウェビナー
ロン・フセイン、ザック・カーン著

ASP.NETは、Webアプリケーションを開発するための非常に人気のあるテクノロジです。 現在、最新バージョンのASP.NET Core WebアプリをASPに移行することを切望している組織で急速に人気を集めています.NET Core。 しかし、ASP.NET Core ユーザーに大きな負荷がかかると、スケーラビリティとパフォーマンスの問題が発生します。 これは、データ ストレージがボトルネックになるために発生します。 ただし、分散キャッシュを使用する場合、このパフォーマンスとスケーラビリティのボトルネックを回避する方法があります。 ASP を最適化する方法を学ぶ.NET Core 極端なトランザクション負荷下でも実行できるパフォーマンスとスケーラビリティ。

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

• ASPの概要.NET Core スケーラビリティとパフォーマンスのボトルネック
• 分散キャッシュがこれらの問題をどのように解決するか
• ASPを介したアプリデータのキャッシュ.NET Core IDistributedCache インターフェイスとダイレクト NCache API
• ASP.NET Core セッションストレージを使用した NCache
• ASP.NET Core 応答キャッシング NCache
• いくつかの重要な NCache 分散キャッシュ機能

今日のウェビナーでは、ASP の概要について説明します。.NET Core スケーラビリティとパフォーマンスのボトルネック、および分散キャッシュがそれらのボトルネックやその他の問題をどのように解決するかについて説明します。 今回はASPについてお話します.NET Core アプリケーションのパフォーマンスとスケーラビリティのボトルネックは何ですか。次に、これらのパフォーマンスとスケーラビリティのボトルネックを次の助けを借りて解決する方法について説明します。 NCache 分散キャッシュ システム。

NCache は、.NET および .NET Core アプリケーション。 これは .NET で書かれており、主に .NET と .NET Core アプリケーションですが、今日は主に ASP に焦点を当てます。.NET Core Web アプリといくつかのサンプル機能を利用できます。 サンプルアプリケーションもいくつか並べてみました。 したがって、これは実践的なウェビナーとなり、キャプチャできるさまざまなユースケースの機能レベルの詳細と、それらのユースケースに対処するために役立つ機能を共有し、それらのサンプルもデモします。 始めましょう。

したがって、最初のいくつかのスライドは ASP についての紹介スライドです。.NET Core プラットフォーム全般。 ASPとは誰でも知っていると思います.NET Core は。 これは、新しい ASP Web アプリケーション プラットフォームです。 すっきりとした軽量のモジュール式です。 Web アプリケーションのアプローチに関する限り、これは主に MVC アーキテクチャです。 人気のフロントエンド Angular や React は、ほとんどが JavaScript ベースのフロントエンドであり、それをバックアップする MVC アーキテクチャです。 クロスプラットフォームです。 Windows、Linux、および macOS などの他のオペレーティング システム上で実行できます。 また、通常、これは従来の 4.0 ASP.NET アプリケーションとの互換性も非常に高いものです。

ASP.NET MVC アプリケーションをお持ちの場合は、そこから移行して ASP の使用を開始できます。.NET Core さらに言えば、一般に、非常に高速で、非常に堅牢で、非常に軽量でクリーンなアーキテクチャであるテクノロジーです。

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

まずはASPについてお話します.NET Core プラットフォームにはスケーラビリティが必要です。 それでは、スケーラビリティとは何かを定義しましょう。 通常のユーザー負荷の下で実行されているアプリケーション、つまり正規化とは、一部のユーザーが存在することを意味します。 5 ～ 10 人のユーザーがログインし、特定のトランザクション、特定の操作、読み取りおよび書き込みリクエストを実行しているとします。 ここでの一般的な考え方は、ユーザー負荷が低い場合、アプリケーションは超高速になるということです。 しかし、アプリケーションの負荷が増大し、それがビジネスの要件となるとすぐに、より多くのユーザーがアプリケーションにログオンする必要があります。 このとき、アプリケーションの速度が低下する傾向があります。 ピーク負荷時にはパフォーマンスが低下する可能性があります。

アプリケーションがユーザー数が少ないときと同じパフォーマンスを維持できず、ユーザー数が多くなっても同じパフォーマンスを維持できる場合、そのアプリケーションは非常にスケーラブルなアプリケーションとして分類されます。 このアーキテクチャにはスケールアウト機能があり、エンド ユーザーからの負荷の増加に対処できます。 したがって、ピーク負荷時の高いパフォーマンスが実際にスケーラビリティ要素を定義するものになります。

これがグラフです。 通常、スケーラビリティは ASP.NET および ASP 内で実現されます。.NET Core 複数の Web サーバーまたはアプリ サーバーを介したプラットフォーム。

アプリケーションの負荷を分散できます。 アプリケーションを複数の Web サーバーまたはアプリ サーバーにデプロイし、それに基づいてアプリケーション ユーザーの負荷をそれらのサーバーに分散するだけで、サーバーを追加するにつれてリクエスト処理能力が直線的に向上します。 サーバーが増えると、アプリケーションからのリクエスト処理能力が増加します。

これは、サーバーを追加した後でも、多くの Web サーバーまたはアプリケーション サーバーを追加しても、ユーザーの負荷に応じてアプリケーションがスケールアウトしないようにアーキテクチャが設計されていない、非線形のスケーラビリティです。成長しています。

したがって、トランザクション要件が増大し、サーバーを追加し、すべての正しい手順を実行しているにもかかわらず、増加したリクエスト負荷に対応するために必要なキャパシティを獲得できていません。 したがって、この問題は通常、バックエンド データ ソースに関連しているので、それについて説明します。

したがって、まず最初に、どのようなアプリケーションにスケーラビリティが必要かを見てみましょう。 さまざまな種類のアプリケーションには何がありますか? ASP.NET内および .NET Core Web アプリと MVC Web アプリケーションがあり、主要なビジネス、いくつかの Web サービス、いくつかのサービス呼び出し、いくつかのマイクロサービスを実行しています。これが新しいアーキテクチャであり、他の一般的な .NET または .NET Core 応用。

内部または外部のユーザーが多数存在したり、リクエストの負荷が発生したりする可能性があるため、これらはすべてスケーラビリティを必要とし、アプリケーション アーキテクチャによってこれを満たす必要があります。

スケーラビリティの問題

Web ファームを作成できることは前述しました。 アプリケーションの負荷を複数のサーバーに分散できます。 では、スケーラビリティの問題は正確にどこにあるのでしょうか? ご覧のとおり、サーバーを追加すると、アプリ ファームまたは Web ファームに関する限り線形のスケーラビリティが得られるため、より多くのリクエスト負荷を処理できるようになります。

しかし、スケーラビリティが非線形になったり、スケーラビリティがまったくなくなったりするのは、正確にはいつなのでしょうか? これは通常、リレーショナル データベースの場合に当てはまります。 アプリケーション層は適切にスケールアウトされます。 さらにサーバーを追加できます。 同じアプリケーションの複数のインスタンスを同じボックス上に作成することも、別のボックスでアプリケーションをホストすることもできます。 しかし、これらのアプリケーションはすべて通常、バックエンドのリレーショナル データベースと通信し、リレーショナル データベースはストレージとしては非常に優れていますが、極端な量のリクエスト負荷を処理することになると、たとえば、アプリケーションで大量のトランザクション負荷が発生している場合、そのデータベースはボトルネック。 まず第一に、速度が低下するため、パフォーマンスのボトルネックとなり、さらにスケーラビリティを向上させる能力がありません。 容量を増やす機能はありません。 これは、データベースがホストされている特定のサーバーの容量を示すだけです。

メインフレーム データベースである可能性もあります。 何らかのファイルシステムである可能性があります。 これらのソースはすべてアプリケーションのスケーラビリティのボトルネックとなり、アプリケーションの速度が低下する原因となります。 リクエストがキューに並び始め、全体的なエンド ユーザー エクスペリエンスが影響を受けます。 NoSQL 答えではありません。 ご存知のように、多くのことは理解しています NoSQL 製品はそこにあります。 という商品もございます NosDB、ある NoSQL database。 しかし、主な問題は、 NoSQL databaseつまり、アプリケーションの再アーキテクチャが必要になり、リレーショナル データベースの使用をやめて、 NoSQL 非構造化データ ソースとの比較。

したがって、アプリケーションの再構築も簡単ではありません。 したがって、それはあなたが取り組む必要がある別の問題です。 したがって、主にバックエンド データ ソースが原因で、アプリケーションは全体的にスケーラブルではありません。

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

解決策は何ですか? 次のような分散キャッシュ システムの使用を開始するのは非常に簡単です。 NCache。 インメモリなのでデータベースに比べて超高速です。 つまり、それが最初に得られるメリットです。 したがって、インメモリ アクセスでは、ディスク ベースのアクセスと比較して、 NCache 比較すると超高速です。 したがって、最初の利点は、通常のアプリケーション リクエストが NCache データベースと比較して、超高速になり、バックエンド データ ソースへの移動が節約されるため、データベースの負荷も軽減されます。 したがって、データベースは他のことも自由に行うことができます。 XNUMX 番目の利点は、非常に拡張性が高いことです。 そのモデルは線形にスケーラブルです。 単なる単一のサーバーではありません。 キャッシュ クラスターのホストに使用できるサーバーは複数あります。 それはキャッシュクラスターです。 したがって、サーバーのチームは相互に連携して動作し、クライアントのリクエストに対応するのに役立ちます。 サーバーが増えると、リクエスト処理能力が増加します。 NCache そこに大きなメリットがあり、超高速な応答が得られるだけではありません。 NCache、超高速、低遅延であり、高スループット、非常に高いスケーラビリティも提供します。 アプリケーション アーキテクチャ内で何も変更することなく、サーバーを追加し続けることができ、ユーザーの負荷が増加するたびにその容量を直線的に拡張できます。

そして、良い点は、 NCache バックエンド データベースに加えて使用するということです。 これは、従来のリレーショナル データ ソースに代わるものではありません。 使い始めるためにアプリケーションを再構築する必要はありません NCache。 いつでもご利用いただけます NCache データの一部または大部分が内部にあるバックエンド データ ソースと組み合わせて使用​​します。 NCache データベースにはそのマスターコピーがあります。 ただし、ユースケースによっては、キャッシュにすべてのデータが含まれる場合があります。 たとえば、セッションやその他のユースケースの場合です。

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

スループットの数値は次のとおりです。 これらのテストは AWS ラボで実施しました。 これは、AWS ラボでシミュレートされた実際のアプリケーション データです。 したがって、それはすぐに使えるデータではありません。 私たちの環境でシミュレートされた実際のアプリケーション データ。 5を使用した場所 NCache サーバーを使用し、2 秒あたり XNUMX 万件のリクエストを達成することができました。 NCache.

したがって、サーバーをさらに追加すると、スケーラビリティの数値が向上し、パフォーマンスが向上します。 つまり、わずか 2 件で 5 秒あたり XNUMX 万リクエスト NCache これは非常に直線的に増加する傾向にあり、サーバーを追加し続ければ増加し続けるはずです。

これらは弊社ウェブサイトでも公開しております。 あります デモンストレーション 同様に利用できる。

デプロイメントアーキテクチャ

これが私たちのデプロイメントアーキテクチャです。 通常は次のようになります NCache 分散キャッシュシステムが導入されています。 オンプレミスとクラウドのすべての環境でサポートされます。 .NET または NET Core Framework を使用できるようにするだけで可能です。 それが唯一の前提条件です NCache また、Windows だけでなく Linux サーバーにもデプロイできます。 オンプレミスの物理ボックスまたは仮想ボックスである場合もあれば、.NET または .NET Core Windows または Linux にインストールされます。 したがって、これら XNUMX つの要件があります。

それ以外 NCache すべてのプラットフォームでサポートされています。 で利用可能です Azure Marketplace、AWS と同様に、SaaS ベースのモデルまたはデプロイメントも考え出しています。 NCache 今後のバージョンでは。

XNUMX つの展開オプションがあります。 XNUMX つは、キャッシュには専用サーバーを使用し、アプリケーションはクライアント サーバー モデルで接続する必要があるということです。 これは、クライアント側 VM がなくサーバー側展開があるクラウドでも推奨されるモデルです。

XNUMX 番目の展開オプションは、既存のアプリケーション ボックスを NCache サーバーも同様です。 これはほとんどの場合、アプリケーション層がすでに存在するオンプレミスで行われます。 より小規模な構成を使用するとよいでしょう NCache 同じボックス、同じサーバーのセットにインストールされます。

どちらにしても NCache トラフィックのほとんどを処理します。 100% が推奨され、一部のトラフィックは常にバックエンド データベースに送信されます。これは、バックエンド データ ソースへのキャッシュを通じて処理できるトランザクション操作の読み取り、書き込み操作である可能性があります。

したがって、アプリケーションがデータを保持してデータを更新したり、キャッシュとデータベースから相互に連携してデータを取得したりするサイト パターンとしてキャッシュを使用することも、 で利用可能なリードスルーおよびライトスルーのアプローチを使用することもできます。 NCache.

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

いくつかの使用例について説明してから、すぐに説明に入ります。 ASP.NET Core 特定のキャッシュ 特徴。 それでは、いくつかの一般的な使用例について説明しましょう。 NCache。 多くの使用例があります。 そして、技術的な観点からいくつかリストしましたが、これらは ASP に固有のものです。.NET Core アプリケーション、ただし一般的にはあらゆる .NET または ASP.NET または ASP に適用されます。.NET Core or .NET Core。 Web アプリケーション、バックエンド アプリケーション、ワークフロー、Windows サービスなど、あらゆるアプリケーションが利用できます。 NCache 選択できる使用例は数多くあります。

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

   主にASP向け.NET Coreでは、アプリデータのキャッシュを対象とします。これには XNUMX つのオプションがあります。 使用できます IDistributedCacheインターフェース。 アプリケーションですでに IDistributedCache を使用している場合は、単純にプラグインすることができます。 NCache そのためのプロバイダーとして。 したがって、それが最初のオプションです。 XNUMX 番目のオプションは、直接を使用することです NCache API とアプリ データ キャッシュでは、アプリケーション内のほぼすべてのものをキャッシュします。 ドメイン オブジェクト、コレクション、データ セットなど、複数回使用したいがバックエンド データベースにはアクセスしたくないデータが考えられます。そのデータを取得したので、そのデータをキャッシュを使用すると、キャッシュ リポジトリを使用し続けて、データベースへのアクセスを節約できます。

2. ASP.NET Core セッションキャッシュと SignalR Backplane

   XNUMX 番目のユースケースは ASP です.NET Core 特定のキャッシュ。 これらは Web フロントエンド キャッシュ機能です。 この面において、私たちは多くの機能を備えています。 ASPをご利用いただけます.NET Core セッション状態。 ご存知のとおり、これは単一サイト セッションと複数サイト セッションです。 NCache 分散キャッシュクラスターです。 したがって、セッションは内部に分散して保存されます。 NCache。 また、コード変更のないオプションでもあり、プラグインする拡張メソッドのコードをほぼ XNUMX 行変更するだけで済みます。 NCache。 これを使用するために大規模なコード変更は必要なく、内部的には非常に信頼性があります。 NCache セッションはサーバー間でレプリケートされるためです。 したがって、サーバーがダウンしても、ユーザー側ではデータの損失やアプリケーションのダウンタイムは発生しません。

   ここでのXNUMX番目の特徴は、 ASP.NET Core 応答キャッシング。 静的ページがある場合。 歴史的に、ASP.NET には出力キャッシュがありました。 新しいASPでは.NET Core プラットフォームでは、応答キャッシュを使用できます。ページ レベルのヘッダーを定義し、それに基づいてすべてのページのページ出力が内部にキャッシュされます。 NCache。 したがって、応答はキャッシュされます。 まったく同じリクエストを再度発行すると、事前にキャッシュされたレスポンスが利用可能になります。 つまり、それは内部の機能です NCacheこれは、ASP で使用できるコード変更不要のオプションでもあります。.NET Core フロントエンドのキャッシュレベル。

   そして、SignalR を使用していて Web ファームを持っている場合は、バックプレーンが必須となります。 それで、 SignalR Backplane 単一サーバーから Web ファーム展開に移行する場合に必要です。その場合は NCache ASPとして機能できる.NET Core バックプレーン、 SignalR Backplane SignalR アプリケーション向け。 これはバックグラウンドでイベント駆動型の Pub/Sub メッセージングを使用しています。 非常に高速で、非常にスケーラブルです。 したがって、プラグインを使用すると、高いパフォーマンスとスケーラビリティ、高い可用性と信頼性の利点が得られます。 NCache ASPとして.NET Core SignalR Backplane.

3. Pub / Subメッセージング

   最後に、XNUMX 番目の使用例は Pub/Sub メッセージングです。 Pub / Subメッセージング も別の使用例です。 SignalR の場合、舞台裏で Pub/Sub メッセージングを使用しています。 ただし、Pub/Sub メッセージングは​​、内部で別のユースケースとして使用できます。 NCache 同じように。 マイクロサービス アプリケーションの場合、マイクロサービス アーキテクチャで単純なアプリケーションを定義する場合、これは非常に理にかなっています。 彼らは専用のタスクを担当します。 彼らが果たしている非常に重要な目的。 したがって、これらのマイクロサービスと NCache その問題を解決できます。 マイクロサービス アプリケーション内に通信を自分で実装する必要はありません。 信頼できる NCache そのための通信プラットフォームとそれに接続されているアプリケーションはメッセージを送受信でき、その実行中にパフォーマンスが低下する必要はありません。

   パブリッシャー・サブスクライバー・モデルを使用できます。 パブリッシャーがデータをキャッシュにパブリッシュし、キャッシュがそれらのメッセージを保存してすべてのサブスクライバーに中継します。 これは非同期イベント駆動のメカニズムです。 したがって、発行者と購読者はお互いを知る必要さえありません。 したがって、遅延、待機、同期呼び出しは発生しません。 つまり、非常に堅牢で高速な疎結合アーキテクチャであり、すべてが管理されます。 NCache、このプラットフォームに関する限り。

実践的なデモ

以上、これらの高レベルの機能について説明しました。 次に実際の製品を実際に動かしてみます。 ここでキャッシュ クラスターを作成します。 試して。 監視の側面をいくつか示してから、ASP で使用できるすべての機能について説明します。.NET Core 一つずつ。 そこで、そのためのサンプル アプリケーションをいくつか並べてみました。 そこで、デモ環境にログオンします。

それで、ここにXNUMXつあります NCache 私が使用するサーバーと私のボックスは、これらすべてのサンプル アプリケーションを実行するクライアント マシンとして機能します。 そこで、ここでのアイデアは、 Webベースの管理ツールと監視ツール.

したがって、この Web ベースの管理ツールを使用すると、すべてを XNUMX つのポイントから管理および監視できます。 これは、任意の Web リクエスト、どこからでも、環境からの XNUMX つまでの http リクエストである可能性があります。 NCache サーバーやクライアントを管理し、Web 経由ですべてをリモートで管理および監視できるようにする必要があります。

クラスター化キャッシュの作成

したがって、localhost に IP アドレスを指定すると、インターネット上のどこからでもこのリソースにアクセスできます。 そこで、新しいキャッシュを作成してみます。 「aspcorecache」としましょう。 すべてのキャッシュに名前を付ける必要があります。 複数のキャッシュ クラスターを作成することもでき、必要に応じて意味のあるキャッシュ名を付けることができます。

シリアル化のモードはバイナリまたは JSON です。 したがって、私はバイナリに固執し、バイナリに固執します。そして、JSON も非常に柔軟なので、それを使用したい場合は、レプリカ キャッシュ トポロジのパーティションを選択します。

中で NCache 沢山あります キャッシングトポロジ。 さっさと終わりの方へ連れて行けば。 そのため、選択できるキャッシュ トポロジが多数あります。 パーティション分割を行った後、バックアップを使用してパーティション分割を行います。 したがって、この例では、各サーバーが XNUMX つのパーティションを維持しています。 クライアントが接続されているアクティブ データ パーティションと、別のサーバーのパッシブ レプリカ パーティション。 ご覧のとおり、サーバー XNUMX はアクティブで、そのバックアップはサーバー XNUMX にあり、サーバー XNUMX はアクティブで、そのバックアップはサーバー XNUMX にあります。 いずれかのサーバーがダウンした場合、バックアップがアクティブ化され、ここからすべてのデータが取得されます。 通常の運用では、これらのパーティションにはデータが均等に分散されています。

クライアントはすべてのサーバーに接続されているため、読み取りおよび書き込みリクエストは非常に高速です。サーバーを追加すると、これらすべてのサーバーが相互に連携して動作するため、読み取りおよび書き込みリクエストの処理能力が向上します。 これが、私がレプリカのパーティションとして選択しているトポロジです。

次に、非同期レプリケーション オプションです。 アクティブとバックアップの間で、同期または非同期を選択できます。 同期の信頼性が向上しました。 非同期の方が速いです。 それでは、それでは進めさせていただきます。

このデモにはサイズ 1024 で十分ですが、意味があると思われる任意のサイズを思いつくことができます。

TCPパラメータ。

質問： 私たちが現在使用しているのは、 NCacheclient.ncc または nc conf ファイル、または開発パイプラインにあるものを回避する方法はありますか?

はい。 それは絶対に可能です。 client.ncconf を使用すると、キャッシュ クラスターが実行されているキャッシュ サーバーに接続するための構成を指定できます。 私の場合、XNUMX つのボックスと XNUMX つのキャッシュ名があります。 したがって、client.ncconf には、キャッシュ名と、このキャッシュが構成されているサーバーが含まれています。 client.ncconf を回避したい場合は、これらすべての設定をインラインで指定できます。 キャッシュ初期化パラメータがあります。 これらをキャッシュ初期パラメータと呼びます。 これらのオブジェクトを使用すると、アプリケーション コード内でこれらすべての構成を指定できるようになります。 あ、はい。 この質問に答えるには、キャッシュ初期化パラメータを使用する必要があります。

質問： 導入できますか NCache アズールでは？

絶対に。 これについては、デプロイメント アーキテクチャの詳細を共有しているときに話し合いました。 NCache Microsoft Azure、AWS、その他のパブリック クラウドまたはプライベート クラウドで完全にサポートされています。 のみの前提条件 NCache .NET または .NET Core、選択したオペレーティング システムによって異なります。 また、Azure と AWS 内での SaaS モデルも考案中です。 したがって、完全にサポートされています。 弊社マーケットプレイス画像も掲載しております。 ということで、いろいろな使い方ができます NCache Azureで.

NCache TCP/IP ベースのキャッシュ クラスタリング プロトコルです。 したがって、IP アドレスとポートが必要です。 したがって、画面上のすべてをデフォルトのままにします。

キャッシュがいっぱいになった場合、XNUMX つの選択肢があります。新しい更新を拒否して読み取りにキャッシュを使用し続けるか、エビクションをオンにして、新しいアイテムのためのスペースを確保するために一部のデータを自動的に削除することができます。

セッション、ビューステート、応答キャッシュ、さらにはオブジェクト キャッシュの場合、データが重要な性質のものである場合は、エビクションをオフにして、満杯にならないように、また満杯になった場合でも十分な大きさのガス サイズを提供することを強くお勧めします。実行時にキャッシュ サイズを変更できます。 ただし、余裕があれば、実際に一部のデータが失われても大丈夫です。その場合は、エビクションを有効にすると、キャッシュがいっぱいになると、一部のデータが自動的に削除され、新しいデータ用のスペースが確保されます。 つまり、立ち退きというのはそういうことなのです。

終了時にこのキャッシュを開始し、サービスの開始時にこのキャッシュを自動的に開始します。 したがって、サーバーが再起動されるたびに、キャッシュが自動的に起動され、それだけです。 このように、XNUMX ノード キャッシュ クラスターを構成するのは非常に簡単です。 NCache.

ストレスのシミュレーションとキャッシュ統計の監視

したがって、キャッシュは稼働しています。 これも有効になっているので、早速テストしてみます。 統計ウィンドウ。 したがって、これらは両方のサーバーのパフォーマンス カウンターと監視の側面を示しています。 NCache.

とても良い。 したがって、サーバー側とクライアント側のダッシュボード レポート ビューも提供されます。 つまり、すべてのパラメータがそこにあります。

次に、このキャッシュをテストします。 アプリケーションが接続されていないので、先に進みます。 これはキャッシュの名前で、舞台裏ではクライアント側の構成を使用して接続しており、キャッシュ クラスターに接続してリクエストのシミュレーションを開始します。 アクティビティを示す XNUMX 秒あたりのリクエスト数カウンターとキャッシュ操作あたりの平均マイクロ秒カウンターが表示されていることがわかります。 追加、フェッチ、更新も発生し、キャッシュ サイズ カウンターが表示され、CPU、メモリ、現在キャッシュに接続されているクライアント IP が表示されます。

このツールの別のインスタンスを実行してみましょう。

質問： これを行っている間、もう XNUMX つの質問は、キャッシュに接続されているすべてのクライアントを監視できるかということです。

絶対に。 これは非常に強力な機能の XNUMX つです NCache。 この例を使ってこれを示すことができます。 これで 107 つのクライアントが接続されました。 まず、クライアントのダッシュボードが表示されます。 したがって、これら XNUMX つのクライアントは XNUMX から実行されており、このクライアント ボックスから読み取り操作が行われていることがわかります。 私がボックスからアプリケーションを実行している場合は、ボックスの統計もここに表示され、同様に、プロセス、そのプロセス ID、ポート、ここから送受信されたバイト数も確認できます。 しかし、あなたが探している主なことは、クライアント側からの監視の異なる側面だと思います。 つまり、XNUMX 秒あたりの読み取り操作数、XNUMX 秒あたりの追加数、XNUMX 秒あたりの更新数、フェッチ数になります。

したがって、クライアント側のカウンターの完全なセットがあり、これらはの一部として利用できます。 NCache、右、キャッシュの健全性、これらはすべてサーバー側のカウンターですが、クライアント側の下に表示されているこれらのカウンターはすべて追加でき、クライアント アプリケーション サーバーのカウンターもすべて確認できます。

そう、 NCache は、クライアント側の監視を非常に広範囲にサポートしています。 それがあなたの質問の答えになることを願っています。

さて、実際に実行してみました。ストレス テスト ツールの 800 つのインスタンスを実行でき、それぞれのインスタンスで 900 秒あたり約 XNUMX ～ XNUMX のリクエストが発生していることがわかります。 NCache サーバ。 つまり、平均して 1500 秒あたり約 XNUMX のリクエストが処理されることになります。

以上、簡単なデモでした。 これらのツールを停止するつもりです。 次に、実際に活用できる機能を紹介していきます。 そこで、私たちはその方法をかなりの時間を費やして説明してきました。 NCache 非常にスケーラブルです。 どのように展開されるのでしょうか? キャッシュ クラスターを構成および作成するにはどうすればよいですか?

さて、次に注目したいのは、その活用方法です。 NCache ASPで.NET Core アプリケーションと主な使用例は何ですか。 さまざまなユースケースについて説明しました。 それでは、ASP 内での Web フロントエンド キャッシュの使用例を始めてみましょう。.NET Core.

NCache ASP.NET Core セッションキャッシング

それで、私が強調したい最初の機能は、 NCache ASP.NET Core セッションのキャッシュ。 ここには XNUMX つの選択肢があります。 すでにセッションを使用していて、おそらく IDistributedCache インターフェイスを使用している場合は、使用できます。 それで、プラグインできます NCache IDistributedCache を介したセッション キャッシュのプロバイダーとして。 スタンドアロンのインメモリプロバイダーがあります。 SQL サーバープロバイダーがあります。 スタンドアロンは単一障害点です。 スケーラブルではありません。 SQL サーバーは場合によっては単一障害点にもなります。 スケーラビリティがなく、非常に遅いです。

NCache プロバイダーは超高速です。 メモリ内にあります。 非常に拡張性があります。 単一障害点ではなく、実行時の容量が増加します。 したがって、さらに多くのサーバーを追加することができ、無制限のスケーラビリティを実現できることがわかります。 NCache。 それでは、IDistributedCache について簡単に確認してみましょう。 ということで、これが私たちの推測ゲーム、IDistributedCache です。

public void ConfigureServices(IServiceCollection services)
{
	//Add framework services
	services.AddMvc();

	services.AddNCacheDistributedCache(configuration =>
        {
	   configuration.CacheName = "MyNCacheCache";
	   configuration.EnableLogs = true;
	   configuration.ExceptionsEnabled = true;
        });
}

public void Configure(IApplicationBuilder app)
{
	app.UseNCacheSession();
}

あなたがする必要があるのは、services dot add だけです NCache 「分散キャッシュ」を選択し、「アプリの使用」と入力します。 NCache Session と、これを実行するサンプル アプリケーションを次に示します。

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

            //To test sessions with NCache Distributed Cache, uncomment the following lines and comment the line after it
            services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
			services.AddSession();			
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
        {
            loggerFactory.AddConsole(Configuration.GetSection("Logging"));
            loggerFactory.AddDebug();

            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
                app.UseBrowserLink();
            }
            else
            {
                app.UseExceptionHandler("/Home/Error");
            }

            app.UseStaticFiles();

ここでの XNUMX 番目のオプションは、 NCache 高度な機能を備えたセッションプロバイダーであり、そのためのサンプルアプリケーションもあります。 それでは、実際にこれに焦点を当ててみましょう。 主に、私たちのプロバイダーは IDistributedCache と比較してはるかに豊富な機能を備えているため、これを強調したいと思います。その一環として、IDistributedCache プロバイダーが提供するすべての機能も確認してください。

それで、ここに戻ってきます。 まず第一に、必要なのは NCache NuGet パッケージ。これはすでにこの中に追加されています。 それで、もし私たちが持っているなら、 AspNetCore.セッション。NCache、 右。 これが NuGet パッケージです。すぐにここに戻って、ここでのセッションも確認してみましょう。 NCache.Microsoft.Extensions.Caching。 したがって、IDistributedCache セッションの NuGet パッケージは、 NCache 実際のセッションプロバイダー。

そこで、ここではこれに焦点を当てて説明します。 あなたがしなければならないのは…。 まず、Startup.cs にアクセスします。 サービスがあります。追加NCacheセッションとそれがかかる 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();
        
        //To test sessions with NCache Distributed Cache, uncomment the following lines and comment the line after it
        //services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
		//services.AddSession();
			
        services.AddNCacheSession(Configuration.GetSection("NCacheSettings"));
    }
    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
        {
            loggerFactory.AddConsole(Configuration.GetSection("Logging"));
            loggerFactory.AddDebug();
... 

そして、設定内ですべてを指定します NCache プロバイダーの設定。 たとえば、ASP を使用しています。.NET Core キャッシュ。 SessionAppId は、アプリにキャッシュ アイテム キーが追加されるアプリ ID 属性です。 セッション ID がキャッシュ キーになり、この属性がそれに追加されます。 そのため、内部のさまざまなアプリケーションのセッションを独自に表示できます。 NCache 次に、セッションのロックを設定します。 これを true に設定すると、それが可能になります。 これを true に設定すると、単純にセッションをロックできるようになり、同時アクセスが許可されなくなります。

{
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Debug",
      "System": "Information",
      "Microsoft": "Information"
    }
  },
  "NCacheSettings": {
    "CacheName": "mycache", //Replace "myPartitionedCache" with the name of your cache
    "SessionAppId": "GuessGame", //(Optional)Specifies an identifier to make sure that session ID remains unique in case multiple applications are using the same cache.
    "EnableSessionLocking": false, //(Optional)If this flag is set, NCache Session Store Provider exclusively locks the session-store item for which multiple concurrent requests are made. The default is false.
    "SessionLockingRetry": -1, //(Optional)If enableSessionLocking is true and this integer is not less than 0, NCache Session Store Provider will return empty session after sessionLockingRetry, which specify the number of retries to acquire a lock. The default is -1.
    "EnableLogs": false, //(Optional)When this flag is set, store provider logs all error information. The log files are created in %NCHOME%/log-files/SessionStoreProvider. The default is false.
    "EnableDetailLogs": false, //(Optional)When this flag is set, store provider logs all debugging information. The log files are created in %NCHOME%/log-files/SessionStoreProvider. The default is false.
    "ExceptionsEnabled": false, //(Optional)Specifies whether exceptions from cache API are propagated to the page output. Setting this flag is especially helpful during development phase of application since exceptions provide more information about the specific causes of failure. The default is false.
    "OperationRetry": 0, //It specifies the number of times server will retry the operation, in case connection is lost with a server while an operation is executing. Its default is zero.
    "operationRetryInterval": 0 //It specifies the time interval between each operation retry, in case connection is lost with the server. Its default value is zero.
  }
}

したがって、セッションの読み取りのみが可能です。 書き込みアクセスは、ログを持つ現在のリクエストにのみ付与され、詳細なログが利用可能になります。 シングルサイトセッションとマルチサイトセッションが利用可能です。 したがって、これらすべての機能は、当社の ASP に接続した場合にのみ利用可能です.NET Core セッションプロバイダー。 IDistributeCache セッションはサポートされていますが、制限されています。 それで、これを本当に素早く実行して、最終的にこの ASP に接続するアプリケーションをシミュレートします。.NET Core キャッシュ。

実は、これはやめさせてください。 まずボックスをクライアントとして追加しましょう。 したがって、ここで行う必要があるのは、ここに私のボックスであるクライアント ボックスを追加することだけです。

さあ、どうぞ。 これですべての構成が完了したので、このアプリケーションをもう一度実行できるようになり、キャッシュ クラスターへの接続が許可されるはずです。 とても良い。 そのため、初めてのインスタンス化には時間がかかります。

したがって、これにより内部にセッションオブジェクトが作成されます NCache。 監視の観点に行くと、107 つのクライアントが接続されていることがわかります。 プロバイダーが初期化されると、クライアントは 108 と XNUMX に接続し、内部にセッション オブジェクトを作成します。 NCache。 現時点では、メイン ユーザーであるため、セッション オブジェクトは XNUMX つだけ作成されます。 私はログインしている XNUMX 人のユーザーになりますが、複数のアプリケーション ユーザーがいる場合は、内部で複数のセッションが作成されることがわかります。 NCache。 ただし、ここでの考え方は、これら XNUMX 行のコードを追加するだけでよいということです。 追加 NCache 「セッション」を選択し、「使用」と言います NCache セッション。

// 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();

//To test sessions with NCache Distributed Cache, uncomment the following lines and comment the line after it
//services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
//services.AddSession();
			
services.AddNCacheSession(Configuration.GetSection("NCacheSettings"));
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    loggerFactory.AddConsole(Configuration.GetSection("Logging"));
    loggerFactory.AddDebug();
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
        app.UseBrowserLink();
    }
    else
    {
        app.UseExceptionHandler("/Home/Error");
    }
    app.UseStaticFiles();
    //To test NCache Distributed Cache, uncomment this and comment the line below this
    //app.UseSession();
    app.UseNCacheSession();
... 

これらの拡張メソッドはすべてをカバーします。 最初のインスタンス化にはわずかに長い時間がかかります。これは ASP で確認されたことです.NET Core しかし、それが完了したら、アプリケーションが稼働し、すぐにテストできるはずです。 さあ、どうぞ。 XNUMX つのクライアントがすでに接続されているので、そこにいると思います。

それまでの間、export という簡単なコマンドを実行させてください。 このツールは、現在存在するすべてのキャッシュ キーをダンプします。

したがって、XNUMX つのクライアントが接続されているため、キャッシュに XNUMX つのセッション オブジェクトが追加されることを期待しており、これにより XNUMX つのセッションが存在できるはずです。 前回の試みから XNUMX つと今回の試みから XNUMX つがすでに存在しています。 さあ、どうぞ。

これは数字を推測できる推測ゲームで、セッション内でそれらの数字を追加し、それらの数字も表示します。 それで、もっと大きな数字を推測させてください。それが、次のリクエストを行う方法です。 NCache.

これは非常に単純なアプリケーションですが、ここに戻ってきたら、キャッシュ内に XNUMX つのアイテムがあり、先ほど行った XNUMX つのリクエストを見たはずです。 NCache サーバ側。

これで最初のデモンストレーションが完了しました。プラグインできるようになります。 NCache セッションキャッシュ用。 たくさんの機能があります。 単一サイト、複数サイトのセッションがサポートされています。 セッションのロックがサポートされています。 広範なロギングが利用可能です。 とても安全です。 その上にセキュリティと暗号化が備わっています。 したがって、使用する予定がある場合は、これは完全なパッケージです。 NCache セッションキャッシュ用。

ASP.NET Core 応答キャッシング

XNUMX番目の機能はASPです.NET Core 応答のキャッシュ。 この例では、アプリケーションに http ヘッダーがあります。 ページ出力をキャッシュするかどうかを選択できます。 NCache キャッシュ用の応答キ​​ャッシュ ミドルウェアを使用し、これも IDistributedCache インターフェイスを介して行われます。 それで、ここに戻ってきたら、これがあります サンプルアプリケーション.

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.HttpsPolicy;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Alachisoft.NCache.Caching.Distributed;

namespace ResponseCaching
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddResponseCaching();
            services.Configure<CookiePolicyOptions>(options =>
            {
                // This lambda determines whether user consent for non-essential cookies is needed for a given request.
                options.CheckConsentNeeded = context => true;
                options.MinimumSameSitePolicy = SameSiteMode.None;
            });

            #region Option1
            // Reading NCacheSettings using appsettings.json

したがって、これを使用するために必要なのは、この NuGet パッケージを使用することだけです NCache.Microsoft.Extensions.Caching。 これは、セッション、オブジェクト キャッシュ用の IDistributedCache、および XNUMX つの NuGet パッケージ内の応答キャッシュをカバーします。

そして、次にあなたがしなければならないことは、 サービス。追加NCache分散キャッシュ.

// This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddResponseCaching();
            services.Configure<CookiePolicyOptions>(options =>
            {
                // This lambda determines whether user consent for non-essential cookies is needed for a given request.
                options.CheckConsentNeeded = context => true;
                options.MinimumSameSitePolicy = SameSiteMode.None;
            });

            #region Option1
            // Reading NCacheSettings using appsettings.json
            services.AddNCacheDistributedCache(Configuration.GetSection("NCacheSettings"));
            #endregion

            #region Option2
            // Reading NCacheSettings using hardcoded values
            //services.AddNCacheDistributedCache(options =>
            //{
            //    options.CacheName = "myPartitionedCache";
            //    options.EnableLogs = true;
            //    options.ExceptionsEnabled = true;
            //});
            #endregion

            services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
        }

これは、プラグインされる IDistributedCache インターフェイスですが、応答のキャッシュに使用します。アプリの設定には、セットアップしたキャッシュ名といくつかのロギング設定があり、ここに戻ってきたら、応答のキャッシュがあることになります。 services.AddResponseCaching(); も設定されています。

...
namespace ResponseCaching
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddResponseCaching();
            services.Configure<CookiePolicyOptions>(options =>
            {
                // This lambda determines whether user consent for non-essential cookies is needed for a given request.
                options.CheckConsentNeeded = context => true;
                options.MinimumSameSitePolicy = SameSiteMode.None;
            });
...

したがって、このアプリケーションは応答のキャッシュが行われることを期待しています。 それは、 NCache IDistributedCache インターフェイスを使用します。 しばらく時間がかかるので、これをすぐに実行して、実際に接続できるようにすることにします。 NCache 次に、実際に追加されるデータを表示します。

コードをお見せしたら。 ご存知のとおり、構成をインラインで指定することもできます。 たとえば、「追加」NCacheDistributedCache」と入力し、キャッシュ名「demoClusteredCache」または「aspCoreCache」と入力すると、すべての設定をインラインで指定できます。

public void ConfigureServices(IServiceCollection services)
{
...
   services.AddNCacheDistributedCache(configuration => 
   {
	configuration.CacheName = "demoClusteredCache";
	configuration.EnableLogs = true;
        configuration.ExceptionsEnabled = true;
   });
...
}

または単に使用することもできます NCache 設定して設定を与える NCache 設定、ここにあります。 構成またはインライン設定による可能性があります。 したがって、その点では非常にシンプルです。

public void ConfigureServices(IServiceCollection services)
{
   services.AddResponseCaching();

   //remaining services here
   ...
   //Add NCache services to the container
   services.SetNCacheSessionConfiguration ( 
	Configuration.GetSection("NCacheSettings"));

   services.AddNCacheDistributedCache();

   services.AddMvc();
}

今ここに戻ってくると、応答キャッシュ アプリケーションも接続するため、XNUMX つのクライアントが接続されることが予想されます。 NCache その結果、キャッシュ内にいくつかの項目が表示されます。

質問： データはどのように正確に暗号化され、安全に保たれますか?

この応答キャッシュのサンプルを示してから、内部のセキュリティ暗号化機能を説明します。 NCache。 アプリケーションを実行すると、ご覧のとおり、いくつかの項目が追加されています。 これを単純に更新すると、値がここから更新され、このページの出力コンテンツが内部に保存されます。 NCache 応答キャッシュを通じて、キャッシュ キーを見せてみると、キャッシュにはさらにいくつかのアイテムが存在します。 したがって、すでに存在するセッション項目に加えて XNUMX つの項目が追加されます。

さて、話に戻りますが、 セキュリティ暗号化。 内部は非常に広いです NCache。 セキュリティと暗号化機能を備えています。 選択できるセキュリティプロバイダーは数多くあります。 AES プロバイダーと DES プロバイダーがあります。 それらの複数。 当社には FIPS 準拠の暗号化プロバイダーがあり、TLS 1.2 もサポートされています。 したがって、トランスポートレベルのセキュリティも利用できます。 NCache。 つまり、これが暗号化をカバーするものです。 クライアント ボックスとサーバー ボックスの間でエンドツーエンドの暗号化を行うことができ、セキュリティの観点から誰がキャッシュ管理者になるか、誰がキャッシュ ユーザーになるかを選択できます。また、Active Directory ベースの LDAP ベースの暗号化セキュリティ プロバイダーを使用できます。プラグインできます。

したがって、特定の質問がある場合は、電子メールを送信してください。私たちはあなたと協力して、これらの設定方法に関する詳細をすべて共有します。 しかし、社内では非常に広範なサポートが用意されています NCache。 それで、ここに戻ってきます。 したがって、これは私たちのASPをカバーします.NET Core 応答のキャッシュ。

ASP.NET Core SignalR Backplane

次の機能はASPです.NET Core SignalR Backplane。 この中で、Web ファームを使用している場合は、次のように使用できます。 NCache そのバックプレーンとして、また従来のバックプレーンと比較して、 NCache 非常に高速で、信頼性が高く、拡張性にも優れています。

それで、これが私が追加したNuGetパッケージです。 AspNetCore.SignalR。NCache 検索できるということ。 すでにインストールされています。 必要なのは、アプリの設定を通じてキャッシュ名を取得することだけです。次に、拡張メソッドを示します。 したがって、services.AddSignalR がある場合は、それに追加する拡張メソッドがあります。 NCache ています SignalR Backplane ASP用.NET Core 分野の様々なアプリケーションで使用されています。

// This method gets called by the runtime. Use this method to add services to the container.
// For more information on how to configure your application, visit https://go.microsoft.com/fwlink/?LinkID=398940
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services.Configure<NCacheConfiguration>(Configuration.GetSection("NCacheConfiguration"));
    services.AddSignalR().AddNCache(ncacheOptions =>
    {
        ncacheOptions.CacheName = Configuration["NCacheConfiguration:CacheName"];
        ncacheOptions.ApplicationID = Configuration["NCacheConfiguration:ApplicationID"];
        // Uncomment in case of cache security enabled.
        //ncacheOptions.UserID = Configuration["NCacheConfiguration:UserID"];
        //ncacheOptions.Password = Configuration["NCacheConfiguration:Password"];
    });
}

時間がかかるので急いで実行します。 いろんなことが動いていると思います。 そこで、このサンプルを実行してみます。 つまり、チャット アプリケーションが起動され、舞台裏で Pub/Sub メッセージングが使用されます。 NCache。 そのため、私が実際に行うことは、ここに戻ってサーバー側でいくつかのパフォーマンス カウンターを表示することです。これにより、Pub/Sub メッセージと SignalR が Pub/Sub を使用していることを具体的に管理および監視できるようになります。舞台裏でのサブメッセージング。 では、SignalR と言わせてください。 お気づきかと思いますが、ここにはメッセージングセクションがあります。 メッセージ ストアのサイズ、メッセージ数、XNUMX 秒あたりの配信数、XNUMX 秒あたりの期限切れ、公開済み、トピック数が表示されます。

トピックを使用すると、関心を分離することができます。 複数のアプリケーションを使用して NCache として SignalR Backplane 内部に複数のトピックが作成されるでしょう NCache。 したがって、同様の性質のメッセージのトピックを別のトピックに割り当てることができます。 たとえば、注文に関するトピックを作成できます。 顧客にメッセージを送信するためのトピックを作成できます。 したがって、異なるトピックに異なるメッセージを含めることができ、別のトピックに接続しているサブスクライバーには、自分に関連するメッセージのみが表示されます。 したがって、ここですでにいくつかのアクティビティが確認されています。これは、アプリケーションが起動して実行中であることを意味します。 したがって、サーバー ダッシュボードに戻ると、現在 XNUMX つのアプリケーションが実行されています。 通常の統計には何も表示されません。 メッセージング統計ですべてがわかります。 したがって、メッセージ数を確認できます。

いくつかのメッセージがあり、ストア サイズは約 800 バイトです。 メッセージが公開されましたが、有効期限がまだないため、日付の他のパラメータは存在しないと思います。

そこで、アプリケーションに戻って、これの別のインスタンスを実行します。 わかりました、それでは 2 つの申請があります。 シークレットモードで実行する必要がありましたが、これを送信するとすぐにテストメッセージが送信され、ここにも送信されます。 メッセージ XNUMX をテストすると、反対側にもそのメッセージが表示されます。ここに戻ってきたら、ここで何らかのアクティビティが行われています。

したがって、舞台裏で Pub/Sub メッセージングを使用し、バックプレーンを作成できるようにします。 そのため、SignalR 自体、そのユースケースでは、ユーザーにコンテンツをプッシュできるユーザーポーリングではなく、プッシュ通知に重点を置いています。 ただし、Web ファームでは、その Web サーバーに接続されているクライアントにのみコンテンツをプッシュできるという制限があります。 複数の Web サーバーがある場合は、中央本体と ASP.NET および ASP によるバックプレーンが必要です.NET Core それを解決します。

だから、使用することができます NCache そのためのバックプレーンとして。 すべてのメッセージが中継されるコミュニケーション プラットフォームです。 NCache、 に送信された NCache その後 NCache 次に、すべての Web サーバーに送信してブロードキャストし、最終的にそれらの Web サーバーはそれらのメッセージをエンド ユーザーに送信できるようになります。 これがアーキテクチャ全体を非常に高速にする理由です。 NCache メモリ内にあります。 非常に高速で、拡張性が高く、信頼性が高く、可用性が高くなります。

わかった。 したがって、この点では我々はうまくいっていると思います。 質問は？ それ以外の場合は、次に進み、データ キャッシュの側面について説明します。 したがって、最後の 10 ～ 15 分は、データ キャッシュと一部の機能に時間を費やします。 この面では多くの機能があります。 ということで、早速いくつか紹介していきたいと思います。

まず第一に、使用できる方法はたくさんあります NCache データベース キャッシュまたはアプリ データ キャッシュ用。 データをキャッシュする場所 NCache 旅行をバックエンド データベースに保存します。 すでに IDistributedCache を使用している場合は、非常に限定的ではありますが、プラグインできます。 NCache プロバイダーとして。

ここにサンプルアプリケーションがあります。 繰り返しますが、とてもシンプルです。 NuGet パッケージを追加する必要があります。 それはASPです.NET Core & NCache.Microsoft.Extensions.Caching。

public async Task<IActionResult> onPostResetCachedTime()
{
    var currentTimeUTC = DateTime.UtcNow.ToString();
    byte[] encodedCurrentTimeUTC = Encoding.UTF8.GetBytes(currentTimeUTC);
    var options = new DistributedCacheEntryOptions()
        .SetAbsoluteExpiration(TimeSpan.FromSeconds(20));
    _cache.Set("cachedTimeUTC", encodedCurrentTimeUTC, options);

    return RedirectToPage();
}

これで IDistributedCache について説明しました。次に、キャッシュの名前を指定し、プラグインするstartup.cs内でアプリ設定が必要になります。NCacheDistributedCache は config を通じて設定を指定するか、オプション XNUMX を使用して config を指定し、コードを通じてすべての設定を直接指定することもできます。

public void ConfigureServices(IServiceCollection services)
    {
        // Reading NCacheSettings using appsettings.json
        services.AddNCacheDistributedCache(_config.GetSection("NCacheSettings"));

        services.AddMvc().SetCompatibilityVersion(Microsoft.AspNetCore.Mvc.CompatibilityVersion.Version_2_2);
    }

そして、index.html.cs にはいくつかのメソッドがあります。 ここでcache.GetAsyncを呼び出しています。

public string CachedTimeUTC { get; set; }
public async Task OnGetAsync()
{
    CachedTimeUTC = "Cached Time Expired";
    var encodedCachedTimeUTC = await _cache.GetAsync("cachedTimeUTC");

    if(encodedCachedTimeUTC != null)
    {
        CachedTimeUTC = Encoding.UTF8.GetString(encodedCachedTimeUTC);
    }
}

そして、注意する必要があるのは、この IDistributedCache インターフェイスです。たとえば、GetAsync を示すと、バイト配列が返されます。 したがって、取得するのはシリアル化または逆シリアル化されたオブジェクトではありません。 シリアル化と逆シリアル化を自分で行う必要があります。

using System.Threading;
using System.Threading.Tasks;

namespace Microsoft.Extensions.Caching.Distributed
{
public interface IDistributedCache
{
    byte[] Get(string key);
    Task<byte[]> GetAsync(string key, CancellationToken token = default);
    void Refresh(string key);
    Task RefreshAsync(string key, CancellationToken token = default);
    void Remove(string key);
    Task RemoveAsync(string key, CancellationToken token = default);
    void Set(string key, byte[] value, DistributedCacheEntryOptions options);
    Task SetAsync(string key, byte[] value, DistributedCacheEntryOptions options, 
    CancellationToken token = default);
}
}

このサンプルで行ったことは、実際には、追加する前にオブジェクトをシリアル化し、取得した後にオブジェクトを逆シリアル化するという方法で実行しました。 したがって、これを通じて文字列を取得します。

public string CachedTimeUTC { get; set; }
public async Task OnGetAsync()
    {
        CachedTimeUTC = "Cached Time Expired";
        var encodedCachedTimeUTC = await _cache.GetAsync("cachedTimeUTC");

        if(encodedCachedTimeUTC != null)
        {
            CachedTimeUTC = Encoding.UTF8.GetString(encodedCachedTimeUTC);
        }
    }

つまり、それは私たちが広範囲に取り組んできたことであり、あなたがしなければならないことです。 と NCache アプリのデータ キャッシュ プラットフォームとして直接使用する場合は、これらすべてを行う必要はありません。 NCache オブジェクトを自動的にシリアル化および逆シリアル化します。 必要なのは、それらをシリアル化可能としてマークすることだけです。

それで、このサンプルをすぐに実行して、IDistributedCache インターフェイスも紹介できるようにします。最後に、これが実行されている間にビルドもしたいと思います。これが IDistributedCache インターフェイスで、これが XNUMX 番目です。ここで示しているオプションは、直接的なものです NCache API。 API は次のとおりです。

/*Cache Connection*/
Cache cache = NCache.InitializeCache("myCache");
cache.Dispose();

/*Fetching Data*/
Employee employee = cache.Get<Employee>("Employee:1000");
bool isPresent = cache.Contains("Employee:1000");

/*Writing Data*/
cache.Add("Employee:1000", employee);
cache.AddAsync("Employee:1000", employee);

cache.Insert("Employee:1000", employee);
cache.InsertAsync("Employee:1000", employee);

Employee employee = (Employee) cache.Remove("Employee:1000");
cache.RemoveAsync("Employee:1000");

あるいは、直接経由ですべてを管理すると、より細かく制御できることを強くお勧めします。 NCache API 呼び出し。 あなたはに接続します NCache 現在のバージョンでは、キャッシュの初期化またはキャッシュの取得を使用して、アイテムを取得するには「cache.Get」と言い、アイテムを追加するには「cache.Add」を使用します。 [非同期の追加] も使用できます。 [挿入] と [非同期の挿入] も使用でき、その後、cache.Remove を呼び出すことができます。 これは、このサンプルが実行され、IDistributedCache がサポートされたら紹介する XNUMX 番目のアプローチです。しかし、当社の直接 API は、比較するとより広範な機能が豊富です。

質問： 使えますか NCache API と IDistributedCache のサンプルはどこで入手できますか?

したがって、まず第一に、IDistributedCache を使用できます。 すでに IDistributedCache を使用している必要があります。 それで、プラグインできます NCache そのソースとして。 したがって、これを出発点として、さらに同じアプリケーション内で直接 API の使用を開始することもできます。 それで、はい、それができます。 どちらか一方を使用するという制限はありません。 セッション キャッシュ、応答キャッシュ、 SignalR Backplane、IDistributedCache または直接 NCache API 呼び出し。 これら XNUMX つの機能は、すべて XNUMX つのアプリケーションで使用することもできます。 それが美しさなのです NCache これらすべてのユースケースを組み合わせることができます。

サンプル アプリケーション、これらのサンプルはすべて、次のものがインストールされています。 NCache、 右。 したがって、ここではカスタムのものは何も使用していません。 したがって、これらはすべてプログラム ファイル サンプルで利用可能です。 NCache サンプル。 これらは弊社ウェブサイトでも公開しております。

これで、このサンプルは実行されました。 したがって、キャッシュ時間をリセットすると、それが実行され、すぐにここに戻ってくると、キャッシュ キーが表示され、さらにいくつかのキャッシュ キーが表示されます。 いくつかのアイテムの有効期限が切れていると思いますが、キャッシュ時間は UTC と表示されます。 一部の応答キャッシュ オブジェクトの有効期限が切れている必要があります。

これが、IDistributedCache インターフェイスを使用する方法です。 NCache.

今回はダイレクトを紹介します NCache API 呼び出し。これを強くお勧めします。 それはあなたにもできることです。 したがって、これには、 Alachisoft.NCache.SDK NuGet パッケージ。 これが完全な SDK で、クライアント側のリソース全体が取り込まれ、この SDK を使用してすべての機能をクライアント側で公開できます。これに基づいて、これらの名前空間を含めることができます。 Alachisoft.NCache。クライアント 含めることもできます Alachisoft.NCache。ランタイム それを通じて使用できる高度な機能がいくつかあるからです。

using Alachisoft.NCache.Runtime;
using Alachisoft.NCache.Sample.Data;
using Alachisoft.NCache.Client;
using System;
using System.Configuration;
using Alachisoft.NCache.Runtime.Caching;

namespace Alachisoft.NCache.Samples
{
    public class BasicOperations
    {
        private static ICache _cache;
    }
}
...

Iキャッシュインターフェイス。 これは IDistributedCache とは異なり、独自のインターフェイスです。 したがって、比較してわかるように、当社には多くの機能があり、その中にも複数の機能があります。 これらは ICache 上のいくつかのオブジェクトです。

したがって、キャッシュを初期化できます。 初期化は次のように行われます NCache。クライアント. CacheManager.GetCache、そうやって繋がっていくんですね。 キャッシュ ハンドルを取得し、そのキャッシュ ハンドルを使用して、時間ベースの有効期限を設定できます。 この場合顧客であるオブジェクトを与えてください、 オブジェクトをキャッシュに追加 そして顧客を獲得しています。 次に、cache.Add というキーと値の項目が追加されます。 したがって、顧客オブジェクトはキャッシュに追加する間に自動的にシリアル化され、cache.Get を通じて取得し、cache.Insert を通じて更新し、一部の値を変更できます。 有効期限を変更すると、cache.Remove を呼び出してデータも削除できます。

それでは、このサンプル内で簡単に説明します。 よし。 つまり、アプリの設定からキャッシュを取得しています。 このキャッシュの名前を ASP コア キャッシュにすると、データ キャッシュにも同じキャッシュが使用され始めます。別のアプリケーション内で同じキャッシュを使用したことはすでにおわかりでしょうが、それが XNUMX つの大きなアプリケーションの場合、これらすべての機能を相互に連携させたり、組み合わせたりすることもサポートされています。

したがって、これが実行されている間、多くの機能があります。 これらは基本的な操作にすぎず、キャッシュにデータが追加されるため、サンプルでは XNUMX つまたは XNUMX つだけを示しています。 いつでも止まらないかもしれません、よくわかりませんが、見てみましょう。 その間、XNUMX つのクライアントが接続されていることを示します。 何らかの操作が行われましたね。 それを願いましょう。 どこかにブレークポイントを置いて、もう一度実行してみましょう。

つまり、実際に行ったことは、実際にキャッシュを初期化し、オブジェクトを追加し、取得し、更新し、再度取得し、削除してからキャッシュを破棄するということでした。 したがって、破棄する前にブレークポイントを設定したので、初期化、追加、フェッチ、詳細の更新、キャッシュ内の更新が確認できると思います。 したがって、これらのメソッドはすべて実行されました。

したがって、このサンプルを実行するのは非常に簡単です。 必要なのは、NuGet パッケージと含める名前空間だけです。その後、ここで紹介するさまざまな API を試してみましょう。

多くの機能が利用可能です。 最後の 5 ～ 6 分間は、直接のサービスの一部として利用できるさまざまな機能について説明します。 NCache API。 したがって、時間ベースの有効期限を使用できます。 絶対有効期限とスライド有効期限が利用可能です。 絶対とは、事前に時間を指定し、その時間が経過するとデータが削除される場合です。 スライディングとは、そのデータを使用し続ける場合、10 分間のスライディング有効期限があるとします。そのアイテムに 10 分間アクセスしなかった場合、そのアイテムは削除されます。 それ以外の場合、そのオブジェクトを使用し続けると、そのオブジェクトはキャッシュ内に残ります。

キャッシュをデータベースと同期できます。 キャッシュされたアイテムのコンテンツに変更があった場合。 たとえば、キャッシュされたアイテムのデータベース レコードの変更などです。 データベースに属するアイテムをキャッシュしている場合、データベースに変更が加えられると、そのアイテムはキャッシュから無効になります。これにはイベント ベースの SQL 依存関係があります。 DB ベースの依存関係と、ポーリング ベースの DB ポーリング依存関係があります。 変更をプールし、データベース内の一部のレコードが変更されたことを検出すると、対応する項目をキャッシュから削除します。 .NET CLR ストアド プロシージャ。直接作成できる NCache API はデータベース サーバーから直接呼び出します。 キャッシュを非リレーショナル データベースと同期することもできます。 ファイルの依存関係が利用可能です。 キャッシュ項目をファイルに依存させることができます。 または、コード登録を実行するカスタム依存関係である可能性もあります。 NCache そしてそれによって、その項目をキャッシュから期限切れにする必要があるかどうかが決まります。 したがって、ビジネス ロジックに基づいて、キャッシュからアイテムを期限切れにすることができます。 キーベースの依存関係があります。 これを使用して、キャッシュされたアイテム間の関係を処理できます。 したがって、XNUMX 対 XNUMX、XNUMX 対多、および多対多の関係を内部で管理できます。 NCache.

サーバー側のサポート、コードのサポートは非​​常に広範囲にわたっています。 キャッシュ アサイド パターンを使用することも、キャッシュからキャッシュに読み取るリードスルー パターンとライトスルー パターンを使用することもできます。データがキャッシュにない場合は、プロバイダーを実行してキャッシュを介して読み取ることができます。 これは、ユーザーが実装して登録するインターフェースであり、キャッシュを読み取ってアイテムを取得したり、バックエンド データベースからアイテムを破壊したりできます。

ライトスルーはその逆で、キャッシュを更新すると、ライトスルー ハンドラーを呼び出すことでバックエンド データベースを自動的に更新することもできます。これは、実装して登録し、ライトビハインドでバックエンド データベースを非同期に更新するインターフェイスです。これは比較すると非常に高速であり、書き込み操作の必要もなく、キャッシュ項目がキャッシュ内で更新されるだけでアプリケーションが戻り、舞台裏でキャッシュがバックエンドデータベースを更新します。

グループ、サブグループが利用可能です。 内部に論理コレクションを作成できます NCache。 タグがサポートされています。 アイテムにキーワードを付けることができ、対応するタグに基づいてアイテムを取得、削除、フェッチしたり、遊んだり、検索したりすることもできます。

SQL Like 検索が利用可能です。 SQL および LINQ 検索がサポートされています。 属性に基づいてアイテムを検索できます。 検索条件を実行できます。これは、product がオブジェクト タイプである select products のようなもので、product.price が 10 より大きく、product .price が 100 未満である select products のようになります。つまり、指定した条件に基づいて、 NCache アプリケーションでの結果セットを定式化します。

また、LINQ クエリもサポートされています。 これらは並列です。 データのインデックス作成はこの一環としてサポートされています。 非常に高速に検索できるようにするために、これが必須として必要です。 NCache.

Pub/Subメッセージングとイベント

Pub/Sub メッセージングとイベントは別の機能です。 私たちは、非同期イベント駆動の Pub/Sub メッセージング プラットフォームを持っています。 条件ベースの継続クエリがあり、データ セットをマッピングし、そのデータ セットからイベントを取得できます。 たとえば、製品価格が 100 未満のすべての製品をマッピングできます。つまり、それがデータ セットになる可能性があります。 そのデータセットに変更があった場合は、通知が届きます。

主要なベースイベントが利用可能です。 したがって、アイテムが更新または削除された場合、またはすべてのアイテムが監視されているキャッシュ レベルの場合に通知を受け取ることができます。

動的キャッシュクラスター

最後に、いくつかの詳細について NCache クラスタリング。 これは動的キャッシュ クラスタリング プロトコルに基づいています。 NCache サーバーをオンザフライで追加または削除できます。 したがって、単一障害点はありません。 サーバーがダウンした場合でも、プロトコル内で管理されます。 さらにサーバーを追加すると、新しく追加されたサーバーを使用して自動的に起動します。 サーバーがダウンしても、その場合でもダウンタイムは発生しません。主に、このキャッシュをホストしているサーバーが複数あるため、単一障害点がありません。

アプリケーションに関する限り、サーバーの追加と削除はシームレスです。 100% の稼働時間を実現し、可用性の高いキャッシュ シナリオを実現します。トポロジについてはすでに説明しました。

私たちはいくつかあります クライアントキャッシュ. WANレプリケーション 特徴。 アクティブ/アクティブ サイトまたはアクティブ/パッシブ サイト間でサイト間のレプリケーションを行うことができます。 それも管理されています。

リストはまだ続くことがわかります。 多くの詳細を説明したと思いますが、実際にどのように活用できるかについて簡単に概要を説明したいと思います。 NCache ASPで.NET Core。 さて、私たちはすでにこのプレゼンテーションの終わりに向かっています。 XNUMX時間マーカーだと思います。

この辺で終わりにさせていただきたいと思います。ここまでで何かご質問がございましたら、お知らせください。そうでない場合は、ザックに渡して、彼はそこからそれを受け取ることができます。質問は？フロアを 1 分間ほど開いたままにします。質問がある場合、またはまだ考えている場合は、遠慮なく質問してください。

ここまでの作業で、目にするこれらすべての機能をほぼカバーしました。 ASP.NET Core セッション、応答キャッシュ、 SignalR Backplane、IDistributedCache、データ キャッシュ、および直接 NCache API 呼び出しのほか、Pub/Sub メッセージング用のサンプル アプリケーションもあります。このセクションに別途興味がある場合は、別のサンプル アプリケーションも入手できます。

質問： このプレゼンテーションは後で利用できるようになりますか?

はい、そうなります。 ウェビナーの録画を入手できるだけでなく、ダウンロードして使用したい場合はスライドも用意します。準備ができたら、録画したウェビナーへのリンクをメールでお送りします。 そのため、ライブ配信後はいつでも当社の Web サイトにアクセスでき、録画されたウェビナーを見つけることができます。

質問： IDistributedCache と IDistributedCache の違いは何ですか NCache ASP.NET Core セッションストアプロバイダー?

さて、質問は IDistributedCache を介したセッションの使用と、キャッシュ プロバイダーを介したセッションの使用の違いに焦点を当てていると思います。 したがって、大まかに言えば、IDistributedCache は機能が制限されています。 NCache プロバイダーを使用すると、より詳細な制御が可能になります。 まず第一に、セッション ロックを使用できます。 IDistributedCache セッションは非ロック ベースのストアです。 シングルサイトセッションとマルチサイトセッションを使用できます。 それは内部の特別な機能です NCache これは IDistributedCache では利用できません。 それでも、 NCache IDistributedCache セッション プロバイダーをそのままサポートします。 IDistributedCache に加えて多くの利点が得られますが、IDistributedCache セッションと比較すると、 NCache あなたが知っています、 NCache セッションストアプロバイダー NCache、そこです NCache プロバイダーには明確な優位性があります。 さらに、異なるアプリケーション間でのセッション共有など、多くの機能があります。 指定できるセッション アプリ ID 属性があります。 例外をイベント ログに記録したり、キャッシュ ログを作成したり、クライアント ログを作成したりできます。 したがって、これら XNUMX つには異なる機能の膨大なリストがあります。

したがって、セッション キャッシュを使用している場合は、次のことを強くお勧めします。 NCacheしたがって、個人的には、セッション ストア プロバイダーを IDistributedCache Session と比較してレビューすることをお勧めします。 NCache たくさんのメリットが得られるからです。

質問： データをグループ化すると、どのようにしてデータの検索が容易になるのでしょうか?

右。 したがって、グループを複数のアイテムにアタッチすると、グループ データを取得するグループ ベースの API があり、それらのすべてのアイテムを一度に取得できます。 したがって、これらの個々のオブジェクトのキーを個別に与える必要はありません。 そのため、XNUMX 回の API 呼び出しですべてのグループ データを取得できます。 XNUMX 回の API 呼び出しでデータを削除できます。 つまり、取得と更新のプロセスが比較して簡単であるということです。