kafka以高吞吐量，低延迟，可扩展性据称，并被在越来越多的场景中应用，在其地位越来越高的同时，对其稳定性的要求就越高，今天就来说说kafka的高可用。
在讲kafka高可用之前，先介绍一下ISR。LSR全称（in-sync replica）， LSR是 Kafka 为某个partition维护的一组同步集合，每个partition都有自己的一个 ISR 集合，处于 ISR 集合中的副本，意味着 follower 副本与 leader 副本保持同步状态，只有处于 ISR 集合中的副本才有资格被选举为 leader。一条 Kafka 消息，只有被 ISR 中的副本都接收到，才被视为“已同步”状态。这跟zookeeper 的同步机制不一样，zookeeper使用的是Raft协议，感兴趣的同学可以去看看Raft协议原理，zookeeper 只需要超过半数节点写入，就可被视为已写入成功。
说完LSR，就来说说，kafka怎么来实现高可用的，和hadoop一样，用多副本去实现高可用，当leader的服务器宕机之后，LSR副本服务器就会接管服务器，称为新的leader，继续为应用提供服务。
但是这里会有一个问题，leader与LSR副本之间同步模式，怎么才能做到数据一致性，不丢数据。
。
如果设置为0， producer 不会等broker的反馈。该消息会被立刻添加到 socket buffer 中并认为已经发送完成。在这种情况下，服务器是否收到请求是没法保证的，并且参数retries也不会生效（因为客户端无法获得失败信息）。
每个记录返回的 offset 总是被设置为-1。这个模式kafka的吞吐量最大，并发最高，但是数据易丢失，适用在一些记录应用日志，对数据要求不高的业务场景。
如果设置为1，leader节点会将记录写入本地日志，并且在所有 follower 节点反馈之前就先确认成功。在这种情况下，如果 leader 节点在接收记录之后，并且在 follower 节点复制数据完成之前产生错误，则这条记录会丢失。这个模式和mysql的主从异步复制一样，主从直接会有数据差异，此配置为kafka默认配置。平衡了数据安全和性能。
如果设置为all，这就意味着 leader 节点会等待所有同步中的LSR副本确认之后再确认这条记录是否发送完成。只要至少有一个同步副本存在，记录就不会丢失。这种方式是对请求传递的最有效保证，但是牺牲了性能为代价，适合对数据要求比较高的业务场景，在这里acks=-1与acks=all是等效的。
