定義のコピー
カフカは、テーマにした概念であり、各トピックには、さらにいくつかのパーティションに分割されます。コンセプトは、各パーティションには、いくつかのコピーで構成され、実際にパーティション・レベルの下で定義されたコピーです。
いわゆるレプリカ（レプリカ）は、基本的に唯一の追加書き込まれたログを提出することができるメッセージです。カフカは、格納されたメッセージの同じシーケンス内のパーティションのすべてのコピーと、異なる分散ブローカに記憶されたコピーは、利用できないデータ部分ブローカに対してダウンせることができる、定義メカニズムをコピーします。
実際の生産環境では、各ブローカーは各テーマの下に別のパーティションに保存されている別のコピーを有していてもよく、したがって、そこに一つのブローカーのコピーの数百の現象には非常に正常です。私たちは地図を見て次に、カフカブローカクラスタの3の分布のコピーがあることを示しています。
この図から、我々はテーマディビジョン1つの0 3のコピーが、データの冗長性を実現するためには、以上の3ブローカーを広め、他のトピックはまた別のブローカーに散在しているパーティションをコピーすることがわかります。
レプリカの役割
また、一貫性のある複数のコピーを設定することができ、パーティションが、これらのコピーの内容は、その後、自然な質問です：どのように我々は、すべてのデータのコピーがそれと一致していることを確認するのですか？
特に、プロデューサーがトピックにメッセージを送信カフカは、メッセージは、それに対応するすべてのコピーを同期する方法ですか？この問題に対処するために、最も一般的な解決策は、使用することのメカニズムベースのリーダー（リーダー・ベース）のコピーを。Apacheのカフカは、そのようなデザインです。
以下のようなリーダーシップの原則に基づいて、コピーメカニズムは、私は簡単にこの絵の内部の内容を説明しましょう。
まず、リーダー（リーダーレプリカ）やフォロワーのコピー（フォロワーレプリカ）のコピー：、カフカで、コピーは、2つのカテゴリに分類されます。あなたは選挙のコピーを作成し、各パーティションはリーダーのコピーによって呼び出される必要があり、コピーのコピーの残りの部分は自動的にフォロワーと呼ばれます。
第二に、カフカは、他の分散システムのいくつかよりも厳しいことにするメカニズムをコピーします。カフカでは、コピーの信者は、外部サービス・プロバイダではありません。レスポンスのコピーのいずれかのフォロワーは、消費者と生産者の要望を読み書きすることができないことをこれが意味。すべての要求は、リーダーのコピーによって処理されなければならない、またはすべての読み取りおよび書き込み要求は、プロセスの担当ブローカー、ブローカーコピーの指導者に送付されなければならないということ。フォロワーがクライアントの要求を処理しないコピーし、その唯一のタスクは、リーダーからコピーすることです非同期引っ張られたメッセージをコピーのリーダーとの同期を実現するために、独自にコミットログを書き込みます。
第三にリーダーのコピーがハングアップ、またはカフカはZooKeeperの監視機能に依存している場合は、ダウンブローカーのコピーの指導者は、リアルタイムの知覚を提供し、すぐに信者から選挙のリーダーの新ラウンドを開くと、新しいリーダーとして選択のコピー。再起動後にリーダーの古いコピーバックは、コピーのみのフォロワーとしてクラスタに追加します。
あなたは上記第二の点に特別な注意を払う必要があり、コピーの信者は、外部サービス・プロバイダではありません。私たちは、ただのメカニズムをコピーするメリットについて話しましたカフカは、地域にそれを読み出し動作スケールを提供し、改善するために失敗したときに覚えていますか？このための具体的な理由はそれです。
それはMySQLのような「反読み取り」のコピーは、達成することができないでもない、ヘルプリーダーが改善し、ローカル最近のクライアントデータのコピーから離れていくつかを置くことができ、クライアントのユーザーのために、カフカの信者のコピーが、効果がありませんセックス。
ケースであること。つまり、カフカなぜこのデザイン？実際には、このコピーメカニズムは、2つの利点があります。
1.「読取りあなた-書き込み」の達成を促進します。
名前が示すように、リード・ご-書き込みいわゆるあなたが成功したカフカのプロデューサにメッセージを書き込むためにAPIを使用する場合、すぐにちょうど生産ニュースを読むためにAPIの消費者を使用することです。たとえば、あなたは通常、それを送信した場合など、あなただ完了センドマイクロボーは、確かに典型的である、すぐに見ることを望んでいるシーンが読む-あなた-書き込みます。あなたは、同期複製のためにサービスを提供するために、コピーの信者は、非同期で許可した場合、そのクライアントはニュースが最近書かれて見ることができないのでことを、最新のニュースにそこに引かリーダーの信者のコピーからコピーが存在していないかもしれません。
2.便利な読み取り単調（モノトニック読み込み）。
それを読むことが単調とは何ですか？ユーザーのために、消費者、複数のメッセージは、それが不在しばらく一瞬メッセージの存在は表示されません消費者があります。あなたは信者が提供するサービスのコピーを読み取ることができるようにした場合、現在、非同期リーダーにデータのコピーを引っ張っF1とF2の信者の2つのコピーが存在することが想定されます。F1最新ニュースのリーダーを引くとF2が時間内に引き込まれていないプルコンシューマF1がある場合は、F2と、この時点からのメッセージの後にメッセージを読み始めた場合、それはこのような現象が表示されることがあります最初の第二の消費で最新のニュースを参照するには、消費者が消えていたとき、それは単調な読み取り一貫性ではありません。しかし、単調なカフカを達成することは容易であるように、すべての読み取り要求は、リーダーによって処理されている場合は一貫性をお読みください。
同期レプリカ（ISR）
私達はちょうど繰り返し言ってきた、サービスは信者のコピーを提供しますが、定期的にデータを非同期リーダーコピーを引っ張っていません。それは非同期であるので、リーダーとのリアルタイム同期の危険性があるそうです。適切にこのリスクに対処する方法を説明する前に、我々は同期はいの意味内容を正確に把握する必要があります。または、カフカは明らかに最終的には信者のコピーがリーダーで、どのような条件の下で同期考慮され、私たちを教えてください。
この考えに基づき、カフカもISRレプリカセットとして知られて同期レプリカを、導入しました。ISRのコピーは逆に、ないISRの信者のコピーが同期のリーダーであると考えられている、リーダーのコピーと同期されます。だから、最終的にどのようなISRにそれをコピーすることができますか？
私たちは、最初のISRのリーダー自然のコピーを、その明確でなければなりません。言い換えれば、ISRだけでなく、信者のレプリカセットは、それがリーダーのコピーを含める必要があります。でも、いくつかのケースでは、ISRリーダーそれの一つのコピーのみ。
また、信者のコピーは、一定の条件を満たすようにISRに入ります。どのような条件として、私は、みんなでこの絵を見てみましょう、秘密にしたいと思います。
一人のリーダーのコピーと2人のフォロワーコピー：図は、3つのコピーがあります。現在のメッセージ10のリーダーで書かれたコピー、Follower1は、その中に6メッセージだけ同期レプリカFollower2 3メッセージを前記同期レプリカ。さて、あなたは信者の2つのコピーのためにそれについて考え、信者は、同期のリーダーのコピーであるあなたと思いますか？
答えは、特定の状況に基づいていることです。英語に、それは有名なフレーズ「それが依存」です。それはFollower2がはるかに少ないリーダーよりも、それは同期のリーダーで、最も可能性が高いメッセージの数のように見えます。それは正しいが、唯一可能です。
実際には、この図の2フォロワーコピーがリーダーと同期されないことがありましたが、また、可能性の高いリーダーと同期するようにしています。言い換えれば、カフカは、リーダーとフォロワーの標準的な同期は、メッセージの数が、他との違いを参照していないかどうかを判断する「謎を。」
この規格は、値パラメータreplica.lag.time.max.msパラメータブローカーの終わりです。パラメータの意味は、最も下位のリーダー、長い時間間隔のコピーのフォロワーをコピーすることができ、現在のデフォルト値は10秒です。この手段は、長い10秒を超える不連続の後退時リーダーフォロワーのコピーのコピーなどとして、その後、カフカがフォロワーのコピーがリーダーと同期していると考えて、フォロワーにも大幅に少ないメッセージのリーダーコピーよりも、この時点でのメッセージのコピーを保存していること。
私たちは、フォロワーのコピーが唯一の仕事は常にリーダーコピーからメッセージを引き出した後、ログに書き込まれ、自分のを提出することで、以前に述べました。同期プロセスの速度がメッセージの遅い書き込み速度リーダーのコピーに続く場合、その後、replica.lag.time.max.ms時間の後、これは同期のフォロワーとリーダーコピーのコピーと見なされます、それは取り戻すことはできませんISR。この時点では、カフカが自動的ISRコレクション、「追い出さ」ISRのコピーを縮小します。
それはリーダーの進歩に追いつくためにゆっくりと戻ってコピーする場合、それはISRへの再追加バックすることができ、ことは注目に値します。ISRはむしろ静的不変より、セットの動的に調整され、このことも示しています。
汚れたリーダー選挙（不潔リーダー選挙）
ISRを動的に調整することができるので、その後自然にそのようなA状況が発生する可能性：ISRが空です。ISRが空の場合、ISRの自然リーダーのコピーなので、それはリーダーのコピーが再選出の新しいリーダーに、カフカの必要性を「ハング」もあることを意味します。しかし、ISRは、その時点で新しいリーダーの選出方法は、空のでしょうか？
カフカは、非同期コピーと呼ばれているすべてのISRの存続のコピーではありません。あなたは新しいリーダーとして、これらのコピーを選択した場合、一般的な、非同期コピーリーダーで後方あまり、そう、それはデータが失われる可能性が表示されます。結局のところ、これらは、メッセージのコピーがはるかメッセージの古いリーダーの背後にある保存されました。カフカでは、この選挙プロセスのコピーが汚れたリーダー選挙と呼ばれています。ブローカーの終わりには、汚れたリーダー選挙を許可するかどうかunclean.leader.election.enable制御パラメータ。
オープン汚れたリーダー選挙は、データの損失につながるかもしれないが、利点は、それはリーダーが常に存在しているパーティションのコピーを作成し、高可用性をサービスを提供し、ひいては強化するために中止しないことです。一方、汚れたリーダー選挙を禁止することの利点は、データの一貫性を維持メッセージの損失を避けることが、高可用性を犠牲にすることです。
如果你听说过 CAP 理论的话，你一定知道，一个分布式系统通常只能同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）中的两个。显然，在这个问题上，Kafka 赋予你选择 C 或 A 的权利。
你可以根据你的实际业务场景决定是否开启 Unclean 领导者选举。不过，我强烈建议你不要开启它，毕竟我们还可以通过其他的方式来提升高可用性。如果为了这点儿高可用性的改善，牺牲了数据一致性，那就非常不值当了。
副本处理
Kafka在启动的时候会开启两个任务
一个任务用来定期地检查是否需要缩减或者扩大ISR集合，这个周期是replica.lag.time.max.ms的一半，默认5000ms。当检测到ISR集合中有失效副本时，就会收缩ISR集合，当检查到有Follower的HighWatermark追赶上Leader时，就会扩充ISR。除此之外，当ISR集合发生变更的时候还会将变更后的记录缓存到isrChangeSet中，
另外一个任务会周期性地检查这个Set,如果发现这个Set中有ISR集合的变更记录，那么它会在zk中持久化一个节点。然后因为Controllr在这个节点的路径上注册了一个Watcher，所以它就能够感知到ISR的变化，并向它所管理的broker发送更新元数据的请求。最后删除该路径下已经处理过的节点。
此外，在0.9X版本之前，Kafka中还有另外一个参数replica.lag.max.messages，它也是用来判定失效副本的，当一个副本滞后leader副本的消息数超过这个参数的大小时，则判定它处于同步失效的状态。它与replica.lag.time.max.ms参数判定出的失效副本取并集组成一个失效副本集合。
不过这个参数本身很难给出一个合适的值。以默认的值4000为例，对于消息流入速度很低的主题（比如TPS为10），这个参数就没什么用；对于消息流入速度很高的主题（比如TPS为2000），这个参数的取值又会引入ISR的频繁变动。所以从0.9x版本开始，Kafka就彻底移除了这一个参数。