kafka为何需要High Available

一、为何需要replication

kafka0.8以前的版本中，是没有Replication的，一旦某一个Broker宕机，则其上所有的partition数据都不可被消费，这与kafka数据持久性及Delivery担保设计目标相悖，同时producer都不能再将数据保存于这些partition中。

1.1 如果producer使用同步模式则producer会再尝试重新发送message.send.max.retries(默认值是3）次后会抛出Exception，用户可以选择停止发送后续数据也可选择继续发送。而前者会造成数据阻塞，后者会造成本应发往该broker的数据丢失。

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

由此可见，在没有replication的情况下，一旦某机器宕机或者某个broker停止工作则会造成整个系统的可用性降低，随着集群规模的增加，整个集群中出现该类异常的几率大大增加，因为对于生产系统而言replication机制引入非常重要。

二、为何需要leader Election

leader 选举主要是指replition之间的leader选举

引入replication之后，同一个partition可能会有多个replica，而这时需要再这些replicationn直接选举一个leader，producer和consumer只与这个leader交互，其他replica作为followe从leader中复制数据。

因为需要保证同一个partition的多个replica之间的数据一致性（其中一个宕机后其他replica必须要能继续服务并且即不能造成数据丢失）如果没有一个leader，所有的replication都可同时读/写数据，那就需要保证多个replica之间互相（N*N条通道）同步数据，数据的一致性和有序性非常难保证，大大增加了replication实现的复杂性，同时也增加了出现异常的几率，而引入leader后，只有leader负责数据读写，followe只向leader顺序fetch数据(N条通道），系统更加简单且高效。