从 Kafka 到 Pulsar：数据流演进之路

1、 消息队列概述

1.1 消息队列的应用场景

1.1.1 MQ 消息通道

优点：异步解耦、高可用、削峰填谷、消息订阅

1.1.2 EventBridge 事件总线

事件源：将云服务、自定义应用、SaaS 应用等应用程序产生的事件消息发布到事件集

事件集：存储接收到的事件消息，并根据事件规则将事件消息路由到事件目标

事件目标：消费事件消息

1.1.3 Data Platform 流数据平台

1. 提供批/流数据处理能力
2. 各类组件提供各类 Connect
3. 提供 Streaming/Function 能力
4. 根据数据 schema 灵活的进行数据预处理

1.2 主流消息队列的相关介绍

2、 Kafka 详解

2.1 Kafka 架构介绍

2.1.1 ZooKeeper

Kafka 存储数据：

1. Broker Meta 信息（临时节点）
2. Controller 信息（临时节点）
3. Topic 信息（持久节点）
4. 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 存在的问题：

1. 元数据存取困难
2. 元数据更新网络开销大
3. 强耦合违背软件设计原则
4. 网络分区复杂度高
5. 并发访问 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
  • 消息缓存在堆外，负责快速响应