整合性プロトコルを導入する前に、まず分散システムを理解することができます。私たちが学校にいたとき、実践プロジェクトは間違いなく一元化されたデプロイメントでした。たとえば、Tomcatは、次のように、多くの小さなプロジェクトを含めて解決されました。
ただし、サービスパフォーマンス要件の規定がある場合、または単一障害点などの問題を回避するために、一元的な展開ではニーズを満たすことができない場合があります。ハードウェアまたはソフトウェアコンポーネントが異なるネットワークコンピューターに分散され、メッセージパッシングを通じてのみ相互に通信および調整するシステム、これは分散システムです。
その特徴は次のとおりです。
- 配布
- 同等
- 並行性
- グローバルクロックの欠如
- いつでも失敗する
配布
分散システムであるため、最も明らかな機能は分散である必要があります。単純な観点から、プロジェクトが比較的大きいと仮定すると、プロジェクト全体をさまざまな機能に分割したり、ユーザーマイクロサービスなどの専門的なポイントが異なるマイクロサービスに分割したりできます。製品マイクロサービス、注文マイクロサービス、これらのサービスは異なるTomcat、異なるサーバー、または異なるクラスターにデプロイされ、アーキテクチャ全体が異なる場所に分散され、空間的にランダムであり、いつでも増加します、サーバーノードなどを削除します。
同等
等価性は分散設計の目標です。分散システムアーキテクチャを完成させるために、大規模な単一システムをマイクロサービスに分割し、それを異なるサーバークラスターに展開することは間違いありません。分割後に完了した各マイクロサービスは問題を見つける可能性があり、プロジェクト全体に問題を引き起こす可能性があります。
たとえば、注文サービスは、注文サービスの問題を回避するために、一般にバックアップが必要です。単一障害点を回避するために、上記のように、注文サービスに問題がある場合、元の注文サービスを置き換えることができます。
これには、2つ（または3つ以上）の注文サービスが完全に等しく、機能が完全に一貫している必要があります。実際、これは一種のサービスコピーの冗長性です。
もう1つは、データベースやキャッシュなどのデータコピーの冗長性であり、上記の注文サービスと同じですが、セキュリティ上の理由から、同等の意味であるまったく同じバックアップが必要です。
並行性
並行性は実際には私たちにとって新しいものではありません。並行プログラミングを学ぶ場合、マルチスレッド化が並行性の基礎となります。しかし、ここではマルチスレッドの観点に触れていません。同時コーディングを導入すると、すべてが同じマシンと同じJVMの観点にいるため、複数のJVMの観点から、たとえば、分散型システム内の複数のノードが、分散ロックの問題を含むいくつかの共有リソースおよびその他の問題を同時に操作する場合があります。
グローバルクロックの欠如
分散システムでは、ノードは任意の位置に配置でき、各ロケーションには各ノードに独自の時間システムがあるため、分散システムでは、最初に絡み合った2つのトランザクションを定義することは困難であり、その理由はこれは、制御するグローバルクロックシーケンスがないためです。もちろん、タイムサーバーを呼び出すことで問題を解決できます。
障害はいつでも発生する可能性があります
サーバークラスターが多いほど、障害が発生する可能性が高くなり、クラスターの数が増えると、障害は通常の状態になります。
上記の分散システムの特徴を簡単に紹介しましたが、実際の分散システムではどのような単純な問題が発生しますか？通信异常あります： 网络分区、三态、、节点故障
異常なコミュニケーション
通信異常は、実際にはネットワーク異常であり、ネットワークシステム自体は信頼できず、分散システムはネットワークを介してデータを送信する必要があるため、必然的にネットワークファイバーやルーターなどのハードウェアに問題が発生します。ネットワークに問題がある限り、それはメッセージの送受信プロセスに影響を与えるため、データメッセージの損失または拡張は非常に一般的になります。
ネットワークパーティション
ネットワーク分割は実際にはスプリットブレイン現象です。システム全体の調整を管理するリーダーがいました。すべてが順調でした。突然ネットワークの問題が発生しました。一部のノードはリーダーの指示を受信できませんでした。この場合は、システムを調整する新しいリーダーが表示されます。ただし、元のリーダーはまだ存在し、クラッシュはありませんが、ネットワークシステムが一時的に中断されます。現時点では、問題が発生します。同じシステムでは、異なるリーダーが調整しているため、このシステムに混乱が生じることは避けられません。
このような統合失調症は、さまざまな問題が原因で、同じ領域（分散クラスター）に2人の担当者が競合している場合に発生します。ここでは、脳分割と呼ばれ、ネットワーク分割とも呼ばれます。
トライステート
3つの状態とは何ですか？3つの状態は実際には成功であり、失敗以外の3番目の状態はと呼ばれ超时态ます。JVMでは、成功または失敗のメソッド関数を呼び出した後、および分散システムでは、アプリケーションは明確な応答を受け取りますが、成功または失敗への応答はほとんどの場合受け入れられますが、ネットワーク例外が発生すると、タイムアウトが発生する可能性が高く、タイムアウトが発生すると、ネットワーク通信の開始側は、リクエストが正常に処理されたかどうかを判断できません。
ノード障害
これは実際に機能で導入されます。ノード障害は分散システムで比較的一般的な問題です。サーバークラスタを形成するノードで発生するダウンタイムまたは「ゾンビ」の現象を指します。この現象は頻繁に発生します。
CAP理論
さて、上記の問題を理解した後、どのようにそれらを解決しますか？まず、一般的に上記の問題を3つの角度から解決できCAP理论ます。CAPは実際には、一貫性、可用性、およびパーティションの許容範囲です。
一貫性
一貫性はトランザクションACID [Atomicity、Consistency、Isolation、Durability]の特性であり、MySQLの導入時に詳細に導入されました。ここでの一貫性は基本的には同様ですが、現在は分散環境が検討されているため、単一のデータベースではない可能性があります。
分散システムでは、一貫性とは、複数のコピー間でデータの一貫性が保証されるかどうかであり、ここでの一貫性は、前述の同等性と似ています。特定のデータ項目への変更が分散システムで正常に実行できる場合、すべてのユーザーが最新の値をすぐに読み取ることができ、そのようなシステムは強い整合性があると見なされます
使いやすさ
可用性とは、システムが常に利用可能でなければならないサービスを提供し、ユーザーの操作要求が常に限られた時間内に結果にアクセスできることを意味します。限られた時間を達成するために、キャッシュを使用し、負荷を使用する必要がある場合があります。現時点では、サーバーによって追加されたノードはパフォーマンスを考慮したものであり、結果を返すためにサーバーマスターとバックアップを考慮する必要があります。単一障害点などの問題を回避するために、できるだけ早く交換できます。
パーティションのフォールトトレランス
分散システムでネットワークパーティションの障害が発生した場合でも、ネットワーク環境全体に障害が発生していない限り、一貫性と可用性を満たすサービスを提供できる必要があります。
BASE理論
次に、分散システムで上記のCAP理論の3つの要件を同時に満たすことができますか。申し訳ありませんが、実現することはできません。満たすことができるのは2つだけなので、いくつかの選択肢があります。次のように：
| トレードオフ | 説明文 |
|---|---|
| ギブアップP （ACを満たす） |
1つのノードにデータとサービスを配置して、ネットワークによる悪影響を回避し 、システムの可用性と一貫性を完全に保証しますが、システムのスケーラビリティを放棄するPの手段は放棄します |
| 放棄A （PCに会う） |
ノードやネットワークに障害が発生した場合、影響を受けるサービスは一定時間待機する必要がある ため、待機中はシステムが外部に通常のサービスを提供できず、利用できません。 |
| ギブアップC （PAに会う） |
システムはデータのリアルタイムの一貫性を保証できませんが、データが最終的に一貫性を保証することを約束します。 したがって、データの不整合のウィンドウ期間があり、ウィンドウ期間の長さはシステムの設計に依存します |
しかし、私たちは分散システムであるため、Pをあきらめた場合、単一のノードに戻らないため、AまたはCをあきらめることを考えていますが、完全にあきらめることはできないため、ビジネスに応じてのみ可能です。特定のトレードオフを取るためにできるだけ多くのニーズがあるため、BASE理論が登場しました
基本的に利用可能
分散システムで予期しない障害が発生すると、部分的な可用性が失われ、システムの「基本的な可用性」が確保されます。これは、「時間の損失」と「機能の損失」に反映されます。たとえば、一部のユーザーは11倍のピーク期間中に淘宝網ページをフリーズまたはダウングレードする場合があります。
ソフト状態
システム内のデータは中間状態で存在することが許可されています。つまり、システムの異なるノードのデータコピー間のデータ同期プロセスに遅延があり、この遅延はシステムの可用性に影響を与えないと考えられています。例：春節12306 Webサイトのチケット発行中に、リクエストがキューに入る場合があります。
最終的に一貫
一定期間のデータ同期の後、すべてのデータは最終的に一貫した状態に到達できます。たとえば、銀行APPの送金金額は一時的に一貫していません
