1. 製作者確認の仕組み
メッセージはプロデューサー クライアントからブローカー サーバー トピックに送信され、ACK 確認が必要です。acks
およびmin.insync.replicas
の 2 つの設定パラメータです。その中には、acks
プロデューサの設定パラメータとmin.insync.replicas
ブローカーの設定パラメータが含まれます。これら 2 つのパラメータは、プロデューサのデータ損失を防ぐ上で大きな役割を果たします。
ISR
同期レプリカ (ISR) は同期レプリカと呼ばれ、ISR 内のレプリカはすべてリーダーと同期しているレプリカであるため、リストにないフォロワーはリーダーと同期していないと見なされます。同期されたレプリカのリストは動的であり、レプリカとリーダー間の同期に基づいて動的に追加および削除されます。
acks確認メカニズム
acks パラメーターは、プロデューサがメッセージが正常に書き込まれたとみなす前に、メッセージを受信する必要があるパーティション レプリカの数を指定します。
-
acks=0 は、プロデューサーがメッセージを正常に書き込む前にサーバーからの応答を待たないことを意味します。つまり、問題が発生してサーバーがメッセージを受信しないと、プロデューサーはメッセージを知る方法がありません。失われます。
-
acks=1 は、クラスターのリーダー パーティション コピーがメッセージを受信している限り、成功した応答 ack をプロデューサーに送信することを意味します。この時点で、プロデューサーは ack を受信した後、メッセージが正常に書き込まれたとみなすことができます。メッセージを書き込むことができなくなると、リーダー パーティションのコピーに入ると (ネットワーク上の理由、リーダー ノードのクラッシュなど)、プロデューサーはエラー応答を受け取ります。
-
acks =all, これは、レプリケーションに参加しているすべてのノード (ISR リストのコピー) がメッセージを受信した場合にのみ、プロデューサーがサーバーから応答を受信することを意味します。このモードは最高レベルで最も安全であり、A 以上のことを保証します。ブローカーがメッセージを受信します。このモードでは待ち時間が長くなります。
メッセージ送信については、同期ブロッキングと非同期コールバックの 2 つの方法がサポートされており、アプリケーションのスループットを向上させるために、通常は後者を使用することをお勧めします。
2. 消費者確認の仕組み
Kafka では、コンシューマの置換の送信を通じてコンシューマの確認が実装されます。RabbitMQ の ACK メカニズムに似ています。
消費者の移動
各コンシューマ インスタンスは、現在消費されているメッセージの数を記録するために、消費するパーティションに関する独自の位置情報を保持します。これには、Kafka ではオフセットという固有の用語があります。
サーバー側(ブローカー)でオフセットを保存する場合と比較すると、簡単ではありますが以下のような問題があります。
-
ブローカーがステートフルになるため、同期コストが増加し、スケーラビリティに影響します。
-
消費の成功を判断するには、応答メカニズムを導入する必要があります。
-
多くのコンシューマのオフセットを保存する必要があるため、複雑なデータ構造を導入する必要がある場合があり、これによりリソースがある程度無駄になります。
Kafka では、Consumer Group が消費メッセージの管理と配布を担当するため、Consumer Group にオフセットを保存することがより適切な選択です。データ形式は特定形式の整数データであれば十分です。
オフセットはメッセージ配信セマンティクスの基礎であるため、コンシューマーにとって非常に重要です。
メッセージ配信セマンティクスは、最大 1 回、少なくとも 1 回、および正確に 1 回です。
ディスプレイスメントの提出
コンシューマー クライアントは、データ消費の進行状況を定期的に Kafka クラスターに報告する必要があります。このプロセスはオフセット コミットと呼ばれます。ディスプレイスメントの送信は、消費者にとって非常に重要であり、消費者側の消費の進捗を表すだけでなく、消費者側の消費の意味論的保証を直接決定します。
Kafka の新しいバージョンは、送信されたオフセットをトピック (__consumer_offsets) によって管理します。デフォルトは 50 のパーティションで、0 ~ 49 の番号が付けられます。
各オフセット送信リクエストは、__consumer_offsets の対応するパーティションにメッセージをさらに書き込みます。メッセージのキーは、group.id、トピック、パーティションのタプルであり、値はディスプレイスメント値です。
投稿方法
デフォルトでは、コンシューマはディスプレイスメントを自動的に送信し、自動送信間隔は 5 秒です。これは、特定の設定が行われていない場合、コンシューマー プログラムがバックグラウンドでディスプレイスメントを自動的に送信することを意味します。自動送信の間隔は、auto.commit.interval.ms パラメータを設定することで制御できます。
手動によるディスプレイスメントの送信とは、メッセージが実際に処理されるタイミングをユーザーが決定し、ディスプレイスメントを送信できることを意味します。一般的なコンシューマー アプリケーションのシナリオでは、ユーザーは、poll メソッドによって返されたメッセージ コレクション内のメッセージに対してビジネス レベルの処理を実行する必要があります。ユーザーは、ディスプレイスメントを送信する前に、メッセージのみが実際に処理されることを確認したいと考えています。自動オフセットコミットを使用する場合、このタイミングは保証できないため、この場合は手動オフセットコミットを使用する必要があります。手動コミット オフセットの設定は非常に簡単で、KafkaConsumer のビルド時にenable.auto.commit=false を設定し、commitSync メソッドまたは commitAsync メソッドを呼び出すだけです。
両者の違い、メリット、デメリットは以下の通りです。