10.3.7. キーベースのリハッシュ対応 Operator

イテレーター、スプリッター、および それぞれの 情報は、セグメントだけではなく、セグメントごとのキーを追跡するために、リハッシュ認識が他の端末オペレーターとは異なります。これは、クラスターメンバーシップが変更された場合でも、1回だけ（iterator と spliterator）または1回以上の（forEach）の動作を保証するためです。

リモートノードで呼び出されると iterator および spliterator オペレーターは、エントリーの再バッチを返します。この場合、次のバッチは最後に使用された後にのみ送信されます。このバッチ処理は、ある時点のメモリー内のエントリー数を制限するために行われます。ユーザーノードは、処理したキーを保持し、特定のセグメントが完了すると、それらのキーをメモリから解放します。そのため、iterator メソッドには順次処理が優先されることがあるため、すべてのノードからではなく、セグメントキーのサブセットのみがメモリーに保持されます。

forEach() メソッドはバッチを返しますが、キーの処理が少なくともバッチ処理された後に、キーのバッチを返します。これにより、送信元ノードはどの鍵がすでに処理されているかを把握して、同じエントリーを再処理する可能性を減らすことができます。ただし、これはノードが予期せずダウンした場合に、少なくとも 1 回の動作を要する可能性があることを意味します。この場合、そのノードはバッチを処理していてまだ完了していない可能性があり、処理されたが完了したバッチに含まれていないエントリは、再ハッシュ失敗オペレーションが発生したときに再度実行されます。ノードを追加しても、すべての応答を受け取るまで、再ハッシュフェイルオーバーが発生しないため、この問題は発生しません。

これらの操作バッチサイズは、どちらも CacheStream で distributedBatchSize メソッドを呼び出すことで設定できる同じ値によって制御されます。この値はデフォルトで、状態遷移で設定された chunkSize に設定されます。残念ながら、この値は、メモリ使用量とパフォーマンスと少なくとも1回のトレードオフであり、マイレージは異なる場合があります。

レプリケートされた分散キャッシュでのiteratorの使用

ノードが分散ストリームのすべての要求されたセグメントのプライマリーまたはバックアップ所有者である場合、Red Hat Data Grid は イテレーター または Spliterator ターミナル操作をローカルで実行します。リモート反復がリソース集約型であるため、パフォーマンスを最適化します。

この最適化は、レプリケートされたキャッシュと分散キャッシュの両方に適用されます。ただし、共有 され、write-behind が有効になっているキャッシュストアを使用する場合、Red Hat Data Grid はリモートで反復を実行します。この場合は、リモートで反復を行うことで一貫性が確保されます。