JP6518411B2

JP6518411B2 - キューサーバ

Info

Publication number: JP6518411B2
Application number: JP2014138236A
Authority: JP
Inventors: 広貴堀江; 木下　雅文; 雅文木下; 神谷　俊之; 俊之神谷; 隆文小池
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2014-07-04
Filing date: 2014-07-04
Publication date: 2019-05-22
Anticipated expiration: 2034-07-04
Also published as: JP2016018222A

Description

本発明は、各サービスを実現するシステムにおいて、キューを扱うシステムに関する。

従来のキューを保持するシステムは、各用途においてキューを作成し、キューごとに、各リクエストをメッセージとして扱い、FIFO（ファーストインファーストアウト）で制御している。たとえば、メールシステムなどで使用されている、サービス加入/解約といったサービスを行う際に現状は、キューを用いたサーバを用いたシステム構成をしている場合が一般的である。キューを用いる理由としては、端末(クライアントサーバ)からの処理を遅延させることなく処理するため、また、サービスを実現する各サーバの障害時にも、リクエストを失わないようにするためである。

関連する技術として、特許文献１がある。この文献に開示されているのは、「順序依存性を持つキュー群を正しい順序でコンシューマシステムごとに統合できるキュー統合システム」であり、キュー内部ではなく、キュー間で優先順位を持たせて処理する技術である。そのため、サービスごとに、キューを作成し、さらに、キュー間での優先順位を管理させる結合キューを新たに設けることにより、キュー間での、リクエストの優先順位を決定し、優先順位どおりに処理をしている（要約参照）。

特開２００７−２６６７２４号公報

特許文献１が開示する技術では、キューごとの各サービス実現システムに対しての、優先順位保証は可能であるが、キュー内部のリクエスト単位での、順序制御はできない。また、各サービス実現システムごとのキューの設計が必要となり、運用面においても複雑な運用となる。

また、図９に示すようにキューを用いたシステムでは、キューは格納順に処理する。格納順で処理するため、キューに格納した相互関係が無い他のリクエストの処理の影響を受け、処理遅延が起きる課題がある。また、図１０で示すように、先頭のリクエストがエラーとなった場合に、後続の処理が先頭と相互関係が無い場合にも遅延してしまう課題がある。

上述したリクエストに限らず、キューに格納するメッセージとして扱えるデータ、例えば、各種通信プロトコルを用いてパソコンや携帯電話や携帯情報端末間で送受信される、文字、図、画像、音声、動画等を含む電子メールなどの情報や、センサ情報や、車などモノが発信するデータ、などについても同様の課題がある。

本発明は、同一キュー内において、キューの特徴である格納順での処理の中で、キュー内のメッセージにおいて、他のメッセージとの相互関係に基づいた処理順序の制御を可能とし、さらに、これによりキュー管理を容易にするキュー制御技術を提供する。

本発明は、キュー内部のメッセージの相互関係を管理する優先順位管理テーブルを用意し、キュー格納時に、相互関係のあるメッセージを関連付けるキー（以下、優先順位決定キーという）を付与することにより、同一キュー内での相互関係がないメッセージ同士の独立した処理を可能とし、優先順位決定キーを用いた順序制御によりキュー滞留を発生させないことを特徴とする。

より具体的な本発明の様態は、クライアントサーバから受信するサービスリクエストを、複数のサービス実現サーバへ中継するキューサーバである。
上記キューサーバは、キューとキュー情報管理部とを備え、キュー情報管理部は、受信した、いずれかのサービス実現サーバを宛先とするメッセージに、当該メッセージを相互関係のある他のメッセージと関連付けるキーを付して上記キューへ格納し、前記キューへの格納順に前記メッセージの前記サービス実現サーバへの送信処理を行い、上記キューから取得した、第一のメッセージと、前記第一のメッセージに付されたキーと同じキーが付された他のメッセージとに対して、上記キーと同じキーが付されていない第二のメッセージの送信処理の実行とは独立して、第一のサービス実現サーバへの送信処理を行い、前記第二のメッセージは前記第一のメッセージの送信処理の実行及び前記他のメッセージの送信処理の実行とは独立して、第二のサービス実現サーバへの送信処理を行うことを特徴とする。
また、上記キュー情報管理部は、上記キューへの上記メッセージの格納時に、同一の上記キーが付された上記メッセージを互いに関連付け、上記キューから上記メッセージを取得する際に、上記関連付けを参照するように構成してもよい。

本発明によれば、キューへのリクエスト格納時、キューからのリクエスト取得時において、キュー設計の簡略化や、相互関係がないリクエストの影響を受けた処理遅延を排除することが可能である。

本実施例の論理構成とテーブルを例示する図本実施例での優先順位決定キーがすべて同一の場合の通常処理を例示するシーケンス図本実施例での優先順位決定キーがすべて同一の場合のエラー処理を例示するシーケンス図本実施例での優先順位決定キーがリクエストBのみ異なる場合の通常処理を例示するシーケンス図本実施例での優先順位決定キーがリクエストBのみ異なる場合のエラー処理を例示するシーケンス図キューへリクエスト格納時のフローチャートを例示する図キューからリクエスト取得時のフローチャートを例示する図キューからリクエスト削除時のフローチャートを例示する図従来のキューを用いたサーバでの通常処理を表すシーケンス図従来のキューを用いたサーバでのエラー処理を表すシーケンス図

以下、本実施例の実施の形態について図面により詳細に説明する。以下の実施例では、メッセージの一例として、サービスのリクエストを取り上げて説明する。その他のメッセージについても同様に実施可能である。

図１は本実施例の実施の形態の論理構成とテーブル図を示したものである。３００はキューサーバであり、以下、優先順位保証サーバという。優先順位保証サーバ３００は、各サービスのリクエストを送信するクライアントサーバ１０２と、優先順位保証サーバ３００が中継するリクエストに基づいて、要求されたサービスを提供するサービス実現サーバ１０４〜１０６と接続される。

優先順位保証サーバ３００は、クライアントサーバ１０２からのリクエストを受信する入力インタフェース３０２、入力インタフェースからリクエストを格納するキュー３０３、リクエストをキュー３０３に格納したりキュー３０３から出力したりする場合の管理を行うキュー情報管理部３０４、出力インタフェース３０５を備える。

キュー情報管理部３０４は、キュー格納管理テーブル３０９、キュー取得管理テーブル３１３、優先順位制御テーブル３１０をメモリ上に保持する。

キュー格納管理テーブル３０９は、リクエストをキューへ格納する際に、リクエストID３０７と優先順位決定キー３０８とを対応付けたリストを格納し、格納したリクエストを管理するために用いる。キュー取得管理テーブル３１３は、キュー３０３からのリクエスト取得時に、リクエストID３１４を格納し、キュー３０３から取得したリクエストを管理するために用いる。

優先順位制御テーブル３１０は、優先順位決定キー３０８を一意のキーとして、それぞれの優先順位決定キー３０８に関連付くリクエストID３０７ａ、３０７ｂをリストとして持つテーブルである。キュー情報管理部３０４は、リクエストをキューへ格納する時とキューから取得する時に優先順位制御テーブル３１０を参照することにより、リクエストの送信順番の制御を行う。

キューからリクエストを取得する場合は、キュー格納管理テーブル３０９を検索し、取得できるリクエストを抽出する。取得しようとしたリクエストIDに優先順位決定キー３０８が設定されている場合は、当該リクエストIDの取得可否を判断するために、優先順位制御テーブル３１０を参照する。

優先順位決定キー３０８は、キューからリクエストを取り出す際に、取得するリクエストが、送信する際の順序制御の対象になるかどうかを判断する情報となる。キューに格納されたリクエストのうち、同一の優先順位決定キー３０８が付与されているリクエストは、格納順に送信する。たとえば、電話番号とか、イベント情報を優先順位決定キーに設定することで、他の電話番号、イベント情報と関係なくリクエストが送信可能となる。

優先順位保証サーバ３００は、プロセッサと記憶装置と通信装置とを備える一般的な計算機を用いて実現することが可能である。より具体的には、プロセッサが記憶装置に格納されたプログラムを実行することにより、キュー情報管理部３０４を実現し、キュー３０３を記憶装置上に構成することができる。また、プロセッサがプログラムを実行し通信装置と協働させることにより、入力インタフェース３０２と出力インタフェース３０５を実現できる。

次に、本実施例での優先順位決定キー３０８がすべて同一の値を設定した場合の通常処理を図２のシーケンスに従って説明する。

顧客端末１０１からクライアントサーバ１０２にリクエストA４０７を送信する。

クライアントサーバ１０２は優先順位保証サーバ３００へ転送し、４０９の処理でキュー３０３にリクエストAを格納する。

優先順位保証サーバ３００は、クライアントサーバ１０２へ正常応答４１０を応答し、クライアントサーバ１０２は、顧客端末１０１に正常応答４１１を応答する。

次に、リクエストBについてもリクエストAと同じシーケンスで処理する。

顧客端末１０１からクライアントサーバ１０２へリクエストB４１２を送信し、クライアントサーバ１０２は、優先順位保証サーバ３００にリクエストB４１３を転送する。

優先順位保証サーバ３００は、４１４の処理でキュー３０３にリクエストBを格納する。

優先順位保証サーバ３００は、４１４の処理後に、クライアントサーバ１０２に正常応答４１５を応答し、クライアントサーバ１０２は、顧客端末１０１へ正常応答４１６を応答する。

続いて、リクエストCについても、リクエストA、リクエストBと同じシーケンスで処理を実行する。

顧客端末１０１からクライアントサーバ１０２へリクエストC４１７を送信し、クライアントサーバ１０２は、優先順位保証サーバ３００にリクエストC４１８を転送する。

優先順位保証サーバ３００は、４１９の処理でキュー３０３にリクエストCを格納する。

優先順位保証サーバ３００は、４１９の処理後に、クライアントサーバ１０２に正常応答４２０を応答し、クライアントサーバ１０２は、顧客端末１０１へ正常応答４２１を応答する。

優先順位保証サーバ３００では、リクエストA、リクエストB、リクエストCの順番でキュー３０３に格納され、優先順位保証キーが同一であるので、４２２の処理で、キュー３０３からリクエストを取得し、サービス実現サーバA１０４へリクエストAを送信し、サービス実現サーバA１０４は正常応答４２４を応答する。

４２２の処理後、４２５の処理で、キュー３０３からリクエストAを削除する。

続けて、４２６の処理で、キュー３０３からリクエストBを取得し、サービス実現サーバB１０５にリクエストB４２７を送信し、サービス実現サーバB１０５は正常応答４２８を応答する。

４２６の処理後、４２９の処理で、キュー３０３からリクエストBを削除する。

最後に、４３０の処理でキュー３０３からリクエストCを取得し、サービス実現サーバC１０６へリクエストC４３１を送信し、サービス実現サーバC１０６は正常応答４３２を応答する。

４３０の処理後、４３３の処理で、キュー３０３からリクエストCを削除する。

図２の詳細に説明したとおり、リクエストA、リクエストB、リクエストCと連続で優先順位保証サーバ３００が受信した場合、且つ、優先順位決定キー３０８が同一の場合は、リクエストを格納順に処理する。

図３は、本実施例での優先順位決定キー３０８がすべて同一の値を設定した場合のエラー処理時の図であり、シーケンスに従って説明する。

顧客端末１０１からクライアントサーバ１０２にリクエストA５０７を送信する。

クライアントサーバ１０２は優先順位保証サーバ３００へ転送し、５０９の処理でキュー３０３にリクエストAを格納する。

優先順位保証サーバ３００は、クライアントサーバ１０２へ正常応答５１０を応答し、クライアントサーバ１０２は、顧客端末１０１に正常応答５１１を応答する。

顧客端末１０１からクライアントサーバ１０２へリクエストB５１２を送信し、クライアントサーバ１０２は、優先順位保証サーバ３００にリクエストB５１３を転送する。

優先順位保証サーバ３００は、５１４の処理でキュー３０３にリクエストBを格納する。

優先順位保証サーバ３００は、５１４の処理後に、クライアントサーバ１０２に正常応答５１５を応答し、クライアントサーバ１０２は、顧客端末１０１へ正常応答５１６を応答する。

顧客端末１０１からクライアントサーバ１０２へリクエストB５１７を送信し、クライアントサーバ１０２は、優先順位保証サーバ３００にリクエストC５１８を転送する。

優先順位保証サーバ３００は、５１９の処理でキュー３０３にリクエストCを格納する。

優先順位保証サーバ３００は、５１９の処理後に、クライアントサーバ１０２に正常応答５２０を応答し、クライアントサーバ１０２は、顧客端末１０１へ正常応答５２１を応答する。

次に優先順位保証サーバ３００は、５２２の処理でキュー３０３からリクエストAを取得し、リクエストAをサービス実現サーバA１０４へ送信する。

サービス実現サーバA１０４はエラー応答５２４を応答する。

優先順位保証サーバ３００は、エラー応答を受けたため、５２５の処理でリクエストAのリトライ処理を実行する。

キュー３０３に格納されているリクエストB、リクエストCについては、５２５の処理でリクエストAの処理を実行しているため、図２に示したリクエストB、リクエストCの処理は実行されない。

次に、本実施例での優先順位決定キー３０８がリクエストBのみ異なる値を設定した場合の通常処理を図４のシーケンスに従って説明する。

顧客端末１０１からクライアントサーバ１０２にリクエストA６０７を送信する。

クライアントサーバ１０２は優先順位保証サーバ３００へ転送し、６０９の処理でキュー３０３にリクエストAを格納する。

優先順位保証サーバ３００は、クライアントサーバ１０２へ正常応答６１０を応答し、クライアントサーバ１０２は、顧客端末１０１に正常応答６１１を応答する。

顧客端末１０１からクライアントサーバ１０２へリクエストB６１２を送信し、クライアントサーバ１０２は、優先順位保証サーバ３００にリクエストB６１３を転送する。

優先順位保証サーバ３００は、６１４の処理でキュー３０３にリクエストBを格納する。

優先順位保証サーバ３００は、６１４の処理後に、クライアントサーバ１０２に正常応答６１５を応答し、クライアントサーバ１０２は、顧客端末１０１へ正常応答６１６を応答する。

顧客端末１０１からクライアントサーバ１０２へリクエストC６１７を送信し、クライアントサーバ１０２は、優先順位保証サーバ３００にリクエストC６１８を転送する。

優先順位保証サーバ３００は、６１９の処理でキュー３０３にリクエストCを格納する。

優先順位保証サーバ３００は、６１９の処理後に、クライアントサーバ１０２に正常応答６２０を応答し、クライアントサーバ１０２は、顧客端末１０１へ正常応答６２１を応答する。

優先順位保証サーバ３００では、リクエストA、リクエストB、リクエストCの順番でキュー３０３に格納される。

６２２の処理で、キュー３０３からリクエストを取得し、サービス実現サーバA１０４へリクエストAを送信し、サービス実現サーバA１０４は正常応答６２４を応答する。

６２２の処理後、６２５の処理で、キュー３０３からリクエストAを削除する。

図３で示した条件とは異なり、優先順位保証キーがリクエストBのみ異なるため、６２６の処理で、キュー３０３からリクエストCを取得し、サービス実現サーバC１０６にリクエストC６２７を送信し、サービス実現サーバC１０６は正常応答６２８を応答する。

６２６の処理後、６２９の処理で、キュー３０３からリクエストCを削除する。

最後に、６３０の処理でキュー３０３からリクエストBを取得し、サービス実現サーバB１０５へリクエストB６３１を送信し、サービス実現サーバB１０５は正常応答６３２を応答する。

６３０の処理後、６３３の処理で、キュー３０３からリクエストBを削除する。

図４の詳細に説明したとおり、リクエストA、リクエストB、リクエストCと連続で優先順位保証サーバ３００が受信した場合、且つ、優先順位決定キー３０８がリクエストBのみ異なる場合は、リクエストA、リクエストCを格納順に処理するが、リクエストBは、リクエストA、リクエストCの処理とは関係なく、処理が可能となる。

図５は、本実施例での優先順位決定キー３０８がリクエストBのみが異なる値を設定した場合のエラー処理時の図であり、シーケンスに従って説明する。

顧客端末１０１からクライアントサーバ１０２にリクエストA７０７を送信する。

クライアントサーバ１０２は優先順位保証サーバ３００へ転送し、７０９の処理でキュー３０３にリクエストAを格納する。

優先順位保証サーバ３００は、クライアントサーバ１０２へ正常応答７１０を応答し、クライアントサーバ１０２は、顧客端末１０１に正常応答７１１を応答する。

顧客端末１０１からクライアントサーバ１０２へリクエストB７１２を送信し、クライアントサーバ１０２は、優先順位保証サーバ３００にリクエストB７１３を転送する。

優先順位保証サーバ３００は、７１４の処理でキュー３０３にリクエストBを格納する。

優先順位保証サーバ３００は、７１４の処理後に、クライアントサーバ１０２に正常応答７１５を応答し、クライアントサーバ１０２は、顧客端末１０１へ正常応答７１６を応答する。

顧客端末１０１からクライアントサーバ１０２へリクエストC７１７を送信し、クライアントサーバ１０２は、優先順位保証サーバ３００にリクエストC７１８を転送する。

優先順位保証サーバ３００は、７１９の処理でキュー３０３にリクエストCを格納する。

優先順位保証サーバ３００は、７１９の処理後に、クライアントサーバ１０２に正常応答７２０を応答し、クライアントサーバ１０２は、顧客端末１０１へ正常応答７２１を応答する。

次に優先順位保証サーバ３００は、７２２の処理でキュー３０３からリクエストAを取得し、リクエストAをサービス実現サーバA１０４へ送信する。

サービス実現サーバA１０４はエラー応答７２４を応答する。

優先順位保証サーバ３００は、エラー応答を受けたため、７２５の処理でリクエストAのリトライ処理を実行する。

キュー３０３に格納されているリクエストCについては、７２５の処理でリクエストAの処理を実行しているため、図４に示したリクエストCの処理は実行されない。

リクエストBについては、優先順位決定キー３０８が異なるため、７２６の処理で、サービス実現サーバB１０５にリクエストB７２７を送信し、サービス実現サーバB１０５は正常応答７２８を応答する。

７２６の処理後、７２９の処理で、キュー３０３からリクエストBを削除する。

次に、優先順位保証サーバ３００のキュー情報管理部３０４による、キュー３０３へリクエストを格納する処理の詳細を、図６のフローチャートに従って説明する。

リクエスト格納時処理では、リクエストを優先順位制御するかを判定するために、８０１で優先順位決定キー３０８の有無を解析する。

８０２にて、優先順位決定キー３０８の判定をし、優先順位決定キー３０８がある場合は、８０３にて、図１で説明したキュー格納管理テーブル３０９にリクエストID３０７と優先順位決定キー３０８を関連付けて格納する。

其の後、８０４の処理で、優先順位制御テーブル３１０の情報を取得し、８０５で、優先順位決定キー３０８が優先順位制御テーブル３１０に登録済みかの判定をする。

判定結果が、YESの場合は、すでに登録されているため、先に格納しているリクエストID３０７より後に処理することとなるため、８０６の処理ですでに登録してあるリクエストID３０７の後ろに追加でリクエストID３０７を格納する。

その後、８０７の処理でキュー３０３にリクエストを格納する。

８０５の判定結果で、NOの場合は、優先順位制御テーブル３１０に新規に優先順位決定キー３０８とリクエストID３０７を格納する。

８０２の判定で、優先順位決定キー３０８がない場合は、キュー格納管理テーブル３０９にリクエストID３０７を格納し、８０７の処理でキュー３０３にリクエストを格納して処理を終了する。

次に、優先順位保証サーバ３００のキュー情報管理部３０４による、キュー３０３からリクエストを取得する処理の詳細を、図７のフローチャートに従って説明する。

リクエスト取得処理では、取得可能なリクエストを判定するために、９０１でキュー格納管理テーブル３０９の情報を取得する。

９０１で取得したキュー格納管理テーブル３０９から、リクエストID３０７、優先順位決定キー３０８を取得し、９０２で、優先順位決定キー３０８の有無を判定する。

判定結果がなしの場合は、優先順位決定キーがないリクエストのため、各サーバへリクエストを優先的に送信する必要はない。そのため、９１０でリクエストをキュー３０３から取得し、９１１で取得したリクエストを各サーバへ送信し、９１２でリクエストID３０７をキュー取得管理テーブル３１３に格納し、９１３でキュー格納管理テーブル３０９からリクエストID３０７、優先順位決定キーを削除し、処理を終了する。

９０２の判定結果でありの場合、優先順位決定キーがあり、各サーバへリクエストの送信の優先順位を保つ必要がある。そのため、９０３で優先順位制御テーブル３１０から情報を取得する。

優先順位制御テーブル３１０から、９０４で取得するリクエストID３０７が先頭であるかを判定する。

判定結果がYESの場合は、取得時にキューに格納されているリクエストの中で、取得しようとしているリクエストが先頭であるため、９０５でリクエストをキュー３０３から取得し、９０６でリクエストを各サーバへ送信し、９０７でリクエストID３０７をキュー取得管理テーブル３１３に格納し、９０９でキュー格納管理テーブル３０９からリクエストID３０７、優先順位決定キー３０８を削除し、処理を終了する。

９０４の判定結果がNOの場合は、取得しようしたリクエストが先頭に格納されていないこととなり、他に優先的に送信するリクエストがある判断となるため、その後はなにも実行せずに処理を終了する。

次に、優先順位保証サーバ３００のキュー情報管理部３０４による、キュー３０３からリクエストを削除する処理の詳細を、図８のフローチャートに従って説明する。リクエスト削除処理では、１００１でキュー取得管理テーブル３１３情報を取得し、１００２でキュー取得管理テーブル３１３からリクエストID３０７を削除し、１００３で、優先順位制御テーブル３１０から情報を取得し、１００４で、優先順位制御テーブル３１０からリクエストID３０７を削除し、１００５でキュー３０３からリクエストを削除し、処理を終了する。

３００：優先順位保証サーバ
３０３：キュー
３０４：キュー情報管理部
３０９：キュー格納管理テーブル
３１０：優先順位制御テーブル
３１３：キュー取得管理テーブル

Claims

クライアントサーバから受信するサービスリクエストを、複数のサービス実現サーバへ中継するキューサーバであって、
キューとキュー情報管理部とを備え、
前記キュー情報管理部は、
受信した、いずれかの前記サービス実現サーバを宛先とするメッセージに、当該メッセージを相互関係のある他のメッセージと関連付けるキーを付して前記キューへ格納し、
前記キューへの格納順に前記メッセージの前記サービス実現サーバへの送信処理を行い、
前記キューから取得した、第一のメッセージと、前記第一のメッセージに付されたキーと同じキーが付された他のメッセージとに対して、前記キーと同じキーが付されていない第二のメッセージの送信処理の実行とは独立して、第一のサービス実現サーバへの送信処理を行い、前記第二のメッセージは前記第一のメッセージの送信処理の実行及び前記他のメッセージの送信処理の実行とは独立して、第二のサービス実現サーバへの送信処理を行う
ことを特徴とするキューサーバ。
請求項１に記載のキューサーバであって、
前記キュー情報管理部は、
前記キューへの前記メッセージの格納時に、同一の前記キーが付された前記メッセージを互いに関連付け、
前記キューから前記メッセージを取得する際に、前記関連付けを参照する
ことを特徴とするキューサーバ。
請求項１に記載のキューサーバであって、
前記キュー情報管理部は、
前記第一のメッセージの送信処理の実行、または前記第一のメッセージに付されたキーと同じキーが付された他のメッセージの送信処理を実行した際、前記第一のメッセージまたは前記他のメッセージにおける前記送信処理の結果として前記第一のサービス実現サーバからエラー応答が回答されたとしても、前記第二のメッセージは第二のサービス実現サーバへの送信処理を行う
ことを特徴とするキューサーバ。