这是我参与「第四届青训营」笔记创作活动的第12天
本节课程目录：
- 消息队列概述
- Kafka 详解
- Pulsar 详解
- 周边和生态
1. 消息队列概述
1.1 消息队列的应用场景
1.1.1 MQ 消息通道
1.1.2 EventBridge 事件总线
事件源：将云服务、自定义应用、SaaS 应用等应用程序产生的事件消息发布到事件集
事件集：存储接收到的事件消息，并根据事件规则将事件消息路由到事件目标
事件目标：消费事件消息
1.1.3 Data Platform 流数据平台
- 提供批/流数据处理能力
- 各类组件提供各类 Connect
- 提供 Streaming/Function 能力
- 根据数据 schema 灵活的进行数据预处理
1.2 主流消息队列的相关介绍
2. Kafka 详解
2.1 Kafka 架构介绍
2.1.1 ZooKeeper
Kafka 存储数据：
- Broker Meta 信息（临时节点）
- Controller 信息（临时节点）
- Topic 信息（持久节点）
- Config 信息（持久节点）
-
选举机制
- Paxos 机制
-
提供一致性
- 写入（强一致性）
- 读取（会话一致性）
-
提供可用性
- 一半以上节点存活即可读写
-
提供功能
- watch 机制
- 持久/临时节点能力
2.1.2 Broker
-
Broker 角色
- 若干个 Broker 节点组成 Kafka 集群
- Broker 作为消息的接收模块，使用 React 网络模型进行消息数据的接收
- Broker 作为消息的持久化模块，进行消息的副本复制以及持久化
- Broker 作为高可用模块，通过副本间的Failover 进行高可用保证
2.1.3 Controller 选举
-
Controller 选举
- Broker 启动会尝试去 zk 中注册 controller 节点
- 注册上 controller 节点的 broker 即为 controller
- 其余 broker 会 watch controller 节点，节点出现异常则进行重新注册
-
Controller 作用
- Broker 重启/宕机时，负责副本的 Failover 切换
- Topic 创建/删除时，负责 Topic meta 信息广播
- 集群扩缩容时，进行状态控制
- Partition/Replica 状态机维护
2.1.4 Coordinator
-
Coordinator 介绍
-
负责 topic-partition <-> consumer 的负载均衡
-
根据不同的场景提供不同的分配策略
- Dynamic Membership Protocol
- Static Membership Protocol
- Incremental Cooperative Rebalance
-
2.2 Kafka 高可用
可用性定义
-
Kafka 高可用
-
副本同步机制
- 提供 isr 副本复制机制，提供热备功能
- 写入端提供 ack=0，-1，1机制，控制副本同步强弱
-
副本切换机制
- 提供 clean/unclean 副本选举机制
-
2.2.1 Kafka 副本 ISR 机制
-
AR
- Assign Replica，以及分配的所有副本
-
OSR
- Out Sync Replica，很久没有同步数据的副本
-
ISR
- 一直都在同步数据的副本
- 可以作为热备进行切换的副本
- min.insync.replicas 最少 isr 数据配置
2.2.2 Kafka 写入 Ack 机制
-
Ack = 1
- Leader 副本写入成功，Producer 即认为写成功
-
Ack = 0
- OneWay 模式
- Producer 发送后即为成功
-
Ack = -1
- ISR 中所有副本都成功，Producer 才认为写成功
2.2.3 Kafka 副本同步
-
LEO
- Log End Offset，日志最末尾的数据
-
HW
- ISR 中最小的 LEO 作为 HW
- HW 的消息为 Consumer 可见的消息
2.2.4 Kafka 副本选举
-
Clean 选举
- 优先选取 lsr 中的副本作为 leader
- 如果 lsr 中无可用副本，则 partition 不可用
-
Unclean 选举
- 优先选取 lsr 中的副本作为 leader
- 如果 lsr 中无可用副本，则选择其他存活副本
2.3 Kafka 集群扩缩容
2.3.1 Kafka 集群扩缩容的目标
-
Topic 维度
- partition 在各个 broker 之间分布是均匀的
- 同一个 partition 的 replica 不会分布在一台 broker
-
Broker 维度
- Broker 之间 replica 的数量是均匀的
2.3.2 Kafka 集群扩容步骤
-
扩容 Broker 节点
- Leader 副本写入成功，Producer 即认为写成功
-
计算均衡的 Replica 分布拓扑
- 保证 Topic 的 partition 在 broker 间分布均匀
- 保证 Broker 之间 Replica 分布均匀
-
Controller 负责新的副本分布元数据广播
- Controller 将新的 leader/follower 信息广播给 broker
-
Broker 负责新副本的数据同步
- Broker 上有需要同步数据的副本则进行数据同步
2.3.3 Kafka 集群缩容步骤
-
计算均衡的 Replica 分布拓扑
- 保证 Topic 的 partition 在 broker 间分布均匀
- 保证 Broker 之间 Replica 分布均匀
-
Controller 负责新的副本分布元数据广播
- Controller 将新的 leader/follower 信息广播给 broker
-
Broker 负责新副本的数据同步
- Broker 上有需要同步数据的副本则进行数据同步
-
下线缩容的 Broker 节点
- 数据同步完毕之后下线缩容的 Broker 节点
2.3.4 Kafka 集群扩缩容问题
-
扩缩容时间长
- 涉及到数据迁移，在生产环境中一次扩缩容可能要迁移 TB 甚至 PB 的数据
-
扩缩容期间集群不稳定
- 保证数据的完整性，往往会从最老的数据进行同步，这样会导致集群时刻处于从磁盘读取数据的状态，disk/net/cpu 负载都会比较高
-
扩缩容期间无法执行其他操作
- 在一次扩缩容操作结束之前，无法进行其他运维操作（扩缩容）
2.4 Kafka 未来演进之路
2.4.1 Kafka 去除 zk 依赖
依赖 ZooKeeper 存在的问题：
- 元数据存取困难
- 元数据更新网络开销大
- 强耦合违背软件设计原则
- 网络分区复杂度高
- 并发访问 zk 问题多
2.4.2 Kafka 依赖 KRaft
-
Process.Roles = Broker
- 服务器在 KRaft 模式下充当 Broker
-
Process.Roles = Controller
- 服务器在 KRaft 模式下充当 Controller
-
Process.Roles = Broker，Controller
- 服务器在 KRaft 模式下充当 Broker 和 Controller
-
Process.Roles = null
- 集群就假定是运行在 ZooKeeper 模式下
2.5 Kafka 运维/调优经验介绍
2.5.1 Kafka 单机吞吐
-
Kafka Version：2.3.1
-
机器配置：
- 40C 500GB 12 * 1TB 25GB
-
写入配置：
- Ack = -1，replica = 3，in_sync_replica = 3
- 单条消息 5 KB
-
吞吐
- 单机 150MB/s
2.5.2 Kafka 集群参数配置
2.5.3 扩缩容优化
目标
- Topic-Partition 均匀分布在 Broker 间
- Broker 间的 Replica 是均匀的
