Kafka の学習および Kafka プロダクション構成に関する権威あるガイド

0. Kafka の共通コマンド

Kafka は、拡張性と耐障害性が高い分散ストリーム処理プラットフォームです。Kafka の最新バージョンで一般的に使用されるコマンドをいくつか示します。

1. トピックを作成します。

   bin/kafka-topics.sh --create --topic my-topic --partitions 3 --replication-factor 3 --bootstrap-server localhost:9092

2. トピックのリストを表示します。

   bin/kafka-topics.sh --list --bootstrap-server localhost:9092

3. トピックの詳細を表示します。

   bin/kafka-topics.sh --describe --topic my-topic --bootstrap-server localhost:9092

4. トピックにメッセージを送信します。

   bin/kafka-console-producer.sh --topic my-topic --bootstrap-server localhost:9092

5. トピックからのメッセージを消費します。

   bin/kafka-console-consumer.sh --topic my-topic --from-beginning --bootstrap-server localhost:9092

6. コンシューマ グループのオフセットを表示します (オフセット)。

   bin/kafka-consumer-groups.sh --describe --group my-group --bootstrap-server localhost:9092

7. Kafka サービスを開始します。

   bin/kafka-server-start.sh config/server.properties

1. Kafkaの最適構成

複数のノードを記述するには複数のノードがあります

vim /srv/app/kafka/config/server.properties 

忘れずにbroker.idを変更してください

broker.id=0
listeners=PLAINTEXT://10.53.32.126:9092
advertised.listeners=PLAINTEXT://10.53.32.126:9092
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=/srv/data/kafka-data
num.partitions=3
num.recovery.threads.per.data.dir=3
offsets.topic.replication.factor=3
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=3
log.retention.hours=4
log.segment.bytes=1073741824
log.retention.check.interval.ms=300000
zookeeper.connection.timeout.ms=6000
zookeeper.connect=10.53.32.126:2181,10.53.32.153:2181,10.53.32.134:2181
group.initial.rebalance.delay.ms=0
default.replication.factor=2

動物園飼育員の 2 つの最適な構成

複数のノードを記述するには複数のノードがあります

vim conf/zoo.cfg

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/srv/data/zookeeper-data
dataLogDir=/srv/data/zookeeper-datalog
clientPort=2181
autopurge.snapRetainCount=10
autopurge.purgeInterval=1
maxClientCnxns=1200
leaderServes=yes
minSessionTimeout=4000
maxSessionTimeout=40000
server.1=10.53.32.126:2888:3888
server.2=10.53.32.153:2888:3888
server.3=10.53.32.134:2888:3888
## Metrics Providers
# https://prometheus.io Metrics Exporter
metricsProvider.className=org.apache.zookeeper.metrics.prometheus.PrometheusMetricsProvider
metricsProvider.httpPort=7000
metricsProvider.exportJvmInfo=true

1.zkシングルノードの場合

1. zk              http://bit.ly/2sDWSgJ をダウンロードして起動します。 次のスタンドアロン サービスの例は、基本構成で Zookeeper をインストールする方法を示しています。インストール ディレクトリは /usr/local/zookeeper、データ ディレクトリは /var/lib/zookeeper です。
2. スタートZK

3. # tar -zxf zookeeper-3.4.6.tar.gz
   # mv zookeeper-3.4.6 /usr/local/zookeeper
   # mkdir -p /var/lib/zookeeper
   # cat > /usr/local/zookeeper/conf/zoo.cfg << EOF
   tickTime=2000
   dataDir=/var/lib/zookeeper
   clientPort=2181
   > EOF
   # export JAVA_HOME=/usr/java/jdk1.8.0_51
   # /usr/local/zookeeper/bin/zkServer.sh start
   JMX enabled by default
   Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg
   Starting zookeeper ... STARTED

4.  ポート2181が開いていることを確認します

telnet localhost 2181


ss -luntp|grep 2181

2.zkクラスターの場合

通常は 3 つまたは 5 つのベース ノードを選択します

グループ設定ファイルを変更し、my.id ファイルと設定項目を追加します。

vim  /usr/local/zookeeper/conf/zoo.cfg

myid=1
tickTime=2000
dataDir=/var/lib/zookeeper
clientPort=2181
initLimit=20
syncLimit=5
server.1=zoo1.example.com:2888:3888
server.2=zoo2.example.com:2888:3888
server.3=zoo3.example.com:2888:3888

このうち、initLimitは、スレーブノードとマスターノードとの間の初期接続を確立するのにかかる時間の上限を示し、syncLimitは、スレーブノードとマスターノードとが同期していなくても許容される時間の上限を示す。どちらの値もtickTimeの倍数であるため、initLimitは20*2000ms、つまり40秒になります。

この構成には、グループ内のすべてのサーバーのアドレスもリストされます。サーバー アドレスは、server.X=hostname:peerPort:leaderPort の後に続きます。

パブリック設定ファイルに加えて、各サーバーはデータ ディレクトリに myid というファイルを作成する必要があります。このファイルにはサーバー ID が含まれている必要があります。このファイルは、設定ファイルで設定されている ID と一致している必要があります。これらの手順を完了したら、サーバーを起動して相互に通信できるようにします。

3.kafkaをインストールする

kafka をダウンロードApache Kafka最新バージョンの Kafka をダウンロードhttps://downloads.apache.org/kafka/3.5.1/kafka_2.12-3.5.1.tgz

# tar -zxvf kafka_2.12-3.5.1.tgz

mv kafka_2.12-3.5.1 /usr/local/kafka

 mkdir /tmp/kafka-logs
# export JAVA_HOME=/usr/java/jdk1.8.0_51
/usr/local/kafka/bin/kafka-server-start.sh -daemon 
 /usr/local/kafka/config/server.properties

Kafkaが開始されているかどうかを確認する

Kafka がエラーを報告するかどうかを確認する

ps -ef|grep kafka

インストールが正常であるかどうかをテストします。新しいバージョンはzookに依存する必要がないことに注意してください。

Kafka のバージョンが高すぎます。2.2+ = バージョンでは、トピックの表示/作成にZookeeperに依存する必要はありません。新しいバージョンでは --bootstrap-server を使用して古いバージョン --zookeeper-serverを置き換えます。

トピックを作成する

老版本kafka
/usr/local/kafka/bin/kafka-topics.sh --create --zookeeper localhost:2181  --replication-factor 1 --partitions 1 --topic test

新版本kafka
[root@kafka bin]# /usr/local/kafka/bin/kafka-topics.sh  --bootstrap-server  172.18.207.104:9092 --create --replication-factor 1 --partitions 1 --topic test
Created topic test.

トピックをリストする

[root@kafka bin]# /usr/local/kafka/bin/kafka-topics.sh --list --bootstrap-server 172.18.207.104:9092
test

4 コンシ​​ューマを開始してメッセージを受信します

注文：

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test

上記のコマンドを実行します。赤いウィンドウを閉じずに、続行して次の運用コマンドを実行します。

5 プロデューサーがメッセージを送信

注文：

bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test

プロダクション側にメッセージを入力します。「私はハンサムです」と入力して Enter キーを押します。コンシューマ側で確認すると、消費が実装されていることがわかります 4 (同じトピックの下にある場合)

3. Kafka クラスターの構成

3.1 ブローカーの構成 (よく見てください)

3.1.1 ブローカー ID

各ブローカーには、broker.id で表される識別子が必要です。デフォルト値は 0 ですが、他の整数に設定することもできます。この値は、Kafka クラスター全体で一意である必要があります。この値は任意に選択でき、メンテナンス目的でこれらの ID をサーバーノード間で交換できます。メンテナンス時に ID 番号をマシン名にマッピングする手間を軽減するために、マシン名に関連する整数に設定することをお勧めします。たとえば、マシン名に一意の番号 (host1.example.com、host2.example.com など) が含まれている場合、broker.id にそれらの番号を設定しても問題ありません。

02. ポート 設定サンプルを使用して Kafka を起動する場合、Kafka はポート 9092 でリッスンします。ポート構成パラメータを変更して、他の使用可能なポートに設定します。1024 未満のポートを使用する場合は、root 権限で Kafka を起動する必要がありますが、これはお勧めできません。

03zookeeper.connect ブローカーのメタデータを保存するために使用される Zookeeper アドレスは、zookeeper.connect を通じて指定されます。localhost:2181 は、Zookeeper がローカル ポート 2181 で実行されていることを示します。この構成パラメータは、コロンで区切られたホスト名:ポート/パスのリストのセットです。各部分の意味は次のとおりです: ホスト名は Zookeeper サーバーのマシン名または IP アドレス、ポートは Zookeeper のクライアント接続ポート、/pathはオプションです。Kafka クラスターの chroot 環境としての Zookeeper パス。指定しない場合、デフォルトでルート パスが使用されます。指定された chroot パスが存在しない場合、ブローカーは起動時にそれを作成します。

Kafka クラスターで chroot パスを使用することがベスト プラクティスです。Zookeeper グループは他のアプリケーションと共有でき、他の Kafka クラスターがある場合でも競合は発生しません。構成ファイル内で Zookeeper サーバーのセットをセミコロンで区切って指定することをお勧めします。Zookeeper サーバーがダウンすると、ブローカーは Zookeeper グループ内の別のノードに接続できます。

04. log.dirs Kafka はすべてのメッセージをディスクに保存し、これらのログ フラグメントを保存するディレクトリは log.dirs によって指定されます。これは、カンマで区切られたローカル ファイル システム パスのセットです。複数のパスが指定されている場合、ブローカーは「最小使用」の原則に従って、同じパーティションのログ セグメントを同じパスに保存します。ブローカーは、ディスク容量が最も少ないパスではなく、パーティション数が最も少ないパスにパーティションを追加することに注意してください。

05. num.recovery.threads.per.data.dir 次の 3 つの状況では、Kafka は構成可能なスレッド プールを使用してログ セグメントを処理します: サーバーは通常どおり起動し、各パーティションのログ セグメントを開くために使用されます。サーバーの再起動後に再起動します。クラッシュは各パーティションのログ セグメントをチェックして切り捨てるために使用され、サーバーの通常のシャットダウンはログ セグメントを閉じるために使用されます。デフォルトでは、ログ ディレクトリごとに 1 つのスレッドのみが使用されます。これらのスレッドはサーバーの起動時と停止時にのみ使用されるため、並列処理の目的を達成するために多数のスレッドを設定することは完全に可能です。特に多数のパーティションを持つサーバーの場合、クラッシュが発生した場合、回復中に並列操作を使用すると、時間を節約できる可能性があります。このパラメータを設定する場合、設定された数は log.dirs で指定された単一のログ ディレクトリに対応することに注意してください。つまり、num.recovery.threads.per.data.dir が 8 に設定され、log.dir で 3 つのパスが指定されている場合、合計 24 のスレッドが必要になります。

06. auto.create.topics.enable デフォルトでは、Kafka は次の状況でトピックを自動的に作成します: プロデューサーがトピックへのメッセージの書き込みを開始したとき、コンシューマーがトピック メッセージからの読み取りを開始したとき、クライアントがメタデータ リクエストを送信したときトピック。多くの場合、これらの動作は予期されていません。さらに、Kafka プロトコルによれば、最初にトピックを作成しないと、それがすでに存在するかどうかを知る方法がありません。手動または他の構成システムを通じてトピックを明示的に作成している場合は、auto.create.topics.enable を false に設定できます。

3.1.2 テーマのデフォルト設定（理解）

01.パーティション数

num.partitions パラメーターは、新しく作成されたトピックに含まれるパーティションの数を指定します。このパラメーターのデフォルト値は 1 です。トピック パーティションの数は増やすことはできますが、減らすことはできないことに注意してください。したがって、num.partitions で指定された値よりも少ないパーティションを持つトピックが必要な場合は、トピックを手動で作成する必要があります。

パーティション数の選択方法

トピックのパーティション数の選択はオプションではありません。数を選択するときは、次の要素を考慮する必要があります。

この情報がわからない場合は、経験則として、パーティションのサイズを 25 GB に制限すると、より良い結果が得られます。

02.log.retention.ms

Kafka は通常、データを保持できる期間を決定するために時間を使用します。デフォルトでは、log.retention.hours パラメータを使用して時間を構成します。デフォルト値は 168 時間、つまり 1 週間です。さらに、他に 2 つのパラメーター log.retention. minutes と log.retention.ms があります。これら 3 つのパラメータの機能は同じで、メッセージが削除される期間を決定しますが、log.retention.ms を使用することをお勧めします。複数のパラメータが指定された場合、Kafka は値が最も小さいパラメータを優先します。

03. log.retention.bytes メッセージの有効期限が切れているかどうかを、メッセージの保持バイト数で判断する方法もあります。その値はパラメータ log.retention.bytes によって指定され、各パーティションに作用します。つまり、8 つのパーティションを持つトピックがあり、log.retention.bytes が 1GB に設定されている場合、このトピックは最大 8GB のデータを保持できます。したがって、トピックのパーティション数が増加すると、トピック全体で保持できるデータも増加します。

log.retention.bytes と log.retention.ms (または別の時間パラメーター) の両方が指定されている場合、メッセージはいずれかの条件が満たされるとすぐに削除されます。

04. log.segment.bytes の上記の設定は、個々のメッセージではなくログ セグメントに適用されます。メッセージがブローカーに到着すると、メッセージはパーティションの現在のログ セグメントに追加されます。ログ セグメント サイズが log.segment.bytes で指定された上限 (デフォルトは 1 GB) に達すると、現在のログ セグメントが閉じられ、新しいログ セグメントが開きます。ログセグメントが閉じられると、有効期限が切れるまでの待機が開始されます。このパラメータの値が小さいほど、新しいファイルが閉じられて割り当てられる頻度が高くなり、ディスク書き込みの全体的な効率が低下します。

ログ セグメントのサイズは、オフセットを取得するためのタイムスタンプの使用に影響します。タイムスタンプを使用してログ オフセットを取得する場合、Kafka は、最終変更時刻がパーティション内の指定されたタイムスタンプより大きいログ セグメント (閉じられている) と、ログ セグメントの前のファイルをチェックします。最終変更時刻はそれより小さいです。指定されたタイムスタンプよりも古い。次に、Kafka はそのログ セグメントの先頭のオフセット (つまり、ファイル名) を返します。タイムスタンプを使用してオフセットを取得する操作の場合、ログ セグメントが小さいほど、結果はより正確になります。

3.2 必要なブローカーの数

Kafka クラスターに必要なブローカーの数は、次の要因によって異なります。まず、データを保持するために必要なディスク容量と、単一のブローカーで使用できる容量です。クラスター全体で 10 TB のデータを保持する必要があり、各ブローカーが 2 TB を保存できる場合、少なくとも 5 つのブローカーが必要です。データ レプリケーションが有効な場合は、少なくとも 2 倍のスペースが必要ですが、これは設定されたレプリケーション係数によって異なります (第 6 章で説明)。つまり、データ レプリケーションが有効な場合、クラスターには少なくとも 10 個のブローカーが必要です。

考慮すべき 2 番目の要素は、リクエストを処理するクラスターの容量です。これは通常、特に複数のコンシューマが存在する場合や、データ保持中にトラフィックが変動する場合 (ピーク時のトラフィック バーストなど)、クライアント トラフィックを処理するネットワーク インターフェイスの能力に関連します。1 つのブローカーのネットワーク インターフェイスがピーク時に 80% の使用率に達する可能性があり、コンシューマーが 2 人いる場合、コンシューマーはブローカーが 2 つなければピークを維持できません。クラスターでレプリケーションが有効になっている場合、この追加のコンシューマーが考慮されます。ディスク スループットの低下やシステム メモリの不足によって引き起こされるパフォーマンスの問題も、複数のブローカーを拡張することで解決できます。

 3.2.1 ブローカーの構成

ブローカーをクラスターに追加するには、2 つの構成パラメーターのみを変更する必要があります。まず、すべてのブローカーを同じzookeeper.connect で構成する必要があります。これにより、メタデータの保存に使用される Zookeeper グループとパスが指定されます。

次に、各ブローカーは、broker.id パラメーターに一意の値を設定する必要があります。

3.2.2 vm.swappiness をゼロに設定してはどうでしょうか?

以前は、vm.swapiness を 0 に設定することが推奨されていました。これは、「メモリ オーバーフローが発生しない限り、メモリ スワップを実行しない」ことを意味します。この値の意味が変わったのは、Linux カーネル 3.5-rc1 のリリースまでです。この変更は、Red Hat Enterprise カーネル 2.6.32-303 を含む他のディストリビューションに移植されました。変更後の 0 は、「いかなる状況でもスワップしない」ことを意味します。したがって、この値を 1 に設定することをお勧めします。

3.2.3 ダーティページ

ダーティ ページはディスクにフラッシュされるため、カーネルがダーティ ページを処理する方法を調整することで恩恵を受けることができます。Kafka は I/O パフォーマンスに依存して、プロデューサーに高速な応答時間を提供します。このため、ログ フラグメントは通常、単一の高速ディスク (SSD など) または NVRAM キャッシュを備えたディスク サブシステム (RAID など) のいずれかの高速ディスクに保存されます。このようにして、バックグラウンド フラッシュ プロセスがダーティ ページをディスクに書き込む前に、 vm.dirty_background_ratioを 10 未満の値に設定することで、ダーティ ページの数を減らすことができます。この値はシステム メモリのパーセンテージを指し、ほとんどの場合、5に設定するだけで十分です。0 に設定しないでください。0 に設定すると、カーネルが頻繁にページをフラッシュし、基礎となるデバイスへのディスク書き込みをバッファリングするカーネルの機能が低下します。

カーネル プロセスによってディスクにフラッシュされる前のダーティ ページの数は、 vm.dirty_ratioパラメータを設定することで増やすことができます。このパラメータは 20 より大きい値に設定できます (これはシステム メモリのパーセンテージでもあります)。この値は広い範囲で設定できますが、60 ～ 80 が妥当な範囲です。ただし、このパラメータを調整すると、フラッシュされないディスク操作の数や、同期フラッシュによって生じる長い I/O 待機など、いくつかのリスクが生じます。このパラメーターが高い値に設定されている場合は、システムのクラッシュによるデータ損失を避けるために、Kafka のレプリケーション機能を有効にすることをお勧めします。これらのパラメーターに適切な値を設定するには、ライブ環境とシミュレート環境の両方で、Kafka クラスターの実行中にダーティ ページの数を確認するのが最善です。現在のダーティ ページの数は/proc/vmstatファイルで確認できます。

cat /proc/vmstat | egrep "dirty|writeback"

3.2.4 ファイルシステム

ログ セグメントの保存にどのファイル システムが使用されるかに関係なく、マウント ポイントの noatime パラメータを適切に設定することが最善です。ファイルのメタデータには、作成時刻 (ctime)、最終変更時刻 (mtime)、および最終アクセス時刻 (atime) の 3 つのタイムスタンプが含まれます。デフォルトでは、ファイルが読み取られるたびに atime が更新されるため、大量のディスク書き込みが発生します。また、ファイルが最後に変更されてからアクセスされたかどうかをアプリケーションが知りたい場合を除き、atime 属性はあまり役に立ちません (リアルタイムを使用)この場合）。Kafka はこのプロパティを使用しないため、完全に無効にすることができます。マウント ポイントの noatime パラメータを設定すると、atime は更新されなくなりますが、ctime と mtime には影響しません。

3.2.5 ネットワーク、Chahaを使用する場合はどうすればよいですか

ネットワーク デフォルトでは、システム カーネルは高速で大量のトラフィックのネットワーク送信用に最適化されていないため、アプリケーションでは通常、高トラフィックのサポートを実現するために Linux システムのネットワーク スタックを調整する必要があります。実際、Kafka のネットワーク構成を調整することは、他のほとんどの Web サーバーやネットワーク アプリケーションのネットワーク構成を調整することと同じです。まず、ソケットの読み取りおよび書き込みバッファーに割り当てられるメモリ サイズを調整できます。これにより、ネットワーク伝送パフォーマンスが大幅に向上します。ソケットの読み取りおよび書き込みバッファーに対応するパラメーターは net.core.wmem_default および net.core.rmem_default で、適切な値は 131 072 (つまり 128KB) です。読み取りバッファーと書き込みバッファーの最大値に対応するパラメーターはそれぞれ net.core.wmem_max と net.core.rmem_max で、適切な値は 2 097 152 (つまり 2MB) です。最大値は、各ソケットに大きなバッファ スペースが必要であることを意味するものではなく、必要な場合にこの値に達することを意味するだけであることに注意してください。ソケットの設定に加えて、TCP ソケットの読み取りおよび書き込みバッファーも設定する必要があります。そのパラメーターは net.ipv4.tcp_wmem および net.ipv4.tcp_rmem です。これらのパラメータの値は、最小値、デフォルト値、および最大値を表す、スペースで区切られた 3 つの整数で構成されます。最大値は、net.core.wmem_max および net.core.rmem_max で指定されたサイズより大きくすることはできません。たとえば、「4096 65536 2048000」は、最小値が 4KB、デフォルト値が 64KB、最大値が 2MB であることを示します。Kafka サーバーが受信する実際のトラフィックに応じて、ネットワーク接続により多くのバッファ領域を提供するために、より高い最大値を設定する必要がある場合があります。他にも便利なネットワーク パラメーターがいくつかあります。たとえば、net.ipv4.tcp_window_scaling を 1 に設定し、TCP タイム ウィンドウ スケーリングを有効にすると、クライアント データ送信の効率が向上し、送信されたデータをサーバー側でバッファリングできます。より多くの同時接続を受け入れるには、net.ipv4.tcp_max_syn_backlog をデフォルト値の 1024 より大きい値に設定します。net.coreを入れます。

コンシューマがオフセットを Kafka サーバーに送信できるようにし、Zookeeper への依存を排除​​するには、Kafka の最新バージョンを使用することをお勧めします。

複数の Kafka クラスターは Zookeeper グループを共有できますが、可能であれば Zookeeper を他のアプリケーションと共有することはお勧めできません。Kafka は Zookeeper の遅延とタイムアウトに敏感であり、Zookeeper グループとの通信異常により Kafka サーバーの予期しない動作が発生する可能性があります。これにより、複数のブローカーが同時にオフラインになることが容易になり、それらが Zookeeper から切断されると、パーティションもオフラインになります。

4. Kafka プロデューサー - Kafka にデータを書き込む

クレジット カード トランザクション処理システムには、支払いが発生するたびにトランザクションを Kafka に送信する役割を担うクライアント アプリケーション (オンライン ストアなど) があります。別のアプリケーションがルール エンジンと照合してトランザクションをチェックし、承認するか拒否するかを決定します。承認または拒否の応答メッセージは Kafka に書き戻され、トランザクションを開始したオンライン ストアに送信されます。3 番目のアプリケーションは、Kafka からトランザクションと監査状態を読み取り、データベースに保存します。アナリストは結果を分析して、ルール エンジンを改善できる可能性があります。

この章では、Kafka プロデューサーの設計とコンポーネントから始めて、Kafka プロデューサーの使用方法を学習します。KafkaProducer オブジェクトとProducerRecords オブジェクトを作成する方法、Kafka にレコードを送信する方法、Kafka から返されたエラーを処理する方法を示し、次にプロデューサーの動作を制御するための重要な構成オプションを紹介し、最後にさまざまなパーティション メソッドとシリアライザーの使用方法とその方法について詳しく説明します。シリアライザーとパーティショナーをカスタマイズします。

サードパーティ クライアントの組み込みクライアントに加えて、Kafka はバイナリ接続プロトコルも提供します。つまり、適切なバイト シーケンスを Kafka ネットワーク ポートに直接送信して、Kafka からメッセージを読み取ったり、Kafka にメッセージを書き込んだりできます。C++、Python、Go など、他の言語で実装された Kafka クライアントも多数あり、それらはすべて Kafka 接続プロトコルを実装しているため、Kafka の使用は Java に限定されません。これらのクライアントは Kafka プロジェクトの一部ではありませんが、利用可能なすべてのクライアントのリストが Kafka プロジェクト Wiki にあります。

4.1 プロデューサーの概要

シナリオを使用して要件を区別する

アプリケーションは多くの場合、ユーザー アクティビティの記録 (監査と分析のため)、メトリクスの記録、ログ メッセージの保存、スマート ホーム アプライアンスに関する情報の記録、他のアプリケーションとの通信、非同期通信、約データベースに書き込まれるなど。使用シナリオが多様であるということは、要件も多様であることを意味します。すべてのメッセージは重要ですか? メッセージの一部が失われることは許容されますか? 時折メッセージが重複することは許容されますか? レイテンシーとスループットに関する厳しい要件はありますか? 前述のクレジット カード トランザクション処理システムでは、メッセージの損失やメッセージの重複は許可されず、許容される遅延は最大 500 ミリ秒であり、これには高いスループットが必要です。私たちは 1 秒あたり 100 万件のニュースを処理したいと考えています。

Web サイトのクリック情報を保存することも使用例です。このシナリオでは、ユーザー エクスペリエンスが影響を受けない限り、少数のメッセージの損失または繰り返しが許容され、遅延が長くなる可能性があります。言い換えれば、ユーザーがリンクをクリックした直後にページが読み込まれる限り、メッセージが Kafka サーバーに到達するまでに数秒かかっても気にしません。スループットは、Web サイト ユーザーが Web サイトを使用する頻度によって異なります。さまざまな使用シナリオは、プロデューサー API の使用法と構成に直接影響します。

プロセス

ProducerRecord オブジェクトの送信 ------ シリアル化 ------>> パーティショナー --->> トピックへの起動 -->>

メッセージが Kafka に正常に書き込まれると、RecordMetaData オブジェクトが返されます。このオブジェクトには、トピックとパーティションの情報、およびパーティション内のレコードのオフセットが含まれます。書き込みに失敗した場合は、エラーが返されます。プロデューサーはエラーを受信した後、メッセージの再送信を試みますが、数回繰り返しても失敗する場合は、エラー メッセージを返します。