从 Kafka 到 Pulsar 的数据流演进之路｜ 青训营笔记
# 从 Kafka 到 Pulsar 的数据流演进之路｜ 青训营笔记
这是我参与「第四届青训营 」笔记创作活动的的第 12 天
# 消息队列概述
# 消息队列的应用场景
- MQ 消息通道
- EventBridge 事件总线
- Data Platform 流数据平台
# MQ 消息通道
- 异步解耦
- 削峰填谷
- 高可用
- 发布订阅
# EventBridge 事件总线
- 事件源：将云服务、自定义应用、SaaS 应用等应用程序产生的事件消息发布到事件集。
- 事件集：存储接收到的事件消息，并根据事件规则将事件消息路由到事件目标。
- 事件目标：消费事件消息。
# Data Platform 流数据平台
- 提供批流数据处理能力
- 各类组件提供各类 Connect
- 提供 Streaming/Function 能力
- 根据数据 schema 灵活的进行数据预处理
# 主流消息队列的相关介绍
| RabbitMQ | RocketMQ | Kafka | Pulsar | |
|---|---|---|---|---|
| 推出时间 | 2007 | 2012 | 2010 | 2016 |
| 使用语言 | Erlang | Java | Scala/Java | Java |
| 单机吞吐量 | 一般 | 较高 | 高 | 高 |
| 延迟 | 低 | 低 | 一般 | 低 |
| 可用性 (分片) | 高 (主从架构) | 高 (主从架构) | 非常高 (分布式) | 非常高 (分布式) |
| 一致性 | 较高 | 高 | 高 | 高 |
| 扩展性 | 较高 | 高 | 高 | 非常高 |
# Kafka 详解
# Kafka 架构介绍
# Zookeeper
- 选举机制：Paxos 机制
- 提供一致性：写入 (强一致性)、读取 (会话一致性)
- 提供可用性：一半以上节点存活即可读写
- 提供功能：watch 机制 持久 / 临时节点能力
Kafka 在 Zookeeper 存储哪些数据：
- Broker Meta 信息 (临时节点)
- Controller 信息 (临时节点）
- Topic 信息 (持久节点）
- Config 信息 (持久节点)
# Broker
Broker 角色：
- 若干个 Broker 节点组成 Kafka 集群
- Broker 作为消息的接收模块，使用 React 网络模型进行消息数据的接收
- Broker 作为消息的持久化模块，进行消息的副本复制以及持久化
- Broker 作为高可用模块，通过副本问的 Failover 进行高可用保证
# Controller 选举
- Broker 启动会尝试去 zk 中注册 controller 节点
- 注册上 controller 节点的 broker 即为 controller
- 其余 broker 会 watch controller 节点，节点出现异常则进行重新注册
# Controller 作用
- Broker 重启 / 宕机时，负责副本的 Failover 切换
- Topic 创建 / 删除时，负责 Topic meta 信息广播
- 集群扩缩容时，进行状态控制
- Partition/Replica 状态机维护
# Coordinator
- 负责 topic-partition<-> consumer 的负载均衡
- 根据不同的场景提供不同的分配策略
- Dynamic Membership Protocol
- Static Membership Protocol
- Incremental Cooperative Rebalance
# Kafka 高可用
- 副本同步机制
- 提供 Isr 副本复制机制，提供热备功能
- 写入端提供 ack=0,-1,1 机制，控制副本同步强弱
- 副本切换机制
- 提供 clean/unclean 副本选举机制
# Kafka 副本 ISR 机制
- AR（Assign Replica）：已经分配的所有副本
- OSR（Out Sync Replica）：很久没有同步数据的副本
- ISR（in-sync replica set）：
- 一直都在同步数据的副本
- 可以作为热备进行切换的副本
- min.insync.replicas 最少 isr 数量配置，如果低于该参数设定则无法进行写入，保证集群副本一致性
# Kafka 写入 Ack 机制
- Ack = 1
- Leader 副本写入成功，Producer 即认为写成功
- Ack = 0
- OneWay 模式
- Producer 发送后即为成功
- Ack = -1
- ISR 中所有副本都成功，Producer 才认为写成功
# Kafka 副本同步
- LEO
- Log End Offset，日志最未尾的数据
- HW
- ISR 中最小的 LEO 作为 HW
- HW 的消息为 C onsumer 可见的消息
# Kafka 副本选举
- Clean 选举
- 优先选取 Isr 中的副本作为 leader
- 如果 Isr 中无可用副本，则 partition 不可用
- Unclean 选举
- 优先选取 Isr 中的副本作为 leader
- 如果 Isr 中无可用副本，则选择其他存活副本
# Kafka 集群扩缩容
Kafka 集群扩缩容之后的目标
- Topic 维度
- partition 在各个 broker 之间分布是均匀的
- 同一个 partition 的 replica 不会分布在一台 broker
- Broker 维度
- Broker 之间 replica 的数量是均匀的
# Kafka 集群扩容步骤
- 扩容 Broker 节点
- Leader 副本写入成功，Producer 即认为写成功
- 计算均衡的 Replica 分布拓扑
- 保证 Topic 的 partition 在 broker 间分布均匀
- 保证 Broker 之间 Replica 分布均匀
- Controller 负责新的副本分布元数据广播
- Controller 将新的 leader/follower 信息广播给 broker
- Broker 负责新副本的数据同步
- Broker 上有需要同步数据的副本则进行数据同步
# Kafka 集群缩容步骤
- 计算均衡的 Replica 分布拓扑
- 保证 Topic 的 partition 在 broker 间分布均匀
- 保证 Broker 之间 Replica 分布均匀
- Controller 负责新的副本分布元数据广播
- Controller 将新的 leader/follower 信息广播给 broker
- Broker 负责新副本的数据同步
- Broker 上有需要同步数据的副本则进行数据同步
- 下线缩容的 Broker 节点
- 数据同步完毕之后下线缩容的 Broker 节点
# Kafka 集群扩缩容问题
- 扩缩容时间长
- 涉及到数据迁移，在生产环境中一次扩缩容可能要迁移 TB 甚至 PB 的数据
- 扩缩容期间集群不稳定
- 保证数据的完整性，往往会从最老的数据进行同步，这样会导致集群时刻处于从磁盘读取数据的状态，disk/net/cpu 负载都会比较高
- 扩缩容期间无法执行其他操作
- 在一次扩缩容操作结束之前，无法进行其他运维操作 (扩缩容）
# Kakfa 未来演进之路
# Kafka 去除 zk 依赖
依赖 ZooKeeper 存在问题
- 元数据存取困难
- 元数据的存取过于困难，每次重新选举的 controller 需要把整个集群的元数据重新 restore，非常的耗时且影响集群的可用性。
- 元数据更新网络开销大
- 整个元数据的更新操作也是以全星推的方式进行，网络的开销也会非常大。
- 强耦合违背软件设计原则
- zookeeper 对于运维来说，维护 Zookeeper 也需要一定的开销，并且 kaika 强耦合与 zk 也并不好，还得时刻担心 zk 的宕机问题，违背软件设计的高内聚，低耦合的原则。
- 网络分区复杂度高
- Zookeeper 本身并不能兼顾到 broker 与 broker 之间通信的状态，这就会导致网络分区的复杂度成几何倍数增长。
- 并发访问 zk 问题多
- Zookeeper 本身并不能兼顾到 broker 与 broker 之间通信的状态，这就会导致网络分区的复杂度成几何倍数增长。
# Kafka 依赖 KRaft
- Process.Roles = Broker
- 服务器在 KRaft 模式下充当 Broker
- Process.Roles = Controller
- 服务器在 KRaft 模式下充当 Controller
- Process.Roles = Broker,Controller
- 服务器在 KRaft 模式下充当 Broker 和 Controller
- Process.Roles = null
- 那么集群就假定是运行在 ZooKeeper 模式下。
# Raft 算法
不同于 Paxos 算法直接从分布式一致性问题出发推导出来，Raft 算法则是从多副本状态机的角度提出，用于管理多副本状态机的日志复制。Raft 实现了和 Paxos 相同的功能，它将一致性分解为多个子问题：Leader 选举（Leader election）、日志同步（Log replication）、安全性（Safety）、日志压缩（Log compaction）、成员变更（Membership change）等。同时，Raft 算法使用了更强的假设来减少了需要考虑的状态，使之变的易于理解和实现。
Raft 将系统中的角色分为领导者（Leader）、跟从者（Follower）和候选人（Candidate）：
- Leader：接受客户端请求，并向 Follower 同步请求日志，当日志同步到大多数节点上后告诉 Follower 提交日志。
- Follower：接受并持久化 Leader 同步的日志，在 Leader 告之日志可以提交之后，提交日志。
- Candidate：Leader 选举过程中的临时角色。
Raft 要求系统在任意时刻最多只有一个 Leader，正常工作期间只有 Leader 和 Followers。
Raft 算法角色状态转换如下：
Follower 只响应其他服务器的请求。如果 Follower 超时没有收到 Leader 的消息，它会成为一个 Candidate 并且开始一次 Leader 选举。收到大多数服务器投票的 Candidate 会成为新的 Leader。Leader 在宕机之前会一直保持 Leader 的状态。
参考文档 https://zhuanlan.zhihu.com/p/32052223
# Kafka 运维 / 调优经验介绍
# Kafka 单机吞吐
- Kafka Version
- 2.3.1
- 机器配置
- 40C 500GB 12 * 1TB 25GB 网卡
- 写入配置
- Ack = -1, replica = 3,in_sync_replica = 2-3 之间
- 单条消息 5 KB
- 吞吐
- 单机 150MB/s
# 参数调用
zookeeper.session.timeout.ms = 30000 # zookeeper连接超时时长
log.segment.bytes = 536870912
log.retention.hours = 36
log.retention.bytes = 274877906944
num.network.threads = 32
num.io.threads = 200
auto.create.topics.enable = false # 自动创建topic
auto.leader.rebalance.enable = false # 自动leader的平衡(负载均衡)
unclean.leader.election.enable = false # unclean选举
advertised.listeners = SASL_PLAINTEXT://:,PLAINTEXT://:
security.inter.broker.protocol = SASL_PLAINTEXT
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
# 扩缩容优化
- Topic-Partition 均匀分布在 Broker 间
- Broker 间的 Replica 是均匀的
# 指标可视化
# Pulsar 详解
# Pulsar 架构介绍
# Pulsar Proxy
- Pulsar 客户端连接集群的两种方式
- Pulsar Client -> Broker
- Pulsar Client -> Proxy
- Pulsar Proxy 的作用及应用场景
- 部分场景无法知道 Broker 地址，如云环境或者 Kubernetes 环境
- Proxy 提供类似 GateWay 代理能力，解耦客户端和 Broker，保障 Broker 安全
# Pulsar Broker
- Pulsar Broker 无状态组件，负责运行两个模块
- Http 服务器
- 暴露了 restful 接口，提供生产者和消费者 topic 查找 api
- 调度分发器
- 异步的 tcp 服务器，通过自定义二进制协议进行数据传输
- Http 服务器
- Pulsar Broker 作为数据层代理
- Bookie 通讯
- 作为 Ledger 代理负责和 Bookie 进行通讯
- 流量代理
- 消息写入 Ledger 存储到 Bookie
- 消息缓存在堆外，负责快速响应
- Bookie 通讯
# Pulsar Storage
- Pulsar 数据存储 Segment 在不同存储中的抽象
- 分布式 Journal 系统 (Bookeeper) 中为 Joumal/Ledger
- 分布式文件系统 (GFS/HDFS) 中为文件
- 普通磁盘中为文件
- 分布式对象存储中为对象
- 定义好抽象之后，即可实现多介质存储
- L1 (缓存):
- Broker 使用堆外内存短暂存储消息
- 适用于 Tail-Read 读场景
- L2(Bookkeeper):
- Bookkeeper 使用 Qurom 写，能有效降低长尾，latency 低
- 适用于 Catch-Up 较短时间内的较热数据
- L3 (S3 等冷存):
- 存储成本低，扩展性好
- 适用于 Catch-Up 长时间内的冷数据
# Pulsar IO 连接器
- Pulsar IO 分为输入 (Input）和输出（Output）两个模块，输入代表数据从哪里来，通过 Source 实现数据输入。输出代表数据要往哪里去，通过 Sink 实现数据输出。
- Pulsar 提出了 IO (也称为 Pulsar Connector），用于解决 Pulsar 与周边系统的集成问题，帮助用户高效完成工作。
- 目前 Pulsar IO 支持非常多的连接集成操作：例如 HDFS、Spark、Flink、Flume、Es、HBase 等。
# Pulsar Functions (轻量级计算框架）
- Pulsar Functions 是一个轻量级计算框架，提供一个部署简单、运维简单、API 简单的 FAAS 平台。
- Pulsar Functions 提供基于事件的服务，支持有状态与无状态的多语言计算，是对复杂的大数据处理框架的有力补充。
- 使用 Pulsar Functions，用户可以轻松地部署和管理 function，通过 function 从 Pulsar topic 读取数据或者生产新数据到 Pulsar topic。
# Bookeeper 整体架构
Bookeeper 读写流程
# Bookkeeper 基本概念
- Ledger: BK 的一个基本存储单元，BK Client 的读写操作都是以 Ledger 为粒度的
- Fragment: BK 的最小分布单元 (实际上也是物理上的最小存储单元），也是 Ledger 的组成单位，默认情况下一个 Ledger 会对应的一个 Fragment (一个 Ledger 也可能由多个 Fragment 组成)
- Entry：每条日志都是一个 Entry，它代表一个 record，每条 record 都会有一个对应的 entry id
# Bookkeeper 新建 Ledger
- Ensemble size (E): 一个 Ledger 所涉及的 Bookie 集合
- Write Quorum Size (Qw): 副本数
- Ack Quorum Size (Qa): 写请求成功需要满足的副本数
# Bookkeeper Ledger 分布
- 从 Bookie Pool 挑选 Bookies 构成 Ensemble
- Write Quorum Size 决定发送给哪些 Bookies
- Ack Quorum Size 决定收到几个 Ack 即为成功
# Bookkeeper 写一致性
- LastAddPushed
- LesAqacommed
- Fencing 避免脑裂
# Bookkeeper 读一致性
所有的 Reader 都可以安全读取 Entry ID 小于或者等于 LAC 的记录，从而保证 reader 不会读取未确认的数据，从而保证了 reader 之间的一致性
# Bookkeeper 读写分离
写入优化:
- 写入时，不但会写入到 Journal 中还会写入到缓存 (memtable) 中，定期会做刷盘 (刷盘前会做排序，通过聚合 + 排序优化读取性能）
读取优化:
- 先读 Memtable, 没命中再通过索引读磁盘
- Ledger Device 中会维护一个索引结构，存储在 RocksDB 中，它会将 (Ledgerld, Entryld) 映射到 (EntryLogld，文件中的偏移量)
# Bookkeeper with pulsar
- Topic-Partition:
- Topic 由多个 partition 组成
- Partition 由多个 segment 组成
- Segment 对应 Ledger
- 可以发现:
- Partition <-> Broker 之间只是映射关系
- Broker 在扩缩容的过程中只需要更改映射即可
# Pulsar 功能介绍
# Pulsar 生产模式
| Access Mode | Describtion |
|---|---|
| Shared | 多个 Producer 可以同时往一个 Topic 中生产消息 |
| Exclusive | 独占模式生产，只有一个 Producer 可以 connect 并生产消息其他 Producer 可以启动成功，作为 Stand-by |
| ExclusiveWithFencing | 独占模式生产，只有一个 Producer 可以 connect 并生产消息其他 Producer 启动时，老的 Producer 会断开连接 |
| WaitForExclusive | 独占模式生产，只有一个 Producer 可以 connect 并生产消息其他 Producer 会卡在创建 Producer 环节 |
# Pulsar 消费模式
- Exclusive
- Failover
- Shared
- Key_Shared
# Exclusive 消费模式
独占订阅（Stream 流模型)
- 独占订阅中，在任何时间，一个消费者组（订阅）中有且只有一个消费者来消费 Topic 中的消息。
# Failover 消费模式
故障切换（Stream 流模型）
- 使用故障切换订阅，多个消费者（Consumer) 可以附加到同一订阅。但是，一个订阅中的所有消费者，只会有一个消费者被选为该订阅的主消费者。 其他消费者将被指定为故障转移消费者。
# Shared 消费模式
共享订阅 （Queue 队列模型)
- 使用共享订阅，在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以循环分发形式发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者。
# Key_Shared 消费模式
按 Key 共享订阅 (Queue 队列模型)
- 使用共享订阅，在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以 key-hash 发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者。
# Pulsar 多租户
Pulsar 多租户体现在 Url 中 persistent://tenant/namespace/topic
# Pulsar Plugin
- 当前支持 Plugin 类型
- KOP (Kafka on Pulsar)
- ROP (RocketMQ on Pulsar)
- AOP (AMQP on Pulsar)
- Mop (MQTT on Pulsar)
- 实现 PIugin 需要支持的功能
- 路由查询
- Message Protocol
- Offset & Msgld
# Pulsar GEO Relication
- 跨数据中心复制
- 消费其他地域数据
# Pulsar HA & Scale-up
- Topic <-> Bundle 完成映射
- Bundle 分配给 Broker
- Lookup Topic
- Lookup Result
- Establish TCP Connection
# Pulsar vs Kafka
存储架构
- 存储计算分离之后带来的优劣势
- 多层架构，状态分离之后的优势
运维操作
- 应对突发流量变化，集群扩缩容是否便捷
- 运维任务是否影响可用性
- 集群部署是否灵活
功能特性
- 多语言 & 多协议
- 多租户管理
- 生产消费模式
生态集成
# 存储计算分离
分层架构优势
- 流量代理层和数据存储层解耦
- 流量代理层无状态，可快速扩缩容 (k8s 等弹性平台)
- 流量代理层可以对接海量的客户端连接
- 存储层负责数据存储，可以使用多级存储
计算层
- 对于写入的数据，可以做预处理，简单 ETL
- 可以做数据缓存，应对高扇出度场景
- 无状态，扩缩容之后，能快速完成负载均衡 Balance
存储层
- 按照数据冷热进行存储介质区分，降低成本
- 历史数据可海量保存，数据无价
- 可直接通过存储层接口读取数据，批式计算
# 周边和生态
# Pulsar IO
source
sink
# Kafka Schema
- 向 Kafka 发送数据时，需要先向 Schema Registry 汪册 schema, 然后序列化发送到 Kafka 里
- Schema Registryerver 为每个注册的 schema 提供一个全局唯 ID. 分配的 ID 保证单调递增，但不一定是连续的
- 当我们需要从 Kafka 消费数据时，消费者在反序列化前，会先判断 schema 是否在本地内存中，如果不在本地内存中，则需要从 Schema Registry 中获取 schema，否则，无需获取
# Pulsar SQL
编辑 (opens new window)
上次更新: 2023/12/06, 01:31:48