初心者向け科学: 分散とクラスター

1. 分散型

Xiao Ming の会社には、システム A、システム B、システム C の 3 つのシステムがあります。これら 3 つのシステムはそれぞれ異なる業務を実行し、3 台​​の独立したマシンに展開されています。彼らは互いに（もちろんネットワーク経由で）電話をかけ、協力して会社のビジネス プロセスを完了します。

さまざまなビジネスをさまざまな場所に分散させることで、分散型システムが構成されます。ここで問題が発生します。システム A は、分散システム全体の「顔」です。ユーザーが直接アクセスすると、速度が極端に遅くなったり、ユーザー数が多いとすぐにクラッシュしたりします。私たちは何をすべきでしょうか?

システム A のコピーは 1 つしかないため、単一障害点が発生します。

2. クラスター

シャオミンの会社は資金に困っていないので、さらに数台の機械を購入します。 Xiao Ming は、システム A のコピーを一度に複数展開します (下の図の 3 つのサーバーなど)。各コピーはシステム A のインスタンスであり、外部に同じサービスを提供します。こうすれば、残りの 2 つがまだあるので、どちらかが故障する心配をせずに安らかに眠ることができます。

これら 3 台のサーバー上のシステムはクラスターを形成します。

しかし、ユーザーにとっては、一度に多数のシステム A が存在し、各システムには異なる IP アドレスがあります。どれにアクセスすればいいですか?

全員がサーバー 1.1 にアクセスすると、サーバー 1.1 が使い果たされ、残りの 3 つはアイドル状態になり、お金の無駄になります。

3. ロードバランサー

Xiao Ming は、3 台のマシン上のシステム A の作業をできるだけバランスよくしたいと考えています。たとえば、リクエストが 30,000 件ある場合は、3 つのサーバーがそれぞれ 10,000 件のリクエストを処理するようにします (もちろん、これは理想的な状況です)。これを負荷分散と呼びます。

明らかに、この負荷分散作業は分離して別のサーバー (Ngnix など) に配置するのが最適です。

その後、シャオ ミンは、この負荷分散サーバーの役割はリクエストを受信して​​分散するという非常に単純なものであるにもかかわらず、クラッシュする可能性があり、単一点障害が発生する可能性があることを発見しました。

負荷分散をクラスタ化するしかありませんが、システムAのクラスタとは2つの点で異なります。

1. この新しいクラスターには 2 台のマシンがありますが、何らかの方法を使用して、このクラスターが外部に提供する IP アドレスを 1 つだけにすることができます。つまり、ユーザーには 1 台のマシンしかないように見えます。

2. 同時に、1 台の負荷分散マシンのみを稼働させ、もう 1 台はスタンバイ状態になります。動作中のものが故障した場合、待機中のものが引き継ぎます。

4. 回復力

システム A のこれら 3 つのインスタンスでも大量の要求を満たすことができない場合は、サーバーを追加してください。

ダブル11が近づいており、ユーザー数は通常の10倍です。シャオミンはリーダーに資金を申請し、数十台のサーバーを購入し、一度に数十台のシステムAのコピーを展開しました。しかし、ダブル 11 以降、トラフィックが急激に減少し、それらの数十台のサーバーは必要なくなり、単なる見せかけのものになりました。

上司から批判された後、シャオミンはクラウドコンピューティングを試してみることにしました。クラウド上で仮想サーバーを簡単に作成・削除できるため、ユーザーの要求に応じて動的にサーバーを増減できます。ダブル 11 が来たら仮想サーバーを作成し、ダブル 11 が終わったら使用していないサーバーをシャットダウンしてコストを節約します。

したがって、Xiao Ming のシステムにはある程度の柔軟性があります。

5. フェイルオーバー

上記のシステムは素晴らしいように見えますが、すべてのサービスがステートレスであるという非現実的な仮定に基づいています。つまり、ユーザーからの 2 つのリクエストは直接無関係であると想定されます。

しかし現実には、ショッピング カートなどのほとんどのサービスはステートフルです。

ユーザーがシステムにアクセスし、サーバー 1.1 上にショッピング カートを作成し、そこにいくつかのアイテムを追加します。その後、サーバー 1.1 がクラッシュします。ユーザーはその後のアクセスでサーバー 1.1 を見つけることができません。このとき、他のサーバーが引き継いでユーザーの要求を処理できるように、フェイルオーバーを実行する必要があります。

しかし、問題は、サーバー 1.2 または 1.3 にユーザーのショッピング カートがあるかどうかです。そうしないと、ユーザーは「私が作成したショッピング カートはどこにあるのですか?」と文句を言うでしょう。

さらに悪いことに、ユーザーがサーバー 1.1 にログインし、ユーザーのログイン情報がそのサーバーのセッションに保存されたとします。サーバーがダウンしたため、ユーザーのセッションは当然失われます。ユーザーが別のサーバーにフェイルオーバーされると、他のサーバーはユーザーがログインしていないことを検出し、ユーザーをログイン インターフェイスに切り替えて、再度ログインするように要求します。

ステータス、ステータス、ステータス！ユーザーのログイン情報、ショッピングカートなどはすべてステータス情報です。ステータスの問題が適切に処理されない場合、クラスターのパワーが大幅に低下し、真のフェイルオーバーを完了できなくなるか、使用できなくなる可能性があります。

何をするか？

1 つの方法は、クラスター内のサーバー間でステータス情報を複製し、クラスター内のサーバーが合意に達することができるようにすることです。誰がこれをやるのでしょうか?使用できるのは、Websphere や WebLogic などのアプリケーション サーバーのみです。

もう 1 つの方法は、ステータス情報を 1 か所に保存して、クラスター内のすべてのサーバーがアクセスできるようにすることです。

Xiao MingはRedisが良いと聞いたので、Redisを使って保存しましょう！

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

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