Kafka集群内复制功能深入剖析

Kafka是一个分布式发布订阅消息系统。由LinkedIn开发并已经在2011年7月成为apache顶级项目。kafka在LinkedIn, Twitte等许多公司都得到广泛使用，主要用于：日志聚合，消息队列，实时监控等。

　　0.8版本开始，kafka支持集群内复制，从而提高可用性和系统稳定性，这篇文章主要概述kafka复制的设计。

　　复制

　　有了复制后，kafka客户端将会得到如下好处：

　　生产者能在出现故障的时候继续发布消息，并且能在延迟和持久性之间选择，取决于应用。

　　消费者能在出现故障的时候继续实时接受正确的消息。

　　所有的分布式系统必须在一致性，可用性，分区容错性之间进行权衡并做出取舍(参考CAP定理)，kafka的目标是在单个数据中心里的kafka集群也支持复制。网络分区是比较少见的，因此kafka设计专注于高可用和强一致。强一致意味着所有副本数据完全一致，这简化了应用程序开发人员的工作。

　　kafka是一个基于CA的系统(???)，zookeeper是一个基于CP的系统(很确定)，eureka是一个基于AP的系统(很确定)。

　　复制强一致

　　现有比较成熟的方案中，有两种保持强一致性复制的典型方法。这两种方法都需要副本中的一个被设计为leader，所有写入都需要发布到该副本。leader负责处理所有的接入。并广播这些写到其他follower副本，并且要保证复制顺序和leader的顺序一致。

　　第一种方法是基于法定人数。leader等待直到大多数副本收到数据。当leader出现故障，大多数follower会协调选举出新的leader。这种方法被用于Apache Zookeeper 和Google's Spanner.

　　第二种方法是leader等待所有副本收到数据(重要说明：在kafka中这个"所有"是所有的In-Sync Replicas)。如果leader出现故障，其他副本能被选举为新的leader。

　　kafka复制选择的是第二种方法，有两个主要原因：

　　相同数量的副本情况下，第二种方法能承受更多的容错。例如，总计2n+1个副本，第二种方法能承受2n个副本故障(只要还有一个ISR，就能正常写入)，而第一种方法只能承受n个副本故障。如果在只有两个副本的情况下，第一种方法不能容忍任意一个副本故障。

　　第一种方法延迟性表现更好，因为只需要法定人数确认即可，所以会隐藏掉一些比较慢的副本的影响。而kafka副本被设计在相同的数据中心的一个集群下。所以网络延迟这种变数是比较小的。

　　术语