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

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

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

最近一直在对分布式流处理组件Kafka进行介绍，内容一直未进行同步，已将往期内容地址贴于文章底部，大家按需查看～

前言

通过之前几章的介绍，我们对Producer有了一定的认识。接下来我们将开启新篇章：Broker
本次我们将从如下方面对Broker进行介绍

• Broker工作原理与ZK
• Broker节点管理
• Broker副本选举、故障处理、放置策略等
• Broker数据存储、清除策略等

Broker预计4～5章结束～

Broker

入门Broker

可以说： Broker是整个Kafka集群的基本单元，也是整个集群的核心组件。

QA：与物理器节点的关系

这里需要特别与服务器节点区别：

• 服务器节点是指Kafka集群中的物理与虚拟机器，可以是物理服务器、ECS等机器。 同时Broker可以运行在单独的物理机器上，也可以当多个Broker执行在同一台物理机器。

因此，Broker与物理器节点可以是一对一，也可以是多对一的关系

Broker入门原理

Controller

Controller一般是与Zookeeper协助管理整个Kafka集群

选举过程

既然Controller是由broker间的选举，那么它们的选举流程是什么呢？ 其实非常简单：

• 在每个broker启动时，都会与zookeeper进行交互，而第一个创建成功/controller的broker节点即被选举为Controller
  
  讯享网

Controller职责

当某个broker成功当选Controller之后，那么他将为整个Kafka集群服务，包括但不限定于：

• 集群内Broker节点管理： 包括新增、下线等
• 副本Leader选举、分区重分配

总之，所有与Zookeeper相交互的工作，都是Controller角色来完成

- 集群内Broker节点管理

所有Broker在启动之后都会向/brokers/ids下注册一个临时节点，Controller所在Broker节点通过watch功能监听节点变化，一旦/brokers/ids下的节点信息发生创建、删除、数据变化等，Controller就能通过监听回调的方式尽快对节点变化做出响应。 例如：

• 当集群中Broker下线
  当某个Broker由于某种原因下线，/brokers/ids下对应信息发生删除，进而通知到Controller节点。
  下线之后，存在与该Broker上的Leader分区将不再可用，此时为了最大程度减少集群对外响应时间，Controller将快速找到替代的Leader分区。保证集群的正常可用～

- Leader选举、分区重分配

将Topic分区副本均匀的分布在集群的不同Broker上，最大程度的保证了集群的负载均衡。而当Broker节点发生变化，例如某个Broker下线，那么其它Broker上的分区副本会被选举为Leader。
Controller在选举Leader过程中，都是基于ISR列表来选择，如果副本不存在与ISR中，它是没有选举资格的～
为了最大程度的保证集群的负载均衡能力，kafka会定期对一些分区进行Leader重新选举。而在此过程中有可能会出现原先Follower升级为Leader分区，此时客户端通信、副本交互等请求都会做相应的调整。

auto.leader.rebalance.enabled=true，建议生产环境设置为false

那至于更多更详细的部分，后面在介绍broker节点与副本管理的时候还会细致说明～

Controller故障与脑裂

当Controller所属broker节点发生故障下线，而在Kafka集群中必须存在一个Controller进行集群管理，那么：

• 由于旧Controller与Zookeeper间链接中断，造成会话失效，从而导致注册的/controller节点被删除。
• 基于Zookeeper事件监听机制，其余的Broker节点发现这一现象并且开始争抢注册，例如Broker2成功在Zookeeper中创建，此时Broker2就是会成为新的Controller角色

— 这是一条分割线

集群属于分布式环境，进而有多种因素会造成Broker与Zookeeper间的会话失效，例如：

• 网络波动造成Controller与Zookeeper连接会话失效
• 长时间GC无响应导致与Zookeeper连接会话失效
• …

而如上原因也必将导致旧Controller无法接收到新Controller选举结果，那么当网络或者GC恢复之后，由于缺少了部分记忆，旧Controller还以为自己是Controller角色，在集群中就出现两个Controller角色，发出具有冲突性的命令。从而导致脑裂现象出现。

脑裂现象在分布式场景下非常常见，参考CAP定理

而脑裂问题不解决，会导致严重数据不一致现象。故而在Kafka中引入了epoch number来解决这个问题

• epoch number仅仅是一个单调递增的数字，每次Controller角色的选举都会加1，同时Zookeeper回调会将当前epoch number通知到其它broker节点
• 如果在Controller发布的命令中，包含了比当前epoch number更小的值，那么broker会忽略这条命令，不做任何操作

Zookeeper因为故障选举Leader也有类似的机制

Broker工作原理

接下来回到正题，关于Broker工作流程其实我们已经介绍过一部分了，接下来我们来看：

• kafka集群间的Broker节点在启动后会向ZK注册启动信息，具体注册在/brokers/ids下
• 同时还会去/controller下注册，那个Broker节点注册成功，就会成为Controller，并且Controller会监听/broker/ids下broker的节点变化信息，用来节点管理、分区等
• Topic属于逻辑概念，Topic下的Partition属于物理概念真实存在。Partition属于主从结构，Controller会根据ISR中存活为前提，按照AR排序优先原则选举出Partition的Leader分区
• 如果Controller检测到Broker的Leader挂掉，那么Controller将会从ZK中获取ISR列表并且开始选举新的Leader，ZK在topic下更新leader以及isr列表
• 而如果Controller发生故障，/controller会话失效，其它Broker节点谁能在/controller下注册成功，即为Controller，并且epoch number递增
• 而新的Controller从ZK中同步到相关数据，从而能够维持集群的正常运行

ZK存储信息

而关于Kafka与ZK交互存储了多少信息，我们一点点来看：

本人用一张图来列出其中关键的部分，如图

• /brokers/ids下记录了整个集群中有多少broker节点，对应的[0,1,2]即为broker配置中的broker.id信息，内容如下所示
  
• /brokers/topics/{topic}/partitions/[0,1,2]/state下记录了相关Topic中各分区的相关信息，包括Leader、ISR列表，如下所示

{ 
    "controller_epoch" : 5, "leader": 2, "version" : 1, "leader_epoch": 3, "isr”: [ 2, 0] } 

• /controller记录的哪位broker节点当选Controller角色，当选时间等

讯享网{ 
   "version":1,"brokerid":2, "timestamp":"13"} 

其它更多内容大家可以自行查看

Kafka在2.8.0之后推出了Kraft模式，Kafka-Kraft模式部署能够省略ZK的维护

最后

到这里，多说一点：

• Broker部分更多是理论内容，代码部分偏少

往期内容

以下内容未出现在该平台，更多往期内容请点击查看，具体排序由下至上：

• 分布式流处理组件-优化篇：Producer生产调优之数据可靠性
• 分布式流处理组件-优化篇：Producer生产调优之核心参数
• 分布式流式处理组件-理论篇： Producer分区
• 分布式流处理组件-理论篇：Producer入门理论
• 分布式流处理组件-理论实战结合篇：Kafka实战演练，基操勿6~
• 分布式流处理组件-理论实战结合篇：Kafka架构理论
• 分布式流处理组件-理论篇：Kafka与安装配置