分散メッセージングシステムの設計ポイント

分散キャッシュに関しては、Redis がリードしています。しかし、メッセージ キュー MQ に関しては、まだ繁栄の時代にあります。

キャッシュ システムは基本的にアクセスの問題を解決し、すべてが正常になります。呼び出しは同期的に行われます。メッセージ キューの場合は、状況が少し異なります。使用シナリオは多様で信頼性レベルもさまざまであり、生成から消費までのプロセスは非同期です。

メッセージ システムには多くの設計ポイントがあります。現在では、以下に述べる設計上のポイントを考慮したメッセージング システムを構築することは困難です。もしそうなら、話しているのは母体です。

そのため、Kafka、RabbitMQ、RocketMQ などの多くの一般的なプラットフォームが同時に使用されることがよくあります。適切な選択を行う場合、次の技術的なポイントがトレードオフとなります。諺：明け方に鶏が鳴くのは、家族が困っていることを意味する。

要点

この記事では、これらの MQ に焦点を当て、全体的な観点からいくつかの共通機能を抽象化します。含まれるもの: プロトコル、タイプ、消費方法、スタッキング容量、高可用性、高信頼性、高性能、スケーラビリティ、エコロジー。 MQ についてさらに詳しく知りたい場合は、Kafka に関する記事もいくつかあります。

高可用性

高可用性は主に、異常な状況下でのクラスター内の単一ノードのフェイルオーバーと HA を解決します。高可用性の問題を解決するための一般的な考え方は、レプリケーション メカニズムです。

レプリカを追加することで、データのリスクを複数のマシンに分散できます。これには、プライマリ シャードで問題が発生した場合に、レプリカから新しいプライマリ シャードが見つかることが必要です。 zk など、そのような調整ツールは数多くあります。一部の MQ では、このプロセスを独自に実装することもあります。

RocketMQ などの一部のモードでは、スタンバイ スレーブを使用して高可用性を確保し、問題発生時に処理を引き継ぐため、リソースがより無駄になります。

高い信頼性

メッセージング システムの信頼性とパフォーマンスは互いに矛盾しています。一般的な MQ の場合、信頼性レベルは調整できますが、パフォーマンスは逆の連動になります。メッセージ レベルでは、一般的なルートは次のとおりです。

送信されたら無視してください -> 単一ノード確認 -> マルチノード確認 -> マルチノード確認同期ディスクフラッシュ -> 全ノード同期ディスクフラッシュ -> トランザクション メッセージなど。

単一マシンの高い信頼性

クラスターの高い信頼性は、ack メカニズムとマルチコピー メカニズムによって保証されます。単一ノードの場合、停電やホストの異常は大きな課題となります。この状況に対処するには、ディスク フラッシュ メカニズムまたはその他の永続化メカニズムが必要です。同時に、データの整合性検証も必要となるため、データ量が多い場合、Kafka などのメッセージ システムの起動に非常に長い時間がかかります。

生産

運用側では、バッファ損失の問題を考慮するだけでなく、クラスターとの通信のタイムアウトや再試行処理など、いくつかの送信エラーも考慮する必要があります。

消費者側

コンシューマーはメッセージ確認メカニズムを使用して、メッセージが正しく消費されたことを確認します。その間に多くの異常な状況が発生する可能性があるため、ほとんどのメッセージング システムでは少なくとも 1 回のセマンティクスが保証されます。つまり、メッセージが少なくとも 1 回は消費されることを確認します。

つまり、メッセージは繰り返され、繰り返しの消費によってビジネス上の異常が発生しないようにするために、コンシューマーはべき等性を持つ必要があります。

消費者側でもエラーが発生する場合があります。一部の MQ では、複数の消費失敗後にデッドレター キューに自動的に入れることができますが、一部の MQ では、計画のために独自のトピックを設計する必要があります。

高性能

データ伝送チャネルとして、パフォーマンスは非常に重要な考慮事項です。より重要な指標のうちの 2 つは、メッセージの遅延とメッセージのスループットです。

メッセージがプロダクション側から送信されてからコンシューマー側で処理されるまでのプロセスは、長くなりすぎてはなりません。プルモードを使用して消費する MQ では、ポーリング速度を高速化し、ゼロコピーなどのテクノロジを使用してデータ転送を高速化する必要があります。

メッセージ スループットに関しては、プロダクション側、MQ ノード、およびコンシューマー側の共同最適化の結果です。現在、主な手段は以下の通りです。

非同期

メッセージは非同期で送信されるため、送信者は同期的に待機する必要がなく、処理が高速化されます。

バッチ

ネットワーク送信回数を減らし、データ圧縮を容易にするためにバッチ送信が採用されています。通常、バッファはメモリに保存されます。バッファがいっぱいになるか、時間ウィンドウに達すると、送信が実行されます。これにより転送速度が大幅に向上しますが、適切に処理しないとデータが失われる可能性があります。

シーケンシャルIO

xjjdog は、シーケンシャル ディスク操作はランダム メモリ操作よりもはるかに高速であると多くの記事で述べています。これは、Kafka などのメッセージ キューが高速である理由の 1 つですが、トピックの数に注意してください (理由について考えてください)。

さらに、他の手段もあります。たとえば、オペレーティング システムのパラメータを最適化したり、シャーディングを使用して並列処理を向上させたりします。

メッセージタイプ

メッセージはポイントツーポイントであり、メッセージは一度だけ消費されます。 Pub/Sub はパブリッシュ/サブスクライブ モデルを使用するため、1 つのメッセージを複数のコンシューマーが使用できます。ブロードキャスト モードを通じてブロードキャストされる種類のメッセージもあります。つまり、プロデューサーがメッセージを送信し、すべてのコンシューマーがそれを受信します。

一般的に送信されるメッセージに加えて、特別な目的のためのメッセージもいくつかあります。シーケンシャル メッセージは、グローバル順序とパーティション順序に分けられ、通常、厳格な順序要件があるビジネスで使用されます。ビジネス設計により、パフォーマンスに非常に負荷のかかる操作であるグローバル順序付けを回避できます。

一部の MQ はスケジュールされたメッセージもサポートします (ビジネス システムにはこれが適していると思います)。トランザクション メッセージはパフォーマンスを多く消費するため、注意して使用してください。

タグ付けやメッセージフィルタリング機能を提供する MQS もいくつかあります。たとえば、注文情報はトピックに送信され、コンシューマーは関連製品の注文のみをサブスクライブします。これは、分離が必要な状況で非常に役立ちます。

消費パターン

消費モデルには主にプッシュ モデルとプル モデルの 2 つがあります。プル モードは、消費処理速度を消費者側で調整できるため、最も実用的で人気があります。

プッシュ モデルはリアルタイム パフォーマンスに優れていますが、コンシューマー側の機能を評価することが難しく、簡単に圧倒される可能性があります。同時に、pub/sub の処理や失敗後の再試行などにも多くの課題があります。

プロトコル

Java には JMS 仕様があることは誰もが知っていますが、Kafka のようなものはこの仕様を実装していません。したがって、amqp、openwire などの一部のプロトコルは、より明確にカスタマイズされています。

この伝送プロトコルは機能とはほとんど関係ありません。たとえば、http プロトコル、redis プロトコルをベースにしたもの、あるいは websocket をベースにした stomp などがあります。

MQTT はモノのインターネット (IoT) のアプリケーション プロトコルであり、これに基づいたメッセージ キューが多数存在します。

スタッキング容量

現在、データは非常に大きくなっており、MQ の蓄積容量は非常に重要です。たとえば、Redis のようなメモリ キューの場合、数分でバーストが発生します。メッセージ処理用のチャネルであることに加えて、mq はバックアップ ストレージとしても使用できます。

蓄積容量は、データベースへの保存（矛盾転送）、非常に大きなディスクのマウントなど、大規模なストレージに反映されます。しかし、すぐに満足してはいけません。大規模クラスターの起動時の読み込みや障害の再調整には、通常、長い時間がかかります。

蓄積能力のもう一つの現れは、履歴メッセージのクリーニングです。一般的には、ディスクオンラインと期限切れクリーンアップの 2 つの戦略があり、必要に応じて柔軟に設定できます。

エコロジー

オープンソース ソフトウェア エコシステムは非常に重要であり、これは MQ にも当てはまります。これは主に 2 つの側面に反映されています。1 つは多様な開発言語のサポート (プロデューサー パッケージとコンシューマー パッケージの両方を提供する必要があります)、もう 1 つは周辺ソフトウェアのサポートです。統合コストを削減するために、Spring、Spark、Hadoop、Flink などを使用します。

新しい MQ システムを除き、他のすべてのシステムはこの点では良好に機能しています。

メッセージングシステムの役割

メッセージング システムは、現在の分散システムの設計においてますます重要な役割を果たしています。使用シナリオには以下が含まれますが、これらに限定されません。

ピークカットは、業務システムの処理能力を超える要求に対応し、円滑な業務運営を実現するために使用されます。これにより、多くのコストを節約できます。たとえば、一部のフラッシュセールはピーク時の容量を考慮して設計されていません。

バッファリングは、サービス レイヤーと低速着陸レイヤーにバッファー レイヤーとして存在します。その機能はピークシェービングに似ていますが、主にサービス内のデータフローに使用されます。たとえば、バッチ SMS メッセージを送信します。

デカップリング プロジェクトはまだ始まったばかりであり、具体的な要件は決定できません。メッセージ キューは、重要なビジネス プロセスを分離するためのインターフェイス レイヤーとして機能します。拡張機能を得るには、規則に従い、データに対してプログラムするだけです。

冗長メッセージ データは、複数の無関係なビジネスに対して 1 対多の方法で使用できます。

堅牢なメッセージ キューはリクエストを蓄積できるため、コンシューマー側のビジネスが短時間停止しても、メイン ビジネスの正常な動作には影響しません。

終わり

メッセージの量と目的に基づいて、分散 MQ は大まかに 2 つのカテゴリに分類できます。

1 種類は業務システム用として使用され、極めて高い信頼性を確保します。注文や支払いなどのメッセージが失われないようにし、高い SLA サービス レベルを満たす必要があります。この場合、メッセージの追跡可能性など、MQ には多くの機能要件があります。

ビッグデータに使用される別のタイプのシステムは、非常に高いスループットを特徴としています。異常な状況では、いくつかのメッセージを失っても問題ありません。

しかし、メッセージ システムは MQ 自体にのみ焦点を当てている可能性があります。生産側、消費側、および MQ 自体の可用性をどのように確保するかには、ビジネス上のトレードオフが必要です。

たとえば、xjjdog が以前オープンソース化した okmq は、特定のシナリオにおける高可用性の問題を解決するために使用されました。

オープンソースの Kafka 拡張機能: okmq-1.0.0