Kafka レプリカ間のデータ同期を実現するにはどうすればよいですか?

みなさんこんにちは、私は仙宇です

最近かなり忙しくて、1週間近く記事を更新していませんでした。もう更新しないと、数少ないファンが離れてしまいますT﹏T

最近たまたまKafkaを勉強していたので、Kafka関連の記事を書くことにしました（記事に間違いがあれば指摘してください）

皆さんの中には Kafka を初めて知る人もいるかもしれないので、Kafka とは何かを簡単に紹介したいと思います。

Kafka の紹介

Kafka は、従来のメッセージ キュー (RaabitMQ、RocketMQ など) のように非同期処理、トラフィック ピークの排除、サービス分離をサポートするだけでなく、高スループットの分散メッセージング システムでもあります。

写真

バッチ処理のためにメッセージをディスクに保存することも可能です。さらに、Kafka は分散システムとして設計されているため、スループットと可用性が大幅に向上します。

Kafka ロール

• Kafka クライアント

プロデューサー: パブリッシャーとも呼ばれ、メッセージの作成を担当します

コンシューマー: サブスクライバーとも呼ばれ、メッセージの消費（読み取り）を担当します。

• Kafka サーバー (ブローカー)

• リーダー: 外部の読み取りおよび書き込みサービスを提供する

• フォロワー: サービスを提供しませんが、リーダーとデータを同期する責任があります

トピックとパーティション

トピックはメッセージが公開される場所です。コンシューマーはトピックをサブスクライブすることで対応するメッセージを消費します。

スループットを向上させ、トピックの負荷分散を実現するために、Kafka ではトピックの下にパーティションの概念が導入されています。各トピックは複数のパーティションに分割できます。

パーティションを使用すると、メッセージをトピックの下に水平に分割して保存できます。各パーティションは順序付けられた不変のメッセージ キューです。コンシューマーは同じトピックからのメッセージを並行して消費できます。

PS: トピックは論理的な概念であり、メッセージは実際にはパーティションに保存されます。

写真

たとえば、トピックが n 個のパーティションに分割されている場合、トピックの同時実行性は n 増加し、n 人のコンシューマーがトピック内のメッセージを並行して消費できるようになります。

ログ

各トピックごとに、Kafkaはパーティションログを維持します。

写真

各パーティションは、メッセージを継続的に追加できる、順序付けられた不変のメッセージ キューです。メッセージには、オフセットと呼ばれるパーティション内の一意のシーケンス番号が割り当てられます。

オフセットは、パーティション内の各レコードを一意に識別するために使用されます。

Kafka はすべてのパーティションにメッセージを保持し、メッセージを自動的に削除しません。メッセージ保持ポリシーは、Kafka 構成パラメータによって制御されます。メッセージは、一定期間が経過するか、または一定のサイズに達すると期限切れになることがあります。期限切れのメッセージは削除されます。

コンシューマーは、パーティション内の位置を識別するために、Kafka に独自のオフセットのみを保持します。通常、コンシューマーがメッセージを消費すると、そのオフセットは直線的に増加し、これらのメッセージが消費されたことを示します。

コンシューマーは、オフセットを古い値にリセットして、メッセージの読み取りを再開することを選択できます。

各コンシューマー インスタンスは 1 つのパーティションを担当します。 Kafka は、トピック内の異なるパーティションの順序ではなく、パーティション内のレコードの順序を保証するだけです。

Kafka クラスター

Kafka はクラスターの概念を備えた分散アーキテクチャです。

Kafka のインスタンスはブローカーと呼ばれ、プロデューサーからメッセージを受信して​​ディスクに保存します。コンシューマーはブローカーに接続してメッセージを消費します。

複数のブローカーが Kafka クラスターを形成します。クラスター内のブローカーはクラスター コントローラーとなり、ブローカーへのパーティションの割り当て、ブローカーの監視など、Kafka クラスター全体の管理を担当します。

パーティションは複数のレプリカに複製され、異なるブローカーに均等に分散されます。そのうちの 1 つがリーダーで、その他はフォロワーです。

レプリカを作成する単位はトピックパーティションです

通常、各パーティションにはリーダーと 0 個以上のフォロワーが存在します。この方法では、ブローカーに障害が発生しても、他のブローカーのレプリカが引き続きサービスを提供できます。

写真

では、すべてのレプリカを異なるブローカーに均等に分散するにはどうすればよいでしょうか?

レプリカを割り当てるアルゴリズムは次のとおりです。

• すべてのブローカー（合計でn個のブローカーがあると仮定）と割り当てるパーティションをソートする
• i番目のパーティションを(i mod n)番目のブローカーに割り当てる
• i番目のパーティションのj番目のレプリカを((i + j)モードn)番目のブローカーに割り当てる

Kafka はどのようにしてデータ同期を実現するのでしょうか?

まず、KafkaのISR（In-Sync Replicas）メカニズムを見てみましょう。

各リーダーには少なくとも 1 つのフォロワーが存在するため、Kafka によって動的に維持される同期レプリカのセットである ISR が存在します。

ISR 内のすべてのフォロワーはリーダーと同期され、リーダーも ISR リストに含まれます。リーダー選出に参加できるのは、自身の ISR リスト内のレプリカのみです。

プロデューサーがデータを書き込むと、リーダーがデータを更新します。フォロワーは、リーダーがデータを更新し、データを同期したことをどのようにして知るのでしょうか?

フォロワーは、フェッチ要求をリーダーに定期的に送信してデータを同期します。これはフェッチャー スレッドの役割です。

レプリカがフォロワーとして選出されると、レプリカのフェッチャー スレッドが開始されます。フォロワーは、接続を維持するためにリーダーに定期的にハートビート要求を送信し、最新のデータを取得するためにフェッチ要求を送信します。

フォロワーは、自身の LEO (ログ終了オフセット) がリーダーの LEO と異なることを検出した場合、リーダーのデータとの一貫性を確保するために、自身のログをリーダーの対応する位置に同期するためのデータ同期要求をトリガーします。

フォロワーがフェッチ要求を送信しないか、指定された時間内にリーダーのLEOに追いつかない場合（設定フィールドはreplica.lag.time.max.ms）、ISRから削除されます。

最後にまとめます。

• Kafka におけるトピックは論理的な概念です。各トピックは複数のパーティションに分割でき、パーティションはメッセージを保存するエンティティです。
• 各パーティションは複数のコピーに複製され、コピーの 1 つがリーダーとして選択され、残りはフォロワーになります。
• フォロワーは定期的にリーダーにフェッチリクエストを送信し、データの同期を確実にします。
• リーダーはフォロワーのデータが同期されているかどうかを気にしません。指定された時間内に私にフェッチを依頼しない限り、私はあなたを ISR から外します (積極的であることは悪いことではないことがわかりました)