Zookeeper テクノロジー: 分散アーキテクチャの詳細な説明、分散テクノロジーの詳細な説明、分散トランザクション

[[278655]]

1. 分散アーキテクチャの詳細説明

1. 分散開発の歴史

1.1 単一ポイント集中

機能: アプリ、DB、ファイル サーバーがすべて 1 台のマシンにデプロイされます。アクセスリクエストの数も少ない

1.2 アプリケーションサービスとデータサービスの分割

特徴: アプリ、DB、ファイルサーバーはそれぞれ独立したサーバーに展開されます。アクセスリクエストの数も少ない

1.3 キャッシュを使用してパフォーマンスを向上させる

機能: データベース内の頻繁にアクセスされるデータはキャッシュ サーバーに保存されるため、データベース アクセス回数が減り、データベースの負荷が軽減されます。

1.4 アプリケーションサーバークラスター

特徴：複数のアプリケーションサーバーが負荷分散により同時に外部にサービスを提供し、単一サーバーの処理能力の上限の問題を解決します。

1.5 データベースの読み取りと書き込みの分離

特徴: データベースは、データベースの処理負荷を解決するために、読み取りと書き込みの分離（マスターとスレーブ）で設計されています。

1.6 リバースプロキシと CDN アクセラレーション

機能: リバースプロキシとCDNを使用してシステムアクセスを高速化します

1.7 分散ファイルシステムと分散データベース

特徴: データベースは分散データベースを使用し、ファイルシステムは分散ファイルシステムを使用します

ビジネスが発展するにつれて、データベースの読み取りと書き込みの分離では最終的にニーズを満たせなくなり、分散データベースと分散ファイルシステムが必要になる。

分散データベースは、データベース分割後の最後の手段です。単一のテーブルの規模が非常に大きい場合にのみ使用されます。データベース分割のより一般的な方法は、異なるビジネスのデータベースを異なるマシンに展開するビジネス分割です。

2. 分散技術の詳細説明

1. 同時実行性

2. 配布

大きなタスクを複数のタスクに分割し、複数のマシンに展開して外部サービスを提供する

3. グローバルクロックの欠如

時間は統一されるべき

4. 同等性

複数のマシンに展開されたサービスは同じであり、違いはありません

5. 失敗は必ず起こる

ハードドライブが壊れ、CPUが焼けてしまいました...

3. 分散トランザクション

1. 酸

原子性: トランザクション内のすべての操作は完了するか、まったく完了しないかのいずれかであり、中間段階で終了することはありません。トランザクションの実行中にエラーが発生した場合、トランザクションが実行されなかったかのように、トランザクション開始前の状態に復元 (ロールバック) されます。

一貫性: トランザクションの開始前およびトランザクションの終了後にデータベースの整合性が損なわれることはありません。つまり、書き込まれるデータは、データの正確性と連結、後続のデータベースがスケジュールされたタスクを自発的に完了する機能など、事前に設定されたすべてのルールに完全に準拠している必要があります。

たとえば、A は 500 元、B は 300 元を持っており、A は B に 100 元を送金します。どのような場合でも、A と B の合計金額は常に 800 元になります。

分離: 複数の同時トランザクションが同時にデータを読み取り、書き込み、変更できるようにするデータベースの機能。分離により、複数のトランザクションが同時に実行されるときに、相互実行によって発生するデータの不整合を防ぐことができます。トランザクション分離には、コミットされていない読み取り、コミットされた読み取り、繰り返し読み取り、シリアル化可能など、さまざまなレベルがあります。

耐久性: トランザクションが完了すると、データへの変更は永続的になり、システムに障害が発生しても失われません。

2. 2P/3P

2P = 2 フェーズ コミット (RDBMS (リレーショナル データベース管理システム) は、強力な一貫性を確保するためにこのメカニズムをよく使用します)

3P=3フェーズコミット

注: 2P/3P は、トランザクションの ACID (原子性、一貫性、独立性、永続性) を確保するためのものです。

2.1 2Pの2つのフェーズ

フェーズ1: トランザクションリクエストを送信して（投票フェーズ）、トランザクションを送信できるかどうかを問い合わせます。

フェーズ2: トランザクションコミット（コミット、ロールバック）を実行して、実際にトランザクションをコミットします。

2.2 3Pの3つのフェーズ

フェーズ1: 送信するかどうか - トランザクションを送信できるかどうかを尋ねる

フェーズ2: 事前コミット - 事前コミットトランザクション

フェーズ3: トランザクションコミット（コミット、ロールバック）を実行して、実際にトランザクションをコミットする

注: 3Pは2Pの最初のステージを最初の2つのステージに分割します

3. CAP理論

一貫性: 分散データベース内のデータは一貫性が保たれます

可用性: いずれかのノードに障害が発生した場合でも、他のノードが外部にサービスを提供し続けることができます。

パーティション耐性（ネットワーク パーティション）: ハード ドライブ障害などのデータベース マシンに障害が発生し、データが失われた場合でも、新しいマシンを追加して、他の正常なマシンからバックアップ データを同期できます。

CAP理論の特徴：CAPは2つしか満たせない

CA (P を放棄): すべてのデータを 1 つのノードに配置します。一貫性と可用性を実現します。

AP (C を放棄): 強力な一貫性を放棄し、結果的一貫性を使用してそれを保証します。

CP (キャンセル A): システムに障害が発生すると、影響を受けるサーバーは一定期間待機する必要があり、回復期間中は外部サービスを提供できません。

CAP 理論を説明する例:

3 台のマシンがあり、それぞれに 3 つのデータベースと 2 つのテーブルがあり、データは同じです。

マシン1-db1-tbl_person、tbl_order

マシン2-db2-tbl_person、tbl_order

マシン3-db3-tbl_person、tbl_order

1) machine1 上の db1 の tbl_person テーブルと tbl_order テーブルにデータを挿入する場合、挿入されたデータは machine2 と machine3 に同時に同期される必要があります。これが一貫性です。

2) マシンの 1 つがダウンしても、外部へのサービスの提供を継続できます。ダウンしたマシンを再起動すると、サービスの提供を継続できます。これが可用性です。

3) machine1 に障害が発生し、すべてのデータが失われても、machine2 と machine3 にはまだデータが残っているので問題はありません。新しいマシン machine4 を追加し、machine2 と machine3 のいずれかのバックアップ データを同期するだけです。これはパーティションのフォールト トレランスです。

4. BASE理論

基本的に利用可能、ソフトステート、最終的に一貫性がある

基本的な可用性: 分散システムに障害が発生した場合、ある程度の可用性の損失 (サービスの低下、ページの低下) が許容されます。

ソフト状態: 分散システムで中間状態を表示できます。また、中間状態はシステムの可用性に影響を与えません。

1. ここでの中間状態とは、異なるデータ複製間のデータ更新の最終的な一貫性を指し、遅延される可能性がある。

2. CAP 理論の例のように、machine1 の db1 の tbl_person テーブルと tbl_order テーブルにデータを挿入する場合、挿入されたデータは machine2 と machine3 に同時に同期される必要があります。 machine3 のネットワークに問題がある場合は同期が失敗しますが、しばらくするとネットワークが復旧し、同​​期が成功します。この同期失敗の状態は、同期が最終的に成功するため、ソフト状態と呼ばれます。

最終的な一貫性: データの複製は時間の経過とともに一貫性を保ちます。

5. パクソスアルゴリズム

5.1 Paxosアルゴリズムを紹介する前に、短い物語を見てみましょう

ビザンチン将軍問題

ビザンチン帝国は5世紀から15世紀にかけて存在した東ローマ帝国でした。ビザンチウムは現在トルコのイスタンブールです。ビザンチン軍には多くの部隊があり、敵の都市の外に駐屯し、各部隊は独自の将軍によって指揮されていたと想像できます。将軍が 11 人いて、彼らは使者を通じてのみ通信できるとします。忠実な将軍は敵を観察した後、攻撃するか撤退するかの統一された行動計画を立てなければなりません。しかし、これらの将軍の中には、忠実な将軍たちが合意に達することを望まない裏切り者がおり、統一された行動計画の策定と普及に影響を与えました。

問題は、将軍たちは忠実な将軍全員が同意できる合意を結ばなければならないということであり、少数の裏切り者が忠実な将軍たちに間違った計画を立てさせ、一部の将軍が攻撃し、他の将軍が撤退するような事態を招いてはならないということである。

忠実な将軍が 9 人いて、そのうち 5 人が攻撃を決定し、4 人が撤退を決定し、2 人のスパイが悪意を持って撤退することを決定したとします。結果は間違った撤退ではありますが、この状況は完全に許容されます。なぜなら、この 11 人の将軍は依然として一貫した状態を維持しているからです。

要約:

1) 11人の将軍が街を攻撃する

2)同時攻撃（提案、解決）、同時撤退（提案、解決）

3) 撤退する場合でも攻撃する場合でも、将軍の半数が処刑に同意しなければならない

4) 将軍の中に裏切り者がおり、意思決定を妨げることになる

5.2 Paxosアルゴリズムを紹介しよう

Google Chubby の作者である Mike Burrows 氏は、世界には一貫性アルゴリズムが 1 つだけ存在し、それが Paxos であり、他のアルゴリズムは欠陥製品であると述べています。

Paxos: 多数決（最終的に一貫性の問題を解決）

Paxosアルゴリズムには、提案者、受容者、学習者の3つの役割があります。

提案者: 提出者（提案提出者）

提案を提出する（投票の過半数を獲得したかどうかを判断する）、承認提案を提出する（投票の過半数を獲得したかどうかを判断する）

受諾者: 受信者（提案の受信者）

提案を承認または拒否し、提案者に応答する（約束）

学習者: 学習者 (ただの楽しみ)

モーションが生成された場合は、そのモーションを学習します。

設定1: 受諾者が提案を受け入れない場合、最初の提案を受け入れなければならない

設定 2: 各提案には番号が必要であり、番号は増加のみ可能で繰り返すことはできません。時間が経つにつれて大きくなります。

設定3: より大きな数値の提案を承認します。以前に承認された提案の数よりも小さい場合は、拒否します。

設定4: 提案には2種類あります（提出された提案、承認された提案）

1) 準備段階（提案書提出）

a) 提案者は提案 V を希望します。まず、大多数の受け入れ者に準備リクエストを送信します。準備要求の内容はシーケンス番号Kである

b) アクセプタは、番号 K の準備要求を受信した後、以前に準備要求を処理したことがあるかどうかを確認します。

c) アクセプターが準備要求を受信して​​いない場合、プロポーザーにOKで応答します。これは、アクセプターが最初に受信した提案を受け入れる必要があることを意味します（設定1）

d) それ以外の場合、Acceptor が以前に Prepare 要求 (MaxN など) を受け入れたことがある場合は、提案番号を比較します。 Kの場合

e) K>=MaxN の場合、以前に承認された提案があるかどうかを確認します。そうでない場合は、提案者にOKと返信し、Kを記録します。

f) K>=MaxN の場合、以前に承認された提案があるかどうかを確認します。承認された場合は、承認された提案番号と提案内容を返信してください（例：

2) 受け入れ段階

a) 提案者は、承認された提案番号や提案内容がなく、承認者の半数以上からすべてOKという返信を受け取ります。その後、提案者は承認要求の提出を継続しますが、今回は提案番号Kと提案内容Vを一緒に提出します（

b) 提案者は、承認者の半数以上から、承認された提案番号と提案内容を含む、承認された提案の回答を受け取ります（

c) 提案者が半数以上の受け入れ者から応答を受け取らなかった場合は、提案番号KをK+1に変更し、その番号を受け入れ者に再送信します（準備段階のプロセスを繰り返す）。

d) 承諾者は提案者から承諾要求を受信します。数字がKの場合

e) 承諾者は提案者から承諾要求を受信します。 K>=MaxNの数値の場合、提案を承認し、承認された提案を手元に設定します。

f) 一定期間が経過すると、提案者は受け取った承認応答を比較します。半数以上が承認されると、プロセスは終了し (提案は承認され)、提案を学習できることが学習者に通知されます。

g) 一定期間が経過すると、提案者は受信した承認応答を比較します。回答の半分未満しか受信されなかった場合、提案者は提案番号を変更し、準備段階に戻ります。

5.3 パクソスの例

例1: 連続提案のシナリオ

役割：

提案者: 提案者 1、提案者 2

受容者: 一般 1、一般 2、一般 3 (意思決定者)

1) 参謀1は、信号手を派遣して3人の将軍に手紙を届けることを提案した。その内容は(その1)である。

2) 三人の将軍は参謀１から提案を受けました。彼らはこれまで番号を保存したことがなかったので、忘れないように（番号１）を保存しました。同時に、信号手に手紙を内容とともに持ち帰るように依頼しました（OK）。

3) 参謀1は少なくとも2人の将軍から返事を受け取り、別の信号手に3人の将軍に手紙を届けるよう指示し、その内容は(番号1、攻撃時間1)である。

4) 3人の将軍は参謀1から情報を受け取り、忘れないように（番号1、攻撃時間1）を保存しました。同時に、信号手に手紙を内容（受理）とともに持ち帰るよう依頼した。

5) 参謀1は少なくとも2人の将軍から（承諾）メッセージを受信し、攻撃時間が全員に承諾されたことを確認します。

6) 参謀2は、信号手を派遣して3人の将軍に手紙を届けることを提案した。その内容は(その2)である。

7) 三人の将軍は参謀2から提案を受け取りました。(2)は(1)より大きいので、忘れないように(2)を保存しました。すでに参謀１の提案を受け入れていたため、彼らは信号手に手紙を持ち帰るよう依頼した。その手紙には（番号１、攻撃時刻１）と書かれていた。

8) 参謀2は少なくとも2人の将軍から返答を受け取る。回答には参謀１の提案内容が含まれているため、参謀２は新たな攻撃時間を提案せず、参謀１が提案した時間を受け入れる。

例2: クロスシーン

役割：

提案者: 提案者 1、提案者 2

受容者: 一般 1、一般 2、一般 3 (意思決定者)

1) 参謀1は、信号手を派遣して3人の将軍に手紙を届けることを提案した。その内容は(その1)である。

2) 三将軍の状況は次の通り

a) 将軍1と将軍2は参謀1からの提案を受け取り、(番号1)を書き留めます。他の参謀がそれより少ない数を提案した場合は却下される。同時に、信号手に手紙とその内容をそのまま持ち帰るように頼みます（OK）。

b) 将軍3に通知する責任があった信号手が捕虜になったため、将軍3は参謀1からの提案を受け取らなかった。

3) 参謀2はまた、同時に通信兵を派遣して3人の将軍に手紙を届けることを提案した。その内容は(その2)である。

4) 三人の将軍の状況は次の通り

a) 将軍2と将軍3は参謀2からの提案を受け取り、(番号2)を書き留めます。他の参謀がそれより少ない数を提案した場合は却下される。同時に、信号手に手紙とその内容をそのまま持ち帰るように頼みます（OK）。

b) 将軍1に通知する責任があった信号手が捕虜になったため、将軍1は参謀2からの提案を受け取らなかった。

5) 参謀1は少なくとも2人の将軍から返信を受け取り、別の信号手に、返信してきた2人の将軍に内容が(番号1、攻撃時間1)である手紙を届けるよう指示する。

6) 2人の将軍の状況は次の通り

a) 将軍 1 は (番号 1、攻撃時間 1) を受け取ります。これは将軍が保存した番号と同じなので、将軍は (番号 1、攻撃時間 1) を保存し、信号手に内容 (Accepted) の手紙を持ち帰るように依頼します。

b) ジェネラル2が（番号1、攻撃時間1）を受け取ります。 (番号 1) は保存された (番号 2) より少ないため、彼は使者に内容 (拒否、番号 2) とともに手紙を持ち帰るように依頼します。

7) 参謀2は少なくとも2人の将軍から返信を受け取り、返信した2人の将軍に別の信号手を派遣して、内容が（番号2、攻撃時間2）である手紙を届けさせる。

8) 将軍2と将軍3は、(番号2、攻撃時間2)を受け取りました。これは、彼らが保存した番号と同じだったので、(番号2、攻撃時間2)を保存し、信号手に内容(Accepted)の手紙を持ち帰るように依頼しました。

9) 参謀2は少なくとも2人の将軍から（承認）メッセージを受信し、攻撃時間が大多数によって承認されたことを確認します。

10) 参謀1は将軍1人から(承認)メッセージのみを受信し、さらに(拒否、番号2)も受信しました。参謀1は再度提案し、使者を派遣して三将軍に手紙を届けさせた。内容は（番号3）である。

11) 三人の将軍の状況は次の通りである

a) 将軍1は参謀1から提案を受け取ります。(No.3)は以前保存した(No.1)より大きいため、将軍1は(No.3)を保存します。将軍１は参謀１の前回の提案をすでに受け入れているため、信号手に（番号１、攻撃時刻１）が記載された手紙を持ち帰るよう依頼する。

b) 将軍2は参謀1からの提案を受け取ります。(No.3)は以前に保存された(No.2)より大きいため、(No.3)が保存されます。将軍2は参謀2の提案を受け入れたので、信号手に手紙を持ち帰るように頼みます。手紙には（番号2、攻撃時間2）が含まれています。

c) 将軍3に通知する責任があった信号手が捕虜になったため、将軍3は参謀1からの提案を受け取らなかった。

12) 参謀1は少なくとも2人の将軍から返答を受け取り、2つの返答の数字を比較し、大きい数字に対応する攻撃時間を最新の提案として選択します。参謀 1 は、信号手を派遣して、返信してきた 2 人の将軍に、内容 (番号 3、攻撃時間 2) を記載した手紙を届けさせます。

13) 将軍1と将軍2は、(番号3、攻撃時間2)を受け取りました。これは彼らが保存した番号と同じだったので、(番号3、攻撃時間2)を保存し、信号手に内容(承諾)の手紙を持ち帰るように依頼しました。

14) 参謀1は少なくとも2人の将軍から（承認された）メッセージを受け取り、攻撃時間が大多数によって承認されたことを確認した。

4. Zookeeper ZAB プロトコル

Zookeeper Automic Broadcast (ZAB)、Zookeeperアトミックブロードキャストは、Paxosの古典的な実装です。

用語：

クォーラム: クラスターの過半数

1. ZAB（Zookeeper）のノードは4つの状態に分かれています

参照: リーダー選出ステータス (クラッシュ回復状態)

従う：リーダーの命令に従うフォロワーの状態

leading: 現在のノードはリーダーであり、作業の調整を担当します。

観察: オブザーバー、選挙には参加しない、読み取り専用ノード。

2. ZAB の 2 つのモード (ZK の選挙の実施方法)

クラッシュリカバリ、メッセージブロードキャスト

1) クラッシュリカバリ

リーダーが倒れ、新しいリーダーを選出する必要がある

a.各サーバーは、(3,9) のように、自分自身に投票する 1 つの投票権を持ちます。

b.各サーバーが自分自身に投票した後、他の利用可能なサーバーに投票します。たとえば、Server3 の (3,9) はそれぞれ Server4 と Server5 に投票されます。

紀元前比較投票、比較ロジック: 最初に Zxid が比較され、Zxid が同じ場合にのみ myid が比較されます。 Zxid を比較すると、大きい方がリーダーになります。 myidを比較すると、小さい方がリーダーになる

d.サーバーステータスの変更 (クラッシュ回復 -> データ同期、またはクラッシュ回復 -> メッセージブロードキャスト)

関連概念の補足説明:

エポック期間値

acceptedEpoch (メタファー: 元号): フォロワーはリーダーの元号変更の提案を承認しました (newepoch)。

currentEpoch (比喩: 現在の時代): 現在の時代

lastZxid: 履歴内で最後に受信した提案 zxid (最大値)

履歴: 現在のノードが受信したトランザクション提案のログ

Zxid データ構造の説明:

cZxid = 0x10000001b

64ビットデータ構造

上位32ビット: 10000

リーダーサイクル番号 + myid の組み合わせ

下位32ビット: 001b

トランザクションの自己増加シーケンス（単調増加シーケンス）は、クライアントがリクエストを持っている限り+1です。

新しいリーダーが生成されると、ローカル ログ内の最大のトランザクション Zxid がリーダー サーバーから取得され、そこからエポック + 1 が読み取られて新しいエポックとして使用され、下位 32 ビットが 0 に設定されます (ID が確実に自己増加することを保証するため)

2) メッセージブロードキャスト（2P送信と同様）

a.リーダーはリクエストを受け入れると、そのリクエストにグローバルに一意の 64 ビット自己増分 ID (zxid) を割り当てます。

b. zxid を提案としてすべてのフォロワーに送信します。

紀元前すべてのフォロワーが提案を受信し、それをハードディスクに書き込む場合は、すぐにリーダーに ACK (OK) で応答します。

d.リーダーは、規定の数（半分以上）の Ack を受信すると、すべてのフォロワーにコミット コマンドを送信します。

e.Follower はコミット コマンドを実行します。

注: この段階では、ZK クラスターは正式に外部にサービスを提供しており、リーダーはメッセージをブロードキャストできます。新しいノードが参加する場合は、同期が必要です。

3) データ同期

a.リーダーの最大の lastZxid を取得します (ローカル ログから)

b. zxid に対応するデータを検索し、同期します (データ同期プロセスにより、すべてのフォロワーの一貫性が確保されます)

紀元前クォーラム同期が完了した場合にのみ、準リーダーは真のリーダーになることができます。