Kafka学习笔记2——Kafka中的HA

《Kafka 设计解析（二）：Kafka High Availability （上）》 和《Kafka 设计解析（三）：Kafka High Availability （下）》学习笔记

保证Topic中的单个Partition高可用（Partition Replication）：

数据传播： Producer在发布数据到某个Parititon时，首先通过ZK找到Partition Leader，然后将数据push到Partition Leader；Parittion Leader接收到数据后会将数据记录到本地Log；

                  然后Paritition Follwer从Leader pull数据，然后将其写入本地Log，当Follower写入成功后会发送ACK给Leader。一旦所有ISR都返回了Replica成功的ACK，则认为该消息

                  已经成功Produce到Kafka，Leader会向Producer返回ACK并增加HW（HW标记了已备份完成的数据，Consumer只能消费已经备份完成的数据）。

需要说明的是，一条消息只有被 ISR 里的所有 Follower 都从 Leader 复制过去才会被认为已提交。这样就避免了部分数据被写进了 Leader，还没来得及被任何 Follower 复制就宕机了，而造成数据丢失（Consumer 无法消费这些数据）。而对于 Producer 而言，它可以选择是否等待消息 commit，这可以通过request.required.acks来设置。这种机制确保了只要 ISR 有一个或以上的 Follower，一条被 commit 的消息就不会丢失。

Partition Leader的选举：当原Partition Leader DOWN机时。Kafka Controller会从ISR中选取一个Follower作为新的Leader，如果没有在ISR中的Follower则任意选择一个Follower作为Leader，这样虽然会导致数据丢失但是保证了高可用行。

                                       如果所有的Follower也都DOWN机了，则这个Partition就挂了（个人理解）

 保证Kafka集群中的Controller高可用（ZK注册）：

Controller选举：当Kafka集群开始选举Controller时，所有Broker结点一起向ZK的Controller Path——/Controller注册一个临时结点。但是只会有一个Broker注册成功，这个Broker会成为Kafka集群的Controller，由于只能注册成功一个临时结点其他Broker会注册失败，

                          其他Broker根据失败信息可以知道集群中已经存在一个Controller了。 Kafka Controller负责选择Partition Leader等工作。