分散ソリューションの概要

単一マシンの容量、パフォーマンス、高可用性などのボトルネックを解決するために、分散ファイルシステム、分散コンピューティング、分散メッセージング、分散トランザクション、分散データベースなど、さまざまな分散テクノロジーとソリューションが登場しています。さまざまなシナリオでさまざまな問題を解決します。この記事では、その原理と機能について簡単に説明します。理解が十分ではないかもしれません、多くの抜粋があります、私を訂正してください。

記事のディレクトリ

- - 分散ソリューションの概要

1.原則とツール

CAPの原則： CAPの原則は、CAP定理とも呼ばれます。これは、分散システムの一貫性、可用性、およびパーティションの許容範囲を指します。CAPの原則は、これら3つの要素が同時に達成できるのは2つのポイントのみであり、3つすべてを処理することは不可能であることを意味します。
BASE： BASEは、CAPの整合性と可用性のバランスの結果であり、大規模なインターネットシステムの分散型プラクティスの結論に基づいています。CAP定理に基づいて徐々に進化しています。その核となる考え方は、強い整合性があっても達成することはできません（強い一貫性）が、各アプリケーションは、システムが独自のビジネス特性に従って結果整合性を達成するように適切な方法を採用できます。次に、BASEの3つの要素について詳しく説明します。基本的に利用可能：これは、予測できない障害が発生した場合に、分散システムがその可用性の一部を失うことを許可されることを意味します。
PAXOSアルゴリズム： Paxosアルゴリズムによって解決される問題は、分散システムが特定の値（解像度）についてどのように合意できるかということです。典型的なシナリオは、分散データベースシステムで、各ノードの初期状態が同じであり、各ノードが同じ一連の操作を実行する場合、最終的に一貫した状態を取得できるというものです。各ノードが同じコマンドシーケンスを実行することを保証するために、「一貫性アルゴリズム」を各命令で実行して、各ノードによって見られる命令が一貫していることを保証する必要があります。一般的なコンセンサスアルゴリズムは多くのシナリオに適用でき、分散コンピューティングの重要な問題です。したがって、コンセンサスアルゴリズムの研究は1980年代以降停止していません。ノード通信には、共有メモリとメッセージパッシングの2つのモデルがあります。Paxosアルゴリズムは、メッセージパッシングモデルに基づくコンセンサスアルゴリズムです。
Zookeeperサービス： ZooKeeperは、分散型のオープンソース分散型アプリケーション調整サービスです。分散アプリケーションに一貫したサービスを提供するソフトウェアです。提供される機能には、構成の保守、ドメイン名サービス、分散同期、グループサービスなどがあります。ZooKeeperはFastPaxosアルゴリズムに基づいています。Paxosアルゴリズムにはライブロックの問題があります。つまり、複数のプロポーザルがずらして送信されると、相互に排他的で、誰も正常に送信できない場合があります。FastPaxosはいくつかの最適化を行い、合格しました。選挙リーダー（リーダー）が生成され、リーダーのみが提案を送信できます。

2.分散ファイルシステム（HDFS）

Hadoop分散ファイルシステム（HDFS）は、コモディティハードウェアでの実行に適した分散ファイルシステムとして設計されています。既存の分散ファイルシステムと多くの共通点があります。しかし同時に、それと他の分散ファイルシステムとの違いも非常に明白です。HDFSは、フォールトトレラント性の高いシステムであり、安価なマシンへの展開に適しています。HDFSは、高スループットのデータアクセスを提供できます。これは、大規模なデータセットのアプリケーションに非常に適しています。HDFSは、ファイルシステムデータをストリーミングする目的を達成するために、いくつかのPOSIX制約を緩和します。
HDFSはマスター/スレーブアーキテクチャを使用します。HDFSクラスターは、Namenodeと特定の数のDatanodeで構成されます。Namenodeは、ファイルシステムの名前空間とファイルへのクライアントアクセスの管理を担当する中央サーバーです。クラスター内のデータノードは通常1つのノードであり、それが配置されているノード上のストレージの管理を担当します。HDFSはファイルシステムの名前空間を公開し、ユーザーはファイルの形式でファイルシステムにデータを保存できます。内部的な観点から、ファイルは実際には1つ以上のデータブロックに分割され、データノードのグループに保存されます。Namenodeは、ファイルまたはディレクトリのオープン、クローズ、名前変更など、ファイルシステムの名前空間操作を実行します。また、特定のデータノードノードへのデータブロックのマッピングを決定する役割も果たします。Datanodeは、ファイルシステムクライアントからの読み取りおよび書き込み要求の処理を担当します。Namenodeの統一されたスケジューリングの下で、データブロックを作成、削除、および複製します。
ここに画像の説明を挿入します
NamenodeとDatanodeは、通常の商用マシンで実行するように設計されています。これらのマシンは通常、GNU / Linuxオペレーティングシステム（OS）を実行します。HDFSはJava言語で開発されているため、JavaをサポートするすべてのマシンでNamenodeまたはDatanodeをデプロイできます。移植性の高いJava言語のおかげで、HDFSは複数のタイプのマシンにデプロイできます。典型的なデプロイメントシナリオは、1つのマシンで1つのNamenodeインスタンスのみが実行され、クラスター内の他のマシンが1つのDatanodeインスタンスを実行することです。このアーキテクチャは、1台のマシンで複数のデータノードを実行することを排除するものではありませんが、そのようなケースは比較的まれです。
クラスタ内の単一のNamenodeの構造により、システムアーキテクチャが大幅に簡素化されます。Namenodeは、すべてのHDFSメタデータのアービターおよびマネージャーであるため、ユーザーデータがNamenodeを通過することはありません。
参照ドキュメント：http：//hadoop.apache.org/docs/r1.0.4/cn/hdfs_design.html

3つの分散コンピューティング（Map / Reduce）

Hadoop Map / Reduceは、使いやすいソフトウェアフレームワークです。これに基づいて作成されたアプリケーションは、数千台の商用マシンで構成される大規模なクラスターで実行でき、信頼性が高くフォールトトレラントな方法でTレベルのデータセットを並行して処理できます。。。
Map / Reduceジョブは通常、入力データセットをいくつかの独立したデータブロックに分割し、マップタスク（タスク）はそれらを完全に並列に処理します。フレームワークは、最初にマップの出力をソートし、次に結果をreduceタスクに入力します。通常、ジョブの入力と出力はファイルシステムに保存されます。フレームワーク全体が、タスクのスケジューリングと監視、および失敗したタスクの再実行を担当します。
一般に、Map / Reduceフレームワークと分散ファイルシステムは同じノードのセットで実行されます。つまり、コンピューティングノードとストレージノードは通常一緒になります。この構成により、フレームワークはデータが格納されているノードでタスクを効率的にスケジュールできるため、クラスター全体のネットワーク帯域幅を非常に効率的にすることができます。
ここに画像の説明を挿入します

Map / Reduceフレームワークは、クラスターノードごとに単一のマスターJobTrackerとスレーブTaskTrackerで構成されます。マスターは、ジョブを構成するすべてのタスクをスケジュールする責任があります。これらのタスクは、異なるスレーブに分散されます。マスターは、それらの実行を監視し、失敗したタスクを再実行します。スレーブは、マスターによって割り当てられたタスクの実行のみを担当します。
アプリケーションは、少なくとも入力/出力の場所（パス）を指定し、適切なインターフェイスまたは抽象クラスを実装することにより、mapおよびreduce関数を提供する必要があります。他のジョブのパラメーターとともに、ジョブ構成を構成します。次に、Hadoopのジョブクライアントは、ジョブ（jarパッケージ/実行可能プログラムなど）と構成情報をJobTrackerに送信します。JobTrackerは、これらのソフトウェアと構成情報をスレーブに配布し、タスクをスケジュールし、実行を監視すると同時に、ステータスと診断を提供します。ジョブクライアントへの情報。
HadoopフレームワークはJavaTMで実装されていますが、Map / ReduceアプリケーションをJavaで作成する必要はありません。
参照ドキュメント：http：//hadoop.apache.org/docs/r1.0.4/cn/mapred_tutorial.html

4つの分散データベース（OceanBase）

OceanBaseは、AntFinancialとAlibabaによって完全に独立して開発された分散型リレーショナルデータベースです。2010年に設立されました。OceanBaseは、強力なデータ整合性、高可用性、高パフォーマンス、オンライン拡張、SQL標準および主流のリレーショナルデータベースとの高い互換性、および低コストという特徴を備えており、高いパフォーマンス、コスト、およびスケーラビリティの要件がある財務シナリオに適しています。

主な特徴：

高性能：OceanBaseは、読み取り/書き込み分離アーキテクチャを使用して、データをベースラインデータとインクリメンタルデータに分割します。インクリメンタルデータはメモリ（MemTable）に保存され、ベースラインデータはSSDディスク（SSTable）に保存されます。データへの変更はインクリメンタルデータであり、メモリのみが書き込まれます。したがって、DMLは、非常に高いパフォーマンスを備えた完全なメモリ操作です。
低コスト：OceanBaseは、データエンコーディング圧縮技術を通じて高圧縮を実現します。データエンコーディングは、データベースリレーショナルテーブルのさまざまなフィールドの値の範囲とタイプ情報に基づく一連のエンコーディング方法であり、一般的な圧縮アルゴリズムよりもデータをよく理解し、より高い圧縮効率を実現できます。PCサーバーとローエンドSSDを使用すると、高いストレージ圧縮率でストレージコストが削減され、高性能でコンピューティングコストが削減され、マルチテナント混合ユニットがシステムリソースを最大限に活用します。
高可用性：データは複数のコピーに保存され、いくつかのコピーの失敗はデータの可用性に影響しません。「3つの場所と5つのセンター」の展開により、都市レベルの障害の自動非破壊災害復旧が実現されます。
強力な一貫性：データの複数のコピーがpaxosプロトコルを介してトランザクションログを同期し、大多数が送信できるのは成功したトランザクションのみです。デフォルトでは、強い一貫性を確保するために、読み取りおよび書き込み操作がマスターコピーに対して実行されます。
スケーラブル：クラスターノードはすべてピアツーピアであり、各ノードにはコンピューティング機能とストレージ機能があり、ボトルネックの単一のポイントはありません。直線的およびオンラインで拡張および縮小できます。
互換性：一般的に使用されるMySQL / ORACLE関数およびMySQL / ORACLEフロントエンドおよびバックエンドプロトコルと互換性があります。ビジネスは、ゼロまたはわずかな変更でMySQL / ORACLEからOceanBaseに移行できます。

アプリケーションシナリオ：

OceanBaseの製品ポジショニングは分散リレーショナルデータベースです。OceanBase製品は、高可用性と強力な一貫性を必要とし、パフォーマンス、コスト、スケーラビリティを必要とする、トランザクション、支払い、会計などを含む金融、証券などに適しています。属性シナリオ、およびさまざまなリレーショナル構造化ストレージOLTPアプリケーション。

ソフトウェアアーキテクチャ：

OceanBaseはシェアードナッシングアーキテクチャとして設計されているため、共有ストレージ構造はありません。少なくとも3つのゾーンを展開する必要があり、データは各ゾーンに保存されます。OceanBaseの設計全体に単一のポイントはありません。各ゾーンには複数のObServerノードがあり、アーキテクチャからの高信頼性と高可用性の問題を解決します。
各ノードは完全に同等であり、それぞれに独自のSQLエンジンとストレージエンジンがあります。ストレージエンジンはローカルデータにのみアクセスできますが、SQLエンジンはグローバルスキーマにアクセスして分散クエリプランを生成できます。クエリエグゼキュータは、各ノードのストレージエンジンにアクセスし、各ノード間でデータを分散および収集し、分散プランの実行を完了して、結果をユーザーに返すことができます。
ノードの1つはさらにRootServiceサービスを引き受け、RootServiceは各ゾーンに複数のデバイスを分散させます。リースは、メインのRootServiceとすべてのObServerの間で維持されます。ObServerに障害が発生すると、メインのRootServiceは障害回復操作を検出して実行できます。RootServiceはObServerプロセスの機能モジュールであり、各ObServerにはRootService機能があります。RootServiceの機能には、主にサーバーとゾーンの管理、ゾーンの管理、毎日のマージ制御、システムのブートストラップ、DDL操作などが含まれます。

5つの分散メッセージング（Kafka）

分散アーキテクチャ：

各ブローカーはkafkaサーバーを表し、複数のメッセージプロデューサーとコンシューマーを同時にサポートします。
メッセージはトピックトピックの単位で管理されます。各トピックには、異なるブローカーに格納された複数のパーティションを含めることができます。
Kafkaでは、トピックパーティションに複数のコピーを含めることができ、サーバー側でパーティションコピーの数を構成できます。クラスター内のノードに障害が発生すると、ノードは自動的にフェイルオーバーしてデータの可用性を確保できます。
Zookeeperは、Kafkaのブローカー登録とトピック登録に使用され、コンシューマーとパーティション間の通信を保存し、コンシューマーの負荷分散をトリガーし、コンシューマーのオフセットを保存します。
レプリカ作成の単位はトピックパーティションです。通常、各パーティションにはリーダーと0個以上のフォロワーがあります。レプリカの総数はリーダーの合計です。すべての読み取りおよび書き込み操作はリーダーによって処理されます。通常、パーティションの数はブローカーの数よりも多く、各パーティションのリーダーはブローカー間で均等に分散されます。すべてのフォロワーノードはリーダーノードのログを同期し、ログ内のメッセージとオフセットはリーダー内のものと一致します。（もちろん、いつでも、リーダーノードのログの最後にまだバックアップされていないメッセージがいくつかある可能性があります）。フォロワーノードは、通常のコンシューマーと同じようにリーダーノードからメッセージをプルし、ログファイルに保存します。フォロワーノードは、メッセージログをリーダーノードからバッチで独自のログファイルにプルできます。
ほとんどの分散システムと同様に、障害の自動処理には、ノード「アライブ」の概念を正確に定義する必要があります。Kafkaには、ノードが生きているかどうかを判断する2つの方法があります。ノードはZooKeeperとの接続を維持できる必要があり、ZooKeeperはハートビートメカニズムを介して各ノードの接続をチェックします。ノードがフォロワーである場合、リーダーの書き込み操作を時間内に同期できる必要があり、遅延が長すぎないようにする必要があります。

アプリケーションシナリオ：

Kafkaは、さまざまな状況（データジェネレーターをデータ処理から切り離す、未処理のメッセージをバッファリングするなど）でメッセージブローカーとして使用できます。Kafkaは、他のメッセージングシステムと比較して、スループット、組み込みパーティション、レプリケーション、およびフォールトトレランスが優れているため、理想的な大規模メッセージ処理アプリケーションになります。
Kafkaの最初のユースケースは、ユーザーアクティビティ追跡パイプラインを一連のリアルタイムのパブリッシュ/サブスクライブソースに再構築することでした。これは、Webサイトアクティビティ（Webブラウジング、検索、またはその他のユーザーアクション）が中央のトピックに公開され、各アクティビティタイプにトピックがあることを意味します。これらのフィードは、リアルタイム処理、リアルタイムモニタリング、オフライン処理、Hadoopまたはオフラインデータウェアハウスシステムにロードされたデータのレポートなど、さまざまなユースケースを提供します。
Kafkaは、外部から分散システムのログ送信機能を提供できます。ログは、ノードと動作の間のデータを記録するのに役立ち、再同期メカニズムを使用して、障害が発生したノードからデータを回復できます。Kafkaのログ圧縮機能は、この使用法をサポートしています。
データがKafkaに書き込まれた後、データはディスクに書き込まれ、フォールトトレランスのためにバックアップされます。完全バックアップまで、Kafkaはプロデューサーに書き込みが完了したと思わせます。書き込みが失敗した場合でも、Kafkaは、優れたスケーラビリティを備えたディスク構造を使用してKafkaへの書き込みを継続します。50kbと50TBのデータは同じように動作します。サーバー。大量のデータを保存でき、クライアントがデータの場所を制御できます。Kafkaは、ログストレージ、バックアップ、および伝播機能を備えた、高性能、低遅延の分散ファイルシステムと考えることができます。

メッセージ配信のセマンティック保証：

最大で1回-メッセージは失われる可能性がありますが、再送信されることはありません。
少なくとも1回-メッセージは再送信できますが、失われることはありません。
正確に1回-これはまさに人々が望んでいることであり、各メッセージは1回だけ配信されます。

その他の保証：

プロデューサーから特定のトピックパーティションに送信されたメッセージは、送信された順序で処理されます。つまり、レコードM1とレコードM2が同じプロデューサーによって送信され、M1レコードが最初に送信される場合、M1のオフセットはM2のオフセットよりも小さく、ログの前に表示されます。
コンシューマーインスタンスは、ログ内の順序でレコードを確認します。
Nコピーのトピックの場合、ログに送信されたレコードが失われないように、最大でN-1サーバーの障害を許容できます。

参照ドキュメント：https：//kafka.apachecn.org/intro.html

6つの分散トランザクション（RocketMQ）

強力な一貫性計画（データベースレベル）、2段階の提出2PC：

2PCは、各参加者（各ローカルリソースとも呼ばれます）の送信とロールバックを調整および管理するトランザクションコーディネーターの役割を導入します。2つのフェーズは、準備（投票）フェーズと送信フェーズを指します。
準備フェーズのコーディネーターが各参加者に準備コマンドを送信します。準備コマンドは、トランザクションのコミット以外のすべての完了として理解できます。すべてのリソースの応答を同期的に待機した後、2番目のフェーズであるコミットフェーズに入ります（コミットフェーズは必ずしもコミットトランザクションまたはロールバックトランザクションであるとは限らないことに注意してください）。
第1段階のすべての参加者が正常に準備に戻ると、コーディネーターはすべての参加者にcommit transactionコマンドを送信し、すべてのトランザクションが正常にコミットされるのを待ってから、トランザクションの実行成功を返します。
1人の参加者が最初の段階で失敗を返した場合、コーディネーターはすべての参加者にトランザクションをロールバックする要求を送信します。つまり、分散トランザクションの実行は失敗します。
2番目のステージのコミットが失敗した場合、2番目のステージがロールバックトランザクション操作を実行する場合、答えはすべての参加者がロールバックされるまで再試行を続けることです。そうでない場合、最初のステージで正常に準備した人はWithをブロックし続けます。
第2段階のコミットが失敗した場合、第2段階がトランザクション操作をコミットする場合、答えは再試行を続けることです。一部の参加者のトランザクションが正常に送信された可能性があり、現時点では1つの方法しかありません。急いで、再試行を続けてください。送信が成功するまで、最終的には実際には機能せず、手動でしか処理できません。
コーディネーターは失敗し、新しいコーディネーターが選挙を通じて獲得されます。

TCC（試して-確認-キャンセル）：

試行とは、予約、つまりリソースの予約とロックを指し、予約に注意を払います。
確認とは確認操作のことで、実際に実行されます。
キャンセルとは、キャンセル操作のことで、予約フェーズでのアクションのキャンセルと理解できます。
たとえば、トランザクションで3つの操作A、B、およびCを実行する必要がある場合は、最初に3つの操作の予約アクションを実行します。すべての予約が成功した場合は確認操作が実行され、1つの予約が失敗した場合は、すべてのキャンセルアクションが実行されます。TCCモデルには、TCCグローバルトランザクションステータスを記録し、トランザクションをコミットまたはロールバックするために使用されるトランザクションマネージャーの役割もあります。
ビジネスレベルでは、Try-Confirm-Cancelに対応するように各操作に対して3つのアクションを定義する必要があるため、TCCはビジネスに大きな侵入をし、ビジネスを緊密に結合します。特定の操作に対応する操作を設計する必要があります。シナリオとビジネスロジック。さらに、元に戻す操作と確認操作の実行を再試行する必要がある場合があるため、操作がべき等であることを確認する必要もあります。
2PCや3PCに比べて、TCCの用途は広いですが、開発量も多く、結局のところ、すべてビジネスで実現されており、この3つの方法を書くのが非常に難しい場合があります。ただし、TCCはビジネスで実装されるため、データベース間およびさまざまなビジネスシステム間でトランザクションを実装できます。

結果整合性、ローカルメッセージテーブル：

支払いサービスと会計サービスを例にとると、おおよそのプロセスは次のとおりです。ユーザーが支払い注文を完了し、支払いサービスが正常に支払われた後、ユーザーは会計サービスインターフェイスを呼び出して、データベースへの元の会計伝票を生成します。ユーザーは支払いを完了した後、すぐにユーザーに支払いフィードバックを提供する必要があるため、ユーザーに支払いが成功したことを通知するだけで済みます。
ローカルメッセージテーブルは、その名前が示すように、ローカルメッセージを格納するためのテーブルであり、通常はデータベースに格納されます。そして、事業が実行されると、事業の実行（決済サービス）とメッセージをメッセージテーブルに入れる操作が同じトランザクションになり、メッセージを入れる事業が保証されます。ローカルテーブルを正常に実行する必要があります。
次に、次の操作（アカウンティングサービス）の呼び出しに進みます。次の操作が正常に呼び出された場合、メッセージテーブルのメッセージステータスを直接成功に変更できます。
呼び出しが失敗した場合は問題ありません。ローカルメッセージテーブルを定期的に読み取り、失敗したメッセージを除外して、対応するサービスを呼び出すバックグラウンドタスクがあります。サービスの更新が成功すると、メッセージのステータスが変更されます。
このとき、メッセージに対応する操作が失敗する可能性があるため、再試行する必要があります。再試行では、対応するサービスメソッドがべき等であることを確認する必要があり、通常、再試行の最大回数があります。回数を超えると、手動処理のためにアラームを記録できます。

結果整合性、トランザクションメッセージ（RocketMQ）：

トランザクションメッセージスキームを使用して、ローカルメッセージテーブルスキームを置き換えることができます
最初のステップは、トランザクションメッセージ、つまりハーフメッセージをブローカーに送信することです。ハーフメッセージはハーフメッセージを意味しませんが、メッセージはコンシューマーには見えません。送信者は送信後にローカルトランザクションを実行します。成功しています。次に、ローカルトランザクションの結果に基づいて、CommitコマンドまたはRollBackコマンドをブローカーに送信します。
また、RocketMQの送信者は、カウンターチェックトランザクションステータスインターフェイスを提供します。メッセージが一定期間操作要求を受信しない場合、ブローカーは、送信者のトランザクションがカウンターチェックインターフェイスを介して正常に実行されたかどうかを認識します。 CommitまたはRollBackコマンドを実行します。
Commitの場合、サブスクライバーはメッセージを受信し、対応する操作を実行して、完了後にメッセージを消費できます。
RollBackの場合、サブスクライバーはこのメッセージを受信できません。これは、トランザクションが実行されていないことを意味します。
RocketMQを介して実装するのは比較的簡単であることがわかります。RocketMQはトランザクションメッセージの機能を提供し、トランザクションリバースチェックインターフェイスを定義するだけで済みます。

参照文書：https：//zhuanlan.zhihu.com/p/183753774