永続性を備えた分散キャッシュ
NCache 必要に応じて貴重なデータを確実に取得するために、メモリ内の永続ストアを備えたキー値分散キャッシュを提供します。 キャッシュ データのコピーを永続ストアに保持し、後でキャッシュの再起動 (計画的または計画外) で永続化されたデータをロードします。 キャッシュ サーバーが保持できる限りのデータを格納してロードします。 永続性によりデータの高可用性が保証され、同時にメモリ内データにより高いパフォーマンスが提供されます。 このドキュメントでは、永続性を備えた分散キャッシュを永続キャッシュとも呼びます。
Note
永続性を備えた分散キャッシュのみがサポートされます パーティション化されたトポロジ & ローカル (OutProc) キャッシュ.
を使用して、永続性のある分散キャッシュを作成できます。 NoSQL データ バックアップ用の永続ストアとしてのドキュメント ストア。 キャッシュには、すべての書き込み API、メタ情報、 ストリーム, データ構造, 動的インデックス バックエンドストアへ。
Note
Pub/Sub メッセージは永続化されませんが、 NCache サポート パブリッシュ/サブスクライブAPI 専用の Pub/Sub メッセージング キャッシュ.
データの無効化または明示的な削除によってキャッシュから削除されたデータは、基盤となる永続ストアからも削除されることに注意してください。 有効期限とキーの依存関係を持つアイテムの追加がサポートされています。 ただし、このような永続キャッシュ内に保存されるデータは永続的なデータであるため、このアプローチはお勧めしません。 一方、データ データベースへの依存 また、外部ソースへの依存関係は永続的に設定されていません。
Note
揮発性の分散キャッシュと同様に、バッキング ソースは永続性を備えた分散キャッシュでサポートされています。
データを永続化する理由
NCache アクセスを高速化するためにデータを RAM に保存します。 キャッシュ メモリは揮発性であるため、次のシナリオではデータ損失が避けられません。
- パーティション化されたトポロジでノードがダウンしました。
- パーティション レプリカ トポロジで同時に複数のノードがダウンします。
- メンテナンス上の理由または致命的な障害によりクラスターがダウンします。
永続キャッシュを使用すると、次のことを実現できます。
高いデータ可用性: 前述のいずれかの理由によるメモリ障害の場合、 NCache 基盤となる永続ストアからデータをロードすることで、データを迅速に回復します。 キャッシュは、致命的な障害が発生した後でも、クライアントの動作に影響を与えることなく動作可能になります。
フォールトトレランス: キャッシュ データのリアルタイム コピーを維持することで、ダウンタイムを最小限に抑え、単一または複数のノードがクラスターを離れた場合のフォールト トレランスを提供します。
重要
永続性のために、キーの長さは 1023 バイトを超えてはなりません。
仕組み
ここでは、永続性を備えた分散キャッシュの動作と動作について説明します。 以下の図は、基本的なアーキテクチャを示しています。 バックエンドに永続ストアを使用して、永続性を備えた分散キャッシュを作成できます。 ストアは一元化されており、すべてのノードからアクセスできます。 NCache キャッシュに追加されたデータを、維持可能な時間間隔でバックエンド ストアに書き込みます。 キャッシュの再起動時またはノードの脱退/参加時に、キャッシュ サーバーが保持できる限り、永続化されたデータがメモリにロードされます。
以下では、データの永続化と読み込みの詳細なプロセスについて説明します。
データの永続性
永続性を備えた分散キャッシュを作成すると、すべての書き込み操作が最初にメモリ内で実行され、次にバックエンド ストアに永続化されます。 以来 NCache は分散アーキテクチャを備えており、すべてのサーバー ノードがストアにアクセスできる間、各サーバー ノードはデータを保持します。 さらに、パーティションによりデータ分散がバケットベースであるため、データも同様に永続化されます。
非同期永続性
NCache 非同期永続性を通じてメモリ内のデータを永続ストアに永続化します。 ここではその仕組みを説明します。 各パーティションには、実行されたクライアント操作を記録する永続キューがあります。 クライアントによって実行された書き込み操作は、成功するとキューに入れられます。 永続化は非同期で機能するため、クライアントは操作をキューに入れてから待機しません。 キューに入れられた操作は、設定可能な間隔で定期的にチェックされます。 persistence-interval
そして最終的には永続スレッドによってバックエンド ストアにレプリケートされます。 各キューは独立して書き込まれます。
Note
のデフォルト値 persistence-interval
is 1秒 そしてそれはで設定可能です NCache 管理センター.
通常、バッチは後で適用されます persistence-interval
、ただし、永続化バッチが連続して失敗した場合、その後 persistence-retries
バッチ間隔は にシフトされます persistence-interval-longer
. 成功すると、バッチ間隔はにリセットされます persistence-interval
.
重要
非同期レプリケーションにより、クライアント操作は通常どおり行われるため、キャッシュのパフォーマンスは低下しません。
何らかの問題によりキャッシュが永続キュー内にデータを永続化できない場合、キャッシュがいっぱいになるまで書き込み操作が継続されます。 キューに入れられた操作が持続しない場合、失敗したバケットに関する情報がキャッシュ ログに記録されます。
Note
パーティション - レプリカ トポロジは、レプリカのキューを通じてキュー障害から回復します。 ただし、ノードとそのレプリカが同時にダウンした場合、データ損失は避けられません。
データの読み込み
データがストアに格納されると、キャッシュは、キャッシュの再起動時に永続化されたデータを RAM に自動的に再読み込みします。 永続ストアは、ノードをキャッシュするために常に使用できる必要があります。 ストアにアクセスできない場合、キャッシュは開始されません。 データのロードは分散方式で行われます。 データ ストレージはバケット ベースの手順であるため、各ノードは集中ストアにアクセスして、データ分散マップに基づいて割り当てられたバケットをロードできます。 さらに、キャッシュ内のデータをクエリするためのインデックスを構成した場合、キャッシュの再起動時にクエリ インデックスが再生成されます。
重要
永続ストアは、常にすべてのキャッシュ ノードで使用できる必要があります。
データロード時の動作動作
データの読み込みと永続化のプロセスは同時に実行されます。 一方、要求されたデータが読み込まれると、キーベースのフェッチがキャッシュから提供されます。 キャッシュにない場合、そのような操作は、遅延読み込みによってストアから直接提供されます。 その場合、 Get
動作に影響が出ます。
次のような、キーベースまたは条件ベースの検索操作ではないことに注意してください。 GetGroupKeys
, GetKeysByTag
、および SQL クエリは、データがストアからメモリに完全に読み込まれるまで提供されません。
警告
データの読み込み中に非キーベースの検索操作が発生し、要求されたデータが完全に読み込まれない場合、アプリケーションは例外をスローします。 データが永続ストアから完全にロードされていない.
データ読み込みのシナリオ
次のシナリオでは、永続ストアからデータがロードされます。
キャッシュ開始時: キャッシュの開始時に、コーディネーター ノードはすべてのバケットを読み込みます。 他のノードがクラスターに参加するとすぐに、バケットの分散が更新されます。 各ノードは、割り当てられたバケットをローカル環境で探します。 キャッシュにロードされたバケットはプルスルーされます 状態転送. ノードに割り当てられたバケットが完全にロードされない場合、それらのバケットはそのノードによってストアから直接ロードされます。 各ノードは、キャッシュに存在する場合、割り当てられたバケットをロードするためにストアにアクセスできます。
永続性を備えた分散キャッシュが初めて開始されるとき、構成によってデータを取り込むことができます。 キャッシュスタートアップローダー その時点で永続ストアにはデータがないためです。 ストアが読み込まれると、キャッシュ ローダーを構成した場合でも、データは常にキャッシュの開始時にストアから読み込まれます。 ただし、定期的にデータを追加する必要がある場合は、 キャッシュリフレッシャー. キャッシュ リフレッシャーは、キャッシュとストアに既にデータがあるかどうかに関係なく、定期的に実行されます。
ノード参加時: 新しいノードがクラスターに参加すると、既存のクラスター ノードが既にロードされている場合は、状態転送を通じて割り当てられたバケットを既存のクラスター ノードから取得します。 割り当てられたバケットがキャッシュに完全にロードされない場合、それらは新しいノードによってストアからロードされます。
ノード離脱時: ノードがクラスターから離れるときのデータ損失を避けるために、データはストアからロードされます。 ノード離脱時のロード動作は、トポロジによって異なります。
パーティション化されたトポロジ: ノードが離れると、そのバケットは既存のクラスター ノードに分散され、新しい所有者によって永続ストアからロードされます。
パーティション-レプリカ トポロジ: パーティション レプリカは、レプリカからの状態転送を通じて失われたバケットを回復することで、最大 XNUMX レベルのノード障害を許容します。 ただし、ノードとそのレプリカが同時にダウンした場合でも、失われたデータはバックアップ ストアから回復できます。
重要
キャッシュには、ノードのダウン/離脱の場合にデータを収容できる容量が必要です。
永続性を備えた分散キャッシュの容量管理
永続キャッシュは、キャッシュに離脱したノードのデータを収容するのに十分なクッションがある場合にのみ、ノードの離脱時または停止時のデータ損失から回復できます。 キャッシュがいっぱいであるか、その他の理由により、永続ストア上のすべてのデータを収容できない場合、追加または更新操作は失敗し始めます。 一方、一部のバケットには完全なデータがありません。 これらの不完全なバケットは、次の XNUMX つの場合にストアからリロードされます。
- 新しいノードがクラスターに参加します。
- キャッシュ サイズはホット アプライによって増加します。
Note
キャッシュがいっぱいでも永続ストアと 100% 同期している場合、新しい追加のみがブロックされます。 他のすべての操作は、キャッシュ上で問題なく発生する可能性があります。
メモリ内の部分的なデータでキャッシュがいっぱいになると、キャッシュは非キー ベースまたは基準ベースの操作 ( GetGroupKeys
, GetKeysByTag
、および SQL クエリ)。 一方、キーベースのフェッチは、常にキャッシュまたはストアを介して提供されます。 具体的には、キャッシュ ミスの場合、キャッシュは不完全なバケットのすべてのキーベースの取得を遅延ロードしようとします。
警告
基準ベースの検索操作がキャッシュがいっぱいのときに行われ、要求されたデータがキャッシュにない場合、例外がスローされます キャッシュにすべてのデータがメモリ内にないため、操作を実行できません.
キャッシュがいっぱいの場合のキャパシティプランニング
キャッシュがいっぱいになったときに発生する問題を回避するには、使用を開始する前に永続キャッシュの容量を計画する必要があります。 永続性を備えた分散キャッシュのキャパシティ プランニングを行う場合、ノードがダウンした場合に残りのノードが失われたノードのすべてのデータに対応できるように、ノードごとのキャッシュのサイズを計画することをお勧めします。
キャッシュフル時のキャッシュサイズ拡張
重要
NCache 単一ノード上のデータの高可用性を確保しようとすると、サイズ拡張による永続性を備えたパーティション レプリカ ベースの分散キャッシュに残ります。 ただし、高いデータ可用性が約束または保証されているわけではありません。
パーティション レプリカの場合、ノードがクラスターから離脱すると、クラスター内の残りのノードが、離脱したノードが所有するデータを収容します。 ただし、サイズの問題により、離脱するノードからのデータにスペースがない可能性があります。 NCache ノードが永続性のあるパーティション レプリカ ベースの分散キャッシュを離れるときの自動キャッシュ サイズ拡張をサポートします。 拡張モードは、単一ノードが停止している場合にのみサポートされます。 その目的は、キャッシュ内の部分的なデータを回避し、完全なキャッシュに対して条件に基づく操作を提供することです。
拡張プロセスは内部で発生します。 拡張モードは、実行中のノードが構成されたノード以上であるときに、単一のノードがクラスターを離れたときにトリガーされます。 展開されたサイズは、クラスター内の構成済みノードまたは実行中のノード (いずれか大きい方) に基づいて計算されます。 キャッシュが拡張モードの場合、クラスタ内の各ノードは、ノードの脱退時に状態転送を通じて受信したデータに対応するために、そのサイズを自動的に拡大します。
重要
拡張は、(ノードがダウンした後) 残りのノードの数が以下の場合にのみ発生します。 最大{構成済みノード/実行中ノード}-1。 拡張サイズは、クラスター内の構成されたノードまたは実行中のノード (どちらか大きい方) に基づいて計算されます。
拡張モードでは、キーと条件に基づく操作の両方が提供されます。 ただし、キャッシュ サイズが構成済みのキャッシュ サイズを一度超えた場合、追加操作は引き続きブロックされます。
新しいノードがクラスタに参加するか、キャッシュ サイズがホット アプライによって増加すると、キャッシュは拡張モードから抜け出します。 次に、分散マップが更新され、状態転送がトリガーされます。 状態の転送が完了すると、各ノードは拡張モードから抜け出し、キャッシュ サイズは構成されたキャッシュ サイズに縮小されます。
Note
キャッシュが拡張モードに入って存在すると、キャッシュ ログとイベント ログの両方にエントリが記録されます。
アクセシビリティ不能の動作
データはキャッシュの起動時に永続ストアからロードされるため、ノードを一貫してキャッシュするためにストアを使用できる必要があります。 ここでは、永続ストアにアクセスできない場合の動作について説明します。
- キャッシュ作成時: ストアへの接続は、キャッシュの作成時に検証されます。 アクセスできない場合、キャッシュを作成できず、エラー通知を受け取ります。 同様に、どのクラスター ノードでもストアを使用できない場合、キャッシュは開始されません。
警告
キャッシュの作成時にすべてのサーバー ノードが永続ストアにアクセスできるようになるまで、キャッシュは開始されません。
データロード時: ネットワーク障害により、データのロード中にストアにアクセスできなくなる場合があります。 その場合、キャッシュはロード中の残りのデータ バケットのロードを再試行します。 一方、非キーベースの検索操作は失敗します。 あなたはできる データロードの再試行を構成する サービス構成ファイルで。
キャッシュ実行時: ネットワーク障害が原因で、実行中のキャッシュが短時間または無期限にストアにアクセスできなくなる場合があります。 このような接続が失われた場合、キャッシュは書き込み操作を受け入れてキューに入れ続けます。 その間、 NCache 永続ストアへの接続が再確立されるまで、バッチ間隔でキューに入れられた操作を永続化しようとし続けます。
接続が無限に失われると、キャッシュ メモリがいっぱいになるまで書き込み操作が行われます。 キャッシュがいっぱいになると、後続の書き込み操作は失敗します。 ただし、キーベースのフェッチ操作は、前に説明したように提供されます。
永続キャッシュの作成と監視
Note
永続性を備えた分散キャッシュでは、JSON のシリアル化されたキャッシュのみがサポートされます。
新しいストアまたは既存のストア ( NCache) のいずれかを介して NCache 管理センター またはを通じて PowerShellツール.
NCache 異なるを提供します パフォーマンスカウンター 分散キャッシュの統計を永続的に監視するため。 さらに、次のことができます。 分散キャッシュを永続的に監視する スルー NCache モニター、PowerShell、および PerfMon ツール。