从 Kafka 到 Pulsar:数据流演进之路 | 青训营笔记
这是我参与「第四届青训营」笔记创作活动的的第10天。
一、课程概述
- 介绍了消息队列的内容
- 介绍了Kafka的背景、实现、应用
- 介绍了Pulsar的实现和应用
二、详细信息
1. 消息队列概述
消息队列在各个领域扮演的角色。
1.1 消息队列的应用场景
- MQ信息通道
- 异步解藕:下游无需关注上游
- 削峰填谷:数据可以储存
- 发布订阅
- 高可用:解藕小模块,各模块独立可用
- EventBridge事件总线
- 事件源:将云服务、自定义应用、SaaS应用等应用程序产生的时间信息发布到事件集
- 事件集:存储接受的事件信息,并根据事件规则将事件信息路由到事件目标
- 事件目标
- DataPlatform流数据平台
- 提供批/流数据处理能力
- 各类组件提供各类connect
- 提供streaming/function能力
- 根据数据schema灵活进行数据预处理
1.2 主流消息队列相关介绍
2. Kafka详解
Kafka架构解析及未来演进方向。
2.1 架构介绍
- Producer:生产数据,写入Kafka存储系统中
- Consumer:数据消费
- Zookeeper:元数据存储
- 选举机制:Paxos
- 提供一致性:写入强一致性;读取会话一致性
- 提供可用性:一半以上节点存活即可续写
- 提供功能:watch机制;持久/临时节点能力
- Kafka存储数据:
- Broker Meta信息(临时节点)
- Controller信息(临时节点)
- Topic信息(持久节点)
- Config信息(持久节点)
- Broker集群 由多个节点构成,topic的partition分配在brocker中;主节点负责写入,从节点负责备份
- 若干broker节点组成kafka集群
- broker作为消息接收模块,使用react网络模型进行消息数据的接受
- broker作为消息持久化模块
- controller选举
- broker启动尝试去zk注册controller节点
- 注册上的就是controller,其余watch controller,异常则重新注册
- coordinator
- 负责topic-partition和consumer的负载均衡
- 根据不同场景提供不同的分配策略
- Dynamic Membership
- Static Membership
- Incremental Cooperative Rebalance
2.2 高可用
- 副本同步机制
- 提供lsr副本复制机制,提供热备功能
- 写入端提供ack=0, -1, 1机制,控制副本同步强弱
- 副本切换机制
- 提供clean/unclean副本选取机制
2.2.1 ISR机制
- AR:assign replica 已经分配的所有副本
- OSR:out sync replica 很久没有同步数据的副本
- ISR:一直都在同步数据的副本;可以作为热备进行切换的副本;min.insync.replicas最少isr数量配置
2.2.2 Kafka写入ACK
- 如何保证消息不丢
- 3副本如何结合min.insync.replica以及ack配置保证写入Kafka系统中数据不丢失?
- min.insync.replica = 2 , ack = -1
- 5副本?
- 相同
- 3副本如何结合min.insync.replica以及ack配置保证写入Kafka系统中数据不丢失?
2.2.3副本同步
- LEO:log end offset 日志最末尾的数据
- HW:ISR中最小的LEO作为HW,HW的消息为consumer可见消息
2.2.4 副本选举
- clean选举
- unclean选举
2.3 集群扩缩容
-
集群扩缩容目标
- topic维度
- partition在各个broker之间分布均匀
- 同一个partition的replica不会分在一台broker
- broker维度
- broker之间replica数量均匀
- topic维度
-
扩容
-
缩容
-
问题
- 扩缩容时间长:数据迁移
- 扩缩容期间集群不稳定:保证数据完整性,从最老开始同步,集群时刻从磁盘读取,负载高
- 扩缩容期间无法执行其他操作
2.4 未来演进
- 去除zookeeper依赖
- 依赖zk的问题:元数据存储困难/元数据更新网络开销大/强耦合违背软件设计原则/网络分区复杂度高/并发访问zk问题多
- 使用KRaft作为元数据和数据存储
- process.roles = broker
- process.roles = controller
- process.roles = broker, controller
- process.roles = null ZK模式下
- 存算分离
3. Pulsar详解
Pulsar结构解析以及云原生中的优势。
3.1 Pulsar架构介绍
- proxy
- pulsar客户端连接集群的两种方式:client->broker/proxy
- 作用和场景
- 部分场景无法知道broker地址,云/kubernetes
- proxy提供类似gateway能力,解藕客户端和broker,保护broker安全
- pulsar broker
- 无状态组件 运行http服务器和调度分发器
- 作为数据层代理:BK通讯,流量代理(消息写入ledger存储到BK,消息缓存在堆外负责快速响应)
- pulsar storage
- pulsar数据存储segment在不同存储中的抽象
- 分布式journal系统BK中为journal/ledger
- 分布式文件系统中为文件
- 磁盘中为文件
- 分布式blob中为blob
- 分布式对象存储中为对象
- 定义好抽象之后可以按需选择
- 多级存储
- L1缓存:broker使用堆外内存短暂存储/tail-read
- L2 BK:qurom写降低长尾,latency低,适用于catch-up较短时间内较热数据
- L3 冷存:存储成本低,扩展性好;适用于catch-up长时间的冷数据
3.2 bookkeeper介绍
- BK新建ledger
- ensemble size(E)一个Ledger所涉及的bookie集合
- write quorum size:副本数
- ack quorum size:写请求成功需要满足的副本数
- BK ledger分布
- 从bookie pool挑选bookie构成ensemble
- write quorum size决定发送给哪些bookies
- ack quorum size决定收到哪几个ack即为成功
- BK读一致性
- 检查LAC
- BK读写分离
- 写入不但会写入journal也会写入memtable,定期刷盘
- 先读取memtable,没有再通过索引读磁盘
- BK with pulsar
- topic-partition
- topic由多个partition组成
- partition由多个segment组成
- segment对应ledger
- partition和broker之间为映射关系
- broker扩缩容过程只需要修改底层
- topic-partition
3.3 pulsar特性介绍
-
生成模式
- shared:多producer往一个topic生产消息
- exclusive:独占,只有一个producer可以connect并生产
- exclusivewithfencing:新producer会取代旧producer
- 新producer卡在创建环节
-
消费模式
- 独占订阅(stream流模型):只有一个消费者
- failover消费模式(故障切换):多个附加到同一订阅,但一个订阅中所有消费者只能有一个,然后故障切换到下一个
- shared模式(queue):均分模式
- key-shared模式(queue):按照key进行hash发给不同consumer
-
多租户能力
- 体现在url中
-
plugin
-
GEO replication
- 跨数据中心复制:重要数据异地容灾
- 消费其他地域数据
3.4 集群HA & scale up
- Topic<->bundle完成映射
- bundle分配给broker
- look up topic
- look up result
- TCP连接
3.5 Pulsar vs Kafka
- 存储架构
- pulsar存算分离
- 分层架构优势:流量代理数据存储解藕;流量代理无状态快速扩缩容;流量代理可以对接海量客户端;存储层负责数据存储,可以多级;
- 计算层:可以预处理数据;数据缓存;无状态扩缩容后能快速负载均衡
- 存储层:可以实现分层存储 扩缩容
- 运维操作
- 功能特性
- 生态集成
三、个人总结
本节课介绍了数据流的基本概念,通过消息队列实现数据的流动。Kafka和Pulsar是消息队列的两种不同实现方式,本节课也介绍了他们不同的模式、应用和优势。