図 |分散システムをマスターする: プログラマーになるための道

[[384765]]

プログラミングは芸術であり、その魅力は創造にあります。

65 兄さんは 2 年間働き、単純で反復的なプログラミング作業を行い、CRUD しか知らない社会人になりました。

ブラザー 65: 偉い人たちが分散システムについて話しているのをよく聞きますが、分散システムとは何ですか?

分散システムとは、ハードウェアまたはソフトウェア システムが異なるネットワーク コンピューターに分散され、メッセージの受け渡しのみを通じて相互に通信および調整するシステムです。分散システムでは、独立したコンピュータのグループが、あたかも単一のシステムであるかのように、ユーザーには統合された全体として表示されます。システムにはさまざまな一般的な物理および論理リソースがあり、タスクを動的に割り当てることができ、分散された物理および論理リソースはコンピュータ ネットワークを介して情報を交換できます。

65 兄：何とかして人間の言葉を話してくれないか？理解できない。

さて、分散システムがどのように生まれ、発展してきたかを理解するために、最も身近なものから始め、実践を通して一般的な理論を要約してみましょう。これらの理論は、より完全な分散システムを設計する方法を導くための基礎となります。

この記事から、次のことを学ぶことができます。

基本的なコアでも、分散型の高同時実行シナリオでも、Java テクノロジーを共有します。あるいは、SpringBoot、MySQL、Redis、Spring Cloud などのフレームワークの原理とソースコード分析。

Web アプリケーション拡張

分散アプリケーションはなぜ登場するのでしょうか?

兄65: これについては私も知りません。以前作成した Web アプリケーションは Tomcat に直接投入され、Tomcat を起動することでアクセスできました。これは間違いなく分散アプリケーションではありません。

さて、まずは誰もが最もよく知っている Web バックエンド アプリケーションから始めましょう。以前は、当社のシステムのトラフィックは少なく、ビジネスは複雑ではありませんでした。 1 つのサーバーと 1 つのアプリケーションですべてのビジネス リクエストを処理できます。その後、当社は繁栄し、交通量も増加し、事業も拡大しました。上司は依然として私たちの給料を上げませんでしたが、私たちのシステムは不安定で、大規模な同時実行に耐えられないといつも文句を言っていました。これは耐え難いことでした。私たちは、より多くのお金と引き換えにアップグレードしたいと考えていました。

サーバーが構成を無限に追加できる場合、パフォーマンスの問題はすべて問題になりません。

システム処理能力を向上させるために、まず考えられる拡張方法は、システム構成をアップグレードし、8コアCPUを32コアまたは64コアにアップグレードし、64Gメモリを128Gまたは256Gにアップグレードし、帯域幅を10,000ギガビットまたは100,000ギガビットに増やすことです。これを垂直拡張といいます。しかし、このような拡大は、以下の理由により持続可能ではないでしょう。

1. スタンドアロンシステムの処理能力は最終的にボトルネックに達する
2. 1台のマシンをアップグレードするための限界費用はますます大きくなる

私たちプログラマーを止めるものは何もありません。

諺にあるように、システムが耐えられない場合はサーバーを追加し、1 台が機能しない場合は 2 台追加します。

垂直拡張が技術的なボトルネックに達した場合、または入出力比率が予想を超えた場合は、同時実行機能を向上させるためにサーバーの数を増やすことを検討できます。これを水平拡張と呼びます。

システム分割

65 兄：ああ、これが分散システムなんですね？それはそんなに簡単なのでしょうか？

ああ、それはそんなに簡単なことではない。水平展開ではサーバーの台数を増やしましたが、それらのサーバーが全体として外部に対していかに安定的かつ効果的なサービスを提供できるかが鍵となります。複数のサーバーが存在するため、システムをさまざまなノードに展開する方法を検討する必要があります。

兄65: これは簡単だよ。 SpringBoot プロジェクトを複数のサーバーにデプロイし、それらの前に nginx を追加しました。現在、当社のシステムは安定しており、効率的で完璧です。アーキテクチャ図を描きます (ささやき声、私はこれを学校で習いました)。

平和な人生など存在しません。ただ誰かがあなたの代わりに重荷を背負ってくれているだけです。上記のように単純に思える理由は、実際には 2 つあります。

1. システムの分離は完了していません。重要な点は、それらが依然としてデータベースを共有していることです。
2. この成熟したシステムには、前述の nginx など、私たちにサービスを提供する成熟したミドルウェアが数多くあります。

システムを分割する方法には、垂直分割と水平分割の 2 つがあります。上記の垂直拡張と水平拡張は同じ問題を扱うわけではないことに注意してください。 （兄65：ははは、わかってるよ、世の中の全ては「縦と横」の二つに過ぎないんだ）

システムの垂直分割とは、同じシステムを複数セット展開することです。すべてのノードは同じであり、同じ役割と機能を持ちます。それぞれが機能要求の一部を共有することで、システム全体の処理能力が向上します。

Web リクエストの処理の観点から見ると、垂直分割の各ノードは完全なリクエストを処理し、各ノードはリクエスト量の一部を担当します。

データ ストレージの観点から見ると、各データ ノードは同じビジネス データを格納し、各ノードはデータの一部を格納します。

システムの水平分割とは、システムを異なるモジュールまたは役割に分割し、異なるモジュールが異なる処理を処理することです。

Web リクエストの観点から見ると、リクエストを完了するには複数の相互依存システムが協力する必要があり、各ノードによって処理される要件は矛盾しています。

データ保存の観点から見ると、各データノードは独自のビジネスモジュールに関連するデータを保存しており、それらのデータは異なります。

上記の垂直分割後、各ノードはクラスターを形成し、各ノードの水平分割は分散されます。これがクラスタリングと分散の違いです。前述のように同時処理能力が向上するだけでなく、クラスターはシステムの高可用性も保証します。一部のノードに障害が発生しても、システム全体で完全なサービスを提供できます。分散システムでも同様です。同時実行機能の向上に加えて、システムの分離、システム境界の明確化、システム機能の統合も大きな利点です。そのため、実際のシステムでは両方の方法を同時に使用することが多く、よく話題に上がる分散システムには実際にクラスターの概念が含まれています。

分散ターゲット

帰納法と演繹法は人間の合理性の基礎です。学習と思考とは、過去の経験を常に要約して普遍的な法則を取得し、その法則を他の事柄に当てはめて、より実践的なプロセスを導くことです。

上記では分散システムの起源について説明しました。それでは、このプロセスを振り返って要約してみましょう。分散システムの導入は、実際のニーズと目標に基づいて行う必要があります。

65 ブラザー：配布の目的は何ですか？

Distributed は、次の目標を達成するように設計されています。

• 透明性: 透明性とは、ユーザーがシステムの背後にある配布を気にする必要がないことを意味します。システムが分散型であるかスタンドアロン型であるかにかかわらず、ユーザーに対して透過的である必要があります。ユーザーは、システムの利用可能な機能のみに注意を払う必要があります。ここでの透明性には次の側面が含まれます。
  • アクセスの透明性: アクセス インターフェイスとメソッドは固定され、統一されているため、分散システム内の変更によってシステム アクセス メソッドが変更されることはありません。
  • 場所の透明性: 外部の訪問者は分散システムの特定のアドレスを知る必要がなく、システム ノードの変更は機能に影響を与えません。
  • 同時実行の透明性: 複数のプロセスが互いに干渉することなく、共有リソースを同時に使用できます。
  • レプリケーションの透過性: リソースの複数のインスタンスを使用することで、ユーザーやプログラマーがレプリカについて知らなくても信頼性とパフォーマンスが向上します。
  • 障害の透明性: 分散システム内の一部のノードに障害が発生しても、システム全体の機能には影響しません。
  • モビリティの透明性: リソースとクライアントは、影響を受けることなくシステム内を移動できます。
  • パフォーマンスの透明性: 負荷が変化すると、システムを再構成してパフォーマンスを向上させることができます。
  • スケーラビリティの透明性: システム構造やアプリケーション アルゴリズムを変更することなく、システムとアプリケーションを拡張できます。
• オープン性: オープン性、共通プロトコル、使用方法。
• スケーラビリティ: リソース数やユーザー アクセスが増加してもシステムの有効性を維持できる場合、そのシステムはスケーラブルであると言えます。分散システムは、システムのサイズとシステム管理の点で拡張可能である必要があります。
• パフォーマンス: モノリシック アプリケーションと比較すると、分散システムはより優れたパフォーマンスを発揮します。
• 信頼性: モノリシック システムと比較して、分散システムはセキュリティ、一貫性、エラーを隠す能力が優れている必要があります。

分散型チャレンジ

流通の課題は不確実性から生じます。考えてみてください。分散システムにはモノリシック アプリケーションよりも優れている点は何でしょうか?

Brother 65: サービス ノードが増えると、サービス間のネットワーク通信も行われます。

はい、65 兄弟はシステムの考え方と分析方法を学んだようです。分散システムのすべての課題は、これら 2 つの要素の不確実性から生じます。

1. ノード障害:

ノードの数が増えるほど、障害が発生する可能性が高くなります。分散システムでは、障害が発生してもシステムが引き続き利用可能であることを保証する必要があります。これには、システムがすべてのノードのサービス ステータスを認識し、ノードに障害が発生したときにそのノードが担当するコンピューティング タスクとストレージ タスクを他のノードに転送できる必要があります。

2. 信頼できないネットワーク:

ノードはネットワークを介して通信しますが、ネットワークが信頼できないことは誰もが知っています。考えられるネットワークの問題としては、ネットワークのセグメンテーション、遅延、パケット損失、順序どおりの送信などがあります。スタンドアロンのプロシージャ呼び出しと比較して、ネットワーク通信で最も厄介なのは、タイムアウトと双方向通信の不確実性です。タイムアウトが発生すると、ネットワーク通信の開始者は、現在の要求が正常に処理されたかどうかを判断できません。

信頼性の低いネットワークやノードでも、分散システムはシステムの最も基本的な要件である可用性、安定性、効率性を確保する必要があります。したがって、分散システムの設計とアーキテクチャには多くの課題が伴います。

分割して征服する

分散システムでは、並列コンピューティングとストレージにさらに多くのリソースを最大限に活用して、システム パフォーマンスを向上させます。これが分割統治の原則です。

兄65: ああ、なるほど。では、MapReduce のマップ、Elasticsearch のシャーディング、Kafka のパーティションはすべて分散分割統治の原則に基づいているのでしょうか?

はい、クラスメート65は要約できるだけでなく、1つの例から推論を導き出すこともできます。はい、マップ、シャーディング、パーティション、またはリクエスト ルーティングの負荷分散のいずれであっても、計算またはデータを分割し、計算と保存のために異なるノードに分散することで、システムの同時実行性を向上させることが重要です。

さまざまな種類のクラスター

シャーディング

同じ点でも、分野や実装システムによって表現が異なる場合があります。シャーディングは通常、データ ストレージ システム内の異なるノードに異なるデータを分散する方法であり、中国語ではデータ シャーディングと翻訳されるのが一般的です。

たとえば、MongoDB では、MongoDB が大量のデータを保存する場合、単一のマシンではデータを保存したり、許容できる読み取りおよび書き込みスループットを提供したりするのに十分でない可能性があります。この時点で、データベース システムがより多くのデータを保存および処理できるように、複数のマシンにデータを分割できます。

たとえば、Elasticsearch では、各インデックスには 1 つ以上のシャードがあり、インデックス データは各シャードに分散されます。これは、バケツ 1 杯の水を入れるのに N 個のカップを使用するのと同じです。シャーディングは水平方向の拡張に役立ち、N 個のシャードが異なるノードに可能な限り均等に分散 (再バランス) されます。

パーティション

パーティションの概念は Kafka でよく見られます。 Kafka では、トピックは論理的な概念です。分散キューの観点から見ると、トピックはユーザー用のキューです。 Kafka の特定の実装では、トピックは異なるノードに分散されたパーティションで構成されます。各パーティションは、パーティション分割アルゴリズムに従って分割された複数のパーティションです。 Kafka では、同じグループ内の複数のコンシューマーが同じパーティションを使用することはできません。したがって、トピックが持つパーティションの数は、ある意味でこのトピックの同時処理能力を示します。

優れた分散データベース DynamoDB では、テーブルも基盤となる実装で異なるパーティションに分割されます。

負荷分散

負荷分散は、高可用性ネットワーク インフラストラクチャの重要なコンポーネントであり、通常は、Web サイト、アプリケーション、データベース、またはその他のサービスのパフォーマンスと信頼性を向上させるために、ワークロードを複数のサーバーに分散するために使用されます。

たとえば、nginx のロード バランシングでは、さまざまなロード バランシング分散戦略を通じて、Web アプリケーションのさまざまなノードに http リクエストを分散し、アプリケーションの同時処理機能を向上させます。

たとえば、dubbo のクライアント負荷容量により、dubbo リクエストを特定のプロデューサー ノードにルーティングできます。負荷分散は、完全な RPC が備えるべき機能です。

Spring Cloud システムでは、Robbin コンポーネントは Spring Cloud のマイクロサービス間の通信の負荷分散の問題を解決し、クラスター内の異なるノードにリクエストを分散することができます。

の戦略

パーティショニング、シャーディング、パーティション ルーティングのいずれの場合でも、実際にはいくつかの一般的なパーティショニング アルゴリズムが存在します。上記のリバース プロキシ サーバー nginx、分散メッセージ キュー kafka、RPC フレームワーク Dubbo など、次のような概念は、さまざまな分野の多くの学生が目にしたことがあるかもしれません。これは時々多くの学生を混乱させます。

実際、どんな分野であっても、それが果たすコア機能を把握していれば、どのように分割するか、処理要求（つまり計算）を異なるマシンに均等に分配する方法、データを異なるノードに分配する方法などの問題を検討していることが分かります。

広い視点から見ると、再現可能な戦略と再現不可能な戦略の 2 つがあります。

再現可能。この戦略では、特定のアルゴリズムに従って計算とデータを割り当てます。同じ条件下では、どの時点でも結果は同じになります。したがって、同じ条件のリクエストとデータに対して複製可能です。異なる時点の同じリクエストとデータは常に同じノード上にあります。この戦略は通常、データ ステータスがある状況で使用されます。

再現不可能。この戦略では完全にランダムな方法を使用します。同じ条件下でも、異なる時点で得られた結果は矛盾しており、これも元に戻せません。復元可能性のみを目的とする場合、割り当てられたデータがメタデータを通じて記録されていれば、後で復元する必要があるときにメタデータを使用してデータの場所を正確に把握できます。

65 兄：そんなに魔法なの？さまざまなシステムがどのような戦略を持っているかを確認したいと思います。

ダボ負荷分散

Dubbo は Alibaba のオープンソース分散サービス フレームワークです。複数の負荷分散戦略を実装します。

ランダムロードバランス

ランダム、重みによってランダム確率を設定できます。セクション上の衝突の確率は高くなりますが、通話量が多いほど均等に分散され、確率に基づく重み付けを使用した後も比較的均等になるため、プロバイダーの重み付けを動的に調整するのに役立ちます。

ラウンドロビン負荷分散

ポーリングでは、コンベンション後の重みに応じてポーリング比率を設定します。低速のプロバイダーがリクエストを蓄積するという問題があります。たとえば、2 台目のマシンは遅いですが、壊れてはいません。リクエストが 2 番目のマシンに転送されると、そこで停止します。時間が経つと、すべてのリクエストは 2 番目のマシンに転送されたときに停止します。

最小アクティブ負荷バランス

アクティブ通話の最小数、同じアクティブ番号のランダム数、アクティブ数は通話前と通話後のカウントの差を指します。低速プロバイダーでは呼び出し前後のカウントの差が大きくなるため、低速プロバイダーが受信するリクエストの数を減らします。

一貫性ハッシュロードバランス

一貫性のあるハッシュ、同じパラメータを持つリクエストは常に同じプロバイダーに送信されます。プロバイダーがクラッシュすると、そのプロバイダーに最初に送信されたリクエストは、大幅な変更を引き起こすことなく、仮想ノードに基づいて他のプロバイダーに分散されます。

Kafka のパーティション割り当て戦略

Kafka は、複数のパーティション割り当てアルゴリズム (PartitionAssignor) の実装を提供します。

範囲割り当て者

RangeAssignor 戦略の原則は、コンシューマーの合計数とパーティションの合計数を分割してスパンを取得し、スパンに応じてパーティションを均等に分散して、パーティションがすべてのコンシューマーに可能な限り均等に分散されるようにすることです。各トピックについて、RangeAssignor 戦略は、このトピックにサブスクライブするコンシューマー グループ内のすべてのコンシューマーを名前の辞書順に並べ替え、各コンシューマーの固定パーティション範囲を分割します。分布が均等でない場合は、辞書式順序が高いコンシューマーに追加のパーティションが割り当てられます。

ラウンドロビンアサイン者

RoundRobinAssignor の割り当て戦略は、コンシューマー グループとすべてのコンシューマーでサブスクライブされているすべてのトピックのパーティションを並べ替え、できるだけ均等に分散することです (RangeAssignor は、単一のトピックのパーティションを並べ替えて分散します)。

スティッキーアサイン者

文字通り、Sticky は「粘着性」を意味し、割り当て結果が「粘着性」であると理解できます。つまり、割り当ての変更ごとに、前の割り当てと比較して変更が最小限に抑えられます (前の結果は粘着性です)。これは主に、次の 2 つの目標を達成するためのものです。

パーティションの配分は可能な限りバランスが取れている

1. 各再配布の結果は、可能な限り以前の配布結果と一致するようにする必要があります。
2. 65 兄：わぁ、素晴らしいシステムが全部つながっているようだな。

インスタンス

レプリカは、分散クラスターの高可用性の問題を解決するために使用されます。クラスター システムでは、各サーバー ノードは信頼性が低く、各システムはダウンタイムのリスクにさらされます。少数のノードに障害が発生した場合にシステム全体の可用性をどのように確保するかは、分散システムの課題の 1 つです。この問題の解決策はコピーです。レプリカにより同時処理機能も向上します。たとえば、データは異なるノードで個別に読み書きでき、並列で読み取ることもできます。

実際には、マスター-サルブ、リーダー-フォロワー、プライマリ-シャード、リーダー-レプリカなど、多くの用語があります。

MySQL マスタースレーブアーキテクチャ

現在、主流のリレーショナル データベースのほとんどは、マスター スレーブ ホット スタンバイ機能を提供しています。 2 つ (またはそれ以上) のデータベース間にマスター/スレーブ関係を構成することにより、1 つのデータベース サーバー上のデータ更新を別のサーバーに同期できます。これにより、データベースの読み取りと書き込みの分離が実現され、データベースの負荷圧力が軽減されるだけでなく、データの高可用性も向上します。複数のデータバックアップにより、データ損失のリスクが軽減されます。

Elasticsearch レプリケーション メカニズム

ES には、プライマリ シャードとレプリカ シャードの概念があります。レプリカ シャーディングの主な目的は、フェイルオーバーを容易にすることです。プライマリ シャードを保持しているノードに障害が発生した場合、レプリカ シャードがプライマリ シャードの役割に昇格され、外部にクエリ サービスを提供します。

CAP理論

理論計算機科学において、CAP 定理 (ブリューワーの定理とも呼ばれる) は、分散コンピューティング システムが分散システムの一貫性、可用性、およびパーティション耐性 (つまり、CAP の「C」、「A」、「P」) の要件を同時に満たすことは不可能であると述べています。

65 ブラザー: 一貫性、可用性、パーティション耐性とは何ですか?

一貫性

一貫性とは、どのノードに接続されているかに関係なく、すべてのクライアントが同時に同じデータを表示することを意味します。これを実現するには、データが 1 つのノードに書き込まれるたびに、書き込みが「成功」と見なされる前に、そのデータがシステム内の他のすべてのノードにすぐに転送または複製される必要があります。

可用性

どのクライアント要求でも、応答エラーなしで応答データを取得できます。言い換えれば、可用性とは、分散システムの観点からシステムにアクセスする顧客に対する別の種類のコミットメントです。つまり、データは確実に返し、エラーは返しませんが、データが最新であることを保証することはできません。私が強調したいのは、間違いがないということです。

パーティションフォールトトレランス

パーティションとは、分散システムにおける通信の中断、つまり 2 つのノード間の接続が失われたり一時的に遅延したりすることです。パーティション耐性とは、システム内のノード間の通信障害が発生してもクラスターが動作し続ける必要があることを意味します。

これら 3 つの特性をペアで組み合わせると、次の 3 つの状況が考えられます。

• CA: 2PC（2フェーズコミットプロトコル、第1フェーズで投票、第2フェーズでトランザクションの送信）などの完全に厳格な仲裁プロトコル
• CP: PaxosやRaftなどの不完全（多数決）仲裁プロトコル
• AP: DynamoやGossipなどの競合解決プロトコルを使用する

CA と CP の両方のシステム設計は、強力な一貫性理論に従います。違いは、CA システムはノード障害を許容できないことです。 CP システムは、2f+1 個のノードのうち f 個のノードの障害を許容できます。

基本理論

CAP 理論によれば、分散システムでは、一貫性、可用性、分断耐性の 3 つの条件を同時に満たすことは不可能であり、最大でも 2 つしか満たすことができません。

分散環境では、ネットワーク自体が 100% 信頼できるわけではなく、障害が発生する可能性があるため、パーティショニングは避けられない現象であり、P (パーティション許容度) 係数を選択する必要があることがわかります。言い換えれば、パーティション耐性は分散システムの基本要件です。

CAP 定理では、3 つすべてを同時に満たすことは制限されていますが、BASE 定理である C、A、P を満たすようにすることはできます。

BASE 理論は、「Basically Available (基本的に利用可能)」、「Soft State (ソフト ステート)」、「Eventually Consistent (最終的に一貫性がある)」という 3 つのフレーズの略語です。強力な一貫性を実現できない場合でも、各アプリケーションは独自のビジネス特性に基づいて、システムが最終的な一貫性を実現できるように適切な方法を採用できます。

基本的に利用可能

基本的な可用性とは、分散システムに障害が発生した場合に、ある程度の可用性が失われることが許容され、つまりコアの可用性が確保されることを意味します。

電子商取引のプロモーション中、トラフィックの急増に対処するために、一部のユーザーはダウングレードされたページに誘導され、サービス層はダウングレードされたサービスのみを提供する場合があります。これは、部分的な可用性の喪失の現れです。

ソフトステート

ソフトステートとは何ですか?アトミック性と比較すると、複数のノードのデータのコピーが一貫していることが必要となり、これは「ハード状態」となります。

ソフト状態とは、システム内のデータが中間状態で存在することを許可し、その状態がシステム全体の可用性に影響を与えないと想定することを意味します。つまり、システムが複数の異なるノード上のデータ コピーでデータ遅延を持つことを許可することを意味します。

最終的な一貫性

最終的な一貫性とは、システム内のすべてのデータ コピーが、一定期間後に最終的に一貫した状態に到達することを意味します。

弱い一貫性は強い一貫性の反対であり、結果的一貫性は弱い一貫性の特殊なケースです。

BASE 理論は、大規模で可用性が高く、スケーラブルな分散システムを目的としています。従来の ACID 特性に反し、ACID の強力な一貫性モデルとは異なり、BASE は強力な一貫性を犠牲にして可用性を獲得することを提案し、一定期間データの不整合を許容しますが、最終的には一貫した状態に到達します。

配布はシステム拡張の必然的な方向です。分散システムで発生する問題はよくあるものです。数多くの優れたプロジェクトが流通の道を歩んできたため、先人たちは豊富な理論を数多くまとめてきました。さらに、さまざまな分野で分散システムが次々と登場しています。私たちは、これらの優れた理論的知識をよく学ぶだけでなく、さまざまな分散システムの実装をさらに詳しく調べ、それらの共通点を要約し、さまざまな分野における独自のハイライトとトレードオフを発見する必要があります。さらに重要なのは、学んだことを日常のプロジェクトの実践に適用し、実践の中でより一般的な理論を要約することです。

この記事はWeChatの公開アカウント「MaGeByte」から転載したもので、以下のQRコードからフォローできます。この記事を転載する場合は、Code Byte の公開アカウントにご連絡ください。