JP2009110165A

JP2009110165A - パブリッシュ／サブスクライブ通信における負荷分散処理方法及びその実施装置と処理プログラム

Info

Publication number: JP2009110165A
Application number: JP2007280396A
Authority: JP
Inventors: Hironari Tsuzuki; 裕也都築
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2007-10-29
Filing date: 2007-10-29
Publication date: 2009-05-21

Abstract

【課題】
パブリッシュ／サブスクライブ通信において、サブスクライブ側（受信側）の負荷分散構成を実現する。
【解決手段】
パブリッシュ／サブスクライブ通信を行なう通信ノードとメッセージの配信を実行するブローカとの間に代理のパブリッシュ／サブスクライブ（pub/sub）通信ノードを配置する。この代理pub/sub通信ノードは接続されている複数の通信ノードの代理としてブローカに対してパブリッシュ／サブスクライブ要求を発行する。代理pub/subサーバが複数ノードから同一のトピックでサブスクライブ要求を受信した場合に、最初の要求を受信した時にのみブローカに対してサブスクライブ要求を発行し、後続のサブスクライブ要求受付時には、どの通信ノードから受信したかを記憶しておくだけにし、ブローカからそのトピックに対するパブリッシュメッセージを受信した場合に、記憶しておいたサブスクライブ要求を発行した複数の通信ノードから一つを選択して配信する。
【選択図】図１

Description

本発明はパブリッシュ／サブスクライブ通信に関わり、配信データを複数ノードへ分散させることにより各ノードで分散処理を実行させる負荷分散処理方法に関するものである。

メッセージを送受信する方式として広く使用されているモデルにPoint-to-Point方式がある。これは、送信側が受信側の宛先を指定してメッセージを送信する方式であり、送信側が受信する宛先を意識する必要がある。一方、Publish-Subscribe方式という通信モデルがある。Publish-Subscribe方式では、送信側は宛先を意識せずにメッセージを発行（Publish）し、そのメッセージを受け取ったメッセージングシステムがメッセージの種類や属性を見て、そのメッセージの購読を要求（subscribe）している受信側に対してメッセージを配送する。Publish-Subscribe方式では、送信側と受信側がお互いに相手が誰でどこにいるかを意識する必要がなく、また受信側は自分が必要とするメッセージのみを受け取ることができる方式である。送信側、受信側がお互いを意識する必要がないため、サービスの追加、削除といった構成変更が容易な方式である。

Point-to-PointとPublish-Subscribeのメッセージング仕様の一例では、送信側はトピックに対してメッセージを送信し、メッセージはそのトピックをサブスクライブ（購読）している全てのアプリケーションが受信できる。サブスクライブしている全てのアプリケーションの受信が終わるとその時点でトピックからそのメッセージは削除される。

Point-to-Point方式が１対１通信であるのに対して、Publish-Subscribe方式は１対Ｎ通信である。Publish-Subscribe方式が実システムに適用された例として、株価配信システムがある。ユーザがある会社の株価の購読（subscribe）を登録しておくと、その会社の更新された株価が送信（Publish）される。購読（subscribe）を登録した複数のユーザには同じ情報が通知される。

通信構成としては、各クライアントプログラムはブローカと呼ばれるメッセージ配信ノードに接続され、さらにブローカ間が接続する構成が考えられる（特許文献１）。

ところで、多数のクライアントプログラムからの処理要求が多量に発生するシステムでは、クライアントプログラムが動作する装置とサーバプログラムが動作する装置との間に負荷分散装置を設置する等して、サーバプログラムが動作する処理装置を複数配置することで、処理要求の負荷を複数装置に分散させる構成をとるのが一般的である。通信にPoint-to-Point方式を使用した場合にこの構成は適用できる。しかし、Publish-Subscribe方式を使用した場合、複数配置した処理装置からメッセージの購読要求（subscribe）がなされるため、同一メッセージが複数の処理装置に配信されることになり負荷分散の構成をとることができない。

特表２００６−５２３９０５号

前記の様にパブリッシュ／サブスクライブ通信では、送信側と受信側がお互いに相手が誰でどこにいるかを意識する必要がなく、また受信側は自分が必要とするメッセージのみを受け取ることができるので、この通信を用いた負荷分散処理システムを構築すれば、送信側、受信側がお互いを意識する必要がなく、サービスの追加、削除といった構成変更が容易な負荷分散処理システムが構築可能であると考えられるが、前記の様に従来の技術ではパブリッシュ／サブスクライブ通信を使用した場合に負荷分散の構成をとることが困難であった。

本発明の目的は、上記問題点を解決し、パブリッシュ／サブスクライブ通信においてサブスクライブ側（受信側）の負荷分散構成を実現することが可能な技術を提供することにある。

本発明は、パブリッシュ／サブスクライブ通信でメッセージを配信して負荷分散処理を複数ノードに実行させる負荷分散処理システムであって、あるトピックについての最初のサブスクライブ要求のブローカへの送信や選択した一つのノードへのブローカからのメッセージの配信を代理サーバが行うことで、メッセージを用いた処理を複数のノードで分散して実行させるものである。

本発明では、パブリッシュ／サブスクライブ通信を行なう通信ノードとメッセージの配信を実行するブローカとの間に代理のパブリッシュ／サブスクライブ（pub/sub）通信ノード（代理pub/subサーバ）を配置する。この代理pub/subサーバは接続されている複数の通信ノードの代理としてブローカに対してパブリッシュ／サブスクライブ要求を発行する。

すなわち本発明の負荷分散処理方法では、代理pub/subサーバが複数ノードから同一のトピックでサブスクライブ要求を受信した場合に、最初の要求を受信した時にのみブローカに対してサブスクライブ要求を発行し、後続のサブスクライブ要求受付時には、どの通信ノードから受信したかを記憶しておくだけにするステップと、ブローカからそのトピックに対するパブリッシュメッセージを受信した場合に、記憶しておいたサブスクライブ要求を発行した複数の通信ノードから一つを選択して配信するステップを有し、代理pub/subサーバがサブスクライブ要求をキャンセルするアンサブスクライブ要求を通信ノードから受信した場合、記憶していた全ての通信ノードからアンサブスクライブ要求を受信した時にのみブローカにアンサブスクライブ要求を送信するステップを有することで負荷分散処理を実現する。

また、予め上記のステップに従い処理するトピック名を指定することで、サブスクライブ要求を発行した複数の通信ノードから一つを選択してパブリッシュメッセージを配信するか、従来通りサブスクライブ要求を発行した全ての通信ノードにパブリッシュメッセージを配信するかを選択することも可能とする。

本発明により、パブリッシュ／サブスクライブ通信において複数のサブスクライバを配置して負荷分散構成を実現できる。

図１はパブリッシュ／サブスクライブ通信のネットワークの実施例であり、各通信ノード間のメッセージ配信を司るブローカ１２０、各通信ノード１０１、パブリッシュ／サブスクライブ通信の負荷分散を制御する代理pub/subサーバ１３０、代理pub/subサーバ１３０に接続された通信ノード１４０から構成され、各装置はネットワーク及び通信装置を介してパブリッシュ／サブスクライブ通信を行う。ここで、代理pub/subサーバ１３０は装置であり、メモリ上のpub/subサーバ１０４及びpub/subサーバ１４３はプログラムである。

通信ノード１０１はメモリ１０３とＣＰＵ１０２で構成される。メモリ１０３にはノード内でのパブリッシュ／サブスクライブ処理を制御するpub/subサーバ１０４と、パブリッシュ／サブスクライブを要求するアプリケーション１０５が配置されている。

通信ノード１４０はブローカに接続された通信ノード１０１にサービスを提供するノードであり、メモリ１４１とＣＰＵ１４２で構成される。メモリ１４１にはノード内でのパブリッシュ／サブスクライブ処理を制御するpub/subサーバ１４３と、サービスを提供するサービスＡ１４４、サービスＢ１４５が配置されている。

サービスＡ１４４、サービスＢ１４５はトピックを指定したサブスクライブ要求をpub/subサーバ１４３に発行し、通信ノード１０１からパブリッシュされたメッセージの内サービスＡ１４４、サービスＢ１４５が指定したトピックと一致するメッセージを受信する。通信ノード１４０は複数存在し、全て代理pub/subサーバ１３０に接続されており、複数の通信ノード１４０は代理pub/subサーバ１３０からのメッセージを受信してサービスＡ１４４及びサービスＢ１４５の処理を負荷分散により行う。

代理pub/subサーバ１３０はメモリ１３２、ＣＰＵ１３１、トピック定義部１３５とノードリスト管理部１３６で構成される。メモリ１３２にはパブリッシュ／サブスクライブ通信メッセージを制御するトピック検出部１３３とブローカ１２０から通知されたメッセージを各通信ノード１４０に負荷を分散させて送信する負荷分散部１３４が配置される。トピック検出部１３３は負荷分散対象のトピックを管理するトピック定義部１３５と各トピックのメッセージを負荷分散して配信するノード一覧を管理するノードリスト管理部１３６の情報を参照、更新する。

代理pub/subサーバ１３０をトピック検出部１３３や負荷分散部１３４として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。

図２はトピック定義部１３５の構成について示すものである。トピック定義部１３５はトピック識別子２０１、トピック名２０２、一致パターン２０３、ノードリスト名２０４から成る複数のレコード２１１、２１２、２１３、２１４から構成される。

本実施形態では、代理pub/subサーバ１３０が送受信するメッセージを負荷分散対象とするかはトピック識別子２０１、一致パターン２０３により決定されるものとする。一致パターン２０３には「前置」２２１、「後置」２２２、「全体」２２３がある。

代理pub/subサーバ１３０と通信ノード１４０間で送受信されるトピック名とブローカ１２０に接続された通信ノード１０１間で送受信されるメッセージのトピック名を一致させる場合は、一致パターン２０３に「全体」２２３を設定しておく。レコード２１３がその例にあたる。

ブローカ１２０に接続された通信ノード１０１間で送受信されるメッセージのトピック名の前にトピック識別子２０１を付加したものを代理pub/subサーバ１３０と通信ノード１４０間で送受信されるトピック名とする場合は、一致パターン２０３に「前置」２２１を設定しておく。レコード２１１、２１２がその例である。レコード２１１の場合、ブローカ１２０と通信ノード１０１間でのトピック名は”/request_A”となるが、代理pub/subサーバ１３０と通信ノード１４０間のトピック名は”/#LB_prefix/request_A”となる。レコード２１２の場合、ブローカ１２０と通信ノード１０１間でのトピック名は”/request_B”となるが、代理pub/subサーバ１３０と通信ノード１４０間のトピック名は”/#LB_prefix/request_B”となる。

ブローカ１２０に接続された通信ノード１０１間で送受信されるメッセージのトピック名の後にトピック識別子２０１を付加したものを代理pub/subサーバ１３０と通信ノード１４０間で送受信されるトピック名とする場合は、一致パターン２０３に「後置」２２２を設定しておく。レコード２１４の場合、ブローカ１２０と通信ノード１０１間でのトピック名は”/request_C”となるが、代理pub/subサーバ１３０と通信ノード１４０間のトピック名は”/request_C/#LB_prefix”となる。

一致パターン２０３に「前置」２２１、「後置」２２２を指定すると、代理pub/subサーバ１３０に接続された通信ノード１４０の各サービス１４４、１４５は負荷分散対象とする全トピックを予めトピック定義部１３５に指定する必要がなく、サービスが追加された時も、ある規則に基づいたトピック名を指定してサブスクライブすれば良い。ノードリスト名２０４は該当トピックの負荷分散対象ノードの一覧を示すものであり、ノードリスト管理部１３６のノードリストポインタ３０１の位置を示すものである。

図３はノードリスト管理部１３６の構成を示すものである。ノードリスト管理部１３６はノードリストポインタ３０１とノードリスト３０２により構成される。ノードリストポインタ３０１にはトピック定義部１３５の各レコード２１１、２１２、２１３、２１４対応のポインタ領域３１１、３１２、３１３、３１４が確保される。ノードリスト３０２にはポインタ領域３１１からポイントされる負荷分散対象のノード３２１、３２２が確保される。

図４で代理pub/subサーバ１３０が通信ノード１４０からサブスクライブ要求を受付けた流れを示す。代理pub/subサーバ１３０のトピック検出部１３３は、サブスクライブ要求を受付けると（ステップ４０）、トピック定義部１３５に一致するトピックがあるかを判定する（ステップ４１）。

ステップ４１で判定した結果がNOの場合、サブスクライブ要求受付け処理を終了する（ステップ４７）。またステップ４１で判定した結果がYESの場合、前記受付けたサブスクライブ要求と同一のサブスクライブ要求をブローカ１２０へ送信済みであるかを判定する（ステップ４２）。

ステップ４２で判定した結果がYESの場合、ステップ４５へ進む。またステップ４２で判定した結果がNOの場合、トピック定義部１３５の一致パターンに従いサブスクライブ要求を作成し直し（ステップ４３）、その作成し直したサブスクライブ要求をブローカ１２０へ送信する（ステップ４４）。

次に、ノードリスト管理部１３６に該当ノードがあるかを判定する（ステップ４５）。ステップ４５で判定した結果がNOの場合にのみ、ノードリスト管理部１３６に該当ノードを追加し（ステップ４６）、サブスクライブ要求受付け処理を終了する（ステップ４７）。

図５でトピック定義部１３５に一致するトピックがあるかを判定する処理（ステップ４１）の流れを示す。代理pub/subサーバ１３０のトピック検出部１３３は、ステップ５０で処理を開始した後、一致パターン２０３が「全体」２２３であり、かつ、該当トピック名と同一のトピック識別子２０１のレコードが存在するか判定する（ステップ５１）。

ステップ５１での判定の結果がYESの場合、最終判定結果もYESとなり（ステップ５５）、判定処理を終了する（ステップ５６）。ステップ５１での判定の結果がNOの場合、一致パターン２０３が「前置」２２１であり、かつ、該当トピック名の先頭から比較して前方一致するトピック識別子２０１が存在するか判定する（ステップ５２）。

ステップ５２での判定の結果がYESの場合、最終判定結果もYESとなり（ステップ５５）、判定処理を終了する（ステップ５６）。ステップ５２での判定の結果がNOの場合、一致パターン２０３が「後置」２２２であり、かつ、該当トピック名の後端から比較して後方一致するトピック識別子２０１が存在するか判定する（ステップ５３）。

ステップ５３での判定の結果がYESの場合、最終判定結果もYESとなり（ステップ５５）、判定処理を終了する（ステップ５６）。ステップ５３での判定の結果がNOの場合、最終判定結果もNOとなり（ステップ５４）、判定処理を終了する（ステップ５６）。

図６でトピック定義部１３５の一致パターンに従いサブスクライブ要求を作成し直す処理（ステップ４３）の流れを示す。代理pub/subサーバ１３０のトピック検出部１３３は、ステップ６０で処理を開始した後、トピック定義部１３５の一致したレコードの一致パターン２０３が「前置」２２１であるかを判定する（ステップ６１）。

ステップ６１で判定した結果がYESの場合、サブスクライブ要求の該当トピック名の前方からトピック識別子２０１の文字列を削除する（ステップ６２）。そして、ここで作成したトピック名に一致するレコードがトピック定義部１３５に無い場合、作成したトピック名を持つレコードを追加し（ステップ６３）、処理を終了する（ステップ６７）。またステップ６１で判定した結果がNOの場合、トピック定義部１３５の一致したレコードの一致パターン２０３が「後置」２２２であるかを判定する（ステップ６４）。

ステップ６４で判定した結果がYESの場合、サブスクライブ要求の該当トピック名の後方からトピック識別子２０１の文字列を削除する（ステップ６５）。そして、ここで作成したトピック名に一致するレコードがトピック定義部１３５に無い場合、作成したトピック名を持つレコードを追加し（ステップ６６）、処理を終了する（ステップ６７）。またステップ６４で判定した結果がNOの場合は処理を終了する（ステップ６７）。

図７で代理pub/subサーバ１３０が通信ノード１０１から発行されたパブリッシュメッセージを受信する処理の流れを示す。代理pub/subサーバ１３０のトピック検出部１３３は、ステップ７０でパブリッシュメッセージ受信した後、トピック定義部１３５のトピック名２０２に一致するトピックがあるかを判定する（ステップ７１）。

ステップ７１での判定の結果がNOの場合、受信したパブリッシュメッセージを該当トピックに対してサブスクライブしている全ての通信ノード１４０に送信し（ステップ７５）、パブリッシュメッセージ受信処理を終了する（ステップ７６）。ステップ７１での判定の結果がYESの場合、トピック定義部１３５の一致パターン２０３に従いパブリッシュメッセージを作成し直す（ステップ７２）。

そしてノードリスト管理部１３６のノードリスト３０２の該当ノードを負荷分散部１３４に渡し宛先を決定する（ステップ７３）。ここで、負荷分散部１３４では、該当ノードの情報から一つを選択してメッセージを配信するノードを選択する。この様に負荷分散部１３４はメッセージを複数ノードに割振り負荷を分散させる機構を実現するものであるが、この負荷分散の機構に関しては本発明の対象外である。次に負荷分散部１３４は、決定した宛先にパブリッシュメッセージを送信し（ステップ７４）、処理を終了する（ステップ７５）。

図８で、トピック定義部１３５の一致パターン２０３に従いパブリッシュメッセージを作成し直す処理（ステップ７２）の流れを示す。代理pub/subサーバ１３０のトピック検出部１３３は、ステップ８０で処理を開始した後、トピック定義部１３５のトピック名２０２に一致するトピックがあり、かつ、一致パターン２０３が「前置」２２１であるかを判定する（ステップ８１）。

ステップ８１で判定した結果がYESの場合、該当トピックの前方にトピック定義部１３５のトピック識別子２０１を付加し（ステップ８２）、処理を終了する（ステップ８５）。ステップ８１での判定の結果がNOの場合、トピック定義部１３５のトピック名２０２に一致するトピックがあり、かつ、一致パターン２０３が「後置」２２２であるかを判定する（ステップ８３）。ステップ８３で判定した結果がYESの場合、該当トピックの後方にトピック定義部１３５のトピック識別子２０１を付加し（ステップ８４）、処理を終了する（ステップ８５）。

図９で、代理pub/subサーバ１３０が通信ノード１４０からアンサブスクライブ要求を受付けた流れを示す。代理pub/subサーバ１３０のトピック検出部１３３は、ステップ９０でアンサブスクライブ要求を受付けると、トピック定義部１３５に一致するトピックがあるかを判定する（ステップ９１）。この判定処理の流れは図５に示される。

ステップ９１で判定した結果がNOの場合、アンサブスクライブ要求受付け処理を終了する（ステップ９８）。またステップ９１で判定した結果がYESの場合、ノードリスト管理部１３６のノードリスト３０２の該当ノードを削除する（ステップ９２）。

次にノードリスト管理部１３６の該当ノードリストポインタから指されるノードが１つ以上存在するか判定する（ステップ９３）。ステップ９３で判定した結果がYESの場合、アンサブスクライブ要求受付け処理を終了する（ステップ９８）。またステップ９３で判定した結果がNOの場合、トピック定義部の一致パターンに従いアンサブスクライブ要求を作成し直す（ステップ９４）。そして作成し直したアンサブスクライブ要求をブローカ１２０に対して送信する（ステップ９５）。次に、ステップ９３で判定した結果がNOの場合、トピック定義部１３５の該当レコードのトピック名２０２をクリアする（ステップ９６）。そして、同一トピック識別子２０１のレコードが他に存在する場合にのみ該当レコードを削除し、アンサブスクライブ要求受付け処理を終了する（ステップ９８）。

図１０で、トピック定義部の一致パターンに従いアンサブスクライブ要求を作成し直す処理（ステップ９４）の流れを示す。代理pub/subサーバ１３０のトピック検出部１３３は、ステップ１０１で処理を開始した後、トピック定義部１３５の一致したレコードの一致パターン２０３が「前置」２２１であるかを判定する（ステップ１０２）。

ステップ１０２で判定した結果がYESの場合、アンサブスクライブ要求の該当トピック名の前方からトピック識別子２０１の文字列を削除し（ステップ１０３）、処理を終了する（ステップ１０６）。またステップ１０２で判定した結果がNOの場合、トピック定義部１３５の一致したレコードの一致パターン２０３が「後置」２２２であるかを判定する（ステップ１０４）。

ステップ１０４で判定した結果がYESの場合、サブスクライブ要求の該当トピック名の後方からトピック識別子２０１の文字列を削除し（ステップ１０５）、処理を終了する（ステップ１０６）。またステップ１０４で判定した結果がNOの場合は処理を終了する（ステップ１０６）。

前記の様に本実施形態の負荷分散処理システムでは、あるトピックについての最初のサブスクライブ要求のブローカへの送信や選択した一つのノードへのブローカからのメッセージの配信を代理サーバが行うことで、メッセージを用いた処理を複数のノードで分散して実行させるので、パブリッシュ／サブスクライブ通信において複数のサブスクライバを配置して負荷分散構成を実現することが可能である。

なお前記の負荷分散処理システムでは、代理pub/subサーバ１３０が送受信するメッセージを負荷分散対象とするかはトピック定義部１３５のトピック識別子２０１及び一致パターン２０３により決定するものとしたが、負荷分散対象とするトピックを示す情報をトピック定義部１３５以外の他のテーブルとして予め記憶装置へ格納しておき、サブスクライブ要求のトピックがその記憶装置に格納されたテーブル中のトピックに一致した場合に、サブスクライブ要求を発行した複数の通信ノードから一つを選択してパブリッシュメッセージを配信することにより負荷分散処理を行わせ、そうでない場合に、従来通りサブスクライブ要求を発行した全ての通信ノードにパブリッシュメッセージを配信する様にしても良い。

本実施形態のパブリッシュ／サブスクライブ通信のネットワークを示す図である。本実施形態のトピック定義部を示す図である。本実施形態のノードリスト管理部を示す図である。本実施形態のサブスクライブ要求を受付けた時のフローを示す図である。本実施形態のトピック定義部に一致するトピックがあるかを判定するフローを示す図である。本実施形態のサブスクライブ要求を作成し直すフローを示す図である。本実施形態のパブリッシュメッセージを受信するフローを示す図である。本実施形態のパブリッシュメッセージを作成し直すフローを示す図である。本実施形態のアンサブスクライブ要求を受付けた時のフローを示す図である。本実施形態のアンサブスクライブ要求を作成し直すフローを示す図である。

符号の説明

１０１、１４０…通信ノード、１０２、１３１、１４２…ＣＰＵ、１０３、１３２、１４１…メモリ、１０４、１４３…pub/subサーバ、１０５…アプリケーション、１４４、１４５…サービス、１２０…ブローカ、１３０…代理pub/subサーバ、１３３…トピック検出部、１３４…負荷分散部、１３５…トピック定義部、１３６…ノードリスト管理部、２０１…トピック識別子、２０２…トピック名、２０３…一致パターン、２０４…ノードリスト名、２１１、２１２、２１３、２１４…トピック定義部のレコード、２２１、２２２、２２３…一致パターンの種類、３０１…ノードリストポインタ、３１１、３１２、３１３、３１４…ポインタ領域、３０２…ノードリスト、３２１、３２２…ノード領域、４０〜４７…サブスクライブ要求を受付けた時のフローの各処理、５０〜５６…トピック定義部に一致するトピックがあるかを判定するフローの各処理、６０〜６７…サブスクライブ要求を作成し直すフローの各処理、７０〜７５…パブリッシュメッセージを受信するフローの各処理、８０〜８５…パブリッシュメッセージを作成し直すフローの各処理、９０〜９８…アンサブスクライブ要求を受付けた時のフローの各処理、１０１〜１０６…アンサブスクライブ要求を作成し直すフローの各処理

Claims

パブリッシュ／サブスクライブ通信でメッセージを配信して負荷分散処理を複数ノードに実行させる代理サーバにおける負荷分散処理方法であって、
同一トピックのメッセージのサブスクライブを要求する複数ノードとそのメッセージを配信するブローカとの間に介在する代理サーバが、あるトピックの最初のサブスクライブ要求を通信装置によりブローカへ送信し、前記トピックのサブスクライブ要求を送信したノードを示す情報を記憶装置に格納するステップと、前記代理サーバが、前記ブローカから前記トピックのメッセージを受信した場合に、そのトピックのサブスクライブ要求を送信したノードを示す情報を前記記憶装置から読み出し、その読み出した情報から一つを選択して当該メッセージをその選択したノードへ通信装置により配信するステップを有することで、前記メッセージを用いた処理を前記複数のノードで分散して実行させることを特徴とする負荷分散処理方法。
各ノードがあるトピックのメッセージのサブスクライブを止めるアンサブスクライブ要求を発行し、前記代理サーバが、当該トピックのサブスクライブ要求を受付けた全てのノードから前記アンスクライブ要求を受信した場合に、そのトピックのメッセージのアンサブスクライブ要求を通信装置により前記ブローカへ送信し、当該トピックのサブスクライブ要求を送信したノードを示す情報を前記記憶装置から全て消去することを特徴とする請求項１に記載された負荷分散処理方法。
負荷分散対象とするトピックを示す情報を予め記憶装置へ格納しておき、前記サブスクライブ要求のトピックが前記記憶装置に格納されたトピックに一致した場合に、前記メッセージの配信による負荷分散処理を行わせることを特徴とする請求項１または請求項２のいずれか１項に記載された負荷分散処理方法。
パブリッシュ／サブスクライブ通信でメッセージを配信して負荷分散処理を複数ノードに実行させる代理サーバであって、
同一トピックのメッセージのサブスクライブを要求する複数ノードとそのメッセージを配信するブローカとの間に介在し、あるトピックの最初のサブスクライブ要求を通信装置によりブローカへ送信し、前記トピックのサブスクライブ要求を送信したノードを示す情報を記憶装置に格納するトピック検出部と、前記ブローカから前記トピックのメッセージを受信した場合に、そのトピックのサブスクライブ要求を送信したノードを示す情報を前記記憶装置から読み出し、その読み出した情報から一つを選択して当該メッセージをその選択したノードへ通信装置により配信する負荷分散部とを備えることで、前記メッセージを用いた処理を前記複数のノードで分散して実行させることを特徴とする代理サーバ。
パブリッシュ／サブスクライブ通信でメッセージを配信して負荷分散処理を複数ノードに実行させる代理サーバにおける負荷分散処理方法をコンピュータに実行させる為のプログラムであって、
同一トピックのメッセージのサブスクライブを要求する複数ノードとそのメッセージを配信するブローカとの間に介在する代理サーバが、あるトピックの最初のサブスクライブ要求を通信装置によりブローカへ送信し、前記トピックのサブスクライブ要求を送信したノードを示す情報を記憶装置に格納するステップと、前記代理サーバが、前記ブローカから前記トピックのメッセージを受信した場合に、そのトピックのサブスクライブ要求を送信したノードを示す情報を前記記憶装置から読み出し、その読み出した情報から一つを選択して当該メッセージをその選択したノードへ通信装置により配信するステップを有することで、前記メッセージを用いた処理を前記複数のノードで分散して実行させる負荷分散処理方法をコンピュータに実行させることを特徴とするプログラム。