5.2. データの持続性
メッセージ配信の確認は、メッセージが失われる可能性を最小限に抑えます。acks プロパティーが acks=all に設定されている場合、確認レスポンスはデフォルトで有効になっています。
メッセージ配信の承認
# ...
acks=all 1
# ...
- 1
acks=allを指定すると、リーダーレプリカが強制的に、特定数のフォロワーに対するメッセージを複製してから、メッセージリクエストが正常に受信されたことを確認します。
acks=all 設定は、最も強力な配信保証を提供しますが、プロデューサーがメッセージを送信して確認レスポンスを受け取るまでの待ち時間が長くなります。このような強力な保証が必要ない場合は、acks=0 または acks=1 を設定すると、配信が保証されないか、リーダーレプリカがログにレコードを書き込んだことを確認するだけになります。
acks=all を使用すると、リーダーはすべての同期レプリカがメッセージ配信を確認するまで待機します。トピックの min.insync.replicas 設定は、同期レプリカの確認レスポンスに必要な最小数を設定します。確認レスポンスの数には、リーダーとフォロワーが含まれます。
一般的に、以下の設定を使用して操作を開始します。
プロデューサーの設定:
-
acks=all(デフォルト)
-
トピックレプリケーションのブローカー設定:
-
default.replication.factor=3(default =1) -
min.insync.replicas=2(default =1)
-
トピックの作成時に、デフォルトのレプリケーション係数をオーバーライドできます。また、トピック設定のトピックレベルで min.insync.replicas を上書きすることもできます。
AMQ Streams は、Kafka のマルチノードデプロイメントの例の設定ファイルを使用します。
以下の表は、リーダーレプリカを複製するフォロワーの可用性に応じてこの設定がどのように動作するかを示しています。
表5.1 フォロワーの可用性
| 利用可能なフォロワーと同期しているフォロワーの数 | 確認 | プロデューサーがメッセージを送信できるか? |
|---|---|---|
| 2 | リーダーは、フォロワー 2 つからの確認レスポンスを待つ | あり |
| 1 | リーダーは、フォロワー 1 つからの確認を待つ | あり |
| 0 | リーダーが例外を発生させる | いいえ |
トピックのレプリケーション係数が 3 の場合は、1 つのリーダーレプリカと 2 つのフォロワーが作成されます。この設定では、1 つのフォロワーが利用できない場合にプロデューサーはそのまま続行できます。in-sync レプリカから障害のあったブローカーを削除している間または、新しいリーダーを作成している間に、遅延が生じる可能性があります。2 つ目のフォロワーも利用できない場合、メッセージ配信は成功しません。リーダーは、メッセージ配信の成功を確認する代わりに、エラー (not enough replicas) をプロデューサーに送信します。プロデューサーは同等の例外を発生させます。retries 設定を使用すると、プロデューサーは失敗したメッセージリクエストを再送信できます。
システムに障害が発生すると、バッファーの未送信データが失われる可能性があります。