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 是均匀的
2.5.4 指标可视化
3、 Pulsar 详解
3.1 Pulsar 架构介绍
3.1.1 Pulsar Proxy
Pulsar 客户端连接集群的两种方式：
- Pulsar Client -> Broker
- Pulsar Client -> Proxy
Pulsar Proxy 的作用及应用场景：
- 部分场景无法知道 Broker 地址，如云环境或 Kubemetas 环境
- Proxy 提供类似 GateWay 代理能力，解耦客户端和 Broker，保障 Broker 安全
3.1.2 Pulsar Broker
Pulsar Broker 无状态组件，负责运行两个模块
Http 服务器
- 暴露了 restfull 接口，提供生产者和消费者 topic 查找 api
调度分发器
- 异步的 top 服务器，通过自定义二进制协议进行数据传输
Pulsar Broker 作为数据层代理
Bookie 通讯
- 作为 Ledger 代理负责和 Bookie 进行通讯
流量代理
- 消息写入 Ledger 存储到 Bookie
- 消息缓存在堆外，负责快速响应
