5.2. データの持続性

メッセージ配信の確認は、メッセージが失われる可能性を最小限に抑えます。acks プロパティーが acks=all に設定されている場合、確認応答はデフォルトで有効になっています。

# ...
acks=all 

# ...

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

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

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

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

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

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

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