検索

1.6. サイト全体でのクライアント接続

download PDF

クライアントは、Active/Passive または Active/Active 設定のいずれかで Data Grid クラスターに書き込みできます。

Active/Passive

以下の図は、Data Grid が 1 つのサイトのみからのクライアント要求を処理する Active/Passive を示しています。

上記のイメージでは、以下のようになります。

  1. クライアントは LON で Data Grid クラスターに接続します。
  2. クライアントは "k1" をキャッシュに書き込みます。
  3. LON のサイトマスター n1 は、k1 をレプリケートする要求を NYC のサイトマスター nA に送信します。

Active/Passive では、NYC はデータの冗長性を提供します。LON の Data Grid クラスターが何らかの理由でオフラインになると、クライアントは NYC への要求の送信を開始できます。LON をオンラインに戻すと、NYC とデータを同期し、クライアントを LON に戻すことができます。

Active/Active

以下の図は、Data Grid が 2 つのサイトでクライアント要求を処理する Active/Active を示しています。

上記のイメージでは、以下のようになります。

  1. クライアント A は、LON で Data Grid クラスターに接続します。
  2. クライアント A は "k1" をキャッシュに書き込みます。
  3. クライアント B は、NYC の Data Grid クラスターに接続します。
  4. クライアント B は "k2" をキャッシュに書き込みます。
  5. LON および NYC のサイトマスターは、"k1" が NYC に複製され、"k2" が LON に複製されるように要求を送信します。

Active/Active では、NYCLON の両方は、クライアント要求の処理中にデータをリモートキャッシュに複製します。NYC または LON のいずれかがオフラインになると、クライアントはオンラインサイトへの要求の送信を開始できます。その後、オフラインサイトをオンラインに戻し、状態をプッシュしてデータを同期し、必要に応じてクライアントを切り替えることができます。

バックアップストラテジー

重要

Active/Active 設定では、常に非同期バックアップストラテジー (strategy=async) を使用する必要があります。

複数のクライアントが同じエントリーに同時に書き込もうとし、バックアップストラテジーが同期 (strategy=sync) の場合、デッドロックが発生します。ただし、両方のサイトが異なるデータセットにアクセスする場合、Active/Passive 設定で同期バックアップストラテジーを使用できます。この場合、同時書き込みによるデッドロックのリスクはありません。

1.6.1. 同時書き込みおよび競合エントリー

クライアントが同時に同じエントリーに書き込むが、サイトが異なる場合は、Active/Active サイト設定でエントリーの競合が発生する可能性があります。

たとえば、クライアント B が NYC の k1 に書き込むのと同時に、クライアント A は LON の "k1" に書き込みます。この場合、"k1" の値は LONNYC とで異なります。レプリケーションの発生後、"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" のベクター値が LONNYC の間で厳密に大きかったり小さかったりしないためです。

競合するエントリーを見つけると、Data Grid は Java compareTo(String anotherString) メソッドを使用してサイト名を比較します。どのキーが優先されるかを決定するために、Data Grid は辞書式順序で他のキーよりも小さいサイト名を選択します。AAA という名前のサイトからのキーは、AAB という名前のサイトからのキーよりも優先されます。

同じ例に従って、"k1" の競合を解決するために、Data Grid は LON からの "k1" の値を使用します。これにより、Data Grid が競合を解決し、値を複製した後に、LONNYC の両方で "k1=5" となります。

ヒント

競合するエントリーを解決するための優先順位を表す簡単な方法として、サイト名の前に番号を付けます。たとえば、1LON2NYC などです。

注記

Data Grid は、非同期バックアップストラテジ (strategy=async) のみを使用して競合解決を実行します。ただし、同時書き込みはデッドロックになるため、Active/Active 設定で同期バックアップストラテジーを使用しないでください。

競合解決アルゴリズム

Data Grid は、カスタム競合解決ストラテジーを実装できる XSiteEntryMergePolicy SPI に加えて、競合を解決するためのさまざまなアルゴリズムを提供します。

辞書式比較を使用するデフォルトの競合解決ストラテジーとは別に、Data Grid の競合解決アルゴリズムを使用して次のことができます。

  • 競合するエントリーを常に削除します。
  • 書き込み/削除の競合が発生したときに書き込み操作を保持します。
  • 書き込み/削除の競合が発生したときにエントリーを削除します。

org.infinispan.xsite.spi.XSiteMergePolicy 列挙で、利用可能なすべてのアルゴリズムとその説明を検索します。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.