Red Hat Summit2.3. クライアントのインテリジェンス
Hot Rod クライアントのインテリジェンスとは、リクエストを効率的にルーティングするために Data Grid サーバーを見つけるメカニズムを指します。
BASIC インテリジェンス
クライアントは、Data Grid クラスターまたはキーハッシュ値に関する情報を保存しません。
トポロジー対応
クライアントは、Data Grid クラスターに関する情報を受信し、保存します。クライアントは、サーバーがクラスターに参加またはクラスターから離脱するたびに変更するクラスタートポロジーの内部マッピングを維持します。
クラスタートポロジーを受信するには、クライアントには、起動時に少なくとも 1 つの Hot Rod サーバーのアドレス(IP:HOST)が必要です。クライアントがサーバーに接続すると、Data Grid はトポロジーをクライアントに送信します。サーバーがクラスターに参加またはクラスターから離脱すると、Data Grid は更新されたトポロジーをクライアントに送信します。
ディストリビューション対応
クライアントはトポロジーに対応し、キーの一貫したハッシュ値を保存します。
たとえば、put (k,v) 操作を取ります。クライアントはキーのハッシュ値を計算して、データが存在する正確なサーバーを見つけられるようにします。その後、クライアントは所有者に直接接続して操作をディスパッチできます。
ディストリビューション対応インテリジェンスの利点は、Data Grid サーバーがキーハッシュに基づいて値を検索する必要がないことです。これは、サーバー側で使用するリソースが少なくなることです。もう 1 つの利点は、サーバーが追加のネットワークラウンドトリップをスキップするため、クライアント要求により迅速に応答することです。
2.3.1. バランシングの要求
topology-aware インテリジェンスを使用するクライアントは、すべてのリクエストに対してリクエストバランシングを使用します。デフォルトのバランシングストラテジーはラウンドロビンであるため、トポロジー対応のクライアントは常にラウンドロビン順でサーバーにリクエストを送信します。
たとえば、s1、s2、s3 は Data Grid クラスターのサーバーです。クライアントは以下のようにリクエストバランシングを実行します。
CacheContainer cacheContainer = new RemoteCacheManager();
Cache<String, String> cache = cacheContainer.getCache();
//client sends put request to s1
cache.put("key1", "aValue");
//client sends put request to s2
cache.put("key2", "aValue");
//client sends get request to s3
String value = cache.get("key1");
//client dispatches to s1 again
cache.remove("key2");
//and so on...分散対応インテリジェンスを使用するクライアントは、失敗したリクエストにのみ要求の分散を使用します。リクエストが失敗すると、分散対応のクライアントは次に利用可能なサーバーでリクエストを再試行します。
カスタムバランシングポリシー
FailoverRequestBalancingStrategy を実装し、以下のプロパティーを使用して hotrod-client.properties 設定でクラスを指定できます。
infinispan.client.hotrod.request_balancing_strategy
2.3.2. クライアントフェイルオーバー
Hot Rod クライアントは、Data Grid クラスタートポロジーが変更されたときに自動的にフェイルオーバーできます。たとえば、トポロジー対応の Hot Rod クライアントは、1 つ以上の Data Grid サーバーに障害が発生したことを検出できます。
クラスター化された Data Grid サーバー間のフェイルオーバーに加えて、HotRod クライアントは Data Grid クラスター間でフェイルオーバーをすることができます。
たとえば、ニューヨーク (NYC) で実行している Data Grid クラスターと、ロンドン (LON) で実行している別のクラスターがあるとします。NYCに要求を送信するクライアントは、使用可能なノードがないことを検出したため、LONのクラスターに切り替えます。その後、クライアントは、手動でクラスターを切り替えるか、フェイルオーバーが再度発生するまで、LONへの接続を維持します。
フェイルオーバーを伴うトランザクションキャッシュ
putIfAbsent()、replace()、remove() などの条件付きオペレーションには、厳密なメソッドの戻り保証があります。同様に、一部のオペレーションでは、以前の値を返さないといけない場合があります。
Hot Rod クライアントはフェイルオーバーが可能ですが、トランザクションキャッシュを使用して、操作が部分的に完了せず、異なるノードに競合するエントリーが残らないようにする必要があります。
