分散システムのアーキテクチャについて話しましょう

今日は、Xiaojiao が分散システムのアーキテクチャ ルーチンについてお話します。ルーチンについて話す前に、まず「なぜ分散アーキテクチャが必要なのか」という質問について考えてみましょう。

ほとんどの開発者とほとんどのシステムは分散システムに触れたことがなく、分散システム アーキテクチャを開発する必要はありません。なぜ？訪問回数または QPS が単一マシンのパフォーマンスボトルネックに達しない場合は、分散アーキテクチャは必要ありません。では、業務量が増えた場合、通常はどのように解決するのでしょうか?

[[218074]]

最初に検討すべきことは、マシンのアップグレードです。マシン構成を垂直に拡張するには、まず、CPU、メモリ、ハードディスク、帯域幅など、現在のパフォーマンスのボトルネックを見つける必要があります。 CPU を追加するためにお金をかけること、SSD ハードドライブを交換するためにお金をかけること、1T のメモリを交換するためにお金をかけること、これが通常、問題を解決する最も直接的で効果的な方法です。帯域幅が足りませんか?帯域幅を増やします。1G では不十分なので、100G を使用してください。 CPU 8コアでは足りませんか? 32コアまたは96コアを取得します。これはほとんどの企業が最初に思いつく解決策です。これは、すぐに結果が得られる最も速くて安全な方法でもあります。

2 番目のステップは、システムを分割することです。提供するサービスの主処理と分岐処理を整理し、処理に応じてシステムを分割します。木と同じように、コアビジネスがメインプロセスとして機能し、他のシステムは木の枝や葉のように必要に応じて分割されます。分割方法はいくつかあり、フロントエンドとバックエンドで分割したり、フィールドで分割したり、チームで分割したりすることができます。もちろん、一般的に言えば、これらの分割は基本的に組織構造に従います。

それでも問題が解決しない場合は、テクノロジーをアップグレードし、より効率的なテクノロジーやシナリオに適したテクノロジーに置き換えます。たとえば、Oracle から HBase への切り替えなどです。データベース接続プール A からデータベース接続プール B に切り替えます。技術的な変化により、ビジネス ボリュームのサポートも大幅に強化されました。同じマシンに異なるテクノロジを使用すると、パフォーマンスのレベルが大きく異なる可能性があります。

最終的な手段が考慮された場合にのみ、分散アーキテクチャが考慮されます。本当にそんなにお金をかける余裕がないのであれば、他に方法はありません。分散アーキテクチャでは、一貫性に関する問題が確実に多く発生するからです。元々は 1 台のマシンにアクセスするだけで済みましたが、現在は N 台のマシンにアクセスする必要があります。では、これらの N 台のマシンの一貫性をどのように確保するのでしょうか?以前は、マスター スレーブ バックアップを用意し、データを定期的に同期するのが最善の方法でした。ここで、N 台のデバイスのデータをどのように管理するか、さらにはクラスター自体をどのように管理するかが致命的な問題になります。

したがって、業務量が一定レベルに達し、1 台のマシンでは対応できなくなった場合にのみ、マシンのアップグレード、システムの分割、テクノロジーの変更に費用を費やし、マシンのアップグレード、システムの分割に引き続き費用を費やし、コストが高すぎることが判明するか、テクノロジーがオンライン化できるレベルに達するまで、このサイクルを何度も繰り返します。 ***分散アーキテクチャを選択する以外に選択肢はありません。

ただし、分散アーキテクチャの利点も明らかです。低コストのデバイスのグループを使用することで、高性能、高スループット、安定したシステムを実現できます。一般的な分散クラスター アーキテクチャについて説明します。

1. 純粋な負荷分散形式。

クラスターの前には、トラフィックを分散するためのトラフィック分散コンポーネントが配置されます。クラスター全体のマシンは同等のサービスを提供します。これは一般的な Web サーバーで最も一般的な方法です。現在主流のアプローチは、マシンのクラスター全体をクラウドに移動し、リアルタイムの通話量に基づいてクラウド サーバーを弾力的に拡張することです。一般的な負荷分散には、ハードウェア レベルでの F5 とソフトウェア レベルでの nginx が含まれます。

2. リーダー選挙

クラスター全体のすべてのメッセージは、マスター スレーブの一種であるクラスターのリーダーに転送されます。唯一の違いは、このマスターは一時的に選出されるという点です。マスターがダウンすると、クラスターはすぐに新しいリーダーを選出し、外部へのサービスの提供を継続します。リーダー選出アーキテクチャを使用する一般的なアプリケーションには、ElasticSearch や Zookeeper などがあります。

3. ブロックチェーン

クラスター全体のすべてのノードは記録できますが、記録されたコンテンツが有効であるためには、クラスター全体の N 台のマシンによって認識される必要があります。代表的なアプリケーションとしては、Bit Coin や Hyperledger などがあります。

4. 主従型

クラスター全体は、クラスターをスケジュールするマスターを中心に構成されます。やりとりは次のようになります。通常、すべての管理データはマスターに配置され、特定のデータはスレーブに配置されます。実際に呼び出す際には、クライアントはまずマスターを呼び出して、データが保存されているサーバーの情報を取得し、その後、独自にスレーブと対話します。代表的なシステムは Hadoop です。クラスター、HBase クラスター、Redis クラスターなど。

5. ルールベースの一貫性ハッシュ

このタイプのアーキテクチャは、通常、データベース シャーディングの設計に使用されます。ルールに従ってデータベースとテーブルを分割し、クエリを実行する前にルール エンジンを使用してデータベースとテーブルを確認してから、特定のアプリケーションにアクセスします。一貫性ハッシュを使用する理由は何ですか?実際には何でも使用できますが、このタイプのアプリケーションでは一貫性のあるハッシュがより一般的です。

さて、これまで、私が知っている分散クラスタールーチンのほとんどについて説明してきました。要約します。

1. マシン構成をアップグレードするのが、最も直接的なアップグレード方法です。分散コンピューティングは絶対に必要な場合を除いて使用されません

2. 配信の核となるのは、事業分割とトラフィック分散です。

【この記事は51CTOコラムニスト「Da Jiao」によるオリジナル記事です。転載する場合は著者のWeChat公開アカウント「A Programmer Named Da Jiao」を通じて許可を得てください。

この著者の他の記事を読むにはここをクリックしてください