分散システムの設計方法をご存知ですか?デザインの仕方がわからない場合は、アリババの建築家がデザイン方法を教えてくれます

[[274519]]

1. 分散システムに関連する概念

1.1 モデル

1.1.1 ノード

ノードは、分散プロトコルに従って一連のロジックを独立して完了できるプログラム エンティティであり、エンジニアリングではプロセスと呼ばれることがよくあります。

1.1.2 コミュニケーション

ノードは完全に独立しており、互いに分離されているため、通信する唯一の方法は信頼性の低いネットワーク経由です。

1.1.3 ストレージ

ノードは、ノードと同じマシン上のローカル ストレージ デバイスにデータを書き込むことでデータを保存できます。

1.1.4 例外

（１）機械の停止時間

大規模クラスターでのダウンタイムの確率は 1 日あたり 0.1% です。その結果、マシン ノードは動作できなくなり、再起動後にすべてのメモリ情報が失われます。

（２）ネットワーク異常

メッセージ損失: ネットワーク輻輳、経路変更、デバイス異常、ネットワーク分断(部分異常)

メッセージ障害: IP ストアアンドフォワード、ルーティングの不確実性、ネットワークメッセージ障害

データエラー: ビットエラー

信頼性の低い TCP: プロトコル スタックに到達した後、プロセスに到達するまでの間に TCP が順序どおりに機能しない、突然のダウンタイム、複数のノードでの分散 TCP

（３）分散システムの３つの状態

すべてのリクエストでは、成功、失敗、タイムアウトの 3 つの状況を考慮する必要があります。タイムアウトしたリクエストの場合、リクエストが正常に実行されたかどうかを知ることはできません。

（4）ストレージデータの損失

（５）その他の異常

遅いIO操作、ネットワークジッター、輻輳

1.2 インスタンス

1.2.1 レプリ​​カの概念

レプリカ/コピーとは、分散システム内のデータまたはサービスに提供される冗長性を指します。

データ複製: 異なるノードに同じデータを保存します。例えば、GFSは同じチャンクのコピーを複数持つ

サービス レプリカ: 複数のノードが同じサービスを提供します。このサービスはローカル ストレージに依存せず、データは他のノードから取得されます。たとえば、Map Reduceジョブワーカー

1.2.2 レプリカの一貫性

レプリカの一貫性は、特定のレプリカではなく、分散システムを指します。強度の程度に応じて、次のように分類されます。

強力な一貫性: どのユーザー/ノードも、いつでもデータの最新更新コピーを読み取ることができます。

単調な一貫性: ユーザーは、特定のデータの更新された値をいつでも読み取ると、古い値を読み取ることはありません。

セッションの一貫性: ユーザーは、セッション内のデータの更新された値をいつでも読み取ることができますが、このセッションでは古い値を読み取ることはできません。

最終的な一貫性: 各レプリカのデータは最終的に一貫した状態になりますが、その時間は保証されません。

一貫性が弱い: 実用的な価値がないため省略。

1.3 分散システムを測定するための指標

1.3.1 パフォーマンス

スループット: 特定の時間に処理できるデータの総量

応答遅延: 機能を完了するのに必要な時間

同時実行: QPS (1秒あたりのクエリ数)

1.3.2 可用性

システムのダウンタイムと通常のサービス時間の比率

1.3.3 スケーラビリティ

クラスターマシンを拡張することで、システムパフォーマンス、ストレージ容量、コンピューティング能力が向上するという特性は、分散システム独自の特性です。

1.3.4 一貫性

レプリカによって生じる一貫性の問題

1.3.5: 分散アーキテクチャシステムの視覚監視ソリューション

1. アーキテクトは分散アーキテクチャ システムの監視問題をどのように解決するのでしょうか?

2. ELK とは誰ですか? どこから来たのですか? そしてどこへ向かうのですか?

3. JD の大量データ取得を体験してみましょう。

4. マウスをクリックするだけで、ハイエンドの監視インターフェイスが開きます。

5. あなたはインターネット アーキテクトになるまでどのくらいの距離がありますか?聞いてみればわかります。

6. アーキテクトのテクノロジー スタックはどうあるべきでしょうか?あなたが尋ねれば、私は答えます。

前進、前進、前進。重要なことは3回言うべきです。前進して私について来てください。プライベート メッセージを送信します: Java アーキテクチャでは、分散アーキテクチャ マインド マップと、上級アーキテクトが説明する分散集中ビデオ マテリアルが提供されます (高並行性、Spring ソース コード、MyBatis ソース コード、Dubbo、Netty など、複数の知識ポイントのビデオ テクノロジ共有も提供されます)。

2. 分散システムの原則

2.1 データ配信

コンピューティングやストレージに関係なく、問題の入力オブジェクトはデータです。分散システムの入力データをどのように分割するかは、分散システムの基本問題と呼ばれます。

2.1.1 ハッシュ法

一般的なハッシュ方法は、データが属するユーザー ID に基づいてハッシュを計算することです。

アドバンテージ：

• ハッシュ可能性: 良好
• メタ情報: 必要なのは関数とサーバーの総数のみ

欠点:

• スケーラビリティ: 低い。クラスタサイズが大きくなると、ほとんどのデータを移行して再配布する必要がある。
• データスキュー: 特定のユーザー ID のデータ量が極端に多い場合、単一サーバーの処理能力の上限に達しやすくなります。

2.1.2 データ範囲による分布

特性値の範囲に応じてデータを分割します。たとえば、ユーザー ID の値の範囲は [1, 33)、[33, 90)、[90, 100) に分割され、3 つのサーバーによって処理されます。間隔のサイズは、間隔内のデータのサイズとは関係がないことに注意してください。

アドバンテージ：

• スケーラビリティ: 良好。データ量に応じて元のデータ間隔を柔軟に分割

欠点:

• メタ情報: 大きい。簡単にボトルネックになる可能性があります。

2.1.3 データ量による分布

データが範囲別に分散されるのと同様に、メタデータは簡単にボトルネックになる可能性がある。

2.1.4 一貫性のあるハッシュ

（１）ノードとしてのマシン

ハッシュ関数を使用してデータ（特徴）のハッシュ値を計算し、ハッシュ関数の値の範囲を閉じたリングにして、リング上にノードをランダムに分散します。各ノードは、それ自体から始めて時計回りに次のノードまで値の範囲内でデータを処理する役割を担います。

アドバンテージ：

• スケーラビリティ: 優れています。隣接ノードにのみ影響を与え、ノードを動的に追加または削除します。

欠点:

• メタ情報: 大きくて複雑
• ノードをランダムに配置すると、不均一になりやすい
• 動的にノードを追加することで、隣接ノードの問題を軽減できる。
• 一つの関節に異常があると、圧力は隣接する節に完全に伝わります

（２）仮想ノード

仮想ノード: 仮想ノードの数はマシンの数よりもはるかに多くなります。仮想ノードは範囲リング上に均等に分散され、実際のマシンノードはメタデータを通じて検出されます。

アドバンテージ：

特定のノードが利用できなくなると、複数の仮想ノードが利用できなくなり、負荷のバランスがとれる。

新しいノードを追加すると複数の仮想ノードが追加され、全体的な圧力が軽減されます。

2.1.5 レプリカとデータ分散

前の 4 つのデータ分散に関する説明では、データ複製の問題は考慮されていませんでした。

（１）機械によるコピー

欠点:

回復効率：低い。 1 が失敗した場合、2 と 3 からすべてのデータをコピーすると、より多くのリソースが消費されます。サービスに影響を与えないようにするために、通常は 2 をオフラインにしてコピーを作成し、その結果 3 のみが正常に動作することになります。

スケーラビリティ: 低い。システム内の 3 台のマシンが互いのレプリカである場合、2 台のマシンのみを追加しても新しいレプリカ グループを形成することはできません。

使いやすさ: 悪い。 1 台のマシンは圧力を下げ、残りの 2 台は圧力を 50% 増加させます。理想的には、単一のレプリカ グループだけでなく、クラスター全体に均等に分散されます。

（２）データセグメントの複製

たとえば、サーバーが 3 台あり、データが 10G あります。データ セグメントは、ハッシュ モジュロ 100 を取得した後、それぞれ 100M になります。各サーバーは 333 のデータ セグメントを担当します。データがデータ セグメントに分割されると、レプリカはデータ セグメント単位で管理できるようになり、レプリカはマシンに厳密に関連付けられなくなります。

たとえば、システム内に 3 つのデータ opq があり、各データ セグメントに 3 つのコピーがあり、システム内に 4 台のマシンがあるとします。

アドバンテージ：

回収効率：高。クラスタ全体を同時にコピーできる

使いやすさ：良好。マシンダウンの圧力はクラスタ全体に分散されます

プロジェクト内のデータ セグメントに基づいてレプリカを完全に作成すると、メタデータのオーバーヘッドが増加します。このアプローチは、データ セグメントを 1 つの大きなデータ セグメントにグループ化することです。

2.1.6 ローカライズされたコンピューティング

コンピューティング ノードとストレージ ノードが異なる物理マシン上に配置されている場合、オーバーヘッドが高くなり、ネットワーク帯域幅がシステムのボトルネックになります。ストレージ ノードと同じ物理マシン上でノード コンピューティングを実行するようにコンピューティングをスケジュールすることを、コンピューティング ローカリゼーションと呼びます。

2.2 基本的なコピープロトコル

2.2.1 集中コピー制御プロトコル

集中型レプリカ制御プロトコルの基本的な考え方は、中央ノードがレプリカ データの更新を調整し、レプリカ間の一貫性を維持し、同時実行を制御することです。

同時実行制御: 複数のノードが同時にレプリカデータを変更する必要がある場合、「書き込み-書き込み」や「読み取り-書き込み」などの同時実行の競合を解決する必要があります。

スタンドアロン システムでは、同時実行制御にロックなどの方法を使用し、集中型プロトコルも使用できます。欠点は、中央ノードに過度に依存することです。

2.2.2 プライマリセカンダリプロトコル

これは一般的に使用される集中型コピー制御プロトコルであり、プライマリ コピーとして機能するのは 1 つのノードのみです。対処する必要がある問題は 4 つあります。

（１）データ更新の基本手順

更新はプライマリによって調整されます

外部ノードは更新操作をプライマリノードに送信する

プライマリ ノードは同時実行制御を実行し、同時更新操作の順序を決定します。

プライマリノードは更新操作をセカンダリノードに送信する

プライマリノードは、セカンダリノードの完了ステータスに基づいて更新が成功したかどうかを判断し、その結果を外部ノードに返します。

ステップ 4 では、GFS などの一部のシステムでは、プライマリ帯域幅がボトルネックになるのを避けるために、プライマリ -> セカンダリ 1 -> セカンダリ 2 というリレー方式を使用してデータを同期します。

（２）データ読み取り方法

方法 1: データ更新プロセスはプライマリによって制御されるため、プライマリ コピー上のデータは最新のものでなければなりません。したがって、プライマリ コピーのデータのみを常に読み取ることで、強力な一貫性を実現できます。マシンの無駄を避けるために、前述の方法を使用してデータをセグメント化し、データ セグメントをレプリケーションの単位として使用することができます。これにより、各マシンにプライマリ コピーが存在することが保証されます。

方法 2: プライマリ ノードがセカンダリ ノードの可用性を制御します。プライマリがセカンダリの更新に失敗すると、セカンダリは使用不可としてマークされます。使用できないセカンダリ レプリカは、正常に同期されて使用可能になるまで、プライマリとのデータの同期を試行し続けます。

方法 3: クォーラム メカニズム。フォローアップの議論。

（３）プライマリレプリカの決定と切り替え

プライマリコピーを決定するにはどうすればよいでしょうか?プライマリコピーが配置されているマシンが異常な場合、コピーを切り替えるにはどうすればよいですか?

通常、プライマリ-セカンダリ分散システムでは、どのレプリカがプライマリであるかに関する情報はメタ情報であり、専用のメタデータ サーバーによって管理されます。更新操作を実行するときは、まずメタデータ サーバーにクエリを実行してレプリカのプライマリ情報を取得し、その後データ更新プロセスを実行します。

レプリカの切り替えには、元のプライマリ ノードの異常を検出するためにノードの状態をどのように判断するかという 2 つの難しさがあります (リース メカニズム)。プライマリ ノードの切り替えは一貫性に影響を与えてはなりません (クォーラム メカニズム)。

（4）データ同期

セカンダリとプライマリの間に矛盾がある場合、セカンダリはプライマリと調整する必要があります。

矛盾が生じる理由は 3 つあります。

ネットワークの断片化やその他の異常により、セカンダリがプライマリより遅れる

一般的な方法は、プライマリ上の操作ログ（REDO ログ）を再生して、プライマリの更新進行状況に追いつくことです。

一部のプロトコルでは、セカンダリはダーティデータです

破棄して3番目のケースに進みます。または、UNDOログに基づいた方法を設計する

セカンダリは、データが全くない新しく追加されたコピーです

プライマリ データを直接コピーしますが、プライマリが同時に更新サービスを継続的に提供できることが要求されます。そのためには、プライマリ コピーがスナップショット機能をサポートする必要があります。つまり、ある時点でレプリカ データのスナップショットを取得し、そのスナップショットをコピーし、ログを再生することでスナップショット以降の更新操作をキャッチアップします。

2.2.3 分散レプリカ制御プロトコル

分散型レプリカ制御プロトコルには中央ノードが存在せず、ノードは平等な協議を通じて合意に達します。強力な一貫性が求められるエンジニアリングに適用できる唯一のプロトコルは、Paxos プロトコルです。続編の紹介です。

2.3 リースの仕組み

2.3.1 リースベースの分散キャッシュシステム

（１）要件：分散システムには、システムのメタデータを保存し、維持するノードAが存在する。システム内の他のノードが A にアクセスしてメタデータを読み取ったり変更したりすると、A のパフォーマンスがシステムのボトルネックになります。このため、メタデータ キャッシュは各ノードのメタデータ情報をキャッシュするように設計されています。

Aへのアクセスを減らしてパフォーマンスを向上させる

各ノードのキャッシュデータは常にAと一致している

ノードのダウンタイム、ネットワークの中断、その他の異常を可能な限り処理する

（２）解決原理：

A は、ノードにデータを送信しながら、各ノードにリースを発行します。各リースには有効期間があり、通常は特定の時点となります。実時間がその時点を超えると、リースは期限切れになります。

リースの有効期間中、A は対応するデータの値が変更されないことを保証します。

A がデータを変更する場合、まずすべての新しい読み取り要求をブロックし、データの以前に発行されたすべてのリースの有効期限が切れるまで待機してから、データの値を変更します。

（３）クライアントノードがメタデータを読み込むプロセス

if (メタデータがローカル キャッシュにあり、リースが有効) { キャッシュ内のメタデータを直接返します。} else { 結果 = メタデータ情報を読み取るように A に要求します。 Result.Status == SUCCESS の場合、WriteToCache(Result.data, Result.lease); } else if (Result.Status == FAIL || Result.Status == TIMEOUT) { retry() または exit(); }}

（４）クライアントノードによるメタデータの変更プロセス

ノードはメタデータを変更するためにAにリクエストを送信します

変更要求を受信した後、A はすべての新しい読み取りデータ要求をブロックします。つまり、読み取り要求は受け入れますが、データは返しません。

A は、メタデータに関連付けられたすべてのリースがタイムアウトするまで待機します。

Aはメタデータを変更し、ノードに成功した変更を返します。

（５）最適化ポイント

メタデータを変更するときにすべての新しい読み取り要求をブロックします

これは、新しいリースの発行によって新しいキャッシュ ノードが常にリースを保持し、ライブロックが形成されるのを防ぐためです。最適化の方法は次のとおりです。A が変更プロセスに入ると、読み取り要求を盲目的にブロックするのではなく、読み取り要求のリースを返さずにデータのみが返されます。その結果、キャッシュ ノードはデータを読み取ることはできますが、データをキャッシュすることはできません。さらに最適化するには、現在発行されているリースの最大値を返します。これにより、ライブロック問題も回避されます。

メタデータを変更するときは、すべてのリースが期限切れになるまで待つ必要があります。

最適化の方法は次のとおりです。A はリースを保持している各ノードにリースを放棄し、キャッシュ内の関連データをクリアするように積極的に通知します。キャッシュノードからネゴシエーションが成功したことを確認する応答を受信した場合、変更アクションを事前に完了できます。途中で失敗したりタイムアウトしたりした場合は、リースの有効期限が切れるのを待つ通常のプロセスが開始され、プロトコルの正確性には影響しません。

2.3.2 リースメカニズムの詳細な分析

（１）リースの定義

リースは、発行者によって一定期間付与される契約です。発行者がリースを発行すると、受取人がリースを受け取ったかどうか、また受取人がその後どのような状態にあるかに関係なく、リースが期限切れにならない限り、発行者はその約束を厳守する必要があります。一方、受領者は、リースの有効期間内は発行者の約束を使用することができますが、リースの有効期限が切れると、引き続き使用することはできません。

（２）賃貸借契約の解釈

リースは単なる約束であるため、約束の具体的な内容は、前のセクションのデータの正確さから特定の権限まで、非常に広範囲にわたります。たとえば、同時制御では、一度に 1 つのノードにのみリースが発行され、リースを保持しているノードのみがデータを変更できます。たとえば、プライマリ-セカンダリでは、リースを保持しているノードがプライマリ ID を持ちます。

（３）リースの可用性の高さ

有効期間の導入により、ネットワーク異常の問題が効果的に解決されます。リースは一定の期間のみ有効であるため、簡単に再発行できます。リースを受け取った後は、ネットワーク通信に依存しなくなります。

（４）リースクロ​​ック同期

エンジニアリングでは、リースの有効性に影響を与えないように、発行者の有効期間は受信者の有効期間よりも長く設定され、クロック エラーよりも大きくなります。

2.3.3 リースメカニズムに基づいてノードのステータスを決定します。

分散システムにおいて、ノードが正常に動作しているかどうかを判断するのが困難であること。ネットワークの断片化の可能性があるため、ネットワーク通信を通じてノードの状態を判断することはできません。

たとえば、abc は互いのレプリカであり、a はプライマリ ノード、q は監視ノードです。 q は ping を使用して abc のステータスを確認し、a が動作していないと結論付けます。プライマリノードを b に切り替えます。しかし、実際には、ping が受信されなかっただけで、問題はないと判断したため、両方の ab がマスター ノードであると認識する「デュアル マスター」問題が発生しました。

解決策は、ハートビートを送信するときに q がリースを追加し、abc のステータスが確認され、ノードがリースの有効期間内に正常に動作できることを示すことです。 q はプライマリ ノードに特別なリースを付与し、ノードがプライマリとして機能することを示します。 q がプライマリに切り替えたい場合、デュアルプライマリの問題を回避するには、以前のプライマリのリースの有効期限が切れるまで待つだけです。

2.3.4 リース有効期間の選択

工学では一般的に10秒が選ばれる

2.4 クォーラムメカニズム

2.4.1 すべて書き込み、1つ読み取り

更新操作 Wi の場合、N 個のレプリカすべてで更新が成功した場合にのみ、「正常に送信された更新操作」と見なされ、対応するデータは「正常に送信されたデータ」となり、データ バージョンは Vi になります。

欠点:

バージョン番号の頻繁な読み書きはボトルネックになりやすい

N-1 個のコピーが成功した場合でも、更新は失敗と見なされます。

2.4.2 クォーラム定義

WARO は読み取りサービスの可用性を最大化し、書き込みサービスの可用性を犠牲にします。読み取りと書き込みの可用性を犠牲にすることで、クォーラム メカニズムが実現します。

クォーラム メカニズムでは、更新 Wi が N 個のコピーのうち W 個で成功すると、それは「正常に送信された更新操作」と呼ばれ、対応するデータは「正常に送信されたデータ」と呼ばれます。 R > N - W とし、Wi によって更新されたデータ Vi が確実に読み取れるようにするには、最大で R 個のコピーを読み取る必要があります。

WARO は、Quorum で W = N の場合の特別なケースであることがわかります。

2.4.3 正常に送信された最新のデータを読む

クォーラムの定義は、次の 2 つの仮定に基づいています。

読者は現在提出されているバージョン番号を知っている

すべての応募は成功です

ここで、これら 2 つの仮定を取り消して、次の実際の問題を分析します。

N = 5、W = 3、R = 3。ある時点でのレプリカの状態は (V2 V2 V2 V1 V1) です。理論的には、3 つのレプリカを読み取ると確実に最新のデータ V2 が生成されますが、3 つのレプリカのみを読み取っても最新のデータが保証されるわけではありません。

例えば、レプリカのステータスが (V2 V1 V1 V1 V1) のとき、(V2 V1 V1) も読み取られるため、読み取られるのは (V2 V1 V1) であり、このとき V2 バージョンのデータは送信に失敗したことになります。したがって、3 のみを読み取っても、最新の有効なバージョンが V2 か V1 かを判別することはできません。

解決：

送信される更新操作は厳密に増分である必要があり、次の更新操作は前の更新操作が成功した後にのみ送信できます。バージョン番号の成功を確実にする

R 個のコピーを読み取り、バージョン番号が最も高いデータの場合、W 個のコピーがすでに存在する場合は、このデータが最新の結果になります。それ以外の場合は、X 個のコピーがあると仮定して、このバージョンの W 個のコピーが正常に読み取られるまで他のコピーの読み取りを続けます。 W が見つからない場合は、2 番目に大きいバージョン番号が、正常に送信された最新のバージョンになります。

したがって、クォーラム メカニズムのみを使用する場合、正常に送信された最新のバージョンを決定するには、最大で R + (W - R - 1) = N 個のコピーを読み取る必要があります。実際のプロジェクトでは、N 個のコピーを読み取る必要性を回避するために、クォーラムとプライマリ/セカンダリの組み合わせが一般的に使用されます。

2.4.4 クォーラムメカニズムに基づくプライマリ選択

クォーラム メカニズムはプライマリ-セカンダリ プロトコルで導入されています。プライマリは、W レプリカを正常に更新した後、ユーザーに成功メッセージを返します。

プライマリに障害が発生した場合、新しいプライマリを選択し、セカンダリコピーがプライマリとデータを同期する。

通常、プライマリスイッチは監視ノード q によって完了します。クォーラムの導入後、新しいプライマリを選択する方法はデータの読み取りと同様です。つまり、q は R 個のレプリカを読み取り、R 個のレプリカの中で最もバージョン番号が高いレプリカを新しいプライマリとして選択します。新しいプライマリは、q によって選出されたレプリカを除く少なくとも W 個のレプリカとのデータ同期を完了した後、新しいプライマリとして機能します。

基本原則は次のとおりです。

R コピーの中で最もバージョン番号が高いコピーには、正常に送信された最新のデータが含まれている必要があります。

最も高いバージョン番号を持つデータが最新の正常に送信されたデータであるかどうかは確実ではありませんが、新しいプライマリは W コピーの更新を直ちに完了し、それを正常に送信されたデータにします。

たとえば、N = 5、W = 3、R = 3 のシステムでは、ある瞬間のレプリカの状態は (V2 V2 V1 V1 V1) です。このとき、V1 は正常に送信された最新のデータであり、V2 は正常に送信されていない中間状態のデータです。 V2 がダーティ データとして破棄されるか、新しいデータとして同期されるかは、q がホストする新しいプライマリの選挙会議に参加できるかどうかによって完全に決まります。 qが(V1 V1 V1)を選択した場合、V2は後続の更新プロセスでダーティデータとして破棄されます。 q が (V2 V1 V1) を選択した場合、V2 は V1 を更新し、最新の成功データになります。

2.5 ログ技術

ログ技術は分散システム技術ではありませんが、分散システムではダウンタイムの回復にログ技術が広く使用されています。

2.5.1 データベースシステムログの確認

データベース ログは、undo、redo、redo/undo、no-redo/no-undo の 4 種類に分かれていますが、ここでは詳しく紹介しません。

2.5.2 やり直しとチェックポイント

ダウンしたマシンを REDO ログを使用して復元する場合の欠点は、REDO ログ全体をスキャンし、すべての REDO ログを再生する必要があることです。この問題の解決策は、チェックポイント技術を導入することです。簡略化されたモデルでは、チェックポイントは開始と終了の間にあり、メモリは特定のデータ編成方法でディスクにダンプされます。このように、ダウンしたマシンを復元するときには、最後の終了から最新の開始を見つけて、中間のメモリ状態を復元するだけで済みます。

2.5.3 元に戻す/やり直し不可

この技術は 01 ディレクトリとも呼ばれ、つまり、アクティブ ディレクトリと非アクティブ ディレクトリの 2 つのディレクトリがあり、マスター レコードも存在し、「レコード ディレクトリ 0」または「使用ディレクトリ 1」のいずれかになります。ディレクトリ 0 と 1 には、ログ ファイル内の各データの場所が記録されます。

2.6 2相コミットプロトコル

2.7 MVCC に基づく分散トランザクション

どちらもデータベース トランザクションに関連しており、2 フェーズ コミット プロトコルはエンジニアリングではあまり使用価値がないため、ここでは省略します。

2.8 パクソスプロトコル

エンジニアリングにおいて使用価値のある唯一の分散型レプリカノード制御プロトコル。複雑すぎて理解できません。

2.9 CAP理論

一貫性

在庫状況

ネットワークの分割に対する耐性

CAP の 3 つの特性を完全に備えた分散プロトコルを設計することは不可能です。 3 つの間で妥協することしかできません。この理論の意味は、「完璧な分散システムを設計することを夢見てはいけない」ということです。