Kafka基于Zookeeper搭建高可用集群实战

Kafka基于Zookeeper搭建高可用集群实战

1 前言
1.1 高可用的由来
为何需要Replication？
在Kafka在0.8以前的版本中，是没有Replication的，一旦某一个Broker宕机，则其上所有的
Partition数据都不可被消费，这与Kafka数据持久性及Delivery Guarantee的设计目标相悖。同时
Producer都不能再将数据存于这些Partition中。
如果Producer使用同步模式则Producer会在尝试重新发送message.send.max.retries（默认值
为3）次后抛出Exception，用户可以选择停止发送后续数据也可选择继续发送。而前者会造成数据的阻塞，后者会造成本应发往该Broker的数据的丢失。
如果Producer使用异步模式，则Producer会尝试重新发送message.send.max.retries（默认值
为3）次后记录该异常并继续发送后续数据，这会造成数据丢失并且用户只能通过日志发现该问题。同时，Kafka的Producer并未对异步模式提供callback接口。
由此可见，在没有Replication的情况下，一旦某机器宕机或者某个Broker停止工作则会造成整
个系统的可用性降低。随着集群规模的增加，整个集群中出现该类异常的几率大大增加，因此对于生产系统而言Replication机制的引入非常重要。
什么是Leader Election
引入Replication之后，同一个Partition可能会有多个Replica，而这时需要在这些Replication之间选出一个Leader，Producer和Consum