テキスト
まず、高可用性の起源
1.1なぜあなたはレプリケーションが必要なのです
1ブローカがダウンしたら、以前のバージョンではカフカ0.8では、どのカフカデータの永続性と配達保証設計目標反し、、、その後、すべてのパーティション上のデータを消費することはできません何のレプリケーションはありません。同時にプロデューサー、これらのデータは、パーティションに格納されていることができません。
同期モードは、プロデューサープロデューサーは時間が例外をスローした後、ユーザーは次のデータ送信の送信を停止することを選択できます（デフォルトは3である）の再送信message.send.max.retriesしようとしている場合も、選択し続けることを選択することができます。データの損失を引き起こす可能性があり、元の意志原因の障害物データは、ブローカーに送信する必要があります。
プロデューサーは、2番目のログ後（デフォルトは3である）、例外を再送message.send.max.retriesにプロデューサーの試行を非同期モードを使用している場合、データの損失や、ユーザーにつながることができますフォローアップのデータを送信し続け、ログによって問題を見つけることができます。同時に、カフカのプロデューサーは、非同期モードへのコールバックインタフェースを提供していません。
したがって、レプリケーション状況の不存在下で、一度マシンがダウンしているかブローカワークは、システム全体の可用性低下をもたらすであろう停止します。レプリケーションメカニズムの導入は、生産システムのために非常に重要であるように、クラスタサイズの確率の増加に伴い、クラスタ全体で表示される異常の種類が大幅に増加しました。
1.2リーダー選挙
導入レプリケーションの後、同じレプリカのパーティションを複数持っている、とだけ相互作用リーダー、フォロワー他のレプリカとリーダーからデータをコピーするなどの複製、プロデューサーと消費者の間でリーダーを選択する必要があります。
（他のレプリカを提供し続けることができ、そのデータの重複がデータ損失の原因することはできません。原因ではありません必要があります後に1ダウン）同じパーティションの複数のレプリカの間でデータの一貫性を確保する必要があるため。すべてのレプリカ/書き込みデータを読み取ることができながら、リーダーなしで、それは、大幅に増加各（N×Nは、レーンの断片）同期データ、データの一貫性を発注し、複数のレプリカの間で確保することは非常に困難であることを確認する必要がありますレプリケーションの実装の複雑さが、また、例外の可能性を高めます。リーダーの導入後に、リーダーは、データ読み出し及び書き込みのため、唯一のフォロワーは、データをフェッチ（N経路）リーダー配列、より簡単で効率的なシステムに関する。
二、カフカHA設計解析
すべてのレプリカに均等にクラスタ全体に分散されますどのように2.1
優れた負荷分散するためには、カフカが均等にクラスタ全体に分散し、すべてのパーティションを試してみてください。展開の典型的な数は、トピックパーティションブローカーよりも大きくなります。一方、異なるマシンのレプリカパーティションを広めるためにしようとする必要があるとカフカの耐障害性を向上させるためです。すべてのレプリカが同じブローカーである場合は実際には、ブローカーがダウンしたら、パーティションのすべてのレプリカが仕事にできないことを、我々は、HAの効果を実現します。ブローカーがダウンしている場合一方、負荷の上にそれを維持する必要性が均等に他のすべてのブローカーの存続に配布することができます。
次のようにカフカ割り当てアルゴリズムのレプリカは以下のとおりです。
1.すべてのブローカ分配される（Nブローカの合計を想定）とパーティションをソーティング
前記第1の（I MOD N）に割り当てられたi番目のパーティションブローカ番目
第一（（I + J）モードn）に割り当てられた3パーティションi番目、j番目のレプリカ番目ブローカ
2.2データ・レプリケーション（ポリシーのコピー）
カフカ保証高い信頼性は、その強力なコピー（複製）戦略から来ています。
2.2.1メッセージの同期化戦略
あなたが最初に関わらず、複製ファクターのトピックの、ZooKeeperのでパーティションのリーダーを見つけ、パーティションへのメッセージを公開プロデューサーはどのように多くの、プロデューサーが唯一のパーティションのリーダーにメッセージを送信します。リーダーは、そのローカルログにメッセージを書き込みます。各フォロワーリーダープルからのすべてのデータ。このように、データが順次リーダーと一致フォロワー保存されています。メッセージを受信し、それをログを書き込み後のフォロワーは、リーダーにACKを送信します。ISR内のすべてのACKを受信したらレプリカリーダーは、メッセージがコミット有していると考えられる、とリーダーはHWは、プロデューサーにACKを送信増加します。
それはむしろ、データがログに書き込まれるまで待つよりも、受信されると、パフォーマンスを向上させるために、各リーダーのフォロワーは、すぐにデータにACKを送信します。このように、すでにメッセージをコミットするために、カフカは、それがメモリの複数のレプリカに格納されていることを確認し、彼らがディスクに永続化された例外は、消費者の消費量である必要があります後、それはこのマッサージを保証できないことを保証することはできません。
消費者情報を読み取りリーダーから読み込まれ、それはメッセージが消費者に公開されますコミットだけでした。
下に示すように、データ・ストリームのカフカレプリケーション：
バックアップの数を確保する必要性の前に2.2.2 ACK
カフカの場合、ブローカーは、「生きている」の定義は、二つの条件が含まれているかどうか：
- まず、それは（これはハートビート機構のZooKeeperによって達成される）のZooKeeperとのセッションを維持する必要があります。
- 第2従動は「これまでの背後にある。」、来てタイムリーなニュースのリーダーをコピーすることはできませんでなければなりません
リーダーは、リストはISR（IEで同期レプリカ）と呼ばれ、レプリカの同期を維持し、そのリストを追跡します。フォロワーのダウン、またはあまりにも多くの背後にある場合、リーダーは、ISRから削除されます。本明細書に記載の「後ろファー」は、個数を意味するリーダー後ろフォロワメッセージがreplica.lag.max.messages $ KAFKA_HOME /設定/ server.propertiesて配置することができるコピーされた所定値（デフォルトを超え値は4000である）、または特定の時間よりもフォロワー（この値は$ KAFKA_HOME /設定/ server.properties、デフォルト値は10000です）フェッチ要求をリーダーに送信されませんreplica.lag.time.max.msによって構成されていてもよいです。
カフカのレプリケーションメカニズムは、非同期レプリケーションは単純ではない、どちらも完全に同期レプリケーションです。実際には、完全に同期レプリケーションがコピーされているすべてのフォロワーの作業を必要とし、メッセージがコミット考慮されます、このレプリケーションが大幅にスループットを（ハイスループットはカフカの非常に重要な特性である）に影響します。フォロワーがリーダーの背後にあるコピーされた場合は、非同期レプリケーション、リーダーフォロワーデータからの非同期レプリケーションは、限りデータがログリーダーに書かれているとして、この場合には、コミット有していると考えられるが、リーダーが突然ダウンした場合、それは意志データの損失。ISRとカフカの使用は、データが失われたとスループットされていないことを確実にすることのバランスのとれた方法です。リーダーから従動缶バルク・コピー・データは、これは非常に大きくフォロワーとリーダーとの間のギャップを減少させる、レプリケーション性能（ディスクに一括書き込み）を改善します。
カフカが唯一の「ビザンチン」（「ビザンチン」）の問題を扱っていない、回復/失敗に対処注意すべきです。メッセージは、提出されたものとみなされます過去からコピーされているすべてのリーダーフォロワーで唯一のISRです。これはリーダーに書き込まれるデータの一部を回避し、フォロワーはダウンタイムにコピーする時間を持っていたし、（これらのデータを消費する消費者ができない）に起因するデータの消失していません。プロデューサーが懸念しているために、それはニュースがrequest.required.acksによって設定することができ、コミットを待機するかどうかを選択することができます。長いフォロワーの一つ以上があるようISRは、コミットメッセージが失われないことである。このメカニズム性を保証
2.2.3リーダー選挙アルゴリズム
リーダー選挙は、2つの方法の分散ロックのZooKeeperがあっ基づき、基本的に分散ロックです。
- ユニークなノード名：より多くのクライアントは、ノードを作成するには、ノードは、成功したロックを取得するためのクライアントを作成します
- ノードの一時的な順序：すべてのクライアントがディレクトリ内のノードの独自の一時的な順序を作成するための、唯一の最小の数が得られたロック
非常に人気の選出されたリーダーは、「多数決」（「過半数」）ですが、カフカは、この方法ではありませんでした。我々は（リーダーとフォロワーを含む）2F + 1のGeのレプリカを持っている場合は、このモードでは、それは新しいリーダーを選出する権利を確保するために+ Fをコミットする前に1つのGeのレプリカの完全な複製メッセージは、レプリカを超えないようにして失敗することを確認する必要がありますF A。任意のF + 1のGeのレプリカの残りの部分は、少なくとも、レプリカは、すべての最新ニュースが含まれているため。このアプローチは、大きな利点を持って、待ち時間のシステムは、いくつかのブローカーではなく、最も遅い1の最速に依存します。大多数の投票は、通常のリーダー選挙を確保するために、いくつかの欠点があり、フォロワーの数が、それはあまり許容できる失敗します。あなたがフォロワーを容認ハングアップしたい場合は、三つ以上のレプリカがなければならない2フォロワーを許容し、あなたがハングアップする場合は、5つ以上のレプリカが存在しなければなりません。言い換えれば、耐障害性の高い程度を確保するために、本番環境では、レプリカが多数存在でなければならない、とレプリカの多数は、大量のデータのパフォーマンスの急激な減少につながります。これは、この共有クラスタ以上のZooKeeperのシステム構成で使用されるアルゴリズムは、めったに使用されるシステムのデータ原因を大量に格納する必要がありません。HA機能のHDFSの例は、多数決ベースのジャーナルに基づいていますが、それはこのように保存されたデータを使用していません。
ZooKeeperの中カフカはダイナミックISR（イン・シンクのレプリカ）を保持し、すべてのレプリカでISRがリーダーに追いつくために必要があり、ISRのメンバーのみが可能なのリーダーとして選択されています。損失がメッセージ前提コミット有することなく、このモードでは、レプリカF + 1のための1つが、パーティションレプリカF耐障害性を確保することができます。ほとんどの使用シナリオでは、このモデルは非常に良好です。実際には、Fのレプリカ、レプリカ多数決と、それは同じである待つようにコミットするISR前の数が、多数決のほぼ半分のISRニーズのレプリカの総数の失敗を許容するためです。
多数決とISRは、以上の最も遅いBrokerの利点を待つ必要がないが、著者は、カフカカフカプロデューサーは、この問題を改善するためにコミットブロックするかどうかを選択し、レプリカを保存したディスクISRモードはまだ作り価値があることができると信じていますが。
すべてのレプリカのない仕事に対処する方法2.2.4
ISRに少なくとも1つのフォロワーがある場合は、カフカはすでにそのデータが失われないことを確認するためにコミットが、パーティションのすべてのレプリカがダウンしている、と場合は、データが失われないことを保証することはできません。この場合、2つの可能なオプションがあります：
以上、そしてそれはリーダーとして選択されたいずれかのレプリカ「ライブ」によるISRのため1.待ち
リーダーとして、（必ずしもISR内）のレプリカを超える最初の「ライブ」を選択します
この必要性は、使いやすさと、それらの一貫で、単純なトレードオフを行います。あなたが利用できない時間をかけて「ライブ」ISRレプリカを待たなければならない場合は、比較的長いかもしれません。、またはデータが失われたオーバーレプリカISRのすべてのことができます「ライブ」ではない場合や、パーティションが利用可能になることはありません。リーダーとしてのレプリカを超える最初の「ライブ」を選択し、これはISRのレプリカレプリカではありません、それはすでに、すべてのコミットメッセージを含んでいることを保証するものではありませんが、それは以前に（消費者データソースとしてのリーダーになります）リーダーがすべての読み取りと書き込みを完了するための命令があります。Kafka0.8は。*第二の方法を使用してください。カフカのドキュメントによると、将来のリリースでは、カフカが異なる利用シーンに応じて、高可用性や強い一貫性を選択するために、設定するには、これらの2つの方法のいずれかを選択するようにユーザーをサポートしています。
2.2.5選挙リーダー
だけのことを確認し、最もシンプルで直感的なプログラム、リーダーのダウンタイム、自動的に削除対応短命のznode、その後、すべてのフォロワーが受賞者を作成し、ノードを作成しようとしていたら、すべては、ZooKeeperの上のフォロワーウォッチに設定されている（ZooKeeperの新しいリーダーで成功）を作成するために、他のレプリカはフォロワーです。
しかし、この方法では、3つの質問があります。
ZooKeeperのの特性に起因している。この1.split、脳、順序でのZooKeeperがすべてのウォッチトリガーが、それはレプリカの異なる応答をもたらすことができるすべてのレプリカの状態が同じである「見る」と同じ時間を、保証するものではないことを確実にします矛盾
ブローカーのパーティション2.herd効果がよりダウンしている場合、クラスタ内の調整の多くを引き起こして、トリガーされるより腕時計になります
クラスタサイズが重すぎるだろう数千のパーティションのZooKeeper負荷に上昇したときに、各レプリカにこの目的のZooKeeperの登録を、オーバーロードされ3.ZooKeeper。
カフカ0.8。*上記の問題にリーダー選挙ソリューションは、それは、すべてのブローカーで、コントローラによってすべての意思決定のリーダー選挙パーティションのコントローラを選出しました。リーダーコントローラは、応答ブローカとして、この通知に必要とされるRPCメソッド（ZooKeeperのキューよりもより効率的な方法）を介して直接変化します。また、コントローラは、追加および削除だけでなく、トピックを再割り当てのレプリカを担当していますが。
三、HA関連構造のZooKeeper
3.1管理者
関連する操作がある場合のznodeこのディレクトリにのみ存在するであろう、それは操作の終了時に削除されます
別のブローカーにセットの一部を分配するための/管理/ reassign_partitionsパーティション。それぞれのパーティションは、カフカストアすべてのレプリカブローカーIDとのznodeに対応する、再割り当てされます。znodeは、管理プロセスによって作成され、再び、それは自動的に正常に削除割り当てられます。
3.2ブローカー
つまり/ブローカー/ IDS / [brokerId]）を格納する "アライブ" メッセージ・ブローカ。
トピックの登録情報（/ブローカー/トピック/ [トピック]）、すべてのトピックのすべてのレプリカパーティションが存在するブローカIDが格納され、第1のレプリカが好ましいレプリカである、特定のパーティションのために、その同じブローカーにほとんど唯一のレプリカ、レプリカIDなどのため、ブローカーのIDで。
3.3コントローラ
コントローラ店舗> INT（コントローラのブローカID）現在の情報 - /コントローラ
/ Controller_epoch - >ないJSON文字列として格納され、他のznode等整数ストアコントローラエポックの形で直接INT（エポック）。
四、プロデューサーのニュースリリース
4.1書き込みモード
producer 采用 push 模式将消息发布到 broker，每条消息都被 append 到 patition 中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障 kafka 吞吐率）。
4.2 消息路由
producer 发送消息到 broker 时，会根据分区算法选择将其存储到哪一个 partition。其路由机制为：
1、 指定了 patition，则直接使用； 2、 未指定 patition 但指定 key，通过对 key 的 value 进行hash 选出一个 patition 3、 patition 和 key 都未指定，使用轮询选出一个 patition。
4.3 写入流程
producer 写入消息序列图如下所示：
流程说明：
1、 producer 先从 zookeeper 的 "/brokers/.../state" 节点找到该 partition 的 leader 2、 producer 将消息发送给该 leader 3、 leader 将消息写入本地 log 4、 followers 从 leader pull 消息，写入本地 log 后 leader 发送 ACK 5、 leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 发送 ACK
五、broker保存消息
5.1 存储方式
物理上把 topic 分成一个或多个 patition（对应 server.properties 中的 num.partitions=3 配置），每个 patition 物理上对应一个文件夹（该文件夹存储该 patition 的所有消息和索引文件），如下：
5.2 存储策略
无论消息是否被消费，kafka 都会保留所有消息。有两种策略可以删除旧数据：
1、 基于时间：log.retention.hours=168 2、 基于大小：log.retention.bytes=1073741824
六、Topic的创建和删除
6.1 创建topic
创建 topic 的序列图如下所示：
流程说明：
1、 controller 在 ZooKeeper 的 /brokers/topics 节点上注册 watcher，当 topic 被创建，则 controller 会通过 watch 得到该 topic 的 partition/replica 分配。
2、 controller从 /brokers/ids 读取当前所有可用的 broker 列表，对于 set_p 中的每一个 partition：
2.1、 从分配给该 partition 的所有 replica（称为AR）中任选一个可用的 broker 作为新的 leader，并将AR设置为新的 ISR
2.2、 将新的 leader 和 ISR 写入 /brokers/topics/[topic]/partitions/[partition]/state
3、 controller 通过 RPC 向相关的 broker 发送 LeaderAndISRRequest。
6.2 删除topic
删除 topic 的序列图如下所示：
流程说明：
1、 controller 在 zooKeeper 的 /brokers/topics 节点上注册 watcher，当 topic 被删除，则 controller 会通过 watch 得到该 topic 的 partition/replica 分配。 2、 若 delete.topic.enable=false，结束；否则 controller 注册在 /admin/delete_topics 上的 watch 被 fire，controller 通过回调向对应的 broker 发送 StopReplicaRequest。
七、broker failover
kafka broker failover 序列图如下所示：
流程说明：
1、 controller 在 zookeeper 的 /brokers/ids/[brokerId] 节点注册 Watcher，当 broker 宕机时 zookeeper 会 fire watch
2、 controller 从 /brokers/ids 节点读取可用broker
3、 controller决定set_p，该集合包含宕机 broker 上的所有 partition
4、 对 set_p 中的每一个 partition
4.1、 从/brokers/topics/[topic]/partitions/[partition]/state 节点读取 ISR
4.2、 决定新 leader
4.3、 将新 leader、ISR、controller_epoch 和 leader_epoch 等信息写入 state 节点
5、 通过 RPC 向相关 broker 发送 leaderAndISRRequest 命令
八、controller failover
当 controller 宕机时会触发 controller failover。每个 broker 都会在 zookeeper 的 "/controller" 节点注册 watcher，当 controller 宕机时 zookeeper 中的临时节点消失，所有存活的 broker 收到 fire 的通知，每个 broker 都尝试创建新的 controller path，只有一个竞选成功并当选为 controller。
当新的 controller 当选时，会触发 KafkaController.onControllerFailover 方法，在该方法中完成如下操作：
1、 读取并增加 Controller Epoch。 2、 在 reassignedPartitions Patch(/admin/reassign_partitions) 上注册 watcher。 3、 在 preferredReplicaElection Path(/admin/preferred_replica_election) 上注册 watcher。 4、 通过 partitionStateMachine 在 broker Topics Patch(/brokers/topics) 上注册 watcher。 5、 若 delete.topic.enable=true（默认值是 false），则 partitionStateMachine 在 Delete Topic Patch(/admin/delete_topics) 上注册 watcher。 6、 通过 replicaStateMachine在 Broker Ids Patch(/brokers/ids)上注册Watch。 7、 初始化 ControllerContext 对象，设置当前所有 topic，“活”着的 broker 列表，所有 partition 的 leader 及 ISR等。 8、 启动 replicaStateMachine 和 partitionStateMachine。 9、 将 brokerState 状态设置为 RunningAsController。 10、 将每个 partition 的 Leadership 信息发送给所有“活”着的 broker。 11、 若 auto.leader.rebalance.enable=true（默认值是true），则启动 partition-rebalance 线程。 12、 若 delete.topic.enable=true 且Delete Topic Patch(/admin/delete_topics)中有值，则删除相应的Topic。