Kafka のべき等プロデューサーを 1 つの記事で理解する

[[422790]]

この記事はWeChatの公開アカウント「Mingge's IT Essays」から転載したもので、著者はIT Minggeです。この記事を転載する場合は、Mingge の IT Essays 公開アカウントにご連絡ください。

1 はじめに

みなさんこんにちは、ミン兄弟です！

オープンソースの分散イベント ストリーム プラットフォームである KAFKA には、ビッグ データやマイクロサービスの分野で幅広いアプリケーション シナリオがあります。これは、リアルタイム ストリーム処理シナリオにおけるメッセージ キューの事実上の標準です。一言でまとめると、KAFKA はリアルタイム データ ウェアハウスの基礎であり、イベント駆動型アーキテクチャの魂です。

しかし、一部の技術パートナー、特に KAFKA を非常に早い段階で使い始めたパートナーは、KAFKA の開発動向やいくつかの新機能にあまり精通しておらず、使用中に多くの落とし穴に遭遇しています。

これを踏まえて、次回は KAFKA シリーズの記事を掲載し、KAFKA のこれらの新機能について具体的に説明します。

この記事は、KAFAK のべき等プロデューサーに関するシリーズの一部です。

以下が本文です。

2. 歴史的観点から見たKAFKAの発展

まず、KAFKA の発展を歴史的な観点から見てみましょう。

• KAFKA は 2013 年 12 月に重要なバージョン 0.8.0 をリリースしました。このバージョンは、KAFKA-50 を通じて初めてマルチコピー メカニズムを導入し、フォールト トレランスの強固な基盤を築いたため、非常に重要です。
• その後、後続のバージョンでは多くの新機能が徐々に追加されました。
  • たとえば、Zookeeper への依存を徐々に排除します。
  • コンパクトなクリーンアップ戦略のサポートなど。
  • Kafka の古いストレージのサポートなど。
  • プロデューサーの冪等性など。
  • トランザクションのサポートなど。
  • 大規模な Kafka エコシステムの Kafka connect API、Kafka stream API、KSQL、Kafka スキーマ レジストリなど。
• 現在（202109）、KAFKA の最新の安定バージョンは 2.8.0 に進化しています。
• KAFKA は、単なる高スループット メッセージ ミドルウェアから、リアルタイム ストリーム処理シナリオにおけるメッセージ キューの事実上の標準へと進化しました。一言で言えば、KAFKA はリアルタイム データ ウェアハウスの基礎であり、イベント駆動型アーキテクチャの核心です。
• ただし、市場にはバージョン 0.8.0 などの初期バージョンを使用している実稼働環境がまだ多く存在します。

カフカタイムライン

カフカAPI

3 べき等プロデューサーとは何ですか?

Kafka プロデューサーがブローカー内のトピックにデータを送信すると、ネットワーク ジッターなどのさまざまな理由により、プロデューサーがブローカーの ack 確認情報を受信しない可能性があることがわかっています。この時点でプロデューサーには 2 つの選択肢があります。

プロデューサーは、ack 確認メッセージを受信しなかったという事実を無視し、それ以上の処理を行わないことを選択できます。この場合、メッセージが失われる可能性があります。 (メッセージがブローカーのトピックに書き込まれていない可能性があるため、これは可能ですが、ブローカーのトピックに正しく書き込まれているが、ネットワーク ジッターのためにコールバック ack メッセージがプロデューサーによって受信されなかった可能性もあります。)

プロデューサーは、ack 確認メッセージを受信するか、再試行の最大回数に達するまで、メッセージを複数回再送信することもできます。これにより、メッセージの重複書き込みが発生する可能性があります。つまり、ブローカー側のトピックは、これらの再試行されたメッセージを繰り返し保存します。

プロデューサーが ack 確認を受信して​​いないメッセージを再送信すると、ブローカーのトピックのパーティション内のメッセージの順序が乱れる可能性もあります。つまり、失敗のために再送信されたメッセージは、失敗しておらず再送信する必要のないメッセージの後に送信されます。

プロデューサーが ack 確認を受信して​​いないメッセージを再送信することによって発生するデータ重複の問題は、次の図に示されています。メッセージ 7/8/9/10 は重複メッセージです。

プロデューサー再送信失敗

KAFKA のべき等プロデューサーは上記の問題を解決します。つまり、メッセージが損失や重複なくブローカーに正しく配信され、トピックの各パーティションに正しい順序で保存されることを保証します。

4 べき等プロデューサーを有効にするにはどうすればいいですか?

• べき等プロデューサーを有効にするには、コードの変更は不要で、次の構成項目の変更のみが必要です。
• enable.idempotence=true; // 冪等プロデューサー関数スイッチ
• message.send.max.retries=xx //送信失敗後の再試行回数は、10000000 などの大きな値、または Integer.MAX_VALUE に設定できます。
• max.in.flight.requests.per.connection=xx //xx <= 5 は、各接続で実行中のリクエストの数を表します。一部のブログでは、このパラメータは =1 として設定する必要があると書かれていますが、これは正しくありません。 5 以下である必要があります (enable.idempotence が true の場合、max.in.flight は 5 以下に設定する必要があります)。
• Acks=All //ACK 確認パラメータ、オプション 0/1/-1/ALL、-1 は ALL に相当します。 idempotence プロデューサー機能が有効になっている場合、このパラメータは ALL/-1 に設定する必要があります。つまり、メッセージが正常に配信されたと見なされる前に、すべての ISR がメッセージの受信を確認する必要があります (enable.idempotence が true の場合、acks は all に設定する必要があります)。
• べき等プロデューサーが有効になっている場合 (enable.idempotence=true)、パラメーター max.in.flight.requests.per.connection および Acks を構成することもできません。この場合、これら 2 つのパラメータは自動的に構成されます。

5 べき等プロデューサーの原則とは何ですか?

まず、べき等プロデューサーが有効になっている場合、メッセージが失敗したときのメッセージの再送信は Kafka クライアントによって自動的に実装されることを説明する必要があります。これは私たちにとって透過的であり、コードの送信を再試行する必要はありません。 (実際、コード内でメッセージの送信を再試行すると、メッセージが重複することになります)。

内部的には次のように動作します。

• プロデューサー側では、ブローカーによって各プロデューサーにプロデューサー ID (PID) が自動的に割り当てられます。プロデューサーからブローカーに送信される各メッセージには、内部的に pid と増加するシーケンス番号が付随します。
• ブローカー側では、ブローカーは各トピックの各パーティションに対して現在正常に書き込まれたメッセージの最大 PID シーケンス番号タプルを維持します。
• ブローカーは、現在の最大 PID シーケンス番号タプルよりも小さいシーケンス番号メッセージを受信すると、重複したデータ保存を避けるためにメッセージを破棄します。
• ブローカーが失敗し、新しいリーダーを再選出した場合でも、上記の重複排除メカニズムは有効です。ブローカーのトピックに保存されているメッセージ本体には PID シーケンス番号情報が付随しており、リーダーのすべてのメッセージがフォロワーにコピーされるためです。元のフォロワーが新しいリーダーとして選出されると、PID シーケンス番号情報がすでに内部メッセージに保存されているため、メッセージの重複排除を実行できます。
• ブローカー側でのべき等プロデューサー重複排除の動作原理を次の図に示します。

6. べき等プロデューサーはトランザクションとどのように関係しますか?

べき等プロデューサーは Kafka トランザクションの必要条件ですが、十分な条件ではありません。

べき等グロワーを有効にするときにトランザクションを有効にする必要はありません。

Kafka トランザクションを開始するには、べき等プロデューサーを有効にする必要があります。

実際、Kafka トランザクションを開始すると、Kafka は自動的にべき等プロデューサーを開始します。