JP2019516171A

JP2019516171A - サービス処理方法、デバイス、及びシステム

Info

Publication number: JP2019516171A
Application number: JP2018550376A
Authority: JP
Inventors: ドゥー，ジュアン
Original assignee: アリババグループホウルディングリミテッド
Priority date: 2016-03-24
Filing date: 2017-03-13
Publication date: 2019-06-13
Anticipated expiration: 2037-03-13
Also published as: CN107229455B; TW201734857A; EP3435604A4; CN107229455A; EP3435604B1; WO2017162056A1; EP3435604A1; US20190028555A1; US11445030B2; JP6921107B2; TWI777935B

Abstract

本願は、サービス処理方法、デバイス及びシステムを開示する。前記サービス処理方法は：サービス処理参照情報を含むサービス処理要求を、サービス要求側により生成し、前記サービス処理要求をサービス処理側へ送信するステップであって、同一のサービスイベントについて繰り返し送信されるサービス処理要求は同一の前記サービス処理参照情報を含む、前記送信するステップと；前記サービス処理要求の受信後、前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を、前記サービス処理側により特定し、前記特定した格納場所に冪等性チェックを実行し、前記冪等性チェックの結果に基づいて前記現行サービスに処理を実行するステップと；を含む。本願の技術的解決策では、同一のサービスイベントについて種々の格納場所で複数の冪等性チェックを実施しないため、繰り返しサービス処理を効果的に減らすことができる。

Description

本願は、２０１６年３月２４日に中国特許庁に出願された「サービス処理方法、デバイス、及びシステム」と題された中国特許出願第２０１６１０１７３７４７．６号の優先権を主張し、上記中国特許出願は参照によってその全体が本明細書に組み込まれる。

本願は、コンピュータアプリケーション技術の分野に関し、特に、サービス処理方法、デバイス、及びシステムに関する。

コンピュータシステムにおいて、複数回実行される冪等演算が及ぼす影響は、１回実行される冪等演算が及ぼす影響と同一である。実使用において、冪等演算は、通常、演算の繰り返しがシステムに及ぼす影響を回避するためになされる。金融システムを一例にとる。ここで確保しなければならないことは、送金要求は１回の送金操作に対応すること、そしてネットワーク遅延により生じた複数の送金操作は許可されないことである。そのため、外部の会計インターフェースの冪等性は金融システム内で実施されねばならない。

冪等性を達成するための一般的な方法として、サービスシステム側のデータベース内の各サービス要求に一意の制約を課す方法がある。例えば、データベース内に冪等性テーブルを作成する。サービス要求を処理する前にその都度、サービス要求の一意の識別情報（「サービス要求取引番号」、「サービス要求取引番号」＋「サービスタイプ」、又は、「サービス要求取引番号」＋「サービス要求元」等）を冪等性テーブルに挿入する必要がある。この識別情報の挿入に成功した場合、サービスシステムはそのサービス要求を初めて処理したことを意味する。識別情報の挿入に失敗した場合、冪等性テーブルにそのサービス情報が既に存在している、つまり、サービスシステムが過去にそのサービス要求を処理していることを意味する。この場合、その要求を繰り返し要求として直ちに特定し、要求の処理を中止する。

一般に、先に述べた解決策を用いてサービスシステム内の外部インターフェースの冪等性をより確実に達成できる。しかし、分散格納の要件とディザスタリカバリの要件とのために、データは大抵、パーティション又はシャーディングを介して格納される。パーティションのアプリケーションシナリオ又はシャーディングのアプリケーションシナリオでは、要求側が同一のサービスについて複数の要求をサービスシステムに対して開始するが、何らかの理由（例えば、ディザスタリカバリ切り替え）で、サービスシステムによって複数の要求が複数の異なるデータテーブルにルーティングされる。種々のデータテーブルの冪等性テーブルは異なるため、冪等性の不具合が生じ、その結果、サービス処理が繰り返されてしまう可能性がある。

先の技術的問題について、本願は、データベースシャーディングのアプリケーションシナリオ又はマルチデータベースのアプリケーションシナリオにおける冪等性の不具合の問題を軽減するサービス処理方法、デバイス、及びシステムを提供する。この技術的解決策は以下のとおりである。

本願の第１の態様により、サービス処理方法が提供され、前記方法は：サービス処理参照情報を含むサービス処理要求を、サービス要求側により生成し、前記サービス処理要求をサービス処理側へ送信するステップであって、前記サービス処理参照情報は、データベース内での現行サービスの関連データの格納場所を特定するために前記サービス処理側によって用いられ、同一のサービスイベントについて繰り返し送信されるサービス処理要求は同一の前記サービス処理参照情報を含む、前記送信するステップと；前記サービス処理要求の受信後、前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を、前記サービス処理側により特定し、前記特定した格納場所に冪等性チェックを実行し、前記冪等性チェックの結果に基づいて前記現行サービスに処理を実行するステップと；を含む。

本願の第２の態様により、サービス処理方法が提供され、前記方法はサービス要求側に適用され；サービス処理参照情報を含むサービス処理要求を生成するステップと；前記サービス処理要求をサービス処理側へ送信するステップであって、前記サービス処理側が、前記サービス処理要求の受信後に、前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定し、前記特定した格納場所に冪等性チェックを実行し、前記冪等性チェックの結果に基づいて現行サービスの処理を実行する、前記送信するステップと；を含む。

前記サービス処理参照情報は、データベース内での前記現行サービスの関連データの格納場所を特定するために、前記サービス処理側によって用いられ、前記同一のサービスイベントについて繰り返し送信されるサービス処理要求は、同一のサービス処理参照情報を含む。

本願の第３の態様により、サービス処理方法が提供され、前記方法はサービス処理側に適用され：サービス要求側により送信されたサービス処理要求を受信するステップであって、前記サービス処理要求はサービス処理参照情報を含む、前記受信するステップと；前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定し、前記特定した格納場所に冪等性チェックを実行し、前記冪等性チェックの結果に基づいて現行サービスに処理を実行するステップと；を含む。

前記サービス処理参照情報は、データベース内での前記現行サービスの関連データの格納場所を特定するために、前記サービス処理側によって用いられ、前記サービス要求側により前記同一のサービスイベントについて繰り返し送信されるサービス処理要求は、前記同一のサービス処理参照情報を含む。

本願の第４の態様により、サービス処理デバイスが提供され、前記デバイスはサービス要求側に適用され：サービス処理参照情報を含むサービス処理要求を生成するように構成された要求生成モジュールと；前記サービス処理要求をサービス処理側へ送信するように構成された要求送信モジュールであって、前記サービス処理側が、前記サービス処理要求の受信後に、前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定し、前記特定した格納場所に冪等性チェックを実行し、前記冪等性チェックの結果に基づき現行サービスに処理を実行する、前記要求送信モジュールと；を含む。

前記サービス処理参照情報は、データベース内での前記現行サービスの関連データの格納場所を特定するために、前記サービス処理側により用いられ、前記同一のサービスイベントについて繰り返し送信されたサービス処理要求は前記同一のサービス処理参照情報を含む。

本願の第５の態様により、サービス処理デバイスが提供され、前記デバイスはサービス処理側に適用され：サービス要求側により送信されるサービス処理要求を受信するように構成された要求受信モジュールであって、前記サービス処理要求はサービス処理参照情報を含む、前記要求受信モジュールと；前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定し、前記特定した格納場所に冪等性チェックを実行し、前記冪等性チェックの結果に基づいて現行サービスに処理を実行するように構成されたサービス処理モジュールと；を含む。

前記サービス処理参照情報は、データベース内での前記現行サービスの関連データの格納場所を特定するために、前記サービス処理側により用いられ、前記同一のサービスイベントについて前記サービス要求側により繰り返し送信されるサービス処理要求は前記同一のサービス処理参照情報を含む。

本願の第６の態様により、サービス処理システムが提供され、前記システムは：サービス要求側デバイスとサービス処理側デバイスとを含む。

前記サービス要求側デバイスは：サービス処理参照情報を含むサービス処理要求を生成するように構成された要求生成モジュールと；前記サービス処理要求を、サービス処理側へ送信するように構成された要求送信モジュールと；を含む。

前記サービス処理参照情報は、データベース内での現行サービスの関連データの格納場所を特定するために、前記サービス処理側によって用いられ、前記同一のサービスイベントについて繰り返し送信されたサービス処理要求は前記同一のサービス処理参照情報を含む。

前記サービス処理側デバイスは：前記サービス要求側により送信される前記サービス処理要求を受信するように構成された要求受信モジュールと；前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定し、前記特定した格納場所に冪等性チェックを実行し、前記冪等性チェックの結果に基づいて前記現行サービスに処理を実行するように構成されたサービス処理モジュールと；を含む。

本願で提供される技術的解決策では、サービス要求側によりサービス処理側へ送信されるサービス処理要求に、サービス処理参照情報が付加される。同一のサービスイベントについて繰り返し送信されるサービス処理要求は同一のサービス処理参照情報を含むので、同一のサービスイベントについて種々の格納場所で複数の冪等性チェックはなされず、よって、サービス処理の繰り返しは効果的に減る。

前述の一般的な説明及び以下の詳細な説明は、単なる説明のための例示であり、本願を限定するものではないことを理解されたい。

本願の実施又は既存の技術における技術的解決策をより明確に説明するために、以下では、実施又は既存の技術を説明するために必要な添付図面を簡単に紹介する。明らかに、以下の説明における添付の図面は、本願に記録されたいくつかの実施を示すに過ぎず、当業者は創造的な努力なしにこれらの添付図面から他の図面を引き出すことができる。

図１は、本願による、サービス処理方法を示す概略フローチャートである。

図２は、本願による、データベース展開ソリューションを示す概略図である。

図３は、本願による、サービス要求側デバイスを示す概略図である。

図４は、本願による、サービス処理側デバイスを示す概略図である。

図５は、本願による、サービス処理システムを示す概略図である。

ビッグデータのアプリケーションシナリオでは、データは、通常、分散データ格納を実施するためにシャーディングを介して格納され、シャーディングは複数のディメンションに基づいて実施できる。一般的な分割ディメンションは「時刻」ディメンションである。例えば、１年の１２か月に基づく分割により１２個のパーティションテーブルが得られ、この１２個のパーティションテーブルは、異なる時刻に開始されたサービス要求に対応するサービスデータを格納するために用いられる。

加えて、通常は、システムディザスタリカバリを実施するために、データベース上で冗長バックアップが実行される。つまり、マスタデータベース内のデータがフェイルオーバ（ＦＯ）データベースに完全にコピーされる。通常、マスタデータベースとＦＯデータベースとは別々の領域に展開されている。正常状態におけるサービス要求はマスタデータベースにルーティングされ（正常モード）、ディザスタリカバリ状態におけるサービス要求はＦＯデータベースにルーティングされる（フェイルオーバモード）。

シャーディングとパーティションは一般的なデータベースアプリケーション解決策である。しかし、シャーディングアプリケーションシナリオ及びパーティションアプリケーションシナリオでは既存の冪等性解決法が失敗する可能性があり、以下にこれらのシナリオの例を示す。

ユーザＡがユーザＢへ＄１００を送金したいと仮定する。サービス処理側の送金プラットフォームが、アプリケーションプラットフォームを用いてユーザＡより送信された送金要求を１１月３０日の２３時５９分に受信し、このサービスをパーティションテーブル１１（１１月に対応するパーティションテーブル）にルーティングする。サービスの識別情報をパーティションテーブル１１の冪等性テーブルへ挿入できるので、このサービスは「＄１００はアカウントＡからアカウントＢへ送金された」として正常に処理されることができる。しかし、ネットワークの問題により、サービス要求側のアプリケーションプラットフォームが、サービスの処理が成功した旨を示す応答を受信しないと、それにより、アプリケーションプラットフォームは、処理タイムアウトが生じた、と特定して、送金プラットフォームへ２回目の送金要求を送信してしまう。送金プラットフォームが１２月１日の００時０１分に２回目の送金要求を受信し、このサービスをパーティションテーブル１２（１２月に対応するパーティションテーブル）にルーティングする。パーティションテーブル１２の冪等性テーブルは送金サービスの識別情報を含んでいないため、この識別情報の挿入も成功し、サービスは正常に処理されてしまう可能性がある。これにより、ユーザＡは、再度、ユーザＢへ＄１００を送金してしまう。

ユーザＡがユーザＢへ＄１００を送金したいと仮定する。アプリケーションプラットフォームを用いてユーザＡより初めて送信された送金要求をサービス処理側の送金プラットフォームが受信した場合、システムは正常な実行状態にあるため、サービスはマスタデータベース内のデータテーブルにルーティングされる。このケースでは、サービスの識別情報をマスタデータベース内の冪等性テーブルに挿入することができるので、サービスは「＄１００がアカウントＡからアカウントＢへ送金された」として正常に処理される。ネットワークの問題に起因して、サービス要求側のアプリケーションプラットフォームが、サービスの処理に成功した旨を示す応答を受信せず、それによりアプリケーションプラットフォームは、処理タイムアウトが生じた、と特定して、送金プラットフォームへ２回目の送金要求を送信してしまう。送金プラットフォームが２回目の送金要求を受信するとき、マスタデータベースは不具合状態である。そのため、サービスはＦＯデータベース内のデータテーブルへルーティングされ、ＦＯデータベース内の冪等性テーブルは送金サービスの識別情報を含まない。上と同様に、識別情報の挿入に成功し、サービスは正常に処理されてしまう。これにより、ユーザＡは再びユーザＢへ＄１００を送金してしまう。

データシャーディングのアプリケーションシナリオ又はマルチデータベース格納のアプリケーションシナリオでは、種々の格納場所（例えば、マスタデータベース／ＦＯデータベース、パーティションデータベース、パーティションテーブル）が種々の冪等性テーブルを別々に維持することが分かる。そのため、同一のサービスイベントについて繰り返し送信された要求が種々の格納場所にルーティングされた場合、冪等性チェックは失敗である。

本願は、先の問題を軽減するサービス処理方法を提供する。図１に示すように、本方法は以下のステップを含むことができる。

Ｓ１０１：サービス要求側が、サービス処理参照情報を含むサービス処理要求を生成する。

既存の解決策と比較すると、本願の解決策では、サービス処理参照情報のような拡張パラメータがサービス処理要求に付加される。この情報の機能は、シャーディングのアプリケーションシナリオ又はパーティションのアプリケーションシナリオにおいて、サービス処理側が、この情報に基づいて現行サービスのデータベース格納場所を特定できるという機能である。つまり、現行サービスの処理中に関連のデータ処理操作を実行する必要があるデータベース（マスタデータベース／ＦＯデータベース、パーティションデータベース等を含む）及び／又はデータテーブルを特定し、特定した格納場所においてサービス処理側が後続のデータ処理を実行できるようにする。

本願のこの解決策では、サービス要求側により提供されたサービス処理参照情報をサービス処理側で識別でき、現行サービスによって用いられるデータベース又はデータテーブルをこの情報に基づいて特定できる場合、サービス要求側がサービス処理側の実際のシャーディング論理又は実際のパーティション論理を知得する必要はない。

例えば、データベース内で「時刻」ディメンションに基づいてパーティションを実行する場合、サービス要求側は、サービス処理要求を送信する前に現在時刻情報を取得し、この時刻情報をサービス処理要求に書き込むだけでよい。更に、サービス処理側は、後続の処理を実行するために、対応する時刻ディメンションデータパーティションテーブルを時刻情報に基づいて選択できる。

データベース冗長バックアップシナリオでは、サービス要求側は、サービス処理要求を送信する前に、サービス処理側によって現在用いられているデータベース実行モード情報について知得し、データベース実行モード情報をサービス処理要求に書き込む。ここで述べる実行モードは正常モードとフェイルオーバモードとを含む。更に、サービス処理側は、後続の処理を実行するために、マスタデータベース又はＦＯデータベースをデータベース実行モード情報に基づいて選択できる。実使用では、サービス要求側は、サービス要求側又はミドルウェアによってアクティブにプッシュされたデータベース実行モード情報を申し込みにより取得できる、又は、サービス処理要求を送信しなければならない場合に必要に応じてデータベース実行モード情報を取得できる。本願において実施は限定されない。

先に用いた２タイプの「サービス処理参照情報」は単なる例であり、本願の解決策の限定として解釈されることを意図されていない点に留意されたい。例えば、サービス要求側がサービス処理側のシャーディング論理又はパーティション論理について知得している場合、サービス要求側は、現行サービスが用いているデータベース又はデータテーブルの識別子をサービス要求に直接付加できる。実使用の要件に基づき、１つのサーバ処理要求が複数タイプのサービス処理参照情報を含んでよいことは更に言うまでもない。例えば、時刻情報とデータベース実行モード情報との両方を含めることで、時刻ディメンションに基づいてパーティションシナリオアプリケーションとフェイルオーバシナリオアプリケーションとの要件を満たすことができる。

Ｓ１０２：サービス要求側が、サービス処理要求をサービス処理側へ送信する。

本願のこの解決策において、サービス処理参照情報の別の機能は、シャーディング／パーティションのアプリケーションシナリオにてサービス処理側のインターフェースの冪等性を確保することである。同一のサービスイベントについてサービス要求側から繰り返し送信されるサービス処理要求は同一のサービス処理参照情報を含んでいる必要があるので、同一のサービスイベントについて複数の要求を処理するときに、サービス処理側が同一の格納場所に冪等性チェックを実行して、冪等性チェックの失敗を減らすことができる。

実使用では、サービス処理要求を初めて送信するときに、サービス要求側はサービス処理参照情報（例えば、現行の時刻情報や現行のデータベース実行モード情報）を取得して、この情報をサービス処理要求に書き込み、書き込みされたこのサービス処理情報を、サービスイベントを用いて識別子として格納できる。その後、同一のサービスイベントについての処理要求を再び送信する必要がある場合、先に格納したサービス処理参照情報が直接読み取られ、新たなサービス処理要求に書き込まれる。当然ながら、本願のこの解決策では、同一のサービスイベントについて繰り返し送信されるサービス処理要求に同一のサービス処理参照情報を含める必要がある。そのため、先に述べた方法は、本願のこの解決策の限定として解釈されることを意図していない。例えば、サービス要求側は初めて生成されたサービス処理要求の全て又は一部を直接格納できる（少なくとも、初めて用いられたサービス処理参照情報を含む）。サービス処理要求を再送信する必要がある場合、先に格納された内容を読み取ることにより再送信を実施できるので、複数の要求に含まれたサービス処理参照情報が同一となることが確保される。

Ｓ１０３：サービス処理側が、サービス処理要求の受信後に、要求に含まれているサービス処理参照情報に基づいて、対応する格納場所を特定する。

本願の解決策において、サービス処理側は、現行サービスの処理中に関連のデータ処理操作を実行する必要があるデータベース（マスタデータベース／ＦＯデータベース、パーティションデータベース等）及び／又はデータテーブルを、サービス要求側より提供されたサービス処理参照情報に基づいて特定しなければならない。

例えば、サービス処理要求が時刻情報を含む場合、サービス処理側は、この時刻情報に基づいて、対応する時刻ディメンションデータパーティションテーブルを特定できる。サービス処理要求がデータベース実行モード情報を含む場合、サービス処理側は、この情報に基づいて、マスタデータベース又はＦＯデータベースが用いられたかどうかを特定できる。

実使用では、サービス処理参照情報は、格納場所を特定するための情報の一部のみであってよいことが分かる。例えば、「ユーザ番号」と「時刻」に基づく２ディメンション式のパーティション解決策において、データパーティションテーブルを、「現行要求を開始したユーザの番号（この情報はデフォルトにてサービス要求に含まれている情報に属する）」と「時刻情報」とに基づいて特定する必要がある。マスタデータベース又はＦＯデータベースの特定後に、パーティション解決策に基づき、データパーティションテーブルを更に特定する必要がある。当然ながら、「その他の情報」は既存の解決策を用いて通常取得できる情報であってよく、又、「その他の情報」に基づいて格納場所を特定するためにも既存の技術を用いることができる。これにより本願の解決策の実施が影響を受けることはない。

Ｓ１０４：特定された格納場所に冪等性チェックを実行し、冪等性チェックの結果に基づいて現行サービスに処理を実行する。

データベース内でのサービス関連データの格納場所を特定するときに、既存の技術を用いて、本願の解決法の冪等性チェックを実行できる。つまり、サービス要求を処理する前にその都度、サービス要求の一意の識別情報（例えば、「サービス要求取引番号」、「サービス要求取引番号＋サービスタイプ」、又は「サービス要求取引番号＋サービス要求元」）を現在の格納場所に対応する冪等性テーブルへ挿入する。識別情報の挿入に成功した場合、これはサービスシステムがサービス要求を初めて処理することを意味するので、正常のサービス処理手順を継続する。識別情報の挿入に失敗した場合、そのサービス情報が冪等性テーブル内に既に存在する、つまり、サービスシステムがこれまでにそのサービス要求を処理していることを示す。この場合、その要求は繰り返し要求である、と直接特定でき、要求の処理を停止する。当然ながら、本願は冪等性チェック解決策を限定する必要はない。

１つのアプリケーションシナリオを参照しながら本願の解決策を以下説明する。

図２は、金融システムの送金プラットフォーム側で用いられるサービスデータベースの展開を示し、ここで、データパーティションテーブルは２つのディメンションに基づく。

「ユーザ番号」ディメンションでは、１００個のユーザクォンタイルを得るために、次の２桁のユーザ番号、即ち、００〜９９を採用している。

「時刻」ディメンションでは、１年の１２か月に基づいて１２個のクォンタイルを得ている。

先の２つのディメンションに基づき、１２×１００で合計１２００個のパーティションテーブルが形成される。各パーティションテーブルの命名規則は「ユーザ番号クォンタイル＿月クォンタイル」であり、各パーティションテーブルは１つの冪等性テーブルに対応する。

加えて、システムディザスタリカバリを実施するために、マスタデータベース内のデータをＦＯデータベースに完全にバックアップして、ＦＯデータベースがマスタデータベースと同一構造を持つようにする。正常状態でのサービス要求はマスタデータベースにルーティングされ（正常モード）、ディザスタリカバリ状態でのサービス要求はＦＯデータベースにルーティングされる（フェイルオーバモード）。

ユーザＡ（ユーザ番号１００００２）がユーザＢへ＄１００を送金したい場合、ユーザＡはアプリケーションプラットフォームを用いて送金プラットフォームへの送金要求を開始する。アプリケーションプラットフォームが２０１５年１１月３０日の２３時５９分に初めて送金要求を開始し、データベースがこのケースにおいては正常実行モードにある場合に、アプリケーションプラットフォームが「２０１５‐１１‐３０２３：５９」と「正常モード」とを送金要求に書き込む。

送金要求の受信後、送金プラットフォームは、先ず、この要求に含まれている情報に基づいて、格納場所はマスタデータベース０２＿１１テーブルである、と特定し、次に、送金サービスの取引番号をマスタデータベース０２＿１１テーブルの冪等性テーブルへ挿入する。挿入の成功により、サービスを、「アカウントＡからアカウントＢへ＄１００を送信した」として、正常に処理できる。

シナリオ１：ネットワークの問題に起因して、アプリケーションプラットフォームがサービスの処理が成功である旨を示す応答を受信しない場合、アプリケーションプラットフォームは、処理タイムアウトが発生した、と特定し、２回目の送金要求を送金プラットフォームに送信する。２回目の送金要求は２０１５年１２月１日の００時０１分に開始される。しかし、２回目の送金要求に含まれている格納場所情報は「２０１５‐１１‐３０２３：５９」、「正常モード」のままである。

２回目の送金要求の受信後、送金プラットフォームが、この要求に含まれている情報に基づいて、格納場所がマスタデータベース０２＿１１テーブルである、と特定し、次に、送金サービスの取引番号をマスタデータベース０２＿１１テーブルの冪等性テーブルへ挿入する。冪等性テーブルに同じ記録が既に存在するので、挿入は失敗し、現行の送金要求に対する処理は停止して繰り返し送金処理は減る。

シナリオ２：ネットワークの問題に起因して、アプリケーションプラットフォームがサービスの処理が成功である旨の応答を受信しない場合、アプリケーションプラットフォームは、処理タイムアウトが発生した、と特定し、２回目の送金要求を送金プラットフォームへ送信する。２回目の送金要求は２０１５年１２月１日の００時０１分に開始された。加えて、送金システム側のデータベースはフェイルオーバモードに切り替えられている。しかし、２回目の送金要求に含まれている情報は「２０１５‐１１‐３０２３：５９」、「正常モード」のままである。

２回目の送金要求の受信後、送金プラットフォームは、この要求に含まれている情報に基づいて、格納場所がマスタデータベース０２＿１１テーブルである、と特定し、次に、送金サービスの取引番号をマスタデータベース０２＿１１テーブルの冪等性テーブルに挿入する。マスタデータベースは不具合状態にあり、アクセスできないため、現行の送金要求を処理できない。その結果、繰り返し送金処理は同様に減る。

先の金融システムの適用事例は単なる実施例であり、本願の解決策のアプリケーションシナリオの限定にはならない。実際に、本願の解決策は、システムデータベースがデータシャーディング又はマルチデータベース格納に関与したアプリケーションシナリオにおけるシステムインターフェースの冪等性を達成するために適用でき、種々の格納場所（例えば、マスタデータベース／ＦＯデータベース、パーティションデータベース、パーティションテーブル）はそれぞれの冪等性テーブルを別々に維持する。本願のこの解決策では、同一のサービスイベントについてサービス要求側から繰り返し送信されるサービス処理要求は同一のサービス処理参照情報を含むため、同一のサービスイベントについて種々の格納場所で複数の冪等性チェックが実行されることはなく、したがって、繰り返しサービス処理は効果的に減る。

先の方法の実施に対応し、本願はサービス要求側に適用されるサービス処理デバイスを更に提供する。図３を参照すると、このデバイスは：サービス処理参照情報を含むサービス処理要求を生成するように構成された要求生成モジュール１１０と：サービス処理要求をサービス処理側へ送信することにより、サービス処理要求の受信後、サービス処理側が、この要求に含まれるサービス処理参照情報に基づいて、対応する格納場所を特定し、特定した格納場所に冪等性チェックを実行し、冪等性チェックの結果に基づき現行サービスに処理を実行できるように構成された要求送信モジュール１２０と；を含む。

サービス処理参照情報は、データベース内における現行サービスの関連データの格納場所を特定するためにサービス処理側によって用いられ、同一のサービスイベントについて繰り返し送信されるサービス処理要求は同一のサービス処理参照情報を含む。

本願の実施では、サービス処理参照情報は時刻情報であってよい。

要求生成モジュール１１０は、サービス処理要求が同一のサービスイベントについて初めて送信された場合に現在時刻情報を取得し、時刻情報をサービス処理要求に書き込むように構成されることができる。サービスイベントについて再送される各々の後続の要求は時刻情報を含む。

本願の別の実施では、サービス処理参照情報はデータベース実行モード情報であってよく、データベースモードは正常モードとフェイルオーバモードとを含むことができる。

要求生成モジュール１１０は、サービス処理要求が同一のサービスイベントについて初めて送信された場合に、サービス処理側により現在用いられているデータベース実行モード情報を取得し、このデータベース実行モード情報をサービス処理要求に書き込むように構成されることができる。サービスイベントについて再送される各々の後続の要求はデータベース実行モード情報を含む。

図４を参照すると、本願は、サービス処理側に適用されるサービス処理デバイスを更に提供し、このデバイスは、サービス要求側より送信されるサービス処理要求を受信するように構成された要求受信モジュール２１０であって、サービス処理要求はサービス処理参照情報を含む、要求受信モジュール２１０と；要求に含まれているサービス処理参照情報に基づいて対応する格納場所を特定し、特定した格納場所に冪等性チェックを実行し、冪等性チェックの結果に基づいて現行サービスに処理を実行するように構成されたサービス処理モジュール２２０と；を含むことができる。

サービス処理参照情報は、データベース内での現行サービスの関連データの格納場所を特定するために、サービス処理側により用いられ、サービス要求側から同一のサービスイベントについて繰り返し送信されるサービス処理要求は、同一のサービス処理参照情報を含む。

サービス処理モジュール２２０は、要求に含まれている時刻情報に基づいて、時刻情報に対応する時刻ディメンションデータパーティションテーブルを特定し、特定したデータパーティションテーブルに冪等性チェックを実行し、冪等性チェックの結果に基づき現行サービスに処理を実行するように構成されることができる。

サービス処理モジュール２２０は、要求に含まれているデータベース実行モード情報に基づいて、データベース実行モード情報に対応するデータベースを特定し、特定したデータベースに冪等性チェックを実行し、冪等性チェックの結果に基づいて現行サービスに処理を実行するように構成されることができる。

本願はサービス処理システムを更に提供する。図５に示すように、このシステムはサービス要求側デバイス１００とサービス処理側デバイス２００とを含むことができる。２つのデバイスの実施については先の実施を参照できるため、本願では説明を繰り返さない。

当業者であれば、必要なユニバーサルハードウェアプラットフォームに加えてソフトウェアを使用することによって本願を実施できることを明確に理解することができる、ということを実施の説明から知ることができる。このような理解に基づいて、本願における技術的解決策は本質的に、すなわち既存技術に寄与する部分は、ソフトウェア製品の形態で実施することができる。ソフトウェア製品は、ＲＯＭ／ＲＡＭ、磁気ディスク、光ディスクなどの記憶媒体に格納することができ、本願の実施又は実施のいくつかの部分で説明された方法を実行するために、コンピュータデバイス（パーソナルコンピュータ、サーバ、又はネットワークデバイス）に実行させるためのいくつかの命令を含む。

本明細書の実施は、漸進的な方法で記述される。実施における同一又は類似の部分については、互いに参照を行うことができる。各実施は、他の実施との違いに焦点を当てている。特に、デバイス又はシステムの実施は、方法の実施に類似しているので、簡単に説明されている。関連部分については、方法の実施における関連説明を参照することができる。記載されたデバイス又はシステムの実施は単なる例に過ぎない。別個の部分として記載されたモジュールは、物理的に分離していてもいなくてもよい。本願における解決策が実施される場合、各モジュールの機能は、１つ又は複数のソフトウェア及び／又はハードウェアで実施され得る。モジュールの一部又はすべては、実施の解決策を実装する実際の必要性に基づいて選択できる。当業者は、創造的な努力なしに、本願の実施を理解し、実装することができる。

前述の説明は、本願の特定の実施に過ぎない。当業者は、本願の原理から逸脱することなく、いくつかの改良又は研磨を行うことができることに留意することは有益である。改良及び研磨は、本願の保護範囲内に入るものとする。

Claims

サービス処理方法であって：
サービス処理参照情報を含むサービス処理要求を、サービス要求側により生成し、前記サービス処理要求をサービス処理側へ送信するステップであって、前記サービス処理参照情報は、データベース内での現行サービスの関連データの格納場所を特定するために前記サービス処理側によって用いられ、同一のサービスイベントについて繰り返し送信されるサービス処理要求は同一の前記サービス処理参照情報を含む、前記送信するステップと；
前記サービス処理要求の受信後、前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を、前記サービス処理側により特定し、前記特定した格納場所に冪等性チェックを実行し、前記冪等性チェックの結果に基づいて前記現行サービスに処理を実行するステップと；を備える、
サービス処理方法。
前記サービス処理参照情報は時刻情報であり；
サービス処理参照情報を含むサービス処理要求を生成する前記ステップは：
同一のサービスイベントについて前記サービス処理要求が初めて送信された場合に、現在時刻情報を取得し、前記時刻情報を前記サービス処理要求に書き込むステップであって、前記サービスイベントについて再送される各々の後続の要求は前記時刻情報を含む、前記書き込むステップを備え；
前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定する前記ステップは：
前記要求に含まれる前記時刻情報に基づいて、前記時刻情報に対応する時刻ディメンションデータパーティションテーブルを特定するステップを備える；
請求項１に記載の方法。
前記サービス処理参照情報はデータベース実行モード情報であり、データベースモードは正常モードとフェイルオーバモードとを含み；
サービス処理参照情報を含むサービス処理要求を生成する前記ステップは：
前記同一のサービスイベントについて前記サービス処理要求が初めて送信された場合に、前記サービス処理側により現在使用されているデータベース実行モード情報を取得し、前記データベース実行モード情報を前記サービス処理要求に書き込むステップであって、前記サービスイベントについて再送される各々の後続の要求は前記データベース実行モード情報を含む、前記書き込むステップを備え；
前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定する前記ステップは：
前記要求に含まれる前記データベース実行モード情報に基づいて、前記データベース実行モード情報に対応するデータベースを特定するステップを備える；
請求項１に記載の方法。
サービス処理方法であって：
サービス要求側に適用され；
サービス処理参照情報を含むサービス処理要求を生成するステップと；
前記サービス処理要求をサービス処理側へ送信するステップであって、前記サービス処理側が、前記サービス処理要求の受信後に、前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定し、前記特定した格納場所に冪等性チェックを実行し、前記冪等性チェックの結果に基づいて現行サービスの処理を実行する、前記送信するステップと；
を備え、
前記サービス処理参照情報は、データベース内での前記現行サービスの関連データの格納場所を特定するために、前記サービス処理側によって用いられ、前記同一のサービスイベントについて繰り返し送信されるサービス処理要求は、同一のサービス処理参照情報を含む；
サービス処理方法。
前記サービス処理参照情報は時刻情報であり：
サービス処理参照情報を含むサービス処理要求を生成する前記ステップは：
前記サービス処理要求が前記同一のサービスイベントについて初めて送信された場合に、現在時刻情報を取得し、前記時刻情報を前記サービス処理要求に書き込むステップであって、前記サービスイベントについて再送される各々の後続の要求は前記時刻情報を含む、前記書き込むステップを備える；
請求項４に記載の方法。
前記サービス処理参照情報はデータベース実行モード情報であり、データベースモードは正常モードとフェイルオーバモードとを含み；
サービス処理参照情報を含むサービス処理要求を生成する前記ステップは：
前記サービス処理要求が前記同一のサービスイベントについて初めて送信された場合、前記サービス処理側により現在用いられているデータベース実行モード情報を取得し、前記データベース実行モード情報を前記サービス処理要求に書き込むステップであって、前記サービスイベントについて再送された各々の後続の要求は前記データベース実行モード情報を含む、前記書き込むステップを備える；
請求項４に記載の方法。
サービス処理方法であって：
サービス処理側に適用され：
サービス要求側により送信されたサービス処理要求を受信するステップであって、前記サービス処理要求はサービス処理参照情報を含む、前記受信するステップと；
前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定し、前記特定した格納場所に冪等性チェックを実行し、前記冪等性チェックの結果に基づいて現行サービスに処理を実行するステップと；を備え、
前記サービス処理参照情報は、データベース内での前記現行サービスの関連データの格納場所を特定するために、前記サービス処理側によって用いられ、前記サービス要求側により前記同一のサービスイベントについて繰り返し送信されるサービス処理要求は、前記同一のサービス処理参照情報を含む、
サービス処理方法。
前記サービス処理参照情報は時刻情報であり；
前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定する前記ステップは：
前記要求に含まれる前記時刻情報に基づいて、前記時刻情報に対応する時刻ディメンションデータパーティションテーブルを特定するステップを備える；
請求項７に記載の方法。
前記サービス処理参照情報はデータベース実行モード情報であり、データベースモードは正常モードとフェイルオーバモードとを含み；
前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定する前記ステップは：
前記要求に含まれる前記データベース実行モード情報に基づいて前記データベース実行モード情報に対応するデータベースを特定するステップを備える；
請求項７に記載の方法。
サービス処理デバイスであって：
サービス要求側に適用され：
サービス処理参照情報を含むサービス処理要求を生成するように構成された要求生成モジュールと；
前記サービス処理要求をサービス処理側へ送信するように構成された要求送信モジュールであって、前記サービス処理側が、前記サービス処理要求の受信後に、前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定し、前記特定した格納場所に冪等性チェックを実行し、前記冪等性チェックの結果に基づき現行サービスに処理を実行する、前記要求送信モジュールと；を備え、
前記サービス処理参照情報は、データベース内での前記現行サービスの関連データの格納場所を特定するために、前記サービス処理側により用いられ、前記同一のサービスイベントについて繰り返し送信されたサービス処理要求は前記同一のサービス処理参照情報を含む、
サービス処理デバイス。
前記サービス処理参照情報は時刻情報であり；
前記要求生成モジュールは、前記サービス処理要求が前記同一のサービスイベントについて初めて送信された場合に現在時刻情報を取得し、前記時刻情報を前記サービス処理要求に書き込むように構成され、前記サービスイベントについて再送される各々の後続の要求は前記時刻情報を含む；
請求項１０に記載のデバイス。
前記サービス処理参照情報はデータベース実行モード情報であり、データベースモードは正常モードとフェイルオーバモードとを含み；
前記要求生成モジュールは、前記サービス処理要求が前記同一のサービスイベントについて初めて送信された場合に、前記サービス処理側により現在用いられているデータベース実行モード情報を取得し、前記データベース実行モード情報を前記サービス処理要求へ書き込むように構成されており、前記サービスイベントについて再送される各々の後続の要求は前記データベース実行モード情報を含む、
請求項１０に記載のデバイス。
サービス処理デバイスであって：
サービス処理側に適用され：
サービス要求側により送信されるサービス処理要求を受信するように構成された要求受信モジュールであって、前記サービス処理要求はサービス処理参照情報を備える、前記要求受信モジュールと；
前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定し、前記特定した格納場所に冪等性チェックを実行し、前記冪等性チェックの結果に基づいて現行サービスに処理を実行するように構成されたサービス処理モジュールと；を備え、
前記サービス処理参照情報は、データベース内での前記現行サービスの関連データの格納場所を特定するために、前記サービス処理側により用いられ、前記同一のサービスイベントについて前記サービス要求側により繰り返し送信されるサービス処理要求は前記同一のサービス処理参照情報を含む、
サービス処理デバイス。
前記サービス処理参照情報は時刻情報であり；
前記サービス処理モジュールは、前記要求に含まれる前記時刻情報に基づいて、前記時刻情報に対応する時刻ディメンションデータパーティションテーブルを特定し、前記特定したデータパーティションテーブルに冪等性チェックを実行し、前記冪等性チェックの結果に基づいて前記現行サービスに処理を実行するように構成された、
請求項１３に記載のデバイス。
前記サービス処理参照情報はデータベース実行モード情報であり、データベースモードは正常モードとフェイルオーバモードとを含み；
前記サービス処理モジュールは、前記要求に含まれる前記データベース実行モード情報に基づいて、前記データベース実行モード情報に対応するデータベースを特定し、前記特定したデータベースに冪等性チェックを実行し、前記冪等性チェックの結果に基づいて前記現行サービスに処理を実行するように構成された、
請求項１３に記載のデバイス。
サービス処理システムであって：
サービス要求側デバイスとサービス処理側デバイスとを備え：
前記サービス要求側デバイスは：
サービス処理参照情報を含むサービス処理要求を生成するように構成された要求生成モジュールと；
前記サービス処理要求を、サービス処理側へ送信するように構成された要求送信モジュールと；を備え、
前記サービス処理参照情報は、データベース内での現行サービスの関連データの格納場所を特定するために、前記サービス処理側によって用いられ、前記同一のサービスイベントについて繰り返し送信されたサービス処理要求は前記同一のサービス処理参照情報を含み；
前記サービス処理側デバイスは：
前記サービス要求側により送信される前記サービス処理要求を受信するように構成された要求受信モジュールと；
前記要求に含まれる前記サービス処理参照情報に基づいて、対応する格納場所を特定し、前記特定した格納場所に冪等性チェックを実行し、前記冪等性チェックの結果に基づいて前記現行サービスに処理を実行するように構成されたサービス処理モジュールと；を備える、
サービス処理システム。