分布式流处理组件 - 理论篇：Broker
💯 作者：谢先生。 2014 年入行的程序猿。多年开发和架构经验。专注于 Java、云原生、大数据等技术。从 CRUD 入行，负责过亿级流量架构的设计和落地，解决了千万级数据治理问题。
📖 微信公众号、B 站：搜索「谢先生说技术」不定时更新 ～
📂 清单： goku-framework、【定期开源】享阅读II
前言
通过之前几章的介绍，我们对 Producer 有了一定的认识。接下来我们将开启新篇章：Broker 本次我们将从如下方面对 Broker 进行介绍
Broker 工作原理与 ZK
Broker 节点管理
Broker 副本选举、故障处理、放置策略等
Broker 数据存储、清除策略等
Broker 预计 4～5 章结束～
Broker
入门 Broker
我们先来对 Broker 有一个清晰的认识：Broker 是指 Kafka 集群中的一个节点，负责处理客户端请求、同时也处理客户端发送数据的存储与复制。Kafka 集群由多个 Broker 节点组成，并且每个 Broker 都有全局唯一的 id 标识～
可以说： Broker 是整个 Kafka 集群的基本单元，也是整个集群的核心组件。
QA：与物理器节点的关系
这里需要特别与服务器节点区别：
服务器节点是指 Kafka 集群中的物理与虚拟机器，可以是物理服务器、ECS 等机器。 同时 Broker 可以运行在单独的物理机器上，也可以当多个 Broker 执行在同一台物理机器。
因此，Broker 与物理器节点可以是一对一，也可以是多对一的关系
Broker 入门原理
Controller
一般集群模式分为主从模式、主备模式等。但是在 kafka 集群中各 broker 间不存在主从、主备的关系。但是为了能够更好的管理 broker 上下线、topic 分区等工作，broker 间会选取出 Controller 的角色，由当前角色做管理工作。 整个集群中只会出现一个 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记录的哪位 broker 节点当选 Controller 角色，当选时间等
其它更多内容大家可以自行查看
Kafka 在 2.8.0 之后推出了 Kraft 模式，Kafka-Kraft 模式部署能够省略 ZK 的维护
最后
到这里，多说一点：
Broker 部分更多是理论内容，代码部分偏少
本章作为 Broker 的入门介绍，到这里就全部结束，接下来介绍 Broker 负载均衡等相关内容期待～
往期内容
以下内容未出现在该平台，更多往期内容请点击查看，具体排序由下至上：
版权声明: 本文为 InfoQ 作者【谢先生说技术】的原创文章。
原文链接:【http://xie.infoq.cn/article/2e27ffe8eb2833ef68bfc0c06】。文章转载请联系作者。
还未添加个人签名 2022-07-01 加入
2014年入行的程序猿。多年开发和架构经验。专注于Java、云原生、大数据领域技术。负责过亿级流量架构的设计和落地，千万级数据治理问题。
评论