Kafka进阶之Replication

最新推荐文章于 2025-03-17 11:01:41 发布

2401_85822327

最新推荐文章于 2025-03-17 11:01:41 发布

阅读量417

点赞数 5

文章标签： kafka 分布式

本文链接：https://blog.youkuaiyun.com/2401_85822327/article/details/141110528

版权

概念

–

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

Leader Replica ：每个partition只能有一个leader replica，所有的producer的请求都会发送到这个leader replica，当然consumer可以从leader上consume数据也可以从follower replica中consume数据。
**Follower Repl

本文已被开源项目：【一线大厂面试真题解析+核心总结学习笔记+最新全套讲解视频+实战项目源码讲义】收录

ica** ：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。那我们如何来设置这个参数呢？一般考虑以下几个因素：