从 Kafka 到 Pulsar：数据流演进之路 - 复习笔记

这是我参与「第四届青训营」笔记创作活动的的第13天！

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
Kafka副本同步

LEO
- Log End Offset，日志最未尾的数据
HW
- ISR中最小的LEO作为HW
- HW的消息为Consumer可见的消息

Kafka副本选举

Clean 选举
- 优先选取Isr中的副本作为leader
- 如果Isr 中无可用副本，则partition不可用
Unclean 选举
- 优先选取Isr中的副本作为leader
- 如果Isr中无可用副本，则选择其他存活副本

2.3. Kafka集群扩缩容

Kafka 集群扩缩容之后的目标
- Topic维度
  - partition在各个broker之间分布是均匀的
  - 同一个partition的replica 不会分布在一台broker
- Broker 维度
  - Broker 之间replica的数量是均匀的

2.3.1. Kafka 集群扩容步骤

扩容Broker节点
- Leader副本写入成功，Producer 即认为写成功
计算均衡的Replica分布拓扑
- 保证Topic的partition在broker间分布均匀
- 保证 Broker 之间 Replica分布均匀
Controller 负责新的副本分布元数据广播
- Controller 将新的leader/follower 信息广播给broker
Broker 负责新副本的数据同步
- Broker 上有需要同步数据的副本则进行数据同步

2.3.2. Kafka 集群缩容步骤

计算均衡的Replica分布拓扑
- 保证Topic的partition在broker间分布均匀
- 保证 Broker 之间 Replica分布均匀
Controller 负责新的副本分布元数据广播
- Controller 将新的leader/follower 信息广播给broker
Broker 负责新副本的数据同步
- Broker 上有需要同步数据的副本则进行数据同步
下线缩容的Broker节点
- 数据同步完毕之后下线缩容的Broker节点

2.3.3. Kafka 集群扩缩容问题

扩缩容时间长
- 涉及到数据迁移，在生产环境中一次扩缩容可能要迁移TB甚至PB的数据
扩缩容期间集群不稳定
- 保证数据的完整性，往往会从最老的数据进行同步，这样会导致集群时刻处于从磁盘读取数据的状态，disk/net/cpu负载都会比较高
扩缩容期间无法执行其他操作
- 在一次扩缩容操作结束之前，无法进行其他运维操作（扩缩容）

2.4. Kafka未来演进之路

2.4.1. Kafka 去除zk依赖
依赖ZooKeeper存在问题

元数据存取困难
- 元激据的存取过于困难，每次王新选举的controller需要把整个集群的元数据三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和Controlle
Process.Roles=null
- 那么集群就假定是运行在ZooKeeper模式下。

2.4. Kafka 运维/调优经验介绍

2.4.1. Kafka单机吞吐

Kafka Version
- 2.3.1
机器配置
- 40C500GB 12*1TB 25GB
写入配置
- Ack=-1，replica=3，in_sync_replica=3
- 单条消息5KB
吞吐
- 单机150MB/s

2.4.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_PLAINTEXT://：，PLAINTEXT://：
security.inter.broker.protocol=SASL_PLAINTEXT

2.4.3. 扩缩容优化

目标

Topic-Partition均匀分布在Broker间
Broker间的Replica是均匀的

3. Pulsar详解

3.1. Pulsar 架构介绍

3.1.1. Pulsar Proxy

Pulsar 客户端连接集群的两种方式
- Pulsar Client->Broker
- Pulsar Client->Proxy
Pulsar Proxy的作用及应用场景
- 部分场景无法知道 Broker 地址，如云环境或者Kubermetes环境
- Proxy 提供类似GateWay代理能力，解耦客户端和Broker，保障Broker安全

3.1.2. Pulsar Broker

Pulsar Broker 无状态组件，负责运行两个模块
- Http 服务器
  - 暴露了restful接口，提供生产者和消费者topic查找api
- 调度分发器
  - 异步的tcp服务器，通过自定义二进制协议进行数据传输
Pulsar Broker 作为数据层代理
- Bookie通讯
  - 作为Ledger代理负责和Bookie 进行通讯
- 流量代理
  - 消息写入Ledger 存储到Bookie
  - 消息缓存在堆外，负责快速响应

3.1.3. Pulsar Storage

Pulsar 数据存储 Segment在不同存储中的抽象
- 分布式Journal系统（Bookeeper）中为Jourmal/Ledger
- 分布式文件系统（GFS/HDFS）中为文件
- 普通磁盘中为文件
- 分布式Blob存储中为Blob
- 分布式对象存储中为对象
定义好抽象之后，即可实现多介质存储

L1（缓存）
- Broker 使用堆外内存短暂存储消息
- 适用于Tail-Read读场景
L2（Bookkeeper）：
- Bookkeeper 使用Qurom写，能有效降低长尾，latency低
- 适用于Catch-Up 较短时间内的较热数据
L3（S3等冷存）：
- 存储成本低，扩展性好
- 适用于Catch-Up长时间内的冷数据

3.1.4. Pulsar IO 连接器

Pulsarl0分为输入（Input）和输出（Output）两个模块，输入代表数据从哪里来，通过Source 实现数据输入。输出代表数据要往哪里去，通过Sink 实现数据输出。
Pulsar提出了10（也称为Pulsar Connector），用于解决Pulsar 与周边系统的集成问题，帮助用户高效完成工作。
目前Pulsar IO支持排常多的连接集成操作：例如HDFS、Spark、Flink、Flume、ES、HBase等。

3.1.5. Pulsar Functions（轻量级计算框架）

Pulsar Functions 是一个轻量级计算框架，提供一个部署简单、运维简单、API简单的FAAS平台。
Pulsar Functions 提供基于事件的服务，支持有状态与无状态的多语言计算，是对复杂的大数据处理框架的有力补充。
使用Pulsar Functions，用户可以轻松地部署和管理function，通过function 从Pulsar topic 读取数据或者生产新数据到Pulsar topic。

3.2. Bookeeper 介绍

3.2.1. Bookeeper 整体架构

3.2.2. 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即为成功

3.2.4 Bookkeeper 一致性
Bookkeeper 写一致性

LastAddPushed
LastAddConfirmed
Fencing 避免脑裂

Bookkeeper 读一致性

所有的Reader 都可以安全读取Entry ID小于或者等于LAC的记录，从而保证 reader不会读取未确认的数据，从而保证了reader之间的一致性

Bookkeeper 读写分离

写入优化：
- 写入时，不但会写入到Jourmal中还会写入到缓存（memtable）中，定期会做刷盘（刷盘前会做排序，通过聚合+排序优化读取性能）
读取优化：
- 先读Memtable，没命中再通过索引读磁盘
- Ledger Device 中会维护一个索引结构，存储在RocksDB中，它会格（Ledgerld，Entryld）映射到（EntryLogld，文件中的偏移量）

3.2.5. Bookkeeper with pulsar

Topic-Partition：
- Topic 由多个partion 组成
- Partition 由多个segment 组成
- Segment对应Ledger
可以发现：
- Partition<->Broker 之间只是映射关系
- Broker 在扩缩容的过程中只需要更改映射即可

3.3. Pulsar 功能介绍

3.3.1. Pulsar 生产模式

3.3.2. Pulsar 消费模式

Exclusive
Failover
Shared
Key_Shared

Exclusive 消费模式

独占订阅（Stream流模型）
- 独占订阅中，在任何时间，一个消费者组（订阅）中有且只有一个消费者来消费Topic中的消息。

Failover 消费模式

故障切换（Stream流模型）
- 使用故障切换订阅，多个消费者（Consumer）可以附加到同一订阅。但是，一个订阅中的所有消费者，只会有一个消费者被选为该订阅的主消费者。其他消费者将被指定为故障转移消费者。

Shared 消费模式

共享订阅（Queue队列模型）
- 使用共享订阅，在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以循环分发形式发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者。

Key_Shared 消费模式

按Key共享订阅（Queue队列模型）
- 使用共享订阅，在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以key-hash 发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者。

3.3.3. Pulsar 多租户

Pulsar 多租户体现在Url中
persistent://tenant/namespace/topic

3.3.4. Pulsar Plugin

当前支持Plugin类型
- KOP（Kafka on Pulsar）
- ROP（RocketMQ on Pulsar）
- AOP（AMQP on Pulsar）
- Mop（MQTT on Pulsar）
实现Plugin需要支持的功能
- 路由查询
- Message Protocol
- Offset&Msgld

3.3.5. Pulsar GEO Relication

跨数据中心复制
消费其他地域数据

3.4. 集群HA&Scale-up

3.4.1. Pulsar HA & Scale-up

Topic<->Bundle 完成映射
Bundle 分配给Broker

3.4.2. Pulsar HA & Scale-up

Lookup Topic
Lookup Result
Establish TCP Connection

3.5. Pulsar vs Kafka

存储架构
- 存储计算分离之后带来的优劣势
- 多层架构，状态分离之后的优势
运维操作
- 应对突发流量变化，集群扩缩容是否便捷
- 运维任务是否影响可用性
- 集群部署是否灵活
功能特性
- 多语言&多协议
- 多租户管理
- 生产消费模式
生态集成

3.5.1. 存储计算分离

分层架构优势
- 流量代理层和数据存储层解耦
- 流量代理层无状态，可快速扩缩容（k8s等单性平台）
- 流量代理层可以对接海量的客户端连接
- 存储层负责数据存储，可以使用多级存储
存储层
- 按照数据冷热进行存储介质区分，降低成本
- 历史数据可海量保存，数据无价
- 可直接通过存储层接口读取数据，批式计算
计算层
- 对于写入的数据，可以做预处理，简单ETL
- 可以做数据缓存，应对高扇出度场景
- 无状态，扩缩容之后，能快速完成负载均衡Balance

大数据-复习笔记-12 | 青训营笔记