💯 作者： 谢先生。 2014 年入行的程序猿。多年开发和架构经验。专注于 Java、云原生、大数据等技术。从 CRUD 入行，负责过亿级流量架构的设计和落地，解决了千万级数据治理问题。

📖 微信公众号、B 站：搜索「谢先生说技术」不定时更新 ～

📂 清单： goku-framework、【定期开源】享阅读II

真的是好久都没有更新了，失业难过中😫

前言

在最开始我们就说过，Kafka 中存储消息数据看似在向 Topic 写入，但其实 Topic 只是逻辑上的概念，实际上数据最终都以 Partition 为落点。随后 Broker 会对 Partition 中的存储数据做进一步操作。与此同时 Producer 和 Consumer 都是跟 Partition 的 Leader 角色进行数据发送与消费。

顾名思义，这都是我们之前了解过的

本章我们针对 Broker 中的副本信息作细致介绍。本节内容包括：

• 副本基本信息

• 副本间 Leader 选举与故障处理

• Leader Partition 自平衡处理

• 人为干预 Partition 分布策略

把我们零碎的知识汇总起来～

副本

副本信息

我们在创建 Topic 的时候，会设置对应的分区数与副本因子，为了保证整个集群的健康，默认情况下 Kafka 集群会将分区与副本均匀的每一个 Broker 节点上。

而一般情况下，Broker 会将同一分区的 Leader 和 Follower 节点进行分离，这样主要为了保证：

• 为了防止当某个 Broker 节点出现宕机等问题，其余 Follower 能够快速升级。保证整个集群的高可用

• 为了提高数据的可靠性，避免由于单点故障而导致数据丢失等情况

这里需要注意的是：副本并不是说越多越好，如果副本数设置过多，会增加磁盘的存储空间，而且主从节点间的数据同步还会增加网络数据传输这里建议：

• 建议副本数配置 2，不要过多设置

故障处理

前面其实我们也提到过： 分区 Leader 角色承担与 Producer 和 Consumer 的读写交互，而 Follower 会从 Leader 分区中进行数据同步。但是我们必须能够想到：

• 如果由于出现网络或者 Broker 节点本身出现故障，导致分区无法正常交互，进而影响到整个集群健康

为了能够尽快对外提供服务，Kafka 也提供了故障处理机制。我们先从 Leader 故障处理来看：

Leader 故障处理

当 Leader 发生故障之后，首先 Controller 控制器会从 ZK 中查询该分区下的所有副本的 LEO，某个最大 LEO 所在的 Broker 将会被选举为 Leader 角色

选举原则一： 副本数据保存最全

如果存在多个副本的 LEO 相同，则 Controller 将会从 ISR 列表中选择一个副本所在 Broker 为 Leader。

ISR： 同步副本队列，当前集合表示其它副本及时于 Leader 进行数据同步，同步数据基本赶上了 Leader 的数据

如果 ISR 中不存在集合数据，那么将选择所有副本中第一个在线的 Broker 作为 Leader。

为了保证副本数据间的一致性，此时其它 Follower 需要与新的 Leader 进行数据同步：

• 其它 Follower 会先将各自的 log 文件中高于 HW 的部分截取，然后开始从新的 Leader 同步

Follower 故障处理

接下来我们看看当 Follower 出现故障之后会出现的问题：

首先，Follower 无法正常与 Leader 进行心跳且无法正常拉取数据，那么当等待replica.lag.time.max.ms时间之后将会被提出 ISR 列表

等待该 Follower 正常恢复之后，由于 Leader 还在正常处理消息中，必然会出现消息同步不及时的问题。

• 此时当前 Follower 节点会读取本地磁盘记录的 HW，并将 log 记录中高于 HW 的部分进行截取，然后从 HW 的位置开始从 Leader 进行同步

• 等待当前 Follower 的 LEO 与该 Partition 的 HW 持平，那么表示当前 Follower 可以重新加入到 ISR 集合中

Leader 分区自平衡机制

自平衡是 Kafka 在处理分区均匀分散的一种非常重要的机制。Kafka 本身会通过该机制将 Partition 均匀分散在每个 Broker 节点上。这样能够保证每个 Broker 节点的读写吞吐量都是平均的。

但是如果某些 Broker 节点故障出现宕机等问题，Controller 会快速对 Leader 和 Follwer 进行故障恢复处理，此时 Partition 容易集中在部分 Broker 节点上。

• 这样就会导致部分 Broker 节点的读写请求压力过高

• 而当 Broker 节点重启恢复之后，大概率都是 Follower 分区，这些节点上读写请求非常低。这样就很大程度上会造成集群负载不均衡。现在我们来看看 Kafka 是如何解决这种问题的～

核心参数

为了防止出现上述问题，kafka 提供三个配置项：

• auto.leader.rebalance.enable当前参数默认为true，也就是说默认自动开启 LeaderPartition 平衡检测机制。

其实在生产环境我们一般推荐将参数设置为false如果出现频繁自平衡调整，将会导致整个集群性能严重下降

• leader.imbalance.per.broker.percentage每个 Broker 允许的不平衡的比率。如果 broker 超过了设置的值，那么 Controller 就会触发自动平衡进行调整

默认 10%， 如果非要开启auto.leader.rebalance.enable， 建议将该值设置的略大一些

• leader.imbalance.check.interval.seconds
  

一般情况下比率与间隔时间都是相辅出现的: 如果迟迟没有达到leader.imbalance.per.broker.percentage设置的值，那么 Broker 将在等待leader.imbalance.check.interval.seconds之后检查集群是否平衡

检查每个 Broker 节点下 Leader Partition 是否平衡的间隔时间。默认为 300 秒

人为干预副本分配

手动调衡副本的方式其实非常简单，我们在上一节《Broker 节点负载》中也介绍过执行命令，回忆回忆：

• kafka-reassign-partitions.sh
  

操作流程如下

1. 编写副本存储计划

{    "version": 1,    "partitions": [        {            "topic": "",           // topic名称            "partition": 0/1/2/3,  // 分区号            "replicas": [0,1]      // 想要放的broker节点        }    ]}

2. 执行当前计划

kafka-reassign-partitions.sh --bootstrap-server master:9092 --reassignment-json-file jsonfile.json --execute

3. 对当前执行计划进行校验

kafka-reassign-partitions.sh --bootstrap-server master:9092 --reassignment-json-file b.json --verify

如此这般，就能实现手动管理副本的功能。

最后

到此本节内容结束，基于概念性内容居多，希望大家多看多理解。后面为大家介绍关于 Broker 中消息数据的存储与过期等内容。 期待～