28.4. ConsistentHashFactories
Red Hat JBoss Data Grid は、一貫したハッシュアルゴリズムを選択するためのプラグ可能なメカニズムを提供します。これは 4 つの実装に同梱されていますが、カスタム実装を使用することもできます。
JBoss Data Grid には次の 4 つの ConsistentHashFactory 実装が同梱されています。
DefaultConsistentHashFactory- すべてのノード間でセグメントが均等に分散されるようにします。ただし、キーマッピングは、各キャッシュの履歴に依存するため、複数のキャッシュ間で同じであることは保証されません。consistentHashFactory が指定されない場合は、このクラスが使用されます。SyncConsistentHashFactory- 現在のメンバーシップが同じである場合、キーマッピングが各キャッシュについて同一であることを保証します。ただし、この欠点として、キャッシュに参加するノードが既存ノードによるセグメントの交換を生じさせる可能性があり、その結果、追加の状態転送のトラフィックが発生するか、またはデータ分散が少なくなるかのいずれか、またはそれらの両方が生じる場合があります。TopologyAwareConsistentHashFactory-DefaultConsistentHashFactoryと同等ですが、設定にサーバーヒンティングが含まれる場合に自動的に選択されます。TopologyAwareSyncConsistentHashFactory-SyncConsistentHashFactoryと同等ですが、設定にサーバーヒンティングが含まれる場合に自動的に選択されます。
一貫したハッシュ実装をハッシュ設定で選択できます。
<hash consistentHashFactory="org.infinispan.distribution.ch.SyncConsistentHashFactory"/>
この設定は、同じメンバーを持つキャッシュに同一の一貫したハッシュがあることを保証し、さらに
machineId、rackId、または siteId 属性がトランスポート設定で指定される場合、バックアップコピーを複数の物理マシン/ラック/データセンターにまたがって分散させます。
想定される欠点として、この設定により、バランスの再調整時に必要とする以上の数のセグメントが移動する可能性があります。ただし、この影響は、多数のセグメントを使用することによって軽減できます。
もう 1 つの想定される欠点として、セグメントが均等に分散されないことや、さらには多数のセグメントを実際に使用することによりセグメントの分散状況が悪化することなどがあります。
上述の欠点がありますが、多くの場合、
SyncConsistentHashFactory と TopologyAwareSyncConsistentHashFactory を使用すると、ノードがクラスターに参加した順序に基いてハッシュが計算されないため、クラスター化環境でオーバーヘッドが減少します。また、これらのクラスは通常、各ノードに割り当てられるセグメントの数に大きな違いがあっても許容されるため、デフォルトのアルゴリズムよりも高速になります。
28.4.1. ConsistentHashFactory の実装
カスタム
ConsistentHashFactory は、以下のメソッド (これらすべては org.infinispan.distribution.ch.ConsistentHash の実装を返します) を使って、org.infinispan.distribution.ch.ConsistenHashFactory インターフェースを実装する必要があります。
例28.1 ConsistentHashFactory メソッド
create(Hash hashFunction, int numOwners, int numSegments, List<Address> members,Map<Address, Float> capacityFactors) updateMembers(ConsistentHash baseCH, List<Address> newMembers, Map<Address, Float> capacityFactors) rebalance(ConsistentHash baseCH) union(ConsistentHash ch1, ConsistentHash ch2)
現在のところ、カスタムパラメーターを
ConsistentHashFactory 実装に渡すことはできません。
