この問題について詳しく調べてみると、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 つのメッセージ配信プロセスがあります。

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

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

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

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

プロデューサーはリーダーと直接対話するため、最初にクラスターからトピックに対応するパーティションのリーダーメタデータを取得します。
リーダーパーティションのメタデータを取得したら、メッセージを直接送信します。
Kafka ブローカーに対応するリーダーパーティションは、メッセージを受信した後、永続化のためにファイルに書き込みます。
フォロワーはリーダーのメッセージを引き出し、データをリーダーと一貫性のある状態に保ちます。
フォロワーがメッセージのプルを完了したら、リーダーに ACK 確認メッセージで応答する必要があります。
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 つの段階でメッセージが失われる可能性があります。

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