メッセージキューの高可用性を確保するにはどうすればよいですか?

メッセージ キューは、同時実行性の高いシナリオでは不可欠なスキルです。私たちの使用では、実稼働環境では次のような多くの問題が発生します。メッセージ キューの高可用性を実現するにはどうすればよいですか?

シナリオには多くの種類のミドルウェアがありますが、ここでは分析や処理によく使われるミドルウェアをいくつか用意します。

1. RabbitMQ の高可用性

RabbitMQ はマスター/スレーブ (非分散) 高可用性に基づいているため、比較的代表的なものであるため、RabbitMQ を使用します。最初の MQ の高可用性を実装する方法を説明する例。

RabbitMQ には、スタンドアロン モード、通常クラスタ モード、ミラー クラスタ モードの 3 つのモードがあります。

シングルプレイヤー モード

スタンドアロン モードはデモ レベルです。通常は楽しみのためにローカルで起動します。本番環境でスタンドアロン モードを使用する人はいません。

通常のクラスター モード (高可用性なし)

通常のクラスター モードとは、複数のマシン上で複数の RabbitMQ インスタンスを各マシンに 1 つずつ起動することを意味します。作成したキューは 1 つの RabbitMQ インスタンスにのみ配置されますが、各インスタンスはキューのメタデータを同期します (メタデータはキューの構成情報と考えることができます。メタデータを通じて、キューが配置されているインスタンスを見つけることができます)。 。

消費するときに、実際に別のインスタンスに接続している場合、そのインスタンスはキューが配置されているインスタンスからデータをプルします。

この方法は非常に面倒かつあまり良い方法ではなく、いわゆる分散には至らず、ただのクラスタです。これは、コンシューマが毎回ランダムにインスタンスに接続してデータを取得するか、コンシューマがキューが配置されているインスタンスに固定的に接続してデータを消費することになるためです。前者にはデータの取得のオーバーヘッドがあり、後者にはデータの取得に伴うオーバーヘッドが発生します。単一インスタンスのパフォーマンスのボトルネック。

そして、キューを保持しているインスタンスがダウンすると、他のインスタンスはそのインスタンスからプルできなくなります。メッセージの永続性を有効にして RabbitMQ にメッセージを保存させる場合、メッセージは必ずしも失われるわけではありません。このキューからデータをプルし続ける前に、このインスタンスが回復するまで待機します。

したがって、この問題はさらに厄介です。いわゆる高可用性はありません。この解決策は主にスループットを向上させること、つまり、クラスター内の複数のノードが特定のノードの読み取りおよび書き込み操作を実行できるようにすることです。列。 。

ミラー クラスター モード (高可用性)

このモードは、RabbitMQ のいわゆる高可用性モードです。通常のクラスター モードと異なるのは、ミラー クラスター モードでは、キュー内のメタデータやメッセージに関係なく、作成したキューが複数のインスタンス上に存在することです。つまり、各 RabbitMQ ノードにはこのキューの完全なコピーが存在します。ミラーリングとは、キューのすべてのデータを含めることを意味します。その後、キューにメッセージを書き込むたびに、メッセージは複数のインスタンスのキューに自動的に同期されます。

では、このミラー クラスター モードを有効にするにはどうすればよいでしょうか?実際、これは非常に簡単です。RabbitMQ には、バックグラウンドでポリシーを追加する優れた管理コンソールがあります。このポリシーは、ミラー クラスター モード ポリシーです。指定すると、データをすべてのノードに同期するように要求したり、ノードがキューを再度作成するときに、この戦略を適用すると、データが他のノードに自動的に同期されます。

この場合、利点は、マシンのいずれかがダウンしても大丈夫ということです。他のマシン (ノード) にはこのキューの完全なデータがまだ含まれており、他のコンシューマは他のノードに移動して、データを消費します。

欠点は、まずパフォーマンスのオーバーヘッドが大きすぎることです。メッセージをすべてのマシンに同期する必要があるため、ネットワーク帯域幅の負荷が大きくなり、消費量が大きくなります。

第 2 に、これらのゲームは分散されておらず、スケーラビリティがありません。キューの負荷が高く、マシンを追加すると、新しいマシンにはキューのすべてのデータも含まれることになります。キューを直線的に拡張します。

2. Kafka の高可用性

Kafka の最も基本的なアーキテクチャの理解: Kafka は複数のブローカーで構成され、各ブローカーはノードであり、トピックを作成します。このトピックは複数のパーティションに分割でき、各パーティションは異なるブローカー上に存在でき、各パーティションはデータの一部を保存します。

これは自然な分散メッセージ キューです。つまり、トピックのデータが複数のマシンに分散されており、各マシンがデータの一部を格納します。

実際には、RabbmitMQ などは分散メッセージ キューではありません。これらは従来のメッセージ キューです。これらは、クラスタリングと HA (高可用性、高可用性) メカニズムを提供するだけです。 RabbitMQ のキューのデータは 1 つのノードに配置されますが、ミラー クラスターの下では、キューの完全なデータも各ノードに配置されます。

Kafka 0.8 より前には、HA メカニズムがありませんでした。ブローカーがダウンすると、そのブローカー上のパーティションは役に立たなくなり、書き込みも読み取りもできなくなります。高可用性はまったくありませんでした。

たとえば、トピックを作成し、パーティションの数が 3 で、それぞれが 3 台のマシン上にあると指定すると仮定します。ただし、2 台目のマシンがダウンすると、このトピックに関するデータの 1/3 が失われるため、可用性を高めることはできません。

Kafka 0.8 以降では、レプリカ メカニズムである HA メカニズムが提供されます。各パーティションのデータは他のマシンと同期され、独自の複数のレプリカが形成されます。すべてのレプリカはリーダーを選出し、生産と消費はこのリーダーに対処し、他のレプリカはフォロワーになります。書き込みの場合はリーダーがすべてのフォロワーにデータを同期する責任を負いますが、読み取りの場合はリーダー上のデータを直接読み取るだけです。リーダーしか読み書きできないのですか？

これは非常に簡単です。各フォロワーを自由に読み書きできる場合は、データの一貫性の問題に対処する必要があります。システムの複雑さが高すぎるため、問題が簡単に発生する可能性があります。 Kafka は、フォールト トレランスを向上させるために、パーティションのすべてのレプリカを異なるマシンに均等に分散します。

これを行うと、特定のブローカーがダウンしても大丈夫なので、いわゆる高可用性が実現します。そのブローカー上のパーティションには、他のマシン上にコピーがあります。ダウンしたブローカーに特定のパーティションのリーダーがいる場合、新しいリーダーがフォロワーの中から再選され、誰もが引き続き新しいリーダーの読み取りと書き込みを行うことができます。これを高可用性と呼びます。

データを書き込むときは、プロデューサーがリーダーに書き込み、リーダーがデータをローカル ディスクに書き込み、その後、他のフォロワーが主導権を持ってリーダーからデータを取得します。すべてのフォロワーがデータを同期したら、リーダーに ack を送信し、リーダーがすべてのフォロワーから ack を受信した後、正常に書き込まれたメッセージをプロデューサーに返します。 (もちろん、これはモードの 1 つにすぎず、この動作は適切に調整できます)

消費するときは、リーダーからのみ読み取られますが、メッセージがすべてのフォロワーによって同期されている場合に限られます。 ack. が正常に返された場合、このメッセージはコンシューマによって読み取られます。

関連する php の知識については、php チュートリアル をご覧ください。

以上がメッセージキューの高可用性を確保するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。