フレームワーク: 分散一貫性ソリューション

[[403883]]

この記事はWeChatの公開アカウント「Sneak Forward」から転載したもので、著者はcscwです。この記事を転載する場合は、Qianxingqianxing の公開アカウントにご連絡ください。

序文

前回のアーキテクチャ：分散理論CAPとBASE[1]の記事では、分散システムに存在する問題と一般的な理論的解決策について学びましたが、具体的な実装プロトコルや解決策は何でしょうか？

• 分散一貫性
• 分散コンセンサスアルゴリズム
  • パオックス、いかだ、ザブ
• 分散トランザクションの一貫性
• 分散トランザクション一貫性の実装スキーム（XAモードとATモード）
  • 2フェーズコミット
  • 3相コミット
  • フレキシブルアフェアーズTCC
  • ATモード
  • イベント通知

1 分散一貫性

分散一貫性とは何ですか?分散一貫性は、実際には複数のサービス間のデータコピーの一貫性を解決する傾向があり、リレーショナルデータベースの一貫性（データ制約）とは異なります。

2 分散コンセンサスアルゴリズム

Paoxsアルゴリズム

• Paxos アルゴリズムは、メッセージ パッシングに基づくコンセンサス アルゴリズムであり、高度なフォールト トレランスを備えています。現在、分散一貫性問題を解決するための最も効果的なアルゴリズムの 1 つとして認識されています。
• Paxosアルゴリズムの一般的な理解
  • 旅行したい人が 10 人いて、目的地が成都とラサだとします。目的地を統一するための簡単な方法は、WeChatグループチャットを作成し、少数派が多数派に従うという原則に従って全員が投票することです。しかし、Paxos アルゴリズムでは、WeChat プラットフォームは信頼できないと見なされます。クラッシュしたらどうなりますか? Paxos の原則は、フォールト トレランスが非常に強力でなければならないということであるため、Paxos は相互にテキスト メッセージを送信する方法を採用しています。
  • 仲介者となる他の 3 人を見つけ (仲介者は 3 人に限らず、10 人から選択することもできます)、その 10 人が仲介者にテキスト メッセージを送信します。仲介者は互いに通信する必要はありません。
• 「申請段階」：各人のテキストメッセージには送信時間が付いており、仲介者は最新のテキストメッセージの提案者とのみ通信し、1人とのみ通信できます。誰もがエージェントに必死にテキストメッセージを送り、コミュニケーションの権利を得ようとしています
• 「通信段階」：中間通信権の半分を取得した場合。提案者は、希望する旅行先（成都など）をこれらのエージェントに推奨します。受け取った結果は 3 つあります。
  • A: 代理店の半数以上が商品を集めて成都に送ることに同意しました。
  • B: 少なくとも 1 人の仲介者が観光地を決定しました (必ずしも成都である必要はなく、他の提案者と仲介者が合意したラサである可能性もあります)。次に、観光地の半分を超えているかどうかを確認します。そうでない場合は、次回は最後に選択した観光地が選択されます。
  • C: コミュニケーションする権利を失い、テキストメッセージの送信を継続します。 。 。 。 。 。
• Paxos の一貫性は冗長コピーの一貫性を解決することであり、リレーショナル データベースの ACID の一貫性とは異なります。

ラフトアルゴリズム

• Paxos は理解するのが難しいため、実装するのも困難です。そこで、新しいコンセンサス アルゴリズムが存在します。ラフトには3つの役割がある
  • リーダー: すべてのクライアントインタラクション、ログレプリケーションなどを処理します。一度に有効なリーダーは 1 つだけです。
  • フォロワー: 投票者と同様、完全に受動的
  • 候補者: 新しいリーダーとして選出される可能性がある

選挙フェーズ

最初は、どのサーバーもフォロワーです。カウントダウン機能が組み込まれています。カウントダウンが終了すると、候補者となり、他のフォロワーに自分自身を選出するようリクエストを送信します。

現時点では3つの州がある

A: フォロワーの半数以上がフォローし、新しいリーダーになる

B: フォロワーの半数以上を占める競争相手がいる場合は、選挙を諦めてその競争相手のフォロワーになる

C: 競争相手はいますが、全員が互角です。候補者は次の選挙サイクルで再選される予定。この時点でカウントダウンも組み込まれています。カウントダウンを最初に終えた人が、フォロワーの半分を最初に獲得したリーダーになります (注: 前のラウンドで他の人のフォロワーが再び選挙に立候補することはできません)

ログ複製フェーズ

1: リーダーが選出され、クライアントがログを追加する要求を送信します。たとえば、ログは「hello」です。

2: リーダーはフォロワーに指示に従い、新しいログの内容をそれぞれのログに追加することを要求する

3: ほとんどのフォロワーサーバーは、ログをディスクファイルに書き込んだ後、追加が成功したことを確認し、コミットOKを発行します。

4: 次のハートビートで、リーダーはすべてのフォロワーにコミットされた項目を更新するように通知します。

このプロセス中にネットワーク パーティションまたはネットワーク通信障害が発生した場合。これにより、リーダーはほとんどのフォロワーにアクセスできなくなり、フォロワーは外部サービスを提供するために新しいリーダーを再選出します。ネットワークが復元されると、古いリーダーは、フォロワーの大多数を持つ新しいリーダーのフォロワーになります。失敗時のコミットロールバック

Zabアルゴリズム

ゼクシド

プロトコルのトランザクション番号 Zxid は 64 ビットの数値になるように設計されています。

下位 32 ビットは単純な単調増加カウンターです。クライアントからのトランザクション要求ごとに、カウンターは 1 ずつ増加します。

上位 32 ビットはリーダー サイクルのエポック番号を表します。新しいリーダー サーバーが選出されるたびに、そのローカル ログ内の最大トランザクション ZXID がリーダー サーバーから取得され、そこからエポック値が読み取られ、1 が加算されて新しいエポックとして使用されます。下位32ビットカウンタは0から再びカウントを開始する

クラッシュリカバリモード（選択）

クラスターが初期化されるか、リーダーが接続を失うと、ノード (任意のノード) がリーダー選出を開始し、クラスター内の他のノードがリーダー選出を開始したノードに投票します。

ノード B は A がリーダーになれると判断し、ノード B はノード A に投票します。この判断の根拠は次のとおりです: 選挙エポック (A) > 選挙エポック (B) || zxid(A) > zxid(B) || sid(A) > sid(B) です。そしてBに投票する投票を更新してください

sidは手動で設定されるサービスIDです

メッセージブロードキャストモード

• リーダーはクライアントのリクエストを提案に変換します
• リーダーはフォロワーごとに FIFO キューを準備し、そのキューに提案を送信します。
• リーダーがフォロワーの半数以上からACKフィードバックを受け取った場合
• リーダーはすべてのフォロワーにコミットを送信します

詳細

リーダーはクライアント要求を受信すると、要求をトランザクションにカプセル化し、トランザクション ID (ZXID) と呼ばれるグローバルに増加する一意の ID をトランザクションに割り当てます。 ZAB プロトコルではトランザクションの順序を保証する必要があるため、各トランザクションは ZXID に従ってソートされてから処理される必要があります。

リーダーとフォロワーの間には、それらを分離して同期ブロックを解除するためのメッセージ キューもあります。

Zookeeper クラスター内のすべてのプロセスが適切に実行されるようにするために、書き込み要求を受け入れることができるのはリーダー サーバーのみです。フォロワー サーバーがクライアントからリクエストを受信した場合でも、処理のためにリーダー サーバーに転送されます。

3 分散トランザクションの一貫性

分散一貫性と分散トランザクション一貫性のため。私は次のように区別することを好みます:

A-分散一貫性は、データが複数のサービスに一貫した状態で分散されている（複数のコピーが一貫している）という問題を解決します。

B-分散トランザクションの一貫性は、リレーショナル データベースの一貫性に似ていますが、分散サービス内のデータ間の関係を制約することです (たとえば、サービス A のデータ a とサービス B のデータ b の状態は、固定されたマッピング関係を維持する必要があります)。

分散コンセンサスアルゴリズムと分散一貫性の違い

コンセンサスアルゴリズムは分散一貫性を解決するように設計されていますが、分散トランザクション一貫性を解決するのには適していません（解決できますが、適していません）

4 分散トランザクション一貫性の実装（XAモードとATモード）

XA モードは、事前にコミットされたデータ モードです (事前にコミットされたデータは他のトランザクションからアクセスできません)。障害が発生した場合、事前にコミットされたデータはロールバックされます。

AT モードのデータはコミットされていることが確認されていますが、他のトランザクションによるデータへのアクセスを防ぐロックが存在します。障害が発生した場合は、逆操作を使用してデータを修復します。 XA モードと比較して、AT モードは分散トランザクションを解決し、ブロック待機時間を短縮するのに適しています。

2 フェーズ コミット (強力な一貫性) (XA モード)

2 フェーズ コミット プロトコル (2PC) は、一般的に使用される分散トランザクション ソリューションであり、トランザクション送信プロセスを準備フェーズと送信フェーズの 2 つのフェーズに分割します。

処理フロー

フェーズ1: 準備

コーディネーターは、トランザクションの内容をすべての参加者に送信し、トランザクションを送信できるかどうかを尋ね、すべての参加者からの応答を待ちます。

各参加者はトランザクション操作を実行し、元に戻す情報とやり直し情報をトランザクション ログに記録します (ただし、トランザクションはコミットしません)。

参加者が正常に実行した場合、コーディネーターに「はい」というフィードバックが返され、アクションを送信できることを示します。アクションが失敗した場合、コーディネータに「いいえ」というフィードバックが送信され、アクションを送信できないことが示されます。

フェーズ2: 提出フェーズ

コーディネータが参加者から失敗メッセージまたはタイムアウトを受信した場合、各参加者にロールバックメッセージを直接送信します。それ以外の場合はコミット メッセージを送信します。

参加者はコーディネータの指示に従ってコミットまたはロールバック操作を実行し、トランザクション処理プロセスで使用されるすべてのロック リソースを解放します。

2PCソリューションの欠点:

パフォーマンスの問題: トランザクションの送信フェーズ中、すべての参加者は同期ブロック状態になり、システム リソースを占有し、パフォーマンスのボトルネックが発生しやすくなります。

信頼性の問題: コーディネータに単一障害点がある場合、コーディネータに障害が発生すると、参加者はロックされたままになります。

データ一貫性の問題: コミット フェーズ中にローカル ネットワークの問題が発生すると、一部のトランザクション参加者はコミット メッセージを受信しますが、他の参加者は受信しないため、ノード間でデータの不整合が発生します。

3 フェーズ コミット (強力な一貫性) (XA モード)

3 フェーズ コミット プロトコルは、2 フェーズ コミット プロトコルの改良版です。 2 フェーズ コミット プロトコルとは異なり、タイムアウト メカニズムが導入されています。同時に、コーディネーターと参加者の両方にタイムアウトメカニズムを導入する

処理フロー

フェーズ 1: canCommit

コーディネーターは参加者にコミット要求を送信します。参加者がコミットできる場合は、 yes 応答 (参加者はトランザクション操作を実行しません) を返し、そうでない場合は no 応答を返します。

コーディネータは、トランザクションの内容を含むcanCommitリクエストをすべての参加者に送信し、トランザクションがコミットできるかどうかを尋ね、すべての参加者からの応答を待ちます。

canCommit リクエストを受信した後、参加者はトランザクション操作を実行できると判断した場合、yes で応答し、準備完了状態になります。それ以外の場合は、no で応答します。

フェーズ2: 事前コミット

• コーディネータは、フェーズ 1 の canCommit 参加者の応答に基づいて、トランザクション ベースの preCommit 操作を実行するかどうかを決定します。応答に応じて、次の 2 つの可能性があります。
• 「ケース1」：フェーズ1 すべての参加者が「はい」と回答し、参加者はトランザクションを事前実行する
  • コーディネーターはすべての参加者にpreCommitリクエストを送信し、準備フェーズに入ります。
  • preCommit 要求を受信した後、参加者はトランザクション操作を実行し、元に戻す情報とやり直し情報をトランザクション ログに記録します (ただし、トランザクションはコミットしません)。
  • 各参加者は、ack 応答または no 応答でコーディネータに応答し、最終指示を待ちます。
• 「ケース 2」: フェーズ 1 で、いずれかの参加者が「いいえ」と応答するか、「コーディネータの待機がタイムアウトし、すべての参加者からの応答を受信できないため、トランザクションが中止されます」
  • コーディネーターはすべての参加者に中止要求を送信します
  • 「参加者がコーディネータから中止要求を受け取った場合、またはコーディネータの要求を待っている間にタイムアウトが発生した場合、トランザクションは中止されます」

フェーズ3: コミットする

• この段階では実際のトランザクションの送信が行われます。これは次の3つの状況に分かれています。
• 「ケース1」: フェーズ2 すべての参加者がackで応答し、実際のトランザクションコミットを実行します。
  • コーディネーターが作業状態にある場合、すべての参加者に do Commit 要求を送信します。 do Commit リクエストを受信すると、参加者はトランザクションのコミットを正式に実行し、トランザクション全体で占有されていたリソースを解放します。
  • 各参加者はコーディネータに完了の確認メッセージをフィードバックします。コーディネーターがすべての参加者から ack メッセージを受信すると、トランザクションがコミットされます。
• 「ケース 2」: フェーズ 2 では、いずれかの参加者が「いいえ」と応答するか、コーディネーターが待機タイムアウト後にすべての参加者からのフィードバックを受信できず、トランザクションが中止されます。
  • コーディネーターが作業状態にある場合、すべての参加者に中止要求を送信します。参加者はフェーズ 1 の元に戻す情報を使用してロールバック操作を実行し、トランザクション全体で占有されていたリソースを解放します。
  • 各参加者は、ack 完了メッセージをコーディネータにフィードバックします。コーディネーターがすべての参加者から ack メッセージを受信すると、トランザクションは中断されます。
• 「ケース3」：コーディネーターと参加者のネットワークの問題
  • 「コーディネータが do Commit または abort 要求を発行し、待機時間が経過した後も、参加者はトランザクション コミットの実行を継続します。」

長所と短所

利点: 第 2 フェーズでは、コーディネーターまたは参加者が待機タイムアウト後にトランザクションを中断します。

利点: 第 3 フェーズでは、コーディネーターの単一ポイント問題が回避されます。コーディネーターに問題がある場合、参加者はトランザクションを送信し続ける（これも欠点です）

デメリット: データの不整合の問題が依然として存在します。第 3 段階では、コーディネーターがトランザクションの中断を要求し、コーディネーターが参加者と正常に通信できない場合、参加者はトランザクションを送信し続け、データの不整合が発生します。

柔軟なトランザクションTCC（サービスレベルでのXAモードの実装）

試行フェーズ: リソースをチェックして予約する必要があります。お金を引き出すシナリオでは、Try が行う必要があるのは、アカウントの利用可能残高が十分かどうかを確認し、アカウントの資金を凍結することです。 Try メソッドが実行された後、口座残高は依然として 100 元ですが、そのうち 30 元は凍結され、他の取引に使用できなくなります。

確認段階: 試行段階で凍結された資金を差し引きます。 Confirmメソッドが実行されると、第1段階で口座に凍結されていた30元が差し引かれ、口座Aの残高は70元になります。

キャンセル段階: ロールバックする場合は、キャンセル方法で、Try の最初の段階で凍結された 30 元を解放する必要があります。これにより、アカウント残高が初期状態に戻り、100 元が完全に利用可能になります。

AT モード (Ali 分散フレームワーク seata)

フェーズ 1: 提出

• 最初の段階では、Seata は「ビジネス SQL」をインターセプトし、最初に SQL セマンティクスを解析し、「ビジネス SQL」によって更新されるビジネス データを検索し、ビジネス データが更新される前の「前イメージ」として保存し、次に「ビジネス SQL」を実行してビジネス データを更新し、ビジネス データが更新された後に「後イメージ」として保存し、最後に行ロックを生成します。上記のすべての操作は 1 つのデータベース トランザクションで完了し、第 1 段階の操作の原子性が保証されます。

2フェーズコミットまたはロールバック

• 第 2 ステージが送信される場合、「ビジネス SQL」は第 1 ステージでデータベースに送信されているため、Seata フレームワークは、第 1 ステージで保存されたスナップショット データと行ロックを削除するだけで、データのクリーンアップを完了できます。

• 第 2 段階がロールバックされた場合、Seata は第 1 段階で実行された「業務 SQL」をロールバックし、業務データを復元する必要があります。
• ロールバック方式は、「以前のイメージ」を使用してビジネス データを復元することです。ただし、復元する前に、まずダーティ ライトを確認し、「データベースの現在のビジネス データ」と「後のイメージ」を比較する必要があります。2 つのデータが完全に一致している場合は、ダーティ ライトがないことを意味し、ビジネス データを復元できます。不一致がある場合は、ダーティ ライトが発生していることを意味し、ダーティ ライトは手動で処理する必要があります。

イベント通知（トランザクションメッセージ）

同期通知

• 人々は同期的に考える傾向があるため、これはシンプルで実装しやすい解決策です。しかし、サードパーティのシステムと比較すると信頼性が低く、内部処理のタイムアウトやネットワークの切断などの事故が発生しやすくなります。さらに、インターフェースが戻るのを待つことはブロッキングプロセスであり、システムのパフォーマンスに影響を及ぼします。

非同期コールバック通知

同期通知と比較すると、その処理インターフェースは非同期コールバックです。したがって、タイムアウト処理とタイムアウト戻りの問題を回避できます。

インターフェースがコールバック中にエラーを報告することを考慮すると、再試行コールバックを開始する必要があり、再試行メカニズムを追加する必要があります。

メッセージキュー

• メッセージキューはサービスを分離し、エラー再試行の問題を解決できる
• インターフェースの呼び出しはエラーや繰り返しの呼び出しを引き起こす可能性があるため、インターフェースの冪等性を保証する必要がある。
• 通常のメッセージ処理の一貫性の問題: 送信者のビジネス ロジック処理は成功 -> MQ はメッセージを正常に保存 -> ただし MQ 処理はタイムアウト -> ACK 確認は失敗 -> 送信者のローカル トランザクションがロールバックされるが、MQ は実際には正常に処理する
• 処理結果が返される場合は、メッセージキューを通じて返すこともできる。

トランザクションステータステーブル + メッセージキューソリューション

• ローカル メッセージに基づく結果整合性ソリューションのコア アプローチは、ビジネス操作を実行するときにメッセージ データを DB に記録することであり、メッセージ データの記録とビジネス データの記録は同じトランザクションで完了する必要があります。
• メッセージ データを記録した後、スケジュールされたタスクを使用して、送信待ち状態にあるメッセージを DB でポーリングし、メッセージを MQ に配信できます。このプロセス中にメッセージの配信が失敗する可能性があります。この場合、再試行メカニズムは、MQ からの ACK 確認が正常に受信された後に、メッセージ ステータスが更新されるか、メッセージがクリアされることを確認するために使用されます。
• インターフェースの冪等性を保証することも必要である

テキスト内の誤りを指摘することを歓迎します

参考文献

• 分散理論1：Paxosアルゴリズムの一般的な理解[2]
• 分散トランザクション一貫性ソリューション[3]
• 2PCと3PC[4]
• 「分散トランザクション」がまだ理解できませんか?この記事ではそれについて説明します。 [5]
• 分散トランザクション - メッセージ最終一貫性ソリューション[6]
• 分散トランザクション?いいえ、最終的な一貫性[7]
• 分散トランザクションの4つのモード[8]
• 分散トランザクションシート（パート2）AT、TCC、Sagaとは何かを理解する[9]

参照

[1] アーキテクチャ：分散理論CAP、BASE：

https://juejin.cn/post/6948809101392478245

[2] 分散理論1：Paxosアルゴリズムの一般的な理解：

https://www.cnblogs.com/esingchan/p/3917718.html

[3] 分散トランザクション一貫性ソリューション：

https://www.cnblogs.com/williamjie/p/11200885.html

[4]2PCと3PC：

https://blog.csdn.net/skyie53101517/article/details/80741868

[5] 「分散トランザクション」がまだ理解できない？この記事ではそれについて説明します。

https://www.cnblogs.com/zjfjava/p/10425335.html

[6] 分散トランザクション - メッセージ最終一貫性ソリューション:

https://www.jianshu.com/p/04bad986a4a2

[7] 分散トランザクション？いいえ、最終的な一貫性:

https://zhuanlan.zhihu.com/p/25933039

[8] 分散トランザクションの4つのモード：

https://zhuanlan.zhihu.com/p/141645172

[9] 分散トランザクションシート（II）AT、TCC、Sagaとは何かを理解する：

https://www.jianshu.com/p/f2caa8737b7b