分散ロックを正式に導入する前に、分散システムとCAP定理を確認する必要があります。自分自身と敵を知ることによってのみ、分散ロックの概念が現れる理由を知ることができます。
言うまでもありませんが、この記事のトピックに直接アクセスしてください。
1.分散型とクラスター型の違い
分散システムは一夜にして構築されるのではなく、いくつかの段階を経て進化しました。
1.スタンドアロン
スタンドアロンとは、サーバーにシステムをデプロイすることを意味し、すべての要求はこのサーバーによって処理されます。
明らかに、ビジネスの成長が速すぎると、サーバーはビジネスニーズをまったく満たすことができず、単一のアプリケーションも非常に複雑で需要の発展に対応できません。マシンに障害が発生すると、アプリケーション全体が使用できなくなります。
2.クラスター
QPSが大きすぎるなど、機械がビジネスの発展を支えるのに十分でない場合は、この時点で拡張を検討し、同じサービスを多形機械に展開して外界にサービスを提供します。このようにして、処理能力はN倍に増加します（非線形関係）。これはクラスターであり、単一のマシンのマルチインスタンスです。
短所：深刻なビジネスカップリング、非コアビジネスはコアビジネスに影響を与える可能性があります;リソースの浪費を引き起こします;拡大を助長しません。
3.分散
クラスターはビジネス要求のプレッシャーを少し共有できますが、すべてのTaobaoシステム（注文、ロジスティクス、支払い、マーケティング、リスク管理など）が1つのアプリケーションに含まれている場合、アプリケーションが爆発すると推定されると想像してください。 、1,000台のマシンがある場合でも、クラスターはビジネス上のプレッシャーに耐えられない場合があります。このとき、アプリケーション全体を注文、ロジスティクス、支払い、マーケティングなどのアプリケーションに分割するサービス分割を考えました。さまざまなアプリケーションがRPCまたはHTTPを介して通信します。同時に、サービスの可用性を確保するために、分割された各アプリケーションをクラスターモードにすることができます。
分散システムは、ネットワークを介して疎結合された独立したサーバーで構成されています。このシステムでは、各サーバーは独立したホストであり、サーバーは内部ネットワークを介して接続されています。
2.ビザンチン将軍問題
分散システムについて話す前に、「ビザンチン将軍問題」について言及する必要があります。
ビザンチン将軍問題は、実際には、分散システムにおけるネットワーク通信のフォールトトレランスの問題を説明するための架空の歴史的な話にすぎません。
ビザンチン将軍問題は、9人の将軍が一緒に戦っていることを前提としています。攻撃するか撤退するかを決定するとき、彼らはそれを解決するために投票することを選択します。各将軍はメッセンジャーを通じて他の将軍にそれを渡すことを選択します。通常の状況では、戦闘状況が後退することを想定し、5人の将軍が後退し、4人の将軍が攻撃することを選択すると、少数派は多数派の原則に従い、後退することを選択します。退却することを選択しましたが、攻撃することを選択しました。6回の攻撃> 3回の退却ですが、最後の攻撃は失敗しました。2人のメッセンジャーが殺され、最後の4回の攻撃> 3回の退却も失敗する可能性があります。
実際の分散環境に対応して、
- 通常のジェネラルは、正常に実行されているコンピューターノードに対応します。
- 反抗的な将軍は、誤解を招く情報を送信できなかったコンピュータノードに対応します。
- メッセンジャーの殺害は、ネットワーク通信の障害と情報の損失に対応します。
ビザンチン将軍問題は、主に、ネットワーク通信における制御不能なネットワーク通信のために、複数のコンピューターがコンセンサス合意に達することを可能にする問題を解決することです。
3つの分散システム
「分散システムの概念と設計」という本では、分散システムの次の定義が作成されています。
分散システムとは、ハードウェアまたはソフトウェアの組織が異なるネットワークコンピューターに分散され、メッセージパッシングによってのみ相互に通信および調整するシステムです。
簡単に言えば、典型的な分散システムは、空間に任意に分散された一連の複数のプロセスで構成されています。
これらのプロセスによって展開されるマシンは、同じマシン、異なるマシン、異なるコンピュータールームのマシン、または異なる都市のマシンに配置できます。異なるマシンにデプロイされたサービスは、ネットワークを介して通信します。
分散システムには次の特徴があります。
-
分散：分散システム内のマシンの分散はいつでも変更できます。たとえば、サービスAは都市Bのマシン1に展開することも、都市Cのマシン1にすぐに展開することもできます。
-
同等性：分散システム内のコンピューターはマスターとスレーブに分割されておらず、すべてのノードが同等です。ただし、レプリカの概念は、データが失われず、サービスが利用可能であることを保証するために提供されます。
- データコピーとは、異なるノードでの同じデータの永続性を指します。特定のノードデータが失われた場合、データはコピーデータノードから取得できます。これは、分散システムでのデータ損失の問題に対する効果的な解決策でもあります。
- サービスレプリカとは、複数のノードが同じサービスを提供することを意味します。そのため、ノードに障害が発生した場合でも、レプリカノードはサービス処理要求を提供できます。
-
同時実行性：同じ分散システム内の複数のノードが、データベースや分散ストレージなどの共有リソースを同時に操作する場合があります。データの整合性や同時更新などによって引き起こされる一般的な問題。分散システムを設計するときは、これらの要素を考慮する必要があります。
-
グローバルクロックの欠如：分散システムには、分散システムのクロックとイベントのシーケンスを制御するためのグローバルクロックがありません。
-
障害は常に発生します。分散システム内のどのノードにも障害が発生する可能性があります。これらの異常な状況は、分散システムの設計で考慮する必要があります。
分散システムの問題
-
メッセージの損失と遅延：分散システムの各ノードはネットワークを介して通信します。ネットワーク内の光ファイバ、ルーター、DNSハードウェア機器の障害により、通信障害によってメッセージが失われる可能性があります。さらに、ネットワーク通信の遅延（1ms以上）のため、メッセージ遅延の問題があります。マイクロサービスのRPC呼び出し中のタイムアウト例外は、通信の遅延が原因で発生します。
-
ネットワークパーティション：サービスには分散システム内に複数のノードがあり、これらのノードは相互に通信し（データを同期し）、サービスを一緒に提供します（たとえば、要求Aはサービス1によって処理され、要求Bは次のようになります）。サービスによって処理されます2）。一部のノードが異常（ダウンしている、またはネットワークが遅延して通信できない可能性がある）の場合、通常のノードはこれらのノードとの通信を失い、ネットワークパーティションである通常のノードのみが通信できます。
システムの可用性、つまりパーティションのフォールトトレランスを確保するために、通常、複数の正常なノードが引き続き要求を正常に処理できますが、この時点で発生する可能性のある問題は、異常なノードが引き続き要求を処理できる可能性があることです。リクエスト（正常ノードと通信できないことに注意してください。異常ノードは必ずしもダウンしているとは限りません）。そのため、データを処理するときに正常ノードと異常ノードの間にデータの不整合が生じる可能性があります。
例：n1〜n5の5つのノードがあり、ネットワークパーティションが[n1n2]と[n3n5]の2つのグループに分割されているとします。
P（パーティションフォールトトレランス）を維持するために、n1は要求が来たときに要求を処理します。
C（整合性）を確保するために、n1が処理結果をn2および[n3〜n5]に同期する必要がある場合。ネットワークパーティションn13-n5はデータに同期できないため、障害に戻ることしかできません（システムは現時点では利用できません）。ステータス）;
A（可用性）を確保するために、n1が処理された結果をn2に同期するだけでよい場合。その場合、同じリクエストを処理するときに、n3-n5のデータに一貫性がない可能性があります。
-
3つの状態：分散システムにおける「3つの状態」の概念：成功、失敗、およびタイムアウト。成功と失敗は理解しやすく、ネットワークのためにタイムアウトは不可能です。通常、2つの状況があります。
-
送信者によって送信された応答は、送信プロセス中に失われ、受信者に正常に送信されませんでした。
-
受信者はメッセージを正常に受信しましたが、送信者に応答を正常に返すことができず、メッセージは失われました。
-
第四に、CAP定理
分散システムに関しては、CAP定理について話すことは避けられません。
2000年7月、Eric Brewer教授は有名なCAP予想を提案しました。これはその後証明され、CAP定理と呼ばれました。
1. CAP定理：
分散システムは、整合性（C：整合性）、可用性（A：可用性）、およびパーティションの許容範囲（P：パーティションの許容範囲）を同時に満たすことはできません。
せいぜい2つしか満足できません。
実際の分散シナリオでは、APまたはCPのみを満たすことができます。
-
整合性（C：整合性）：分散システムでは、整合性とは、複数のレプリカノード間のデータの整合性を指します。クライアントがどのノードにアクセスしても、最新の書き込みデータの同じコピーを読み取ります。そうでない場合、読み取りは失敗します（強い整合性）。一貫性により、データが正しいことが保証されます。
例：ユーザー1が1つのアイテムを購入し、アイテムの数が1減少し（1を引いた後にアイテムの数が0になると仮定）、アイテムの数-1がノード1で操作されます。一貫性がない場合（アイテム数が0になり、ノード1から変更されていないアイテム数がノード2に同期されます。このとき、ユーザー2は、ノード2で商品を表示したときに、商品の数量が1のままであることを確認し、クリックします。購入すると、売られ過ぎの原因になります。電子商取引や金融のシナリオでは、強力なデータの整合性が一般的な要件です。
-
可用性（A：可用性）：クライアントは障害のないノードにアクセスし、限られた時間内に正しく応答を返すことができます。ただし、各ノードのデータが同じ最新データであるという保証はありません。可用性は、サービスが利用可能であることを保証しますが、データが正しいことを保証するものではありません。
さらに上記の例では、製品の数を1で引いた後、2人のユーザーが異なるノードに到達するために要求する製品の数に一貫性がない可能性がありますが、製品の数の応答データを返すことができます。
-
パーティション許容値（P：パーティション許容値）：分散システムがネットワークパーティションに遭遇したときに、外部に通常のサービスを提供する必要があるという事実を指します（ノード間のネットワーク障害は通信を失い、データを同期できません）。パーティションの障害に対するクラスターのフォールトトレランスを強調します。パーティションフォールトトレランスは、分散システムの最も基本的な要件です。それ以外の場合は、分散システムを使用する必要はありません。
たとえば、データベースマスターノード1とスレーブノード2、3、および4は、サービスの可用性を確保するために異なる都市またはコンピュータールームに展開され、ネットワーク通信を使用してデータを同期し、データの整合性を確保します。ネットワークパーティションが発生した場合、データベースノード3と4が応答を失い、2つのパーティション[1,2]と[3、4]になると仮定すると、[1,2]は通常どおり外界にサービスを提供する必要があります。
2、CPまたはAP？
分散システムでは、3つのCAP定理はCPまたはAPの2つしか満たすことができません。
データベース同期更新のシナリオで分析すると、ユーザーは、コンピュータールーム1のデータアクセス層を介してMySQLマスターデータベースに更新し、ネットワークを介してコンピュータールーム2のMySQLスレーブデータベースにデータを同期することを要求します。次の図に示すように:(
画像ソース：https：//mp.weixin.qq.com/s/dnNUmlHR7-sjzjMYXID_Cw）
このシナリオでは、CAPの対応する定義は次のとおりです。
C：コンピュータールーム1のMySQLデータベースマスターノードでデータが更新され、コンピュータールーム2のMySQLデータベーススレーブノードも更新して、2つのデータベースの同じデータに一貫性を持たせる必要があります。
A：同時に、2つのリクエストがMySQLデータベースのマスターノードとスレーブノードに到着し、それらは通常どおり更新および照会できます。
P：コンピュータルーム1と2にネットワークパーティションがある場合、データを同期するためのネットワーク通信を実行できず、システム全体が使用可能である必要があります。
したがって、Aを保証するために、MySQLマスターノードとスレーブノードから同じデータに同時にアクセスすると、一貫性のない結果が生じる可能性があります。つまり、AがCを保証できないことを保証します。
メッセージの損失と高遅延が原因でネットワークパーティションが発生した場合、Cが整合性を破壊しないようにするために、ノードは最新のデータに応答できず、最終的にエラー応答を返す可能性があります。
選び方は？
注：ネットワークパーティションがある場合にのみ、CPまたはAPを選択する必要があります。CとAは、システムが正常に実行されているときに同時に存在できます。
古いデータの読み取りがシステム運用またはビジネス運用に影響を与える場合（たとえば、注文時に数量に一貫性がない場合、異なるユーザーが同じアイテムを表示する場合）、CPを選択します。それ以外の場合は、APを選択します。
5、BASE理論
CAP定理から、分散システムでは3つを同時に満たすことはできず、CPまたはAPからのみ選択とバランスをとることができることがわかります。したがって、BASE理論が生まれました。
BASEは基本的に使用可能（基本的に使用可能）、ソフト状態（ソフト状態）、および結果整合性（結果整合性）です。
BASE理論の中核は、基本的なユーザビリティと結果整合性です。
BASE理論はCAP理論におけるAPの拡張であり、可用性を強調します。この理論は非常に重要です。現在、インターネットバックエンド分散システムはBASE理論をサポートしています。
（1）基本的に利用可能
基本的な可用性とは、システムに予測できない障害（ノード障害、システムの過負荷を引き起こすバーストトラフィックなど）がある場合、サービスの低下により、システムのコア機能の可用性を確保できることを意味します。 -コア機能。
基本的な可用性を実現するための一般的な手段は次のとおりです。
- トラフィックのピークカット：アクセスリクエストをずらしてリクエストのピークを弱めます。たとえば、ダブル11の前に淘宝網を先行販売すると、ダブル11の夜のアクセスリクエストの数を減らすことができます。
- 遅延応答：システムトラフィックが大きすぎる場合、遅延キューを使用して要求を処理し、インターフェイスの応答時間を犠牲にしてコア機能を確実に使用します。
- エクスペリエンスの低下：Weiboトラフィックが大きすぎる場合は、写真やビデオの鮮明度を下げるなどの方法を使用して、システムの処理能力を向上させることができます。
- 過負荷保護：システム要求量が大きすぎる場合、要求は処理のために指定されたキューに入れられます。リクエストの待機時間が長すぎるか、キューが大きすぎる場合は、システムの過負荷を回避するために直接拒否できます。
（2）ソフト状態
ソフト状態とは、データの中間状態、つまり、異なるノードがデータコピー間で同期できるようにするプロセスを指します。
（3）結果整合性
結果整合性とは、システム内のすべてのデータコピーが、一定期間の同期後に最終的に整合性に達することができることを意味します。結果整合性は、データが短い遅延後に一貫していることを強調します。CAPの一貫性は強力な一貫性です。つまり、データはいつでも一貫性があります。強い整合性は、結果整合性の特殊なケースです。
参照：
CAPモデルに基づいて、エンタープライズレベルの真に可用性の高い分散ロック
「PaxosからZookeeperの分散整合性の原則と実際の戦闘」を設計します。