В 前の記事 耐障害性と高可用性を実現するために、RabbitMQ クラスタリングを検討しました。 それでは、Apache Kafka について詳しく見てみましょう。

ここで、レプリケーションの単位はパーティションです。 各トピックには 3 つ以上のセクションがあります。 各セクションには、フォロワーの有無にかかわらずリーダーがいます。 トピックを作成するときは、パーティションの数とレプリケーション係数を指定します。 通常の値は XNUMX で、これは XNUMX つのレプリカ (XNUMX つのリーダーと XNUMX つのフォロワー) を意味します。

米。 1. XNUMX つのセクションが XNUMX つのブローカーに分散されています

すべての読み取りおよび書き込みリクエストはリーダーに送られます。 フォロワーは定期的にリーダーにリクエストを送信し、最新のメッセージを受信します。 消費者はフォロワーに頼ることはありません。後者は冗長性とフォールト トレランスのためにのみ存在します。

パーティション障害

ブローカーが失敗すると、多くの場合、いくつかのセクションのリーダーも失敗します。 それぞれのノードで、別のノードからのフォロワーがリーダーになります。 実際には、常にそうとは限りません。同期係数も影響します。同期されたフォロワーがあるかどうか、ない場合は非同期レプリカへの切り替えが許可されるかどうかです。 しかし、今は物事を複雑にするのはやめましょう。

ブローカー 3 がネットワークを離れ、ブローカー 2 でセクション 2 の新しいリーダーが選出されます。

米。 2. ブローカー 3 が死亡し、ブローカー 2 のフォロワーがパーティション 2 の新しいリーダーとして選出されます。

その後、ブローカー 1 が去り、セクション 1 もリーダーを失い、その役割はブローカー 2 に引き継がれます。

米。 3. ブローカーが XNUMX 人残っています。 すべてのリーダーは冗長性のない XNUMX つのブローカー上にあります

ブローカー 1 がオンラインに戻ると、2 つのフォロワーが追加され、各パーティションにある程度の冗長性が提供されます。 しかし、すべてのリーダーは依然としてブローカー XNUMX に残りました。

米。 4. リーダーはブローカー 2 に残ります

ブローカー 3 が起動すると、パーティションごとに 2 つのレプリカに戻ります。 しかし、すべてのリーダーはまだブローカー XNUMX にいます。

米。 5. ブローカー 1 と 3 の修復後のリーダーのアンバランスな配置

Kafka には、RabbitMQ よりも優れたリーダーのリバランスを行うツールがあります。 そこでは、移行中の冗長性を削減することでマスター ノードの移行ポリシーを変更するサードパーティのプラグインまたはスクリプトを使用する必要がありました。 さらに、キューが大きい場合は、同期中に利用できないことを受け入れる必要がありました。

Kafka には、リーダーの役割に「優先レプリカ」という概念があります。 トピック パーティションが作成されると、Kafka はリーダーをノード間で均等に分散しようとし、最初のリーダーを優先としてマークします。 時間の経過とともに、サーバーの再起動、障害、接続の切断により、上記の極端なケースのように、リーダーが他のノードに移動する可能性があります。

これを修正するために、Kafka は XNUMX つのオプションを提供します。

• オプション auto.leader.rebalance.enable=true これにより、コントローラー ノードがリーダーを優先レプリカに自動的に再割り当てし、均一な分散を復元できるようになります。
• 管理者はスクリプトを実行できます kafka-preferred-replica-election.sh 手動での再割り当ての場合。

米。 6. リバランス後のレプリカ

これは失敗の簡略化されたバージョンですが、ここではそれほど複雑なことはありませんが、現実はさらに複雑です。 すべては同期レプリカ (In-Sync Replica、ISR) に帰着します。

同期レプリカ (ISR)

ISR は、「同期」 (同期中) とみなされるパーティションのレプリカのセットです。 リーダーはいるが、フォロワーはいないかもしれない。 フォロワーは、間隔が終了する前にすべてのリーダーのメッセージの正確なコピーを作成した場合、同期しているとみなされます。 レプリカ.ラグ時間.最大ミリ秒.

次の場合、フォロワーは ISR セットから削除されます。

• 間隔を選択するリクエストを行いませんでした レプリカ.ラグ時間.最大ミリ秒 (死亡したと思われる)
• 間隔中に更新できませんでした レプリカ.ラグ時間.最大ミリ秒 (遅いと考えられます)

フォロワーは間隔内でサンプリングリクエストを行います レプリカ.fetch.wait.max.ms、デフォルトは 500 ミリ秒です。

ISR の目的を明確に説明するには、プロデューサーからの確認といくつかの失敗シナリオを検討する必要があります。 プロデューサーは、ブローカーがいつ確認を送信するかを選択できます。

• acks=0、確認は送信されません
• acks=1、リーダーがローカル ログにメッセージを書き込んだ後に確認が送信されます。
• acks=all、ISR 内のすべてのレプリカがメッセージをローカル ログに書き込んだ後に確認が送信されます。

Kafka の用語では、ISR がメッセージを保存した場合、そのメッセージは「コミット」されます。 Acks=all は最も安全なオプションですが、追加の遅延も発生します。 失敗の XNUMX つの例と、さまざまな「ack」オプションが ISR の概念とどのように相互作用するかを見てみましょう。

Acks=1 および ISR

この例では、リーダーがすべてのフォロワーからのすべてのメッセージが保存されるまで待機しない場合、リーダーが失敗した場合にデータが失われる可能性があることがわかります。 同期されていないフォロワーへの移動は、設定によって有効または無効にできます。 unclean.leader.election.enable.

この例では、製造元の値は acks=1 です。 このセクションは 3 つのブローカーすべてに分散されています。 ブローカー 7456 は遅れており、1 秒前にリーダーと同期し、現在 XNUMX メッセージ遅れています。 ブローカー XNUMX はわずか XNUMX 秒遅れでした。 プロデューサーはメッセージを送信し、リーダーが待機していない遅いフォロワーや停止したフォロワーのオーバーヘッドなしで、すぐに ack を返します。

米。 7. XNUMX つのレプリカを持つ ISR

ブローカー 2 が失敗し、プロデューサーは接続エラーを受け取ります。 リーダーがブローカー 1 に渡された後、123 個のメッセージが失われます。 ブローカー 1 のフォロワーは ISR の一部でしたが、リーダーが落ちたときにリーダーと完全には同期していませんでした。

米。 8. クラッシュするとメッセージが失われる

構成中 ブートストラップ.サーバー メーカーには複数の仲介業者がリストされており、別の仲介業者に誰が新しいセクションリーダーになるかを尋ねることができます。 次に、ブローカー 1 への接続を確立し、メッセージの送信を続けます。

米。 9. 短い休憩の後、メッセージの送信を再開します

ブローカー 3 はさらに遅れています。 フェッチリクエストを行いますが、同期できません。 これは、ブローカー間のネットワーク接続の遅さ、ストレージの問題などが原因である可能性があります。ISR から削除されます。 現在、ISR は XNUMX つのレプリカ、つまりリーダーで構成されています。 メーカーは引き続きメッセージを送信し、確認を受け取ります。

米。 10. ブローカー 3 のフォロワーが ISR から削除されます

ブローカー 1 がダウンし、リーダーの役割はブローカー 3 に移り、15286 個のメッセージが失われます。 メーカーは接続エラー メッセージを受け取ります。 ISR の外のリーダーへの移行は、設定によってのみ可能でした unclean.leader.election.enable=true。 にインストールされている場合 falseの場合、遷移は発生せず、すべての読み取りおよび書き込みリクエストが拒否されます。 この場合、ブローカー 1 がレプリカにそのままのデータを持って戻ってくるのを待ち、ブローカー XNUMX が再びリーダーシップを引き継ぎます。

米。 11. ブローカー 1 がフォールします。 障害が発生すると、大量のメッセージが失われます

プロデューサーは最後のブローカーとの接続を確立し、彼が現在セクションのリーダーであることを確認します。 彼はブローカー 3 へのメッセージの送信を開始します。

米。 12. 短い休憩の後、メッセージが再びセクション 0 に送信されます。

新しい接続を確立したり、新しいリーダーを探したりするための短時間の中断を除けば、メーカーが継続的にメッセージを送信していることがわかりました。 この構成では、一貫性 (データ セキュリティ) を犠牲にして可用性を確保します。 Kafka は何千ものメッセージを失いましたが、新しい書き込みを受け入れ続けました。

Acks=all および ISR

このシナリオをもう一度繰り返してみましょう。 acks=すべて。 ブローカー 3 の平均遅延は XNUMX 秒です。 メーカーは次のようなメッセージを送信します acks=すべて、現在は迅速な応答が得られません。 リーダーは、ISR 内のすべてのレプリカによってメッセージが保存されるのを待ちます。

米。 13. XNUMX つのレプリカを持つ ISR。 XNUMX つは遅いため、録音に遅れが生じます

さらに 2 秒の遅延が発生した後、ブローカー XNUMX は ACK を送信します。 すべてのレプリカが完全に更新されました。

米。 14. すべてのレプリカがメッセージを保存し、ACK を送信します。

ブローカー 3 はさらに遅れをとり、ISR から削除されます。 ISR には遅いレプリカが残らないため、遅延が大幅に短縮されます。 ブローカー 2 はブローカー 1 のみを待機し、平均 500 ミリ秒の遅延があります。

米。 15. ブローカー 3 上のレプリカが ISR から削除されます

その後、ブローカー 2 がダウンし、メッセージを失うことなくリーダーシップがブローカー 1 に移ります。

米。 16. ブローカー 2 が落ちる

メーカーは新しいリーダーを見つけ、彼にメッセージを送り始めます。 ISR が XNUMX つのレプリカで構成されているため、遅延はさらに短縮されます。 したがって、オプションは acks=すべて 冗長性は追加されません。

米。 17. ブローカー 1 のレプリカがメッセージを失わずに主導権を握る

その後、ブローカー 1 がクラッシュし、リードはブローカー 3 になり、14238 個のメッセージが失われます。

米。 18. ブローカー 1 が死亡し、不潔な設定でリーダーシップが移行した結果、大規模なデータ損失が発生

オプションを装着できませんでした unclean.leader.election.enable 意味に true。 デフォルトでは次のようになります false。 設定 acks=すべて с unclean.leader.election.enable=true 追加のデータセキュリティを備えたアクセシビリティを提供します。 ただし、ご覧のとおり、メッセージが失われる可能性は依然としてあります。

しかし、データのセキュリティを強化したい場合はどうすればよいでしょうか? 置くことができます unclean.leader.election.enable = false, しかし、これは必ずしもデータ損失から私たちを守るわけではありません。 リーダーが激しく転倒してデータを持ち去った場合、メッセージは依然として失われ、管理者が状況を復元するまで可用性も失われます。

すべてのメッセージが冗長であることを確認し、そうでない場合は録音を破棄することをお勧めします。 したがって、少なくともブローカーの観点からは、データ損失が発生する可能性があるのは、XNUMX つ以上の障害が同時に発生した場合のみです。

Acks=all、min.insync.replicas、ISR

トピック構成あり min.insync.レプリカ データセキュリティのレベルを向上させています。 前のシナリオの最後の部分をもう一度見てみましょう。ただし、今回は次のようになります。 min.insync.replicas=2.

したがって、ブローカー 2 にはレプリカ リーダーがあり、ブローカー 3 のフォロワーは ISR から削除されます。

米。 19. XNUMX つのレプリカからの ISR

ブローカー 2 がダウンし、メッセージを失うことなくリーダーシップがブローカー 1 に移ります。 ただし、現在、ISR は XNUMX つのレプリカのみで構成されています。 これはレコードを受信するための最小数を満たしていないため、ブローカーは書き込み試行に対してエラーで応答します。 レプリカが足りない.

米。 20. ISR の数が min.insync.replicas で指定された数より XNUMX つ少ない

この構成では、一貫性のために可用性が犠牲になります。 メッセージを確認する前に、メッセージが少なくとも 5 つのレプリカに書き込まれることを確認します。 これにより、メーカーはさらに大きな自信を得ることができます。 ここで、メッセージ損失が発生する可能性があるのは、メッセージが追加のフォロワーにレプリケートされるまでの短い間隔で XNUMX つのレプリカが同時に失敗した場合のみですが、その可能性は低いです。 ただし、非常に偏執的な場合は、レプリケーション係数を XNUMX に設定することもできます。 min.insync.レプリカ by 3. ここで記録を失うには、XNUMX 人のブローカーが同時に倒れる必要があります。 もちろん、この信頼性の代償として追加の遅延が発生します。

データセキュリティのためにアクセシビリティが必要な場合

同様に RabbitMQ を使用した場合、データセキュリティのためにアクセシビリティが必要な場合があります。 考慮する必要があるのは次のとおりです。

• 発行者は単純にエラーを返し、上流のサービスまたはユーザーに後で再試行させることはできますか?
• 発行者はメッセージをローカルまたはデータベースに保存して、後で再試行できますか?

答えが「いいえ」の場合、可用性を最適化することでデータのセキュリティが向上します。 記録しない代わりに可用性を選択すると、失われるデータが少なくなります。 したがって、すべてはバランスを見つけることになり、決定は特定の状況に依存します。

ISRの意味

ISR スイートを使用すると、データ セキュリティと遅延の間の最適なバランスを選択できます。 たとえば、大部分のレプリカで障害が発生した場合の可用性を確保し、待機時間の観点から、停止したレプリカや遅いレプリカの影響を最小限に抑えます。

私たちは自分たちで意味を選びます レプリカ.ラグ時間.最大ミリ秒 あなたのニーズに応じて。 本質的に、このパラメータは、どのくらいの遅延を許容できるかを意味します。 acks=すべて。 デフォルト値は XNUMX 秒です。 これが長すぎる場合は、短縮できます。 その後、フォロワーの削除と追加がより頻繁に行われるため、ISR の変更の頻度が増加します。

RabbitMQ は、単に複製する必要があるミラーのセットです。 ミラーが遅いと追加の遅延が発生し、デッドミラーは各ノードの可用性 (ネットティック) をチェックするパケットが応答するまで待機する可能性があります。 ISR は、これらの遅延の問題を回避する興味深い方法です。 ただし、ISR はリーダーまでしか縮小できないため、冗長性が失われるリスクがあります。 このリスクを回避するには、次の設定を使用します。 min.insync.レプリカ.

クライアント接続保証

設定で ブートストラップ.サーバー プロデューサーとコンシューマーは、クライアントを接続するために複数のブローカーを指定できます。 これは、XNUMX つのノードがダウンしても、クライアントが接続を開くことができる予備のノードがいくつか残るという考えです。 これらは必ずしもセクション リーダーである必要はなく、単に初期負荷の出発点にすぎません。 クライアントは、どのノードが読み取り/書き込みパーティション リーダーをホストしているかを尋ねることができます。

RabbitMQ では、クライアントは任意のノードに接続でき、内部ルーティングによって要求が必要な場所に送信されます。 これは、RabbitMQ の前にロード バランサーをインストールできることを意味します。 Kafka では、クライアントが対応するパーティション リーダーをホストするノードに接続する必要があります。 このような状況では、ロードバランサーをインストールすることはできません。 リスト ブートストラップ.サーバー 障害後にクライアントが正しいノードにアクセスして見つけることができることが重要です。

Kafka コンセンサス アーキテクチャ

これまで、クラスターがブローカーの崩壊をどのように学習するのか、また新しいリーダーがどのように選出されるのかについては考慮していませんでした。 Kafka がネットワーク パーティションでどのように動作するかを理解するには、まずコンセンサス アーキテクチャを理解する必要があります。

各 Kafka クラスターは、可用性よりも一貫性を優先して、システムが特定の状態について合意に達することを可能にする分散型コンセンサス サービスである Zookeeper クラスターとともにデプロイされます。 読み取りおよび書き込み操作を承認するには、Zookeeper ノードの大多数の同意が必要です。

Zookeeper はクラスターの状態を保存します。

• トピック、セクション、構成、現在のリーダー レプリカ、優先レプリカのリスト。
• クラスターのメンバー。 各ブローカーは Zookeeper クラスターに ping を送信します。 指定された期間内に ping を受信しない場合、Zookeeper はブローカーを使用不可として記録します。
• コントローラーのメイン ノードとスペア ノードを選択します。

コントローラー ノードは、レプリカ リーダーの選出を担当する Kafka ブローカーの XNUMX つです。 Zookeeper は、クラスターのメンバーシップとトピックの変更に関する通知をコントローラーに送信し、コントローラーはこれらの変更に応じて動作する必要があります。

たとえば、3 個のパーティションと XNUMX のレプリケーション係数を持つ新しいトピックを考えてみましょう。コントローラーは、ブローカー間でリーダーを最適に分散しようとして、パーティションごとにリーダーを選択する必要があります。

各セクションコントローラーについて:

• ISR とリーダーに関する Zookeeper の情報を更新します。
• このパーティションのレプリカをホストする各ブローカーに LeaderAndISRCommand を送信し、ISR とリーダーについてブローカーに通知します。

リーダーを持つブローカーが倒れると、Zookeeper はコントローラーに通知を送信し、新しいリーダーを選出します。 ここでも、コントローラーは最初に Zookeeper を更新し、次に各ブローカーにリーダーの変更を通知するコマンドを送信します。

各リーダーは ISR を採用する責任があります。 設定 レプリカ.ラグ時間.最大ミリ秒 そこに誰が入るかを決定します。 ISR が変更されると、リーダーは新しい情報を Zookeeper に送信します。

Zookeeper には変更が常に通知されるため、障害が発生した場合でも管理は新しいリーダーにスムーズに移行します。

米。 21. カフカのコンセンサス

レプリケーションプロトコル

レプリケーションの詳細を理解することは、潜在的なデータ損失シナリオをより深く理解するのに役立ちます。

サンプリング クエリ、ログ エンド オフセット (LEO) およびハイウォーター マーク (HW)

フォロワーが定期的にリーダーにフェッチリクエストを送信すると考えました。 デフォルトの間隔は 500 ミリ秒です。 これは、RabbitMQ ではレプリケーションがキュー ミラーではなくマスターによって開始されるという点で RabbitMQ とは異なります。 マスターは変更をミラーにプッシュします。

リーダーとすべてのフォロワーは、Log End Offset (LEO) と Highwater (HW) ラベルを保存します。 LEO マークはローカル レプリカ内の最後のメッセージのオフセットを保存し、HW は最後のコミットのオフセットを保持します。 コミット ステータスの場合、メッセージはすべての ISR レプリカにわたって保持される必要があることに注意してください。 これは、通常、LEO が HW よりわずかに進んでいることを意味します。

リーダーはメッセージを受信すると、それをローカルに保存します。 フォロワーは自分の LEO を送信することでフェッチ要求を行います。 次に、リーダーはこの LEO から始まるメッセージのバッチを送信し、現在の HW も送信します。 リーダーは、すべてのレプリカが指定されたオフセットにメッセージを格納したという情報を受け取ると、HW マークを移動します。 リーダーのみが HW を移動できるため、すべてのフォロワーはリクエストに対する応答の現在の値を知ることになります。 これは、フォロワーがメッセージとハードウェア知識の両方においてリーダーに遅れる可能性があることを意味します。 コンシューマは現在の HW までのメッセージのみを受信します。

「永続化」とは、ディスクではなくメモリに書き込まれることを意味することに注意してください。 パフォーマンスを向上させるために、Kafka は特定の間隔でディスクと同期します。 RabbitMQ にもそのような間隔がありますが、マスターとすべてのミラーがメッセージをディスクに書き込んだ後でのみ、パブリッシャーに確認応答が送信されます。 Kafka 開発者は、パフォーマンス上の理由から、メッセージがメモリに書き込まれたらすぐに ack を送信することにしました。 Kafka は、冗長性によって、確認応答されたメッセージがメモリのみに一時的に保存されるリスクが相殺されると考えています。

リーダーの失敗

リーダーが失われると、Zookeeper はコントローラーに通知し、コントローラーは新しいリーダー レプリカを選択します。 新しいリーダーは、LEO に従って新しい HW マークを設定します。 その後、フォロワーは新しいリーダーに関する情報を受け取ります。 Kafka のバージョンに応じて、フォロワーは XNUMX つのシナリオのいずれかを選択します。

1. ローカル ログが既知の HW に切り詰められ、このマークの後のメッセージの要求が新しいリーダーに送信されます。
2. リーダーに、リーダーに選出された時点の HW を検索するリクエストを送信し、ログをこのオフセットまで切り詰めます。 その後、このオフセットから定期的なフェッチ要求を開始します。

フォロワーは、次の理由によりログを切り詰める必要がある場合があります。

• リーダーが失敗すると、Zookeeper に登録された ISR セット内の最初のフォロワーが選挙に勝ち、リーダーになります。 ISR のすべてのフォロワーは、「同期している」とみなされますが、元リーダーからすべてのメッセージのコピーを受信して​​いない可能性があります。 注目のフォロワーが最新のコピーを持っていない可能性は十分にあります。 Kafka は、レプリカ間に相違がないことを保証します。 したがって、不一致を避けるために、各フォロワーはログを、選挙時の新しいリーダーの HW 値に切り詰める必要があります。 これが設定するもう XNUMX つの理由です acks=すべて 一貫性にとって非常に重要です。
• メッセージは定期的にディスクに書き込まれます。 すべてのクラスター ノードに同時に障害が発生した場合、異なるオフセットを持つレプリカがディスクに保存されます。 ブローカーがオンラインに戻ったとき、選出された新しいリーダーは他のリーダーよりも先にディスクに保存されていたため、支持者に後れをとっている可能性があります。

クラスターとの再会

クラスターに再参加すると、レプリカはリーダーに障害が発生したときと同じことを行います。つまり、リーダーのレプリカをチェックし、その HW へのログを (選択時に) 切り捨てます。 比較すると、RabbitMQ は、再結合されたノードをまったく新しいものとして同様に扱います。 どちらの場合も、ブローカーは既存の状態をすべて破棄します。 自動同期を使用する場合、マスターは「全世界を待機させる」方法で、現在のすべてのコンテンツを新しいミラーに複製する必要があります。 この操作中、マスターは読み取りまたは書き込み操作を受け付けません。 このアプローチでは、大規模なキューで問題が発生します。

Kafka は分散ログであり、一般に、データが読み取られた後にキューから削除される RabbitMQ キューよりも多くのメッセージを保存します。 アクティブなキューは比較的小さいままでなければなりません。 ただし、Kafka は独自の保持ポリシーを持つログであり、数日または数週間の期間を設定できます。 キューのブロックと完全同期のアプローチは、分散ログでは絶対に受け入れられません。 代わりに、Kafka フォロワーは、自分たちのコピーがリーダーよりも先にある場合、リーダーの HW (選挙時) へのログを単純に切り詰めます。 より可能性の高いケースとしては、フォロワーが遅れている場合、現在の LEO からフェッチ リクエストを開始するだけです。

新規または再参加したフォロワーは ISR の外部から開始され、コミットには参加しません。 彼らは単にグループと協力して、リーダーに追いついて ISR に入るまでできるだけ早くメッセージを受信します。 ロックインはなく、すべてのデータを破棄する必要もありません。

接続の喪失

Kafka には RabbitMQ よりも多くのコンポーネントがあるため、クラスターが切断されたときの動作セットがより複雑になります。 ただし、Kafka はもともとクラスター用に設計されているため、ソリューションは非常によく考えられています。

以下に、接続障害のシナリオをいくつか示します。

• シナリオ 1: フォロワーにはリーダーが見えませんが、動物園の飼育員は見えます。
• シナリオ 2: リーダーにはフォロワーが表示されませんが、Zookeeper は表示されます。
• シナリオ 3: フォロワーにはリーダーが見えますが、動物園の飼育員は見えません。
• シナリオ 4: リーダーにはフォロワーが見えますが、動物園の飼育員は見えません。
• シナリオ 5: フォロワーは、他の Kafka ノードおよび Zookeeper の両方から完全に分離されています。
• シナリオ 6: リーダーは、他の Kafka ノードおよび Zookeeper の両方から完全に分離されています。
• シナリオ 7: Kafka コントローラー ノードは別の Kafka ノードを認識できません。
• シナリオ 8: Kafka コントローラーは Zookeeper を認識しません。

各シナリオには独自の動作があります。

シナリオ 1: フォロワーにはリーダーは見えませんが、Zookeeper は見えています

米。 22. シナリオ 1: XNUMX つのレプリカの ISR

接続障害により、ブローカー 3 はブローカー 1 および 2 から分離されますが、Zookeeper からは分離されません。 ブローカー 3 はフェッチ リクエストを送信できなくなります。 時間が経ってから レプリカ.ラグ時間.最大ミリ秒 これは ISR から削除され、メッセージのコミットには参加しません。 接続が回復すると、フェッチ要求が再開され、リーダーに追いついたときに ISR に参加します。 Zookeeper は引き続き ping を受信し、ブローカーが正常に動作していると想定します。

米。 23. シナリオ 1: ブローカーは、replica.lag.time.max.ms 間隔内にフェッチ要求を受信しなかった場合、ISR から削除されます。

RabbitMQ のようなスプリット ブレインやノードの一時停止はありません。 代わりに、冗長性が削減されます。

シナリオ 2: リーダーにはフォロワーが表示されませんが、Zookeeper は表示されます

米。 24. シナリオ 2. リーダーと XNUMX 人のフォロワー

ネットワーク接続の障害によりリーダーとフォロワーが分離されますが、ブローカーは引き続き Zookeeper を認識できます。 最初のシナリオと同様に、ISR は縮小しますが、すべてのフォロワーがフェッチ リクエストの送信を停止するため、今回はリーダーのみが縮小します。 繰り返しますが、論理的な分割はありません。 その代わり、接続が復元されるまで新しいメッセージの冗長性が失われます。 Zookeeper は引き続き ping を受信して​​おり、ブローカーが生きていると信じています。

米。 25. シナリオ 2. ISR はリーダーのみに縮小しました

シナリオ 3. フォロワーにはリーダーが見えますが、飼育員は見えません

フォロワーは Zookeeper からは分離されていますが、リーダーを持つブローカーからは分離されていません。 その結果、フォロワーは引き続きフェッチ要求を行い、ISR のメンバーになります。 Zookeeper は ping を受信しなくなり、ブローカーのクラッシュを登録しますが、単なるフォロワーであるため、回復後の影響はありません。

米。 26. シナリオ 3: フォロワーがリーダーにフェッチ リクエストを送信し続ける

シナリオ 4. リーダーにはフォロワーが見えますが、Zookeeper は見えません

米。 27. シナリオ 4. リーダーと XNUMX 人のフォロワー

リーダーは動物園の飼育員からは離れていますが、信者を持つブローカーからは離れていません。

米。 28. シナリオ 4: 飼育員から孤立したリーダー

しばらくすると、Zookeeper はブローカーの障害を登録し、それについてコントローラーに通知します。 彼は追随者の中から新しい指導者を選ぶだろう。 ただし、元のリーダーは引き続き自分がリーダーであると考え、からのエントリーを引き続き受け入れます。 ACK=1。 フォロワーは彼にフェッチ リクエストを送信しなくなったため、彼はフォロワーが死んだものとみなし、ISR をそれ自体に縮小しようとします。 ただし、Zookeeper との接続がないため、これを実行することはできず、その時点でそれ以上のエントリの受け入れを拒否します。

Сообщения acks=すべて ISR が最初にすべてのレプリカをオンにし、メッセージがレプリカに到達しないため、確認応答は受信されません。 元のリーダーが ISR からメッセージを削除しようとしても、削除することはできず、メッセージの受け入れをまったく停止します。

クライアントはすぐにリーダーの変更に気づき、新しいサーバーへのレコードの送信を開始します。 ネットワークが復元されると、元のリーダーは自分がリーダーではなくなったことを認識し、ログの発散を避けるために新しいリーダーが障害時に持っていた HW 値にログを切り詰めます。 その後、新しいリーダーへのフェッチ リクエストの送信が開始されます。 新しいリーダーに複製されなかった元のリーダーのレコードはすべて失われます。 つまり、XNUMX 人のリーダーが作業していた数秒間に元のリーダーによって確認されなかったメッセージは失われます。

米。 29. シナリオ 4. ネットワークが復元された後、ブローカー 1 のリーダーがフォロワーになる

シナリオ 5: フォロワーは他の Kafka ノードおよび Zookeeper の両方から完全に分離されています

フォロワーは、他の Kafka ノードと Zookeeper の両方から完全に分離されています。 彼はネットワークが復旧するまで ISR から外し、その後他の人たちに追いつきます。

米。 30. シナリオ 5: 孤立したフォロワーが ISR から削除される

シナリオ 6: リーダーは他の Kafka ノードおよび Zookeeper の両方から完全に分離されています

米。 31. シナリオ 6. リーダーと XNUMX 人のフォロワー

リーダーは、そのフォロワーである管理者や動物園の飼育員から完全に隔離されています。 短期間ですが、引き続きエントリーを受け付けます。 ACK=1.

米。 32. シナリオ 6: リーダーを他の Kafka および Zookeeper ノードから分離する

有効期限を過ぎてもリクエストを受信して​​いない場合 レプリカ.ラグ時間.最大ミリ秒、ISR をそれ自体に縮小しようとしますが、Zookeeper との通信がないため縮小できず、書き込みの受け入れを停止します。

一方、Zookeeper は孤立したブローカーを死亡としてマークし、コントローラーが新しいリーダーを選出します。

米。 33. シナリオ 6. XNUMX 人のリーダー

元のリーダーは数秒間エントリを受け入れることができますが、その後メッセージの受け入れを停止します。 クライアントは 60 秒ごとに最新のメタデータで更新されます。 彼らはリーダーの変更を知らされ、新しいリーダーにエントリーを送信し始めます。

米。 34. シナリオ 6: メーカーが新しいリーダーに交代

接続が失われると、元のリーダーによって作成された確認済みのエントリはすべて失われます。 ネットワークが復元されると、元のリーダーは Zookeeper を通じて、自分がリーダーではなくなったことを発見します。 その後、選挙時に新しいリーダーの HW へのログが切り詰められ、フォロワーとしてリクエストの送信が開始されます。

米。 35. シナリオ 6: ネットワーク接続が回復した後、元のリーダーがフォロワーになる

この状況では、論理的な分離が短期間発生する可能性がありますが、これは次の場合に限られます。 ACK=1 и min.insync.レプリカ また、1. ネットワークが復元された後、元のリーダーが自分がリーダーではなくなったことを認識したとき、またはすべてのクライアントがリーダーが変更されたことを認識して新しいリーダーへの書き込みを開始したときのいずれか早い方で、論理的な分離は自動的に終了します。 いずれの場合でも、一部のメッセージは失われますが、それは次の場合に限られます。 ACK=1.

このシナリオには別の変形があり、ネットワークが分割される直前に、フォロワーが遅れをとり、リーダーが ISR を自分だけに圧縮しました。 その後、接続が失われることで孤立します。 新しいリーダーが選出されますが、元のリーダーは引き続きエントリーを受け入れます。 acks=すべて、ISRには彼以外に誰もいないからです。 ネットワークが復旧すると、これらの記録は失われます。 このオプションを回避する唯一の方法は、 min.insync.replicas = 2.

シナリオ 7: Kafka コントローラー ノードが別の Kafka ノードを認識できない

一般に、Kafka ノードとの接続が失われると、コントローラーはリーダー変更情報をそれに送信できなくなります。 最悪の場合、これはシナリオ 6 のように、短期的な論理的分離につながります。多くの場合、ブローカーが失敗した場合、そのブローカーは単純にリーダー候補にはなりません。

シナリオ 8: Kafka コントローラーが Zookeeper を認識しない

Zookeeper は、障害が発生したコントローラーから ping を受信せず、新しい Kafka ノードをコントローラーとして選択します。 元のコントローラーは引き続きそのように表示できますが、Zookeeper からの通知を受信しないため、実行するタスクはありません。 ネットワークが復元されると、彼は自分がもはやコントローラーではなく、通常の Kafka ノードになったことに気づきます。

シナリオからの結論

フォロワーの接続が失われてもメッセージが失われるのではなく、ネットワークが復旧するまで冗長性が一時的に低下するだけであることがわかります。 もちろん、XNUMX つ以上のノードが失われた場合、データ損失が発生する可能性があります。

接続が失われたためにリーダーが Zookeeper から離れた場合、Zookeeper からのメッセージが失われる可能性があります。 ACK=1。 動物園飼育員とのコミュニケーション不足により、XNUMX 人の指導者の間に一時的な論理的亀裂が生じます。 この問題はパラメータによって解決されます acks=すべて.

パラメーター min.insync.レプリカ 6 つ以上のレプリカに分割することで、このような短期間のシナリオでは、シナリオ XNUMX のようにメッセージが失われることがないという追加の保証が提供されます。

失われたメッセージの概要

Kafka でデータが失われる可能性があるすべての方法をリストしてみましょう。

• メッセージが次を使用して確認された場合のリーダーの失敗 ACK=1
• たとえ acks=すべて
• を使用してメッセージが確認された場合、リーダーを Zookeeper から隔離する ACK=1
• すでにISRグループを自分一人にまで縮小させたリーダーを完全に孤立させる。 すべてのメッセージは失われます。 acks=すべて。 これは次の場合にのみ当てはまります min.insync.replicas=1.
• すべてのパーティション ノードの同時障害。 メッセージはメモリから確認されるため、一部のメッセージはまだディスクに書き込まれていない可能性があります。 サーバーを再起動すると、一部のメッセージが失われる場合があります。

不純なリーダーシップの交代は、それを禁止するか、少なくとも XNUMX 名の冗長性を確保することで回避できます。 最も耐久性のある構成は次の組み合わせです。 acks=すべて и min.insync.レプリカ もっと1。

RabbitMQ と Kafka の信頼性の直接比較

信頼性と高可用性を確保するために、両方のプラットフォームにプライマリおよびセカンダリのレプリケーション システムが実装されています。 ただし、RabbitMQ にはアキレス腱があります。 障害後に再接続すると、ノードはデータを破棄し、同期がブロックされます。 この二重の打撃により、RabbitMQ における大規模なキューの寿命に疑問が生じます。 冗長性の低下または長いブロッキング時間のいずれかを受け入れる必要があります。 冗長性を減らすと、大量のデータ損失のリスクが高まります。 ただし、キューが小さい場合は、冗長性を確保するために、接続試行を繰り返すことで短期間 (数秒) の利用不能に対処できます。

カフカにはこの問題はありません。 リーダーとフォロワーの間の分岐点からのみデータを破棄します。 すべての共有データが保存されます。 さらに、レプリケーションによってシステムがブロックされることはありません。 新しいフォロワーが追いついてくる間、リーダーは投稿を受け入れ続けるため、DevOps の場合、クラスターへの参加または再参加は簡単な作業になります。 もちろん、レプリケーション時のネットワーク帯域幅などの問題はまだあります。 複数のフォロワーを同時に追加すると、帯域幅制限が発生する可能性があります。

RabbitMQ は、クラスター内の複数のサーバーに同時に障害が発生した場合の信頼性の点で Kafka よりも優れています。 すでに述べたように、RabbitMQ は、マスターとすべてのミラーによってメッセージがディスクに書き込まれた後でのみ、パブリッシャーに確認を送信します。 ただし、これにより次の XNUMX つの理由によりレイテンシがさらに増加し​​ます。

• 数百ミリ秒ごとに fsync
• ミラーの障害は、各ノードの可用性をチェックするパケットの有効期間 (ネット ティック) が経過した後にのみ気づくことができます。 ミラーが遅くなったり落ちたりすると、遅延が追加されます。

Kafka の賭けは、メッセージが複数のノードにまたがって保存されている場合、メモリに到達するとすぐにメッセージを確認できるということです。 このため、あらゆる種類のメッセージ (たとえ acks=すべて, min.insync.replicas=2) 同時故障の場合。

全体的に、Kafka はより優れたソフトウェア パフォーマンスを示し、クラスター向けにゼロから設計されています。 信頼性を確保するために必要に応じて、フォロワーの数を 11 まで増やすことができます。 レプリケーション係数 5 と同期するレプリカの最小数 min.insync.replicas=3 メッセージの損失が非常にまれなイベントになります。 インフラストラクチャがこのレプリケーション率と冗長性レベルをサポートできる場合は、このオプションを選択できます。

RabbitMQ クラスタリングは、小規模なキューに適しています。 ただし、トラフィックが多い場合は、たとえ小さなキューでも急速に増大する可能性があります。 キューが大きくなると、可用性と信頼性の間で難しい選択をする必要があります。 RabbitMQ クラスタリングは、RabbitMQ の柔軟性の利点がクラスタリングの欠点を上回る、非典型的な状況に最適です。

大規模なキューに対する RabbitMQ の脆弱性に対する XNUMX つの解毒策は、キューを多数の小さなキューに分割することです。 キュー全体の完全な順序付けを必要とせず、関連するメッセージ (特定のクライアントからのメッセージなど) のみを必要とする場合、またはまったく順序付けを行わない場合は、このオプションを使用できます。私のプロジェクトを見てください。 リバランサー キューを分割します (プロジェクトはまだ初期段階にあります)。

最後に、RabbitMQ と Kafka の両方のクラスタリングとレプリケーションのメカニズムに多数のバグがあることを忘れないでください。 時間が経つにつれて、システムはより成熟し、安定してきましたが、メッセージの損失を 100% 防ぐことはできません。 さらにデータセンターでは大規模事故が発生！

何かを見逃したり、間違いを犯した場合、または点のいずれかに同意できない場合は、お気軽にコメントを書くか、私に連絡してください。

「Kafka と RabbitMQ のどちらを選ぶべきですか?」、「どちらのプラットフォームが優れていますか?」とよく質問されます。 実のところ、それはあなたの状況や現在の経験などによって大きく左右されます。すべてのユースケースと考えられる制限に対して XNUMX つのプラットフォームを推奨するのは過度に単純化しすぎるため、私は意見を言うのを躊躇しています。 このシリーズの記事は、皆さんが自分の意見を形成できるように書きました。

どちらのシステムもこの分野ではリーダーであると言いたいのです。 私はプロジェクトの経験から、メッセージの順序の保証や信頼性などを重視する傾向があるため、少し偏見があるかもしれません。

この信頼性と順序の保証が欠けている他のテクノロジーを見てから、RabbitMQ と Kafka を見て、これら両方のシステムの信じられないほどの価値に気づきました。

出所： habr.com