Kafka——高可用

一.高可用的由来

1.1 为什么需要Replication 

在Kafka在0.8之前的版本中，是没有Replication，一旦某个broker宕机，则其上的所有Partition数据都不可被消费，这与Kafka的数据持久化和Delivery Guarantee设计原则相违背。

如果Producer使用同步模式则Producer则会在尝试重新发送message.send.max.retries（默认值是3）次后抛出异常，用户可以选择停止发送后续数据或者继续发送。而前者会造成数据的阻塞，后者会造成发送到Kafak数据的丢失。

如果Producer使用异步模式，则Producer会尝试重新发送message.send.max.retries（默认值是3）次后记录该异常并继续发送后续数据，这会造成数据丢失并且用户只能通过日志发现问题。同时，Kafka的Producer并没有对异步模式提供fallback接口。

由此可见，在没有Replication的情况下，一旦某机器宕机或者某个Broker停止工作会曹成整个系统的可用性的降低。随着集群规模的增加，整个集群中出现该类异常的几率大大增加，由此可见，Replication的引入是很有必要的。

1.2 Leader Election

引入Replication之后，同一个Partition可能会有多个Replica，而在这些之中需要选取一个Leader，Producer和Comsumer只会和这个Leader交互，其他作为Follower从Leader中复制数据。

因为需要保证同一个Partition中多个副本之间的数据一致性（其中一个宕机后其他副本必须继续服务，不能造成数据重复也不能造成数据丢失）。如果没有一个leader，所有副本都可同时读写数据，则需要多个副本之间联通，数据一致性和有序性非常难保证。引入leader之后，leader负责读写，follower只需要从leader中fetch数据。

二.Kafka 高可用设计分析

2.1 如何将所有Replica均匀分布整个集群