第10章 グリッドでのコードの実行
キャッシュの主な利点は、マシン全体でもキーで値を迅速に検索できることです。実際、これはおそらく多くのユーザーが Red Hat Data Grid を使用する理由です。ただし、Red Hat Data Grid はすぐに理解できない多くの利点を提供できます。通常、Red Hat Data Grid はマシンのクラスターで使用されるため、ユーザーに適したワークロードを実行するためのクラスター全体での活用に役立つ機能もあります。
このセクションでは、埋め込みキャッシュを使用したグリッドでのコードの実行のみを説明します。リモートキャッシュを使用している場合は、Remote Grid の Executing コードを 確認する必要があります。
10.1. クラスターエグゼキューター リンクのコピーリンクがクリップボードにコピーされました!
マシンのグループがあるため、それらすべてでコードを実行するためにそれらの結合された計算能力を活用することは理にかなっています。キャッシュマネージャーには、クラスター内で任意のコードを実行できる優れたユーティリティーが付属しています。この機能にはキャッシュを使用する必要はありません。この Cluster Executor は、EmbeddedCacheManager で executor()を呼び出すことで取得できます。このエグゼキュータは、クラスター構成と非クラスター構成の両方で取得できます。
ClusterExecutorは、コードがキャッシュ内のデータに依存しないコードを実行するために特別に設計されており、代わりに、ユーザーがクラスター内でコードを簡単に実行できるようにする方法として使用されます。
このマネージャーは、Java 8を使用して特別に構築されており、機能的なAPIを念頭に置いているため、すべてのメソッドは機能的なインターフェイスを引数として取ります。また、これらの引数は他のノードに送信されるため、シリアライズする必要があります。ラムダがすぐに Serializable になるような策を使用しています。つまり、引数に Serializable と実際の引数タイプ(つまり、Runnable または Function)の両方を実装させることです。JRE は、呼び出す方法を決定する際に最も具体的なクラスを選択するため、ラムダは常にシリアライズ可能です。また、Externalizer を使用してメッセージサイズをさらに減らすこともできます。
マネージャーはデフォルトで、指定されたコマンドを、送信元のノードを含むクラスター内のすべてのノードに送信します。セクションで説明されているように、filterTargets メソッドを使用して、タスクが実行するノードを制御できます。
10.1.1. 実行ノードのフィルタリング リンクのコピーリンクがクリップボードにコピーされました!
コマンドを実行するノードを制限できます。たとえば、同じラック内のマシンでのみ計算を実行したい場合があります。または、ローカルサイトで 1 回、別のサイトで操作を再実行することもできます。クラスターエグゼキューターは、同じマシン、ラック、またはサイトレベルのスコープで要求を送信するノードを制限できます。
SameRack.java
EmbeddedCacheManager manager = ...; manager.executor().filterTargets(ClusterExecutionPolicy.SAME_RACK).submit(...)
EmbeddedCacheManager manager = ...;
manager.executor().filterTargets(ClusterExecutionPolicy.SAME_RACK).submit(...)
このトポロジーベースのフィルタリングを使用するには、Server Hinting でトポロジーを認識しているハッシュを有効にする必要があります。
ノードの Address に基づいて述部を使用してフィルタリングすることもできます。これは任意で、以前のコードスニペットでトポロジーベースのフィルタリングと組み合わせることもできます。
また、実行対象と見なすことができるノードを除外する Predicate を使用して、任意の方法でターゲットノードを選択することもできます。これは同時に Topology フィルタリングと組み合わせて、クラスター内でコードを実行する場所をより詳細に制御できるようにすることもできます。
Predicate.java
EmbeddedCacheManager manager = ...; // Just filter manager.executor().filterTargets(a -> a.equals(..)).submit(...) // Filter only those in the desired topology manager.executor().filterTargets(ClusterExecutionPolicy.SAME_SITE, a -> a.equals(..)).submit(...)
EmbeddedCacheManager manager = ...;
// Just filter
manager.executor().filterTargets(a -> a.equals(..)).submit(...)
// Filter only those in the desired topology
manager.executor().filterTargets(ClusterExecutionPolicy.SAME_SITE, a -> a.equals(..)).submit(...)
10.1.2. タイムアウト リンクのコピーリンクがクリップボードにコピーされました!
Cluster Executor を使用すると、呼び出しごとにタイムアウトを設定できます。デフォルトは、Transport Configuration で設定された分散同期のタイムアウトになります。このタイムアウトは、クラスター化されたキャッシュマネージャーとクラスター化されていないキャッシュマネージャーの両方で機能します。タイムアウトの期限が切れると、エグゼキューターがタスクを実行しているスレッドを中断する場合と中断しない場合があります。ただし、タイムアウトが発生すると、Consumer または Future はTimeoutException を渡して完了します。この値は、タイムアウト メソッドを公開して必要な期間を指定することで上書きできます。
10.1.3. 単一ノードの提出 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Executorは、すべてのノードにコマンドを送信する代わりに、単一ノード送信モードで実行することもできます。代わりに、通常はコマンドを受信するノードの1つを選択し、1つだけに送信します。それぞれの送信は、別のノードを使用してタスクが実行される可能性があります。これは、ClusterExecutor が実装する java.util.concurrent.Executor として ClusterExecutor を使用するのが非常に便利です。
SingleNode.java
EmbeddedCacheManager manager = ...; manager.executor().singleNodeSubmission().submit(...)
EmbeddedCacheManager manager = ...;
manager.executor().singleNodeSubmission().submit(...)
10.1.3.1. Failover リンクのコピーリンクがクリップボードにコピーされました!
シングルノード送信で実行する場合は、コマンドを再試行することにより、特定のコマンドの処理中に例外が発生した場合にClusterExecutorが処理できるようにすることが望ましい場合があります。これが発生すると、Cluster Executor は単一のノードを再度選択し、任意のフェイルオーバー試行までコマンドを再実行します。選択したノードは、トポロジーまたは述部のチェックをパスするノードである可能性があることに注意してください。フェイルオーバーは、上書きされた singleNodeSubmission メソッドを呼び出すことによって有効にされます。指定されたコマンドは、コマンドが例外なく完了するか、送信の合計量が指定されたフェイルオーバーカウントと等しくなるまで、単一のノードに再送信されます。
10.1.4. 例: PI アプローチ リンクのコピーリンクがクリップボードにコピーされました!
この例は、ClusterExecutor を使用して PI の値を見積もる方法を示しています。
Pi近似は、ClusterExecutorを介した並列分散実行から大きな利点を得ることができます。正方形の面積はSa = 4r2であり、円の面積はCa=pi*r2であることを思い出してください。2 つ目の式からの r2 を置き換えると、pi = 4 * Ca/S になります。ここで、正方形に非常に多くのダーツを射ることができると仮定して、射ったダーツの総数に対して円の中に入ったダーツの割合を取ると、Ca/Saの値が近似します。pi = 4 * Ca/Sa であるため、piの近似値を簡単に導き出すことができます。ダーツを多く撃つほど、より良い近似が得られます。以下の例では、「Shooting」ではなく、Red Hat Data Grid クラスター全体でのダイアピングの作業を並列化しています。これは 1 のクラスターで正常に機能しますが、遅くなることに注意してください。