这是我参与「第四届青训营 」笔记创作活动的第十一天
从 Kafka 到 Pulsar：数据流演进之路
一、消息队列概述
1.1 消息队列应用场景
1.1.1 MQ 消息通道
- 异步解耦
- 削峰填谷
- 发布订阅
- 高可用
1.1.2 EventBridge 事件总线
- 事件源:将云服务、自定义应用、SaaA应用等应用程序产生的事件发布到事件集
- 事件集：存储接收到的事件消息，并根据事件规则将事件消息路由到事件目标
- 事件目标：消费事件消息
1.1.3 Data Platform 数据流平台
- 提供批、流 数据处理能力
- 各类组件提供各类Connect
- 提供Streaming/Function 能力
- 根据数据schema灵活的进行数据预处理
1.2 主流消息队列介绍
- RabbitMQ
- RocketMQ
- Kafka
- Pulsar
二、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 mela信息广播
- 集群扩缩容时，进行状态控制
- Partition/Replica状态及维护
2.1.4 Coordinator
负责topic-partition <-> consumer 的负载均衡
2.2 Kafka 高可用
Kafka高可用
- 副本同步机制
- 提供lsr副本复制机制，提供热备功能
- 写入端提供ack=0,-1,1机制，控制副本同步强弱
- 副本切换机制
- 提供clean/unclean副本选举机制
2.2.1 Kafka 副本 ISR机制
- AR
- Assign Replica,已经分配的所有副本
- OSR
- Out Sync Replica
- 很久没有同步数据的副本
- ISR
- 一直都在同步数据的副本
- 可以作为热备进行切换的副本
- min.insync.replicas最少isr数量配置
2.3 Kafka 集群扩缩容
2.3.1 Kafka集群扩缩容之后的目标
- Topic维度
- parttion在各个broker之间分布是均匀的
- 同一个partition的replica不会分布在一台broker
- Broker维度
- Broker之间replica的数量是均匀的
2.3.2 Kafka集群扩容步骤
- 扩容Broker节点
- Leader副本写入成功，Producer即认为写成功
- 计算均衡的Replica分布拓扑
- 保证Topic的partition在broker间分布均匀
- 保证Broker之间Replica分布均匀
- Controller负责新的副本分布元数据广播
- Controller将新的leaderlfollower信息广播给broker
- Broker负责新副本的数据同步
- Broker上有需要同步数据的副本则进行数据同步
- 下线缩容的Broker节点
- 数据同步完毕之后下线缩容的Broker节点
2.3.3 Kafka集群扩缩容问题
- 扩缩容时间长
- 涉及到数据迁移，在生产环境中一次扩 缩容可能要迁移TB甚至PB的数据
- 扩缩容期间集群不稳定
- 保证数据的完整性，往往会从最老的数据进行同步，这样会导致集群时刻处于从磁盘读取数据的状态，disk/net/cpu 负载都会比较高
- 扩缩容期间无法执行其他操作
- 在一次扩缩容操作结束之前，无法进行其他运维操作(扩缩容)
2.4 Kafka 未来演进之路
2.4.1 Kafka去除zk依赖
- 依赖ZooKeeper存在问题
- 元数据存取困难
- 元数据的存取过于困难，每次重新选举的contoller需要把整个焦群的元数据重新restore,非常的耗时且影响焦群的可用性。
- 元数据更新网络开销大
- 整个元数据的更新操作也是以全量推的方式进行，网络的开销也会非常大。
- 强耦合违背软件设计原则
- Zookeeper对于运维来说，维护Zookeeper也需要一 定的开销，并且kafka强耦合与zk也并不好，还得时刻担心zk的宕机问题，违背软件设计的高内聚，低耦合的原则。
- 网络分区复杂度高
- Zookeeper本身并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂度成几何倍数增长。
- 并发访问zk问题多
- Zookeeper本身并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂度成几何倍数增长。
- 元数据存取困难
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单机吞吐
2.5.2 Kafka集群参数配置
- zookeeper.session.timeout.ms = 30000
- 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
- auto.leader.rebalance. enable = false
- unclean.leader.election.enable = false
- advertised.listeners = SASL PL AINTEXT://,PL AINTEXT://:
- security .inter .broker.protocol = SASL_ PL AINTEXT
2.5.3 扩缩容优化
三、Pulsar详解
3.1 Pulsar 架构介绍
3.2 Bookkeeper 介绍
3.2.1 Bookkeeper 基本概念
- Ledger: BK的一个基本存储单元，BK Client的读写操作都是以Ledger为粒度的
- Fragment: BK的最小分布单元(实际上也是物理上的最小存储单元)，也是Ledger的组成单位，默认情况下一个Ledger会对应的一个Fragment (一个Ledger也可能由多个Fragment组成)
- Entry:每条日志都是一个 Entry,它代表一个 record,每条
- record都会有一个对应的 entry id
3.3 Pulsar 特性介绍
3.3.1 Pulsar生产模式
3.3.2 Pulsar消费模式
3.3.3 Pulsar多租户
3.4 Pulsar 集群 HA & Scale-up
3.5 Pulsar vs Kafka
- 存储架构
- 存储计算分离之后带来的优劣势
- 多层架构，状态分离之后的优势
- 运维操作
- 应对突发流量变化，集群扩缩容是否便捷
- 运维任务是否影响可用性
- 集群部署是否灵活
- 功能特性
- 多语言&多协议
- 多租户管理
- 生产消费模式
- 生态集成
四、周边生态
4.1 Kafka Schema
- 向Kafka发送数据时，需要先向Schema Registry注册schema, 然后序列化发送到Kafka里
- Schema Registry server为每个注册的schema提供一个全局唯一ID,分配的ID保证单调递增，但不一定是连续的
- 当我们需要从Kafka消费数据时，消费者在反序列化前，会先判断schema是否在本地内存中，如果不在本地内存中，则需要从Schema Registry中获取schema,否则，无需获取
