Kafka HA机制

就像前文所介绍的那样，Kafka有各种方式去提高吞吐率，可是如果只有一个Broker，当这个Broker 宕机或者这个broker所挂载的磁盘坏掉后，即使有各种分区、消费机制，也都没有用了，数据也就丢失了，所以Kafka需要提供高可用，不止一个Broker提供服务，也需要有多个Broker。那么当多个Broker启用后，Kafka如何工作呢，数据又是如何存储，以保证Kafka集群的稳定性和可恢复性呢。这就是这篇文章所要探讨的内容了。

---

1. 消息需要Replication（副本），默认情况下 Replication数为1，但是当消息副本数大于1时，即使当Broker停止工作时，也可以极大保证数据不丢失。
2. 假设一条消息有N个副本，如果每个副本都负责读写，那么数据一致性的处理就会很麻烦，很难保证一致性和有序性。但是如果这N个副本的“地位”不一样时，有一个副本是Leader，其他的N-1 个 Replica都是Follower，那么这大大减少了Replication的复杂程度，系统会更加简单且高效，只有Leader负责数据读写，Follower只是复制数据，即只向Leader顺序Fetch数据。

---

关于Replication

尽量将所有的Partition均匀分配到整个集群上，已达到负载均衡。同时为了提高Kafka的容错能力，也需要将同一个Partition的Replica尽量分散到不同的机器。当某个Broker宕机了，需要保证它上面的负载可以被均匀的分配到其它幸存的所有Broker上。

Kafka分配Replica的算法如下：
将所有Broker（假设共n个Broker）和待分配的Partition排序
将第i个Partition分配到第（i mod n）个Broker上
将第i个Partition的第j个Replica分配到第（(i + j) mod n）个Broker上

关于Propagate

关于Kafka的复制机制，并不是完全的同步复制，因为如果是同步复制要求所有能工作的Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。
Kafka的复制机制也不是单纯的异步复制。
Kafka复制的几大关键点：

1. 每次数据写入时，只有ISR中的所有Replica都复制完，Leader才会将其置为Commit，它才能被Consumer所消费。
2. Producer发布数据时，Leader并不需要ISR中的所有Replica同步该数据才确认收到数据。
3. Producer可以通过acks参数指定最少需要多少个Replica确认收到该消息才视为该消息发送成功。
   1）acks的默认值是1，即Leader收到该消息后立即告诉Producer收到该消息，此时如果在ISR中的消息复制完该消息前Leader宕机，那该条消息会丢失。
   2）如果将该值设置为0，则Producer发送完数据后，立即认为该数据发送成功，不作任何等待，而实际上该数据可能发送失败，并且Producer的Retry机制将不生效。
   3）acks设置为all或者-1，这是推荐的做法，只有ISR中的所有Replica都收到该数据（也即该消息被Commit），Leader才会告诉Producer该消息发送成功，从而保证不会有未知的数据丢失。

关于Leader Election

就像前文所提到的，无论是为了简化副本间的同步，还是为了应对broker 宕机后的副本重分配，都涉及到一个重要环节，就是Leader选举。

controller负责选举leader

为防止Zookeeper负载过重（每个Replica都要为此在Zookeeper上注册一个Watch，当集群规模增加到几千个Partition时Zookeeper负载会过重），Kafka是在所有broker中选出一个controller，所有Partition的Leader选举都由controller决定。controller会将Leader的改变直接通过RPC的方式（比Zookeeper Queue的方式更高效）通知需为此作出响应的Broker。同时controller也负责增删Topic以及Replica的重新分配。

关于ISR

Leader会跟踪与其保持同步的Replica列表，该列表称为ISR（即in-sync Replica）。
使用ISR方案的原因：

1. 由于Leader可移除不能及时与之同步的Follower，故与同步复制相比可避免最慢的Follower拖慢整体速度，也即ISR提高了系统可用性。
2. ISR中的所有Follower都包含了所有Commit过的消息，而只有Commit过的消息才会被Consumer消费，故从Consumer的角度而言，ISR中的所有Replica都始终处于同步状态，从而与异步复制方案相比提高了数据一致性。
3. ISR可动态调整，极限情况下，可以只包含Leader，极大提高了可容忍的宕机的Follower的数量。与Majority Quorum方案相比，容忍相同个数的节点失败，所要求的总节点数少了近一半。
   例如，起初ISR如图：
   
   当down掉一个broker之后，ISR变更为
   

总结

kafka的设计很是复杂，对于各个环节是有各种保证处理机制，我只是了解皮毛。若想了解更多，请参考此系列文章。