JPWO2016157358A1 - データ処理システム - Google Patents

Abstract

【課題】同一データを複数のDB サーバに保全するに際し、処理の迅速性を確保する。【解決手段】複数のAP サーバと複数のDB サーバを備えたデータ処理システム10 において、各DB サーバは、共通の業務データを格納する共通のテーブルを備えるが、レコードの削除及び更新が禁止される。各AP サーバは、全DB サーバと接続され、共通の業務処理を実行し、処理結果の業務データを各DB サーバに送信し、対応テーブルへの追加を依頼する。各業務データには、実行したAP サーバの識別符号を含むID が付され、各DB サーバには、排他制御が求められる特定の業務処理を担当するAP サーバを定義する担当AP 定義テーブルが格納されている。各AP サーバは、排他制御を要する処理の場合に担当AP 定義テーブルを参照して担当AP サーバを特定し処理を委譲する。担当AP サーバは、この業務処理をキューに格納した後、FIFO に従って順に実行する。

Description

この発明はデータ処理システムに係り、特に、複数のAPサーバによって生成された業務データを、複数のDBサーバで重複管理する技術に関する。

地震や津波、噴火等の大規模災害、あるいは原発事故やテロ等の人災によってデータベースが物理的に損壊する場合に備え、企業の基幹システムにおいては、業務データを遠隔地に設置したバックアップ用のデータベースに重複登録することが以前より行われている。
例えば、特許文献１においては、正制御装置のディスク装置にデータを登録した後、遠隔地に設置された副制御装置に同一データを送信し、その登録を求める技術が開示されている。
特開平１１−８５４０８号 Webシステム入門／第１回 Webサイトの構成とJ2EEサーバ インターネットURL：http://www.atmarkit.co.jp/fjava/rensai2/websys01/websys01.html 検索日：２０１５年３月１０日 ２相コミット インターネットURL：http://e-words.jp/w/2%E3%83%95%E3%82%A7%E3%83%BC%E3%82%BA%E3%82%B3%E3%83%9F%E3%83%83%E3%83%88.html 検索日：２０１５年３月１０日

このように、正副２台の制御装置によってデータを二重持ちすることにより、一方の地域において地震等が発生し、ディスク装置が物理的に破損した場合であっても、生き残った他方のディスク装置内のデータを活用することで、業務処理の連続性を担保することが可能となる。
また、サーバコンピュータ自体の故障やトラブルも想定されるため、遠隔地に限らず、同一拠点内においても普段からデータベースサーバを二重化しておき、万一の事態に備えることが望ましいといえる。

ところで、複数のデータベースに対する更新処理を実行する際には、全てのデータベースに対するコミットが成立しないとデータ相互間に矛盾が生じるため、通常はXAインターフェースの２相コミットと称する調停方式が採用され、データベース相互間の整合性が担保される。

この２相コミットではまず、処理全体を司るマスターサーバが、対象となる各DBサーバに対し、コミットが実行可能であるかを問い合わせる。更新準備が整っているDBサーバは「準備完了」の応答を返し、すべてのDBサーバが準備を終えたことを確認した上で、マスターサーバはコミット開始を通知し、データベースが一斉に書き換えられる。書き換え中にいずれかのデータベースで異常が発生した場合、異常が生じたDBサーバは失敗を伝え、マスターサーバはすべてのサーバに処理撤回を通知して、データを復元する「ロールバック」処理を行うよう指示する（非特許文献２）。

このような２相コミットを採用することにより、DBサーバ間でのデータ整合性が確保され、不正なデータが発生することは確かに回避できる。
しかしながら、マスターサーバと遠隔地に設置されたDBサーバ間で何度もデータのやり取りを繰り返す必要があることから、処理の迅速性が犠牲とならざるを得なかった。このため、ATM取引のように数秒程度の待ち時間が生じても問題にならない業務処理に対しては有効であっても、例えばオンライントレードのように、コンマ何秒かの遅延も許されないような業務処理には適用できないという問題があった。

この発明は、このような現状に鑑みて案出されたものであり、同一データを複数のDBサーバに保全することを前提としながらも、処理の迅速性を確保することが可能な技術の実現を目的としている。

上記の目的を達成するため、請求項１に記載したデータ処理システムは、複数のAPサーバと、複数のDBサーバを備えたデータ処理システムであって、上記の各DBサーバは、相互に共通する業務データを格納するテーブルをそれぞれ備える共に、各テーブルにはレコードの参照及び追加のみが許容され、削除及び更新が禁止される制約が設けられており、上記の各APサーバは、それぞれ上記の各DBサーバと接続されており、クライアント端末から送信されたリクエストに対して共通の業務処理を実行する機能と、処理の結果生じた業務データを上記の各DBサーバに送信し、対応のテーブルへの追加登録を依頼する機能を備え、上記の各業務データには、これを生成したAPサーバを特定するための識別符号を含むユニークなIDが割り振られており、さらに、上記の各DBサーバには、排他制御が求められる特定の業務処理を担当するAPサーバを業務処理毎に定義しておく担当AP定義テーブルが格納されており、上記の各APサーバは、上記クライアント端末から送信された業務処理のリクエストが、排他制御を要するものでない場合には自ら実行するのに対し、排他制御を要するものである場合には上記担当AP定義テーブルを参照し、当該業務処理を担当すべきAPサーバを特定した後、当該担当APサーバに該当の処理を委譲し、これを受けた担当APサーバは、委譲された業務処理を一旦キューに格納した後、キュー内の各業務処理をFIFOのルールに従って順に実行することを特徴としている。

請求項２に記載したデータ処理システムは、請求項１のシステムであって、さらに、上記担当AP定義テーブルには、主担当APサーバの他に、当該主担当APサーバが機能しない場合に処理を担当すべき副担当APサーバが業務処理毎に定義されていることを特徴としている。

請求項３に記載したデータ処理システムは、請求項１または２のシステムであって、さらに、上記の業務データにはそれぞれ業務処理実行時のタイムスタンプが刻印されており、上記APサーバは、既存の業務データを更新する必要がある場合に、当該業務データと異なる昇順のID、修正後のデータ及び修正時のタイムスタンプを備えた業務データを新たに生成すると共に、この更新用の業務データを各DBサーバに設けられた該当のテーブルに追加登録させることにより、既存の業務データを実質的に更新することを特徴としている。

請求項４に記載したデータ処理システムは、請求項１〜３のシステムであって、さらに、上記APサーバは既存の業務データを削除する必要がある場合に、取消対象として当該業務データのIDを格納するデータ項目を備えたデータ取消用の業務データを生成すると共に、このデータ取消用の業務データを各DBサーバに設けられた取消専用のテーブルに追加登録させることにより、既存の業務データを実質的に削除することを特徴としている。

請求項１に記載したデータ処理システムによれば、APサーバによって生成された業務データが複数のDBサーバに同時に送信され、それぞれのテーブルに重複登録されるため、業務データの保全性を高めることができる。
しかも、業務データの登録については障害発生時にデータの復旧に複雑な処理を要する削除や更新が禁止されており、単純に他のDBサーバから不足データをコピーするだけでデータの復旧が可能な追加のみが許容されているため、２相コミットのような厳格な調停方式を採用する必要がなく、各DBサーバから単純に受取通知が返ってきた時点で登録完了と認定することができる。

また、APサーバも複数用意され、排他制御を要しない業務処理であれば各APサーバが自由に処理できるため、負荷分散によりシステム全体の処理効率を高めることができる。
これに対し、排他制御を要する一部の業務処理については、担当AP定義テーブルにおいて予め設定されたAPサーバに処理が集約され、FIFOのルールに則って処理されるため、異なるAPサーバによって相互に矛盾するデータが生成されることを有効に回避することができる。
各APサーバにおいて生成される業務データには、それぞれのAPサーバの識別符号を含むユニークなIDが割り振られているため、DBサーバに対して各APサーバからバラバラに業務データが送信されても、それぞれのIDが重複することがなく、絶対的なユニーク性が担保される。

請求項２に記載したデータ処理システムの場合、担当AP定義テーブルにおいて主担当APサーバの他に副担当APサーバも定義されているため、何らかの事由によって主担当APサーバがダウンしている場合であっても、副担当APサーバに対して速やかに業務処理を委譲することが可能となる。

この発明の場合、DBサーバのテーブルにはレコードの削除及び更新が禁止される制約が設けられているが、請求項３及び４に記載の仕組みを用いることにより、業務データの実質的な更新や削除を実現することが可能となる。

図１は、この発明に係るデータ処理システム10の全体構成図である。
まず、東京に配置された第１のデータセンター12内には、第１のAPサーバ14と、第１のDBサーバ16と、第２のDBサーバ18が設置されている。
また、大阪に配置された第２のデータセンター20内には、第２のAPサーバ22と、第３のDBサーバ24と、第４のDBサーバ26が設置されている。

第１のAPサーバ14及び第２のAPサーバ22は、それぞれ同一のアプリケーションプログラムを備えており、インターネット等の通信ネットワーク27経由でクライアント端末28から送信されたリクエストに対し、同一の業務処理を実行する機能を有する。

図示の便宜上、第１のAPサーバ14及び第２のAPサーバ22のみが描かれているが、実際には各データセンター内には同一機能を備えた複数のAPサーバが設置され、図示しないロードバランサを介して負荷分散が図られている。
このように、同一データセンター内に複数のAPサーバを設けておけば、何れかのAPサーバの計画停止時あるいは計画外停止時おいても、他のデータセンター内のAPサーバに切り替えることなく同一データセンター内の残りのAPサーバで代替可能となり、ダウンタイムを最小化することができる。
DBサーバの数にも限定はなく、３台以上のDBサーバを各データセンター内に設置することができる。

第１のDBサーバ16、第２のDBサーバ18、第３のDBサーバ24及び第４のDBサーバ26は、それぞれ共通のテーブルを備えており、各テーブルには同一のデータが格納されている。
ここでは、図２は示すように、ポイント加算テーブル50と、加算取消テーブル51と、ポイント適用テーブル52と、適用取消テーブル53と、担当AP定義テーブル54を各DBサーバは共通して備えている。

ポイント加算テーブル50には、加算ID、アカウント、ポイント数、タイムスタンプ等のデータ項目が設定されている。
また、加算取消テーブル51には、取消対象、タイムスタンプ等のデータ項目が設定されている。
ポイント適用テーブル52には、適用ID、アカウント、ポイント数、タイムスタンプ等のデータ項目が設定されている。
また、適用取消テーブル53には、取消対象、タイムスタンプ等のデータ項目が設定されている。
担当AP定義テーブル54には、担当AP定義IDと、アカウントと、主担当APと、副担当AP等のデータ項目が設定されている。
上記の加算ID、適用IDには、人工キーによるユニークな識別コードが格納される（詳細は後述）。

第１のAPサーバ14は、LANを介して第１のDBサーバ16及び第２のDBサーバ18と接続されると共に、通信回線29を介して第２のデータセンター20内に設置された第３のDBサーバ24及び第４のDBサーバ26とも接続されている。
また、第２のAPサーバ22は、LANを介して第３のDBサーバ24及び第４のDBサーバ26と接続されると共に、通信回線29を介して第１のデータセンター12内に設置された第１のDBサーバ16及び第２のDBサーバ18とも接続されている。

平常時においては、東日本に設置されたクライアント端末28は第１のデータセンター12内に設置された第１のAPサーバ14に接続され、西日本に設置されたクライアント端末28は第２のデータセンター20内に設置された第２のAPサーバ22に接続される。

これに対し、例えば大規模な地震が首都圏で発生し、第１のデータセンター12が壊滅的な打撃を受けた場合には、DNSサーバ（図示省略）の設定変更により、東日本に設置されたクライアント端末28の接続先が第２のデータセンター20内に設置された第２のAPサーバ22に切り替えられるため、東日本のユーザに対するサービスの継続性が確保される。
同様に、第２のデータセンター20が被害を受けた場合には、西日本に設置されたクライアント端末28の接続先が第１のデータセンター12内に設定された第１のAPサーバ14に切り替えられる。

このように、各データセンターは平常時には近隣のクライアント端末28に対してサービスを提供する一方、災害時には全国のクライアント端末28に対してもサービスを提供することになるため、上記したように、各DBサーバは普段から同一内容のデータを相互に保持しておく必要がある。
また、同一データセンター内にも同一のデータを備えた複数のDBサーバが設置されているため、データを参照する際にAPサーバは任意のDBサーバにデータの抽出を依頼することができ、負荷分散を図ることができる。

データセンターの数は２つに限定されるものではなく、可能な限り多くのデータセンターを各地に設けると共に、同一機能を備えた複数のAPサーバをそれぞれに設置し、各データセンター内に設置された全DBサーバと通信ネットワーク経由で接続するように構成することが望ましい。

図３は、第１のAPサーバ14及び第２のAPサーバ22の内部構成を示すものであり、それぞれ業務処理部30と、人工キー管理部32と、データ制御部34と、複数のDB連絡部38とを備えている。

業務処理部30は、クライアント端末28からのリクエストに応じてデータの生成処理や演算処理、DBサーバへの登録処理等を実行するものであり、APサーバのCPUが専用のアプリケーションプログラムに従って動作することにより、実現される。

人工キー管理部32は、業務処理部30からのリクエストに応じて、人工キー（サロゲートキー）を発行する機能を備えている（詳細は後述）。
この人工キー管理部32は、専用のミドルウェアに従ってAPサーバのCPUが動作することにより、実現される。

データ制御部34は、業務処理部30からデータ登録の指令を受けた際に、データをDBサーバの数だけ複製し、それぞれをDB連絡部38に渡す機能等を担うものであり、専用のミドルウェアに従ってAPサーバのCPUが動作することにより、実現される。
またデータ制御部34は、人工キー管理部32の指令を受け、同一データセンター内に設置された各DBサーバを担当するDB連絡部38に対して、人工キー管理データの更新を指令する機能をも備えている（詳細は後述）。

各DB連絡部38は、予め自己に割り当てられたDBサーバに対してSQL文を発行し、データの追加登録及び参照を指令する機能等を果たすものであり、専用のミドルウェアに従ってAPサーバのCPUが動作することにより、実現される。

ここで、図４のフローチャートに基づき、このシステム10における人工キー付与の仕組みについて説明する。
まず、業務処理の結果としてデータを生成する必要が生じた業務処理部30は、人工キー管理部32に対して、テーブルを指定して人工キーの発行を要求する（Ｓ10）。上記のポイント加算テーブル50に格納するデータを生成するケースであれば、「加算ID」用の人工キーの発行を要求することとなる。

これを受けた人工キー管理部32は、同じデータセンター内に設置されたDBサーバに格納されている人工キー管理テーブル56を参照し（Ｓ12）、ポイント加算テーブル50に係る最新の人工キーを業務処理部30に通知する（Ｓ14）。

図５に示すように、人工キー管理テーブル56は、「テーブルID」、「APサーバID」、「次のキー値」のデータ項目を備えており、「テーブルID」＋「APサーバ」単位で最新の人工キー（次のキー値）が管理されている。

ここで「人工キー」とは、所定の長さ（例えば32bitまたは64bit）を備えた数値よりなる。
また、数値の下一桁（末尾）には、データを生成したAPサーバを特定するための識別符号（０〜９の何れかの数値）がセットされている。

具体的には、人工キーの下一桁管理テーブル57において、各APサーバのIDと０〜９の数値との関連性が定義されている。
また、APサーバ管理テーブル58及びデータセンター管理テーブル59において、各APサーバとデータセンターとの関連性が定義されている。
これら人工キーの下一桁管理テーブル57、APサーバ管理テーブル58、データセンター管理テーブル59も、人工キー管理テーブル56と同じく、同一データセンター内のDBサーバに格納されている。

業務処理部30に対して人工キーの最新値を通知し終えた人工キー管理部32は、人工キー管理テーブル56の各レコードの値を更新させる（Ｓ16）。
具体的には、当該APサーバに係るポイント加算テーブル50の「次のキー値」に対して、「直前の値（上記の最新値）の中で、末尾の識別符号を除いた部分で構成される数値に、１を加算した値」をセットする。

ただし、人工キーの最新値の更新方法としては、このような「昇順」に限定されるものではなく、「直前の値（上記の最新値）の中で、末尾の識別符号を除いた部分で構成される数値から１を減算した値」をセットする「降順」であってもよい。APサーバの識別符号も上記のような「０〜９」の数値に限定されるものではなく、他の文字種を用いてもよい。また、人工キーの先頭に識別符号を挿入してもよい。
さらには、人工キー管理テーブル56の「次のキー値」にAPサーバの識別符号を除いた数値のみを格納しておき、人工キーの発行時点で人工キー管理部32が対応の識別符号を上記数値の末尾等に付加して業務処理部30に発行することもできる。

人工キー管理部32から最新の人工キーを受け取った業務処理部30は、当該人工キーをIDとしてプライマリーキーや外部キーにセットしたデータを生成する（Ｓ18）。
このデータは、データ制御部34及びDB連絡部38を介して全DBサーバに送信され、それぞれに設けられた対応のテーブル（ポイント加算テーブル50）に追加登録される。

上記のように、人工キーは「APサーバ×テーブル」単位でユニーク性が担保され、各APサーバはデータセンター管理テーブル59において特定のデータセンターと紐付けされているため、各APサーバにおいてそれぞれ独自に人工キーが発行されたとしても、下一桁の数値に独自性が確保されているため、重複する人工キーが発行される危険性はなく、各データのユニーク性は確実に担保される。

なお、APサーバの業務処理部30から発せられた人工キー発行のリクエストは、一旦キューに溜められた上で、FIFO（先入れ先出し）のルールに則って処理されるため、後から発生したデータに対して誤って値の小さい人工キーが発行される危険性はなく、順序性が担保される。

各APサーバの業務処理部30によって生成されたデータは、上記のように各DBサーバ内のテーブルに格納されることになるが、各テーブルには、削除（デリート）禁止及び更新（アップデート）禁止の制約が予め課せられている。
要するに、このシステム10においては、各テーブルに対する追加（インサート）と参照（セレクト）のみが許容されることになる。

このため、既存のデータを無効にする必要が生じた場合には、レコードを削除する代わりに、他のテーブルに新たなレコードを追加することで同等の状態を実現する。
例えば、図２に示したポイント加算データを無効化する場合には、加算取消テーブル51に加算取消データを追加する。
この加算取消データの「取消対象」には、無効化すべきポイント加算データの加算IDが充填されているため、業務処理部30はポイント加算テーブル50に登録されたポイント加算データの中で、その加算IDが加算取消テーブル51に登録されているものについては、カウント対象外とする。

同様に、ポイント適用データを無効化する場合には、適用取消テーブル53に適用取消データを追加する。
この適用取消データの「取消対象」には、無効化すべきポイント適用データの適用IDが充填されているため、業務処理部30はポイント適用テーブル52に登録されたポイント適用データの中で、その適用IDが適用取消テーブル53に登録されているものについては、カウント対象外とする。

また、このシステム10において登録データの修正が必要な場合には、既存レコードをアップデートする代わりに、修正後のデータを備えたレコードを新規に登録することで対応する。
例えば、ポイント加算データのポイント数を修正する場合、当該ポイント加算データの加算IDとは異なる昇順の加算IDを新たに払い出すと共に、同じアカウントでポイント数を変更したポイント加算データを、ポイント加算テーブル50に追加する。
修正前のデータと修正後のデータには、ミリ秒精度のタイムスタンプが刻印されており、またそれぞれに昇順の異なる加算IDが付与されているため、業務処理部30は集計時に最新のデータを間違いなく特定することができる。

上記のように、各DBサーバには同一のデータが格納されており、また各APサーバは同一の業務処理を実行する機能を備えているため、多数のクライアント端末28に対して同時並行的にサービスを提供することが可能となり、システム10全体の負荷分散が可能となる。

ただし、業務処理の内容によっては、各APサーバ間における排他制御が必要となるものが存在する。
まず、商品やサービスを購入したユーザに対してポイントを加算する処理については排他制御の必要はなく、例えば企業内の複数の社員によって当該企業のアカウントに対するポイント加算要求が同時に発生した場合に、複数のAPサーバにおいて同時並行的に処理がなされても、特に問題は生じない。
同じく、同一のアカウントに対するポイント残高照会処理に関しても、排他制御は不要といえる。
これに対し、当該アカウントに蓄積されたポイントを用いて商品を購入する場面では、蓄積ポイント数に限りがあるため、同時並行的にポイント適用の要求があった場合には、排他制御を実行する必要性がある。

以下、図６の模式図及び図７〜図１０のフローチャートに従い、このシステム10をポイント管理業務に応用した場合の一般的な処理手順を説明した上で、排他制御方式について説明する。
まず、あるユーザが店頭で商品を購入し、ポイントカードを提示すると、店舗内のクライアント端末28Aからポイントカードのアカウント（カード番号）と、当該商品購入によって発生したポイント数（加算ポイント数）が、第２のAPサーバ22に送信される。

このポイント加算リクエストを受けた第２のAPサーバ22の業務処理部30は（図７のＳ10）、加算IDの発行を人工キー管理部32から受けた後、ポイント加算データを生成する（Ｓ12）。
つぎに業務処理部30は、各DB連絡部38を介して第１のDBサーバ14〜第４のDBサーバ26に対してポイント加算データの追加登録を依頼する（Ｓ14）。
これを受けた第１のDBサーバ14〜第４のDBサーバ26は、一斉にそれぞれのポイント加算テーブル50にポイント加算データを追加する。

つぎに業務処理部30は、当該ユーザのポイント残高を計算する（Ｓ16）。
具体的には、当該アカウントに関連付けられた全ポイント加算データを何れかのDBサーバから取得し（図８のＳ16-01）、各ポイント加算データから加算IDを抽出する（Ｓ16-02）。
つぎに、この加算IDを任意のDBサーバに送信し、対応の加算取消データを取得する（Ｓ16-03）。
そして、加算取消データが登録されているポイント加算データを除き、残りの有効なポイント加算データのポイント数を総計することにより（Ｓ16-04）、当該ユーザの加算ポイント数を確定する。

つぎに、当該アカウントに関連付けられた全ポイント適用データを何れかのDBサーバから取得し（Ｓ16-05）、各ポイント適用データから適用IDを抽出する（Ｓ16-06）。
つぎに、この適用IDを任意のDBサーバに送信し、対応の適用取消データを取得する（Ｓ16-07）。
そして、適用取消データが登録されているポイント適用データを除き、残りの有効なポイント適用データのポイント数を総計することにより（Ｓ16-08）、当該ユーザの適用ポイント数を確定する。

つぎに、全有効加算ポイントから全有効適用ポイントを減算することにより（Ｓ16-09）、現時点におけるポイント残高を確定する。
このポイント残高は、クライアント端末に送信され（図７のＳ18）、レシートに印字される。

これに対し、あるユーザが店頭においてポイントの適用を希望した場合、クライアント端末28Bからポイントカードのアカウント（カード番号）と、購入商品の代金に応じた適用ポイント数が、第２のAPサーバ22に送信される。

このポイント適用リクエストを受けた第２のAPサーバ22の業務処理部30は（図９のＳ30）、何れかのDBサーバ内の担当AP定義テーブルを参照し、当該アカウントについてのポイント適用処理を担当するAPサーバを特定する（Ｓ32）。そして、たまたま自己が主担当APサーバとして指定されていた場合には、そのまま後述のポイント適用処理を執行するが、他のAPサーバ（例えば第１のAPサーバ14）が担当APサーバとして指定されていた場合には、該当のAPサーバにリクエスト（アカウント、適用ポイント数等）を転送し、ポイント適用処理を委譲する（Ｓ34）。

この処理の委譲を受けた第１のAPサーバ14は、このリクエストを一旦FIFOのキューに格納した後（Ｓ36）、順番にポイント適用処理を実行していく（Ｓ38）。
このポイント適用処理は、具体的には以下の手順に従う。
まず、第１のAPサーバ14は、上記と同様の手順により、当該アカウントのポイント残高を算出する（図１０のＳ38-01）。

つぎに、このポイント残高の範囲内で、ポイント適用データを生成する（Ｓ38-02）。
例えば、現時点でのポイント残高が今回の適用ポイント数を上回っている場合、業務処理部30は人工キー管理部32から適用IDの発行を受けた後、ポイント適用データ（適用ID、アカウント、ポイント数、タイムスタンプ）を生成する。
そして、全DBサーバに対してポイント適用データの追加登録を依頼する（Ｓ38-03）。
これに対し、この時点でポイント残高が適用ポイント数を下回っていた場合、業務処理部30は残存ポイント数分のポイント適用データを生成し、全DBサーバに対してその追加登録を依頼する。この結果、当該アカウントのポイント残高はゼロとなる。

委譲されたポイント適用処理を完了した第１のAPサーバ14は、第２のAPサーバ22に対して処理結果（適用ポイント数とポイント残高）を通知する（図９のＳ40）。

これを受けた第２のAPサーバの業務処理部30は、処理結果をクライアント端末28Bに送信する（Ｓ42）。
すなわち、全購入金額についてポイントが適用できた場合には、その旨とポイント残高がクライアント端末28Bに通知される。
これに対し、購入金額の一部にのみポイントが適用された場合には、その旨と不足金額がクライアント端末28Bに通知される。この際、店頭では不足分について現金決済がなされる。

上記のように、排他制御が必要なポイント適用処理に差し掛かった段階で、第２のAPサーバ22から第１のAPサーバ14に処理の権限が委譲され、第１のAPサーバ14においてはFIFOのルールに従ってポイント適用処理が実行される。このため、ほぼ同時期に同一のアカウントに係るポイント適用リクエストがクライアント端末28Cから第１のAPサーバ14に送信されていたとしても、FIFO（先入れ先出し）のルールに従って競合リクエスト間の調整が図られるため、不正な処理（実際にはポイント残高がゼロなのにもかかわらず、ポイントの適用が執行されてしまうこと等）の発生を有効に回避できる。

これに対し、同一アカウントに対するポイント加算処理やポイント残高算出処理の場合には、複数のAPサーバにおける並列処理に供されるため、分散処理による効率化を図ることができる。

なお、担当AP定義テーブル54には、主担当APの他に副担当APも格納されているので、万一、主担当APに指定されたAPサーバがダウンしている場合には即座に副担当APサーバに対して権限を委譲することができる。
副担当APサーバの用意だけでは不安な場合には、副々担当AP等、より下位のAPサーバを予め設定しておけばよい。
担当AP定義テーブル54は、全てのDBサーバ内に保持されているため、何れかのDBサーバが一時的にダウンしていても、APサーバは他のDBサーバから主担当APサーバ等を特定することが可能となる。

この排他制御を実効あらしめるためには、業務処理部用のアプリケーションプログラムにおいて、排他制御を要する処理（ポイント適用処理）と不要な処理（ポイント加算処理、ポイント残高確認処理等）について予め定義しておくことが必要となる。
また、担当AP定義テーブル54に、アカウント毎（またはアカウントのグループ毎）に主担当APと副担当APの特定情報（URL等）を定義しておく。

もっとも、この発明は上記のように排他制御を要する業務処理の種類（ポイント適用処理）をアプリケーションプログラム中で定義すると共に、その処理対象（アカウント）とAPサーバとの対応関係を担当AP定義テーブル54側で定義する方式に限定されるものではない。

例えば、以下のようにアプリケーションプログラム中で複数種類の業務処理について要排他制御の定義をしておき、担当AP定義テーブルにおいて業務処理の種類毎に主担当APサーバと副担当APサーバを設定することもできる。
［アプリケーションプログラム側の設定］
要排他制御処理−＞Ａ処理、Ｂ処理、Ｃ処理
［担当AP定義テーブル側の設定］
Ａ処理−＞主担当AP：サーバa1、副担当AP：サーバa2
Ｂ処理−＞主担当AP：サーバb1、副担当AP：サーバb2
Ｃ処理−＞主担当AP：サーバc1、副担当AP：サーバc2

上記においてはポイント管理業務について例示したが、他の業務処理についても同様の排他制御を適用することができる。
例えば、在庫管理システムに適用する場合には、図１１に示すように、入荷テーブル60と、入荷取消テーブル61と、出荷テーブル62と、出荷取消テーブル63と、担当AP定義テーブル64を各DBサーバ内に設けておく。

入荷テーブル60には、入荷ID、商品コード、個数、タイムスタンプ等のデータ項目が設定されている。
また、入荷取消テーブル61には、取消対象、タイムスタンプ等のデータ項目が設定されている。
出荷テーブル62には、出荷ID、商品コード、個数、タイムスタンプ等のデータ項目が設定されている。
また、出荷取消テーブル63には、取消対象、タイムスタンプ等のデータ項目が設定されている。
担当AP定義テーブル64には、担当AP定義ID、商品コード、主担当AP、副担当AP等のデータ項目が設定されている。
上記の入荷ID、出荷IDには、人工キーによるユニークな識別コードが格納される。

ここで、クライアント端末28から商品の入荷リクエストを受けた場合、単純に入荷テーブル60に入荷データを追加すればよく、排他制御不要のため何れのAPサーバにも処理権限が認められる。
また、クライアント端末28から在庫数の照会リクエストを受けた場合にも、「未取消入荷数−未取消出荷数」によって算出できるため、APサーバ間の排他制御は不要である。

これに対し、クライアント端末28から商品の注文（出荷）リクエストが送信された場合には、在庫数以上の注文を受けることはできないため、APサーバ間での排他制御が必要となる。
具体的には、商品の注文リクエストが発生した段階で、当該商品（商品コード）の出荷処理を担当するAPサーバに対して処理権限が委譲される。

これを受けた主担当APサーバは、FIFOのキューに注文リクエストを一旦格納し、早いもの順に処理を実行する。
すなわち、主担当APサーバの業務処理部30は、注文リクエストに含まれる商品コードに係る商品の在庫を算出した上で、注文リクエストに含まれる個数が在庫の範囲内であれば対応の出荷データを生成し、全DBサーバに対して出荷テーブル62への追加登録を依頼する。その後、委託先のAPサーバから委託元のAPサーバに処理結果が通知される。
また、当該商品の在庫が注文数を下回っている場合、委託先のAPサーバは出荷データを生成することなく、在庫不足の結果を委託元のAPサーバに通知する。

このケースでも、排他制御を実効あらしめるためには、業務処理部30用のアプリケーションプログラムにおいて、排他制御を要する処理（注文受付処理）と不要な処理（入荷受付処理、在庫確認処理）について予め定義しておくことが必要となる。
また、ダウンロード形式で販売されるソフトウェアや電子書籍のように、販売対象によっては在庫数を気にする必要がないものもある。
このような場合には、同じ注文受付処理であっても対象商品毎（商品コード毎）に排他制御の要否を定義しておくことが求められる。

このシステム10における各DBサーバは、DB連絡部38から追加すべきデータを受け取って自身のメモリに格納した時点で、DB連絡部38に対して受取完了通知を送信し、その後、ハードディスクやSSD等の外部記憶装置内に設けられたテーブルに対応のレコードを格納する。

このDBサーバから送信された受取完了通知は、各DB連絡部38を経由してデータ制御部34に集められる。
データ制御部34は、全てのDB連絡部38から受取完了通知が返ってきた時点で、業務処理部30に対して登録完了通知を出力する。

業務処理部30は、この登録信完了通知をデータ制御部34から受け取った時点で、上記データを読み込みの対象と認識する。
逆に言えば、登録完了通知が返ってくるまでの間、業務処理部30は当該データを読み込みの対象外とすることで、各DBサーバにおける登録のタイミングがずれて不正なデータが読み込まれてしまう危険性を回避している。

ただし、何れかのDBサーバから一定時間を経過しても受取完了通知が返って来ない場合、データ制御部34は通信障害あるいはマシントラブルが発生したものと認定し、当該DBサーバをオフラインモードに移行させる。
具体的には、当該DBサーバを一時的にシステム10から切り離し、残りのDBサーバのみに基づく運用形態に移行する。
すなわち、切り離されたDBサーバ以外の全DBサーバから受取完了通知が届いていた場合、データ制御部34から業務処理部30に対して登録完了通知が出力され、登録データが読み取りの対象となる。

この間、切り離されたDBサーバについて点検がなされ、必要な復旧対策が施される。例えば、通信機器の故障が原因で受取完了通知が届いていなかったと判明した場合、新しい通信機器に交換した上で、当該DBサーバをライトモード（データの書込のみが許容され、データの参照が禁止される状態）に設定し、同一データセンター内に設置された他のDBサーバから差分データをコピーする。

そして、格納データが最新の状態に追い着いた時点で、当該DBサーバはリード／ライトモード（データの書込及び参照が許容される状態）に設定され、システム10に再接続される。
以後、データ制御部34は、当該DBサーバを担当しているDB連絡部38を介して、データの送受信を再開する。

このシステム10の場合、上記の通り、各業務データは追加のみが許容され、削除や更新が認められないルールが適用されているため、データの復旧が極めて容易となる。
すなわち、データの削除や更新が許容されることを前提とした場合、データを復旧させるためにはDBサーバが保持している更新履歴情報に基づき、一定の時点からデータの追加や削除、更新を順番に再現する必要があり、これに長い時間と大きな負荷を要することになる。また、更新ログを確実に保存する仕組みをDBサーバ側に設ける必要がある。

これに対し、このシステム10のようにデータの追加のみが許容され、削除と更新が禁止される前提の場合、他の正常なDBサーバに登録されたデータと障害が発生したDBサーバに登録されたデータを比較し、単純に足りないデータをコピーするだけで済み、データの順序（先後関係）を考慮する必要がなくなる。

また、このシステム10にあっては、上記のようにDB連絡部38から送信されたデータがDBサーバのメモリに格納された時点で、DBサーバから受取完了通知がAPサーバに発行されるため、極めて短時間の中に業務処理部30は当該データを読み込みの対象とすることができる。

これまでの常識では、メモリは揮発性の記憶手段であり、電源供給が停止された時点でデータが喪失してしまうため、不揮発性の記憶手段（ハードディスク等）にデータが格納された時点で完了通知が返されるべきとなる。
これに対し、このシステム10の場合には、あるDBサーバでデータの欠損が発生しても、単純に隣接するDBサーバから不足データをコピーするだけで追い着くことができるため、データがハードディスク等に格納されるまで待機する必要がない。

また、このようにデータの復旧が容易であるため、複数のDBサーバに同一データを格納するに際し、従来のように２相コミットという面倒な手順を踏むことが求められず、各DBサーバに対して単純に登録を依頼し、それぞれから受取完了通知が返ってきた時点でリード可能とすることが可能となる（いわゆるオートコミットの実現）。
この結果、APサーバとDBサーバ間の電文のやり取りが激減し、全体的な処理速度を向上させることができる。

上記の各種業務データ（ポイント加算データ、加算取消データ、ポイント適用データ、適用取消データ等）には、上記のように業務処理部30によってミリ秒精度のタイムスタンプが刻印されているため、人工キーの値がMAXに達し、発行済のIDと重複するIDの再発行（リサイクル）がなされた場合でも、業務処理部30はタイムスタンプを比較することで新旧データの判定が可能となる。

上記においては、複数のデータセンター内に複数のAPサーバとDBサーバを配置させた例を示したが、この発明はこれに限定されるものではない。
すなわち、一つのデータセンター内に複数のAPサーバと複数のDBサーバを設置し、各APサーバと全DBサーバ間をネットワークで接続した環境において、排他制御を要しない業務処理については各APサーバが独自に並列処理すると共に、排他制御を要する業務処理については予め設定されたAPサーバに処理権限を集約させる場合にも有効に適用できる。

この発明に係るデータ処理システムの全体構成図である。 各DBサーバに格納されるテーブルの一例を示す図である。 第１のAPサーバ及び第２のAPサーバの内部構成を示すブロック図である。 人工キーの発行手順を示すフローチャートである。 人工キー管理テーブル等の構造を示す図である。 このシステムをポイント管理業務に応用した場合の処理手順を示す模式図である。 ポイント加算処理の手順を示すフローチャートである。 残高算出処理の手順を示すフローチャートである。 APサーバ間の排他制御に係る処理手順を示すフローチャートであ ポイント適用処理の手順を示すフローチャートである。る。 各DBサーバに格納されるテーブルの他の例を示す図である。

10 データ処理システム
12 第１のデータセンター
14 第１のAPサーバ
16 第１のDBサーバ
18 第２のDBサーバ
20 第２のデータセンター
22 第２のAPサーバ
24 第３のDBサーバ
26 第４のDBサーバ
27 通信ネットワーク
28 クライアント端末
29 通信回線
30 業務処理部
32 人工キー管理部
34 データ制御部
38 DB連絡部
50 ポイント加算テーブル
51 加算取消テーブル
52 ポイント適用テーブル
53 適用取消テーブル
54 担当AP定義テーブル
56 人工キー管理テーブル
57 人工キーの下一桁管理テーブル
58 APサーバ管理テーブル
59 データセンター管理テーブル
60 入荷テーブル
61 入荷取消テーブル
62 出荷テーブル
63 出荷取消テーブル
64 担当AP定義テーブル

Claims (4)

1. 複数のAPサーバと、複数のDBサーバを備えたデータ処理システムであって、
   上記の各DBサーバは、相互に共通する業務データを格納するテーブルをそれぞれ備える共に、各テーブルにはレコードの参照及び追加のみが許容され、削除及び更新が禁止される制約が設けられており、
   上記の各APサーバは、それぞれ上記の各DBサーバと接続されており、クライアント端末から送信されたリクエストに対して共通の業務処理を実行する機能と、処理の結果生じた業務データを上記の各DBサーバに送信し、対応のテーブルへの追加登録を依頼する機能を備え、
   上記の各業務データには、これを生成したAPサーバを特定するための識別符号を含むユニークなIDが割り振られており、
   さらに、上記の各DBサーバには、排他制御が求められる特定の業務処理を担当するAPサーバを業務処理毎に定義しておく担当AP定義テーブルが格納されており、
   上記の各APサーバは、上記クライアント端末から送信された業務処理のリクエストが、排他制御を要するものでない場合には自ら実行するのに対し、排他制御を要するものである場合には上記担当AP定義テーブルを参照し、当該業務処理を担当すべきAPサーバを特定した後、当該担当APサーバに該当の処理を委譲し、
   これを受けた担当APサーバは、委譲された業務処理を一旦キューに格納した後、キュー内の各業務処理をFIFOのルールに従って順に実行することを特徴とするデータ処理システム。
2. 上記担当AP定義テーブルには、主担当APサーバの他に、当該主担当APサーバが機能しない場合に処理を担当すべき副担当APサーバが業務処理毎に定義されていることを特徴とする請求項１に記載のデータ処理システム。
3. 上記の業務データには、それぞれ業務処理実行時のタイムスタンプが刻印されており、
   上記APサーバは、既存の業務データを更新する必要がある場合に、当該業務データと異なる昇順のID、修正後のデータ及び修正時のタイムスタンプを備えた業務データを新たに生成すると共に、
   この更新用の業務データを各DBサーバに設けられた該当のテーブルに追加登録させることにより、既存の業務データを実質的に更新することを特徴とする請求項１または２に記載のデータ管理システム。
4. 上記APサーバは、既存の業務データを削除する必要がある場合に、取消対象として当該業務データのIDを格納するデータ項目を備えたデータ取消用の業務データを生成すると共に、
   このデータ取消用の業務データを各DBサーバに設けられた取消専用のテーブルに追加登録させることにより、既存の業務データを実質的に削除することを特徴とする請求項１〜３の何れかに記載のデータ処理システム。

Images