Kafka は高い信頼性と高可用性を維持するためにどのようなメカニズムに依存していますか?

大企業の面接では、履歴書に Kafka が記載されていると、ほぼ確実に次のような質問を受けるでしょう。「Acks パラメータはメッセージの永続性にどのような影響を与えますか?」

Acks パラメータは、Kafka の使用において非常に中核的かつ重要なパラメータであり、多くのことを決定します。

したがって、インタビューのためであろうと実際のプロジェクトでの使用のためであろうと、この記事の Kafka の Acks パラメータの分析とその背後にある原則を読む価値はあります。

ダウンタイム中にデータが失われないようにするにはどうすればよいですか?

この Acks パラメータの意味を理解するには、まず Kafka の高可用性アーキテクチャの原則を理解する必要があります。

たとえば、次の図は、トピックごとに複数のパーティションを含めるように設定でき、各パーティションがトピックのデータの一部を格納する役割を担っていることを示しています。

次に、Kafka のブローカー クラスターでは、各マシンにいくつかのパーティションが保存され、トピック データの一部も保存されるため、ブローカー クラスター上でトピック データの分散ストレージが実現されます。

しかし、問題があります。 Kafka ブローカーがダウンした場合、そこに保存されているデータは失われませんか?

はい、これは比較的大きな問題です。分散システムのデータ損失問題は、最初に解決しなければならない問題です。いずれかのマシンがダウンすると、データが失われます。

冗長性の複数のコピーを備えた高可用性メカニズム

したがって、Zookeeper、Kafka、Redis Cluster、Elasticsearch、HDFS などの分散システムの原理を分析します。

実際、それらはすべて独自の内部マルチコピー冗長性メカニズムを備えており、マルチコピー冗長性は、ほぼすべての優れた分散システムに必須の機能です。

Kafka クラスターでは、各パーティションに複数のコピーがあり、次の図に示すように、そのうちの 1 つはリーダーと呼ばれ、他のコピーはフォロワーと呼ばれます。

上の図に示すように、トピックが Partition0、Partition1、Partition2 という 3 つのパーティションに分割されているとします。この時点で、各パーティションには 2 つのコピーがあります。

たとえば、Partition0 にはリーダーであるレプリカが 1 つとフォロワーであるレプリカがもう 1 つあります。リーダーとフォロワーのレプリカは異なるマシンに分散されます。

このようなマルチコピー冗長メカニズムにより、いずれかのマシンに障害が発生した場合でも、少なくとも他のマシンにコピーが存在するため、データが完全に失われることはありません。

複数のコピー間でデータを同期するにはどうすればよいですか?

次に、複数のレプリカ間でデータがどのように同期されるかを見てみましょう。実際、どのパーティションでも、リーダーだけが外部に読み取りおよび書き込みサービスを提供します。

つまり、クライアントがパーティションにデータを書き込む場合、通常はこのパーティションのリーダー コピーに書き込みます。

その後、リーダー コピーがデータを受信すると、フォロワー コピーは継続的にリクエストを送信して、最新のデータを取得し、それをローカルの場所に取得し、ディスクに書き込もうとします。

次の図に示すように:

ISR とは具体的に何を意味するのでしょうか?

Partiton のマルチコピー データ同期メカニズムについて理解できたので、次は ISR について見てみましょう。

ISR の正式名称は「In-Sync Replicas」で、同期されたレプリカを意味します。どのフォロワーが常にリーダーと同期されるかを意味します。

考えてみてください。フォロワーが配置されているブローカーが JVM FullGC などの問題のために停止し、リーダーから同期データを時間内に取得できない場合、フォロワーのデータはリーダーより大幅に遅れるのではないでしょうか。

つまり、この時点で、フォロワーはリーダーと同期関係にないことになります。

ただし、フォロワーがリーダーからのデータをタイムリーに同期し続けている限り、両者が同期関係にあることが保証されます。

したがって、各パーティションには ISR があり、リーダーはデータが最新であることを確認するため、ISR にはリーダー自体が含まれている必要があります。すると、リーダーと同期しているフォロワーも ISR に含まれるようになります。

Acksパラメータの意味

ここまでの基礎作業を経て、ようやく本題に入り、Acks パラメータの意味について話すことができます。

これまでのコピーの仕組み、同期の仕組み、ISRの仕組みを理解していないと、Acksパラメータの意味を完全に理解することはできません。このパラメータは実際に多くの重要なことを決定します。

まず、プロデューサークライアントである Kafka Producer で Acks パラメータを設定します。

つまり、Kafka にデータを書き込むときに、Acks パラメータを設定できます。そして、このパラメータには実際に設定できる 3 つの共通値、つまり 0、1、すべてがあります。

最初のオプションは、Acks パラメータを 0 に設定することです。これは、クライアント側の Kafka プロデューサーでは、メッセージが送信されている限り、データがディスク上にあるかどうか、パーティション リーダー上にあるかどうかに関係なく、メッセージが正常に送信されたと想定することを意味します。

この設定を使用する場合、送信したメッセージがまだ途中である可能性があることに注意する必要があります。

その結果、パーティション リーダーが配置されているブローカーが直接クラッシュし、クライアントはメッセージが正常に送信されたと認識し、メッセージが失われます。

2 番目のオプションは、Acks = 1 を設定することです。これは、パーティション リーダーがメッセージを受信して​​ローカル ディスクに書き込む限り、他のフォロワーがメッセージを同期したかどうかに関係なく、成功したと見なされることを意味します。

この設定は実際には Kafka のデフォルト設定です。ぜひ注目して要点を押さえてご覧ください！これがデフォルト設定です。

つまり、デフォルトでは、Acks パラメータを無視すると、パーティション リーダーが正常に書き込みを行う限り、成功したと見なされます。

しかし、ここで問題があります。パーティション リーダーがメッセージを受信したばかりで、フォロワーがメッセージを同期する時間がなく、リーダーが配置されているブローカーがクラッシュした場合、クライアントは既にメッセージが正常に送信されたと認識しているため、メッセージは失われます。

*** 1 つのケースは、Acks=all を設定することです。これは、パーティション リーダーがメッセージを受信した後、メッセージが正常に書き込まれたとみなされる前に、リーダーと同期されている ISR リスト内のフォロワーにもメッセージを同期するように要求する必要があることを意味します。

パーティション リーダーがメッセージを受信したが、フォロワーがメッセージを受信せず、リーダーがダウンしている場合、クライアントはメッセージが正常に送信されなかったことを感知し、メッセージを再度送信しようとします。

このとき、パーティション2のフォロワーがリーダーになる場合があります。この時点で、ISR リストにはリーダーに変身したフォロワー *** のみが含まれます。その後、新しいリーダーがメッセージを受信すれば、成功したとみなされます。

***の考え

Acks=all はデータが失われないことを意味しますか?もちろん違います。パーティションにコピーが 1 つだけ (つまり、リーダー) あり、フォロワーがない場合、acks=all は役に立つと思いますか?

もちろん、ISR にはリーダーが 1 つしかないため、メッセージ受信後にリーダーがクラッシュすると、データ損失も発生するため、これは役に立ちません。

したがって、Acks=all は、ISR リスト内の少なくとも 2 つのレプリカ (少なくとも 1 つのリーダーと 1 つのフォロワー) で使用する必要があります。

これにより、データが書き込まれるときに、それが成功したとみなされるには 2 つ以上のコピーによって受信される必要があることが保証されます。この時点でいずれかのコピーがダウンしても、データは失われません。

ですので、この記事を皆さんによく理解していただければ幸いです。面接に出かけたり、仕事で Kafka を使用したりするときに、皆さんにとって大きな助けとなるでしょう。

著者: Huperzeda sinensis

Chinese Huperzine: 10 年以上の BAT アーキテクチャ経験、一流インターネット企業のテクニカル ディレクター。数百人のチームを率いて、数億のトラフィックを処理する複数の高同時実行システムを開発しました。長年の研究で蓄積してきた研究論文や経験の要約を文書にまとめましたので、皆様にご紹介したいと思います。 WeChat 公開アカウント: Shishan’s Architecture Notes (ID: shishan100)。