分散アーキテクチャの基本的な考え方の要約

インターネットの普及に伴い、さまざまな分散システムが一般的になりました。検索エンジン、電子商取引ウェブサイト、Weibo、WeChat、O2O プラットフォーム。 。大規模なユーザーと高い同時アクセスを伴うものはすべて分散されます。

分散システムに関しては、特定のアーキテクチャが間違いなく最良であることを示す標準的な答えはありません。ビジネス形態が異なれば、直面する課題も、使用するアーキテクチャ設計も異なるため、通常は特定のビジネス分析が必要になります。

しかし、どのようなビジネスであっても、どのような分散システムであっても、いくつかの基本的な考え方は同じです。この記事では、これらの基本的な考え方を整理して要約します。

[[230402]]

スピンオフ

システム分割

WeChatの設計者はかつてこう言いました。「大きなシステムを小さな方法で構築する」大規模で複雑なシステムに直面したとき、最初に思い浮かぶのは、それを複数のサブシステムに分割することです。各サブシステムには独自のストレージ/サービス/インターフェース層があり、各サブシステムは独立して開発、テスト、展開、保守されます。

チーム管理の観点から見ると、各チームが使い慣れた言語システムを使用でき、明確な責任を持ち、それぞれが独自の職務を遂行するインターフェースに基づいてチームが連携できます。

サブシステムの分離

サブシステムに分割された後、サブシステムはさらにレイヤーとモジュールに分割できます。もちろん、ここでの「システム」、「サブシステム」、「レイヤー」、「モジュール」は、相対的な概念にすぎません。システムでは、モジュールがある程度複雑になると、それを抽出して別のシステムにします。初期段階では、大規模で単純なモジュールは分割されず、 1 つのシステムに集中される可能性があります。

それは、常に成長し、進化し、分裂し、結合し、変化し、発展する生物組織のようなものです。

ストレージ分割

Nosql: MongoDB などの Nosql データベースは本質的に分散されており、データ シャーディングを簡単に実装できます。

Mysql: Mysql またはその他のリレーショナル データベースの場合、設計には個別のライブラリとテーブルが含まれます。データベースとテーブルのシャーディングには、シャーディング ディメンション、結合処理、分散トランザクションなど、いくつかの重要な問題が関係します。

計算分割

計算を分割する方法は 2 つあります。

データ分割: 大きなデータ セットを複数の小さなデータ セットに分割し、それらを並列に計算します。

例えば、大規模なデータのマージソート

タスクの分割: 長いタスクを複数の部分に分割し、各部分を並行して計算します。

Java のマルチスレッド Fork/Join フレームワークと Hadoop の Map/Reduce フレームワークは、どちらも分割を計算するための典型的なフレームワークです。考え方は似ており、最初に計算を分割し、次に結果を結合します。

たとえば、分散検索エンジンでは、データが分割され、インデックスが個別に作成され、クエリ結果がマージされます。

同時

最も一般的なのはマルチスレッドであり、これによりプログラムの同時実行性が最大限に高まります。

たとえば、複数の連続した RPC 呼び出しは、非同期 RPC を通じて同時呼び出しに変換できます。

たとえば、テーブル全体をスキャンして数時間実行する必要があるジョブがある場合、データ シャーディングとマルチスレッドを使用するとパフォーマンスが数倍高速化されます。

キャッシュ

キャッシュは誰もがよく知っています。パフォーマンスの問題が発生した場合、最初に思い浮かぶのはキャッシュです。キャッシュに関して重要なポイントは、キャッシュの粒度です。

たとえば、Tweet のアーキテクチャでは、キャッシュの粒度は、行キャッシュ、ベクター キャッシュ、フラグメント キャッシュ、ページ キャッシュなど、小さいものから大きいものへと増加します。

粒度が小さいほど再利用性は向上しますが、クエリを複数回繰り返す必要があり、データの組み立てが必要になります。

粒度が大きくなるほど、失敗しやすくなります。少しでも変更するとキャッシュが失敗する可能性があります。

オンライン コンピューティングとオフライン コンピューティング / 同期コンピューティングと非同期コンピューティング

実際のビジネス ニーズでは、すべてのニーズが完全にリアルタイムである必要はありません。

たとえば、製品や業務向けに社内で開発されたさまざまなレポート照会および分析システムなど。

たとえば、私がWeiboに投稿すると、ファンは数秒後にそれを見るかもしれません。遅延に気付かないので、これは許容範囲です。

たとえば、検索エンジンのインデックス作成: ブログ記事を投稿した後、検索エンジンがそれをインデックスするまでに数分かかることがあります。

例えば、Alipay を通じて送金や引き出しを行う場合、送金後すぐに相手にお金が届くわけではありません。

。 。 。

そういった例はたくさんあります。この「非リアルタイムも許容される」シナリオは、アーキテクチャの設計において十分な操作の余地を提供します。

リアルタイムではないため、メッセージ キューを使用したり、バックグラウンド ジョブを使用して特定のタスクを定期的に処理したりするなど、非同期で実行できます。

また、リアルタイムではないため、読み取りと書き込みの分離が可能であり、MySQL のマスター スレーブのように読み取りと書き込みが完全に同期されるわけではありません。

全額＋増額

フル/増分は、実際にはオンライン/オフラインの考え方です。

たとえば、検索エンジンのフルインデックス + 増分インデックスの場合、前者はスループット用、後者はリアルタイム用です。

たとえば、OceanBase データベースでは、各更新は小さなテーブルに保存され、定期的にマージされます。

押す vs. 引く

すべての分散システムには、ノード間 (または 2 つのサブシステム間) のステータス通知という基本的な問題が存在します。たとえば、ノードのステータスが変更された場合、別のノードに通知する方法は 2 つあります。

プッシュ: ノードAの状態が変化したら、ノードBにプッシュします。

プル: つまり、ポーリングです。ノード B は定期的にノード A のステータスを照会します。

この問題は分散システムでのみ発生するものではなく、コードを書く上での基本的な問題であると言えます。オブジェクト指向プログラミングに対応して、これは「双方向関連」と呼ばれることが多い結合問題です。

A が B に電話をかけ、B が A に電話をかけ返します。このような状況は、システム開発でよく発生します。さらに複雑なことに、複数のモジュールが互いに呼び出し合うため、呼び出し関係は蜘蛛の巣のようになります。

この問題の発生は、プッシュ/プル戦略と密接に関係しています。

A が B を呼び出す場合、ロジックは B 側に記述されます。 B が A を呼び出す場合、ロジックは A 側に記述されます。したがって、アクティブ コール プル方式を採用するか、コールバック プッシュ方式を採用するかは、さまざまなモジュールまたはサブシステムにおける責任の分散に重大な影響を及ぼします。

バッチ

バッチは実際にはオンライン/オフラインの考え方であり、リアルタイムの問題をバッチ処理の問題に変換し、システム スループットへの負荷を軽減します。

たとえば、Kafka でのバッチ メッセージングなど。

例えば、広告料控除制度では、複数のクリックが累積されて控除されます。

。 。

軽く書き直して読む vs. 軽く読み直して書く

書き直しと軽い読書は本質的に「スペースを時間に変えること」です。計算に時間がかかり、待ち時間も長いのではないでしょうか?そうすれば、事前に計算して保存することができます。手に入れたら、直接取りに行きましょう。

通常、MySQL は書き込みよりも読み取りに重点を置いて使用します。書くときは簡単です。検索時には、複雑な結合計算が実行されて結果が返されます。これを実行する利点は、強力なデータ一貫性を簡単に実現でき、フィールドの冗長性によるデータの不整合が発生しないことです。しかし、パフォーマンスが問題になるかもしれません。

Weibo のフィード構造は、書き込みが多く、読みやすいという典型的な例です。フィードを確認したいです。通常の MySQL の慣例に従うと、最初にフォローしているすべてのユーザーをチェックし、すべてのメッセージを並べ替えてページで返す必要があります。当然ながら、大量のデータの場合、これには時間がかかります。

しかし、書き直しと軽い読み上げというアプローチを採用する場合、どのようにすればよいのでしょうか?フィードを読みたい場合は、全員用のフィードまたは受信トレイを準備します。誰かがWeiboに投稿すると、その人のWeiboが全員の受信トレイに拡散されます。この拡散は非同期で、バックグラウンドで発生します。こうすることで、誰もがフィードを見るときに、受信トレイに移動してフィードを取得できるようになります。

読み取りと書き込みの分離

同様に、従来のスタンドアロン MySQL データベースでは、読み取りと書き込みは完全に同期されます。書かれた内容はすぐに読むことができます。

しかし、多くのビジネス シナリオでは、読み取りと書き込みを完全に同期する必要はありません。このとき、別々に保存し、ある場所に書き込んでから、別の場所に非同期で同期することができます。これにより、読み取りと書き込みの分離が可能になります。

たとえば、MySQL のマスター/スレーブ モデルが典型的な例です。スレーブ上のデータはマスターとリアルタイムで同期されません。

別の例としては、さまざまなレポート分析、OLTP/OLAP、オンライン/オフライン データの分離、分析用の Hive クラスターへのオンライン データの定期的な同期などがあります。

静的と動的の分離

動的と静的の分離の典型的な例は、Web サイトのフロントエンドです。動的ページは Web サーバー上に配置され、静的 css/jss/img は CDN 上に直接配置されます。これにより、パフォーマンスが向上するだけでなく、サーバーの負荷も大幅に軽減されます。

この考えに従って、多くの大規模な Web サイトでは、動的なコンテンツを静的にし、簡単にキャッシュできるようにすることに取り組んでいます。

熱と冷の分離

たとえば、MySQLの履歴データをHiveに定期的に同期する

電流制限

最近、多くの電子商取引企業がフラッシュセールを行っています。フラッシュセールの特徴として、商品の数が非常に少ないにも関わらず、短期間でトラフィックが急増し、サーバーが大量のリクエストにまったく対応できなくなることが挙げられます。

この種の問題に対処するための基本的な考え方は、フローを制限することです。たくさんのリクエストには対応できませんし、たくさんの人が来ても席を確保できないでしょう。だったら、そんなに多くの人を中に入れないでください。

これは私たちの日常生活でも同じで、休日になると特定の観光地に人が集まりすぎて人の流れが制限されてしまいます。

サービス回路ブレーカーと劣化

サービスの低下はシステムの最後の防衛線です。複雑なシステム内では、システムが他の大規模なシステムのサービスを呼び出すことがよくあります。アクセスが集中した場合、メインプロセスが正常に動作することを保証しながら、他のサービスをダウングレードすることがあります。

いわゆるダウングレードとは、サービスが利用できない場合に、サービスを提供することが許可されず、デフォルトの結果が直接返されることを意味します。このサービスは利用できなくなりますが、メインプロセス全体が麻痺することはないため、コアシステムの可用性を最大限に確保できます。

CAP理論

上で述べたさまざまなアイデアは、CAP という大きなアイデアにまとめることができます。

一貫性: データの一貫性。これは簡単に理解できます。つまり、ダーティデータは存在しないということです。 MySQL には、参照整合性制約やトランザクションなどの一貫性の概念があることはわかっています。しかし、ここでの C は主に、同じデータの複数のバックアップ間の一貫性を指します。

可用性: 可用性には 2 つの意味があります。 1 つは安定性、つまりサービスが利用可能であり、クラッシュしないことです。もう 1 つはパフォーマンス、つまり高速でなければなりません。レイテンシが非常に高く、タイムアウトが頻繁に発生する場合は、クラッシュと変わりません。

パーティション許容度: パーティションは実際にはネットワーク パーティションを指します。 1 つの物理デバイスから複数の物理デバイスにデータを分割する場合、デバイスはネットワークを介して通信する必要があります。これにより、典型的な「2 人の将軍の問題」であるネットワーク分割が発生し、ネットワークのタイムアウト期間が不確実になります。学術の世界には「非同期通信環境」という用語があります。

CAP 理論については前にも触れましたが、分散システムでは、上記の 3 つのうち 2 つだけが同時に満たされると言われています。しかし、これは実際には正確ではありません。 P は必ず存在し、それを避けることはできません。私たちにできることは、主に C と A のバランスを取ることです。

たとえば、MySQL の場合、C が最も強力、A が 2 番目、P が最も弱いです。書き換えや軽い読み取りなど、A のデータを冗長化した場合、C を保証することは困難です。 P のデータを異なるデータベースとテーブルに分割すると、トランザクションを実行できなくなります。

たとえば、Nosql には最も強力な P があり、データ分割を非常にうまく行うことができますが、C は十分ではなく、トランザクションを実行できません。

たとえば、マイクロブログ システムでは、C の要件が削減されると、大量のキャッシュを追加して A を改善できます。データシャーディングにより P を改善できます。

ただし、支払いとトランザクションの転送には C に対する要件が非常に高いため、パフォーマンスを向上させるためだけにキャッシュを使用することはできません。

[[230403]]

ここで皆さんに建築学習・交流グループをおすすめします。コミュニケーションと学習グループ番号: 190713474 元のリンクをクリックしてグループに参加すると、上級アーキテクトが録画したビデオ録画がいくつか共有されます: Spring、MyBatis、Netty ソースコード分析、高並行性、高パフォーマンス、分散、マイクロサービス アーキテクチャ、JVM パフォーマンスの最適化、分散アーキテクチャなど。これらは、アーキテクトにとって必要な知識体系になっています。無料の学習リソースも受け取ることができ、現在多くのメリットがあります

最終的な一貫性

前述したように、分散システムでは、データとサービスが分離されているため、強力な一貫性を確保することが困難です。現時点で最も一般的に使用されている概念は「結果整合性」です。

強い一貫性、弱い一貫性、最終的な一貫性は、一貫性の異なるレベルです。従来のリレーショナル データベースでは、トランザクションを通じて強力な一貫性が保証されます。

ただし、分散システムでは、通常、強力な一貫性は最終的な一貫性に妥協され、分散トランザクションの問題が隠された形で解決されます。

送金の典型的な例としては、A が B に 10,000 元を送金する場合です。A の口座から 10,000 元が差し引かれ、B の口座に 10,000 元が追加されます。しかし、これら 2 つのステップは必ずしも同時に実行する必要はありません。 A が差し引いた金額は、B の口座にすぐに振り込まれるわけではありませんが、最終的に B が受け取れるのであれば十分です。

最終的な一貫性の実装には通常、信頼性の高いメッセージ キューが必要です。これについてはインターネット上にさまざまな共有記事があり、この問題については後で別途詳しく説明する予定です。