序文
長年にわたるコーディングと設計の経験により、著者は基本的なコーディング、クラウド コンピューティング プラットフォーム、アーキテクトを行い、多くのアプリケーション設計、システム設計、ミドルウェアを見てきました。また、既存のテクノロジー システム開発モデル、集中型 -> 分散型の方式、キャップと分散を理解しています。基本的な理論では、基本的にユーザビリティはほとんどの場合、設計に必要な目標であるため、分散状況でユーザビリティを実現する方法は、答えはコピーです。つまり、理論的には、より多くのリソースをデプロイすることです。ただし、すべての状態がステートレスであるわけではないため、トレードオフは避けられません。
共通のデザイン
一般的に使用されるさまざまなテクノロジにはレプリカの概念があります。マルチコア CPU などのステートレス レプリカの場合、各コアは独立して実行され、タイムスライス スレッドを実行できますが、キャッシュの一貫性の問題は依然として存在します (MESI プロトコル)。同様に、分散環境においてもステートレスなサービスであれば、より多くのリソースを配置するほど一貫性を考慮する必要がないため可用性が高くなり、CAP理論によればAPで実現可能となります。しかし、実際の状況では、データベース トランザクションやセッションなど、一貫性が必要になることがよくあります。
実際には、クラウド コンピューティングにはリージョンと可用性ゾーンの概念があり、実際には複数のデータ センターであるため、高可用性アーキテクチャはステートフルになります。一般的な設計には、アクティブとスタンバイ、レプリカ セット、断片化されたクラスター、および接続されたクラスターが含まれます。
アクティブ/スタンバイ+アービトレーション
アクティブ/スタンバイ設計は、多くのシナリオ (通常は MySQL MHA と Redis Sentinel) で使用されます。MySQL を例に挙げると、自動フェイルオーバーが必要な場合は、MHA などの調停ノードのサポートが必要です。
実はRedisのセンチネルモードも同様で、マスターとバックアップは別のデータセンターに配置されています。もちろん遅延は小さければ小さいほど良いのですが、データセンター間での遅延設計が必要になります。データを作成することで最適化することができます。中心が十分に近いか、転送するデータが少なくなります。
ここで、MHA サーバーはフェイルオーバーと自動マスタースタンバイ切り替えを担当する調停ノードですが、ハートビート検出によると、実際には mongodb コピーも 1+2 モードを使用でき、原理は同じです。
同様に、マスター/スレーブ レプリケーションにより、スタンバイ ノードは書き込みを提供できず、マスター ノードからコピーする必要があるため (完全同期、準同期、非同期)、スタンバイ ノードが多すぎないようにします。マスターノードの書き込みが多すぎて拡張できない場合があります。
レプリカ セット (拡張クラスター)
レプリカ セットは通常、アービトレーションを使用しません。これは実際には同じ考え方ですが、奇数のノードが相互にアービトレーションする必要があります。実際には偶数のノードも可能ですが、スプリット ブレインまたは困難な現象が発生します。仲裁。このアイデアは paxos アルゴリズムに基づいていますが、paxos アルゴリズムは複雑すぎるため、zab アルゴリズムと raft アルゴリズムが簡略化されているようです。Zookeeper は ZAB 自律選出アルゴリズムに基づいており、MongoDB レプリカ セットは Raft アルゴリズムに基づいており、Tencent は MongoDB を模倣し、MySQL を使用して tdsql を実装しています。
ノードはペアで接続され、相互に投票を開始します。投票方法は、必ずマスターとして表示されるノードの設計 (奇数、ID など) に従って設計されます。投票の設計により、ノードの数が増えるほど、投票方法が設計されます。つまり、選挙が難しくなればなるほど、多ければ多いほど良いということであり、5 や 7 などのバランス ポイントがあります。
この図に見覚えがあるでしょうか? 実際、Redis クラスターと rocketmq クラスターはフェイルオーバーにこの方法を使用しますが、従来のレプリカ セットとは異なり、フラグメンテーション + raft アルゴリズムを使用します。
次に、クロスデータセンター HA を設計する場合、2 つの場所と 3 つのセンターが必要になりますが、データセンターにノードを展開することで、データセンターがダウンしてもサービスを利用できるようになります。
シャード化されたクラスター
シャード クラスターを設計するには、シャード シャードをレプリカ セットとして使用する方法と、シャード シャードをアクティブおよびスタンバイとして使用する方法の 2 つがあります。
シャード化されたクラスター
フラグメント化された部分がレプリカ セットである場合、レプリカ セットはフェイルオーバー機能を提供します。一般的なものは、mongodb フラグメント化クラスター、mongos ルーティング + configserver (レプリカ セット) + フラグメンテーションであり、各フラグメントは raft レプリカ セット (replicaSet) です。実際、K8S は展開計画を作成し、RS (replicaSet) も作成します。
たとえば、2 つのシャードを持つシャード クラスターでは、各シャードがレプリカ セットであるため、各シャードのレプリカ セット ノードがデータ センターにまたがって 2 つの場所と 3 つのセンターを実現できます。理論的には、シャーディングは無限に拡張できますが、拡張が増加するにつれて、ルーティング クエリの作成のプレッシャーが増大します。このアーキテクチャ設計が、mongodb または ES (シャーディングも) が大量のデータを保存できる理由です。たとえば、60 億の「ウォッチ」 」。
フラグメンテーション + マスター/スタンバイ
一般的なものは、Redis クラスター、rocketmq クラスター、ES クラスターなどです。Redis を例に挙げます。
Redisのシャーディングもデータのシャーディングですが、RedisのプライマリとバックアップのフェイルオーバーはRedisマスターノードの投票によって決定されるため、マルチデータセンター設計ではデータセンターが2つあると対応できませんが、したがって、Redis は通常、3 マスター 3 スレーブ、5 マスター 5 スレーブなどになります。2 つのデータ センターに奇数のノードが表示され、ノード数が多いデータ センターで障害が発生し、クラスター全体が使用できなくなり、2 つのデータ センターと 3 つのデータ センターのサポートが必要になります。
クラスターを接続する
名前が示すように、クラスターを接続します。データの整合性を確保するために、2 つ以上のクラスターのデータを相互にコピーします。
複数の接続
rocketmq を例に挙げると、中間レプリケーション プラットフォームを使用して、2 つのデータ センターの rocketmq クラスターを相互にレプリケートします。
ここでは半分だけ描画されており、右側も左側にコピーされます
SDK ルーティング分散により、アクティブ/アクティブ クラスタが実現され、データは完全に同期されます。データ センターの 1 つがダウンしても、ビジネスにはまったく影響しません。デメリットも明らかで、帯域幅の使用量が非常に高くなります。データセンターの遅延が大きい場合、または帯域幅が十分でない場合、この方法は機能しません。
アプリケーションの設計では、MQ 消費の冪等重複排除など、複数の消費を避けることも考慮する必要があります。送信はデータ領域のマークに従って片側で送信できますが、もちろん、消費もデータ領域のマークに従って処理できます。実際の状況は、真のデュアルライブ設計です。データセンター障害発生時には送信マークと消費マークを切り替え、シームレスなサービス移行を実現し、さらには監視データに基づく自動切り替えも実現します。
クラスターに接続されているため、書き込まれたデータの ID (一意性) の競合を保存時に考慮する必要があり、データを書き込み用にマークすることをお勧めします。
データストア ファイルのコピー
上記の設計は、MySQL binlog、Kafka のコミット ログ インデックス ログなどのミドルウェア機能を使用するなど、さらに最適化できます。ファイルまたはデータ ストリームのレプリケーションは、ミドルウェア自体のプロパティを通じて実現されます。
違いを認識するだけで、本質は同じです。
大規模なクラスターの断片化 - データ損失は許容されます
データ要件が高くなく、データのキャッシュなど、損失が許容される場合は、断片化された大規模クラスター モードを使用できます。
データは完全に断片化されており、データ ソースは定期的に同期して Redis に書き込むことができます。1 つのデータ センターがダウンしたために Redis クラスターがハングした場合、データは失われ書き込み待ちになりますが、ビジネスには影響しません。 SDK ルーティングの設計方法については、特定の状況に応じて、ルーティング ルールが適用されます。登録センターのようなローカルキャッシュがあり定期的にハートビートをチェックしていればコピーせずに自動で登録されます
データはコピーされませんが、断片化されたクラスターです。データ センターの 1 つがダウンした場合、SDK はもう一方のデータ センターに自動的に登録され、各 SDK にはローカル キャッシュがあり、スイッチング不要のコストを実現します。データセンター全体がダウンし、アプリケーションも問題なくハングします。
もちろん、データセンター間の自動登録を実装せず、APP が提供する機能の一部を失い、回復後にアプリケーションが自動的に機能を復元することも可能です。
要約する
著者は、クロスデータセンターの実践とスキームについて簡単に紹介しただけですが、実際には、設計はより複雑で、特にさまざまなステータス、レプリケーションの安定性、帯域幅、その他の総合的な考慮事項を考慮すると、さまざまな実際的な問題は非常に困難です。シンプルな SDK には、ルーティング重複排除などの複数の設計が含まれます。実際のシーンに合わせて設計する必要があります。
開発ロジックのプラットフォームへの移行
近年はdockerなどのコンテナの台頭により開発ロジックがプラットフォームに傾き、以前はFATJarモードでの開発がエージェント、サイドカー、サーバーレスとなる固定フレームとなっています。 、品質と効率を確保するためにフレーム内で作業します。開発者にとって、システムの実装ロジックに触れるのは難しいです。