知財求人 - 知財ポータルサイト「IP Force」
特表2024-521688要求処理方法、装置、コンピューティング機器及びコンピュータプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-06-04
(54)【発明の名称】要求処理方法、装置、コンピューティング機器及びコンピュータプログラム
(51)【国際特許分類】
G06F 9/52 20060101AFI20240528BHJP
【ＦＩ】
G06F9/52 120B
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2023571701
(86)(22)【出願日】2022-07-29
(85)【翻訳文提出日】2023-11-17
(86)【国際出願番号】 CN2022108772
(87)【国際公開番号】W WO2023029837
(87)【国際公開日】2023-03-09
(31)【優先権主張番号】202111003764.2
(32)【優先日】2021-08-30
(33)【優先権主張国・地域又は機関】CN
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＭｙＳＱＬ
２．ＯＲＡＣＬＥ
(71)【出願人】
【識別番号】517392436
【氏名又は名称】▲騰▼▲訊▼科技（深▲セン▼）有限公司
【氏名又は名称原語表記】ＴＥＮＣＥＮＴ ＴＥＣＨＮＯＬＯＧＹ （ＳＨＥＮＺＨＥＮ） ＣＯＭＰＡＮＹ ＬＩＭＩＴＥＤ
【住所又は居所原語表記】３５／Ｆ，Ｔｅｎｃｅｎｔ Ｂｕｉｌｄｉｎｇ，Ｋｅｊｉｚｈｏｎｇｙｉ Ｒｏａｄ，Ｍｉｄｗｅｓｔ Ｄｉｓｔｒｉｃｔ ｏｆ Ｈｉ－ｔｅｃｈ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７，ＣＨＩＮＡ
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100150197
【弁理士】
【氏名又は名称】松尾 直樹
(72)【発明者】
【氏名】熊 ▲亮▼春
(72)【発明者】
【氏名】潘 安群
(72)【発明者】
【氏名】雷 ▲海▼林
(57)【要約】
要求処理方法、装置、コンピューティング機器及び記憶媒体であって、データベースの技術分野に属している。ロック同期モードに対して柔軟な複数のレベルを設置し、弱い同期モードで、データ要求に対応するデータリソースを直接的にロッキングして、当該データ要求を実行することで、データ要求を優先的に推進することを保証でき、第２のコンピューティング機器の応答を待つ必要がなく、非弱い同期モードで、各第２のコンピューティング機器のロッキングフィードバック情報を取得し、取得したロッキングフィードバック情報がターゲット条件に合う場合、当該データリソースをロッキングして当該データ要求を実行し、異なるトラフィックシナリオで異なるロック同期モードを選択するようにサポートし、例えばスマート交通シナリオで、弱い同期モードに基づいて、駐車スペース追加の要求を優先的に推進できるが、行程共有の要求を優先的に推進する必要がなく、クラスタデータベースが異なるトラフィックシナリオの処理ニーズを満たすことができることを保証して、クラスタデータベースシステムの処理能力を向上する。
【特許請求の範囲】
【請求項1】
クラスタデータベースにおける第１のコンピューティング機器が実行する要求処理方法であって、データ要求に応答して、前記クラスタデータベースのロック同期モードを決定するステップと、
前記ロック同期モードが弱い同期モードである場合、前記データ要求に対応するデータリソースをロッキングして、前記データ要求を実行するステップと、
前記ロック同期モードが前記弱い同期モードではない場合、前記クラスタデータベースにおける少なくとも１つの第２のコンピューティング機器の、前記データリソースに対するロッキングフィードバック情報を取得するステップであって、前記ロッキングフィードバック情報は、前記第２のコンピューティング機器の、前記データリソースに対するロッキングが成功したかどうかを表し、取得した前記ロッキングフィードバック情報が前記ロック同期モードに対応するターゲット条件を満たしている場合、前記データ要求に対応するデータリソースをロッキングして、前記データ要求を実行するステップと、を含む方法。
【請求項2】
前記クラスタデータベースにおける少なくとも１つの第２のコンピューティング機器の、前記データリソースに対するロッキングフィードバック情報を取得する前記ステップは、前記少なくとも１つの第２のコンピューティング機器に、前記データ要求に関連付けられるロッキング要求を送信するステップと、
前記少なくとも１つの第２のコンピューティング機器から前記ロッキング要求に基づいて戻された前記ロッキングフィードバック情報を受信するステップと、を含む請求項１に記載の方法。
【請求項3】
前記少なくとも１つの第２のコンピューティング機器に、前記データ要求に関連付けられるロッキング要求を送信する前記ステップは、前記第１のコンピューティング機器上のメッセージ処理スレッドによって、前記少なくとも１つの第２のコンピューティング機器上のメッセージ処理スレッドに前記ロッキング要求をそれぞれ送信するステップを含み、
前記少なくとも１つの第２のコンピューティング機器から前記ロッキング要求に基づいて戻された前記ロッキングフィードバック情報を受信する前記ステップは、
前記第１のコンピューティング機器上のメッセージ処理スレッドによって、前記少なくとも１つの第２のコンピューティング機器上のメッセージ処理スレッドから戻された前記ロッキングフィードバック情報を受信するステップを含む請求項２に記載の方法。
【請求項4】
前記方法は、何れか１つの第２のコンピューティング機器のロッキングフィードバック情報を受信したことに応答して、前記データ要求がアクティブ状態にある場合、前記メッセージ処理スレッドによって前記ロッキングフィードバック情報を前記データ要求のロック要求スレッドに送信するステップと、
前記データ要求が非アクティブ状態にあり、且つ前記ロッキングフィードバック情報が、ロッキング成功を表す場合、前記第２のコンピューティング機器にロック解除要求を送信するステップであって、前記ロック解除要求は、前記データ要求に対応するデータリソースを解除するように、前記第２のコンピューティング機器に指示するためのものであるステップと、をさらに含む請求項３に記載の方法。
【請求項5】
前記ロック同期モードが強い同期モードである場合、前記ターゲット条件は、前記少なくとも１つの第２のコンピューティング機器のロッキングフィードバック情報が何れもロッキング成功を表すことであり、前記ロック同期モードが準強い同期モードである場合、前記ターゲット条件は、前記少なくとも１つの第２のコンピューティング機器のうちのターゲット数以上の第２のコンピューティング機器のロッキングフィードバック情報が、ロッキング成功を表すことである請求項１に記載の方法。
【請求項6】
前記ロック同期モードが強い同期モードである場合、前記ターゲット条件は、待ち期間が第１の待ち閾値の以下であり、且つ前記少なくとも１つの第２のコンピューティング機器のロッキングフィードバック情報が何れもロッキング成功を表すことであり、前記ロック同期モードが準強い同期モードである場合、前記ターゲット条件は、待ち期間が第２の待ち閾値の以下であり、且つ前記少なくとも１つの第２のコンピューティング機器のうちのターゲット数以上の第２のコンピューティング機器のロッキングフィードバック情報がロッキング成功を表すことである請求項１に記載の方法。
【請求項7】
前記方法は、前記ロック同期モードが前記準強い同期モードである場合、前記ターゲット数を取得するステップと、
前記ターゲット数が１より小さいか、又は前記クラスタデータベースにおける全ての第２のコンピューティング機器の数を超える場合、前記ロック同期モードを前記強い同期モードに切り替えるステップと、をさらに含む請求項５又は６に記載の方法。
【請求項8】
前記方法は、取得した前記ロッキングフィードバック情報が前記ターゲット条件を満たしていないか、又は前記データ要求の実行が完了した場合、前記少なくとも１つの第２のコンピューティング機器にロック解除要求を送信するステップであって、前記ロック解除要求は、前記データ要求に対応するデータリソースを解除するように、前記第２のコンピューティング機器に指示するためのものであるステップと、をさらに含む請求項１に記載の方法。
【請求項9】
前記データ要求は、データ定義言語ＤＤＬ要求である請求項１に記載の方法。
【請求項10】
クラスタデータベースにおける第２のコンピューティング機器が実行する要求処理方法であって、データ要求に関連付けられるロッキング要求に応答して、前記ロッキング要求をロッキングキューに追加するステップであって、前記ロッキング要求は、ロック同期モードが弱い同期モードではない場合、前記クラスタデータベースにおける第１のコンピューティング機器によって送信されるものであるステップと、
前記ロッキングキューにおける前記ロッキング要求を処理して、ロッキングフィードバック情報を取得するステップと、
前記第１のコンピューティング機器に前記ロッキングフィードバック情報を送信するステップと、を含む方法。
【請求項11】
前記ロッキングキューにおける前記ロッキング要求を処理して、ロッキングフィードバック情報を取得する前記ステップは、前記データ要求に対応するデータリソースをロッキングして、前記ロッキングフィードバック情報は、ロッキング成功を表すように決定されるステップと、
前記ロッキング要求の前記ロッキングキューにおける待ち期間が第３の待ち閾値を超えるか、又はデッドロック検出が不合格である場合、前記ロッキングフィードバック情報は、ロッキング失敗を表すように決定されるステップと、を含む請求項１０に記載の方法。
【請求項12】
前記方法は、前記第１のコンピューティング機器のデッドロック検出メッセージに応答して、前記ロッキング要求に対してロカールデッドロック検出を行うステップと、
ロカールデッドロック検出が不合格である場合、デッドロック検出が不合格であると決定するステップと、
ロカールデッドロック検出が合格である場合、前記ロッキング要求のロック待ちリンクを決定するステップであって、前記ロック待ちリンクは、前記ロッキング要求と依存関係を有するロック情報を含むステップと、
前記ロック待ちリンクが遠位ロックを含む場合、前記遠位ロックを発信する第３のコンピューティング機器にデッドロック検出メッセージを送信するステップであって、前記遠位ロックは、前記第２のコンピューティング機器に登録されているロック情報であるが、前記第２のコンピューティング機器から発信されるロック情報ではないステップと、
前記デッドロック検出メッセージを送信する何れか１つのコンピューティング機器は前記デッドロック検出メッセージを再び受信した場合、デッドロック検出が不合格であると決定するステップと、をさらに含む請求項１０に記載の方法。
【請求項13】
前記データ要求に関連付けられるロッキング要求に応答して、前記ロッキング要求をロッキングキューに追加する前記ステップは、前記第２のコンピューティング機器上のメッセージ処理スレッドによって、前記ロッキング要求を受信するステップと、
前記メッセージ処理スレッドによって、前記ロッキング要求に対応するロックプロキシスレッドを起動させるステップと、
前記ロックプロキシスレッドによって、前記ロッキング要求を前記ロッキングキューに追加するステップと、を含む請求項１０に記載の方法。
【請求項14】
前記方法は、前記データ要求に対応するデータリソースをロッキングする場合、前記データ要求に対応するロック情報を登録するステップと、
ターゲット期間ごとに、前記ロック情報がアクティブなロック情報であるかどうかを確定するステップと、
前記ロック情報がアクティブなロック情報であり、且つ前記データ要求に対応するデータリソースのロッキング期間が死活監視閾値を超える場合、前記第１のコンピューティング機器に死活監視要求を送信するステップであって、前記死活監視要求は、前記データリソースを解除するかどうかを指示するように、前記第１のコンピューティング機器に要求するためのものであるステップと、をさらに含む請求項１０に記載の方法。
【請求項15】
要求処理装置であって、データ要求に応答して、クラスタデータベースのロック同期モードを決定する決定モジュールと、
前記ロック同期モードが弱い同期モードである場合、前記データ要求に対応するデータリソースをロッキングして、前記データ要求を実行するロッキング実行モジュールと、
前記ロック同期モードが前記弱い同期モードではない場合、前記クラスタデータベースにおける少なくとも１つの第２のコンピューティング機器の、前記データリソースに対するロッキングフィードバック情報を取得する第１の取得モジュールであって、前記ロッキングフィードバック情報は、前記第２のコンピューティング機器の、前記データリソースに対するロッキングが成功したかどうかを表すためのものである第１の取得モジュールと、を含み、
前記ロッキング実行モジュールはさらに、取得した前記ロッキングフィードバック情報が、前記ロック同期モードに対応するターゲット条件を満たしている場合、前記データ要求に対応するデータリソースをロッキングして、前記データ要求を実行する装置。
【請求項16】
データ要求に関連付けられるロッキング要求に応答して、前記ロッキング要求をロッキングキューに追加する追加モジュールであって、前記ロッキング要求は、ロック同期モードが弱い同期モードではない場合、クラスタデータベースにおける第１のコンピューティング機器によって送信されるものである追加モジュールと、前記ロッキングキューにおける前記ロッキング要求を処理して、ロッキングフィードバック情報を取得する処理モジュールと、
前記第１のコンピューティング機器に前記ロッキングフィードバック情報を送信する送信モジュールと、を含む要求処理装置。
【請求項17】
コンピューティング機器であって、前記コンピューティング機器は１つ又は複数のプロセッサー及び１つ又は複数のメモリを含み、前記１つ又は複数のメモリには少なくとも１つのコンピュータプログラムが記憶され、前記少なくとも１つのコンピュータプログラムは前記１つ又は複数のプロセッサーによって読み込まれて実行されることで、請求項１～請求項９、又は請求項１０～請求項１４の何れか１つの項に記載の要求処理方法を実現することを特徴とするコンピューティング機器。
【請求項18】
コンピューティング機器の１つ又は複数のプロセッサーによって読み込まれて実行されることで、請求項１～請求項９、又は請求項１０～請求項１４の何れか１つの項に記載の要求処理方法を実現することを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本出願は、２０２１年０８月３０日にて中国特許庁に提出され、出願番号が２０２１１１００３７６４２であり、出願の名称が「要求処理方法、装置、コンピューティング機器及び記憶媒体」である中国特許出願の優先権を主張して、その全ての内容は本出願に援用されている。
【0002】
本出願は、データベースの技術分野に関して、特に要求処理技術に関している。
【背景技術】
【0003】
データベース技術の発展に連れて、従来のスタンドアロンデータベースはだんだんビッグデータ、クラウドコンピューティングなどのトラフィックシナリオに適応できなくなり、クラスタデータベースはますます普及している。現在、ＭｙＳＱＬ、ＰｏｓｔｇｒｅＳＱＬなどのスタンドアロンデータベースであっても、ＩＢＭ、Ｏｒａｃｌｅなどのクラスタデータベースであっても、何れも強い同期ロックメカニズムによる並行制御方法を採用し、強い同期ロックメカニズムは以下の通りであり、ロック要求プロセスはクラスタ内の全てのコンピューティング機器から何れも対応するレベルのロックを取得した場合に限り、ロック要求に成功し、さもなければ、待機し、クラスタ内の何れか１つのコンピューティング機器のロック要求が失敗するか、又は待機がタイムアウトした場合、当該プロセスはロックを成功的に要求できない。
【発明の概要】
【発明が解決しようとする課題】
【0004】
クラスタデータベースにおいて、強い同期ロックメカニズムはクラスタ内の全てのコンピューティング機器が何れも対応するレベルのロックを取得し、クラスタ内のコンピューティング機器の数の増加に連れて、ロック要求のオーバーヘッドも著しく増えて、さらに、クラスタデータベースシステムの処理能力が悪くなる。従って、クラスタデータベースシステムの処理能力を向上できる方法を必要とする。
【0005】
本出願の実施例は、クラスタデータベースシステムの処理能力を向上できる要求処理方法、装置、コンピューティング機器及び記憶媒体を提供する。当該技術案は以下の通りである。
【課題を解決するための手段】
【0006】
１つの態様によれば、クラスタデータベースにおける第１のコンピューティング機器が実行する要求処理方法を提供し、
データ要求に応答して、前記クラスタデータベースのロック同期モードを決定するステップと、
前記ロック同期モードが弱い同期モードである場合、前記データ要求に対応するデータリソースをロッキングして、前記データ要求を実行するステップと、
前記ロック同期モードが弱い同期モードではない場合、前記クラスタデータベースにおける少なくとも１つの第２のコンピューティング機器の、前記データリソースに対するロッキングフィードバック情報を取得するステップであって、前記ロッキングフィードバック情報は、前記第２のコンピューティング機器の、前記データリソースに対するロッキングが成功したかどうかを表し、取得した前記ロッキングフィードバック情報が前記ロック同期モードに対応するターゲット条件を満たしている場合、前記データ要求に対応するデータリソースをロッキングして、前記データ要求を実行するステップと、を含む。
データ要求に応答して、前記クラスタデータベースのロック同期モードを決定するステップと、
前記ロック同期モードが弱い同期モードである場合、前記データ要求に対応するデータリソースをロッキングして、前記データ要求を実行するステップと、
前記ロック同期モードが弱い同期モードではない場合、前記クラスタデータベースにおける少なくとも１つの第２のコンピューティング機器の、前記データリソースに対するロッキングフィードバック情報を取得するステップであって、前記ロッキングフィードバック情報は、前記第２のコンピューティング機器の、前記データリソースに対するロッキングが成功したかどうかを表し、取得した前記ロッキングフィードバック情報が前記ロック同期モードに対応するターゲット条件を満たしている場合、前記データ要求に対応するデータリソースをロッキングして、前記データ要求を実行するステップと、を含む。
【0007】
１つの態様によれば、クラスタデータベースにおける第２のコンピューティング機器が実行する要求処理方法を提供し、前記方法は
データ要求に関連付けられるロッキング要求に応答して、前記ロッキング要求をロッキングキューに追加するステップであって、前記ロッキング要求は、ロック同期モードが弱い同期モードではない場合、前記クラスタデータベースにおける第１のコンピューティング機器によって送信されるものであるステップと、
前記ロッキングキューにおける前記ロッキング要求を処理して、ロッキングフィードバック情報を取得するステップと、
前記第１のコンピューティング機器に前記ロッキングフィードバック情報を送信するステップと、を含む。
データ要求に関連付けられるロッキング要求に応答して、前記ロッキング要求をロッキングキューに追加するステップであって、前記ロッキング要求は、ロック同期モードが弱い同期モードではない場合、前記クラスタデータベースにおける第１のコンピューティング機器によって送信されるものであるステップと、
前記ロッキングキューにおける前記ロッキング要求を処理して、ロッキングフィードバック情報を取得するステップと、
前記第１のコンピューティング機器に前記ロッキングフィードバック情報を送信するステップと、を含む。
【0008】
１つの態様によれば、要求処理装置を提供し、
データ要求に応答して、クラスタデータベースのロック同期モードを決定する決定モジュールと、
前記ロック同期モードが弱い同期モードである場合、前記データ要求に対応するデータリソースをロッキングして、前記データ要求を実行するロッキング実行モジュールと、
前記ロック同期モードが弱い同期モードではない場合、前記クラスタデータベースにおける少なくとも１つの第２のコンピューティング機器の、前記データリソースに対するロッキングフィードバック情報を取得する第１の取得モジュールであって、前記ロッキングフィードバック情報は、前記第２のコンピューティング機器の、前記データリソースに対するロッキングが成功したかどうかを表すためのものである第１の取得モジュールと、を含み、
前記ロッキング実行モジュールはさらに、取得した前記ロッキングフィードバック情報が前記ロック同期モードに対応するターゲット条件を満たしている場合、前記データ要求に対応するデータリソースをロッキングして、前記データ要求を実行する。
データ要求に応答して、クラスタデータベースのロック同期モードを決定する決定モジュールと、
前記ロック同期モードが弱い同期モードである場合、前記データ要求に対応するデータリソースをロッキングして、前記データ要求を実行するロッキング実行モジュールと、
前記ロック同期モードが弱い同期モードではない場合、前記クラスタデータベースにおける少なくとも１つの第２のコンピューティング機器の、前記データリソースに対するロッキングフィードバック情報を取得する第１の取得モジュールであって、前記ロッキングフィードバック情報は、前記第２のコンピューティング機器の、前記データリソースに対するロッキングが成功したかどうかを表すためのものである第１の取得モジュールと、を含み、
前記ロッキング実行モジュールはさらに、取得した前記ロッキングフィードバック情報が前記ロック同期モードに対応するターゲット条件を満たしている場合、前記データ要求に対応するデータリソースをロッキングして、前記データ要求を実行する。
【0009】
１つの態様によれば、要求処理装置を提供し、
データ要求に関連付けられるロッキング要求に応答して、前記ロッキング要求をロッキングキューに追加する追加モジュールであって、前記ロッキング要求は、ロック同期モードが弱い同期モードではない場合、前記クラスタデータベースにおける第１のコンピューティング機器によって送信されるものである追加モジュールと、
前記ロッキングキューにおける前記ロッキング要求を処理して、ロッキングフィードバック情報を取得する処理モジュールと、
前記第１のコンピューティング機器に前記ロッキングフィードバック情報を送信する送信モジュールと、を含む。
データ要求に関連付けられるロッキング要求に応答して、前記ロッキング要求をロッキングキューに追加する追加モジュールであって、前記ロッキング要求は、ロック同期モードが弱い同期モードではない場合、前記クラスタデータベースにおける第１のコンピューティング機器によって送信されるものである追加モジュールと、
前記ロッキングキューにおける前記ロッキング要求を処理して、ロッキングフィードバック情報を取得する処理モジュールと、
前記第１のコンピューティング機器に前記ロッキングフィードバック情報を送信する送信モジュールと、を含む。
【0010】
１つの態様によれば、コンピューティング機器を提供し、当該コンピューティング機器は１つ又は複数のプロセッサー及び１つ又は複数のメモリを含み、当該１つ又は複数のメモリには少なくとも１つのコンピュータプログラムが記憶され、当該少なくとも１つのコンピュータプログラムは当該１つ又は複数のプロセッサーによって読み込まれて実行されることで、上記の何れか１つの可能な実現形態の要求処理方法を実現する。
【0011】
１つの態様によれば、記憶媒体を提供し、当該記憶媒体には少なくとも１つのコンピュータプログラムが記憶され、当該少なくとも１つのコンピュータプログラムはプロセッサーによって読み込まれて実行されることで、上記の何れか１つの可能な実現形態の要求処理方法を実現する。
【0012】
１つの態様によれば、コンピュータプログラム製品又はコンピュータプログラムを提供し、前記コンピュータプログラム製品又は前記コンピュータプログラムは１つ又は複数のプログラムコードを含み、前記１つ又は複数のプログラムコードはコンピュータ可読記憶媒体に記憶される。コンピューティング機器の１つ又は複数のプロセッサーはコンピュータ可読記憶媒体から前記１つ又は複数のプログラムコードを読み取り、前記１つ又は複数のプロセッサーは前記１つ又は複数のプログラムコードを実行することで、コンピューティング機器に上記の何れか１つの可能な実施形態の要求処理方法を実行させる。
【発明の効果】
【0013】
本出願の実施例が提供する技術案による有益な効果は少なくとも以下を含み、
ロック同期モードに対して柔軟な複数のレベルを設置し、弱い同期モードで、データ要求に対応するデータリソースを直接的にロッキングして、当該データ要求を実行することで、データ要求を優先的に推進することを保証でき、第２のコンピューティング機器の応答を待つ必要がなく、非弱い同期モードで、各第２のコンピューティング機器のロッキングフィードバック情報を取得し、取得したロッキングフィードバック情報がターゲット条件を満たしている場合に限り、当該データリソースをロッキングして当該データ要求を実行し、異なるトラフィックシナリオで異なるロック同期モードを選択するようにサポートし、クラスタデータベースが異なるトラフィックシナリオの処理ニーズを満たすことができることを保証して、クラスタデータベースシステムの処理能力を向上する。
ロック同期モードに対して柔軟な複数のレベルを設置し、弱い同期モードで、データ要求に対応するデータリソースを直接的にロッキングして、当該データ要求を実行することで、データ要求を優先的に推進することを保証でき、第２のコンピューティング機器の応答を待つ必要がなく、非弱い同期モードで、各第２のコンピューティング機器のロッキングフィードバック情報を取得し、取得したロッキングフィードバック情報がターゲット条件を満たしている場合に限り、当該データリソースをロッキングして当該データ要求を実行し、異なるトラフィックシナリオで異なるロック同期モードを選択するようにサポートし、クラスタデータベースが異なるトラフィックシナリオの処理ニーズを満たすことができることを保証して、クラスタデータベースシステムの処理能力を向上する。
【図面の簡単な説明】
【0014】
【図1】本出願の実施例が提供する要求処理方法の実施環境の概略図である。
【図2】本出願の実施例が提供するロック同期メカニズムモデルの原理概略図である。
【図3】本出願の実施例が提供する要求処理方法のフローチャートである。
【図4】本出願の実施例が提供する要求処理方法のインタラクションフローチャートである。
【図5】本出願の実施例が提供するロッキングフローの原理概略図である。
【図6】本出願の実施例が提供するロック解除フローの原理概略図である。
【図7】本出願の実施例が提供するデッドロック検出フローの原理概略図である。
【図8】本出願の実施例が提供する要求処理装置の構造概略図である。
【図9】本出願の実施例が提供する要求処理装置の構造概略図である。
【図10】本出願の実施例が提供するコンピューティング機器の構造概略図である。
【図11】本出願の実施例が提供するコンピューティング機器の構造概略図である。
【発明を実施するための形態】
【0015】
本出願の目的、技術案及び利点がより分かりやすくなるために、以下、図面を結合して本出願の実施形態をさらに詳しく記載する。
【0016】
本出願における「第１」「第２」などの用語は作用及び機能が基本的に同様である同一項又は類似項を区別するための用語であり、ここで、「第１」、「第２」、「第ｎ」の間は論理又は順序上の依存関係を具備しないとともに、数及び実行順序を限定しない。
【0017】
本出願における「少なくとも１つ」という用語は１つ又は複数を指し、「複数」の意味は２つ又は２つ以上であり、例えば、複数の第１の位置は、２つ又は２つ以上の第１の位置を指す。
【0018】
本出願の実施例を紹介する前、いくつかのクラウド技術分野内の基本的な概念を導入する。
【0019】
クラウド技術（Ｃｌｏｕｄ Ｔｅｃｈｎｏｌｏｇｙ）：広域通信網又はローカルネットワーク内でハードウェア、ソフトウェア、ネットワークなどの一連のリソースを統合して、データのコンピューティング、記憶、処理及び共有を実現するホスティング技術であり、クラウドコンピューティングビジネスモードに基づいて適用されるネットワーク技術、情報技術、統合技術、プラットフォーム管理技術、アプリケーション技術などの総称であり、リソースプールを構成でき、ニーズに応じて使用され、柔軟且つ便利である。クラウド技術分野においてクラウドコンピューティング技術は重要なサポートになる。技術ネットワークシステムのバックグランドサービスは大量のコンピューティング、記憶リソース、例えばビデオウェブサイト、ピクチャ類ウェブサイト及びより多くのポータルサイトを必要とする。インターネット業界の高度発展及び適用に連れて、将来、各物品は何れも自分の識別マークが存在して、バックグランドシステムに伝送して、論理処理を行う必要がある可能性があり、異なるレベルのデータは分かれて処理され、各類の業界データは何れも強大なシステムバックグラウンドサポートを必要とし、クラウドコンピューティングによって実現できる。
【0020】
クラウド記憶（Ｃｌｏｕｄ Ｓｔｏｒａｇｅ）：クラウドコンピューティング概念に基づいて延伸して発展した新規概念であり、分散型クラウド記憶システム（以下、記憶システムと略称される）はクラスタアプリケーション、グリッド技術及び分散型ファイル記憶システムなどの機能によって、ネットワークにおける大量の異なるタイプの記憶機器（記憶機器は記憶ノードとも呼ばれる）を、アプリケーションソフトウェア又はアプリケーションインターフェースを介して集積して協働動作させ、共同で外部にデータ記憶及びトラフィックアクセス機能を提供する記憶システムである。
【0021】
データベース（Ｄａｔａｂａｓｅ）：要するに、電子化ファイルキャビネットであり―電子ファイルを記憶する箇所であり、ユーザーはファイルにおけるデータに対して追加、検索、更新、削除などの操作を行うことができる。「データベース」とは、一定の方式で記憶され、複数のユーザーと共有可能、できるだけ小さな冗長度を有し、アプリケーションプログラムと互いに独立するデータセットである。
【0022】
以下、本出願の実施例に係る用語を解釈して説明する。
【0023】
コンピューティング機器：即ち、コンピューティングノードであり、データベース（一般的にクラスタデータベースであり、スタンドアロンデータベースにとってスタンドアロン機器自体はコンピューティング機器である）の、ユーザーの特定コンピューティング要求を処理して、主にユーザー要求を実行するノード機器であり、ＳＱＬエンジン（ＳＱＬＥｎｇｉｎｅ）とも呼ばれ、ＳＱＬの英語のフルネームはＳｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅであり、中国語のフルネームは構造化クエリ言語である。
【0024】
ロックメカニズム：クラスタデータベースの運転期間、異なる又は同一コンピューティング機器には、異なるプロセス又はスレッドが同一種類のデータリソース（例えば：データベース、データテーブル、データ列、データデータテーブルなど）を同時に修正するという現象があり、ロックメカニズムによって当該データリソースの、異なる並行プロセス又はスレッド中の修正の正確さを保証できる。クラスタデータベースは中央クラスタデータベース及び分散型クラスタデータベースに分けられ、中央クラスタデータベースは集中化制御モジュールを有するクラスタデータベースであり、分散型クラスタデータベースは非集中化されたクラスタデータベースである。
【0025】
強い同期ロックメカニズム：即ち、ロック要求プロセスはクラスタ内の全てのコンピューティング機器から対応するレベルのロックを取得した場合に限り、ロック要求が成功し、さもなければ、待機し、クラスタ内の何れか１つのコンピューティング機器のロック要求が失敗し、又は待機がタイムアウトした場合、当該プロセスはロックを成功的に要求できない。
【0026】
強い同期ロックメカニズムの、ノードの間（即ち、コンピューティング機器の間）の通信性能に対する要求が非常に高く、単一コンピューティング機器の不応答又は故障のため、クラスタ内の他のコンピューティング機器の実行が当該コンピューティング機器にブロックされてしまい、クラスタ全体のトラフィック処理能力が著しく低下するように見え、例えば、クラスタ全体のトラフィック処理はブロックされる（Ｈａｎｇ（ハングアップされる））。一般的に、強い同期ロックメカニズムは主にスタンドアロンデータベース及び中央クラスタデータベースシナリオに適用される。
【0027】
弱い同期ロックメカニズム：実行過程で、いくつかのプロセス又はスレッド（例えば、データ定義言語ＤＤＬ要求のプロセス又はスレッド）はある種類のデータリソースをロッキングしようとすると、他のコンピューティング機器にロックを要求する必要がなく、直接的に推進すればよく、操作の正確さは特定メカニズムＷｒｉｔｉｎｇ Ｆｅｎｃｅ（書き込みバリア）によって保証される。書き込みバリアメカニズムの保証で、ＤＤＬ要求のプロセス又はスレッドはロックを要求する必要がなく、直接的に推進して実行でき、そして、書き込みバリアを推進することで、他のトラフィックプロセス又はスレッドはデータを操作する時、何れも今回操作の書き込みバリアバージョンが最新データに記憶される書き込みバリアバージョンと一致するかどうかを対比し、不一致であれば、データ処理の正確さ及び一致性を保証するために、トラフィックプロセス又はスレッドに対応するトラフィックトランザクションをロールバックする。
【0028】
弱い同期ロックメカニズムはある意味で、ＤＤＬ要求の優先を保証し、なぜならば、書き込みバリアを推進したとたん、操作に対応するデータ操作言語ＤＭＬ要求はロールバックされる可能性があるためであり、即ち、弱い同期ロックメカニズムはＤＭＬ要求に優しくない。上記の弱い同期ロックメカニズムは、あるタイプのプロセス又はスレッド（例えばＤＤＬ要求のプロセス）の優先実行と見なされてもよく、このような弱い同期モードは、補助手段（例えば書き込みバリア又はリースメカニズム）を使用してメカニズム全体の推進の正確さを保証する必要があり、このような弱い同期モードは分散型クラスタデータベースシナリオに好適であるが、ユーザーに対する表現行為が伝統のデータベースの実行行為と一致しない状況が存在し、且つＤＭＬ要求に優しくない。また、弱い同期モードでのＤＤＬプロセス又はスレッドはロックを取得したとデフォルトされるため、大量の他のタイプのＤＭＬプロセス又はスレッドが実行するトランザクションはロールバックされてしまう。
【0029】
準強い同期ロックメカニズム：即ち、上記の２つのロックメカニズム（強い同期ロックメカニズム及び弱い同期ロックメカニズム）の折衷実現であり、上記の２つのロックメカニズムは何れも著しい長所と短所を有するため、分散型クラスタデータベースに適用されると、大きな挑戦に面し、従って、大規模の分散型クラスタの、ユーザートラフィックに対する高性能処理にとって準強い同期ロックメカニズムの概念は非常に必要である。即ち、あるプロセス又はスレッドはあるデータリソースに対してロックを要求する場合、全てのコンピューティング機器にロック要求を送信する方式を採用するとともに、計時し始め、しばらく待った後、指定のターゲット数のコンピューティング機器のフィードバック状況（例えば、ロッキングフィードバック情報）に基づいて、ロック要求が成功したかどうかを決定し、このような準強い同期モードは、いくつかのコンピューティング機器の不応答のため、クラスタ全体の処理能力が明らかに低下して、ひいては、クラスタ全体の処理能力が無効になることがなく、あるプロセス又はスレッドが生まれつきのロックを有するため、他のＤＭＬ（一般的に、ユーザートラフィックトランザクションであり、データベースが提供するデータサービスの品質、性能を評価する重要な指標である）要求がロールバックという不当な扱いに合うこともない。
【0030】
ＤＤＬ（Ｄａｔａ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ、データ定義言語）要求：即ち、ＤＤＬステートメント操作であり、データベースにおけるデータオブジェクト（例えば、データベース、データテーブル、データ列、データインデックスなどのオブジェクト）の定義を修正する修正操作ステートメントである。
【0031】
ＤＭＬ（Ｄａｔａ Ｍａｎｉｐｕｌａｔｅ Ｌａｎｇｕａｇｅ、データ操作言語）要求：即ち、ＤＭＬステートメント操作であり、データベースに記憶されるユーザーデータを修正する操作ステートメントであり、一般的に、ユーザートラフィックトランザクションに対応し、即ち、ＤＭＬ要求は一般的にトラフィック要求、ユーザートラフィックトランザクションであり、データベースが提供するデータサービスの品質、性能を評価する重要な指標である。
【0032】
本出願の実施例はクラスタデータベース（即ち、クラスタデータベースシステム）に適用され、クラスタデータベースは中央クラスタデータベース及び分散型クラスタデータベースを含み、中央クラスタデータベースは集中化制御モジュールを有するクラスタデータベースであり、クラスタ内には、グローバルトランザクションマネージャ及びグローバルロック管理モジュールを配置するための中心ノードが設けられ、分散型クラスタデータベースは非集中化されたクラスタデータベースであり、クラスタ内には、グローバルトランザクションマネージャ及びグローバルロック管理モジュールを配置するための中心ノードがなく、クラスタ内の全てのコンピューティングノードはあるアルゴリズムでグローバルトランザクション及びグローバルロックの実現を達成する。例えば、分散型クラスタデータベースは分散型データベースシステム、分散型ビッグデータ処理システム及び類似のアーキテクチャを使用する分散型データベース管理システムである。
【0033】
クラスタデータベースには少なくとも１つのコンピューティング機器（即ち、コンピューティングノード）が含まれ、各コンピューティング機器のデータベースには複数のデータテーブルが記憶され、各データテーブルは１つ又は複数のデータ行を記憶し（記録）、各データ行は特定位置インデックスに従って配列される１組のフィールドセットから構成され、即ち、データフィールド列である。なお、コンピューティング機器のデータベースは何れかのタイプのクラスタデータベースであり、関係型データベース又は非関係型データベースのうちの少なくとも１つ、例えばＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ、構造化クエリ言語）データベース、ＭｙＳＱＬ、ＮｏＳＱＬ、ＮｅｗＳＱＬ（一般的に、各種新規の拡張可能／高性能データベース）などを含み、本出願の実施例においてデータベースのタイプを具体的に限定しない。
【0034】
いくつかの実施例において、本出願の実施例はさらに、ブロックチェーン技術によるデータベースシステム（以下、「ブロックチェーンシステム」と略称される）に適用でき、上記のブロックチェーンシステムは本質に、非集中化された分散型データベースシステムであり、コンセンサスアルゴリズムを利用してブロックチェーン上の異なるコンピューティング機器に記載される台帳データの一致を保持し、暗号化アルゴリズムによって異なるコンピューティング機器の間の台帳データの暗号化伝送及び改ざん不能を保証し、スクリプトシステムによって台帳機能を拡張し、ネットワークルーティングによって異なるコンピューティング機器の間を互いに接続する。
【0035】
ブロックチェーンシステムには１本又は複数本のブロックチェーンが含まれ、ブロックチェーンは暗号化方法で生成された関連付けられる一連のデータブロックであり、各データブロックには１バッチのネットワークトランザクションの情報が含まれることで、その情報の有効性（偽物防止）を検証して次のブロックを生成する。
【0036】
ブロックチェーンシステムにおいてコンピューティング機器の間はピアツーピア（Ｐｅｅｒ Ｔｏ Ｐｅｅｒ、Ｐ２Ｐ）ネットワークを構成し、Ｐ２Ｐプロトコルはトランスミッションコントロールプロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、ＴＣＰ）上で運転されるアプリケーション層プロトコルである。ブロックチェーンシステムにおいて、何れか１つのコンピューティング機器は以下の機能を備え：１）ルーティング、コンピューティング機器が具備する基本的な機能であり、コンピューティング機器の間の通信をサポートする。２）アプリケーション、ブロックチェーンに配置され、実際のトラフィックニーズに基づいて特定のトラフィックを実現して、特定のトラフィックに関連付けられるデータを記録して台帳データを形成し、台帳データにはデジタル署名が付けられることで、データ由来を表示し、台帳データをブロックチェーンシステムにおける他のコンピューティング機器に送信することで、他のコンピューティング機器は台帳データの由来及び完全性を成功的に検証した場合、台帳データを一時的なブロックに追加し、アプリケーションによって実現されるトラフィックはウォレット、共有台帳、スマートコントラストなどを含む。３）ブロックチェーン、時間順序に従って互いに接続される一連のブロックを含み、新たなブロックはブロックチェーンに追加されると、削除されることがなく、ブロックには、ブロックチェーンシステムにおけるコンピューティング機器から提出された台帳データが記録される。
【0037】
いくつかの実施例において、各ブロックは、当該ブロックのトランザクション記録を記憶するためのハッシュ値（当該ブロックのハッシュ値）及び前のブロックのハッシュ値を含み、各ブロックはハッシュ値接続によってブロックチェーンを形成し、また、ブロックは、ブロックを生成した時のタイムスタンプなどの情報をさらに含む。
【0038】
以下、本出願の実施例のシステムアーキテクチャを説明する。
【0039】
図１は、本出願の実施例が提供する要求処理方法の実施環境の概略図である。図１を参照し、クラスタデータベースが分散型クラスタデータベースであることを例として説明し、分散型クラスタデータベースシステムはアプリケーションクライアント１０１、ゲートウェイサーバー１０２及び分散型記憶クラスタ１０３を含み、分散型記憶クラスタ１０３は１つ又は複数のコンピューティング機器を含む。
【0040】
アプリケーションクライアント１０１はユーザー側の端末に搭載されて実行され、データ要求を開始できるクライアントであり、当該データ要求はＤＤＬ要求又はＤＭＬ要求などであってもよく、本出願の実施例はこれに対して具体的に限定しない。任意選択で、アプリケーションクライアント１０１のタイプは決済アプリケーション、ソーシャルアプリケーション、音・ビデオアプリケーション、ライブ配信アプリケーション、通販アプリケーション、デリバリーアプリケーション又はタクシーアプリケーションなどを含むが、これらに限定されず、本出願の実施例はアプリケーションクライアント１０１のタイプを具体的に限定しない。いくつかの実施例において、ユーザー側の端末はユーザー機器、端末機器、ユーザー端末、モバイル端末、スマート端末、通信機器などとも呼ばれる。任意選択で、端末機器のタイプは、スマートフォン、タブレット、ノートパソコン、デスクトップコンピュータ、スマートスピーカー、スマートウォッチ、車載端末、スマートアプライアンス、スマート音声インタラクション機器などを含むが、これらに限定されない。
【0041】
アプリケーションクライアント１０１とゲートウェイサーバー１０２との間は有線又は無線の通信方式で直接又は間接的に接続され、これに対して本出願は限定しない。
【0042】
ゲートウェイサーバー１０２は外部のデータ要求を受信して、データ要求に対応する読み書きトランザクションを分散型記憶クラスタ１０３に配信する。概略的に、ユーザーは端末でアプリケーションクライアント１０１にログインして、ＤＤＬ要求を生成するようにアプリケーションクライアント１０１をトリガーして、例えば、ＤＤＬ要求はデータテーブルＡのテーブル名称を修正し、アプリケーションクライアント１０１は当該ＤＤＬ要求をゲートウェイサーバー１０２に送信するように分散型クラスタデータベースシステムが提供したＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ、アプリケーションプログラミングインターフェース）を呼び出して、例えば、当該ＡＰＩはＭｙＳＱＬＡＰＩ（関係型データベースシステムが提供するＡＰＩ）である。また、例えば、スマート交通シナリオで、駐車スペース追加の要求はＤＤＬ要求であり、既存の駐車スペースを検索する要求はＤＭＬ要求である。
【0043】
いくつかの実施例において、当該ゲートウェイサーバー１０２は同一の物理マシンで分散型記憶クラスタ１０３における何れか１つのコンピューティング機器と結合し、即ち、分散型記憶クラスタ１０３におけるあるコンピューティング機器をゲートウェイサーバー１０２とする。
【0044】
分散型記憶クラスタ１０３は１つ又は複数のコンピューティング機器を含み、一部のデータ要求、例えばＤＤＬ要求に対して、ＤＤＬ要求を実行する場合、当該ＤＤＬ要求にグローバルなロックを追加することで、ＤＤＬ要求に対応するＤＤＬトランザクションの操作の正確さを保証する必要がり、ＤＤＬ要求を処理するコンピューティング機器は第１のコンピューティング機器と呼ばれ、第１のコンピューティング機器以外の他のコンピューティング機器は第２のコンピューティング機器と呼ばれる。任意選択で、第１のコンピューティング機器と第２のコンピューティング機器との区別は異なるＤＤＬ要求を対象とし、第２のコンピューティング機器の数は１つ又は複数であってもよく、本出願の実施例は分散型記憶クラスタ１０３におけるコンピューティング機器の数を具体的に限定しなく、例えば、コンピューティング機器の数はｍ個であり、ｍは１以上の整数である。
【0045】
任意選択で、各コンピューティング機器はマスター／スレーブ構成（即ち、１マスター／多スレーブクラスタ）を採用し、図１に示すように、コンピューティング機器は１マスター／２スレーブクラスタであることを例として説明し、各コンピューティング機器は１つのマスター機器及び２つのスレーブ機器を含み、任意選択で、各マスター機器又はスレーブ機器には何れも対応するようにプロキシ（Ａｇｅｎｔ）機器が配置されており、プロキシ機器とマスター機器又はスレーブ機器とは物理的に独立してもよく、無論、プロキシ機器はさらにマスター機器又はスレーブ機器のプロキシモジュールとしてもよく、コンピューティング機器１を例とし、コンピューティング機器１は１つのマスターデータベース及びプロキシ機器（マスターｄａｔａｂａｓｅ＋ａｇｅｎｔ、マスターＤＢ＋ａｇｅｎｔと略称され）を含むとともに、２つのスレーブデータベース及びプロキシ機器（スレーブｄａｔａｂａｓｅ＋ａｇｅｎｔ、スレーブＤＢ＋ａｇｅｎｔと略称される）を含む。
【0046】
例示的なシナリオにおいて、各コンピューティング機器に対応するマスター機器又はスレーブ機器のデータベースインスタンスセットは１つのＳＥＴ（セット）と呼ばれ、例えば、あるコンピューティング機器はスタンドアロン機器であれば、当該コンピューティング機器のＳＥＴは当該スタンドアロン機器のデータベースインスタンスであり、あるコンピューティング機器は１マスター／２スレーブクラスタであれば、当該コンピューティング機器のＳＥＴはマスター機器データベースインスタンス及び２つのスレーブ機器データベースインスタンスのセットである。
【0047】
いくつかの実施例において、上記のゲートウェイサーバー１０２及び分散型記憶クラスタ１０３からなる分散型クラスタデータベースシステムは、ユーザー端末にデータサービスを提供するサーバーとみなされ、当該サーバーは独立する物理サーバーであってもよいし、複数の物理サーバーからなるサーバークラスタ又は分散型システムであってもよいし、さらにクラウドサービス、クラウドデータベース、クラウドコンピューティング、クラウド関数、クラウド記憶、ネットワークサービス、クラウド通信、ミドルウェアサービス、ドメイン名サービス、セキュリティーサービス、ＣＤＮ（Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ、コンテンツデリバリーネットワーク）、ビッグデータ及び人工智能プラットフォームなどの基礎クラウドコンピューティングサービスを提供するクラウドサーバーであってもよい。
【0048】
以下、クラスタデータベースが分散型クラスタデータベースであることを例として、本出願の実施例が提供するロック同期メカニズムモデルを紹介し、図２は本出願の実施例が提供するロック同期メカニズムモデルの原理概略図であり、２００に示すように、分散型クラスタデータベースは第１のコンピューティング機器及び３つの第２のコンピューティング機器Ａ、Ｂ、Ｃを含み、第１のコンピューティング機器はある時点で１つのＤＤＬ要求を受信すると仮定し、当該ＤＤＬ要求は分散型クラスタデータベースにおいてロッキングした場合に限り、操作の正確さを保証できる。強い同期モードを例として、強い同期モードで、第１のコンピューティング機器及び第２のコンピューティング機器Ａ、Ｂ、Ｃで何れも当該ＤＤＬ要求に対応するデータリソースのロックを要求し、全てのコンピューティング機器が何れもロックを成功的に要求した後、ＤＤＬ要求の処理論理を実行し、即ち、対応するＤＤＬトランザクションを完成して、第１のコンピューティング機器は当該ＤＤＬ要求のロックを解除するとともに、当該ＤＤＬ要求のロックを解除するように、第２のコンピューティング機器Ａ、Ｂ、Ｃに通知する。以下、ロック同期フロー全体を詳しく説明する：
ステップ１：第１のコンピューティング機器はＤＤＬ要求を処理し始める。
ステップ２：第１のコンピューティング機器はＤＤＬ準備を行って、例えば、ロカールで、ロッキングを必要とするデータリソースに対してロカールロック要求を完成する。
ステップ３：第１のコンピューティング機器はロッキングモジュール又はロッキング関数によって、第２のコンピューティング機器Ａ、Ｂ、Ｃにロッキング要求をそれぞれ送信し、第２のコンピューティング機器Ａ、Ｂ、Ｃはそれぞれ当該ロッキング要求を処理して、第１のコンピューティング機器にロッキングフィードバック情報を戻す。
ステップ４：第１のコンピューティング機器はＤＤＬ処理論理を実行し、例えば、ＤＤＬ要求に対応するＤＤＬトランザクションを実行する。
ステップ５：第１のコンピューティング機器はロック解除モジュール又はロック解除関数によって、第２のコンピューティング機器Ａ、Ｂ、Ｃにロック解除要求をそれぞれ送信し、第２のコンピューティング機器Ａ、Ｂ、Ｃはそれぞれ当該ロック解除要求を処理して、第１のコンピューティング機器にロック解除フィードバック情報を戻す。
ステップ６：第１のコンピューティング機器はＤＤＬ要求の処理プロセス（ＤＤＬプロセスと略称される）を終了する。
ステップ１：第１のコンピューティング機器はＤＤＬ要求を処理し始める。
ステップ２：第１のコンピューティング機器はＤＤＬ準備を行って、例えば、ロカールで、ロッキングを必要とするデータリソースに対してロカールロック要求を完成する。
ステップ３：第１のコンピューティング機器はロッキングモジュール又はロッキング関数によって、第２のコンピューティング機器Ａ、Ｂ、Ｃにロッキング要求をそれぞれ送信し、第２のコンピューティング機器Ａ、Ｂ、Ｃはそれぞれ当該ロッキング要求を処理して、第１のコンピューティング機器にロッキングフィードバック情報を戻す。
ステップ４：第１のコンピューティング機器はＤＤＬ処理論理を実行し、例えば、ＤＤＬ要求に対応するＤＤＬトランザクションを実行する。
ステップ５：第１のコンピューティング機器はロック解除モジュール又はロック解除関数によって、第２のコンピューティング機器Ａ、Ｂ、Ｃにロック解除要求をそれぞれ送信し、第２のコンピューティング機器Ａ、Ｂ、Ｃはそれぞれ当該ロック解除要求を処理して、第１のコンピューティング機器にロック解除フィードバック情報を戻す。
ステップ６：第１のコンピューティング機器はＤＤＬ要求の処理プロセス（ＤＤＬプロセスと略称される）を終了する。
【0049】
上記の過程から分かるように、第１のコンピューティング機器にロッキングモジュール又はロッキング関数を追加すれば、あるＤＤＬ要求のロックが当該クラスタ内の他の第２のコンピューティング機器に同期されることを保証でき、例えば、各第２のコンピューティング機器はロッキング要求を受信した後、ロカールでロックを要求して、ロッキングフィードバック情報を、ロックを要求する遠位ノード（即ち、第１のコンピューティング機器）に戻し、また、ロック解除過程もロック所有側（即ち、ロッキング要求を開始する第１のコンピューティング機器）から、ロック解除要求を当該クラスタ内の他の第２のコンピューティング機器に送信し、各第２のコンピューティング機器はロック解除要求を受信した後、対応するロックをロカールで解除して、ロック解除フィードバック情報を遠位ノード（即ち、第１のコンピューティング機器）に戻す。
【0050】
上記の実施例において、ロック同期メカニズムモデルの大体のフレームを簡単に紹介し、本出願の実施例において、ロッキング過程中の第１のコンピューティング機器の各操作を説明し、図３は本出願の実施例が提供する要求処理方法のフローチャートである。図３を参照し、当該実施例はクラスタデータベースにおける第１のコンピューティング機器によって実行され、当該実施例は以下のステップを含む：
３０１：第１のコンピューティング機器はデータ要求に応答して、クラスタデータベースのロック同期モードを決定する。
３０１：第１のコンピューティング機器はデータ要求に応答して、クラスタデータベースのロック同期モードを決定する。
【0051】
任意選択で、クラスタデータベースは中央クラスタデータベース、又は分散型クラスタデータベースであり、何れも当該要求処理方法に適用でき、本出願の実施例において、分散型クラスタデータベースのみを例として説明する。クラスタデータベースは第１のコンピューティング機器及び第２のコンピューティング機器を含み、第１のコンピューティング機器は当該データ要求を処理するコンピューティング機器であり、クラスタ内の第１のコンピューティング機器を除いた全てのコンピューティング機器は第２のコンピューティング機器と呼ばれる。
【0052】
いくつかの実施例において、ユーザーは端末でアプリケーションクライアントにログインし、当該データ要求を生成するようにアプリケーションクライアントをトリガーし、任意選択で、当該データ要求はデータ定義言語ＤＤＬ要求、又はデータ操作言語ＤＭＬ要求であり、本出願の実施例において、データ要求がＤＤＬ要求であることを例として説明し、例えば、ＤＤＬ要求はデータテーブルＡのテーブル名称を修正することである。データ要求を生成した後、アプリケーションクライアントは当該データ要求を当該第１のコンピューティング機器に送信するように、ＡＰＩを呼び出す。
【0053】
いくつかの実施例において、第１のコンピューティング機器は当該データ要求を受信し、当該データ要求のヘッドフィールドを解析し、当該ヘッドフィールドは当該データ要求が指定タイプの要求、例えばＤＤＬ要求であることを指示する場合、当該クラスタデータベースのロック同期モードを決定する。
【0054】
いくつかの実施例において、当該ロック同期モードは、データベースシステム（又はデータベースエンジン）に配置されるロック同期モードパラメータｌｏｃｋ＿ｌｅｖｅｌ＿ｍｏｄｅによって指示され、ロック同期モードパラメータｌｏｃｋ＿ｌｅｖｅｌ＿ｍｏｄｅはクラスタデータベースが所在しているロック同期モードを表し、当該ロック同期モードは強い同期モード（Ｓｔｒｏｎｇ）、準強い同期モード（Ｍｉｄｄｌｅ）及び弱い同期モード（Ｆｅａｋ）を含むが、これらに限定されない。第１のコンピューティング機器は、配置ファイルからロック同期モードパラメータｌｏｃｋ＿ｌｅｖｅｌ＿ｍｏｄｅの値を検索し、ロック同期モードパラメータｌｏｃｋ＿ｌｅｖｅｌ＿ｍｏｄｅ ＝ Ｓｔｒｏｎｇであれば、当該ロック同期モードを強い同期モードに決定し、ロック同期モードパラメータｌｏｃｋ＿ｌｅｖｅｌ＿ｍｏｄｅ ＝ Ｍｉｄｄｌｅであれば、当該ロック同期モードを準強い同期モードに決定し、ロック同期モードパラメータｌｏｃｋ＿ｌｅｖｅｌ＿ｍｏｄｅ ＝ Ｆｅａｋであれば、当該ロック同期モードを弱い同期モードに決定する。
【0055】
いくつかの実施例において、上記の当該ロック同期モードパラメータｌｏｃｋ＿ｌｅｖｅｌ＿ｍｏｄｅは当該配置ファイルに追加され、クラスタデータベースが起動すると、クラスタ内の各コンピューティング機器のデータベースエンジンには何れも当該配置ファイルがロードされる。
【0056】
いくつかの実施例において、クラスタ全体が運転する時、当該ロック同期モードパラメータｌｏｃｋ＿ｌｅｖｅｌ＿ｍｏｄｅはコンピューティング機器によってランダムに修正されてもよく、ロック同期モードパラメータｌｏｃｋ＿ｌｅｖｅｌ＿ｍｏｄｅを修正した後、コンピューティング機器は自動に修正後のロック同期モードパラメータｌｏｃｋ＿ｌｅｖｅｌ＿ｍｏｄｅをクラスタ内の全てのコンピューティング機器に同期させる。
【0057】
いくつかの実施例において、第１のコンピューティング機器は当該ロック同期モードを弱い同期モードに決定した場合、以下のステップ３０２を実行し、第１のコンピューティング機器は当該ロック同期モードを強い同期モード又は準強い同期モードに決定した場合、以下のステップ３０３～３０４を実行する。
【0058】
他のいくつかの実施例において、第１のコンピューティング機器はロカールで、ロッキングを必要とするデータリソースに対してロカールロック要求を完成してから、ロッキングフローに進み、そして、当該ロック同期モードが弱い同期モードであるかどうかを判定し、当該ロック同期モードが弱い同期モードであれば、以下のステップ３０２を実行し、当該ロック同期モードが弱い同期モードではなければ、以下のステップ３０３～３０４を実行する。
【0059】
３０２：当該ロック同期モードが弱い同期モードである場合、第１のコンピューティング機器は当該データ要求に対応するデータリソースをロッキングして、当該データ要求を実行する。
【0060】
当該ロック同期モードが弱い同期モードであれば、第１のコンピューティング機器は現在のデータ要求、例えばＤＤＬ要求を直接的に推進でき、他の第２のコンピューティング機器にロックを要求する必要がない。なお、操作の正確さは特定メカニズムＷｒｉｔｉｎｇ Ｆｅｎｃｅ（書き込みバリア）によって保証される。上記のメカニズムによって、マルチコアマルチスレッド環境において、ある時点で１つのスレッドのみがクリティカルセクションコードに入ることができることを保証し、クリティカルセクションにおける操作データの一致性を保証する。
【0061】
ここで、本出願の実施例に係る「ロック」は、メモリにおける１つのメモリ状態パラメータであり、例えば、当該メモリ状態パラメータは整数であってもよく、当該メモリ状態パラメータはデータリソースに関連し、関連のデータリソースをロッキングするかどうかを示す。
【0062】
任意選択で、当該メモリ状態パラメータは、アイドル状態及びロック済み状態という２つの状態を含む。ロッキングする時、ロックがアイドルであるかどうかを判定し、アイドルであれば、ロック済み状態に修正するとともに、自体がロック所有側に変換し、ロック要求成功を戻し、既にロックされている場合、ロック要求失敗を戻す。ロックを解除する時、ロック済み状態をアイドル状態に修正する。
【0063】
任意選択で、当該メモリ状態パラメータは、アイドル状態、読み取りロック（即ち、共有ロック、Ｓロック）、書き込みロック（即ち、排他ロック、Ｘロック）及び更新ロックという２つ以上の状態を含み、読み取りロック、書き込みロック及び更新ロックは、ロック済み状態で他のＤＭＬ要求の、ロッキングされたデータリソースに対する実行可能な操作を区別し、例えば、あるＤＤＬ要求はユーザーテーブルＴ１にＴ１＿ｌｏｃｋを追加し、Ｔ１＿ｌｏｃｋは読み取りロックであれば、他のＤＭＬ要求はユーザーテーブルＴ１に対して書き込み操作を実行できないが、依然的に、ユーザーテーブルＴ１におけるデータ項を正常に読み取ることができる。
【0064】
弱い同期モードで、書き込みバリアメカニズムの保証のため、第１のコンピューティング機器はロカールでロックを成功的に要求した後、直接にロックを取得したとみなしてもよく、即ち、第１のコンピューティング機器はロック所有側に変換し、他の各第２のコンピューティング機器にロッキング要求を送信する必要がなく、当該データ要求に対応するデータリソースを成功的にロッキングしたと決定し、ロッキングフローが終了し、そして、当該データ要求に対応するデータベーストランザクションを実行すればよく、例えば、ＤＤＬスレッドによってＤＤＬ要求に対応するＤＤＬトランザクションを実行する。
【0065】
３０３：当該ロック同期モードが弱い同期モードではない場合、第１のコンピューティング機器は、当該クラスタデータベースにおける少なくとも１つの第２のコンピューティング機器の、当該データリソースに対するロッキングフィードバック情報を取得し、当該ロッキングフィードバック情報は、当該第２のコンピューティング機器の、当該データリソースに対するロッキングが成功したかどうかを表す。
【0066】
ロック同期モードは弱い同期モードではなければ、強い同期モード又は準強い同期モードである可能性があり、上記の強い同期モード又は準強い同期モードで、第１のコンピューティング機器は遠位の各第２のコンピューティング機器にロックを要求し、２つのモードによる、ロック要求の成功を判定するためのターゲット条件が異なり、強い同期モードで、全ての第２のコンピューティング機器が何れもロックを成功的に要求した場合に限り、当該データリソースに対するロックのグローバル要求が成功したとみなし、準強い同期モードで、ターゲット数以上の第２のコンピューティング機器がロックを成功的に要求すれば、当該データリソースに対するロックのグローバル要求が成功したとみなす。
【0067】
いくつかの実施例において、第１のコンピューティング機器は各第２のコンピューティング機器にロックを要求して、各第２のコンピューティング機器のロッキングフィードバック情報を取得し、任意選択で、当該ロッキングフィードバック情報はロッキング成功及びロッキング失敗を含み、通常、ロッキング失敗の原因は多様であり、例えば、待機がタイムアウトし、デッドロックに達するなどがある。
【0068】
いくつかの実施例において、上記の各第２のコンピューティング機器にロックを要求する過程は、第１のコンピューティング機器は当該少なくとも１つの第２のコンピューティング機器に、当該データ要求に関連付けられるロッキング要求を送信するステップと、第１のコンピューティング機器は、当該ロッキング要求に基づいて当該少なくとも１つの第２のコンピューティング機器から戻された当該ロッキングフィードバック情報を受信するステップと、を含む。
【0069】
任意選択で、第１のコンピューティング機器及び各第２のコンピューティング機器において、何れもバックグラウンドでメッセージ処理スレッドを確立し、当該メッセージ処理スレッドはロックメカニズムに関する各種のメッセージを専門に処理し、例えば、他のコンピューティング機器のロッキング要求、ロック解除要求、ロッキングフィードバック情報、ロック解除フィードバック情報などを監視して、ロックメカニズムに関する各種のメッセージを即時に送受信することで、コンピューティング機器の間の通信性能を保障する。
【0070】
上記の状況に基づいて、ロッキング要求を送信する場合、第１のコンピューティング機器はそのメッセージ処理スレッドによって、当該少なくとも１つの第２のコンピューティング機器上のメッセージ処理スレッドに当該ロッキング要求を送信し、同じく、ロッキングフィードバック情報を受信する場合、第１のコンピューティング機器は当該第１のコンピューティング機器のメッセージ処理スレッドによって、当該少なくとも１つの第２のコンピューティング機器上のメッセージ処理スレッドから戻された当該ロッキングフィードバック情報を受信する。第２のコンピューティング機器のロック要求フローについて、次の実施例において詳しく記載し、ここで、贅言しない。
【0071】
いくつかの実施例において、第１のコンピューティング機器はクラスタ内の各第２のコンピューティング機器にそれぞれ当該ロッキング要求を送信し、各第２のコンピューティング機器のロッキングフィードバック情報が第１のコンピューティング機器に戻る時間は異なっている可能性があり、いくつかの例示的なシナリオにおいて、第１のコンピューティング機器で当該データ要求の処理プロセス（例えば、ＤＤＬプロセス）がクラッシュした場合、当該ＤＤＬプロセスがクラッシュした後、受信したロッキングフィードバック情報に対して、第１のコンピューティング機器は状況に応じて対応するロックを解除するように、ロッキングが成功した第２のコンピューティング機器に即時に指示して、当該データリソース上の他のＤＭＬプロセスをブロッキングすることを回避し、クラスタデータベースの処理性能を最適化する。
【0072】
上記の状況について、第１のコンピューティング機器は何れか１つの第２のコンピューティング機器のロッキングフィードバック情報を受信したことに応答し、当該データ要求がアクティブ状態にある場合、当該メッセージ処理スレッドによって当該ロッキングフィードバック情報を当該データ要求のロック要求スレッドに送信し、当該データ要求が非アクティブ状態にあり、且つ当該ロッキングフィードバック情報が、ロッキング成功を表す場合、当該第２のコンピューティング機器にロック解除要求を送信し、当該ロック解除要求は当該データ要求に対応するデータリソースを解除するように、当該第２のコンピューティング機器に指示する。
【0073】
任意選択で、メッセージ処理スレッドによって何れか１つのロッキングフィードバック情報を受信した後、第１のコンピューティング機器はロカールの当該データ要求がアクティブであるかどうかを判定し、ＤＤＬ要求を例として、ＤＤＬ要求に対応するＤＤＬプロセスが存在するかどうかを判定し、複数のＤＤＬ要求が同一ＤＤＬプロセスを多重利用される状況が存在する可能性があるため、現在のＤＤＬ要求が失敗した（例えば、ターゲット条件を満たしておらず、ＤＤＬトランザクションはロールバックされる）場合でも、ＤＤＬプロセスは依然的に存在する可能性があり、従って、ＤＤＬプロセスに対してＤＤＬ要求がアクティブであるかどうかを判定することは、一定の誤判定の状況が存在する恐れがある。任意選択で、直接的に、ＤＤＬ要求に対応するＤＤＬトランザクションがアクティブ状態にあるかどうかを判定してもよく、これによって、上記の誤判定の状況を効果的に低減して、判定精度を向上できる。
【0074】
当該データ要求は非アクティブであり、即ち、当該データ要求は非アクティブ状態にあると、当該ロッキングフィードバック情報は、ロッキング成功を表すかどうかを判定し、当該ロッキングフィードバック情報は、ロッキング成功を表すことであれば、ロカールのＤＤＬ要求が既に終了したが、遠位の第２のコンピューティング機器でデータリソースに対応するロックを成功的に要求したことを説明し、この場合、データリソースに対応するロックを即時に解除するように、当該第２のコンピューティング機器に指示する必要がり、第１のコンピューティング機器はメッセージ処理スレッドによって当該第２のコンピューティング機器のメッセージ処理スレッドにロック解除要求を送信することで、当該データ要求に対応するデータリソースを解除するように、当該第２のコンピューティング機器に指示し、例えば、当該データリソースに対応するロックのメモリ状態パラメータをアイドル状態に修正し、また、当該ロッキングフィードバック情報は、ロッキング失敗を表すことであれば、遠位はデータリソースを即時に解除する必要がないことを示し、そうすれば、何の処理も必要としない。
【0075】
当該データ要求はアクティブであり、即ち、当該データ要求はアクティブ状態にあると、当該メッセージ処理スレッドによって当該ロッキングフィードバック情報を当該データ要求のロック要求スレッドに送信することで、ロック要求スレッドは、今回受信したロッキングフィードバック情報を記録して、以下のステップ３０４に基づいて、ターゲット条件に合うかどうかを判定し、これによって、当該ロック要求スレッドは、受信したロッキングフィードバック情報が現在ロックの同期モードに対応するターゲット条件に合うかどうかを即時に統計する。
【0076】
いくつかの実施例において、第１のコンピューティング機器はさらに、各第２のコンピューティング機器にロッキング要求を送信した後、計時し始めて、当該計時は、各ロッキングフィードバック情報に対する待ち期間を統計し、配置ファイルに、強い同期モードに対応する第１の待ち閾値及び準強い同期モードに対応する第２の待ち閾値を設置する。第１の待ち閾値は、強い同期モードでコンピューティング機器のロッキングフィードバック情報に対する最大待ち期間を表し、強い同期モードでの待ち期間が第１の待ち閾値を超えると、今回のロッキングが失敗したとみなし、ロック要求が成功した各第２のコンピューティング機器にロック解除要求を送信することで、当該データ要求に対応するデータリソースを解除するように、第２のコンピューティング機器に指示し、そして、ロッキングフローを終了する。当該第１の待ち閾値は何れかの０を超える数値、例えば、１５秒である。第２の待ち閾値は、準強い同期モードでコンピューティング機器のロッキングフィードバック情報に対する最大待ち期間を表し、準強い同期モードでの待ち期間が第２の待ち閾値を超えると、今回のロッキングが失敗したとみんし、ロック要求が成功した各第２のコンピューティング機器にロック解除要求を送信することで、当該データ要求に対応するデータリソースを解除するように第２のコンピューティング機器に指示し、そして、ロッキングフローを終了する。当該第２の待ち閾値は何れかの０を超える数値、例えば、１０秒であり、ここで、第１の待ち閾値及び第２の待ち閾値は同様であってもよいし、又は異なってもよく、これに対して本出願の実施例は限定しない。
【0077】
上記の過程で、第１の待ち閾値及び第２の待ち閾値を配置して、ロッキング要求を送信してから、計時し始めることで、第１のコンピューティング機器が長期間にわたって他の第２のコンピューティング機器のロッキングフィードバック情報を待つことを回避でき、例えば、ロッキングフィードバック情報伝送の過程でパケットロス状況が生じると、強い同期モードで第１のコンピューティング機器の待ち期間は最大、第１の待ち閾値に達し、準強い同期モードでの待ち期間は最大、第２の待ち閾値に達する場合、以降の他のデータ要求の処理を推進でき、クラスタデータベースの性能を向上できる。
【0078】
３０４：取得した当該ロッキングフィードバック情報が、当該ロック同期モードに対応するターゲット条件を満たしている場合、第１のコンピューティング機器は当該データ要求に対応するデータリソースをロッキングして、当該データ要求を実行する。
【0079】
ロック同期モードに対応するターゲット条件は、取得したロッキングフィードバック情報に基づいて、データ要求に対応するデータリソースをロッキングするかどうかを判定する条件であり、一般的に、強い同期モードに対応するターゲット条件は、準強い同期モードに対応するターゲット条件要求よりも高い。
【0080】
いくつかの実施例において、クラスタデータベースにタイムアウトメカニズムが配置されていないと、当該ロック同期モードが強い同期モードである場合、当該ターゲット条件は、当該少なくとも１つの第２のコンピューティング機器のロッキングフィードバック情報が何れもロッキング成功を表すことであり、当該ロック同期モードが準強い同期モードである場合、当該ターゲット条件は、当該少なくとも１つの第２のコンピューティング機器のうちの、ターゲット数以上の第２のコンピューティング機器のロッキングフィードバック情報がロッキング成功を表すことである。
【0081】
いくつかの実施例において、クラスタデータベースにタイムアウトメカニズムが配置されていると、上記の基本的な条件を満たす必要がある上に、強い同期モードでの待ち期間が第１の待ち閾値の以下であり、準強い同期モードでの待ち期間が第２の待ち閾値の以下であることを保証する必要があり、即ち、当該ロック同期モードが強い同期モードである場合、当該ターゲット条件は、待ち期間が第１の待ち閾値の以下であり、且つ当該少なくとも１つの第２のコンピューティング機器のロッキングフィードバック情報が何れもロッキング成功を表すことであり、当該ロック同期モードが準強い同期モードである場合、当該ターゲット条件は、待ち期間が第２の待ち閾値の以下であり、且つ当該少なくとも１つの第２のコンピューティング機器のうちの、ターゲット数以上の第２のコンピューティング機器のロッキングフィードバック情報がロッキング成功を表すことである。当該第１の待ち閾値及び第２の待ち閾値は何れも０超えの数値であり、当該第１の待ち閾値及び第２の待ち閾値は何れも配置ファイルに追加可能であり、クラスタデータベースが起動される場合、各コンピューティング機器のデータベースエンジンからロードされる。
【0082】
いくつかの実施例において、当該ターゲット数はデータベースエンジンに配置されるロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍによって指示され、ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍは、準強い同期モードで、クラスタデータベースにおけるいくつかのコンピューティング機器がロックを成功に要求した場合、グローバルロック要求が成功したとみなすか、ということを表し、任意選択で、ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍはターゲット数に１を加算することで取得した数値であり、ターゲット数は、ロック要求が成功する第２のコンピューティング機器の数を示し、ターゲット数に第１のコンピューティング機器自体を加算すると、クラスタ内の必要な、ロック要求が成功するコンピューティング機器の総数である。ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍの有効値範囲は１以上、且つクラスタ内の全てのコンピューティング機器の数の以下であり、ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍは１より小さいか、又はクラスタ内の全てのコンピューティング機器の数を超えると、クラスタのロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍは有効値範囲内に位置しておらず、何れも強い同期モード又は弱い同期モード（管理者が設定する）を採用することで、ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍが非合法である場合、クラスタの正常な運転を保証し、例えば、何れも強い同期モードを採用する。
【0083】
任意選択で、当該ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍは配置ファイルに追加されてもよく、クラスタデータベースが起動される場合、クラスタ内の各コンピューティング機器のデータベースエンジンは何れも当該配置ファイルをロードする。
【0084】
任意選択で、クラスタ全体が運転する時、当該ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍはコンピューティング機器によってランダムに修正されてもよく、ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍを修正した後、コンピューティング機器は自動的に修正後のロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍをクラスタ内の全てのコンピューティング機器に同期させる。
【0085】
いくつかの実施例において、当該ロック同期モードが準強い同期モードである場合、第１のコンピューティング機器は当該ターゲット数を取得し、当該ターゲット数が１より小さいか、又は当該クラスタデータベースにおける全ての第２のコンピューティング機器の数を超えた場合、当該ロック同期モードを当該強い同期モードに切り替える。
【0086】
上記の過程で、第１のコンピューティング機器は配置ファイルから当該ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍの値を検索して、当該ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍの値から１を引くことで取得した数値を当該ターゲット数に決定する。さらに、当該ターゲット数が合法であるかどうかを判定し、即ち、当該ターゲット数が１以上、且つ当該クラスタデータベースにおける全ての第２のコンピューティング機器の数の以下であれば、当該ターゲット数が合法であることを説明し、そうすれば、当該ロック同期モードは準強い同期モードに従って判定ターゲット条件を判定し、当該ターゲット数が１より小さいか、又は当該クラスタデータベースにおける全ての第２のコンピューティング機器の数を超えた場合、当該ターゲット数が非合法であることを説明し、そうすれば、当該ロック同期モードを強い同期モードに強制的に切り替える。いくつかの実施例において、ロック同期モードを弱い同期モードに強制的に切り替えてもよく、これに対して本出願の実施例は限定しない。
【0087】
他のいくつかの実施例において、配置ファイルから当該ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍの値を検索した後、第１のコンピューティング機器は当該ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍの値が合法であるかどうかを判定し、ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍが合法であれば（即ち、１以上、且つクラスタ内の全てのコンピューティング機器の数の以下）、当該ターゲット数も合法であることを示し、ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍが非合法であれば（即ち、１より小さいか、又はクラスタ内の全てのコンピューティング機器の数を超える）、当該ターゲット数も非合法であることを示し、ロック同期モードを強い同期モード又は弱い同期モードに強制的に切り替える必要があり、本出願の実施例において、ロック同期モードを強い同期モードに切り替えることを例として説明する。
【0088】
いくつかの実施例において、ロック同期モードパラメータｌｏｃｋ＿ｌｅｖｅｌ＿ｍｏｄｅ≠Ｆｅａｋであれば、ロック同期モードは弱い同期モードではないことを示し、この場合、メッセージ処理スレッドによって各第２のコンピューティング機器にロッキング要求を送信して、計時し始め、メッセージ処理スレッドによって各第２のコンピューティング機器から戻されたロッキングフィードバック情報を受信する。任意選択で、ロック同期モードパラメータｌｏｃｋ＿ｌｅｖｅｌ＿ｍｏｄｅ＝Ｓｔｒｏｎｇであれば、当該ロック同期モードを強い同期モードに決定し、全ての第２のコンピューティング機器のロッキングフィードバック情報が何れもロッキング成功を表すかどうかを判定し、この場合、３つの状況に分けて議論する：１）待ちがまだタイムアウトされず、即ち、待ち期間が第１の待ち閾値の以下であり、且つ受信した全ての第２のコンピューティング機器のロッキングフィードバック情報が何れもロッキング成功を表すと、ターゲット条件に合って、グローバルロッキングが成功したとみなす。２）受信した何れか１つの第２のコンピューティング機器のロッキングフィードバック情報がロッキング失敗を表すと、ターゲット条件に合わなく、グローバルロッキングが失敗したとみなす。３）待ち期間が第１の待ち閾値を超えた時、第２のコンピューティング機器が依然的にロッキングフィードバック情報を戻していないと、待ちが既にタイムアウトしたことを示し、ターゲット条件に合わなく、グローバルロッキングが失敗したとみなす。
【0089】
任意選択で、ロック同期モードパラメータｌｏｃｋ＿ｌｅｖｅｌ＿ｍｏｄｅ＝Ｍｉｄｄｌｅであれば、ロック同期モードを準強い同期モードに決定し、配置ファイルからロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍを読み取って、ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍが合法であるかどうかを判定し、ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍが１以上、且つクラスタ内の全てのコンピューティング機器の数の以下であり、即ち、ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍが合法であれば、準強い同期モードに従って継続的に処理し、ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍが１より小さいか、又はクラスタ内の全てのコンピューティング機器の数を超えた場合、強い同期モードに従って継続的に処理する。準強い同期モードで、同じように３つの状況に分けて議論する：Ａ）待ちがまだタイムアウトされず、即ち、待ち期間が第２の待ち閾値の以下であり、且つ受信したロッキングフィードバック情報は、ロッキングが成功した第２のコンピューティング機器の数がターゲット数の以上であることを表すことであれば、ターゲット条件に合って、グローバルロッキングが成功したとみなし、別の可能な実施形態において、受信したロッキングフィードバック情報は、ロッキングが成功した第２のコンピューティング機器の数に１を加算することで取得した数値がロッキング成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍの以上であることを表すことであれば、同じように、ターゲット条件に合うと判定し、グローバルロッキングが成功したとみなす。Ｂ）受信したロッキングフィードバック情報は、ロッキングが失敗した第２のコンピューティング機器の数がクラスタ内の全ての第２のコンピューティング機器の数から当該ターゲット数を引くことで取得した数値を超えたことを表すことであれば、ターゲット条件に合わなく、グローバルロッキングが失敗したとみなす。別の可能な実施形態において、受信したロッキングフィードバック情報は、ロッキングが失敗した第２のコンピューティング機器の数に１を加算することで取得した数値が、クラスタ内の全てのコンピューティング機器からロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍを引くことで取得した数値を超えたことを表すことであれば、同じように、ターゲット条件に合わないと判定し、グローバルロッキングが失敗したとみなす。Ｃ）待ち期間が第２の待ち閾値を超えた時でも、多くの第２のコンピューティング機器が依然的にロッキングフィードバック情報を戻しておらず、状況Ａ）でも、状況Ｂ）でも何れも満たしていなければ、待ちが既にタイムアウトしたことを示し、そうすれば、ターゲット条件に合わなく、グローバルロッキングが失敗したとみなす。
【0090】
いくつかの実施例において、取得したロッキングフィードバック情報がターゲット条件に合うと判定した場合、上記のステップ３０２に類似する操作を実行し、即ち、当該データ要求に対応するデータリソースをロッキングして、当該データ要求を実行し、ここで贅言しない。
【0091】
いくつかの実施例において、取得したロッキングフィードバック情報が当該ターゲット条件に合わないか、又は当該データ要求が実行完了した場合、当該少なくとも１つの第２のコンピューティング機器にロック解除要求を送信し、当該ロック解除要求は当該データ要求に対応するデータリソースを解除するように、当該第２のコンピューティング機器に指示する。
【0092】
上記の過程で、取得したロッキングフィードバック情報がターゲット条件に合わないと、グローバルロッキングが失敗しているが、現在データ要求がいくつかの第２のノード機器で既にロックを成功的に要求した可能性もあり、従って、第１のコンピューティング機器は、ロッキングフィードバック情報がロッキング成功を表す各第２のコンピューティング機器にロック解除要求を即時に送信することで、データリソースに対応するロックを即時に解除する。任意選択で、全ての第２のコンピューティング機器に当該ロック解除要求を直接的にブロードキャストし、ロッキングが成功した第２のコンピューティング機器はデータリソースに対応するロックを解除するが、ロッキングが失敗した第２のコンピューティング機器は何の処理もしない。
【0093】
任意選択で、第１のコンピューティング機器は、各第２のコンピューティング機器がロック解除フィードバック情報を戻すまで待つ必要がなく、これは、以下の実施例の死活監視メカニズムによって保証され、システムの要求処理効率を向上し、無論、第１のコンピューティング機器は、各第２のコンピューティング機器がロック解除フィードバック情報を戻した後、ロッキングフローを完成することで、ネットワークパケットロスのため、いくつかの第２のコンピューティング機器がロック解除要求を受信していないかどうかを即時に探知してもよく、これに対して本出願の実施例は限定しない。別のシナリオで、取得したロッキングフィードバック情報がターゲット条件に合うと、第１のコンピューティング機器は、グローバルロッキングが成功して、データ要求、例えばＤＤＬ要求を実行した後、同じように、データリソースに対応するロックを即時に解除するように、他の各第２のコンピューティング機器に通知し、ロック解除要求の送信方式は上記の状況に類似するため、ここで贅言しない。
【0094】
上記の全ての好適な技術案に対して、何れも任意の組み合わせを採用して本開示の好適な実施例を形成でき、ここで、贅言しない。
【0095】
本出願の実施例が提供する方法によれば、ロック同期モードに対して柔軟な複数のレベルを設置し、弱い同期モードで、データ要求に対応するデータリソースを直接的にロッキングして、当該データ要求を実行し、データ要求を優先的に推進することを保証でき、第２のコンピューティング機器の応答を待つ必要がなく、非弱い同期モードで、各第２のコンピューティング機器のロッキングフィードバック情報を取得し、取得したロッキングフィードバック情報がターゲット条件に合う場合に限り、当該データリソースをロッキングして当該データ要求を実行し、異なるトラフィックシナリオで異なるロック同期モードを選択し、クラスタデータベースが異なるトラフィックシナリオの処理ニーズを満たすことを保証して、クラスタデータベースシステムの処理能力を向上する。
【0096】
上記の実施例において、要求処理過程で、第１のコンピューティング機器が如何にロッキング要求を開始してロッキングフィードバック情報に基づいてターゲット条件に合うかどうかを判定するかについて紹介し、本出願の実施例において、第１のコンピューティング機器及び第２のコンピューティング機器のロッキング過程中のメッセージインタラクション、及びそれぞれのロカールロッキング論理を詳しく説明する。
【0097】
図４は、本出願の実施例が提供する要求処理方法のインタラクションフローチャートであり、図４に示すように、当該実施例はクラスタデータベースに適用され、クラスタデータベースは第１のコンピューティング機器及び少なくとも１つの第２のコンピューティング機器を含み、第１のコンピューティング機器は当該データ要求を処理するコンピューティング機器であり、クラスタ内の第１のコンピューティング機器を除いた全てのコンピューティング機器は第２のコンピューティング機器と呼ばれ、当該実施例は以下のステップを含む：
４０１：アプリケーションクライアントはクラスタデータベースにおける第１のコンピューティング機器にデータ要求を送信する。
４０１：アプリケーションクライアントはクラスタデータベースにおける第１のコンピューティング機器にデータ要求を送信する。
【0098】
任意選択で、クラスタデータベースは中央クラスタデータベース、又は分散型クラスタデータベースであり、何れも当該要求処理方法に適用され、本出願の実施例は分散型クラスタデータベースを例として説明する。
【0099】
いくつかの実施例において、ユーザーは端末でアプリケーションクライアントにログインし、当該データ要求を生成するようにアプリケーションクライアントをトリガーし、任意選択で、当該データ要求はＤＤＬ要求、又はＤＭＬ要求であり、本出願の実施例においてデータ要求がＤＤＬ要求であることを例として説明し、例えば、ＤＤＬ要求はデータテーブルＡのテーブル名称を修正する。データ要求を生成した後、アプリケーションクライアントは当該データ要求を当該第１のコンピューティング機器に送信するように、ＡＰＩを呼び出す。
【0100】
４０２：第１のコンピューティング機器は当該データ要求に応答して、当該クラスタデータベースのロック同期モードを決定する。
【0101】
上記のステップ４０２は上記のステップ３０１に類似するため、ここで贅言しない。
【0102】
４０３：当該ロック同期モードが弱い同期モードである場合、第１のコンピューティング機器は当該データ要求に対応するデータリソースをロッキングして、当該データ要求を実行する。
【0103】
上記のステップ４０３は上記のステップ３０２に類似するため、ここで贅言しない。
【0104】
４０４：当該ロック同期モードが弱い同期モードではない場合、第１のコンピューティング機器は当該クラスタデータベースにおける少なくとも１つの第２のコンピューティング機器に、当該データ要求に関連付けられるロッキング要求を送信する。
【0105】
ロック同期モードが弱い同期モードではなければ、強い同期モード又は準強い同期モードである可能性があり、上記の強い同期モード又は準強い同期モードで、第１のコンピューティング機器は何れも遠位の各第２のコンピューティング機器にロックを要求する必要があり、両者の、ロック要求の成功を判定するためのターゲット条件が異なり、強い同期モードで、全ての第２のコンピューティング機器が何れもロックを成功的に要求した場合に限り、当該データリソースに対するロックのグローバル要求が成功したとみなし、準強い同期モードで、ターゲット数以上の第２のコンピューティング機器がロックを成功的に要求すれば、当該データリソースに対するロックのグローバル要求が成功したとみなす。
【0106】
いくつかの実施例において、第１のコンピューティング機器は各第２のコンピューティング機器にロックを要求して、各第２のコンピューティング機器のロッキングフィードバック情報を取得し、任意選択で、当該ロッキングフィードバック情報はロッキング成功及びロッキング失敗を含み、通常、ロッキング失敗の原因は多様であり、例えば、待機がタイムアウトし、デッドロックに達するなどがある。
【0107】
任意選択で、第１のコンピューティング機器及び各第２のコンピューティング機器において、何れもバックグラウンドでメッセージ処理スレッドを確立し、当該メッセージ処理スレッドはロックメカニズムに関する各種のメッセージを専門に処理し、例えば、他のコンピューティング機器のロッキング要求、ロック解除要求、ロッキングフィードバック情報、ロック解除フィードバック情報などを監視し、ロックメカニズムに関する各種のメッセージを即時に送受信することで、コンピューティング機器の間の通信性能を保障する。
【0108】
上記の状況に基づいて、ロッキング要求を送信する場合、第１のコンピューティング機器はそのメッセージ処理スレッドによって、当該少なくとも１つの第２のコンピューティング機器上のメッセージ処理スレッドに当該ロッキング要求を送信する。
【0109】
４０５：何れか１つの第２のコンピューティング機器に対して、当該データ要求に関連付けられるロッキング要求に応答して、当該ロッキング要求をロッキングキューに追加する。
【0110】
なお、当該ロッキング要求は、ロック同期モードが弱い同期モードではない場合、当該クラスタデータベースにおける第１のノード装置によって送信される。
【0111】
いくつかの実施例において、第２のコンピューティング機器はメッセージ処理スレッドによって当該ロッキング要求を受信し、当該メッセージ処理スレッドによって当該ロッキング要求に対応するロックプロキシスレッドを起動させ、当該ロックプロキシスレッドによって当該ロッキング要求を当該ロッキングキューに追加する。任意選択で、各ロッキング要求は１つのロックプロキシスレッドに対応することで、各ロッキング要求の待ち遅延を低減し、任意選択で、複数のロッキング要求は同一ロックプロキシスレッドを多重利用し、後に到達したロッキング要求はロッキングキューに記憶され、ロックプロキシスレッドは順序に従って当該ロッキングキューに記憶される各ロッキング要求を処理する。
【0112】
上記の過程で、第１のコンピューティング機器及び第２のコンピューティング機器には何れも、ロックに関するメッセージを送受信するためのメッセージ処理スレッドが配置されることで、ロック要求の過程で、メッセージ処理スレッドによってロックプロキシスレッドを起動させ、各第２のコンピューティング機器上の遠位ロックのライフサイクルを維持する。また、第２のコンピューティング機器のロッキングフィードバック情報が第１のコンピューティング機器に達した場合、第１のコンピューティング機器上のロック要求スレッドが既に終了した状況が存在する可能性があり、この場合、メッセージ処理スレッドを配置したため、第１のコンピューティング機器のメッセージ処理スレッドは以下のステップ４０８の操作によって、現在のデータ要求がアクティブであるかどうかを判定するとともに、ロッキングフィードバック情報がロッキング成功を表すかどうかを判定して、データ要求が非アクティブである場合、ロッキングが成功した第２のコンピューティング機器にロック解除要求を即時に戻し、遠位の要求が成功したロックを解除するようにトリガーすることで、第２のコンピューティング機器上のトラフィックをブロッキングしないという目的を達成する。
【0113】
４０６：第２のコンピューティング機器は当該ロッキングキューにおける当該ロッキング要求を処理して、ロッキングフィードバック情報を取得し、当該ロッキングフィードバック情報は、当該第２のコンピューティング機器の、当該データリソースに対するロッキングが成功したかどうかを表す。
【0114】
いくつかの実施例において、第２のコンピューティング機器はロカールのロックプロキシスレッドを起動させて、ロッキングキューにキャッシュされる各ロッキング要求を処理するように、ロカールのロック要求論理を呼び出す。ロックプロキシスレッドは当該ロッキングキューをトラバースし、今回、第１のコンピューティング機器から送信された当該データ要求に対応するデータリソースをロッキングした場合、当該ロッキング要求の処理が完了したことを説明し、当該ロッキングフィードバック情報をロッキング成功に決定し、さもなければ、タイムアウトするか、又はデッドロックに達するまで、ロッキングキューにおいて引き続いて待ち、当該ロッキングフィードバック情報をロッキング失敗に決定し、即ち、当該ロッキング要求の当該ロッキングキューにおける待ち期間が第３の待ち閾値を超えるか、又はデッドロック検出が不合格である場合、当該ロッキングフィードバック情報をロッキング失敗に決定する。当該第３の待ち閾値は０超えの何れかの数値、例えば５秒であり、当該第３の待ち閾値は配置ファイルに追加されて、クラスタデータベースが起動される場合、各コンピューティング機器のデータベースエンジンによってロードされてもよい。
【0115】
上記の過程から分かるように、ロッキング失敗は少なくとも以下の２つの状況が存在する：ａ）待ちがタイムアウトし、即ち、当該ロッキング要求の当該ロッキングキューにおけるキャッシュ期間が第３の待ち閾値を超えた場合、ロッキングが失敗したとみなす。ｂ）デッドロック検出が不合格であれば、デッドロック検出からデッドロックを発見し、且つ第２のコンピューティング機器自体はデッドロック犠牲者として選定されたことを説明し、そうすれば、ロック要求を完成できない。
【0116】
いくつかの実施例において、第２のコンピューティング機器のデッドロック検出フローは以下の通りであり、当該第１のコンピューティング機器のデッドロック検出メッセージに応答して、第２のコンピューティング機器は当該ロッキング要求に対してロカールデッドロック検出を行って、ロカールデッドロック検出が不合格である場合、デッドロック検出が不合格であると決定し、ロカールデッドロック検出が合格である場合、当該ロッキング要求のロック待ちリンクを決定し、当該ロック待ちリンクは当該ロッキング要求と依存関係を有するロック情報を含み、当該ロック待ちリンクは遠位ロックを含む場合、当該遠位ロックを発信する第３のコンピューティング機器にデッドロック検出メッセージを送信し、当該遠位ロックは当該第２のコンピューティング機器に登録されているロック情報であるが、当該第２のコンピューティング機器により発信されるロック情報ではなく、当該デッドロック検出メッセージを送信する何れかのコンピューティング機器が当該デッドロック検出メッセージを再び受信した場合、デッドロック検出が不合格であると決定する。
【0117】
任意選択で、デッドロック検出メッセージは第１のコンピューティング機器から発信されてもよく、例えば、第１のコンピューティング機器は長い期間にわたっても、第２のコンピューティング機器のロッキングフィードバック情報を受信していないが、待ちがまだタイムアウトしていないと、第１のコンピューティング機器のメッセージ処理スレッドは、第２のコンピューティング機器のメッセージ処理スレッドにデッドロック検出メッセージを送信する。当該デッドロック検出メッセージを受信した場合、第２のコンピューティング機器はまず、ロカールデッドロックを検出し、ロカールデッドロック検出が不合格であれば、ロック待ちリンクをトラバースする必要がなく、直接的に第１のコンピューティング機器にロッキングフィードバック情報を戻し、当該ロッキングフィードバック情報はロッキング失敗を指示し、失敗タイプは自体がデッドロック犠牲者として選定されることである。ロカールデッドロック検出が合格であるが、この場合、デッドロックが存在していないことを完全に確保できないため、対応するロック待ちリンクをトラバースし、ロック待ちリンク上の各ロックに対して、遠位ロックであるかどうかを判定し、遠位ロックであれば、遠位ロックのロック所有側（即ち、第３のコンピューティング機器）にデッドロック検出メッセージを送信して、第２のコンピューティング機器に類似するデッドロック検出フローを実行するように、第３のコンピューティング機器をトリガーし、即ち、第３のコンピューティング機器はまず、ロカールデッドロックを検出してから、ロック待ちリンク上の遠位ロックをトラバースして、デッドロック検出メッセージを再び送信する。何れかのコンピューティング機器自体はデッドロック検出メッセージの送信側として、他のコンピューティング機器から送信された同一デッドロック検出メッセージを受信した場合、デッドロックに達したことを説明し、そうすれば、当該コンピューティング機器は第１のコンピューティング機器にロッキングフィードバック情報を戻し、当該ロッキングフィードバック情報は、ロッキング失敗を指示し、且つ失敗タイプは自体がデッドロック犠牲者として選定されることである。例えば、第１のコンピューティング機器は第２のコンピューティング機器にデッドロック検出メッセージを送信し、第２のコンピューティング機器はロック待ちリンクで遠位ロックが存在し、遠位ロックのロック所有側は第１のコンピューティング機器であり、そうすれば、第２のコンピューティング機器は第１のコンピューティング機器にデッドロック検出メッセージを送信し、この場合、依存ループ現象が出現し、即ち、ロックＡはロックＢを待ち、ロックＢはロックＡを待ち、つまり、第１のコンピューティング機器はデッドロック検出メッセージの送信側として、第２のコンピューティング機器から送信された同一デッドロック検出メッセージを受信した場合、デッドロックを発見し、今回のロッキングが失敗したことを説明する。
【0118】
いくつかの実施例において、第２のコンピューティング機器のロッキングが成功した場合、当該データ要求に対応するデータリソースをロッキングする場合、メッセージ処理スレッドにおいて第２のコンピューティング機器のロックプロキシスレッドは当該データ要求に対応するロック情報を登録し、ターゲット期間ごとに、既に登録された当該ロック情報がアクティブなロック情報であるかどうかを確定する。当該ロック情報がアクティブなロック情報であり、且つ当該データ要求に対応するデータリソースのロッキング期間が死活監視閾値を超える場合、当該第１のコンピューティング機器に死活監視要求を送信し、当該死活監視要求は、当該アクティブなロック情報がロッキングしたデータリソースを解除するかどうかを指示するように、当該第１のコンピューティング機器に要求する。当該死活監視閾値は０超えの何れかの数値、例えば２０秒である。
【0119】
上記の過程で、ロッキングが成功した場合、ロックプロキシスレッドはメッセージ処理スレッドにおいて対応するロック情報を登録することで、メッセージ処理スレッドは、ロカールの要求が成功した各ロックを便利に管理し、メッセージ処理スレッドはレジストリにおけるアクティブなロック情報を周期的に検査でき、死活監視閾値を超えた場合でも、アクティブなロック情報は依然的に解除されていないと、例えば、以下のいくつかの可能性が存在する：ｉ）第１のコンピューティング機器のデータ要求の実行が完了したが、送信されたロック解除要求はパケットロスが生じる。ｉｉ）第１のコンピューティング機器のロック要求スレッドがクラッシュする。ｉｉｉ）第１のコンピューティング機器は正常に処理するが、今回のデータ要求、例えばＤＤＬトランザクション自体にかかった時間が長い。この場合、上記の状況ｉ）及びｉｉ）であれば、死活監視要求を送信することで、ロック解除メッセージを再び送信するように、第１のコンピューティング機器をトリガーして、対応するロックを解除するように第２のコンピューティング機器に指示し、上記の状況ｉｉｉ）であれば、第２のコンピューティング機器は対応するロックを解除できず、依然的に、対応するロックを継続的に保持する。
【0120】
４０７：第２のコンピューティング機器は当該第１のコンピューティング機器に当該ロッキングフィードバック情報を送信する。
【0121】
いくつかの実施例において、第２のコンピューティング機器のメッセージ処理スレッドは第１のコンピューティング機器のメッセージ処理スレッドに当該ロッキングフィードバック情報を送信する。
【0122】
上記のステップ４０５～４０７において、単一の第２のコンピューティング機器を例として、遠位ロックの要求フローを紹介し、クラスタ内の各第２のコンピューティング機器に対して何れもステップ４０５～４０７に類似する操作を実行でき、ここで贅言しない。
【0123】
４０８：第１のコンピューティング機器は、当該ロッキング要求に基づいて当該少なくとも１つの第２のコンピューティング機器から戻された当該ロッキングフィードバック情報を受信する。
【0124】
任意選択で、ロッキングフィードバック情報を受信する場合、第１のコンピューティング機器はそのメッセージ処理スレッドによって、当該少なくとも１つの第２のコンピューティング機器上のメッセージ処理スレッドから戻された当該ロッキングフィードバック情報を受信する。
【0125】
いくつかの実施例において、第１のコンピューティング機器はクラスタ内の各第２のコンピューティング機器にそれぞれ当該ロッキング要求を送信し、各第２のコンピューティング機器のロッキングフィードバック情報が第１のコンピューティング機器に戻る時間は異なっている可能性があり、いくつかの例示的なシナリオにおいて、第１のコンピューティング機器で当該データ要求の処理プロセス（例えば、ＤＤＬプロセス）がクラッシュした場合、当該ＤＤＬプロセスがクラッシュした後、受信したロッキングフィードバック情報に対して、第１のコンピューティング機器は状況に応じて対応するロックを解除するように、ロッキングが成功した第２のコンピューティング機器に即時に指示して、当該データリソース上の他のＤＭＬプロセスをブロッキングすることを回避し、クラスタデータベースの処理性能を最適化する。
【0126】
上記の状況に対して、何れかの第２のコンピューティング機器のロッキングフィードバック情報を受信したことに応答し、当該データ要求がアクティブ状態にある場合、第１のコンピューティング機器は当該メッセージ処理スレッドによって当該ロッキングフィードバック情報を当該データ要求のロック要求スレッドに送信し、当該データ要求が非アクティブ状態にあり、且つ当該ロッキングフィードバック情報が、ロッキング成功である場合、当該第２のコンピューティング機器にロック解除要求を送信し、当該ロック解除要求は当該データ要求に対応するデータリソースを解除するように、当該第２のコンピューティング機器に指示する。
【0127】
任意選択で、メッセージ処理スレッドによって何れかのロッキングフィードバック情報を受信した後、第１のコンピューティング機器はロカールの当該データ要求がアクティブであるかどうかを判定し、ＤＤＬ要求を例として、ＤＤＬ要求に対応するＤＤＬプロセスが存在するかどうかを判定し、複数のＤＤＬ要求が同一ＤＤＬプロセスを多重利用する状況が存在する可能性があるため、現在ＤＤＬ要求が失敗した（例えば、ターゲット条件を満たしておらず、ＤＤＬトランザクションはロールバックされる）場合でも、ＤＤＬプロセスは依然的に存在する可能性があり、従って、ＤＤＬプロセスに対してＤＤＬ要求がアクティブであるかどうかを判定することは、一定の誤判定の状況が存在する可能性がある。任意選択で、直接的に、ＤＤＬ要求に対応するＤＤＬトランザクションがアクティブ状態にあるかどうかを判定してもよく、これによって、上記の誤判定状況を効果的に低減して、判定精度を向上できる。
【0128】
当該データ要求は非アクティブであり、即ち、当該データ要求は非アクティブ状態にあると、当該ロッキングフィードバック情報がロッキング成功を表すかどうかを判定し、当該ロッキングフィードバック情報がロッキング成功を表すことであれば、ロカールのＤＤＬ要求が既に終了したが、遠位の第２のコンピューティング機器でデータリソースに対応するロックを成功的に要求したことを説明し、この場合、データリソースに対応するロックを即時に解除するように、当該第２のコンピューティング機器に指示する必要があり、従って、第１のコンピューティング機器はメッセージ処理スレッドによって当該第２のコンピューティング機器のメッセージ処理スレッドにロック解除要求を送信することで、当該データ要求に対応するデータリソースを解除するように、当該第２のコンピューティング機器に指示し、例えば、当該データリソースに対応するロックのメモリ状態パラメータをアイドル状態に修正する。また、当該ロッキングフィードバック情報はロッキング失敗であれば、遠位には、即時に解除される必要があるデータリソースが存在していないことを示し、そうすれば、なんの処理も必要がない。
【0129】
当該データ要求はアクティブであり、即ち、当該データ要求はアクティブ状態にあると、当該メッセージ処理スレッドによって当該ロッキングフィードバック情報を当該データ要求のロック要求スレッドに送信し、ロック要求スレッドは、今回受信したロッキングフィードバック情報を記録して、以下のステップ４０９に基づいて、ターゲット条件に合うかどうかを判定し、これによって、当該ロック要求スレッドは、受信したロッキングフィードバック情報が現在ロックの同期モードに対応するターゲット条件に合うかどうかを即時に統計する。
【0130】
上記のステップ４０４～４０８において、第１のコンピューティング機器が当該クラスタデータベースにおける少なくとも１つの第２のコンピューティング機器の、当該データリソースに対するロッキングフィードバック情報を如何に取得するかを示し、いくつかの実施例において、第１のコンピューティング機器はさらに、クラスタデータベースにおいて、ブロードキャスト又はマルチキャストの方式で当該ロッキング要求を直接的に送信して、各第２のコンピューティング機器から戻されたロッキングフィードバック情報を受信してもよいし、専用のメッセージ処理スレッドを配置せず、第１のコンピューティング機器上のロック要求スレッド及び第２のコンピューティング機器上のロックプロキシスレッドという両者によって直接的に通信し、これによって、スレッドの間の通信オーバーヘッドを低減する。
【0131】
４０９：取得したロッキングフィードバック情報が当該ロック同期モードに対応するターゲット条件を満たしている場合、第１のコンピューティング機器は当該データ要求に対応するデータリソースをロッキングして、当該データ要求を実行する。
【0132】
上記のステップ４０９は上記のステップ３０４に類似するため、ここで贅言しない。
【0133】
４１０：取得したロッキングフィードバック情報が当該ターゲット条件を満たしていないか、又は当該データ要求の実行が完了した場合、第１のコンピューティング機器は当該少なくとも１つの第２のコンピューティング機器にロック解除要求を送信する。
【0134】
当該ロック解除要求は当該データ要求に対応するデータリソースを解除するように、当該第２のコンピューティング機器に指示する。
【0135】
任意選択で、第１のコンピューティング機器のメッセージ処理スレッドは各第２のコンピューティング機器のメッセージ処理スレッドにロック解除要求を送信する。ロック解除要求の送信過程はロッキング要求の送信過程と同様であるため、ここで贅言しない。
【0136】
４１１：何れか１つの第２のコンピューティング機器に対して、当該データ要求に関連付けられるロック解除要求に応答して、当該データ要求に対応するデータリソースを解除する。
【0137】
任意選択で、第２のコンピューティング機器のメッセージ処理スレッドは当該ロック解除要求を受信して、対応するデータリソースを解除するように、ロックプロキシスレッドに通知し、例えば、ロックプロキシスレッドはロックのメモリ状態パラメータをアイドル状態に修正して、レジストリにおいて対応するロック情報を除去し、これで、メッセージ処理が完了し、受信した各メッセージを廃棄すれば、記憶空間を節約できる。
【0138】
上記の全ての好適な技術案に対して、何れも任意の組み合わせを採用して本開示の好適な実施例を形成でき、ここで、贅言しない。
【0139】
本出願の実施例が提供する方法によれば、ロック同期モードに対して柔軟な複数のレベルを設置し、弱い同期モードで、データ要求に対応するデータリソースを直接的にロッキングして、当該データ要求を実行し、データ要求を優先的に推進することを保証でき、第２のコンピューティング機器の応答を待つ必要がなく、非弱い同期モードで、各第２のコンピューティング機器のロッキングフィードバック情報を取得し、取得したロッキングフィードバック情報がターゲット条件に合う場合に限り、当該データリソースをロッキングして当該データ要求を実行し、異なるトラフィックシナリオで異なるロック同期モードを選択し、クラスタデータベースが異なるトラフィックシナリオの処理ニーズを満たすことを保証して、クラスタデータベースシステムの処理能力を向上する。
【0140】
図５は、本出願の実施例が提供するロッキングフローの原理概略図であり、５００に示すように、クラスタデータベースはコンピューティングノード１及びコンピューティングノード２を含み、コンピューティングノード１は第１のコンピューティング機器であり、コンピューティングノード１にはロック要求スレッド及びメッセージ処理スレッドが実行され、コンピューティングノード２は第２のコンピューティング機器であり、コンピューティングノード２にはメッセージ処理スレッド及びロックプロキシスレッドが実行される。データ要求がＤＤＬ要求であることを例として説明し、コンピューティングノード１のロック要求スレッドはロカールでロックを成功的に要求した後、グローバルロッキングフローに進み、以下、グローバルロッキングフローを詳しく記載する：
ステップ１：ロカールロック要求を完成してから、ロッキングフローに進む。
ステップ２：コンピューティングノード１のロック要求スレッドは弱い同期モードであるかどうかを判定し、弱い同期モードであれば、他のノードにロッキング要求を送信する必要がなく、直接にロックを取得した（正確さは書き込みバリアメカニズムによって保障される）とみなし、ステップ２８にジャンプし、弱い同期モードではなければ、ステップ３に進む。
ステップ３：弱い同期モードではない場合、他のノードにロッキング要求を送信して、ステップ４に進むとともに、ステップ２６に進んで計時し始める。
ステップ４：コンピューティングノード２のメッセージ処理スレッドはロッキング要求を受信する。
なお、当該メッセージ処理スレッドはバックグラウンドで他のノードのロッキング要求、ロック解除要求及びロッキングフィードバック情報を専門に監視し、各類のロック関連メッセージを送受信する。ロック要求階段で、メッセージ受信側として、メッセージ処理スレッドは、コンピューティングノード２上の遠位ロックのライフサイクルを維持するように、ロックプロキシスレッドを呼び出す。ロッキングフィードバック情報を戻す階段で、ロッキングフィードバック情報が要求側（コンピューティングノード１）に達した場合、要求側のロック要求スレッドは既にクラッシュしたか又は終了した可能性があり、そうすれば、コンピューティングノード１上のメッセージ処理スレッドはロック要求スレッドが終了したかどうか、及びロッキングフィードバック情報がロッキング成功であるかどうかに基づいて、コンピューティングノード２にロック解除要求を送信して、遠位の要求が成功した遠位ロックを解除するかどうかを決定する。
ステップ５：コンピューティングノード２はロカールロックプロキシスレッドを起動させ、ロカールロック要求論理を呼び出す。
ステップ６：ＤＤＬ要求に対応するロック要求が成功したかどうかを判定し、要求が成功した場合、ステップ８に進み、要求が成功していないと、以下の状況を含む。６.１）ロッキング要求は依然的にロッキングキューに位置して、列に並んで待って、この場合、引き続いて待ち、ステップ７に進み、タイムアウトしたかどうかを判定する。６.２）デッドロック検出からデッドロックを発見し、自体はデッドロック犠牲者として選定され、ステップ８に進む。
ステップ７：遠位ロック要求がタイムアウトしたかどうかを判定し、タイムアウトしていないと、引き続いて待ち、タイムアウトした場合、ステップ８に進む。
例えば、タイムアウトしたかどうかを判定する場合、待ち期間が第３の待ち閾値を超えたかどうかを判定する。
ステップ８：コンピューティングノード１のメッセージ処理スレッドにロッキングフィードバック情報を送信して、ステップ１０に進む。
ステップ１：ロカールロック要求を完成してから、ロッキングフローに進む。
ステップ２：コンピューティングノード１のロック要求スレッドは弱い同期モードであるかどうかを判定し、弱い同期モードであれば、他のノードにロッキング要求を送信する必要がなく、直接にロックを取得した（正確さは書き込みバリアメカニズムによって保障される）とみなし、ステップ２８にジャンプし、弱い同期モードではなければ、ステップ３に進む。
ステップ３：弱い同期モードではない場合、他のノードにロッキング要求を送信して、ステップ４に進むとともに、ステップ２６に進んで計時し始める。
ステップ４：コンピューティングノード２のメッセージ処理スレッドはロッキング要求を受信する。
なお、当該メッセージ処理スレッドはバックグラウンドで他のノードのロッキング要求、ロック解除要求及びロッキングフィードバック情報を専門に監視し、各類のロック関連メッセージを送受信する。ロック要求階段で、メッセージ受信側として、メッセージ処理スレッドは、コンピューティングノード２上の遠位ロックのライフサイクルを維持するように、ロックプロキシスレッドを呼び出す。ロッキングフィードバック情報を戻す階段で、ロッキングフィードバック情報が要求側（コンピューティングノード１）に達した場合、要求側のロック要求スレッドは既にクラッシュしたか又は終了した可能性があり、そうすれば、コンピューティングノード１上のメッセージ処理スレッドはロック要求スレッドが終了したかどうか、及びロッキングフィードバック情報がロッキング成功であるかどうかに基づいて、コンピューティングノード２にロック解除要求を送信して、遠位の要求が成功した遠位ロックを解除するかどうかを決定する。
ステップ５：コンピューティングノード２はロカールロックプロキシスレッドを起動させ、ロカールロック要求論理を呼び出す。
ステップ６：ＤＤＬ要求に対応するロック要求が成功したかどうかを判定し、要求が成功した場合、ステップ８に進み、要求が成功していないと、以下の状況を含む。６.１）ロッキング要求は依然的にロッキングキューに位置して、列に並んで待って、この場合、引き続いて待ち、ステップ７に進み、タイムアウトしたかどうかを判定する。６.２）デッドロック検出からデッドロックを発見し、自体はデッドロック犠牲者として選定され、ステップ８に進む。
ステップ７：遠位ロック要求がタイムアウトしたかどうかを判定し、タイムアウトしていないと、引き続いて待ち、タイムアウトした場合、ステップ８に進む。
例えば、タイムアウトしたかどうかを判定する場合、待ち期間が第３の待ち閾値を超えたかどうかを判定する。
ステップ８：コンピューティングノード１のメッセージ処理スレッドにロッキングフィードバック情報を送信して、ステップ１０に進む。
【0141】
任意選択で、ロッキングフィードバック情報は、ロッキング成功、ロック待ちタイムアウト、デッドロック犠牲者という３類に分けられる。
【0142】
任意選択で、ロッキングフィードバック情報は、ロッキング成功、ロッキング失敗という２類に分けられ、ロッキング失敗は、ロック待ちタイムアウト、デッドロック犠牲者を含む。
【0143】
ステップ９：コンピューティングノード２のメッセージ処理スレッドのメッセージをインターフェースにフィードバックし、ここで、主にステップ１０～１３の死活監視メカニズムによる死活監視要求を処理し、死活監視要求をコンピューティングノード１のメッセージ処理スレッドに送信する。
【0144】
死活監視要求は、分散型環境でロック要求側（コンピューティングノード１）のロック要求スレッドが既に終了したが、コンピューティングノード２の遠位ロックがずっと解除されていない状況に対応する。一定の期間（例えば、死活監視閾値）を超えても、遠位ロックが依然的に解除されていない場合、死活監視要求をロック要求側、即ちロック所有者に送信して、死活監視を行う。
【0145】
ステップ１０：コンピューティングノード２のロックプロキシスレッドはメッセージ処理スレッドに、全ての遠位ロックのロック情報及びロック状態を登録する。
【0146】
ロック情報はロックタイプ（読み取りロック、書き込みロック、更新ロックなど）、ロックの対象となるデータリソース（例えばデータベース名称、データテーブル名称、データインデックスＩＤ、データ列名称など）、ロッキング時間などを含むが、これらに限定されない。
【0147】
ロック状態はアクティブ状態、非アクティブ状態などを含むが、これらに限定されない。
【0148】
ステップ１１：コンピューティングノード２のメッセージ処理スレッドはレジストリにおける各遠位ロック中のアクティブなロックを周期的に検査する。
【0149】
例えば、レジストリにおける各ロック情報をトラバースして、アクティブ状態にある遠位ロックを検索する。
【0150】
ステップ１２：死活監視閾値を超えた遠位アクティブなロックが存在するかどうかを判定し、ＹＥＳであれば、ステップ１３に進み、ＮＯであれば、レジストリにおけるロック情報を継続的に周期的に監視する。
【0151】
ステップ１３：死活監視要求をフィードバックするように準備し、ステップ９に進む。
【0152】
ステップ１４：コンピューティングノード１のメッセージ処理スレッドはロッキングフィードバック情報及び死活監視要求を受信する。
【0153】
ステップ１５：ロカールのロック要求スレッドがアクティブであるかどうかを判定し、ＹＥＳであれば、ステップ１６に進み、ＮＯであれば、ステップ２１に進む。
【0154】
アクティブの場合、３つの状況に分けられる：１５.１）現在ロック要求スレッドがアクティブであり、ロック要求階段に位置すれば、対応するロック要求構造データを更新して、ロック要求スレッドに送信して処理する。１５.２）準強い同期モードで、現在ロック要求スレッドはロック要求成功のターゲット条件に達した場合、対応するロック要求構造データを更新して、操作を完成する。１５.３）現在ロック要求スレッドはロック終了、又はロック要求が失敗して終了した（例えば、準強い同期モードで、ターゲット条件に合わないと判定した）場合、対応するロック要求構造データを更新して、操作を完成する。
【0155】
任意選択で、当該ロック要求構造データは、各コンピューティングノード２のロッキングフィードバック情報を記録し、例えばハッシュテーブル、配列、セット、ベクトルなどの形態を採用し、例えばセット形態を採用すれば、セットにおける各要素は、１つのコンピューティングノードのロッキングが成功したか、それとも失敗したかを示し、要素が０であれば、ロッキングが失敗したことを示し、要素が１であれば、ロッキングが成功したことを示し、要素がヌル（ｎｕｌｌ）であれば、まだロッキングフィードバック情報を受信していないことを示す。
【0156】
ステップ１６：この場合、ロッキングフィードバック情報がロッキング成功であるか、又は死活監視要求を受信した場合、ステップ１７に進み、さもなければ、何の処理もしなく、ステップ３２に進み、即ち、メッセージ処理が完了して、受信した当該メッセージを廃棄する。
【0157】
ステップ１７：コンピューティングノード１のメッセージ処理スレッドはコンピューティングノード２のメッセージ処理スレッドにロック解除要求を送信する。
【0158】
ステップ１８：コンピューティングノード２のメッセージ処理スレッドはロック解除要求を受信する。
【0159】
ステップ１９：コンピューティングノード２のメッセージ処理スレッドはロックを解除するように、ロックプロキシスレッドに通知する。
【0160】
ステップ２０：コンピューティングノード２のロックプロキシスレッドはロックを解除する。
【0161】
ステップ２１：コンピューティングノード１のロック要求スレッドは、メッセージ処理スレッドから送信されたロッキングフィードバック情報を受信する。ここで、ステップ８が係るいくつかのロッキングフィードバック情報を含む。
【0162】
ステップ２２：現在のロック同期モードを判定し、強い同期モードであれば、ステップ２５に進み、準強い同期モードであれば、ステップ２３に進む。
【0163】
ステップ２３：ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍが有効値（即ち、１以上、且つクラスタ内の全てのコンピューティング機器の数の以下である）に設置されたかどうかを検査し、有効値であれば、準強い同期モードに従ってステップ２４に進み、有効値ではなければ、強い同期モードに従ってステップ２５に進む。
【0164】
ステップ２４：ロッキング成功をフィードバックした遠位ノードにロカールノードを加算した数が、ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍを超えたかどうかを判定し、ＹＥＳであれば、ステップ２８に進み、ＮＯであれば、ロック要求がタイムアウトしたかどうか、即ち、待ち期間が第２の待ち閾値を超えたかどうかを判定し、まだタイムアウトしていないと、継続的に待ち、タイムアウトした場合、ロッキングが失敗し、ロッキング失敗をフィードバックした遠位ノードの数がクラスタ内のノード総数からロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍを引くことで取得した数値を超えた場合、ロッキングが失敗したと判定し、ステップ２９に進む。
【0165】
ステップ２５：強い同期モードで、全てのノードが何れもロッキング成功をフィードバックしたかどうかを判定し、上記の条件を満たしていると、ステップ２８に進み、満たしていないが、まだタイムアウトしておらず、即ち、待ち期間が第１の待ち閾値を超えていないと、継続的に待って、何れか１つのノードがロッキング失敗をフィードバックすれば、ロッキングが失敗したと判定し、ステップ２９に進む。
【0166】
ステップ２６：ロック要求時間を計算し始める。
【0167】
ステップ２７：ロック要求時間がタイムアウトしたかどうかを判定し、ＹＥＳであれば、ステップ２９に進み、即ち、ロッキングが失敗し、ＮＯであれば、継続的にステップ２１に戻って、論理を検査する。
【0168】
任意選択で、強い同期モードでタイムアウト閾値は第１の待ち閾値であり、準強い同期モードでタイムアウト閾値は第２の待ち閾値であり、両者の値は同様であってもよいし、又は異なってもよい。
【0169】
ステップ２８：グローバルロッキングが成功する。
【0170】
ステップ２９：グローバルロッキングが失敗する。
【0171】
ステップ３０：他の全てのノードにロック解除要求を送信する。
【0172】
任意選択で、他のノードにはステップ１１～２０の死活監視論理が存在するため、ロック解除要求を送信した後、コンピューティングノード１は、他のノードがロック解除フィードバック情報を戻すまで待つ必要がなく、フローを終了できる。
【0173】
ステップ３１：ロッキングフローを完成する。
【0174】
ステップ３２：メッセージ処理が完了して、メッセージを廃棄すればよい。
【0175】
本出願の実施例において、ロッキングフローを詳しく紹介し、分散型データベースにおいて、柔軟なロックメカニズムを実現することで、各プロセス又はスレッドがあるデータリソースを修正する時の操作の正確さを確保できる。また、このような柔軟なロックメカニズムを実現することで、弱い同期モード、準強い同期モード、強い同期モードで、柔軟な切り替えを実現して、分散型データベースクラスタは自体のデータベースの適用シナリオのニーズに応じて、異なるレベルのロックメカニズムを選択して、ユーザーの異なるトラフィックシナリオでのトラフィックニーズを満たしている。
【0176】
図６は、本出願の実施例が提供するロック解除フローの原理概略図であり、６００に示すように、クラスタデータベースはコンピューティングノード１及びコンピューティングノード２を含み、コンピューティングノード１は第１のコンピューティング機器であり、コンピューティングノード２は第２のコンピューティング機器であり、コンピューティングノード２にはメッセージ処理スレッド及びロックプロキシスレッドが実行される。コンピューティングノード１のグローバルロッキングが成功した後、対応するデータ要求、例えばＤＤＬ要求を実行し、ロカールでＤＤＬトランザクションの処理論理が完成した後、ロック解除フローに進み、以下、ロック解除フローを詳しく記載する：
ステップ１：ＤＤＬトランザクションのロカール処理論理が完成した後、ロック解除フローに進む。
ロックを持つコンピューティングノード１がＤＤＬトランザクションのコンピューティング論理を完成した後、ロックをグローバルに解除し、本出願の実施例において、遠位ロックを解除してから、ロカールロックを解除する順序を例として、グローバルなロック解除のフローを紹介する。この場合、ロッキング及びロック解除の全体的な過程は以下の通りであり：ロカールロッキング→遠位ロッキング→遠位ロック解除→ロカールロック解除。
ステップ２：弱い同期モードであるかどうかを判定し、弱い同期モードであれば、ステップ１０に進み、遠位ロックを解除する必要がなく、弱い同期モードではなければ、ステップ３に進む。
ステップ３：他のノードにロック解除要求を送信する。
ステップ４：コンピューティングノード２のメッセージ処理スレッドはロック解除要求を受信する。
ステップ５：メッセージ処理スレッドは、ロカールで対応する遠位ロックを解除するように、ロックプロキシスレッドを起動させる。
例えば、ロックプロキシスレッドが一時停止状態にあると、メッセージ処理スレッドはロックプロキシスレッドをウェイクアップして、ロック解除操作を行う。
ステップ６：ロックプロキシスレッドはロカールで対応する遠位ロックを解除し、解除が成功した場合、ステップ７に進み、解除が失敗した場合、再び解除する。
ステップ７：レジストリにおける対応するロック情報をクリーニングするように準備する。
ステップ８：レジストリにおける登録済みのロック情報をクリーニングする。
ステップ９：ロックプロキシスレッドが終了する。
ステップ１０：ロック解除が成功する。
ステップ１１：ロック解除フローが終了する。
ステップ１：ＤＤＬトランザクションのロカール処理論理が完成した後、ロック解除フローに進む。
ロックを持つコンピューティングノード１がＤＤＬトランザクションのコンピューティング論理を完成した後、ロックをグローバルに解除し、本出願の実施例において、遠位ロックを解除してから、ロカールロックを解除する順序を例として、グローバルなロック解除のフローを紹介する。この場合、ロッキング及びロック解除の全体的な過程は以下の通りであり：ロカールロッキング→遠位ロッキング→遠位ロック解除→ロカールロック解除。
ステップ２：弱い同期モードであるかどうかを判定し、弱い同期モードであれば、ステップ１０に進み、遠位ロックを解除する必要がなく、弱い同期モードではなければ、ステップ３に進む。
ステップ３：他のノードにロック解除要求を送信する。
ステップ４：コンピューティングノード２のメッセージ処理スレッドはロック解除要求を受信する。
ステップ５：メッセージ処理スレッドは、ロカールで対応する遠位ロックを解除するように、ロックプロキシスレッドを起動させる。
例えば、ロックプロキシスレッドが一時停止状態にあると、メッセージ処理スレッドはロックプロキシスレッドをウェイクアップして、ロック解除操作を行う。
ステップ６：ロックプロキシスレッドはロカールで対応する遠位ロックを解除し、解除が成功した場合、ステップ７に進み、解除が失敗した場合、再び解除する。
ステップ７：レジストリにおける対応するロック情報をクリーニングするように準備する。
ステップ８：レジストリにおける登録済みのロック情報をクリーニングする。
ステップ９：ロックプロキシスレッドが終了する。
ステップ１０：ロック解除が成功する。
ステップ１１：ロック解除フローが終了する。
【0177】
本出願の実施例において、ＤＤＬ要求の実行が完了した後、如何にロック解除フローを行うかについて詳しく紹介し、ここで、死活監視メカニズムは、ＤＤＬスレッドがクラッシュしたか、又はロック同期モードでのターゲット条件に合わないと探知した場合、トリガーされるロック解除フローは本出願の実施例に類似するため、ここで贅言しない。
【0178】
図７は、本出願の実施例が提供するデッドロック検出フローの原理概略図であり、７００に示すように、クラスタデータベースはコンピューティングノード１及びコンピューティングノード２を含み、コンピューティングノード１は第１のコンピューティング機器であり、コンピューティングノード２は第２のコンピューティング機器であり、コンピューティングノード２にはメッセージ処理スレッドが実行される。以下、デッドロック検出フローを説明する：
ステップ１：コンピューティングノード１はデータリソースＡをロッキングすると意図する。
ステップ２：他のノードにデッドロック検出メッセージを送信して、ステップ３及びステップ１０に進む。
ステップ３：コンピューティングノード２のメッセージ処理スレッドはデッドロック検出メッセージを受信する。
例えば、デッドロック検出メッセージは関連するロック情報を含む。
ステップ４：ロカールデッドロック検出論理を使用して、ロカールデッドロック検出を行って、デッドロック検出が合格した場合、ステップ５に進み、デッドロック検出が不合格であれば、自体がデッドロック犠牲者として選定されたことを指示するメッセージを戻す。
ステップ５：ロック待ちリンクをトラバースする。
ステップ６：ロック待ちリンクにおいて現在のロックが遠位ロックであるかどうかを判定し、ＹＥＳであれば、ステップ７に進み、ＮＯであれば、ロック待ちリンク上の次のロックをトラバースする。
ステップ７：ロック所有者にデッドロック検出メッセージを送信する。
本出願の実施例において、ロック所有者がコンピューティングノード１であることを例として説明する。
ステップ８：デッドロック検出メッセージを受信する。
ステップ９：デッドロック検出メッセージがクローズドループを形成することを発見すると、デッドロックが生じる。
ステップ１０：ロカールのメッセージ処理スレッドにロック情報を登録する。
ステップ１：コンピューティングノード１はデータリソースＡをロッキングすると意図する。
ステップ２：他のノードにデッドロック検出メッセージを送信して、ステップ３及びステップ１０に進む。
ステップ３：コンピューティングノード２のメッセージ処理スレッドはデッドロック検出メッセージを受信する。
例えば、デッドロック検出メッセージは関連するロック情報を含む。
ステップ４：ロカールデッドロック検出論理を使用して、ロカールデッドロック検出を行って、デッドロック検出が合格した場合、ステップ５に進み、デッドロック検出が不合格であれば、自体がデッドロック犠牲者として選定されたことを指示するメッセージを戻す。
ステップ５：ロック待ちリンクをトラバースする。
ステップ６：ロック待ちリンクにおいて現在のロックが遠位ロックであるかどうかを判定し、ＹＥＳであれば、ステップ７に進み、ＮＯであれば、ロック待ちリンク上の次のロックをトラバースする。
ステップ７：ロック所有者にデッドロック検出メッセージを送信する。
本出願の実施例において、ロック所有者がコンピューティングノード１であることを例として説明する。
ステップ８：デッドロック検出メッセージを受信する。
ステップ９：デッドロック検出メッセージがクローズドループを形成することを発見すると、デッドロックが生じる。
ステップ１０：ロカールのメッセージ処理スレッドにロック情報を登録する。
【0179】
本出願の実施例において、ロカールデッドロック検出論理を行う上に、分散型データベースを配置し、ロック待ちリンクをトラバースする時、遠位ロックであるかどうかを判定し、ＮＯであれば、ロカールデッドロック検出論理から、デッドロックが生じたかどうかを発見でき、ＹＥＳであれば、ロック所有者（即ち、ロック所有スレッドが所在するコンピューティングノード）にデッドロック検出メッセージを送信し、ロックノードを所有するコンピューティングノードとデッドロック検出を開始するコンピューティングノードとは同一ノードであれば、クローズドループを形成し、即ち、デッドロックが生じたことを示し、例えば、本出願の実施例において、コンピューティングノード１はコンピューティングノード２を待ち、コンピューティングノード２はコンピューティングノード１を待ち、クローズドループを形成し、デッドロックが生じた場合、現在のロック要求操作は拒否され、この場合、データベースエンジンは一定期間後、自動に再試行し、又はメッセージをユーザーに戻すことを拒否して、ユーザーはしばらく待った後、主動に再試行を開始する。
【0180】
上記の各実施例は分散型データベースにおけるロッキングフロー、ロック解除フロー及びデッドロック検出フローを詳しく紹介し、本出願の実施例において、当該ロック同期メカニズムの異常シナリオでの表現を詳しく分析して、上記のロック同期メカニズムが如何に分散型シナリオのコンピューティングノードネットワークのパーティション、ネットワークの不安定、ネットワークの遅延又はネットワークのパケットロスなどの異常シナリオに対処するかについて、説明する。
【0181】
管理者が弱い同期モードを選択した場合、弱い同期モードは遠位にロックを要求する必要がなく、リソース操作の正確さは書き込みバリアメカニズムによって保証されるため、ロック要求を必要とするＤＤＬトランザクションに対して高い優先度を具備し、ＤＤＬトランザクションの推進に連れて、ユーザーのＤＭＬトランザクションはロールバックされる恐れがあり、一般的に、ＤＭＬトランザクションはユーザーの主なトラフィックであるため、いくつかのシナリオで、ユーザーエクスペリエンスが悪いが、多くのＤＤＬトランザクションを有する適用シナリオに適用される。
【0182】
管理者が強い同期モードを選択した場合、ＤＤＬトランザクションとＤＭＬトランザクションとを平等に扱うことを確保できるが、ネットワーク状況が悪い場合、ＤＤＬトランザクションは、グローバルなロックを要求する必要があるため、クラスタ内の他の全てのノードがロッキングフィードバック情報を戻すまで待ち、パーティション又はネットワーク遅延のため、ある１つ又はいくつかのノードが、ロッキングフィードバック情報を即時に戻しておらず、この待ち期間内で、分散型クラスタ全体の他のノードはロック付与の成功によって、ＤＭＬトランザクションの実行を拒否し、結果として、クラスタ全体の応答速度が遅くなり、ユーザーのエクスペリエンスは、クラスタ全体がサービスを提供できないことであり、従って、ネットワーク状況が悪い場合、強い同期モードのユーザーエクスペリエンスは同じく悪い。
【0183】
管理者が準強い同期モードを選択した場合、折衷選択を提供し、即ち、上記の分散型システムネットワーク問題による影響と、ユーザーのトラフィック実行成功に対する高いニーズとの間で、柔軟且つ設置可能なクラスタ運転方式を提供する。準強い同期モードはロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍを設置することで、グローバルなロック要求が成功すると判定できるために、戻す必要があるノードの数を決定し、ｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍ＝０であれば、弱い同期モードに相当し、ｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍ＝ｎであり、ｎはクラスタにおけるノード、即ち、コンピューティング機器の総数であれば、強い同期モードに相当し、０＜ｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍ＜ｎであれば、準強い同期モードである。
【0184】
ロック成功確率パラメータｌｏｃｋ＿ｓｕｃｃ＿ｎｏｄｅ＿ｎｕｍを提供することで、管理者は自体のクラスタのネットワーク状況に基づいて、１つの合理値を設置することで、ユーザーＤＭＬトランザクションとＤＤＬトランザクションとの間の平等な扱いを最大限に保証し、また、ある１つ又は複数のノードが応答していないため、クラスタ全体が無効になり、例えばｈａｎｇされることがない。
【0185】
また、上記のロッキングフローにおけるステップ１０～２０は死活監視メカニズムをさらに提供し、１つのロックのロック所有者（ｏｗｎｅｒ）がある原因でロック解除要求を他のノードに送信していない場合、遠位ノードは死活監視メカニズムによって死活監視を主動的に行うことを確保して、遠位ロックを解除する。
【0186】
本出願の実施例において、柔軟なロッキングメカニズムを提供することで、分散型データベースクラスタが実行されるネットワーク環境及びＤＭＬトランザクション成功率に対する要求に基づいて、ロック同期モードを決定する柔軟な調整方式を管理者に提供し、ユーザーは分散型クラスタのコンピューティング能力を最大限に使用できるとともに、実行過程で、分散型クラスタの各ノードが外部に表現する全体は、単一ノードのデータベースシステムの表現と一致する。
【0187】
図８は、本出願の実施例が提供する要求処理装置の構造概略図であり、図８を参照し、当該装置は、
データ要求に応答して、クラスタデータベースのロック同期モードを決定する決定モジュール８０１と、
当該ロック同期モードが弱い同期モードである場合、当該データ要求に対応するデータリソースをロッキングして、当該データ要求を実行するロッキング実行モジュール８０２と、
当該ロック同期モードが弱い同期モードではない場合、当該クラスタデータベースにおける少なくとも１つの第２のコンピューティング機器の、当該データリソースに対するロッキングフィードバック情報を取得する第１の取得モジュール８０３であって、当該ロッキングフィードバック情報は、当該第２のコンピューティング機器の、当該データリソースに対するロッキングが成功したかどうかを表すためのものである第１の取得モジュール８０３と、を含み、
当該ロッキング実行モジュール８０２はさらに、取得した当該ロッキングフィードバック情報が、当該ロック同期モードに対応するターゲット条件を満たしている場合、当該データ要求に対応するデータリソースをロッキングして、当該データ要求を実行する。
データ要求に応答して、クラスタデータベースのロック同期モードを決定する決定モジュール８０１と、
当該ロック同期モードが弱い同期モードである場合、当該データ要求に対応するデータリソースをロッキングして、当該データ要求を実行するロッキング実行モジュール８０２と、
当該ロック同期モードが弱い同期モードではない場合、当該クラスタデータベースにおける少なくとも１つの第２のコンピューティング機器の、当該データリソースに対するロッキングフィードバック情報を取得する第１の取得モジュール８０３であって、当該ロッキングフィードバック情報は、当該第２のコンピューティング機器の、当該データリソースに対するロッキングが成功したかどうかを表すためのものである第１の取得モジュール８０３と、を含み、
当該ロッキング実行モジュール８０２はさらに、取得した当該ロッキングフィードバック情報が、当該ロック同期モードに対応するターゲット条件を満たしている場合、当該データ要求に対応するデータリソースをロッキングして、当該データ要求を実行する。
【0188】
本出願の実施例が提供する装置によれば、ロック同期モードに対して柔軟な複数のレベルを設置し、弱い同期モードで、データ要求に対応するデータリソースを直接的にロッキングして、当該データ要求を実行し、データ要求を優先的に推進することを保証でき、第２のコンピューティング機器の応答を待つ必要がなく、非弱い同期モードで、各第２のコンピューティング機器のロッキングフィードバック情報を取得し、取得したロッキングフィードバック情報がターゲット条件を満たしている場合、当該データリソースをロッキングし当該データ要求を実行し、異なるトラフィックシナリオで異なるロック同期モードを選択し、クラスタデータベースが異なるトラフィックシナリオの処理ニーズを満たすことができることを保証して、クラスタデータベースシステムの処理能力を向上する。
【0189】
可能な実施形態において、図８の装置構造に基づいて、当該第１の取得モジュール８０３は、
当該少なくとも１つの第２のコンピューティング機器に、当該データ要求に関連付けられるロッキング要求を送信する送信ユニットと、
当該少なくとも１つの第２のコンピューティング機器から当該ロッキング要求に基づいて戻された当該ロッキングフィードバック情報を受信する受信ユニットと、を含む。
当該少なくとも１つの第２のコンピューティング機器に、当該データ要求に関連付けられるロッキング要求を送信する送信ユニットと、
当該少なくとも１つの第２のコンピューティング機器から当該ロッキング要求に基づいて戻された当該ロッキングフィードバック情報を受信する受信ユニットと、を含む。
【0190】
可能な実施形態において、当該送信ユニットは、当該第１のコンピューティング機器上のメッセージ処理スレッドによって、当該少なくとも１つの第２のコンピューティング機器上のメッセージ処理スレッドに当該ロッキング要求を送信し、
当該受信ユニットは、当該第１のコンピューティング機器上のメッセージ処理スレッドによって、当該少なくとも１つの第２のコンピューティング機器上のメッセージ処理スレッドが戻した当該ロッキングフィードバック情報を受信する。
当該受信ユニットは、当該第１のコンピューティング機器上のメッセージ処理スレッドによって、当該少なくとも１つの第２のコンピューティング機器上のメッセージ処理スレッドが戻した当該ロッキングフィードバック情報を受信する。
【0191】
可能な実施形態において、図８の装置構造に基づいて、当該装置は、
何れか１つの第２のコンピューティング機器のロッキングフィードバック情報を受信したことに応答して、当該データ要求がアクティブ状態にある場合、当該メッセージ処理スレッドによって当該ロッキングフィードバック情報を当該データ要求のロック要求スレッドに送信する送信モジュールをさらに含み、
当該送信モジュールはさらに、当該データ要求が非アクティブ状態にあり、且つ当該ロッキングフィードバック情報が、ロッキング成功を表す場合、当該第２のコンピューティング機器にロック解除要求を送信し、当該ロック解除要求は当該データ要求に対応するデータリソースを解除するように、当該第２のコンピューティング機器に指示する。
何れか１つの第２のコンピューティング機器のロッキングフィードバック情報を受信したことに応答して、当該データ要求がアクティブ状態にある場合、当該メッセージ処理スレッドによって当該ロッキングフィードバック情報を当該データ要求のロック要求スレッドに送信する送信モジュールをさらに含み、
当該送信モジュールはさらに、当該データ要求が非アクティブ状態にあり、且つ当該ロッキングフィードバック情報が、ロッキング成功を表す場合、当該第２のコンピューティング機器にロック解除要求を送信し、当該ロック解除要求は当該データ要求に対応するデータリソースを解除するように、当該第２のコンピューティング機器に指示する。
【0192】
可能な実施形態において、当該ロック同期モードが強い同期モードである場合、当該ターゲット条件は、当該少なくとも１つの第２のコンピューティング機器のロッキングフィードバック情報が何れもロッキング成功を表すことであり、当該ロック同期モードが準強い同期モードである場合、当該ターゲット条件は、当該少なくとも１つの第２のコンピューティング機器のうちのターゲット数以上の第２のコンピューティング機器のロッキングフィードバック情報がロッキング成功を表すことである。
【0193】
可能な実施形態において、当該ロック同期モードが強い同期モードである場合、当該ターゲット条件は、待ち期間が第１の待ち閾値の以下であり、且つ当該少なくとも１つの第２のコンピューティング機器のロッキングフィードバック情報が何れもロッキング成功を表すことであり、当該ロック同期モードが準強い同期モードである場合、当該ターゲット条件は、待ち期間が第２の待ち閾値の以下であり、且つ当該少なくとも１つの第２のコンピューティング機器のうちのターゲット数以上の第２のコンピューティング機器のロッキングフィードバック情報が、ロッキング成功を表すことである。
【0194】
可能な実施形態において、図８の装置構造に基づいて、当該装置は、
当該ロック同期モードが準強い同期モードである場合、当該ターゲット数を取得する第２の取得モジュールと、
当該ターゲット数が１より小さいか、又は当該クラスタデータベースにおける全ての第２のコンピューティング機器の数を超えた場合、当該ロック同期モードを当該強い同期モードに切り替える切り替えモジュールと、をさらに含む。
当該ロック同期モードが準強い同期モードである場合、当該ターゲット数を取得する第２の取得モジュールと、
当該ターゲット数が１より小さいか、又は当該クラスタデータベースにおける全ての第２のコンピューティング機器の数を超えた場合、当該ロック同期モードを当該強い同期モードに切り替える切り替えモジュールと、をさらに含む。
【0195】
可能な実施形態において、図８の装置構造に基づいて、当該装置は、
取得した当該ロッキングフィードバック情報が当該ターゲット条件を満たしていないか、又は当該データ要求の実行が完了した場合、当該少なくとも１つの第２のコンピューティング機器にロック解除要求を送信する送信モジュールであって、当該ロック解除要求は当該データ要求に対応するデータリソースを解除するように、当該第２のコンピューティング機器に指示する送信モジュールをさらに含む。
取得した当該ロッキングフィードバック情報が当該ターゲット条件を満たしていないか、又は当該データ要求の実行が完了した場合、当該少なくとも１つの第２のコンピューティング機器にロック解除要求を送信する送信モジュールであって、当該ロック解除要求は当該データ要求に対応するデータリソースを解除するように、当該第２のコンピューティング機器に指示する送信モジュールをさらに含む。
【0196】
可能な実施形態において、当該データ要求はデータ定義言語ＤＤＬ要求である。
【0197】
上記の全ての好適な技術案に対して、任意の組み合わせを採用して本開示の好適な実施例を形成でき、ここで、贅言しない。
【0198】
ここで、上記の実施例が提供する要求処理装置はデータ要求を処理する時、上記の各機能モジュールの区画に対して例を挙げて記載したが、実際の適用においては、ニーズに基づいて、異なる機能モジュールによって完成するように、上記の機能を割り当て、即ち、コンピューティング機器の内部構造を、異なる機能モジュールに区画することで、以上に記載的の全ての又は一部機能を完成する。また、上記の実施例が提供する要求処理装置は、要求処理方法の実施例と同一構想に属するため、その具体的な実現過程について、要求処理方法の実施例を参照すればよく、ここで贅言しない。
【0199】
図９は、本出願の実施例が提供する要求処理装置の構造概略図であり、図９を参照し、当該装置は、
データ要求に関連付けられるロッキング要求に応答して、当該ロッキング要求をロッキングキューに追加する追加モジュール９０１であって、当該ロッキング要求は、ロック同期モードが弱い同期モードではない場合、当該クラスタデータベースにおける第１のコンピューティング機器によって送信されるものである追加モジュール９０１と、
当該ロッキングキューにおける当該ロッキング要求を処理して、ロッキングフィードバック情報を取得する処理モジュール９０２と、
当該第１のコンピューティング機器に当該ロッキングフィードバック情報を送信する送信モジュール９０３と、を含む。
データ要求に関連付けられるロッキング要求に応答して、当該ロッキング要求をロッキングキューに追加する追加モジュール９０１であって、当該ロッキング要求は、ロック同期モードが弱い同期モードではない場合、当該クラスタデータベースにおける第１のコンピューティング機器によって送信されるものである追加モジュール９０１と、
当該ロッキングキューにおける当該ロッキング要求を処理して、ロッキングフィードバック情報を取得する処理モジュール９０２と、
当該第１のコンピューティング機器に当該ロッキングフィードバック情報を送信する送信モジュール９０３と、を含む。
【0200】
本出願の実施例が提供する装置によれば、ロック同期モードに対して柔軟な複数のレベルを設置し、弱い同期モードではない場合に限り、第１のコンピューティング機器はロッキング要求を送信し、当該ロッキング要求に応答して、対応するロッキングフィードバック情報を戻し、取得したロッキングフィードバック情報がターゲット条件を満たしている場合、当該データリソースをロッキングして当該データ要求を実行するように、第１のコンピューティング機器をトリガーすることで、クラスタデータベースは、異なるトラフィックシナリオで異なるロック同期モードを選択するようにサポートし、クラスタデータベースが異なるトラフィックシナリオの処理ニーズを満たすことができることを保証して、クラスタデータベースシステムの処理能力を向上する。
【0201】
可能な実施形態において、当該処理モジュール９０２は、
当該データ要求に対応するデータリソースをロッキングして、当該ロッキングフィードバック情報は、ロッキング成功を表すように決定され、
当該ロッキング要求の当該ロッキングキューにおける待ち期間が第３の待ち閾値を超えるか、又はデッドロック検出が不合格である場合、当該ロッキングフィードバック情報は、ロッキング失敗を表すように決定される。
当該データ要求に対応するデータリソースをロッキングして、当該ロッキングフィードバック情報は、ロッキング成功を表すように決定され、
当該ロッキング要求の当該ロッキングキューにおける待ち期間が第３の待ち閾値を超えるか、又はデッドロック検出が不合格である場合、当該ロッキングフィードバック情報は、ロッキング失敗を表すように決定される。
【0202】
可能な実施形態において、図９の装置構造に基づいて、当該装置は、
当該第１のコンピューティング機器のデッドロック検出メッセージに応答して、当該ロッキング要求に対してロカールデッドロック検出を行う検出モジュールと、
ロカールデッドロック検出が不合格である場合、デッドロック検出が不合格であると決定する第１の決定モジュールと、
ロカールデッドロック検出が合格である場合、当該ロッキング要求のロック待ちリンクを決定する第２の決定モジュールであって、当該ロック待ちリンクは当該ロッキング要求と依存関係を有するロック情報を含む第２の決定モジュールと、をさらに含み、
当該送信モジュール９０３はさらに、当該ロック待ちリンクが遠位ロックを含む場合、当該遠位ロックを発信する第３のコンピューティング機器にデッドロック検出メッセージを送信し、当該遠位ロックは当該第２のコンピューティング機器に登録されているロック情報であるが、当該第２のコンピューティング機器により発信されるロック情報ではなく、
当該第１の決定モジュールはさらに、当該デッドロック検出メッセージを送信する何れか１つのコンピューティング機器が当該デッドロック検出メッセージを再び受信した場合、デッドロック検出が不合格であると決定する。
当該第１のコンピューティング機器のデッドロック検出メッセージに応答して、当該ロッキング要求に対してロカールデッドロック検出を行う検出モジュールと、
ロカールデッドロック検出が不合格である場合、デッドロック検出が不合格であると決定する第１の決定モジュールと、
ロカールデッドロック検出が合格である場合、当該ロッキング要求のロック待ちリンクを決定する第２の決定モジュールであって、当該ロック待ちリンクは当該ロッキング要求と依存関係を有するロック情報を含む第２の決定モジュールと、をさらに含み、
当該送信モジュール９０３はさらに、当該ロック待ちリンクが遠位ロックを含む場合、当該遠位ロックを発信する第３のコンピューティング機器にデッドロック検出メッセージを送信し、当該遠位ロックは当該第２のコンピューティング機器に登録されているロック情報であるが、当該第２のコンピューティング機器により発信されるロック情報ではなく、
当該第１の決定モジュールはさらに、当該デッドロック検出メッセージを送信する何れか１つのコンピューティング機器が当該デッドロック検出メッセージを再び受信した場合、デッドロック検出が不合格であると決定する。
【0203】
可能な実施形態において、当該追加モジュール９０１は、
当該第２のコンピューティング機器上のメッセージ処理スレッドによって当該ロッキング要求を受信し、
当該メッセージ処理スレッドによって、当該ロッキング要求に対応するロックプロキシスレッドを起動させ、
当該ロックプロキシスレッドによって、当該ロッキング要求を当該ロッキングキューに追加する。
当該第２のコンピューティング機器上のメッセージ処理スレッドによって当該ロッキング要求を受信し、
当該メッセージ処理スレッドによって、当該ロッキング要求に対応するロックプロキシスレッドを起動させ、
当該ロックプロキシスレッドによって、当該ロッキング要求を当該ロッキングキューに追加する。
【0204】
可能な実施形態において、図９の装置構造に基づいて、当該装置は、
当該データ要求に対応するデータリソースをロッキングする場合、当該データ要求に対応するロック情報を登録する登録モジュールと、
ターゲット期間ごとに、前記ロック情報がアクティブなロック情報であるかどうかを確定する第３の決定モジュールと、をさらに含み、
当該送信モジュール９０３はさらに、当該ロック情報がアクティブなロック情報であり、且つ当該データ要求に対応するデータリソースのロッキング期間が死活監視閾値を超える場合、当該第１のコンピューティング機器に死活監視要求を送信し、当該死活監視要求は、当該データリソースを解除するかどうかを指示するように、当該第１のコンピューティング機器に要求する。
当該データ要求に対応するデータリソースをロッキングする場合、当該データ要求に対応するロック情報を登録する登録モジュールと、
ターゲット期間ごとに、前記ロック情報がアクティブなロック情報であるかどうかを確定する第３の決定モジュールと、をさらに含み、
当該送信モジュール９０３はさらに、当該ロック情報がアクティブなロック情報であり、且つ当該データ要求に対応するデータリソースのロッキング期間が死活監視閾値を超える場合、当該第１のコンピューティング機器に死活監視要求を送信し、当該死活監視要求は、当該データリソースを解除するかどうかを指示するように、当該第１のコンピューティング機器に要求する。
【0205】
可能な実施形態において、図９の装置構造に基づいて、当該装置は、
当該データ要求に関連付けられるロック解除要求に応答して、当該データ要求に対応するデータリソースを解除する解除モジュールをさらに含む。
当該データ要求に関連付けられるロック解除要求に応答して、当該データ要求に対応するデータリソースを解除する解除モジュールをさらに含む。
【0206】
上記の全ての好適な技術案に対して、何れも任意の組み合わせを採用して本開示の好適な実施例を形成でき、ここで、贅言しない。
【0207】
ここで、上記の実施例が提供する要求処理装置はデータ要求を処理する時、上記の各機能モジュールの区画に対して例を挙げて記載したが、実際の適用においては、ニーズに基づいて、異なる機能モジュールによって完成するように、上記の機能を割り当て、即ち、コンピューティング機器の内部構造を、異なる機能モジュールに区画することで、以上に記載的の全ての又は一部機能を完成する。また、上記の実施例が提供する要求処理装置は、要求処理方法の実施例と同一構想に属するため、その具体的な実現過程について、要求処理方法の実施例を参照すればよく、ここで贅言しない。
【0208】
図１０は、本出願の実施例が提供するコンピューティング機器の構造概略図であり、コンピューティング機器が端末１０００であることを例として説明する。任意選択で、当該端末１０００の機器タイプは、スマートフォン、タブレットコンピューター、ＭＰ３再生装置（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ Ａｕｄｉｏ Ｌａｙｅｒ ＩＩＩ、動画専門家集団オーディオレイヤー３再生装置）、ＭＰ４（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ Ａｕｄｉｏ Ｌａｙｅｒ ＩＶ、動画専門家集団オーディオレイヤー４再生装置）再生装置、ノートパソコン又はデスクトップを含む。端末１０００はさらにユーザー機器、ポータブル端末、ラップトップ端末、デスクトップ端末などの他の名称と呼ばれてもよい。
【0209】
一般的に、端末１０００はプロセッサー１００１及びメモリ１００２を含む。
【0210】
任意選択で、プロセッサー１００１は１つ又は複数の処理コア、例えば４コアプロセッサー、８コアプロセッサーなどを含む。好ましくは、プロセッサー１００１はＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ、デジタル信号処理）、ＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ、フィールドプログラマブルゲートアレイ）、ＰＬＡ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ａｒｒａｙ、プログラマブルロジックアレイ）のうちの少なくとも１つのハードウェア形態で実現されてもよい。いくつかの実施例において、プロセッサー１００１はウェイクアップ状態でのデータを処理するプロセッサー、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央演算処理装置）とも呼ばれるメインプロセッサー、及び待機状態でのデータを処理する低電力消費プロセッサーであるコプロセッサーを含む。いくつかの実施例において、プロセッサー１００１にはＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、グラフィックプロセッサー）が集積され、ＧＰＵは、ディスプレイの表示対象となるコンテンツのレンダリング及び描画を行う。いくつかの実施例において、プロセッサー１００１はＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ、人工智能）プロセッサーをさらに含み、当該ＡＩプロセッサーは機械学習に関するコンピューティング操作を処理する。
【0211】
いくつかの実施例において、メモリ１００２は１つ又は複数のコンピュータ可読記憶媒体を含み、好ましくは、当該コンピュータ可読記憶媒体は非一時的なものである。好ましくは、メモリ１００２は高速ランダムアクセスメモリ、及び不揮発性メモリ、例えば１つ又は複数の磁気ディスク記憶機器、フラッシュ記憶機器をさらに含んでもよい。いくつかの実施例において、メモリ１００２における非一時的コンピュータ可読記憶媒体は少なくとも１つのプログラムコードを記憶し、当該少なくとも１つのプログラムコードはプロセッサー１００１によって実行されることで、本出願における各実施例が提供する要求処理方法を実現する。
【0212】
いくつかの実施例において、端末１０００は周辺機器インターフェース１００３及び少なくとも１つの周辺機器をさらに含む。プロセッサー１００１、メモリ１００２及び周辺機器インターフェース１００３の間はバス又は信号線を介して連結される。各周辺機器はバス、信号線又は回路基板を介して周辺機器インターフェース１００３に連結される。具体的に、周辺機器は無線周波数回路１００４、ディスプレイ１００５、カメラコンポーネント１００６、オーディオ回路１００７、位置決めコンポーネント１００８及び電源１００９のうちの少なくとも１つを含む。
【0213】
いくつかの実施例において、端末１０００は１つ又は複数のセンサー１０１０をさらに含む。当該１つ又は複数のセンサー１０１０は、加速度センサー１０１１、ジャイロセンサー１０１２、圧力センサー１０１３、指紋センサー１０１４、光センサー１０１５及び近接センサー１０１６を含むが、これらに限定されない。
【0214】
当業者であれば理解できるように、図１０の構造は端末１０００を限定せず、図示より多く又は少ないコンポーネントを含んでもよいし、又はいくつかのコンポーネントを組み合わせてもよいし、或いは異なっているコンポーネントを使用して配置してもよい。
【0215】
図１１は、本出願の実施例が提供するコンピューティング機器の構造概略図であり、配置又は性能により、当該コンピューティング機器１１００には大きな差が生じる可能性があり、当該コンピューティング機器１１００は１つ又は１つ以上のプロセッサー（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔｓ、ＣＰＵ）１１０１及び１つ又は１つ以上のメモリ１１０２を含み、当該メモリ１１０２には少なくとも１つのコンピュータプログラムが記憶され、当該少なくとも１つのコンピュータプログラムは当該１つ又は１つ以上プロセッサー１１０１によって読み込まれて実行されることで、上記の各実施例が提供する要求処理方法を実現する。任意選択で、当該コンピューティング機器１１００は入出力を行うための有線又は無線ネットワークインターフェース、キーボード及び入出力インターフェースなどの部材をさらに具備し、当該コンピューティング機器１１００は、機器機能を実現する他の部材をさらに含み、ここで、贅言しない。
【0216】
例示的な実施例において、コンピュータ可読記憶媒体、例えば少なくとも１つのコンピュータプログラムを含むメモリをさらに提供し、上記の少なくとも１つのコンピュータプログラムは端末におけるプロセッサーによって実行されることで、上記の各実施例における要求処理方法を完成する。例えば、当該コンピュータ可読記憶媒体はＲＯＭ（Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ、読み取り専用メモリ）、ＲＡＭ（Ｒａｎｄｏｍ－Ａｃｃｅｓｓ Ｍｅｍｏｒｙ、ランダムアクセスメモリ）、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ、読み取り専用光ディスク）、磁気テープ、フレキシブルディスク及び光データ記憶機器などを含む。
【0217】
例示的な実施例において、コンピュータプログラム製品又はコンピュータプログラムをさらに提供し、１つ又は複数のプログラムコードを含み、当該１つ又は複数のプログラムコードはコンピュータ可読記憶媒体に記憶される。コンピューティング機器の１つ又は複数のプロセッサーはコンピュータ可読記憶媒体から当該１つ又は複数のプログラムコードを読み取り、当該１つ又は複数のプロセッサーは当該１つ又は複数のプログラムコードを実行することで、コンピューティング機器に上記の実施例における要求処理方法を実行させて完成させる。
【0218】
当業者であれば理解できるように、上記の実施例の全て又は一部のステップの実現は、ハードウェアによって完成されてもよいし、プログラムによって完成するように、関連ハードウェアに命令してもよく、任意選択で、当該プログラムはコンピュータ可読記憶媒体に記憶され、任意選択で、上記に言及された記憶媒体は読み取り専用メモリ、磁気ディスク又は光ディスクなどである。
【0219】
以上は本出願を限定していなく、本出願の好適な実施例に過ぎず、本出願の精神及び原則内で完成した任意の修正、均等な置換、改善などは何れも本出願の保護範囲内に含まれる。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【国際調査報告】