知財求人 - 知財ポータルサイト「IP Force」
▶ テンセント・テクノロジー・（シェンジェン）・カンパニー・リミテッドの特許一覧
特表2024-501245ログ実行方法並びにその、装置、コンピュータ機器及びコンピュータプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-01-11
(54)【発明の名称】ログ実行方法並びにその、装置、コンピュータ機器及びコンピュータプログラム
(51)【国際特許分類】
G06F 16/27 20190101AFI20231228BHJP
【ＦＩ】
G06F16/27
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2023537944
(86)(22)【出願日】2022-01-26
(85)【翻訳文提出日】2023-06-29
(86)【国際出願番号】 CN2022074080
(87)【国際公開番号】W WO2022170979
(87)【国際公開日】2022-08-18
(31)【優先権主張番号】202110178645.4
(32)【優先日】2021-02-09
(33)【優先権主張国・地域又は機関】CN
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
２．ＨＡＤＯＯＰ
３．ＣＥＰＨ
４．ＡＬＬＵＸＩＯ
(71)【出願人】
【識別番号】514187420
【氏名又は名称】テンセント・テクノロジー・（シェンジェン）・カンパニー・リミテッド
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】リー，ハイシャン
(72)【発明者】
【氏名】リー，ハオファ
【テーマコード（参考）】
5B175
【Ｆターム（参考）】
5B175AA01
5B175CA09
5B175EA03
5B175KA08
(57)【要約】
ログ実行方法、装置、コンピュータ機器及び記憶媒体であって、データベース技術分野に関している。方法は、ログ実行アクティブウィンドウを循環的にスキャンするステップ（３０１）と、ログ実行アクティブウィンドウにおける何れか１つのログに対して、当該ログの記憶範囲情報に基づいて、当該ログの競合検証結果を取得するステップ（３０２）であって、当該記憶範囲情報は当該ログ及び当該ログより前のターゲット数のログの記憶範囲を指示し、当該ターゲット数は当該ログ実行アクティブウィンドウのウィンドウサイズに等しいステップ（３０２）と、当該競合検証結果が競合なしである場合、当該ログを実行するステップ（３０３）と、を含む。
【特許請求の範囲】
【請求項1】
分散型記憶システムにおける第１ノード機器が実行するログ実行方法であって、前記ログ実行方法は、ログ実行アクティブウィンドウを循環的にスキャンするステップであって、前記ログ実行アクティブウィンドウには未実行の複数のログが含まれ、且つ前記ログ実行アクティブウィンドウより前のログは何れも実行済みである、ステップと、
前記ログ実行アクティブウィンドウにおける何れか１つのログに対して、前記ログの記憶範囲情報に基づいて、前記ログの競合検証結果を取得するステップであって、前記記憶範囲情報は前記ログの記憶範囲及び前記ログより前のターゲット数のログの記憶範囲を指示し、前記ターゲット数は前記ログ実行アクティブウィンドウのウィンドウサイズに等しい、ステップと、
前記競合検証結果が競合なしである場合、前記ログを実行するステップと、を含むログ実行方法。
【請求項2】
前記ログの記憶範囲情報に基づいて、前記ログの競合検証結果を取得するステップは、前記ログの記憶範囲情報を読み取って、前記ログ及び前記ログより前のターゲット数のログの記憶範囲を取得するステップと、
前記ログの記憶範囲と前記ターゲット数のログの記憶範囲との間の共通部分が空集合である場合、前記競合検証結果が競合なしであると決定するステップと、
前記ログの記憶範囲と前記ターゲット数のログの記憶範囲との間の共通部分が空集合ではない場合、前記競合検証結果が競合ありであると決定するステップと、を含む請求項１に記載のログ実行方法。
【請求項3】
前記ログを実行するステップは、前記ログを実行対象ログリストに追加するステップと、
ログ実行スレッドを呼び出し、前記実行対象ログリストに記憶されたログを処理するステップと、を含む請求項１に記載のログ実行方法。
【請求項4】
前記実行対象ログリストに記憶されたログを処理するステップは、前記実行対象ログリストに記憶されたログに対応するサービスデータを揮発性記憶媒体に書き込むステップと、
前記揮発性記憶媒体に書き込まれた前記サービスデータに対応するログを実行済みログリストに追加するステップと、
前記揮発性記憶媒体のデータ記憶量が記憶閾値以上である場合、前記揮発性記憶媒体に記憶されたサービスデータを不揮発性記憶媒体に書き込むステップと、を含み、
前記実行済みログリストにおいて、サービスデータが不揮発性記憶媒体に書き込まれていないログ、及びサービスデータが不揮発性記憶媒体に書き込まれたログに対して異なる状態パラメータをそれぞれ配置する請求項３に記載のログ実行方法。
【請求項5】
前記ログ実行方法は、前記分散型記憶システムはクラッシュイベントが生じた場合、前記分散型記憶システムが再起動する時、前記状態パラメータに基づいて、複数の回復対象ログを前記実行済みログリストから取得するステップであって、前記回復対象ログに対応するサービスデータは前記揮発性記憶媒体に書き込まれたが、前記不揮発性記憶媒体に書き込まれていない、ステップと、
複数の前記回復対象ログの、前記実行済みログリストにおける記憶順序に基づいて、複数の前記回復対象ログに対応する複数のサービスデータを前記揮発性記憶媒体に順に回復するステップと、をさらに含む請求項４に記載のログ実行方法。
【請求項6】
前記ログ実行方法は、前記競合検証結果が競合ありである場合、前記ログと競合したログ数を取得するステップと、
前記ログ数に基づいて、前記ログに対するスキャン頻度を決定するステップと、
前記スキャン頻度に基づいて前記ログをスキャンして前記競合検証結果をリフレッシュし、前記競合検証結果が競合なしになるまで、前記ログを実行するステップと、をさらに含む請求項１に記載のログ実行方法。
【請求項7】
前記ログ数に基づいて、前記ログに対するスキャン頻度を決定するステップは、前記ログ数が競合閾値より大きい場合、前記スキャン頻度を第１頻度に決定するステップ、又は、
前記ログ数が前記競合閾値以下である場合、前記スキャン頻度を第２頻度に決定するステップであって、前記第２頻度は前記第１頻度より大きい、ステップを含む請求項６に記載のログ実行方法。
【請求項8】
前記スキャン頻度に基づいて前記ログをスキャンするステップは、前記ログを前記スキャン頻度に対応するログリストに追加し、前記スキャン頻度に基づいて前記ログリストに記憶されたログをスキャンするステップを含む請求項６に記載のログ実行方法。
【請求項9】
前記ログ実行方法は、ログマッチングインデックステーブルを循環的にスキャンするステップであって、前記ログマッチングインデックステーブルは複数の提出対象ログが前記分散型記憶システムに記憶したコピー数を記録する、ステップと、
前記ログマッチングインデックステーブルにおける何れか１つの提出対象ログのコピー数がターゲット条件に合う場合、前記提出対象ログを提出するステップと、をさらに含む請求項１に記載のログ実行方法。
【請求項10】
前記第１ノード機器は前の任期が終了した後、前記分散型記憶システムにおける複数の第２ノード機器が投票して選挙することで生成され、前記第１ノード機器における連続的且つ提出済みのログの最大インデックスは複数の前記第２ノード機器における連続的且つ提出済みのログの最大インデックスの以上である請求項１に記載のログ実行方法。
【請求項11】
前記ログ実行方法は、ログ提出アクティブウィンドウには少なくとも１つのログが欠如した場合、各欠如したログのインデックスを取得するステップであって、前記ログ提出アクティブウィンドウは未提出の複数のログを含み、前記ログ提出アクティブウィンドウより前のログは何れも提出済みである、ステップと、
前記インデックスに基づいて、複数の前記第２ノード機器に前記欠如したログを要求するステップと、をさらに含む請求項１０に記載のログ実行方法。
【請求項12】
前記ログ実行方法は、複数の前記第２ノード機器から戻されたターゲットログ及び前記ターゲットログの提出状況情報を受信するステップと、
提出状況情報が提出済みであるターゲットログを前記ログ提出アクティブウィンドウに補足するステップと、
提出状況情報が未提出であるターゲットログを端末に要求するステップと、をさらに含む請求項１１に記載のログ実行方法。
【請求項13】
分散型記憶システムにおけるログ実行装置であって、前記ログ実行装置は、ログ実行アクティブウィンドウを循環的にスキャンするスキャンモジュールであって、前記ログ実行アクティブウィンドウには未実行の複数のログが含まれ、且つ前記ログ実行アクティブウィンドウより前のログは何れも実行済みである、スキャンモジューと、
前記ログ実行アクティブウィンドウにおける何れか１つのログに対して、前記ログの記憶範囲情報に基づいて、前記ログの競合検証結果を取得する第１取得モジュールであって、前記記憶範囲情報は前記ログの記憶範囲及び前記ログより前のターゲット数のログの記憶範囲を指示し、前記ターゲット数は前記ログ実行アクティブウィンドウのウィンドウサイズに等しい、第１取得モジュールと、
前記競合検証結果が競合なしである場合、前記ログを実行する実行モジュールと、を含む、ログ実行装置。
【請求項14】
コンピュータ機器であって、前記コンピュータ機器は１つ又は複数のプロセッサー及び１つ又は複数のメモリを含み、前記１つ又は複数のメモリには少なくとも１本のコンピュータプログラムが記憶され、前記少なくとも１本のコンピュータプログラムは前記１つ又は複数のプロセッサーによって読み込まれて、実行されることで、請求項１～請求項１２の何れか１項に記載のログ実行方法を実現する、コンピュータ機器。
【請求項15】
プロセッサーによって読み込まれて、実行されることで、請求項１～請求項１２の何れか１項に記載のログ実行方法を実現させる、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本出願は２０２１年０２月０９日にて提出された、出願番号が２０２１１０１７８６４５.４であり、発明名称が「ログ実行方法、装置、コンピュータ機器及び記憶媒体」である中国特許出願の優先権を主張して、その全ての内容は本出願に援用されている。
【0002】
本出願はデータベースの技術分野に関して、特にログ実行方法並びにその、装置、コンピュータ機器及び記憶媒体に関している。
【背景技術】
【0003】
データベース技術の発展に連れて、産業グレードの分散型記憶システムに対して、提出された全ての修正が損失しないことを確保する必要があるため、一致性アルゴリズム（即ち、コンセンサスアルゴリズム）を導入することで、ファイルシステムにおけるデータの信頼性及び一致性を保証する。Ｒａｆｔアルゴリズムはエンジニアリングにおいて大幅に使用される一致性アルゴリズムであり、強い一致性、分散化、理解及び開発・実現しやすいなどの特点を備える。
【発明の概要】
【発明が解決しようとする課題】
【0004】
本出願の実施例はログ実行方法、装置、コンピュータ機器及び記憶媒体を提供している。
【課題を解決するための手段】
【0005】
１つの態様によれば、分散型記憶システムにおける第１ノード機器が実行するログ実行方法を提供し、当該方法は、
ログ実行アクティブウィンドウを循環的にスキャンするステップであって、前記ログ実行アクティブウィンドウには未実行の複数のログが含まれ、且つ前記ログ実行アクティブウィンドウより前のログは何れも実行済みである、ステップと、
前記ログ実行アクティブウィンドウにおける何れか１つのログに対して、前記何れか１つのログの記憶範囲情報に基づいて、前記何れか１つのログの競合検証結果を取得するステップであって、前記記憶範囲情報は前記何れか１つのログの記憶範囲及び前記何れか１つのログより前のターゲット数のログの記憶範囲を指示し、前記ターゲット数は前記ログ実行アクティブウィンドウのウィンドウサイズに等しい、ステップと、
前記競合検証結果が競合なしであることに応答し、前記何れか１つのログを実行するステップと、を含む。
ログ実行アクティブウィンドウを循環的にスキャンするステップであって、前記ログ実行アクティブウィンドウには未実行の複数のログが含まれ、且つ前記ログ実行アクティブウィンドウより前のログは何れも実行済みである、ステップと、
前記ログ実行アクティブウィンドウにおける何れか１つのログに対して、前記何れか１つのログの記憶範囲情報に基づいて、前記何れか１つのログの競合検証結果を取得するステップであって、前記記憶範囲情報は前記何れか１つのログの記憶範囲及び前記何れか１つのログより前のターゲット数のログの記憶範囲を指示し、前記ターゲット数は前記ログ実行アクティブウィンドウのウィンドウサイズに等しい、ステップと、
前記競合検証結果が競合なしであることに応答し、前記何れか１つのログを実行するステップと、を含む。
【0006】
１つの態様によれば、分散型記憶システムに適用されるログ実行装置を提供し、当該装置は、
ログ実行アクティブウィンドウを循環的にスキャンするスキャンモジュールであって、前記ログ実行アクティブウィンドウには未実行の複数のログが含まれ、且つ前記ログ実行アクティブウィンドウより前のログは何れも実行済みである、スキャンモジュールと、
前記ログ実行アクティブウィンドウにおける何れか１つのログに対して、前記何れか１つのログの記憶範囲情報に基づいて、前記何れか１つのログの競合検証結果を取得する第１取得モジュールであって、前記記憶範囲情報は前記何れか１つのログの記憶範囲及び前記何れか１つのログより前のターゲット数のログの記憶範囲を指示し、前記ターゲット数は前記ログ実行アクティブウィンドウのウィンドウサイズに等しい、第１取得モジュールと、
前記競合検証結果が競合なしであることに応答し、前記何れか１つのログを実行する実行モジュールと、を含む。
ログ実行アクティブウィンドウを循環的にスキャンするスキャンモジュールであって、前記ログ実行アクティブウィンドウには未実行の複数のログが含まれ、且つ前記ログ実行アクティブウィンドウより前のログは何れも実行済みである、スキャンモジュールと、
前記ログ実行アクティブウィンドウにおける何れか１つのログに対して、前記何れか１つのログの記憶範囲情報に基づいて、前記何れか１つのログの競合検証結果を取得する第１取得モジュールであって、前記記憶範囲情報は前記何れか１つのログの記憶範囲及び前記何れか１つのログより前のターゲット数のログの記憶範囲を指示し、前記ターゲット数は前記ログ実行アクティブウィンドウのウィンドウサイズに等しい、第１取得モジュールと、
前記競合検証結果が競合なしであることに応答し、前記何れか１つのログを実行する実行モジュールと、を含む。
【0007】
可能な実施形態において、前記第１取得モジュールは、
前記何れか１つのログの記憶範囲情報を読み取って、前記何れか１つのログ及び前記何れか１つのログより前のターゲット数のログの記憶範囲を取得し、
前記何れか１つのログの記憶範囲と前記ターゲット数のログの記憶範囲との間の共通部分が空集合であることに応答し、前記競合検証結果が競合なしであると決定し、
前記何れか１つのログの記憶範囲と前記ターゲット数のログの記憶範囲との間の共通部分が空集合ではないことに応答し、前記競合検証結果が競合ありであると決定する。
前記何れか１つのログの記憶範囲情報を読み取って、前記何れか１つのログ及び前記何れか１つのログより前のターゲット数のログの記憶範囲を取得し、
前記何れか１つのログの記憶範囲と前記ターゲット数のログの記憶範囲との間の共通部分が空集合であることに応答し、前記競合検証結果が競合なしであると決定し、
前記何れか１つのログの記憶範囲と前記ターゲット数のログの記憶範囲との間の共通部分が空集合ではないことに応答し、前記競合検証結果が競合ありであると決定する。
【0008】
可能な実施形態において、前記実行モジュールは、
前記何れか１つのログを実行対象ログリストに追加する追加ユニットと、
ログ実行スレッドを呼び出し、前記実行対象ログリストに記憶されたログを処理する処理ユニットと、を含む。
前記何れか１つのログを実行対象ログリストに追加する追加ユニットと、
ログ実行スレッドを呼び出し、前記実行対象ログリストに記憶されたログを処理する処理ユニットと、を含む。
【0009】
可能な実施形態において、前記処理ユニットは、
前記実行対象ログリストに記憶されたログに対応するサービスデータを揮発性記憶媒体に書き込んで、
前記揮発性記憶媒体に書き込まれた前記サービスデータに対応するログを実行済みログリストに追加し、
前記揮発性記憶媒体のデータ記憶量が記憶閾値以上であることに応答し、前記揮発性記憶媒体に記憶されたサービスデータを不揮発性記憶媒体に書き込んで、
前記実行済みログリストにおいて、サービスデータが不揮発性記憶媒体に書き込まれていないログ、及びサービスデータが不揮発性記憶媒体に書き込まれたログに対して異なる状態パラメータをそれぞれ配置する。
前記実行対象ログリストに記憶されたログに対応するサービスデータを揮発性記憶媒体に書き込んで、
前記揮発性記憶媒体に書き込まれた前記サービスデータに対応するログを実行済みログリストに追加し、
前記揮発性記憶媒体のデータ記憶量が記憶閾値以上であることに応答し、前記揮発性記憶媒体に記憶されたサービスデータを不揮発性記憶媒体に書き込んで、
前記実行済みログリストにおいて、サービスデータが不揮発性記憶媒体に書き込まれていないログ、及びサービスデータが不揮発性記憶媒体に書き込まれたログに対して異なる状態パラメータをそれぞれ配置する。
【0010】
可能な実施形態において、前記装置は、
前記分散型記憶システムにはクラッシュイベントが生じたことに応答し、前記分散型記憶システムが再起動する時、前記状態パラメータに基づいて、複数の回復対象ログを前記実行済みログリストから取得する第２取得モジュールであって、前記複数の回復対象ログに対応する複数のサービスデータは前記揮発性記憶媒体に書き込まれたが、前記不揮発性記憶媒体に書き込まれていない、第２取得モジュールと、
前記複数の回復対象ログの、前記実行済みログリストにおける記憶順序に基づいて、前記複数の回復対象ログに対応する複数のサービスデータを前記揮発性記憶媒体に順に回復する回復モジュールと、をさらに含む。
前記分散型記憶システムにはクラッシュイベントが生じたことに応答し、前記分散型記憶システムが再起動する時、前記状態パラメータに基づいて、複数の回復対象ログを前記実行済みログリストから取得する第２取得モジュールであって、前記複数の回復対象ログに対応する複数のサービスデータは前記揮発性記憶媒体に書き込まれたが、前記不揮発性記憶媒体に書き込まれていない、第２取得モジュールと、
前記複数の回復対象ログの、前記実行済みログリストにおける記憶順序に基づいて、前記複数の回復対象ログに対応する複数のサービスデータを前記揮発性記憶媒体に順に回復する回復モジュールと、をさらに含む。
【0011】
可能な実施形態において、前記装置は、
前記競合検証結果が競合ありであることに応答し、前記何れか１つのログと競合したログ数を取得する第３取得モジュールと、
前記ログ数に基づいて、前記何れか１つのログに対するスキャン頻度を決定する決定モジュールと、をさらに含み、
前記実行モジュールはさらに、前記スキャン頻度に従って前記何れか１つのログをスキャンし、前記競合検証結果をリフレッシュして、前記競合検証結果が競合なしになるまで、前記何れか１つのログを実行する。
前記競合検証結果が競合ありであることに応答し、前記何れか１つのログと競合したログ数を取得する第３取得モジュールと、
前記ログ数に基づいて、前記何れか１つのログに対するスキャン頻度を決定する決定モジュールと、をさらに含み、
前記実行モジュールはさらに、前記スキャン頻度に従って前記何れか１つのログをスキャンし、前記競合検証結果をリフレッシュして、前記競合検証結果が競合なしになるまで、前記何れか１つのログを実行する。
【0012】
可能な実施形態において、前記決定モジュールは、
前記ログ数が競合閾値より大きいことに応答し、前記スキャン頻度を第１頻度に決定し、又は、
前記ログ数が前記競合閾値以下であることに応答し、前記スキャン頻度を第２頻度に決定し、前記第２頻度は前記第１頻度より大きい。
前記ログ数が競合閾値より大きいことに応答し、前記スキャン頻度を第１頻度に決定し、又は、
前記ログ数が前記競合閾値以下であることに応答し、前記スキャン頻度を第２頻度に決定し、前記第２頻度は前記第１頻度より大きい。
【0013】
可能な実施形態において、前記実行モジュールは、
前記何れか１つのログを前記スキャン頻度に対応するログリストに追加し、前記スキャン頻度に従って前記ログリストに記憶されたログをスキャンする。
前記何れか１つのログを前記スキャン頻度に対応するログリストに追加し、前記スキャン頻度に従って前記ログリストに記憶されたログをスキャンする。
【0014】
可能な実施形態において、前記スキャンモジュールはさらに、ログマッチングインデックステーブルを循環的にスキャンし、前記ログマッチングインデックステーブルは複数の提出対象ログが前記分散型記憶システムに記憶したコピー数を記録し、
前記装置は、前記ログマッチングインデックステーブルにおける何れか１つの提出対象ログのコピー数がターゲット条件に合うに応答し、前記何れか１つの提出対象ログを提出する提出モジュールをさらに含む。
前記装置は、前記ログマッチングインデックステーブルにおける何れか１つの提出対象ログのコピー数がターゲット条件に合うに応答し、前記何れか１つの提出対象ログを提出する提出モジュールをさらに含む。
【0015】
可能な実施形態において、前記装置は、前の任期が終了した後、前記分散型記憶システムにおける複数の第２ノード機器が投票して選挙することで生成され、前記装置における連続的且つ提出済みのログの最大インデックスは前記複数の第２ノード機器における連続的且つ提出済みのログの最大インデックスの以上である。
【0016】
可能な実施形態において、前記装置は、
ログ提出アクティブウィンドウにおいて少なくとも１つのログが欠如することに応答し、欠如した前記少なくとも１つのログの少なくとも１つのインデックスを取得する第４取得モジュールであって、前記ログ提出アクティブウィンドウは未提出の複数のログを含み、前記ログ提出アクティブウィンドウより前のログは何れも提出済みである、第４取得モジュールと、
前記少なくとも１つのインデックスに基づいて、前記複数の第２ノード機器に前記少なくとも１つのログを要求する要求モジュールと、をさらに含む。
ログ提出アクティブウィンドウにおいて少なくとも１つのログが欠如することに応答し、欠如した前記少なくとも１つのログの少なくとも１つのインデックスを取得する第４取得モジュールであって、前記ログ提出アクティブウィンドウは未提出の複数のログを含み、前記ログ提出アクティブウィンドウより前のログは何れも提出済みである、第４取得モジュールと、
前記少なくとも１つのインデックスに基づいて、前記複数の第２ノード機器に前記少なくとも１つのログを要求する要求モジュールと、をさらに含む。
【0017】
可能な実施形態において、前記装置は、
前記複数の第２ノード機器から戻された少なくとも１つのターゲットログ及び前記少なくとも１つのターゲットログの提出状況情報を受信する受信モジュールと、
提出状況情報が提出済みであるターゲットログを前記ログ提出アクティブウィンドウに補足する補足モジュールと、をさらに含み、
前記要求モジュールはさらに、提出状況情報が未提出であるターゲットログを端末に要求する。
前記複数の第２ノード機器から戻された少なくとも１つのターゲットログ及び前記少なくとも１つのターゲットログの提出状況情報を受信する受信モジュールと、
提出状況情報が提出済みであるターゲットログを前記ログ提出アクティブウィンドウに補足する補足モジュールと、をさらに含み、
前記要求モジュールはさらに、提出状況情報が未提出であるターゲットログを端末に要求する。
【0018】
１つの態様によれば、コンピュータ機器を提供し、当該コンピュータ機器１つ又は複数のプロセッサー及び１つ又は複数のメモリを含み、当該１つ又は複数のメモリには少なくとも１本のコンピュータプログラムが記憶され、当該少なくとも１本のコンピュータプログラムは当該１つ又は複数のプロセッサーによって読み込まれて、実行されることで、上記のログ実行方法を実現する。
【0019】
１つの態様によれば、記憶媒体を提供し、当該記憶媒体には少なくとも１本のコンピュータプログラムが記憶され、当該少なくとも１本のコンピュータプログラムはプロセッサーによって読み込まれて、実行されることで、上記のログ実行方法を実現する。
【0020】
１つの態様によれば、コンピュータプログラム製品又はコンピュータプログラムを提供し、前記コンピュータプログラム製品又は前記コンピュータプログラムは１本又は複数本のプログラムコードを含み、前記１本又は複数本のプログラムコードはコンピュータ可読記憶媒体に記憶される。コンピュータ機器の１つ又は複数のプロセッサーはコンピュータ可読記憶媒体から前記１本又は複数本のプログラムコードを読み取って、前記１つ又は複数のプロセッサーは前記１本又は複数本のプログラムコードを実行することで、コンピュータ機器に上記のログ実行方法を実行させる。
【図面の簡単な説明】
【0021】
【図1】本出願の実施例が提供する分散型記憶システムのアーキテクチャ概略図である。
【図2】本出願の実施例が提供するログの順不同複製メカニズムの原理概略図である。
【図3】本出願の実施例が提供するログ実行方法のフローチャートである。
【図4】本出願の実施例が提供するＬＨＡデータ構造の原理概略図である。
【図5】本出願の実施例が提供するデータ持続化メカニズムの原理概略図である。
【図6】本出願の実施例が提供するログの順不同実行・スケジューリングの原理概略図である。
【図7】本出願の実施例が提供するログ提出アクティブウィンドウのデータ構造概略図である。
【図8】本出願の実施例が提供するログ順不同提出メカニズムのフローチャートである。
【図9】本出願の実施例が提供するログが不一致である状況の原理概略図である。
【図10】本出願の実施例が提供するリーダーノードの選挙メカニズムの原理概略図である。
【図11】本出願の実施例が提供する任期Ｔｅｒｍの原理概略図である。
【図12】本出願の実施例が提供する端末とクラスタとのインタラクションの原理フローチャートである。
【図13】本出願の実施例が提供するログ実行装置の構造概略図である。
【図14】本出願の実施例が提供するコンピュータ機器の構造概略図である。
【発明を実施するための形態】
【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】
以下、分散型記憶システムにおいて、異なるノード機器の間でＲＰＣ通信を行うＡｐｐｅｎｄＥｎｔｒｉｅｓ
ＲＰＣ関数を示す：
／／第１ノード機器は呼び出すように、ログ複製要求を開始し、ハートビートとして機能してもよい
パラメータ：
／／第１ノード機器のＴｅｒｍ
ｉｎｔ
ｔｅｒｍ
／／第１ノード機器のｉｄ
ｉｎｔ
ｌｅａｄｅｒｉｄ
／／第１ノード機器でｃｏｍｍｉｔ済みのログ情報
ＣｏｍｍｉｔｅｄＬｏｇ
ｌｅａｄｅｒＣｏｍｍｉｔｓ［］
／／記憶対象ログ；（ＡｐｐｅｎｄＥｎｔｒｉｅｓ
ＲＰＣ関数はハートビート送信に用いられると、当該変数は空である）
ＬｏｇＥｎｔｒｙ
ｅｎｔｒｉｅｓ［］
戻る：
／／戻り値ｔｅｒｍは現在第２ノード機器のＴｅｒｍである
ｉｎｔ
ｃｕｒｒｅｎｔＴｅｒｍ
／／戻り値ｓｕｃｃｅｓｓは実行が成功したかどうかを記録する
ｂｏｏｌ
ｓｕｃｃｅｓｓ
受信者（第２ノード機器）は以下を実現する：
I）ｔｅｒｍ ＜ ｃｕｒｒｅｎｔＴｅｒｍであれば、ｆａｌｓｅを戻す。
II）自体のログｃｏｍｍｉｔアクティブウィンドウをトラバースし、当該範囲内で第１ノード機器のログが自体のログと競合した場合（ｉｎｄｅｘは同様であるが、ｔｅｒｍは異なっている）、当該第１ノード機器のログで自体のログを上書きし、当該範囲内で第１ノード機器は自体の欠如したログを送信した場合、当該ログをｉｎｄｅｘに対応する位置に上書きする；
III）自体のログｃｏｍｍｉｔアクティブウィンドウをトラバースし、当該範囲内で第１ノード機器のログと一致した（ｉｎｄｅｘ及びｔｅｒｍは何れも同様）、第１ノード機器が既にｃｏｍｍｉｔしたログが存在すれば、当該ログをｃｏｍｍｉｔと記する
ＲＰＣ関数を示す：
／／第１ノード機器は呼び出すように、ログ複製要求を開始し、ハートビートとして機能してもよい
パラメータ：
／／第１ノード機器のＴｅｒｍ
ｉｎｔ
ｔｅｒｍ
／／第１ノード機器のｉｄ
ｉｎｔ
ｌｅａｄｅｒｉｄ
／／第１ノード機器でｃｏｍｍｉｔ済みのログ情報
ＣｏｍｍｉｔｅｄＬｏｇ
ｌｅａｄｅｒＣｏｍｍｉｔｓ［］
／／記憶対象ログ；（ＡｐｐｅｎｄＥｎｔｒｉｅｓ
ＲＰＣ関数はハートビート送信に用いられると、当該変数は空である）
ＬｏｇＥｎｔｒｙ
ｅｎｔｒｉｅｓ［］
戻る：
／／戻り値ｔｅｒｍは現在第２ノード機器のＴｅｒｍである
ｉｎｔ
ｃｕｒｒｅｎｔＴｅｒｍ
／／戻り値ｓｕｃｃｅｓｓは実行が成功したかどうかを記録する
ｂｏｏｌ
ｓｕｃｃｅｓｓ
受信者（第２ノード機器）は以下を実現する：
I）ｔｅｒｍ ＜ ｃｕｒｒｅｎｔＴｅｒｍであれば、ｆａｌｓｅを戻す。
II）自体のログｃｏｍｍｉｔアクティブウィンドウをトラバースし、当該範囲内で第１ノード機器のログが自体のログと競合した場合（ｉｎｄｅｘは同様であるが、ｔｅｒｍは異なっている）、当該第１ノード機器のログで自体のログを上書きし、当該範囲内で第１ノード機器は自体の欠如したログを送信した場合、当該ログをｉｎｄｅｘに対応する位置に上書きする；
III）自体のログｃｏｍｍｉｔアクティブウィンドウをトラバースし、当該範囲内で第１ノード機器のログと一致した（ｉｎｄｅｘ及びｔｅｒｍは何れも同様）、第１ノード機器が既にｃｏｍｍｉｔしたログが存在すれば、当該ログをｃｏｍｍｉｔと記する
【0202】
以下、分散型記憶システムにおいて、異なるノード機器の間でＲＰＣ通信を行うＲｅｑｕｅｓｔＶｏｔｅＲＰＣ関数を示し、以下のように説明する：
／／候補ノード機器は呼び出すように票を取得する
パラメータ：
／／候補ノード機器のＴｅｒｍ
ｉｎｔ
ｔｅｒｍ
／／候補ノード機器のｉｄ
ｉｎｔ
ｃａｎｄｉｄａｔｅＩｄ
／／候補ノード機器でｉｎｄｅｘがｃｏｍｍｉｔＩｎｄｅｘの以下のログは何れもｃｏｍｍｉｔ済みである
ｉｎｔ
ｃｏｍｍｉｔＩｎｄｅｘ
戻る：
／／戻り値ｔｅｒｍは現在ノードのＴｅｒｍである
ｉｎｔ
ｔｅｒｍ
／／戻り値ｖｏｔｅＧｒａｎｔｅｄは、当該ノードが当該ｃａｎｄｉｄａｔｅに投票したかどうかを示す
ｂｏｏｌ
ｖｏｔｅＧｒａｎｔｅｄ
受信者（第２ノード機器）は以下を実現する実現：
i）ｔｅｒｍ ＜ ｃｕｒｒｅｎｔＴｅｒｍであれば、ｆａｌｓｅを戻す
ii）ｖｏｔｅＦｏｒは空であり、且つ候補ノード機器のｃｏｍｍｉｔＩｎｄｅｘは自体のｃｏｍｍｉｔＩｎｄｅｘｍの以上であれば、当該候補ノード機器に投票する
／／候補ノード機器は呼び出すように票を取得する
パラメータ：
／／候補ノード機器のＴｅｒｍ
ｉｎｔ
ｔｅｒｍ
／／候補ノード機器のｉｄ
ｉｎｔ
ｃａｎｄｉｄａｔｅＩｄ
／／候補ノード機器でｉｎｄｅｘがｃｏｍｍｉｔＩｎｄｅｘの以下のログは何れもｃｏｍｍｉｔ済みである
ｉｎｔ
ｃｏｍｍｉｔＩｎｄｅｘ
戻る：
／／戻り値ｔｅｒｍは現在ノードのＴｅｒｍである
ｉｎｔ
ｔｅｒｍ
／／戻り値ｖｏｔｅＧｒａｎｔｅｄは、当該ノードが当該ｃａｎｄｉｄａｔｅに投票したかどうかを示す
ｂｏｏｌ
ｖｏｔｅＧｒａｎｔｅｄ
受信者（第２ノード機器）は以下を実現する実現：
i）ｔｅｒｍ ＜ ｃｕｒｒｅｎｔＴｅｒｍであれば、ｆａｌｓｅを戻す
ii）ｖｏｔｅＦｏｒは空であり、且つ候補ノード機器のｃｏｍｍｉｔＩｎｄｅｘは自体のｃｏｍｍｉｔＩｎｄｅｘｍの以上であれば、当該候補ノード機器に投票する
【0203】
以下、分散型記憶システムにおいて、異なるノード機器の間でＲＰＣ通信を行うＲｅｑｕｅｓｔＭｅｒｇｅＲＰＣ関数を示し、以下のように説明する：
／／新たな第１ノード機器の選挙が成功し、保証第１ノード機器ログリストにおけるログの連続性を保証するために、欠如したログを自体に送信するように第２ノード機器に要求する
パラメータ：
／／第１ノード機器のＴｅｒｍ
ｉｎｔ
ｔｅｒｍ
／／第１ノード機器のｉｄ
ｉｎｔ
ｌｅａｄｅｒｉｄ
／／第１ノード機器のログｃｏｍｍｉｔアクティブウィンドウ内のログがｃｏｍｍｉｔしたかどうかを記録する
ｉｎｔ
ｉｓＣｏｍｍｉｔｔｅｄ［］
戻る：
／／戻り値ｔｅｒｍは現在の第２ノード機器のＴｅｒｍである
ｉｎｔ
ｃｕｒｒｅｎｔＴｅｒｍ
／／第２ノード機器に戻され、ｃｏｍｍｉｔ済み且つｉｎｄｅｘが第１ノード機器ログｃｏｍｍｉｔアクティブウィンドウ範囲にあるログ
Ｌｏｇ
ｌｏｇｓ［］
／／第２ノード機器のログリストに戻されたログのｃｏｍｍｉｔ状況
ｂｏｏｌ
ｌｏｇｃｏｍｍｉｔｓ［］
受信者は以下を実現する：
（I）ｔｅｒｍ ＜ ｃｕｒｒｅｎｔＴｅｒｍであれば、ｃｕｒｒｅｎｔＴｅｒｍを戻す
（II）ｃｏｍｍｉｔ済みであり且つｉｎｄｅｘが第１ノード機器のログｃｏｍｍｉｔアクティブウィンドウ範囲内にあるログ、及びログリストにおけるログのｃｏｍｍｉｔ状況を戻す
／／新たな第１ノード機器の選挙が成功し、保証第１ノード機器ログリストにおけるログの連続性を保証するために、欠如したログを自体に送信するように第２ノード機器に要求する
パラメータ：
／／第１ノード機器のＴｅｒｍ
ｉｎｔ
ｔｅｒｍ
／／第１ノード機器のｉｄ
ｉｎｔ
ｌｅａｄｅｒｉｄ
／／第１ノード機器のログｃｏｍｍｉｔアクティブウィンドウ内のログがｃｏｍｍｉｔしたかどうかを記録する
ｉｎｔ
ｉｓＣｏｍｍｉｔｔｅｄ［］
戻る：
／／戻り値ｔｅｒｍは現在の第２ノード機器のＴｅｒｍである
ｉｎｔ
ｃｕｒｒｅｎｔＴｅｒｍ
／／第２ノード機器に戻され、ｃｏｍｍｉｔ済み且つｉｎｄｅｘが第１ノード機器ログｃｏｍｍｉｔアクティブウィンドウ範囲にあるログ
Ｌｏｇ
ｌｏｇｓ［］
／／第２ノード機器のログリストに戻されたログのｃｏｍｍｉｔ状況
ｂｏｏｌ
ｌｏｇｃｏｍｍｉｔｓ［］
受信者は以下を実現する：
（I）ｔｅｒｍ ＜ ｃｕｒｒｅｎｔＴｅｒｍであれば、ｃｕｒｒｅｎｔＴｅｒｍを戻す
（II）ｃｏｍｍｉｔ済みであり且つｉｎｄｅｘが第１ノード機器のログｃｏｍｍｉｔアクティブウィンドウ範囲内にあるログ、及びログリストにおけるログのｃｏｍｍｉｔ状況を戻す
【0204】
以下、分散型記憶システムのサーバー行為（即ち、分散型記憶装置サービスを提供するサーバークラスタ全体の行為）を示す：
全てのサーバー：
（i）ログの順不同ａｃｋ及び順不同ｃｏｍｍｉｔフローを行う
（ii）ログの順不同ａｐｐｌｙフローを行う
第２ノード機器行為：
ａ、候補ノード機器及び第１ノード機器のＲＰＣ関数に応答する
ｂ、選挙時間がタイムアウトし、且つ第１ノード機器又は投票することを約束した候補ノード機器からＡｐｐｅｎｄＥｎｔｒｉｅｓ
ＲＰＣメッセージを受信していないと、候補ノード機器に変換する
候補ノード機器行為：
Ａ、ｃｕｒｒｅｎｔＴｅｒｍをインクリメントする
Ｂ、自分に投票する
Ｃ、選挙時間カウンタをリセットする
Ｄ、他の全てのノード機器にＲｅｑｕｅｓｔＶｏｔｅ
ＲＰＣを送信する
Ｅ、過半数の票を受信した場合、第１ノード機器になる
Ｆ、新たな第１ノード機器からＡｐｐｅｎｄＥｎｔｒｉｅｓ
ＲＰＣメッセージを受信した場合、第２ノード機器に変換する
Ｇ、選挙時間がタイムアウトした場合、新たな選挙周期を開始する
第１ノード機器行為：
I、ハートビートを他の各ノード機器に送信し（ログが空であるＡｐｐｅｎｄＥｎｔｒｉｅｓ
ＲＰＣによって）、他の各ノード機器を第２ノード機器に変換し、ハートビートを繰り返して送信することで、選挙時間のタイムアウトを阻止する
II、サービスをクラスタに提供する前、まず、選挙Ｍｅｒｇｅ回復階段を行って、自体の欠如したログを回復して、自体のログの連続性を保証するとともに、他のノード機器でのログのｃｏｍｍｉｔ状況を取得する
III、端末から命令を受信した場合、ログを自体のログリストの後ろに追加し、ＡｐｐｅｎｄＥｎｔｒｉｅｓ
ＲＰＣを他のノードに送信し、ログがｃｏｍｍｉｔした場合、ａｃｋ情報を端末に返信する
全てのサーバー：
（i）ログの順不同ａｃｋ及び順不同ｃｏｍｍｉｔフローを行う
（ii）ログの順不同ａｐｐｌｙフローを行う
第２ノード機器行為：
ａ、候補ノード機器及び第１ノード機器のＲＰＣ関数に応答する
ｂ、選挙時間がタイムアウトし、且つ第１ノード機器又は投票することを約束した候補ノード機器からＡｐｐｅｎｄＥｎｔｒｉｅｓ
ＲＰＣメッセージを受信していないと、候補ノード機器に変換する
候補ノード機器行為：
Ａ、ｃｕｒｒｅｎｔＴｅｒｍをインクリメントする
Ｂ、自分に投票する
Ｃ、選挙時間カウンタをリセットする
Ｄ、他の全てのノード機器にＲｅｑｕｅｓｔＶｏｔｅ
ＲＰＣを送信する
Ｅ、過半数の票を受信した場合、第１ノード機器になる
Ｆ、新たな第１ノード機器からＡｐｐｅｎｄＥｎｔｒｉｅｓ
ＲＰＣメッセージを受信した場合、第２ノード機器に変換する
Ｇ、選挙時間がタイムアウトした場合、新たな選挙周期を開始する
第１ノード機器行為：
I、ハートビートを他の各ノード機器に送信し（ログが空であるＡｐｐｅｎｄＥｎｔｒｉｅｓ
ＲＰＣによって）、他の各ノード機器を第２ノード機器に変換し、ハートビートを繰り返して送信することで、選挙時間のタイムアウトを阻止する
II、サービスをクラスタに提供する前、まず、選挙Ｍｅｒｇｅ回復階段を行って、自体の欠如したログを回復して、自体のログの連続性を保証するとともに、他のノード機器でのログのｃｏｍｍｉｔ状況を取得する
III、端末から命令を受信した場合、ログを自体のログリストの後ろに追加し、ＡｐｐｅｎｄＥｎｔｒｉｅｓ
ＲＰＣを他のノードに送信し、ログがｃｏｍｍｉｔした場合、ａｃｋ情報を端末に返信する
【0205】
図１３は本出願の実施例が提供するログ実行装置の構造概略図であり、図１３を参照し、当該装置は分散型記憶システムに位置し、当該装置は、
ログ実行アクティブウィンドウを循環的にスキャンするスキャンモジュール１３０１であって、当該ログ実行アクティブウィンドウは未実行の複数のログを含み、且つ当該ログ実行アクティブウィンドウより前のログは何れも実行済みであるスキャンモジュール１３０１と、
当該ログ実行アクティブウィンドウにおける何れか１つのログに対して、当該ログの記憶範囲情報に基づいて、当該ログの競合検証結果を取得する第１取得モジュール１３０２であって、当該記憶範囲情報は当該ログの記憶範囲及び当該ログより前のターゲット数のログの記憶範囲を指示し、当該ターゲット数は当該ログ実行アクティブウィンドウのウィンドウサイズに等しい第１取得モジュール１３０２と、
当該競合検証結果が競合なしである場合、当該ログを実行する実行モジュール１３０３と、を含む。
ログ実行アクティブウィンドウを循環的にスキャンするスキャンモジュール１３０１であって、当該ログ実行アクティブウィンドウは未実行の複数のログを含み、且つ当該ログ実行アクティブウィンドウより前のログは何れも実行済みであるスキャンモジュール１３０１と、
当該ログ実行アクティブウィンドウにおける何れか１つのログに対して、当該ログの記憶範囲情報に基づいて、当該ログの競合検証結果を取得する第１取得モジュール１３０２であって、当該記憶範囲情報は当該ログの記憶範囲及び当該ログより前のターゲット数のログの記憶範囲を指示し、当該ターゲット数は当該ログ実行アクティブウィンドウのウィンドウサイズに等しい第１取得モジュール１３０２と、
当該競合検証結果が競合なしである場合、当該ログを実行する実行モジュール１３０３と、を含む。
【0206】
本出願の実施例が提供する装置において、ログ実行アクティブウィンドウを配置し、ログ実行アクティブウィンドウより前のログが何れも実行済みであることを保証することで、ログ実行アクティブウィンドウ内の何れか１つのログが、ログ実行アクティブウィンドウ内の、当該ログより前の未実行のログと記憶範囲の競合が生じたかどうかを検証すれば、分散型記憶システム全体において当該ログはデータの不一致という問題を招致するかどうかを分かって、競合なしの当該ログに対して、当該ログを順不同的に実行するようにサポートし、当該ログの実行プロセスを渋滞させる必要がなく、且つログ実行アクティブウィンドウ内の、当該ログより前の未実行のログの実行が完了するまで待つ必要がなく、分散型記憶システムのスループットを大幅に向上させ、高並行性シナリオに適用されることができる。
【0207】
可能な実施形態において、当該第１取得モジュール１３０２は、当該ログの記憶範囲情報を読み取って、当該ログ及び当該ログより前のターゲット数のログの記憶範囲を取得し、当該ログの記憶範囲と当該ターゲット数のログの記憶範囲との間の共通部分が空集合である場合、当該競合検証結果が競合なしであると決定し、当該ログの記憶範囲と当該ターゲット数のログの記憶範囲との間の共通部分が空集合ではない場合、当該競合検証結果が競合ありであると決定する。
【0208】
可能な実施形態において、図１３の装置構成に基づいて、当該実行モジュール１３０３は、当該ログを実行対象ログリストに追加する追加ユニットと、当該実行対象ログリストに記憶されたログを処理するように、ログ実行スレッドを呼び出す処理ユニットと、を含む。
【0209】
可能な実施形態において、当該処理ユニットは、当該実行対象ログリストに記憶されたログに対応するサービスデータを揮発性記憶媒体に書き込んで、当該揮発性記憶媒体に書き込まれた、当該サービスデータに対応するログを実行済みログリストに追加し、当該揮発性記憶媒体のデータ記憶量が記憶閾値以上である場合、当該揮発性記憶媒体に記憶されたサービスデータを不揮発性記憶媒体に書き込んで、当該実行済みログリストにおいて、サービスデータが不揮発性記憶媒体に書き込まれていないログ、及びサービスデータが不揮発性記憶媒体に書き込まれたログに対して異なる状態パラメータをそれぞれ配置する。
【0210】
可能な実施形態において、図１３の装置構成に基づいて、当該装置は、当該分散型記憶システムはクラッシュイベントが生じた場合、当該分散型記憶システムの再起動の時、当該状態パラメータに基づいて、当該実行済みログリストから複数の回復対象ログを取得する第２取得モジュールであって、当該回復対象ログに対応するサービスデータは当該揮発性記憶媒体に書き込まれ、而当該不揮発性記憶媒体に書き込まれていない、第２取得モジュールと、複数の当該回復対象ログの、当該実行済みログリストにおける記憶順序に基づいて、複数の当該回復対象ログに対応する複数のサービスデータを当該揮発性記憶媒体に順に回復する回復モジュールと、をさらに含む。
【0211】
可能な実施形態において、図１３の装置構成に基づいて、当該装置は、当該競合検証結果が競合ありである場合、当該ログと競合したログ数を取得する第３取得モジュールと、当該ログ数に基づいて、当該ログに対するスキャン頻度を決定する決定モジュールと、をさらに含み、当該実行モジュール１３０３はさらに、当該スキャン頻度に基づいて当該ログをスキャンして当該競合検証結果をリフレッシュし、当該競合検証結果が競合なしになるまで、当該ログを実行する。
【0212】
可能な実施形態において、当該決定モジュールは、当該ログ数が競合閾値より大きい場合、当該スキャン頻度を第１頻度に決定し、又は、当該ログ数が当該競合閾値以下である場合、当該スキャン頻度を第２頻度に決定し、当該第２頻度は当該第１頻度より大きい。
【0213】
可能な実施形態において、当該実行モジュール１３０３は、当該ログを当該スキャン頻度に対応するログリストに追加し、当該スキャン頻度に基づいて当該ログリストに記憶されたログをスキャンする。
【0214】
可能な実施形態において、当該スキャンモジュール１３０１はさらに、ログマッチングインデックステーブルを循環的にスキャンし、当該ログマッチングインデックステーブルは複数の提出対象ログが当該分散型記憶システムに記憶したコピー数を記録し、当該装置は、当該ログマッチングインデックステーブルにおける何れか１つの提出対象ログのコピー数がターゲット条件に合う場合、当該提出対象ログを提出する提出モジュールをさらに含む。
【0215】
可能な実施形態において、当該装置は前の任期が終了した後、当該分散型記憶システムにおける複数の第２ノード機器が投票して選挙することで生成され、当該装置における連続的且つ提出済みのログの最大インデックスは、複数の当該第２ノード機器における連続的且つ提出済みのログの最大インデックスの以上である。
【0216】
可能な実施形態において、図１３の装置構成に基づいて、当該装置は、ログ提出アクティブウィンドウには少なくとも１つのログが欠如した場合、各欠如したログのインデックスを取得する第４取得モジュールであって、当該ログ提出アクティブウィンドウは未提出の複数のログを含み、当該ログ提出アクティブウィンドウより前のログは何れも提出済みである、第４取得モジュールと、当該インデックスに基づいて、複数の当該第２ノード機器に当該欠如したログを要求する要求モジュールと、をさらに含む。
【0217】
可能な実施形態において、図１３の装置構成に基づいて、当該装置は、複数の当該第２ノード機器から戻されたターゲットログ及び当該ターゲットログの提出状況情報を受信する受信モジュールと、提出状況情報が提出済みであるターゲットログを当該ログ提出アクティブウィンドウに補足する補足モジュールと、をさらに含み、当該要求モジュールはさらに、提出状況情報が未提出であるターゲットログを端末に要求する。
【0218】
上記の全ての好適な技術案に対して、任意に組み合わせて本開示の好適な実施例を形成してもよく、ここで、贅言していない。
【0219】
ここで、上記の実施例が提供するログ実行装置はログを実行する時、上記の各機能モジュールの区画のみを例として説明し、実際応用において、ニーズに応じて、異なる機能モジュールによって完成されるように、上記の機能を割り当て、即ち、コンピュータ機器の内部構造を異なる機能モジュールに区画することで、以上に記載の全て又は一部の機能を完成する。また、上記の実施例が提供するログ実行装置と、ログ実行方法の実施例とは同一の構想に属し、その具体的な実現過程についてログ実行方法の実施例を参照すればよく、ここで、贅言していない。
【0220】
図１４は本出願の実施例が提供するコンピュータ機器の構造概略図であり、当該コンピュータ機器１４００は配置又はパフォーマンスの異なりのため、大きな差があり、当該コンピュータ機器１４００は１つ又は１つ以上のプロセッサー（Ｃｅｎｔｒａｌ
Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔｓ、ＣＰＵ）１４０１、及び１つ又は１つ以上のメモリ１４０２を含み、当該メモリ１４０２には少なくとも１本のコンピュータプログラムが記憶され、当該少なくとも１本のコンピュータプログラムは当該１つ又は１つ以上のプロセッサー１４０１によって読み込まれるとともに、実行されることで、上記の各実施例が提供するログ実行方法を実現する。任意選択で、当該コンピュータ機器１４００は有線又は無線ネットワークインターフェース、キーボード及び入力出力インターフェースなどの部材をさらに備えることで、入力出力を行って、当該コンピュータ機器１４００は機器機能を実現するための他の部材をさらに含み、ここで、贅言していない。
Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔｓ、ＣＰＵ）１４０１、及び１つ又は１つ以上のメモリ１４０２を含み、当該メモリ１４０２には少なくとも１本のコンピュータプログラムが記憶され、当該少なくとも１本のコンピュータプログラムは当該１つ又は１つ以上のプロセッサー１４０１によって読み込まれるとともに、実行されることで、上記の各実施例が提供するログ実行方法を実現する。任意選択で、当該コンピュータ機器１４００は有線又は無線ネットワークインターフェース、キーボード及び入力出力インターフェースなどの部材をさらに備えることで、入力出力を行って、当該コンピュータ機器１４００は機器機能を実現するための他の部材をさらに含み、ここで、贅言していない。
【0221】
例示的な実施例において、コンピュータ可読記憶媒体、例えば、少なくとも１本のコンピュータプログラムを含みメモリをさらに提供し、上記の少なくとも１本のコンピュータプログラムは端末におけるプロセッサーによって実行されることで、上記の各実施例におけるログ実行方法を完成する。例えば、当該コンピュータ可読記憶媒体はＲＯＭ（Ｒｅａｄ－Ｏｎｌｙ
Ｍｅｍｏｒｙ、読み取り専用メモリ）、ＲＡＭ（Ｒａｎｄｏｍ－Ａｃｃｅｓｓ Ｍｅｍｏｒｙ、ランダムアクセスメモリ）、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ－Ｏｎｌｙ
Ｍｅｍｏｒｙ、読み取り専用光ディスク）、磁気テープ、フレキシブルディスク及び光データ記憶などを含む。
Ｍｅｍｏｒｙ、読み取り専用メモリ）、ＲＡＭ（Ｒａｎｄｏｍ－Ａｃｃｅｓｓ Ｍｅｍｏｒｙ、ランダムアクセスメモリ）、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ－Ｏｎｌｙ
Ｍｅｍｏｒｙ、読み取り専用光ディスク）、磁気テープ、フレキシブルディスク及び光データ記憶などを含む。
【0222】
例示的な実施例において、コンピュータプログラム製品又はコンピュータプログラムをさらに提供し、１本又は複数本のプログラムコードを含み、当該１本又は複数本のプログラムコードはコンピュータ可読記憶媒体に記憶される。コンピュータ機器の１つ又は複数のプロセッサーはコンピュータ可読記憶媒体から当該１本又は複数本のプログラムコードを読み取って、当該１つ又は複数のプロセッサーは当該１本又は複数本のプログラムコードを実行することで、コンピュータ機器に、上記の実施例のログ実行方法を実行させて完成させる。
【0223】
当業者であれば理解できるように、上記の実施例の全て又は一部のステップの実現はハードウェアによって完成されてもよいし、プログラムが関するハードウェアに命令することで完成されてもよく、任意選択で、当該プログラムはコンピュータ可読記憶媒体に記憶され、任意選択で、上記の言及された記憶媒体は読み取り専用メモリ、磁気ディスク又は光ディスクなどである。
【0224】
以上は本出願を限定していなく、本出願の好適な実施例のみであり、本出願の精神及び原則内でなされた任意の修正、均等な置換、改善などは何れも本出願の保護範囲内に含まれる。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【国際調査報告】