Kafka Leader-follower架构原理及常见场景技术问题咨询

1. 仅Leader节点可对日志进行读写操作，是否会导致Leader成为集群性能瓶颈？ #

这里的单Leader读写规则是针对单个分区生效，而非整个集群共用一个Leader。Kafka会将Topic拆分为多个分区，不同分区的Leader会均匀分布在集群的不同Broker节点上，读写流量会被分摊到所有Broker的Leader分区上，正常部署场景下不会出现全局性能瓶颈。
如果单个Topic的访问压力极高，对应的单分区Leader确实会成为该分区的性能瓶颈，此时可以通过增加该Topic的分区数量，将流量拆分到更多分区的Leader上，实现性能扩容。

2. 生产者误将数据发送至Follower节点，该节点会直接忽略请求还是会将请求转发至Leader？该场景是否可能发生？ #

• 该场景是可能出现的：正常情况下生产者启动时会拉取集群元数据，直接获取到目标分区的Leader地址，只会向Leader发送数据。但如果集群刚发生Leader切换，生产者本地缓存的元数据还未更新，就可能将请求发送到已经变为Follower的旧Leader节点。
• Follower节点不会转发请求，会直接返回NOT_LEADER_OR_FOLLOWER错误码。生产者收到该错误后会主动刷新集群元数据，获取最新的Leader地址后重试发送请求。

3. 消费者尝试从Follower节点读取数据，会出现什么情况？ #

该场景的表现和集群版本、配置有关：

• 2.4版本之前的Kafka，或者未开启追随者读取特性的集群，消费者向Follower发读取请求时，会收到NOT_LEADER_OR_FOLLOWER错误，消费者会自动刷新元数据，向对应分区的Leader发起读取请求。
• 2.4及以上版本的Kafka，若集群配置了replica.selector.class为RackAwareReplicaSelector，开启了机架感知的追随者读取特性，消费者可以正常从同机架的Follower节点读取数据，该特性常用于降低跨机架带宽消耗、降低读取延迟。

4. 是否有相关文档说明故障Broker节点重启时的消息交互流程？ #

Kafka官方标准文档中对故障Broker重启的交互流程有完整说明，核心流程如下：

1. 故障Broker重启完成后，会首先向集群Controller节点注册，同步当前节点存储的所有副本的基础状态
2. 该节点上的所有Follower副本，会向对应分区的Leader节点发起FETCH请求，同步重启期间缺失的消息，当副本的同步水位追上Leader后，会被重新加入分区的ISR列表
3. 若该节点上存在原本的Leader副本，集群会根据auto.leader.rebalance.enable配置项，决定是否触发Leader重平衡，将Leader角色切回该节点。

内容的提问来源于stack exchange，提问作者xeon