クライアントキャッシュ
NCache クラスタトポロジは、アプリケーションに最高のパフォーマンスとスケーラビリティを提供することを目的としています。 ビジネスニーズの高まりに伴い、アプリケーションはより多くのクライアント要求とデータを処理する必要があります。 分散キャッシュにノードをシームレスに追加すると、線形のスケーラビリティが提供されます。 ハードウェアプロセッサキャッシュと同様に、クライアントキャッシュは、アプリケーションのプロセス内であっても、ホットデータセットをアプリケーションに近づけることで、アプリケーションのパフォーマンスをより高いレベルに引き上げます。 InProcモード.
電子商取引アプリケーションの例を考えてみましょう。アプリケーションは、製品カタログと現在アクティブなユーザーのデータに頻繁にアクセスします。このようなデータは、クライアント ボックス上で実行されているクライアント キャッシュに保存できます。一方で、このデータをクライアント キャッシュに保持すると、データベースやクラスター化されたキャッシュへのトリップが回避され、アプリケーションのパフォーマンスが向上します。一方、クラスター キャッシュがより多くのリクエストを受信できるようにすることで、クラスター キャッシュから多くの読み取り/書き込み操作をオフロードします。また、このパフォーマンスの向上は、データの一貫性を損なうことなく実現されます。クライアント キャッシュは、そのデータをクラスター キャッシュと同期させます。クライアント キャッシュがクラスター キャッシュと同期する方法については、次のセクションで説明します。
プラグ&プレイ: クライアントキャッシュの使用は非常に簡単です。 アプリケーション側でコードを変更する必要はありません。 これは単純な構成オプションです。 クライアントキャッシュは、 NCache 管理センター または NCache サポートされているPowershellコマンドレット。クライアントが構成されると、クライアント アプリケーションは自動的にその使用を開始します。すでに実行中のアプリケーションの場合は、アプリケーションを再起動する必要があります。
すべて CRUD操作 キャッシュキーを入力として受け取る Add, 入手, インセット, 削除します、クライアント キャッシュを通じてルーティングされます。 読み取り操作では、まずクライアント キャッシュ内のデータを検索します。 クライアント キャッシュはデータを返します (見つかった場合)。 それ以外の場合、読み取り操作はクラスター キャッシュに対して実行されます。 クラスター キャッシュから返されたデータは、クライアント キャッシュに追加された後にアプリケーションに返されます。 したがって、同じデータに対する次の Read 呼び出しはクライアント キャッシュから提供されます。 一括読み取り操作の場合、クライアント キャッシュに不足しているデータのみがクラスター キャッシュからフェッチされます。
次のようなキーベースの書き込み操作 Add & インセット、最初にクラスター キャッシュに対して実行されます。 正常に完了すると、データがクライアント キャッシュに追加され、アプリケーションに転送されます。 他のクライアント キャッシュ インスタンスは、バックグラウンド データ同期メカニズムを通じて更新されます。 後で説明します.
クライアント キャッシュは、クラスター キャッシュ データのサブセットのみを保持します。 したがって、次のような他のすべての非キーベースの操作は、 グループを取得, SQLクエリ, GetByTagsなどはクラスター キャッシュ上で直接実行されます。
クライアント キャッシュ: 分離モード
クライアントキャッシュは、アプリケーションが実行されているクライアントノードで実行されます。 パフォーマンスのニーズとアプリケーションアーキテクチャに応じて、クライアントキャッシュでサポートされている次のプロセスレベルの分離モードのいずれかを選択できます。
進行中
名前が示すように、クライアント キャッシュはアプリケーション プロセス内で実行され、プロセス間通信を排除します。逆シリアル化コストを回避するために、ユーザー データはオブジェクト形式で保持されます。このモードでは、アプリケーションに最大のパフォーマンスが提供されます。クライアント キャッシュはアプリケーション プロセス内でホストされるため、クライアント キャッシュ内のデータは他のアプリケーション インスタンス間で共有されません。アプリケーションの各インスタンスは、専用のクライアント キャッシュ インスタンスをホストします。 InProc モードは最大のプロセスを提供しますが、次の場合にのみ適しています。
アプリケーションのホットデータセットは大きすぎません。
アプリケーションには、十分な物理メモリを備えた各クライアント ノード上に少数のインスタンスしかありません。各クライアント キャッシュ インスタンスがデータのコピーを保持していることに注意してください。
アプリケーションのライフサイクルは、クライアントキャッシュのメリットを享受するのに十分な長さです。 クライアントキャッシュのライフサイクルは、アプリケーションのライフサイクルに依存することに注意してください。 アプリケーションがダウンすると、クライアントキャッシュ内のすべてのデータも失われます。 ライフサイクルが短いアプリケーションは、クライアントキャッシュが完全に読み込まれる前に、シャットダウンまたは再起動します。
各アプリケーションには、他のアプリケーションとは異なる独自のホットデータセットがあります。
OutProc
このモードは、クライアント キャッシュにプロセス レベルの分離を提供します。クライアント キャッシュは、クライアント ノード上の専用プロセスで実行されます。アプリケーションは、TCP ソケットを介してクライアント キャッシュと通信します。複数のアプリケーション インスタンスが同じクライアント キャッシュと通信できるため、データを共有できます。 InProc はパフォーマンスにおいて OutProc モードよりも優れていますが、OutProc モードには独自の一連の利点があります。
同じクライアントマシンで実行されている複数のアプリケーションは、同じクライアントキャッシュと通信します。 複数のアプリケーションがデータを共有します。 XNUMXつのアプリケーションによってロードまたは更新されたデータは、他のアプリケーションで使用できるようになります。
アプリケーションを再起動しても、クライアントキャッシュデータが失われることはありません。
各アプリケーション プロセスがクライアント キャッシュのコピーを保持する場合、InProc モードと比較して、OutProc モードでクライアント キャッシュを実行するために必要な RAM や CPU などの物理リソースが少なくなります。
クライアントキャッシュデータ(後で説明)をクラスターキャッシュと同期すると、クライアントマシンごとに単一のクライアントキャッシュインスタンスを実行するため、クラスターキャッシュへの負担が少なくなります。
Note
OutProc クライアント キャッシュがダウンしている場合、アプリケーションはクラスター キャッシュ上で操作を直接実行します。クライアント キャッシュが再度開始されると、自動的にクライアント キャッシュに接続されます。この動作を変更するには、 skip-client-cache-if-unavailable
フラグを立てる client.ncconf。 フラグがに設定されている場合 false
、クライアントキャッシュがダウンしている場合、キャッシュ操作は失敗します。
クラスターキャッシュとのデータの同期
プラグ アンド プレイのセットアップは簡単ですが、クライアント キャッシュにクラスター キャッシュ データのコピーが保持されているという事実を無視することはできません。クラスター キャッシュ内のデータに加えられた変更は、クライアント キャッシュに反映される必要があります。 InProc モードまたは OutProc モードで実行されている複数のクライアント キャッシュが、特定のクラスター キャッシュに存在する場合があります。クライアント アプリケーションによって行われたデータ変更は、アプリケーションが接続されているクライアント キャッシュ インスタンス上で実行されます。したがって、クライアント キャッシュのこのインスタンスは自動的に同期されます。ただし、クライアント キャッシュの他のインスタンスはこれらの変更を認識しません。クラスター キャッシュ データに加えられた変更は、以下で説明するバックグラウンド データ同期メカニズムを通じて、これらのクライアント キャッシュ インスタンスと同期されます。
データがクライアントキャッシュに追加されると、指定されたデータのクラスターキャッシュにデータ変更通知が登録されます。
クラスターキャッシュはそれぞれを追跡します
CacheItem
クライアントキャッシュがデータに加えられた変更を保持および監視すること。専用のバックグラウンド ワーカー スレッドがデータの変更を毎秒検査し、どのクライアント キャッシュに変更を通知するかを決定します。データが変更されたという通知を、影響を受けるクライアント キャッシュに送信します。
クライアント キャッシュ内で実行される別の専用のバックグラウンド ワーカー スレッドは、データ変更通知の受信時にデータ変更をクラスター キャッシュと同期する役割を果たします。通知を受け取るとすぐに、クラスター キャッシュを要求し、データを要求します。 更新情報。この同期メカニズムをクライアント キャッシュ ポーリングと呼びます。
クライアント キャッシュで実行されているこのワーカー スレッドは、クラスター キャッシュから通知を受信していない場合、クライアント キャッシュとクラスター キャッシュの間の接続損失により通知を見逃した可能性がある場合に対処するために、10 秒ごとにデータ変更をポーリングします。
この強力な同期メカニズムにより、クライアントアプリケーションには、パフォーマンスとスケーラビリティが追加されたクライアントキャッシュからの最新データが常に提供されます。
同期モード
バックグラウンドデータ同期メカニズムに加えて、クライアントキャッシュは次のXNUMXつの同期モードをサポートします。
楽観的な同期
これは、クライアントキャッシュのデフォルトの同期モードです。 アプリケーションがクライアントキャッシュからデータをフェッチし、クライアントキャッシュがそのデータを保持している場合、データは単にアプリケーションに返されます。 上で説明したように、同期はバックグラウンドで実行されます。
悲観的な同期
バックグラウンド同期メカニズムは、ほとんどのアプリケーションに適しており、アプリケーションに最適なパフォーマンスとスケーラビリティを提供します。ただし、より機密性が高く、常に最新のデータが提供されるようにしたいアプリケーションの場合は、悲観的モードが設計されています。このモードでは、アプリケーションがクライアント キャッシュからデータをフェッチし、クライアント キャッシュがそのデータを保持する場合、クライアント キャッシュはクラスター キャッシュを使用してアイテムのバージョンを検証します。データの更新バージョンがクラスター キャッシュで見つかると、それがフェッチされてクライアント キャッシュに更新されます。したがって、アプリケーションは最新バージョンの CacheItem
.