6.4.2. キーの所有者
分散キャッシュは、エントリーを固定数のセグメントに分割し、各セグメントを所有者ノードの一覧に割り当てます。レプリケートされたキャッシュは同じで、すべてのノードが所有者である場合を除きます。
所有者リストの最初のノードはプライマリ所有者です。一覧のその他のノードはバックアップの所有者です。キャッシュトポロジが変更するると、ノードがクラスターに参加またはクラスターから離脱するため、セグメント所有権テーブルがすべてのノードにブロードキャストされます。これにより、ノードはマルチキャスト要求を行ったり、各キーのメタデータを維持したりすることなく、キーを見つけることができます。
numSegments プロパティーでは、利用可能なセグメントの数を設定します。ただし、クラスターが再起動しない限り、セグメントの数は変更できません。
同様に、キーからセグメントのマッピングは変更できません。鍵は、クラスタートポロジーの変更に関係なく、常に同じセグメントにマップする必要があります。キーからセグメントのマッピングは、クラスタートポロジーの変更時に移動する必要のあるセグメント数を最小限に抑える一方で、各ノードに割り当てられたセグメント数を均等に分散することが重要になります。
KeyPartitioner を設定するか、Grouping API を使用してキー間のマッピングをカスタマイズできます。
ただし、Red Hat Data Grid は以下の実装を提供します。
- SyncConsistentHashFactory
一貫性のあるハッシュ に基づくアルゴリズムを使用します。サーバーヒントを無効にした場合は、デフォルトで選択されています。
この実装では、クラスターが対称である限り、すべてのキャッシュの同じノードに常にキーが割り当てられます。つまり、すべてのキャッシュがすべてのノードで実行します。この実装には、負荷の分散が若干不均等であるため、負のポイントが若干異なります。また、参加または脱退時に厳密に必要な数よりも多くのセグメントを移動します。
- TopologyAwareSyncConsistentHashFactory
-
SyncConsistentHashFactoryに似ていますが、サーバーヒントに適合しています。サーバーヒントが有効な場合にデフォルトで選択されます。 - DefaultConsistentHashFactory
SyncConsistentHashFactoryよりも均等に分散を行いますが、1 つの欠点があります。ノードがクラスターに参加する順序によって、どのノードがどのセグメントを所有するかが決まります。その結果、キーは異なるキャッシュ内の異なるノードに割り当てられる可能性があります。サーバーヒントを無効にした状態で、バージョン 5.2 からバージョン 8.1 のデフォルトでした。
- TopologyAwareConsistentHashFactory
DefaultConsistentHashFactoryに似ていますが、サーバーヒントに適合しています。
サーバーヒントが有効なバージョン 5.2 から 8.1 へのデフォルトでした。
- ReplicatedConsistentHashFactory
- レプリケートされたキャッシュの実装に内部で使用されます。このアルゴリズムは分散キャッシュで明示的に選択しないでください。
6.4.2.1. 容量ファクト リンクのコピーリンクがクリップボードにコピーされました!
設備利用率は、ノードで使用可能なリソースに基づいてセグメントからノードへのマッピングを割り当てます。
容量要因を設定するには、負の数を指定し、Red Hat Data Grid ハッシュアルゴリズムは各ノードに容量係数(プライマリー所有者およびバックアップ所有者の両方)で重みを割り当てます。
たとえば、nodeA は同じ Red Hat Data Grid クラスターの nodeB よりも 2x のメモリーを持ちます。この場合、capacityFactor を 2 に設定すると、Red Hat Data Grid はセグメント数を nodeA に割り当てるように設定します。
容量係数を0に設定することは可能ですが、ノードが有用なデータ所有者として十分な長さでクラスターに参加していない場合にのみ推奨されます。