この問題について詳しく調べてみると、Kafka メッセージ ミドルウェアはメッセージを失うのでしょうか?

[[351967]]

この記事はWeChatの公開アカウント「笑い好きの建築家」から転載したもので、著者はLei Jiaです。この記事を転載する場合は、笑いが大好きな建築家の公開アカウントまでご連絡ください。

大規模なインターネット企業では、一般的に、メッセージの送信が可能な限り損失なく行われることを要求します。たとえば、ユーザー サービスがバウチャー サービスにメッセージを送信し、そのメッセージが失われた場合、ユーザーは受け取るべきバウチャーを受け取れず、最終的には苦情を言うことになります。

上記のような事態を回避するためには、補償措置を講じるだけでなく、システム設計時にさまざまな例外も十分に考慮し、安定的かつ可用性の高いメッセージシステムを設計する必要があります。

Kafkaを理解する

Wikipediaの定義を見てください

Kafka は分散型のパブリッシュ/サブスクライブ メッセージング システムです。もともと LinkedIn によって開発され、後に Apache プロジェクトの一部となりました。

Kafka は、分散型、パーティション化可能、冗長化可能、永続的なログ サービスです。主にアクティブ ストリーミング データを処理するために使用されます。

Kafka アーキテクチャ

Kafka の全体的なアーキテクチャは非常にシンプルです。これは明示的に分散されたアーキテクチャであり、主にプロデューサー、ブローカー (kafka)、コンシューマーで構成されます。

Kafka アーキテクチャ (簡易版)

プロデューサーは、選択したトピックにデータを公開できます。プロデューサーは、トピックのパーティションにレコードを割り当てる責任があります。負荷分散は、ラウンドロビン方式を使用して簡単に実現できます。また、何らかのセマンティック パーティショニング機能 (レコード内のキーなど) に基づいて実行することもできます。

コンシューマーはコンシューマー グループ名によって識別され、トピックに公開される各レコードは、サブスクライブしているコンシューマー グループ内のコンシューマー インスタンスに割り当てられます。コンシューマー インスタンスは、複数のプロセスまたは複数のマシンに分散できます。

Kafka はメッセージを失いますか?

Kafka がメッセージを失うかどうかを議論する前に、まずメッセージ配信セマンティクスとは何かを理解しましょう。

メッセージパッシングセマンティクス

メッセージ配信セマンティクスは、メッセージ配信プロセス中のメッセージ配信の保証です。主なタイプは3つあります。

• 最大 1 回: 最大 1 回。メッセージは失われたり処理されたりする可能性がありますが、最大で 1 回しか処理されません。
• 少なくとも1回: 少なくとも1回。メッセージは失われませんが、複数回処理される可能性があります。繰り返しても失われません。
• 正確に 1 回: 正確に 1 回配信されます。メッセージは一度だけ処理されます。なくさないで、繰り返さないで、ただ一度だけ。

理想的には、システムのメッセージ配信が厳密に 1 回だけ行われること、つまり、失われず、1 回だけ処理されることが保証されることが望まれますが、これを実現するのは困難です。

主人公の Kafka に戻ると、Kafka には 3 つのメッセージ配信プロセスがあります。

1. プロデューサーは Kafka ブローカーにメッセージを送信します。
2. Kafka ブローカーのメッセージ同期と永続性
3. Kafka Broker はメッセージをコンシューマーに配信します。

これら 3 つのステップのそれぞれでメッセージが失われる可能性があります。以下は、メッセージが失われる理由と、メッセージの損失を最小限に抑える方法の詳細な分析です。

プロデューサーがメッセージを失った

まず、プロデューサーがメッセージを送信する一般的なプロセスを紹介します (一部のプロセスは特定の構成項目に強く関連していますが、ここでは無視します)。

1. プロデューサーはリーダーと直接対話するため、最初にクラスターからトピックに対応するパーティションのリーダー メタデータを取得します。
2. リーダー パーティションのメタデータを取得したら、メッセージを直接送信します。
3. Kafka ブローカーに対応するリーダー パーティションは、メッセージを受信した後、永続化のためにファイルに書き込みます。
4. フォロワーはリーダーのメッセージを引き出し、データをリーダーと一貫性のある状態に保ちます。
5. フォロワーがメッセージのプルを完了したら、リーダーに ACK 確認メッセージで応答する必要があります。
6. Kafka リーダー パーティションとフォロワー パーティションが同期されると、リーダー パーティションはプロデューサーに ACK 確認メッセージで応答します。

プロデューサーがデータを送信するプロセス

プロデューサーはプッシュ モードでブローカーにデータを公開し、各メッセージをパーティションに追加して、ディスクに順番に書き込みます。メッセージがリーダーに書き込まれた後、フォロワーはリーダーと積極的に同期します。

Kafka メッセージを送信する方法には、同期 (sync) と非同期 (async) の 2 つがあります。デフォルトは同期であり、producer.type プロパティを通じて構成できます。

Kafka は、request.required.acks プロパティを構成することによってメッセージの生成を確認します。

• 0 はメッセージの受信が成功したことの確認がないことを意味します。メッセージが正常に送信されたという保証はなく、本番環境では基本的に使用されません。
• 1 はリーダーが正常に受信した際の確認を意味します。リーダーが存続する限り、失われないことが保証され、スループットが保証されます。
• -1 または all は、リーダーとフォロワーの両方がメッセージを正常に受信したことを確認することを意味します。これにより、メッセージが最大限に失われないようにすることができますが、スループットは低くなります。

kafka プロデューサー パラメータ acks のデフォルト値は 1 なので、デフォルトのプロデューサー レベルは正確に 1 回ではなく、少なくとも 1 回になります。

注意してください。ここで情報が失われる可能性があります。

acks が 0 に設定されている場合、メッセージはネットワーク ジッタにより失われ、プロデューサーは ACK をチェックしなければ損失に気付きません。

acks が 1 に設定されている場合、リーダーが失われないことが保証されます。ただし、リーダーが失敗し、ACK のないフォロワーを選択した場合は、メッセージも失われます。

all: リーダーとフォロワーが失われないことを保証しますが、ネットワークが混雑して ACK が受信されない場合は、送信が繰り返される問題が発生します。

Kafka ブローカーがメッセージを失った

データを受信した後、Kafka Broker はデータを永続的に保存します。次のように考えるかもしれません:

メッセージの永続性、キャッシュなし

こうなるとは思っていませんでした:

キャッシュによるメッセージの永続化

オペレーティング システム自体には、ページ キャッシュと呼ばれるキャッシュ レイヤーがあります。ディスク ファイルに書き込む場合、システムはまずデータ ストリームをキャッシュに書き込みます。キャッシュされたデータをファイルに書き込むタイミングは、オペレーティング システムによって決定されます。

Kafka は、アクティブにフラッシュするかどうかを制御するためのパラメーター producer.type を提供します。 Kafka が mmap に書き込んだ直後にフラッシュして Producer に戻る場合、それは同期 (sync) と呼ばれます。 Kafka が flush を呼び出さずに mmap に書き込んだ直後に Producer に戻る場合、それは非同期 (async) と呼ばれます。

注意してください。ここで情報が失われる可能性があります。

Kafka は、マルチパーティションとマルチコピーのメカニズムを通じて、データが失われないという保証を最大限に高めることができました。データがシステム キャッシュに書き込まれているが、まだディスクにフラッシュされていない場合、マシンが突然クラッシュしたり電源が失われたりすると、データは失われます。もちろん、この状況は非常に極端です。

消費者がメッセージを紛失

コンシューマーは、プル モードを通じて Kafka クラスターからメッセージをアクティブにプルします。プロデューサーと同様に、コンシューマーもメッセージをプルするためにリーダー パーティションを探します。

複数のコンシューマーがコンシューマー グループを形成でき、各コンシューマー グループにはグループ ID があります。同じコンシューマー グループ内のコンシューマーは、同じトピックの下にある異なるパーティションからデータを消費できますが、複数のコンシューマーが同じパーティションからデータを消費することはありません。

消費者団体の消費メッセージ

コンシューマー消費の進行状況は、オフセットを通じて Kafka クラスターの __consumer_offsets トピックに保存されます。

メッセージの消費は主に 2 つの段階に分かれています。

1. メッセージを使用済みとしてマークし、オフセット座標をコミットします。

2. メッセージを処理します。

注意してください。ここで情報が失われる可能性があります。

シナリオ 1: 最初にコミットしてからメッセージを処理します。メッセージの処理中に例外が発生しても、オフセットがコミットされている場合、メッセージはコンシューマーに対して失われ、再度消費されることはありません。

シナリオ 2: 最初にメッセージを処理してからコミットします。コミット前に例外が発生した場合、メッセージは次回使用されます。重複消費の問題は、ビジネスによってメッセージのべき等性を保証することで解決できます。

要約する

そこで疑問なのが、Kafka はメッセージを失うのか、ということです。答えは「はい」です。

Kafka では、次の 3 つの段階でメッセージが失われる可能性があります。

（１）プロデューサーがデータを送信する。

（２）Kafka Brokerはデータを保存します。

（３）消費者消費データ

実際には、本番環境で厳密に 1 回だけ実装することは困難であり、効率とスループットも犠牲になります。ベストプラクティスは、メッセージが失われた場合に備えて、ビジネス側で補償メカニズムを用意してバックアップを提供することです。