Kafkaがメッセージを失わないようにするにはどうしたらよいかと質問されるたびに、私は泣きそうになります。

1. 背景の紹介

この記事では、オンライン本番環境でメッセージ ミドルウェア テクノロジを使用する際に、データが最初から最後まで失われないようにする方法について説明します。

この問題はインターネット企業の面接でも頻繁に登場し、実稼働環境でも非常に現実的な問題です。

履歴書に MQ テクノロジー (RabbitMQ、RocketMQ、Kafka) に精通しており、プロジェクトで使用した経験があると書いていた場合、非常に実用的な実稼働環境の質問は、メッセージを MQ に配信し、その後 MQ からメッセージを消費して処理するプロセスでデータが失われるかどうかです。

次に、面接官は次のように質問します。プロジェクトが本番環境に導入されたときにデータが失われる場合、MQ に基づいて送信されるデータが 100% 失われないようにするためにどのような手段を使用しますか?オンラインで使用しているメッセージミドルウェアに基づいて、技術的なソリューションを詳しく説明してください。

これは実際に、面接候補者の技術レベルを本当に区別できる質問です。

実際、中小規模のインターネット企業で働いた経験のある一般エンジニアも含め、大多数のエンジニアは、企業が導入した MQ クラスターをそのまま使用しています。コードレベルでは、メッセージを送信して消費するだけで、あまり多くの技術的なソリューションを考慮していない可能性があります。

しかし実際には、MQ、キャッシュ、シャーディング、NoSQL などのさまざまなテクノロジーやミドルウェアを使用すると、対応するテクノロジーに関連した本番環境の問題が多数発生します。

これらの問題に対処するには、システムの堅牢性、安定性、高可用性を確保するための完全な一連の技術ソリューションを開発する必要があります。

実際、中規模および大規模のインターネット企業の面接官が候補者を面接する際に、MQ 関連技術の経験と習熟度を調べると、10 回中 9 回は MQ の使用時に必ず発生するデータ損失の問題が取り上げられます。この質問により、応募者の技術レベルを判別するのに非常に役立ちます。

そこでこの記事では、RabbitMQ などのメッセージ ミドルウェアのコンテキストに基づいて、MQ にメッセージを配信し、MQ からメッセージを消費するプロセスにおけるデータ損失のリスクと可能性について具体的に説明します。

それでは、MQ 自体が提供するいくつかの技術的機能を組み合わせて、データが失われないようにする方法を見てみましょう。

2. 既存の技術的解決策

これまでのいくつかの記事で議論した結果、データ損失が発生する最初の原因は、コンシューマーがメッセージを受信したものの、それを処理する時間がなく、直接クラッシュした場合であるという予備的な理解が得られました。

このとき、RabbitMQ の自動 ack メカニズムによって、メッセージが処理されたことが MQ クラスターに通知され、MQ クラスターはメッセージを削除します。

そうするとメッセージは失われてしまうのではないでしょうか?このメッセージはどのコンシューマーも処理しません。

したがって、コンシューマー サービスで手動 ack メカニズムを調整することで、MQ クラスターに ack 通知を送信する前にメッセージが正常に処理されたことを確認できることについては、前に詳しく説明しました。

そうでない場合、ACK を送信する前にコンシューマー サービスがクラッシュすると、MQ クラスターはそれを自動的に検知し、メッセージを他のコンシューマー サービス インスタンスに再送信します。

手動 ACK メカニズムのアーキテクチャ図は次のとおりです。

データ損失の問題に加えて、別の問題もありました。MQ クラスター自体が突然クラッシュした場合、データ損失が発生するのでしょうか?

デフォルトでは、キューもメッセージも永続的に配信されないため、これは必ず発生します。そのため、MQ クラスターを再起動すると、一部のデータが失われます。

このとき、メッセージが時間内にコンシューマー サービスに配信されず、MQ クラスターが突然クラッシュした場合でも、MQ クラスターが再起動すると、未配信のメッセージがディスク ファイルから自動的に読み込まれ、コンシューマー サービスに配信され続けるため、データは失われません。

同様に、このソリューションのシステム アーキテクチャ図は次のとおりです。

3. データは100%失われていませんか?

皆さん、考えてみてください。これまでのところ、私たちのアーキテクチャはデータが失われないことを保証できますか?

実際、現在のアーキテクチャでは依然としてデータ損失の問題が残っています。

つまり、プロデューサーとしての注文サービスがメッセージを MQ クラスターに配信した後、そのメッセージは一時的に MQ のメモリ内に存在し、ディスクに永続化する時間はまだありません。同時に、消費者として倉庫サービスにそれを届ける時間はまだありません。

このとき MQ クラスター自体が突然クラッシュした場合、どうすればよいでしょうか?

恥ずかしいですよね？メモリ内に存在するデータは確実に失われます。次の図を見てみましょう。

4. 必要に応じて技術的なソリューションを開発する

ここで、技術的な解決策を検討する必要があります。注文サービスはどのようにしてメッセージがディスクに保存されたことを確認できるでしょうか?

実際、オーダー サービスがプロデューサーとして MQ クラスターにメッセージを配信するときに、データが失われるのは非常に簡単です。

たとえば、ネットワークに問題があり、データがまったく送信されない場合、または上記のメッセージが MQ によって受信されたばかりで、まだメモリ内に常駐していてディスクに保存されていない場合、MQ クラスターはクラッシュし、データが失われます。

したがって、まず最初に、プロデューサーとしての注文サービスが RabbitMQ によって提供される関連機能をどのように使用して技術的なソリューションを実装できるかを検討する必要があります。

この技術的ソリューションでは、注文サービスによって送信されたメッセージが正常に確認される限り、MQ クラスターがメッセージをディスクに永続化していることを保証する必要があります。

MQ クラスターに配信されたデータが失われないようにするには、このような効果を実現する必要があります。

5. 検討すべき技術的な詳細

ここで検討する必要がある技術的な詳細は、データが失われないようにするためのストレージ サービスの手動 ACK の実装原則です。

以前、私は学生たちから多くの質問を受けました。

• ウェアハウス サービスは、手動確認に基づいてデータが失われないことをどのように保証しますか?
• RabbitMQ の基礎となる実装の詳細と原則は何ですか?
• ストレージ サービスが ack を送信せずにクラッシュしたのはなぜですか? RabbitMQ はクラッシュしたことを自動的に感知し、メッセージを他のストレージ サービス インスタンスに自動的に再送信できますか?

これらの背後にある実装原則と基本的な詳細は何ですか?