Replication这个词相信大家都不会陌生，在很多分布式系统中，我们都需要Replication来保证Availability和Durability，Kafka也不例外，它也是利用Replication来保证某个节点发生问题的时候仍然能够保证数据不丢失并正常工作。本文就来详细聊一聊Kafka中的Replication。

概念

我们在前面提过Kafka的数据是根据topic来组织的，每个topic可以有很多个partition，每个partition可以有多个replica。这些replica都保存在brokers上，每个broker可能保存成百上千个replica。总得来说有两种replica：

1. Leader Replica：每个partition只能有一个leader replica，所有的producer的请求都会发送到这个leader replica，当然consumer可以从leader上consume数据也可以从follower replica中consume数据。
2. Follower Replica：partition中除了leader之外的replica就称之为follower replica，follower的数目可以自由配置，不像leader只能有一个。它的主要任务就是保持和leader同步，当旧的leader出现问题的时候它能够快速被promote到leader，从而保证availability。我们可以从follower中读，也可以只从leader读，这个是可以配置的。

从follower读

早期的Kafka只支持从leader读，并不支持从follower读。当时实现这个feature的原因主要是因为有时Kafka cluster会在多个数据中心，这样一来client假如还是一直只能从leader读取的话，网络的cost就会很大（跨DC的网络资费是很贵的），所以为了让client可以从离他最近的replica来读取数据，就需要实现follower的读支持。所以最初实现这个feature并不是因为leader的读traffic太大，想要load balance读的traffic（常见的一个replica读的原因），而是因为跨DC的cost，所以有时钱才是王道啊。

要实现支持follower读就需要实现两个功能：1）Fetch的protocol支持follower fetch。2）实现一个找到“最近”的replica的算法。

我们先来聊聊如何找“最近”的replica，其实开始有两个思路可以实现，一个是让client来查询broker中的meta data（比如说rackId， host information等），然后自己决定。另一种方法是由broker来根据client的信息决定哪个replica最好。当时选择的是后者，原因比较简单，是因为broker知道的信息更多一些，它甚至可以考虑备选replica的负载等各种因素，从而决定一个“最近”的replica，而不是单纯物理距离来判断。

而Fetch的protocol修改主要的保证是当我们从follower读数据的时候，只有被committed的message才能被consumer读取。这样我们就能保证从follower读和从leader读是类似的。要做到这件事，就需要所有的replica知道leader已经committed了哪个message，这就要求leader在发送数据到replica的时候，需要同时把high-water mark（last committed offset，详情见《Kafka基础介绍之消息commit》）发送给follower。这里需要额外注意的就是正是因为需要这个high-water mark的传送，所以follower其实是相比于leader是有一个延迟的。

Leader和follower的sync

Leader除了满足producer/consumer的request请求之外，一个很重要的工作就是和follower保持sync，它需要知道哪些follower目前是in-sync的，哪些follower不是。

Follower为了保持和Leader同步，需要给leader发送Fetch的request，就像一个consumer一样，不停地从leader那边获取数据。我们在《Kafka基础介绍之Consumers》中提到，获取数据的request中需要传入一个offset的值，表示下一步需要获取的信息的offset，而leader正是通过这个参数来知道follower都已经有了哪些数据，从而来判断follower的状态。

默认设置下，当一个follower有10s（可以配置）都没有发送fetch的request，那么则认为它是out-of-sync的，或者一个follower连续10s（同样可以配置）都没有能够catch-up到最新的message，也会认为它是out-of-sync。只有in-sync的follower才能成为新的leader candidate（unclean leader enable则是例外，后面会详细解释）。

这里还有一个特殊的节点：preferred leader，这个节点是当partition创建的时候的第一个leader，这个leader其实是考虑了各种load balance的。当这个节点不是leader的时候，只要它是in-sync的并且auto.leader.rebalance.enable=true，就会重新做leader election，让leader能够回到这个preferred的leader上。

Replication参数

我们前面也提到了一个partition可以有多个replication，那么究竟几个replication呢，这是由replication Factor决定的，当我们设置这个值为N的时候，就意味着我们有1个leader，N-1个follower。那我们如何来设置这个参数呢？一般考虑以下几个因素：

1. Availability：这个比较容易理解，要想availability提高，那么就需要提高replication的数目。
2. Durability：和Availability类似，因为replication都有数据的拷贝，也就意味着一个节点出现比如disk的问题，那么数据并不会丢失，同样的，replication的数目越高，Durability越好。
3. Throughput：这里有两个因素需要考虑，越多的replication就意味着我们需要同步数据的traffic越多，但同时因为我们可以从follower进行读，也就意味着我们的读的速度会越高。这里需要两者综合考虑。
4. End-to-end latency：假如我们的producer设置的是全部replica成功才返回，那么越多的replication数目则意味着latency越大。
5. Cost：这个其实影响是最大的，也是我们通常来说只设置成3的主要原因，因为每多一份replication，你就需要一份的cost来支付存储，网络等等资源。所以通常来说会选择3来达到一定的availability和durability，又不会有太多的cost。

Unclean leader election

我们上面提到只有in-sync的follower才会成为leader的candidate，这个也很容易理解，毕竟那么out-of-sync的follower要是成为leader，就会导致数据的丢失，但是有时我们需要考虑一些特殊情况。比如说，因为网络的原因，还存活的follower都是out-of-sync的，这个时候leader要是crash了，我们是牺牲availability等leader回来，还是接收一个out-of-sync的follower成为leader呢？这就是一个trade off，没有哪种是必然正确的，需要你结合具体的应用情况来进行判断。如果你允许这种情况下out-of-sync的follower成为新的leader，也就是说允许一部分message的lose，那么你需要把unclean.leader.election.enable设置为true，它默认是false。

另外一个方面来解决这个纠结的选择就是每次producer写的时候都让它至少写到两个replica中才返回（当然这个也意味着producer的写在一些情况下会变慢），这里至少写几个replica是由min.insync.replica设置的。

总结

至此，本文就把Kafka中的replication相关的概念都介绍完成了，希望对感兴趣的同学有所帮助。