1.6. サイト全体でのクライアント接続
クライアントは、Active/Passive または Active/Active 設定のいずれかで Data Grid クラスターに書き込みできます。
Active/Passive
以下の図は、Data Grid が 1 つのサイトのみからのクライアント要求を処理する Active/Passive を示しています。
上記のイメージでは、以下のようになります。
- クライアントは LON で Data Grid クラスターに接続します。
- クライアントは "k1" をキャッシュに書き込みます。
- LON のサイトマスター n1 は、k1 をレプリケートする要求を NYC のサイトマスター nA に送信します。
Active/Passive では、NYC はデータの冗長性を提供します。LON の Data Grid クラスターが何らかの理由でオフラインになると、クライアントは NYC への要求の送信を開始できます。LON をオンラインに戻すと、NYC とデータを同期し、クライアントを LON に戻すことができます。
Active/Active
以下の図は、Data Grid が 2 つのサイトでクライアント要求を処理する Active/Active を示しています。
上記のイメージでは、以下のようになります。
- クライアント A は、LON で Data Grid クラスターに接続します。
- クライアント A は "k1" をキャッシュに書き込みます。
- クライアント B は、NYC の Data Grid クラスターに接続します。
- クライアント B は "k2" をキャッシュに書き込みます。
- LON および NYC のサイトマスターは、"k1" が NYC に複製され、"k2" が LON に複製されるように要求を送信します。
Active/Active では、NYC と LON の両方は、クライアント要求の処理中にデータをリモートキャッシュに複製します。NYC または LON のいずれかがオフラインになると、クライアントはオンラインサイトへの要求の送信を開始できます。その後、オフラインサイトをオンラインに戻し、状態をプッシュしてデータを同期し、必要に応じてクライアントを切り替えることができます。
バックアップストラテジー
Active/Active 設定では、常に非同期バックアップストラテジー (strategy=async) を使用する必要があります。
複数のクライアントが同じエントリーに同時に書き込もうとし、バックアップストラテジーが同期 (strategy=sync) の場合、デッドロックが発生します。ただし、両方のサイトが異なるデータセットにアクセスする場合、Active/Passive 設定で同期バックアップストラテジーを使用できます。この場合、同時書き込みによるデッドロックのリスクはありません。
1.6.1. 同時書き込みおよび競合エントリー
クライアントが同時に同じエントリーに書き込むが、サイトが異なる場合は、Active/Active サイト設定でエントリーの競合が発生する可能性があります。
たとえば、クライアント B が NYC の k1 に書き込むのと同時に、クライアント A は LON の "k1" に書き込みます。この場合、"k1" の値は LON と NYC とで異なります。レプリケーションの発生後、"k1" のどの値がどのサイトに存在するかは保証されません。
データの整合性を確保するために、Data Grid はベクトルクロックアルゴリズムを使用して、次の図のように、バックアップ操作中に競合するエントリーを検出します。
LON NYC
k1=(n/a) 0,0 0,0
k1=2 1,0 --> 1,0 k1=2
k1=3 1,1 <-- 1,1 k1=3
k1=5 2,1 1,2 k1=8
--> 2,1 (conflict)
(conflict) 1,2 <--
ベクトルクロックは、エントリーへの書き込みごとにインクリメントするタイムスタンプのメタデータです。上記の例では、0,0 は、"k1" 上のベクトルクロックの初期値を表します。
クライアントは LON に "k1=2" を配置し、ベクトルクロックは 1,0 で、Data Grid はこれを NYC に複製します。その後、クライアントは NYC に "k1=3" を配置し、ベクタークロックは 1,1 に更新されます。Data Grid はこれを LON に複製します。
ただし、クライアントが NYC に "k1=8" を配置するのと同時に、クライアントが LON に"k1=5" を配置すると、Data Grid は競合するエントリーを検出します。これは、"k1" のベクター値が LON と NYC の間で厳密に大きかったり小さかったりしないためです。
競合するエントリーを見つけると、Data Grid は Java compareTo(String anotherString) メソッドを使用してサイト名を比較します。どのキーが優先されるかを決定するために、Data Grid は辞書式順序で他のキーよりも小さいサイト名を選択します。AAA という名前のサイトからのキーは、AAB という名前のサイトからのキーよりも優先されます。
同じ例に従って、"k1" の競合を解決するために、Data Grid は LON からの "k1" の値を使用します。これにより、Data Grid が競合を解決し、値を複製した後に、LON と NYC の両方で "k1=5" となります。
競合するエントリーを解決するための優先順位を表す簡単な方法として、サイト名の前に番号を付けます。たとえば、1LON や 2NYC などです。
Data Grid は、非同期バックアップストラテジ (strategy=async) のみを使用して競合解決を実行します。ただし、同時書き込みはデッドロックになるため、Active/Active 設定で同期バックアップストラテジーを使用しないでください。
競合解決アルゴリズム
Data Grid は、カスタム競合解決ストラテジーを実装できる XSiteEntryMergePolicy SPI に加えて、競合を解決するためのさまざまなアルゴリズムを提供します。
辞書式比較を使用するデフォルトの競合解決ストラテジーとは別に、Data Grid の競合解決アルゴリズムを使用して次のことができます。
- 競合するエントリーを常に削除します。
- 書き込み/削除の競合が発生したときに書き込み操作を保持します。
- 書き込み/削除の競合が発生したときにエントリーを削除します。
org.infinispan.xsite.spi.XSiteMergePolicy 列挙で、利用可能なすべてのアルゴリズムとその説明を検索します。
