36.3. サーバーサイドメッセージロードバランシング

クラスターのノード間でクラスター接続が定義された場合は、HornetQ が特定のノードに到着するメッセージをクライアントから負荷分散します。
シンメトリッククラスター (「シンメトリッククラスター」 で説明) で配置された 4 つのノード A、B、C、および D の単純な例を見てみましょう。OrderQueue と呼ばれるキューがクラスターの各ノードにデプロイされます。
クライアント Ca はノード A に接続され、サーバーに順序を送信します。また、順序プロセッサークライアント Pa、Pb、Pc、および Pd は各ノード A、B、C、D に接続されます。クラスター接続がノード A で定義されない場合、順序メッセージはノード A に到着したときにノード A の OrderQueue にすべて格納され、ノード A、Pa に接続された順序プロセッサークライアントによって消費されます。
ノード A 上のクラスター接続が定義されている場合、順序が決定されたメッセージはノード A に到着したときに、すべてがローカルの OrderQueue インスタンスに格納される代わりに、クラスターのすべてのノード間でラウンドロビン形式で分散されます。メッセージは受け取り側のノードからクラスターの他のノードに転送されます。これは、サーバーサイドで行われ、クライアントはノード A に対する単一の接続を保持します。
たとえば、ノード A に到着したメッセージは、ノード間で B、D、C、A、B、D、C、A、B、D という順序で分散できます。正確な順序は、ノードが起動された順序に基づきますが、使用されるアルゴリズムはラウンドロビンです。

36.3.1. クラスター接続の設定

クラスター接続は、クラスターのノード間でメッセージを負荷分散できるようサーバーをクラスターにグループ分けします。一般的なクラスター接続は JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml の cluster-connection 要素内で定義されます。1 つの HornetQ サーバーごとにゼロ以上のクラスター接続を定義できます。 
<cluster-connections>
   <cluster-connection name="my-cluster">
      <address>jms</address>
      <retry-interval>500</retry-interval>
      <use-duplicate-detection>true</use-duplicate-detection>
      <forward-when-no-consumers>false</forward-when-no-consumers>
      <max-hops>1</max-hops>
      <discovery-group-ref discovery-group-name="my-discovery-group"/>
   </cluster-connection>
</cluster-connections>
上記のクラスター接続では、すべてのパラメータが明示的に指定されています。実際には、一部についてデフォルト値を使用できます。
  • address。各クラスター接続は、この値で始まるアドレスに送信されたメッセージにのみ適用されます。
    この場合、このクラスター接続は jms で始まるアドレスに送信されたメッセージを負荷分散します。このクラスター接続は、サブ文字列 "jms" で始まるコアキューにマップされるため、すべての JMS キューとトピックサブスクリプションに適用されます。
    アドレスとして任意の値を指定でき、address のさまざまな値を持つ多くのクラスター接続を持つことができます (同時にこれらのアドレスに対するメッセージがサーバーのさまざまなクラスターに分散されます)。さまざまなアドレスで複数のクラスター接続を持つことにより、単一の HornetQ サーバーは効果的に複数のクラスターに同時に参加できます。
    address の重複する値 (たとえば、"europe" と "europe.news") を持つ複数のクラスター接続を作成しないよう注意してください。このようなクラスター接続を作成すると、同じメッセージが複数のクラスター接続間で分散され、配信が重複することがあります。
    このパラメータは必須です。
  • discovery-group-ref。このパラメータは、このクラスター接続が接続を確立するクラスターの他のサーバーのリストを取得するために使用する検出グループを決定します。
  • forward-when-no-consumers。このパラメータは、一致が存在するか、他のノードにコンシューマーが存在するかどうかに関係なく、クラスターの他のノード間でメッセージをラウンドロビン形式で分散するかどうかを決定します。
    これが true に設定されたとき、クラスターの他のノードの同じキューがコンシューマーをまったく持つことができない場合や、一致するメッセージフィルター (セレクター) を持たないコンシューマーを持つことができる場合であっても、各受信メッセージはラウンドロビン形式で処理されます。他のノードに同じ名前のキューが存在しない場合は、このパラメータが true に設定された場合であっても、HornetQ はメッセージを他のノードに転送しません。
    これが false に設定された場合、HornetQ はクラスターの他のノードにのみメッセージを転送します (メッセージが転送されるアドレスがコンシューマーを持つキューを持っている場合)。これらのコンシューマーがメッセージフィルター (セレクター) を持っている場合は、これらのセレクターの少なくとも 1 つがメッセージに一致する必要があります。
    このパラメータはオプションであり、デフォルト値は false です。
  • max-hops。クラスター接続がメッセージを 負荷分散できるノードのセットを決定する場合、これらのノードはクラスター接続を介して直接接続する必要はありません。HornetQ は、チェーンの中間として他の HornetQ サーバーと間接的にのみ接続できるノードに対してメッセージを負荷分散するよう設定することもできます。
    これにより、HornetQ をより複雑なトポロジーで設定し、メッセージの負荷分散を提供できます。これについては、この章の後半で説明します。
    このパラメータのデフォルト値は 1 であり、メッセージは、このサーバーに直接接続された他の HornetQ サーバーに対してのみ負荷分散されます。このパラメータはオプションです。
  • min-large-message-size。このパラメータは、サイズのしきい値を決定します。この値よりも上になると、クラスターを介して送信するときに、メッセージが複数のパッケージに分割されます。このパラメータはオプションであり、デフォルト値は100 KiB です。
  • reconnect-attempts。このパラメータは、システムがクラスター上のノードに接続しようとする回数を決定します。最大再試行回数に到達すると、このノードが永久的にダウンしていると見なされ、メッセージのルーティングが停止されます。このパラメータはオプションであり、デフォルト値は -1 (無限再試行回数) です。
  • retry-interval。内部的に、クラスター接続により、クラスターのノード間でブリッジが作成されます。クラスター接続が作成され、ターゲットノードが起動しない場合 (またはリブートされる場合)、他のノードからのクラスター接続が、ターゲットノードが再び起動されるまでブリッジと同じ方法でターゲットノードへの接続を再試行します。
    このパラメータは、再試行の間の時間 ( ミリ秒単位) を決定します。これはブリッジでの retry-interval と同じ意味を持ちます (34章コアブリッジ で説明)。
    このパラメータはオプションであり、デフォルト値は 500 ミリ秒です。
  • use-duplicate-detection。内部的に、クラスター接続はブリッジを使用してノードをリンクし、ブリッジは転送される各メッセージの重複する ID プロパティを追加するよう設定できます。ブリッジのターゲットノードがクラッシュし、回復すると、メッセージは 2 つ目のノードから再送信できます。重複検出を有効にすることにより、すべての重複メッセージはターゲットノードでの受信時にフィルタリングされ、無視されます。
    このパラメータは、ブリッジでの use-duplicate-detection と同じ意味を持ちます。重複検出の詳細については、35章重複メッセージ検出 を参照してください。
    このパラメータはオプションであり、デフォルト値は true です。