JP2011198250A

JP2011198250A - リクエストを処理する情報処理装置、方法及びコンピュータプログラム

Info

Publication number: JP2011198250A
Application number: JP2010066391A
Authority: JP
Inventors: Hirotaka Nakano; 裕隆中野
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2010-03-23
Filing date: 2010-03-23
Publication date: 2011-10-06
Anticipated expiration: 2030-03-23
Also published as: JP4575993B1

Abstract

【課題】マスタデータの更新頻度が高いリアルタイムシステムでキャッシュヒット率を高め、システム全体のスループットを向上させる。
【解決手段】キャッシュサーバ１００は、データ参照リクエストを受け付けたとき、キャッシュヒットすれば、そのリクエストに係るデータをキャッシュメモリ１３０から取得して応答を返し、キャッシュミスすれば、リクエストに係るデータをデータベース１６から取得して返すとともに、キャッシュメモリ１３０へ格納する参照処理部１０１と、マスタデータが更新されたときは、ユーザ単位に更新後のマスタデータをデータベース１６から取得して、キャッシュメモリ１３０に保存する照会処理部１１１と、を備える。
【選択図】図２

Description

本発明は、キャッシュメモリを効率的に利用するための技術に関し、特にマスタデータの更新頻度が高いリアルタイムシステムでキャッシュヒット率を高め、システム全体のスループットを向上させる技術に関する。

従来、リクエストに対する応答時間を短縮させるために、マスタデータをキャッシュメモリに保存することが行われる。例えば、特許文献１には、Ｗｅｂデータが更新されたときに、データ管理プロセスがその旨をキャッシュ管理プロセスへ通知すると、キャッシュ管理プロセスがキャッシュファイルを更新することが記載されている。これにより、Ｗｅｂクライアントからのリクエストに対する応答時間を飛躍的に短縮できる。

特開２００１−５７１５号公報

ところで、ユーザからの有価証券の売買注文を、有価証券の取引所システムへ取り次ぐような取引管理システムでは、短時間に多数の売買注文及びデータ照会などのリクエストを受け付ける。特に、取引開始直後及び終了直前などにはリクエストが殺到する。そのため、この時間帯は極めて負荷が高くなり、リクエストに対する応答が遅れる原因となる。

特に、ヘビーユーザと呼ばれる一部の少数ユーザは、複数台のユーザ端末装置を使って、同時に多数の売買注文及びデータ照会リクエストを発行する。この一部のヘビーユーザが大量リクエストを発行するために、他の多くの一般のユーザの処理まで遅れてしまうという問題があった。

このように、マスタデータの更新頻度が高いリアルタイムシステムでは、マスタデータをキャッシュメモリに保存しても、キャッシュヒット率を高めることが難しく、実効性が乏しいという問題があった。

そこで、本発明の目的は、マスタデータの更新頻度が高いリアルタイムシステムでキャッシュヒット率を高め、システム全体のスループットを向上させることである。

本発明の一つの実施態様に従うリクエストを処理する情報処理装置は、ユーザ別のマスタデータを記憶するデータベースと、前記マスタデータの複製であるコピーデータを、ユーザ別に記憶するキャッシュメモリと、ユーザからデータ参照を要求するリクエストを受け付けたとき、キャッシュヒットすれば、前記リクエストに係るデータを前記キャッシュメモリから取得して前記リクエストに対する応答を返し、キャッシュミスすれば、前記リクエストに係るデータを前記データベースから取得して前記リクエストに対する応答を返すとともに、取得したデータをキャッシュメモリへ格納するリクエスト処理部と、ユーザ単位に、前記マスタデータが更新されたか否かを判定し、前記マスタデータが更新されたときは、ユーザ単位に更新後のマスタデータを前記データベースから取得して、前記キャッシュメモリに保存するキャッシュ管理部と、を備える。

好適な実施形態では、前記リクエスト処理部は、同一ユーザまたは複数のユーザからの複数のリクエストを受け付けると、前記複数のリクエストのそれぞれについて、キャッシュヒットすれば、前記キャッシュメモリから取得したデータを応答として返し、キャッシュミスすれば、前記リクエストに係るデータを前記データベースから取得して前記リクエストに対する応答を返すとともに、取得したデータをキャッシュメモリへ格納し、前記キャッシュ管理部は、前記リクエスト処理部が行う処理とは独立して、ユーザ単位に前記マスタデータが更新されたか否かを判定し、前記マスタデータが更新されたときは、ユーザ単位に更新後のマスタデータを取得して、前記キャッシュメモリに保存するようにしてもよい。

好適な実施形態では、前記キャッシュシステムは、有価証券取引のための取引所システムと接続されていて、ユーザからの売買注文を受け付けると、前記キャッシュメモリから、その売買注文を発注したユーザのコピーデータを消去するとともに、前記取引所システムに対して前記売買注文に係る注文指示を出力する注文受付部をさらに備え、前記キャッシュ管理部は、前記取引所システムからの通知に基づく前記売買注文の約定を検出すると、前記売買注文に係るユーザのマスタデータが更新されたと判定し、更新後のマスタデータを前記データベースから取得して、前記キャッシュメモリに保存するようにしてもよい。

好適な実施形態では、前記キャッシュ管理部は、第１のユーザのマスタデータが更新されたと判定されたときは、前記第１のユーザのマスタデータを前記データベースから取得中でないときに、前記データベースから前記第１のユーザの更新後のマスタデータの取得を開始して、取得後に前記キャッシュメモリに保存し、前記第１のユーザのマスタデータを前記データベースから取得中のときは、前記第１のユーザの更新後のマスタデータの取得を開始しないようにしてもよい。

好適な実施形態では、前記キャッシュ管理部は、ラウンドロビン方式で、前記ユーザ単位にマスタデータが更新されたか否かの判定を行うようにしてもよい。

好適な実施形態では、前記ユーザ別のマスタデータには、各ユーザの注文照会、預かり資産、及び買い付け余力に関するデータが含まれてもよい。

本発明の一実施形態に係る有価証券の取引管理システムを含む有価証券取引を行うコンピュータシステムの概要図である。キャッシュサーバ１００の詳細な構成図を示す。キャッシュメモリ１３０のデータ構造の一例を示す。注文受付処理のフローチャートである。約定受付処理のフローチャートである。キャッシュメモリの更新処理のフローチャートである。データ参照処理のフローチャートである。

以下、本発明のリクエストを処理する情報処理装置を適用した、本発明の一実施形態に係る有価証券の取引管理システムについて、図面を参照して説明する。

図１は、本実施形態に係る有価証券の取引管理システム１を含む有価証券取引を行うコンピュータシステムの概要を示す図である。

本実施形態に係る有価証券の取引管理システム（以下、単に取引管理システムと称する）１は、有価証券取引のための取引所システム（以下、単に取引所システムと称する）３、及び複数のユーザ端末装置５，５，・・・と接続されている。

取引所システム３は、取引管理システム１から有価証券の売買注文を受け付ける。取引所システム３は、多数の売買注文を受け付けると、これらを付き合わせて売買注文を約定させる。取引所システム３は、取引管理システム１から受け付けた売買注文に基づく取引が約定すると、取引管理システム１に対してその約定内容を示す約定通知を行う。

ユーザ端末装置５，５，・・・は、通信機能を有する端末装置であればよく、例えば、携帯電話機、携帯情報端末、あるいは汎用的なパーソナルコンピュータなどでもよい。ユーザ端末装置５，５，・・・は、液晶パネルなどの表示装置、及びプッシュボタンあるいはポインティングデバイスなどの入力装置を有する。ユーザ端末装置５，５，・・・は、ユーザに対して所定のインタフェース画面を提供し、ユーザから売買注文などの指示入力を受け付けたり、現在の口座のステータスを表示したりする。

取引管理システム１は、複数のユーザの有価証券の取引口座に関する情報を管理して、取引所システム３に対する売買注文などを行い、取引口座に関する情報をリアルタイムに更新する。取引管理システム１は、複数のユーザ端末装置５，５，・・・から種々のリクエストを受け付けて、それぞれのリクエストへ応答を返す、いわゆるリアルタイムシステムである。例えば、複数の異なるユーザが、それぞれ異なるユーザ端末装置５，５，・・・からリクエスト送ることもできるし、同一のユーザが複数のユーザ端末装置５，５，・・・を利用して、それぞれ異なるリクエストを送信することもできる。ユーザ端末装置５が送信するリクエストは、例えば、有価証券の売買注文、及び現在の口座のステータス（たとえば、注文照会、預かり資産及び買い付け余力など）に係るデータの照会のリクエストなどがある。

取引管理システム１は、一つのリクエストが完了する前に次のリクエストを受け付ける。このとき、取引管理システム１は、複数のリクエストを同時に受け付けた状態となる。この複数のリクエストは、同一ユーザからのものであってもよいし、複数の異なるユーザからのものであってもよい。特に、取引が集中する時間帯には、取引管理システム１は、多数のリクエストを同時に受け付ける。

取引管理システム１は、図１に示すように、リクエスト処理サーバ１１と、通知処理サーバ１２と、キャッシュサーバ１００と、取引管理サーバ１５とを有する。

リクエスト処理サーバ１１と、通知処理サーバ１２と、キャッシュサーバ１００と、取引管理サーバ１５は、いずれも例えば汎用的なコンピュータシステムにより構成され、以下に説明する各サーバ１１，１２，１００，１５内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。このコンピュータプログラムは、コンピュータ読み取り可能な記録媒体に格納可能である。

リクエスト処理サーバ１１は、ユーザ端末装置５，５，・・・からのリクエストを受け付けて、このリクエストに対する応答を返す。例えば、リクエスト処理サーバ１１は、ユーザ端末装置５，５，・・・からリクエストを受け付けると、このリクエストをキャッシュサーバ１００へ中継する。リクエスト処理サーバ１１は、キャッシュサーバ１００からリクエストの応答を受け付けると、要求元のユーザ端末装置５，５，・・・へその応答を返す。

通知処理サーバ１２は、ユーザ端末装置５，５，・・・に対する通知を行う。例えば、取引管理システム１に対して取引所システム３から約定通知があると、通知処理サーバ１２がその約定通知に係るユーザのユーザ端末装置５，５，・・・へ約定通知を示すデータを送信する。

取引管理サーバ１５は、複数のユーザの口座を管理するとともに、各ユーザからの有価証券の取引注文を受け付けて、取引所システム３に対して取引注文を発注する。取引管理サーバ１５は、データベース１６を有する。取引管理サーバ１５は、このデータベース１６を用いて、複数のユーザの有価証券取引に係る口座情報、例えば売買注文、預かり資産及び買い付け余力などを管理する。

データベース１６には、ユーザの識別情報であるユーザＩＤ別に、それぞれのユーザの売買注文履歴、預かり資産及び買い付け余力に関するデータが記憶されている。売買注文履歴には、例えば、約定した売買注文の履歴及び受付中で未約定の売買注文の履歴などが含まれる。取引管理サーバ１５は、例えば、売買注文を受けると、その注文に関する情報を売買履歴に未約定の売買注文として追加して、取引所システム３に対してその売買注文を発行する。また、取引管理サーバ１５は、取引所システム３から約定通知を受けると、その約定通知に対応する未約定の売買注文を約定済みに変更する売買履歴の更新を行うとともに、預かり資産及び買い付け余力等を更新する。

キャッシュサーバ１００は、コピーデータを記憶するキャッシュメモリ１３０を有する。ここでは、取引管理サーバ１５が保持しているデータベース１６に格納されているデータをマスタデータとして、そのマスタデータの複製であるコピーデータがキャッシュメモリ１３０に格納される。

図２は、キャッシュサーバ１００の詳細な構成図を示す。

キャッシュサーバ１００は、キャッシュメモリ１３０と、参照処理部１０１と、注文受付処理部１０３と、約定受付処理部１０５と、照会処理部１１１と、除外処理部１１３と、バリデート処理部１１５とを備える。

キャッシュメモリ１３０は、データベース１５０のマスタデータの複製であるコピーデータを、ユーザ別に記憶する。例えば、キャッシュメモリ１３０は、ユーザ識別情報であるユーザＩＤ別に、各ユーザＩＤに関連するデータを記憶する領域が予め確保されている。

キャッシュメモリ１３０のデータ構造の一例を図３に示す。

キャッシュメモリ１３０には、ユーザＩＤ１３１別に、ユーザＩＤに関連するデータを記憶する領域であるデータエリア１３３が設けられている。データエリア１３３には、各ユーザＩＤ１３１に対応するコピーデータが格納される。データエリア１３３には、例えば、最終データ取得開始時刻Ｔ１と、最終約定通知時刻Ｔ２と、問い合わせ中フラグＦと、コピーデータ本体Ｄとが記憶される。

最終データ取得開始時刻Ｔ１は、照会処理部１１１が取引管理サーバ１５から、それぞれのユーザＩＤ１３１に係るユーザのマスタデータの取得処理を開始した時刻である。照会処理部１１１が行う処理の詳細については後述する。

最終約定通知時刻Ｔ２は、約定受付処理部１０５が、それぞれのユーザＩＤ１３１に係るユーザの売買注文が約定した旨の通知を受けた時刻のうち、最も新しい時刻（最近の時刻）を示す。約定受付処理部１０５が行う処理の詳細については後述する。

問い合わせ中フラグＦは、照会処理部１１１が取引管理サーバ１５から、それぞれのユーザＩＤ１３１に係るユーザのマスタデータを取得中であるか否かを示すフラグである。つまり、このフラグＦが“０”であれば、照会処理部１１１はデータ取得中ではなく、このフラグＦが“１”であれば、データ取得中であることを示す。

改めて図２を参照すると、参照処理部１０１は、リクエスト処理サーバ１１を介してユーザ端末装置５からのデータ参照リクエストを受け付けて、これに対する応答を返す。例えば、参照処理部１０１は、データ参照を要求するリクエストを受け付けたとき、キャッシュヒットすれば、リクエストに係るデータをキャッシュメモリ１３０から取得してリクエストに対する応答を返す。一方、キャッシュミスすれば、リクエストに係るデータをデータベース１５０から取得してリクエストに対する応答を返すとともに、取得したデータをキャッシュメモリ１３０へ格納する。

また、参照処理部１０１は、同一ユーザまたは複数のユーザからの複数のリクエストを受け付けると、受付順に、それぞれのリクエストに対して独立に応答する。つまり、参照処理部１０１は、複数のリクエストのそれぞれについて、キャッシュヒットすれば、キャッシュメモリ１３０から取得したデータを応答として返し、キャッシュミスすれば、リクエストに係るデータをデータベース１６から取得してリクエストに対する応答を返すとともに、取得したデータをキャッシュメモリ１３０へ格納する。

参照処理部１０１は、受け付けたリクエストに対する応答を返す前であっても、次のリクエストが来ればそれを受け付ける。従って、キャッシュヒット率が高いほど、平均の応答時間は短くなる。

注文受付処理部１０３は、リクエスト処理サーバ１１を介してユーザ端末装置５からの売買注文を受け付けると、キャッシュメモリ１３０に保存されている、その売買注文を発行したユーザのコピーデータを消去するとともに、取引管理サーバ１５を介して取引所システム３に対して売買注文に係る注文指示を出力する。例えば、注文受付処理部１０３は、リクエスト処理サーバ１１から売買注文を受け付けると、その売買注文に含まれるユーザＩＤ（つまり、売買注文を発行したユーザのユーザＩＤ）と対応するキャッシュメモリ１３０のデータエリア１３３のコピーデータ本体Ｄを消去する。

売買注文が発行されると、取引管理サーバ１５において、その売買注文に関連する処理が行われ、データベース１６内のそのユーザに関連するマスタデータが更新される。従って、キャッシュメモリ１３０内のコピーデータをそのまま放置すると、マスタデータとコピーデータとが一致しなくなる。そこで、売買注文を発行する前に、注文受付処理部１０３が予めその注文を発行したユーザのコピーデータをキャッシュメモリ１３０から消去する。これにより、更新前のデータがキャッシュメモリ１３０に残ってしまうことを防止できる。

約定受付処理部１０５は、取引管理サーバ１５から、売買注文が約定したことを示す約定通知を受け付ける。約定受付処理部１０５は、この約定通知を通知処理サーバ１２へ転送する。約定受付処理部１０５は、このときに、約定通知に含まれるユーザＩＤに対応する、キャッシュメモリ１３０のデータエリア１３３内の最終約定通知時刻Ｔ２を更新する。

ここで、この約定通知は、データベース１６が更新された後に取引管理サーバ１５から通知される。つまり、この約定通知によって、約定通知に係るユーザのマスタデータが更新されたことがわかる。従って、約定通知に基づいて更新された最終約定通知時刻Ｔ２もまた、これに対応するユーザのマスタデータが更新されたことを示すものである。次に説明するように、照会処理部１１１は、最終約定通知時刻Ｔ２に基づいてマスタデータが更新されたか否かの判定を行う。

照会処理部１１１は、データベース１６に保存されているマスタデータを取得して、キャッシュメモリ１３０に保存する。例えば、照会処理部１１１は、ユーザ単位に、マスタデータが更新されたか否かを判定し、マスタデータが更新されたときは、ユーザ単位に更新後のマスタデータをデータベース１６から取得して、キャッシュメモリ１３０に保存する。ここで、照会処理部１１１は、参照処理部１０１が参照リクエストを受け付けたか否かには依存せず、独立して上記の処理を行う。

照会処理部１１１は、最終データ取得開始時刻Ｔ１及び最終約定通知時刻Ｔ２からマスタデータが更新されたか否かを判定する。すなわち、最終約定通知時刻Ｔ２が最終データ取得開始時刻Ｔ１よりも後の時刻（Ｔ１＜Ｔ２）であれば、現在格納されているコピーデータの取得を開始した時刻以降に約定があったということである。つまり、Ｔ１＜Ｔ２であれば、マスタデータが更新され、コピーデータと一致しない状態となっていることを意味する。従って、このときには照会処理部１１１は、改めてデータベース１６からマスタデータを取得して、キャッシュメモリ１３０に保存することにより、コピーデータをマスタデータと一致させることができる。

照会処理部１１１は、データベース１６からマスタデータの取得を開始する際に、最終データ取得開始時刻Ｔ１を現在時刻に更新する。これにより、最終データ取得開始時刻Ｔ１は最も新しくマスタデータの取得を開始した時刻となる。照会処理部１１１は、さらに、マスタデータの取得を開始する際に、問い合わせ中フラグＦに“１”をセットする。そして、マスタデータの取得が完了し、取得したデータをキャッシュメモリ１３０へ格納した後、問い合わせ中フラグＦを“０”に戻す。これにより、照会処理部１１１が、データベース１６からデータを取得中であるときは、問い合わせ中フラグＦが“１”となっている。

照会処理部１１１は、参照処理部１０１（リクエスト処理部）が行う処理とは独立して、ユーザ単位にマスタデータが更新されたか否かを判定し、マスタデータが更新されたときは、ユーザ単位に更新後のマスタデータを取得して、キャッシュメモリ１３０に保存する。例えば、参照処理部１０１が同一ユーザから多数のリクエストをほぼ同じタイミングで受け付けたようなときであっても、そのリクエストを受け付けたタイミング及び回数に依存せずに、照会処理部１１１は、照会処理部１１１に対して予め定められたルールに従って、マスタデータの取得を行う。

例えば、照会処理部１１１は、ラウンドロビン方式で、ユーザ単位にマスタデータが更新されたか否かの判定を行い、更新されていた場合は更新後のマスタデータを取得して、キャッシュメモリ１３０に格納する。つまり、照会処理部１１１は、あるユーザＩＤについて、マスタデータの取得要否を判定し、必要であるときはデータベース１６からマスタデータを取得し、取得不要であるときは取得しない。照会処理部１１１は、この処理をユーザＩＤ１３１ごとに、順次、繰り返して行う。

照会処理部１１１は、複数のタスクを用いて並列処理を行うようにしてもよい。この場合、照会処理部１１１の異なるタスクが、同時に同じユーザＩＤ１３１についてマスタデータ取得処理を行ってしまうおそれがある。それを回避するために問い合わせ中フラグＦを用いる。すなわち、照会処理部１１１は、処理を開始する前に、問い合わせ中フラグＦの状態を判定する。つまり、問い合わせ中フラグＦが“１”であれば、他のタスクがマスタデータを取得する処理を実行中である。このときは、照会処理部１１１は処理を行わずに、次のユーザＩＤ１３１へ移行する。

除外処理部１１３は、ユーザ単位に、キャッシュメモリ１３０のデータを消去する。例えば、除外処理部１１３は、取引管理サーバ１５に照会をして、ログアウトしたユーザＩＤを検出すると、そのユーザＩＤのデータがキャッシュメモリ１３０に残存していれば、それを消去する。

バリデート処理部１１５は、コピーデータ本体Ｄが所定時間以上更新されていないときは、これを強制的に更新させるために、最終約定通知時刻Ｔ２を現在時刻に更新する。これにより、上述した照会処理部１１１がデータベース１６から最新のマスタデータを取得して、データエリア１３３のコピーデータ本体Ｄが更新される。

次に、上記のような構成を備えたキャッシュサーバ１００の処理手順について、図４〜図７のフローチャートを用いて説明する。

図４は、注文受付処理のフローチャートである。

まず、ユーザ端末装置５がユーザから売買注文の入力を受け付けると、リクエスト処理サーバ１１に対して売買注文リクエストが発行される。

キャッシュサーバ１００は、リクエスト処理サーバ１１を介してこの売買注文リクエストを受け付ける（Ｓ１１）。

参照処理部１０１は、この売買注文リクエストを発行したユーザＩＤを特定すると、キャッシュメモリ１３０において、このユーザＩＤ１３１に対応するデータエリア１３３のコピーデータ本体Ｄを消去する（Ｓ１３）。

その後、参照処理部１０１は、この売買注文を取引管理サーバ１５へ送信する（Ｓ１５）。

取引管理サーバ１５がこの売買注文を受け付けると、所定の処理を行って取引所システム３へ売買注文が発行される。

これにより、売買注文をリクエストしたユーザに関連するコピーデータがキャッシュメモリ１３０から消去された状態で、取引所システム３に対して売買注文が発行される。これにより、マスタデータと一致しないことが明らかなコピーデータがキャッシュメモリ１３０に残存することがない。

図５は、約定受付処理のフローチャートである。

まず、取引管理サーバ１５が取引所システム３から約定通知を受ける。取引管理サーバ１５は、この約定通知に基づいてデータベース１６を更新するなどの所定の処理を実行後、キャッシュサーバ１００へ約定通知を行う。

キャッシュサーバ１００は、取引管理サーバ１５から約定通知を受け付ける（Ｓ２１）。

約定受付処理部１０５は、この約定通知がどのユーザの取引に係るものであるかを、その約定通知に含まれるユーザＩＤで特定すると、キャッシュメモリ１３０において、このユーザＩＤ１３１に対応するデータエリア１３３の最終約定通知時刻Ｔ２を現在時刻に更新する（Ｓ２３）。

その後、約定受付処理部１０５は、この約定通知を通知処理サーバ１２へ送信する（Ｓ２５）。

通知処理サーバ１２は、その約定通知に含まれるユーザＩＤに対応するユーザ端末装置５へ、約定通知を送信する。

これにより、あるユーザの取引で約定があると、キャッシュメモリ１３０内のそのユーザの最終約定通知時刻Ｔ２が更新される。その結果、照会処理部１１１が最終データ取得開始時刻Ｔ１及び最終約定通知時刻Ｔ２を参照することにより、マスタデータが更新されたことを検出できる。

図６は、照会処理部１１１によるキャッシュメモリ１３０の更新処理のフローチャートである。

照会処理部１１１は、ラウンドロビン方式でユーザＩＤ１３１ごとにデータエリア１３３のコピーデータ本体Ｄの更新を行う。その具体的な処理手順を以下に説明する。

まず、照会処理部１１１が対象ユーザＩＤを特定する（Ｓ３１）。

このユーザＩＤについて、最終約定通知時刻Ｔ２が最終データ取得開始時刻Ｔ１より後であるか否かを判定する（Ｓ３３）。

ここで、最終約定通知時刻Ｔ２が最終データ取得開始時刻Ｔ１より後でないときは（Ｓ３３：Ｎｏ）、そのユーザＩＤについては何も処理を行わず、ステップＳ３１へ戻り次のユーザＩＤの処理へ移行する。これは、マスタデータが更新されていないので、データエリア１３３のコピーデータ本体Ｄを更新する必要がないからである。

最終約定通知時刻Ｔ２が最終データ取得開始時刻Ｔ１より後であるときは（Ｓ３３：Ｙｅｓ）、照会処理部１１１は、対象ユーザＩＤについて、問い合わせ中フラグＦが“０”であるか否かを判定する（Ｓ３５）。

ここで、問い合わせ中フラグＦが“０”でないときも（Ｓ３５：Ｎｏ）、そのユーザＩＤについては何も処理を行わず、ステップＳ３１へ戻り次のユーザＩＤの処理へ移行する。これは、既に別のタスクが対象ユーザのデータ更新を行っている最中なので、重複処理を回避するためである。

問い合わせ中フラグＦが“０”であるときは（Ｓ３５：Ｙｅｓ）、照会処理部１１１は、最終データ取得開始時刻Ｔ１に現在時刻をセットするとともに、問い合わせ中フラグＦに“１”をセットする（Ｓ３７）。その後、照会処理部１１１が取引管理サーバ１５に対して、対象ユーザＩＤに関するデータの取得を要求する（Ｓ３９）。照会処理部１１１は、取引管理サーバ１５から取得した対象ユーザＩＤに関するデータを、順次キャッシュメモリ１３０のデータエリア１３３に格納する（Ｓ４１）。そして、所望のデータの取得が完了すると（Ｓ４３）、照会処理部１１１は、問い合わせ中フラグＦを“０”に戻す（Ｓ４５）。

ステップＳ４５までの処理が完了すると、照会処理部１１１は、ステップＳ３１へ戻って、次のユーザＩＤを特定して、上記の処理を繰り返し行う。

これにより、照会処理部１１１は、ユーザからのリクエストとは独立に、つまり、リクエストの多少に関わらず、マスタデータが更新されると、ほぼリアルタイムにマスタデータとコピーデータとを一致させることができる。

また、本実施形態では、照会処理部１１１は、上記の通り、マスタデータの取得処理をユーザＩＤ単位で行っている。その結果、参照処理部１０１が、同一のユーザ（いわゆるヘビーユーザ）から大量のリクエストを受け付けたときでも、そのヘビーユーザについてだけ、マスタデータを取得する回数が増加するということはない。つまり、参照処理部１０１が受け付けるリクエスト数に依存することなく、照会処理部１１１から取引管理サーバ１５へのマスタデータの取得要求の回数は、全ユーザについて平等である。

よって、いわゆるヘビーユーザが大量のリクエストを発行した場合であっても、取引管理サーバ１５にマスタデータの取得要求が集中し、取引管理サーバ１５が過負荷状態となってスループットが低下するということがない。

図７は、データ参照処理のフローチャートである。

まず、ユーザから入力されたデータ更新指示、及び自動データ更新をトリガとして、ユーザ端末装置５がリクエスト処理サーバ１１に対してデータ参照リクエストが発行する。

キャッシュサーバ１００は、リクエスト処理サーバ１１を介してこのデータ参照リクエストを受け付ける（Ｓ５１）。

参照処理部１０１は、このデータ参照リクエストを発行したユーザＩＤを特定すると、キャッシュメモリ１３０にこのユーザＩＤ１３１のデータエリア１３３が存在し、所望のデータが存在するか否か、つまりキャッシュヒットしたか否かを判定する（Ｓ５３）。

キャッシュヒットすれば（Ｓ５３：Ｙｅｓ）、参照処理部１０１は、データ参照リクエストに係るデータを、キャッシュメモリ１３０のデータエリア１３３から取得し（Ｓ５５）、ここで取得したデータを、通知処理サーバ１２へ送信する（Ｓ６１）。

一方、キャッシュミスすれば（Ｓ５３：Ｎｏ）、参照処理部１０１が取引管理サーバ１５に対して、データ参照リクエストを発行したユーザＩＤのマスタデータの取得要求を行う（Ｓ５７）。参照処理部１０１は、キャッシュメモリ１３０上のユーザＩＤ１３１のデータエリア１３３に、取得したデータを保存する（Ｓ５９）。

参照処理部１０１は、ここで取得したデータを、通知処理サーバ１２へ送信する（Ｓ６１）。

図６で説明した更新処理が継続的に行われているので、ここで説明した参照処理でのキャッシュヒット率は高くなる。つまり、ステップＳ５５でキャッシュメモリ１３０からデータを取得する回数が増え、ステップＳ５７で取引管理サーバ１５にマスタデータの取得要求をする回数が減り、これによっても、取引管理サーバ１５の負荷が軽減され、スループットの低下防止に貢献する。

上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

例えば、上述の実施形態では、本発明のリクエストを処理する情報処理装置を有価証券の取引管理システムに適用した場合を例にとって説明したが、これ以外の用途に適用することも可能である。

１取引管理システム
３取引所システム
５，５，・・・ユーザ端末装置
１１リクエスト処理サーバ
１２通知処理サーバ
１５取引管理サーバ
１６データベース
１００キャッシュサーバ
１０１参照処理部
１０３注文受付処理部
１０５約定受付処理部
１１１照会処理部
１１３除外処理部
１１５バリデート処理部
１３０キャッシュメモリ

Claims

ユーザ別のマスタデータを記憶するデータベースと、
前記マスタデータの複製であるコピーデータを、ユーザ別に記憶するキャッシュメモリと、
ユーザからデータ参照を要求するリクエストを受け付けたとき、キャッシュヒットすれば、前記リクエストに係るデータを前記キャッシュメモリから取得して前記リクエストに対する応答を返し、キャッシュミスすれば、前記リクエストに係るデータを前記データベースから取得して前記リクエストに対する応答を返すとともに、取得したデータをキャッシュメモリへ格納するリクエスト処理部と、
ユーザ単位に、前記マスタデータが更新されたか否かを判定し、前記マスタデータが更新されたときは、ユーザ単位に更新後のマスタデータを前記データベースから取得して、前記キャッシュメモリに保存するキャッシュ管理部と、を備えたリクエストを処理する情報処理装置。
前記リクエスト処理部は、同一ユーザまたは複数のユーザからの複数のリクエストを受け付けると、前記複数のリクエストのそれぞれについて、キャッシュヒットすれば、前記キャッシュメモリから取得したデータを応答として返し、キャッシュミスすれば、前記リクエストに係るデータを前記データベースから取得して前記リクエストに対する応答を返すとともに、取得したデータをキャッシュメモリへ格納し、
前記キャッシュ管理部は、前記リクエスト処理部が行う処理とは独立して、ユーザ単位に前記マスタデータが更新されたか否かを判定し、前記マスタデータが更新されたときは、ユーザ単位に更新後のマスタデータを取得して、前記キャッシュメモリに保存する、請求項１記載のリクエストを処理する情報処理装置。
前記キャッシュシステムは、有価証券取引のための取引所システムと接続されていて、
ユーザからの売買注文を受け付けると、前記キャッシュメモリから、その売買注文を発注したユーザのコピーデータを消去するとともに、前記取引所システムに対して前記売買注文に係る注文指示を出力する注文受付部をさらに備え、
前記キャッシュ管理部は、前記取引所システムからの通知に基づく前記売買注文の約定を検出すると、前記売買注文に係るユーザのマスタデータが更新されたと判定し、更新後のマスタデータを前記データベースから取得して、前記キャッシュメモリに保存する、請求項１または２に記載のリクエストを処理する情報処理装置。
前記キャッシュ管理部は、第１のユーザのマスタデータが更新されたと判定されたときは、
前記第１のユーザのマスタデータを前記データベースから取得中でないときに、前記データベースから前記第１のユーザの更新後のマスタデータの取得を開始して、取得後に前記キャッシュメモリに保存し、
前記第１のユーザのマスタデータを前記データベースから取得中のときは、前記第１のユーザの更新後のマスタデータの取得を開始しない、請求項１〜３のいずれかに記載のリクエストを処理する情報処理装置。
前記キャッシュ管理部は、ラウンドロビン方式で、前記ユーザ単位にマスタデータが更新されたか否かの判定を行う、請求項１〜４のいずれかに記載のリクエストを処理する情報処理装置。
前記ユーザ別のマスタデータには、各ユーザの注文照会、預かり資産、及び買い付け余力に関するデータが含まれる、請求項１〜５のいずれかに記載のリクエストを処理する情報処理装置。
ユーザ別のマスタデータを記憶するデータベースと、前記マスタデータの複製であるコピーデータを、ユーザ別に記憶するキャッシュメモリと、を備えた情報処理装置が、
ユーザからデータ参照を要求するリクエストを受け付けたとき、キャッシュヒットすれば、前記リクエストに係るデータを前記キャッシュメモリから取得して前記リクエストに対する応答を返す処理と、
データ参照を要求するリクエストを受け付けたとき、キャッシュミスすれば、前記リクエストに係るデータを前記データベースから取得して前記リクエストに対する応答を返すとともに、取得したデータをキャッシュメモリへ格納する処理と、
ユーザ単位に、前記マスタデータが更新されたか否かを判定し、前記マスタデータが更新されたときは、ユーザ単位に更新後のマスタデータを前記データベースから取得して、前記キャッシュメモリに保存する処理と、を実行するリクエスト処理のための方法。
ユーザ別のマスタデータを記憶するデータベースと、前記マスタデータの複製であるコピーデータを、ユーザ別に記憶するキャッシュメモリと、を備えた情報処理装置がリクエスト処理のためのコンピュータプログラムであって、
前記情報処理装置に、
ユーザからデータ参照を要求するリクエストを受け付けたとき、キャッシュヒットすれば、前記リクエストに係るデータを前記キャッシュメモリから取得して前記リクエストに対する応答を返す処理と、
データ参照を要求するリクエストを受け付けたとき、キャッシュミスすれば、前記リクエストに係るデータを前記データベースから取得して前記リクエストに対する応答を返すとともに、取得したデータをキャッシュメモリへ格納する処理と、
ユーザ単位に、前記マスタデータが更新されたか否かを判定し、前記マスタデータが更新されたときは、ユーザ単位に更新後のマスタデータを前記データベースから取得して、前記キャッシュメモリに保存する処理と、を実行させるためのコンピュータプログラム。