NCache アーキテクチャ

NCache は、.NET、Java、Node.js、Python 用のオープンソースのインメモリ分散ストアです。 NCache は非常に高速で直線的に拡張できるため、高トランザクションのサーバー アプリケーションに最適です。 使用 NCache パフォーマンスのボトルネックを解消し、アプリケーションをエクストリーム トランザクション処理 (XTP) まで拡張します。 NCache また、高可用性を実現するインテリジェントなデータ レプリケーションと動的クラスタリングも提供します。

NCache は 2005 年以来非常に人気があり、世界中の何百ものハイエンド顧客が使用しています。

 

動的クラスター (高可用性)

NCache ピアツーピアアーキテクチャに基づく自己修復動的キャッシュクラスタリングを備えており、100%の稼働時間を提供します。 これはTCPベースのクラスターであり、マスター/スレーブノードはなく、代わりにクラスター内のすべてのサーバーがピアです。 これにより、キャッシュまたはアプリケーションを停止することなく、実行時にクラスターからキャッシュサーバーを追加または削除できます。

 

ピアツーピア クラスター (自己修復)

NCache クラスタにはピアツーピア クラスタ アーキテクチャがあります。 これは、マスター/スレーブ ノードがなく、各サーバーがピアであることを意味します。 クラスター内で最も古いノードであるクラスター コーディネーター ノードがあります。 クラスター コーディネーター ノードがダウンすると、次に古いノードが自動的にコーディネーターになります。

クラスター コーディネーターは、ノードの追加または削除時のクラスター メンバーシップ、分散マップなど、クラスター関連のすべての操作を管理します。 パーティション化されたキャッシュ / パーティション-レプリカキャッシュ トポロジー、およびその他のキャッシュ構成情報。 Cluster Coordinatorは、クラスターの正常性も管理し、クラスター内の他のすべてのサーバーに部分的に接続されているキャッシュサーバーを強制的に削除します。

 

動的クラスタリング

NCache ています 動的クラスタリングアーキテクチャ。 これはあなたができることを意味します 加えます or 削除します キャッシュやアプリケーションを停止することなく、クラスターからキャッシュ サーバーを削除できます。 キャッシュ サーバーを追加または削除すると、クラスター メンバーシップは実行時にすぐに更新され、クラスター内のすべてのサーバーおよびクラスターに接続されているすべてのクライアントに伝播されます。 このランタイムの更新と伝播により、 NCache そのような変更が行われているときでも、常に稼働していること。

動的クラスタリングを使用すると、次のことができます。

  • - 実行時のキャッシュサーバーの追加/削除: キャッシュやアプリケーションを停止せずに
  • - クラスターのメンバーシップ: は実行時に更新され、クラスター内のすべてのサーバーとクラスターに接続されているすべてのクライアントに伝播されます。
 

スプリット ブレイン クラスターの処理

別の部分 NCache 動的クラスタリングはそのインテリジェントな機能です スプリットブレインの検出と回復 能力。 スプリット ブレインは基本的に、ネットワークの問題によりこれらのキャッシュ サーバー間のネットワーク接続が切断され、その結果複数の独立したサブクラスターが発生し、各サブクラスターが他のすべてのキャッシュ サーバーがダウンし、それが正しい残りのクラスターであると想定するときに発生します。 。

そのような場合、 NCache サーバーは、他のキャッシュ サーバーが突然クラスターから離脱したことに気づき、再接続を試み続けます。 その後、ネットワークの問題が解決すると、これらの NCache サーバーは他のキャッシュ サーバーに再接続できます。 ただし、現在、各サブクラスターは他のキャッシュ サーバーと同期せずに並行してキャッシュを更新しているため、複数のバージョンのデータがサブクラスター全体に存在します。

NCache どのキャッシュ サーバーがデータを放棄し、他のキャッシュ サーバーがデータを保持するかを自動的に決定することで、この「スプリット ブレイン」から回復する方法を提供します。 多少のデータ損失はありますが、最終的には人間の介入なしにキャッシュ クラスターが迅速に復元されます。

 

動的クライアント接続

NCache もできます 実行時にキャッシュクライアントを追加または削除する キャッシュや他のクライアントを停止することなく。 クライアントを追加する場合、このクライアントは接続先のクラスター内のいずれかのキャッシュ サーバーについて認識するだけで済みます。 そのサーバーに接続すると、クラスターのメンバーシップとキャッシュ トポロジ情報を受信し、それに基づいて他のどのサーバーに接続するかを決定します。

  • - 実行時にクライアントを追加/削除する: キャッシュやアプリケーションを停止する必要はありません。
  • - パーティション化キャッシュ / パーティションレプリカキャッシュ: クライアントは、すべてのキャッシュ サーバーのすべてのパーティションに接続します (パーティションはレプリカと通信するため、レプリカには接続しません)。 これにより、クライアントはデータのある場所に直接アクセスして読み取りと書き込みを行うことができます。 また、新しいサーバーがクラスターに追加されると、クライアントは更新されたクラスター メンバーシップ情報を受信し、この新しく追加されたキャッシュ サーバーにも接続します。
  • - 複製されたキャッシュ: の場合には 複製されたキャッシュ、クライアントはクラスター内のXNUMXつのキャッシュサーバーに接続するだけですが、すべてのキャッシュサーバーに同じ数のクライアントがあることを保証するために負荷分散された方法で接続します。 クライアントは、このキャッシュサーバーから負荷分散情報を取得し、それに基づいて、必要に応じて適切なキャッシュサーバーに再接続します。 各サーバーにはキャッシュ全体があり、すべての読み取りと書き込みがその場で可能であるため、クライアントはXNUMXつのキャッシュサーバーにのみ接続します。
  • - ミラーリングされたキャッシュ: の場合には ミラーリングされたキャッシュ、クライアントは、この2ノードクラスター内のアクティブノードにのみ接続します。 クライアントがパッシブノードに接続する場合、パッシブノードはクライアントにアクティブノードについて通知し、クライアントは自動的にアクティブノードに再接続します。 アクティブノードがダウンしてパッシブノードがアクティブになると、すべてのクライアントが自動的に新しいアクティブノードに接続します。
 

動的構成

NCache キャッシュとクライアントの動的構成も提供します。 目的は、キャッシュまたはアプリケーションを停止することなく、後でキャッシュが実行されているときに変更を加えることができるようにすることです。

  • - 実行時にすべてのサーバーとクライアントに伝播する: これには、すべての構成とその変更、さらに配布マップが含まれます。
  • - キャッシュ構成: 管理ツールを通じてキャッシュ構成が作成されると、この構成情報はその時点で既知のすべてのキャッシュ サーバーにコピーされます。 そして、実行時に追加される新しいサーバーは、このキャッシュ構成全体を受け取り、それをローカル ディスクにコピーします。
  • - 構成変更のホット適用: 実行時にキャッシュ構成の一部を変更できます。ホットアプライ「の特徴 NCache。 これを行うと、更新された構成情報が実行時にすべてのキャッシュサーバーに伝達され、それらのディスクに保存されます。 この情報の一部は、ニーズに関連するすべてのクライアントにも送信されます。
  • - 分散マップ (パーティション化/パーティション レプリカ キャッシュ): これはキャッシュの開始時に作成され、すべてのキャッシュ サーバーとキャッシュ クライアントにコピーされます。 この分散マップには、(クラスター化キャッシュ内の合計 1000 個のバケットのうち) どのバケットがどのパーティションに配置されているかに関する情報が含まれています。
 

クラスタ内の接続フェイルオーバー

クラスタ内のすべてのキャッシュサーバーは、TCPを介して相互に接続されています。 また、すべてのキャッシュサーバーは、実行時に追加された新しいサーバーを含め、クラスター内の他のすべてのキャッシュサーバーに接続されます。 NCache 接続が切断されても、クラスター内の接続が維持されるようにするためのさまざまな方法を提供します。 接続の切断は通常、ルーターやファイアウォールによるネットワークの不具合、またはネットワークカードやネットワークドライバーの問題が原因で発生します。

  • - 接続の再試行: XNUMX つのキャッシュ サーバー間の接続が切断された場合、 NCache サーバーは、この接続を確立するために自動的に複数の再試行を行います。 これらの再試行は、「タイムアウト」期間が使い果たされるまで行われます。 ほとんどの場合、これにより接続が再確立されます。
  • - キープアライブ ハートビート: NCache また、各キャッシュサーバーが他のすべてのサーバーにハートビートとしていくつかの小さなデータパッケージを送信し続けるようにする機能もあります。 これにより、ネットワークソケットの破損の問題が発生した場合に、キャッシュサーバーがそれを認識し、再試行によって修正することが保証されます。
  • - 部分的に接続されたサーバー: 再試行にもかかわらず、タイムアウト期間内に接続が復元されず、キャッシュ サーバーが他の XNUMX つ以上のキャッシュ サーバーがダウンしていると判断する場合があります。 したがって、それらがなくても動作し続けます。 しかし、実際には他のサーバーはダウンしておらず、実際にはクラスター内の他のサーバーから認識されています。 これは、部分的に接続されたサーバーと呼ばれます。 これが発生すると、クラスター コーディネーターはこれを記録し、「部分的に接続された」サーバーをクラスターから強制的に削除します。 これを行うと、クラスターが再び正常な状態になります。 また、削除されたサーバーは、手動介入によってクラスターに再参加できます。
 

クライアントとの接続フェイルオーバー

すべてのキャッシュクライアントは、キャッシングトポロジに応じて、TCPを介してクラスター内のXNUMXつ以上のキャッシュサーバーに接続されます。 パーティション化/パーティション-レプリカキャッシュの場合、各クライアントはすべてのキャッシュサーバーに接続されます。 レプリケートされたキャッシュの場合、各クライアントは通常、キャッシュサーバーで使用される負荷分散アルゴリズムを介してキャッシュサーバーのXNUMXつに接続されます。 また、ミラーリングされたキャッシュの場合、すべてのクライアントはアクティブノードにのみ接続され、アクティブノードがダウンしてパッシブノードがアクティブノードになったときにのみパッシブノードに接続します。

  • - 接続の再試行: クライアントとキャッシュ サーバー間の接続が切断された場合、 NCache クライアントが自動的に実行します 複数回の接続再試行 この接続を確立します。 これらの再試行は、「タイムアウト」期間が使い果たされるまで行われます。 ほとんどの場合、これにより、クライアントアプリケーションが気付くことなく接続が再確立されます。 接続を確立できない場合は、クライアントアプリケーションに例外がスローされ、クライアントアプリケーションで処理できるようになります。
  • - キープアライブ ハートビート: NCache また、各クライアントがいくつかの小さなデータパッケージを次のように送信し続けるようにする機能もあります ハートビート 接続されているすべてのキャッシュサーバーに接続します。 これにより、ネットワークソケットの破損の問題が発生した場合に、クライアントはそれを認識し、接続の再試行によって修正することができます。
  • - 部分的に接続されたクライアント (パーティション化された/パーティション レプリカ キャッシュ): 再試行にもかかわらず、タイムアウト期間内に接続が復元されない場合があり、キャッシュ クライアントは、他の XNUMX つ以上のキャッシュ サーバーがダウンしていなくても、それらのサーバーにアクセスできないと想定します。 そのため、パーティション/パーティション レプリカ キャッシュの場合、分散マップで通信できないサーバーにデータがあることが示されていても、すべてのデータの読み取りまたは書き込みのために他のサーバーと対話します。 この場合、他のキャッシュ サーバーが仲介者として機能し、操作が正常に実行されます。
  • - サーバーとの切断 (レプリケート/ミラーリングされたキャッシュ): レプリケート キャッシュの場合、クライアントは XNUMX 台のサーバーにのみ接続され、この接続が切断されると、クライアントは自動的に他のキャッシュ サーバーの XNUMX つに接続します。 ミラー キャッシュの場合、クライアントがアクティブ ノードに接続できない場合、クライアントはダウンしているとみなしてパッシブ ノードへの接続を試みます。
 

キャッシュ トポロジ (線形スケーラビリティ)

NCache さまざまなキャッシングトポロジを提供して、データの一貫性と信頼性を維持しながら線形スケーラビリティを実現します。 これの目標は、非常に小さいXNUMXサーバーキャッシュで実行されているアプリケーションから、数十または数百のキャッシュサーバーで構成される非常に大きいキャッシュクラスターのニーズに対応することです。 キャッシングトポロジは、基本的に、複数のキャッシュサーバーにまたがるクラスター化されたキャッシュでのデータストレージ、データレプリケーション、およびクライアント接続戦略です。

 

参照データとトランザクションデータ

参照データはあまり頻繁に変更されないデータであり、キャッシュして何度も何度もアクセスし、ときどき更新します。 一方、トランザクションデータは非常に頻繁に変更されるデータであり、読み取るたびに更新することができます。

初期の頃、キャッシュは主に参照データに適していると考えられていました。これは、頻繁に変更されるデータは古くなり、データベース内の最新データと同期が取れなくなるためです。 しかし、 NCache キャッシュがデータベースとの同期を維持できるようにする非常に強力な機能を提供するようになりました。

すべてのキャッシュ トポロジは参照データに適していますが、トランザクション データに特に適しているのは一部のキャッシュ トポロジだけです。 どのトポロジが最適かを判断するには、読み取りと書き込みの回数を決定する必要があります。 さらに、一部のキャッシュ トポロジは、特に更新の場合はあまり拡張できないため、その点にも留意してください。

以下は、キャッシュトポロジと、読み取りと書き込みへの影響のリストです。

  • - パーティション化されたキャッシュ (レプリケーションなし): とても良い。 読み取りと書き込みの両方で超高速であり、サーバーを追加することで線形に拡張します。 最速のトポロジですが、データを複製しないため、キャッシュサーバーがダウンした場合にデータが失われます。
  • - パーティション-レプリカキャッシュ (最も人気のある): とても良い。 読み取りと書き込みの両方が超高速で、サーバーを追加することで直線的に拡張できます。 XNUMX 番目に速いトポロジですが、線形スケーラビリティを損なうことなく、信頼性を高めるためにデータを複製します。 速度/スケーラビリティとデータの信頼性の最適な組み合わせ。
  • - 複製されたキャッシュ: 小規模な環境に最適。 超高速で、読み取りに関して線形にスケーラブルです。 2 ノード クラスターでの書き込みは適度に高速ですが、書き込みはすべてのキャッシュ サーバーで同期して行われるため、サーバーを追加しても拡張できません。
  • - ミラーリングされたキャッシュ: 小規模な環境に非常に適しています。 読み取りが超高速。 2 ノード アクティブ/パッシブのレプリケート キャッシュよりも書き込みが高速です。 ただし、これを超えるスケールにはなりません。
  • - クライアントキャッシュ: 読み取り中心の使用に非常に適しています すべてのキャッシュ トポロジで。 分散キャッシュを使用して InProc 速度を実現できます。
 

パーティション化されたキャッシュ

パーティション化されたキャッシュは、読み取りと書き込みの両方で最も高速でスケーラブルなキャッシュトポロジです。 これは大規模なキャッシュクラスターを対象としており、ピーク負荷の下でも読み取りと書き込みのパフォーマンスは非常に良好です。 ただし、データを複製しないため、キャッシュサーバーがダウンするとデータが失われます。

パーティション化されたキャッシュのいくつかの特徴は次のとおりです。

  • - 動的パーティション: キャッシュは実行時にパーティションに分割され、各キャッシュ サーバーには 1000 つのパーティションがあります。 クラスター化キャッシュごとに合計 XNUMX 個のバケットがあり、すべてのパーティションに均等に分散されます。 キャッシュ サーバーを追加/削除すると、実行時にパーティションが作成/削除されます。 データがキャッシュに追加されるときに、パーティションへのバケットの割り当ては変更されません。 代わりに、パーティションが追加または削除されたとき、またはデータ バランシングが発生したときにのみ変更されます (以下を参照)。
  • - 分布図: キャッシュ クラスターは、どのバケットがどのパーティションに存在するかに関する情報を含む分散マップを作成します。 分散マップは、パーティションが追加または削除されるたび、またはデータ バランシングが発生するたびに更新されます (以下を参照)。 配布マップはすべてのサーバーとクライアントに伝播されます。 クライアントはこれを使用して、特定のキャッシュされたアイテムの読み取りまたは書き込みのためにどのキャッシュ サーバーと通信するかを判断します。
  • - 動的データバランシング: すべてのバケットは実際には、キーのハッシュ アルゴリズムに基づいてデータが保存される HashMap バケットであるため、使用されたキーに応じて、一部のバケットに他のバケットよりも多くのデータが含まれる可能性があります。 この不均衡が設定可能なしきい値を超えた場合、 NCache この負荷のバランスをとるために、バケットを自動的に移動します。
  • - クライアントはすべてのパーティションに接続します: クライアントはすべてのキャッシュ サーバーに接続するため、サーバーからの XNUMX つのリクエストでデータを直接読み書きできます。 クライアントとキャッシュ サーバーとの接続がダウンすると、クライアントは他のサーバーの XNUMX つに、アクセスできないサーバー上に存在するキャッシュされたアイテムの読み取りまたは書き込みを要求します。 そして、そのサーバーはクライアントがそれを達成するのに役立ちます。
 

パーティション-レプリカキャッシュ

注:パーティション化されたキャッシュで言及されていることはすべて、ここでも当てはまります。

と同じように パーティション化されたキャッシュ、Partition-Replica Cacheは、読み取りと書き込みの両方で非常に高速で線形にスケーラブルなキャッシュトポロジです。 これは大規模なキャッシュクラスターを対象としており、ピーク負荷の下でも読み取りと書き込みのパフォーマンスは非常に良好です。 さらに、Partition-Replica Cacheはデータを複製するため、キャッシュサーバーがダウンしてもデータが失われることはありません。

パーティション-レプリカキャッシュは私たちの 最も人気のあるキャッシングトポロジ パフォーマンス/線形スケーラビリティとデータの信頼性の両方の長所を提供するためです。

以下は、Partition-ReplicaCacheの特徴の一部です。

  • - 動的パーティション: パーティション化キャッシュと同じ。
  • - 動的レプリカ: 実行時にパーティションが作成または削除されると、そのレプリカも作成または削除されます。 レプリカは常に別のキャッシュ サーバー上にあり、パーティションにはレプリカが XNUMX つだけ存在します。
  • - 非同期レプリケーション: デフォルトでは、パーティションからレプリカへのレプリケーションは非同期です。 これは、クライアントがパーティション内のデータを追加、更新、または削除でき、これらの操作はすべてキューに入れられることを意味します。 そして、それらはレプリカ上に一括で複製されます。 これによりパフォーマンスは向上しますが、パーティションが切断され、すべての更新がレプリカにレプリケートされていない場合には、データが失われる可能性が若干あります。 しかし、ほとんどの状況では、これでまったく問題ありません。
  • - 同期レプリケーション: データが非常に機密性が高く (財務データなど)、古いデータを保持する余裕がない場合は、設定で「同期レプリケーション」オプションを選択できます。 選択すると、すべての書き込み操作は、完了したとみなされるまでパーティションとレプリカの両方で同期的に実行されます。 このようにすると、レプリカで操作が失敗した場合、パーティションでも操作が失敗します。 また、キャッシュ (パーティションとレプリカの両方) 内のすべてのデータが常に一貫していることを保証できます。 ただし、これは非同期レプリケーションよりも遅いため、パフォーマンスに影響します。
  • - 分布図: パーティション化キャッシュと同じ。
  • - 動的データバランシング (パーティションとレプリカ): パーティション化キャッシュと同じ。 ただし、パーティション レプリカ キャッシュでは、パーティションのデータ バランシングが行われると、レプリカでもデータ バランシングが行われます。
  • - クライアントはすべてのパーティションに接続します: パーティション化キャッシュと同じ。 さらに、パーティション レプリカ キャッシュでは、クライアントはパーティションのみと通信し、レプリカとは通信しません。 これは、レプリカがパッシブであり、データをレプリカにレプリケートするときにパーティションのみがレプリカと通信するためです。
 

複製されたキャッシュ

レプリケート キャッシュは、2 つ以上のキャッシュ サーバーでのレプリケーションを通じてデータの信頼性を提供します。 読み取りが非常に高速でスケーラブルです。 ただし、書き込みはクラスター内のすべてのサーバーと同期しているため、書き込みに対しては拡張できません。 3 ノード クラスターの場合、書き込みはデータベースよりも高速ですが、パーティション レプリカ キャッシュほど高速ではありません。 XNUMX つ以上のサーバー クラスタの場合、書き込みパフォーマンスが低下し、最終的には魅力的ではなくなります。

以下は、レプリケートされたキャッシュの特徴の一部です。

  • - 動的に複製されたノード: キャッシュやアプリケーションを停止することなく、実行時に既存のキャッシュにキャッシュ サーバーを追加または削除できます。 新しく追加されたサーバーは、それ自体にキャッシュ全体のコピー (レプリカ) を作成します。 また、削除されたサーバーはクラスターのメンバーシップを更新し、そのすべてのクライアントが他のサーバーに移動します。
  • - 各ノードのキャッシュ全体: キャッシュ全体がクラスター内のすべてのサーバーにコピーされます。
  • - 読み取りはスケーラブルです: サーバーを追加すると、読み取りが超高速でスケーラブルになります。 ただし、新しく追加されたサーバーはキャッシュ全体のコピーにすぎないため、サーバーを追加してもキャッシュ サイズは増加しません。
  • - 書き込みは同期的です: 書き込みは 2 ノード クラスターとしては非常に高速であり、データベースよりも高速です。 ただし、書き込みは同期的であるため、すべてのキャッシュ サーバーが同期的に更新されるまで各書き込み操作は完了しません。 このため、書き込みは他のトポロジほど高速ではなく、クラスター サイズを 2 ノードを超えて増やすとパフォーマンスが低下します。
  • - クライアントは XNUMX つのサーバーのみに接続します: 各キャッシュ クライアントは、キャッシュ サーバーによって決定された負荷分散アルゴリズムに基づいて、クラスター内の XNUMX つのサーバーにのみ接続します。 このキャッシュ サーバーがダウンすると、クライアントはリスト内の次のサーバーに接続します。 負荷分散を使用したくない場合は、キャッシュ構成ファイルで接続するサーバーを手動で指定することもできます。
 

ミラーリングされたキャッシュ

Mirrored Cache は、小規模な環境向けの 2 ノードのアクティブ/パッシブ キャッシュ クラスターです。 アクティブ ノードからパッシブ ノードへの非同期レプリケーション/ミラーリングを通じてデータの信頼性を提供します。 読み取りと書き込みの両方が非常に高速です (実際、書き込みはレプリケート キャッシュより高速です) が、この 2 ノードのアクティブ/パッシブ クラスターを超えて拡張することはできません。

以下は、ミラーリングされたキャッシュの特徴の一部です。

  • - 1 つのアクティブ サーバーと 1 つのパッシブ サーバー: ミラーキャッシュには XNUMX つのサーバーしかありません。 XNUMX つはアクティブ、もう XNUMX つはパッシブです。 どちらもキャッシュ全体のコピーを持っています。 アクティブ サーバーがダウンすると、パッシブ サーバーが自動的にアクティブになります。 また、以前にダウンしたアクティブ サーバーが復旧した場合、実行時に管理ツールを使用してこの指定を変更しない限り、そのサーバーはパッシブ サーバーとして扱われます。
  • - フェイルオーバーをサポートするクライアント接続: 各キャッシュ クライアントは、読み取りおよび書き込み操作を行うためにクラスター内のアクティブ サーバーにのみ接続します。 このアクティブ サーバーがダウンすると、すべてのクライアントは、その時点でアクティブになっているパッシブ サーバーに自動的に接続します。 このフェイルオーバー サポートにより、サーバーがダウンした場合でもミラー キャッシュが常に稼働していることが保証されます。
  • - 非同期ミラーリング: アクティブ サーバー上で行われた書き込みはすべて、パッシブ サーバーに非同期にミラーリング/レプリケートされます。 これにより、アクティブ サーバーがダウンしてパッシブ サーバーがアクティブになる必要がある場合に、パッシブ サーバーが常に最新のデータと同期されることが保証されます。 非同期ミラーリングは、パッシブ サーバー上で複数の書き込みが BULK 操作として実行されるため、パフォーマンスが向上することも意味します。
 

クライアントキャッシュ(InProc Speed)

クライアントキャッシュはWeb/アプリサーバーに対してローカルであり、アプリケーションの非常に近くにあり、分散キャッシュ(任意のキャッシュトポロジ)から読み取っているデータをキャッシュできます。 これは「キャッシュ上のキャッシュ」と見なすことができ、アプリケーションのパフォーマンスとスケーラビリティをさらに大幅に向上させます。 InProcモードでクライアントキャッシュを使用すると、InProcの速度を実現できます。

アプリケーションに対してローカルである間、クライアントキャッシュはスタンドアロンではありません。 代わりに、常にクラスター化されたキャッシュと同期されます。 これにより、クライアントキャッシュ内のデータが古くなることはありません。

以下は、ミラーリングされたキャッシュの特徴の一部です。

  • - 読み取りが多いケースに適しています注: クライアント キャッシュは、読み取り回数が書き込み回数の何倍も多い、読み取り集中型の使用例がある場合にのみ適しています。 書き込み数が読み取り数と同じ場合、書き込みには XNUMX つの場所での更新が含まれるため、クライアント キャッシュは実際には遅くなります。
  • - ローカルキャッシュと同様に高速(InProc / OutProc): クライアント キャッシュは、アプリケーション プロセス内 (InProc モード)、または Web/アプリ サーバーのローカル (OutProc モード) に存在します。 どちらの場合でも、クラスター化されたキャッシュからこのデータをフェッチするだけと比較して、アプリケーションのパフォーマンスが大幅に向上します。 InProc モードでは、オブジェクトを「アプリケーション ヒープ」にキャッシュできるため、どの分散キャッシュにも匹敵しない「InProc 速度」が得られます。
  • - スタンドアロンのキャッシュではない: クライアント キャッシュはローカル キャッシュである可能性がありますが、スタンドアロン キャッシュではありません。 代わりに、クラスター化されたキャッシュとの同期を維持します。 これが意味するのは、クライアント キャッシュにあるクラスター化キャッシュ内のデータを別のクライアントが更新すると、クラスター化キャッシュは、そのデータの最新コピーで自身を更新するようにクライアント キャッシュに通知するということです。 そして、これは非同期で即座に行われます。
  • - 楽観的/悲観的同期: デフォルトでは、クライアント キャッシュはオプティミスティック同期を使用します。つまり、 NCache クライアントは、クライアントキャッシュにあるデータがすべて最新のコピーであると想定します。 クライアントキャッシュにデータがない場合、クライアントはクラスター化されたキャッシュからデータをフェッチし、クライアントキャッシュに配置して、クライアントアプリケーションに返します。 ペシミスティック同期とは、キャッシュクライアントが最初にクラスター化キャッシュをチェックして、キャッシュされたアイテムの新しいバージョンがあるかどうかを確認することを意味します。 含まれている場合、クライアントはそれをフェッチし、クライアントキャッシュに入れて、クライアントアプリケーションに返します。 それ以外の場合は、クライアントキャッシュにあるものをすべて返します。
  • - コード変更なしのプラグイン: クライアント キャッシュの最も優れた点は、アプリケーションのコード変更が必要ないことです。 代わりに、構成変更を通じてプラグインするだけです。 そして、 NCache 舞台裏のクライアントAPIは、クライアントキャッシュの使用について何をすべきかを知っています。

次はどうする?

お問い合わせ(英語)

電話
©著作権 Alachisoft 2002 - . All rights reserved. NCache はダイヤテック株式会社の登録商標です。