5.2. データの持続性

メッセージ配信の確認は、メッセージが失われる可能性を最小限に抑えます。デフォルトでは、acks プロパティーを acks=all に設定すると確認が有効になります。プロデューサーがブローカーによる確認を待機する最大時間を制御し、メッセージ送信の潜在的な遅延に対処するには、delivery.timeout.ms プロパティーを使用できます。

# ...
acks=all 1
delivery.timeout.ms=120000 2
# ...

acks=all 設定は、最も強力な配信保証を提供しますが、プロデューサーがメッセージを送信して確認レスポンスを受け取るまでの待ち時間が長くなります。このような強力な保証が必要ない場合は、acks=0 または acks=1 を設定すると、配信が保証されないか、リーダーレプリカがログにレコードを書き込んだことを確認するだけになります。

acks=all を使用すると、リーダーはすべての同期レプリカがメッセージ配信を確認するまで待機します。トピックの min.insync.replicas 設定は、同期レプリカの確認レスポンスに必要な最小数を設定します。確認レスポンスの数には、リーダーとフォロワーが含まれます。

一般的に、以下の設定を使用して操作を開始します。

トピックの作成時に、デフォルトのレプリケーション係数をオーバーライドできます。また、トピック設定のトピックレベルで min.insync.replicas を上書きすることもできます。

Streams for Apache Kafka は、Kafka のマルチノードデプロイメントの例の設定ファイルを使用します。

以下の表は、リーダーレプリカを複製するフォロワーの可用性に応じてこの設定がどのように動作するかを示しています。

トピックのレプリケーション係数が 3 の場合は、1 つのリーダーレプリカと 2 つのフォロワーが作成されます。この設定では、1 つのフォロワーが利用できない場合にプロデューサーはそのまま続行できます。in-sync レプリカから障害のあったブローカーを削除している間または、新しいリーダーを作成している間に、遅延が生じる可能性があります。2 つ目のフォロワーも利用できない場合、メッセージ配信は成功しません。リーダーは、メッセージ配信の成功を確認する代わりに、エラー (not enough replicas) をプロデューサーに送信します。プロデューサーは同等の例外を発生させます。retries 設定を使用すると、プロデューサーは失敗したメッセージリクエストを再送信できます。