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

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 は自動的にべき等プロデューサーを開始します。

<<:  グランドビューリサーチ:クラウドコンピューティング市場は2028年に12510.9億ドルに達する

>>:  Docker の脱獄、気づきましたか?

推薦する

ゲームデザインメカニズム研究: インターネット製品デザインの 12 の概念

私たちの多くは、物事に集中することが難しいですが、ゲームであれば集中できます。私たちのほとんどは、物...

美団と大衆点評の協力の主な問題

美団と大衆点評の合併は中国インターネット業界で大きな注目を集めている。両者の新会社の評価額は150億...

SEOは常に検索とともに存在し、衰えることはない

昨今、SEO について語ることは、以前に比べてはるかに人気がなくなったようです。過去 2 年間、多く...

ジェレミー・リンのドメイン名ブーム:ドメイン名なし、2つの商標を申請したい

2012年2月20日、報道によると、先週からジェレミー・リンという名前がスポーツ界とドメイン名界で最...

検索エンジン最適化の詳細

検索エンジン向けに最適化する場合、ページがシンプルであればあるほど、細部の最適化に注意を払う必要があ...

#五周年/11-11# uuuvps: VPS 12元から(2年購入で1年無料)、「米国 AS4837/4 ネットワーク CN2/4 ネットワーク CU2/香港 CTG(CN2+BGP)」、ネイティブ ローカル IP

uuuvpsは設立5年目を迎えました。11月はゴールデンプロモーション月間であり、ダブルイレブンとブ...

タオバオの中小販売業者の生活はますます悲惨になっています!それはすべてあなた自身のせいですか?

誰もが今同じような考えを持っているに違いありません。つまり、タオバオとTmallでビジネスをするのは...

組み合わせマーケティングソフトウェアの競争が業界関係者の間で白熱した議論を引き起こす

インターネットマーケティングソフトウェア市場で伝統と革新が対決最近、複合マーケティングソフトウェアと...

中科紅旗の生と死

中科紅旗(正式名称:北京中科紅旗ソフトウェア技術有限公司)は、2000年6月に設立されました。中国科...

Douyinの食品専門家の「オルタナティブ起業」:パーソナルマーケティングを活用して人気商品を管理

2018年最もホットなプロジェクト:テレマーケティングロボットがあなたの参加を待っています「人がいる...

hostodo: 年間 25 ドル、米国 VPS (データセンター 3 か所)、2G メモリ/2 コア/20GNVMe/5T トラフィック

Hostodo (~) は現在、ラスベガス、スポケーン、マイアミのデータセンターで、少なくとも 5T...

ホスティング - 3.5 ドル / 512 m メモリ / 50 g ハードディスク / 1 T トラフィック / 10 g DDOS 保護 / QN コンピュータ ルーム

Hostigation.com は、ロサンゼルス データ センターの VPS をすべてのユーザーに無...

経験: 無効なページを処理してウェブサイトの価値を高める方法

国内SEO市場の拡大と各業界間の熾烈な競争により、SEO実践者は大きな課題に直面しています。最近、フ...

デジタル経済の時代において、Volcano Engineはクラウド上で企業の成長を支援します

クラウド市場での差別化に注力するボルケーノエンジンは、「クラウドにおける新たな成長の原動力」というス...

ウェブマスターがオンラインプロモーションで注意すべきいくつかの詳細

起業の道でまだ奮闘中のウェブマスターの皆さん、私は葉凡喜です。今日は、インターネットで奮闘する道で誰...