从Kafka到Pulsar：数据流演进之路 | 青训营笔记

林鹿白
48 阅读12分钟

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

一、消息队列概述。

1.消息队列的应用场景：
  • MQ 消息通道
  • EventBridge 时间总线
  • Data Platform 流数据平台
1.1MQ 消息通道：

959a3f24a3e3d96b0ceda9a90222f00.jpg

3444b33c77d75c21da9453aa0f0ab4b.jpg

1.2EventBridge 数据总线：
  • 事件源:将云服务、自定义应用、 Saas 应用等应用程序产生的事件消息发布到事件集。
  • 事件集:存储接收到的事件消息，并根据事件规则将事件消息路由到事件目标。
  • 事件目标:消费事件消息。

631c47ab99a0caafce43a5a92fab050.jpg

1.3Data Platform 流数据平台：
  • 提供批/流数据处理能力
  • 各类组件提供各类Connect
  • 提供Streaming/Function 能力
  • 根据数据schema灵活的进行数据预处理

550cba181ce919f21f1387f7e3951ce.jpg

2.主流消息队列的相关介绍：

b02e43195eee86e7269c446d6b285d9.jpg

二、Kafka详解。

1.Kafka架构介绍：

7f35c592cb22609199bb95ecc1ea676.jpg 1.1 ZooKeeper：

  • 选举机制:Paxos机制
  • 提供一致性:
    • 写入(强一致性)
    • 读取(会话一致性)
  • 提供可用性: 一半以上节点存活即可读
  • 提供功能:
    • watch 机制
    • 持久/临时节点能力

Kafka 存储数据:

  • 1.Broker Meta 信息(临时节点)
  • 2.Controller 信息(临时节点)
  • 3.Topic 信息(持久节点)
  • 4.Config 信息(持久节点)

7f35c592cb22609199bb95ecc1ea676.jpg

1.2 Broker：
  • Broker 角色
    • 若干个Broker节点组成Kalka 集群
    • Broker 作为消息的接收模块，使用Readt网络模型进行消息数据的接收
    • Broker 作为消息的持久化模块，进行消息的副本复制以及持久化
    • Broker 作为高可用模块, 通过副本间的Failover进行高可用保证

86dbfdd38aec94b39e44cf9e39cdc8e.jpg

1.3.1 Controller选举：
  • Controller选举
    • Broker 启动会尝试去zk中注册 controller节点
    • 注册上 controller节点的broker即为controller
    • 其余broker 会 watch controller 节点, 节点出现异常则进行重新注册

59a1b22bd7dec698bec93bf74e66d94.jpg

1.3.2 Controller作用：
  • Controller作用
    • Broker 重启/机时, 负责副本的Failover 切换
    • Topic 创建/删除时, 负责 Topic meta 信息广播
    • 集群扩缩容时, 进行状态控制
    • Partition/Replica 状态机维护

a3c2373911de3d5e21e24e3ccec65d3.jpg

1.4 Coordinator：
  • Coordinator 介绍
    • 负责topic-partition<-> consumer的负载均衡
    • 根据不同的场景提供不同的分配策略
      • Dynamic Membership Protocol
      • Static Membership Protocol
      • Incremental Cooperative Rebalance

9a7fa25cf274e2c549e1a8a6bb1c567.jpg

2.Kafka 高可用：
  • Kafka 高可用
    • 副本同步机制
      • 提供Isr 副本复制机制，提供热备功能
      • 写入端提供ack=0,-1,1机制，控制副本同步强弱
    • 副本切换机制
      • 提供 cleanlunclean 副本选举机制

可用性定义：

2eab21113c23bd21a8503e9e257f620.jpg

2.1 Kafka 副本ISR机制：
  • AR
    • Assign Replica, 已经分配的所有副本
  • OSR
    • Out Sync Replica
    • 很久没有同步数据的副本
  • ISR
    • 一直都在同步数据的副本
    • 可以作为热备进行切换的副本
    • min.insync.replicas 最少 isr 数量配置

ce4df94fd433929f491ef1b6ad3c10d.jpg

2.2 Kafka写入Ack机制：
  • Ack=1
    • Leader 副本写入成功，Producer即认为写成功
  • Ack=0
    • OneWay模式
    • Producer 发送后即为成功
  • Ack=-1
    • ISR 中所有副本都成功, Producer才认为写成功
2.3Kafka如何保证消息不丢？
  • 问题1
  • 3副本情况下，如何结合min.insync.replica 以及 ack 的配置，来保证写入kafka 系统中的数据不丢失?
  • min.insync.replica配置成2，ack配置成-1.

Kafka副本同步：

  • LEO
    • Log End Ofset,日志最末尾的数据
  • HW
    • ISR中最小的LEO作为HW
    • HW的消息为Consumer可见的消息

616b3f7af22a6c22b22d1f59da8f402.jpg Kafka副本选举：

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

364766e00fc30f5024dd6133437ebed.jpg

3.1.1 Kafka集群扩缩容：
  • Kafka集群扩缩容之后的目标
    • Topic 维度
      • partion 在各个broker 之间分布是均匀的
      • 同一个parttion 的roplica 不会分布在一台broker
    • Broker 维度
      • Broker 之间repla 的数量是均匀的

6ae655218312efaf5b26e581f4aa2fb.jpg

3.1.2 Kafka集群扩容步骤：
  • 计算均衡的Replica 分布拓扑
    • 保证 Topic 的 parton 在 broker 间分布均匀
    • 保证 Broker 之间 Replica 分布均匀
  • Controler 负责新的副本分布元数据广播
    • Controller将新的leader/fllower 信息广播给 broker
  • Broker 负责新副本的数据同步
    • Broker 上有需要同步数据的副本则进行数据同步
  • 下线缩容的Broker节点
    • 数据同步完毕之后下线缩容的Broker节点

Kafka集群缩容问题：

  • 扩缩容时间长
    • 涉及到数据迁移，在生产环境中一次扩缩容可能要迁移TB 甚至PB的数据
  • 扩缩容期间集群不稳定
    • 保证数据的完整性, 往往会从最老的数据进行同步，这样会导致集群时刻处于从磁盘读取数据的状态,disk/netcpu 负载都会比较高
  • 扩缩容期间无法执行其他操作
    • 在一次扩缩容操作结束之前，无法进行其他运维操作(扩缩容)
4.1Kafka未来演进之路：
  • 问题与挑战：
    • 去除ZooKeeper依赖
    • 存储计算分离演进
    • 使用KRaft作为元数据和数据存储介质
4.1.1 Kafka去除zk依赖：
  • 依赖ZooKeeper存在问题
    • 元数据存取困难
      • 元数据的存取过于国难 每次重新选华的controlor/解要把暨个集料元数抓重新restore，非常的耗时且影响集群的可用性
    • 元数据更新网络开销大
      • 整个元数据的更新操作也是以全量推的方式进行，网络的开销也会非常大。
    • 强揭合违背软件设计原则
      • Zookeeper对于运维来说，堆护Zookeeper也需要一定的开销，并且Kafka强耦合与zk也并不好，还得时刻担心zk的宕机问题，违背软件设计的高内聚，低構合的原则。
    • 网络分区复杂度高
      • Zookeeper本身井不能兼顾到broker与broker之间通信的状态，这就会导教网络分区的实杂度成几何倍数婚长
    • 并发访问zk问题多
      • Zookeeper本身并不能顾到broker与broker之间通信的状态，这就会导致网络分区的复杂度 成几何倍致增长
4.1.2 Kafka依赖KRaft：
  • Process.Roles = Broker
    • 服务器在KRat 模式下充当Broker
  • Process.Roles =Controller
    • 服务器在KRat 模式下充当Controller
  • Process.Roles=Broker, Controller
    • 服务器在KRat 模式下充当Broker和Controller
  • Process. Roles =null
    • 那么集群就假定是运行在Z00Keeper模式下。

e349056f16d500ecef321f3447834ef.jpg

5.1 Kafka运维/调优经验介绍。
5.1.1 Kafka单机吞吐：
  • Kafka Version
    • 2.3.1
  • 机器配置
    • 40C 500GB 12*1TB 25GB
  • 写入配置
    • Ack=-1, replica = 3, in sync replica =3
    • 单条消息5KB
  • 吞吐
    • 单机150MB/S
5.1.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://:I
  • security.inter.broker.protocol=SASL PLAINTEXT
5.1.3扩缩容优化：
  • 目标：
    • Topic-Partition 均匀分布在 Broker间
    • Broker 间的Replica 是均匀的

a10cea6720913dae04e9cbe81bab4e6.jpg

5.1.4指标可视化。

三、Pulsar详解。

1.Pulsar架构介绍：

c4e2d822749c48a5b6692439a65a749.jpg

1.1 Pulsar Proxy：

  • Pulsar客户端连接集群的两种方式：

    • Pulsar Client-> Broker
    • Pulsar Client-> Proxy

  • Pulsar Proxy的作用及应用场景：

    • 部分场景无法知道Broker 地址，如云环境或者Kubemmeles环境
    • Proxy提供类似 GateWay代理能力，解耦客户端和Broker，保障 Broker安全

01ae91d6a178fb92ee1d21e2ba5170a.jpg

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

0eb3970103f9b81b138e9810d0481e5.jpg

1.3 Pulsar Storage：
  • Pulsar 数据存储Segment 在不同存储中的抽象
    • 分布式Journal 系统(Bookeeper)中为Journal/Ledger
    • 分布式文件系统(GFS/HDFS) 中为文件
    • 普选磁盘中为文件
    • 分布式BIob 存储中为 Blob
    • 分布式对象存储中为对象
  • 定义好抽象之后，即可实现多介质存储

4097416b12733e42008e7cbbabcd071.jpg

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

5456272f99e5a82851045cb5e6780e1.jpg

1.4 Pulsar IO连接器：
  • Pulsar I0 分为输入(input) 和输出(Output)两个模块，输入代表数据从#里来，通过Source 实现数据输入，输出代表数据要往器里去，通过Sink 实现数据输出。
  • Pulsar 提出了10(也称为Pulsar Connector) 用于解决Pulsar 与周边系境的集成问题，带助用户高效完成工作。
  • 目前Pusar IO 支持非常多的连接集成操作:例如 HDFS、Spark.Flink、Flume、ES HBase等。

77d79743921ed00d6d116e759bd0535.jpg

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

357671222893388bcdb447c0ec6c39b.jpg

2.1 Bookkeeper整体架构：

43e77b5309cd5e903211219c1092aaf.jpg

2.2Bookkeeper基本概念：
  • Ledger BK 的一个基本存储单元，BK Clent 的读写操作都是以Ledger为粒度的
  • Fragment: BK的展小分布单元(实际上也是物理上的最小存储单元) ，也是Ledger的组成单位，默认情况下一个Ledger 会对应的一个Fragment(一个Ledger 也可能由多个Fragment 组成)
  • Entry:每条日志都是一个Entry,它代表一个record，每条record 都会有一个对应的entry id

959d5680415dc7004b1b0a5840c994d.jpg

2.3.1BookKeeper 新建Ledger：
  • Ensemble size(E):一个Ledger所涉及的Bookie 集合
  • Write Quorum Size(Qw: 副本数
  • Ack Quorum Size(Qa):写请求成功需要满足的副本数

d4f609fdd90742c3eda363133246937.jpg

2.3.2BookKeeper Ledger分布：
  • 从 Bookie Pool 挑选 Bookies构成 Ensemble
  • Write Quorum Size决定发送给哪些Bookies
  • Ack Quorum Size 决定收到几个Ack 即为成功

7621005cf2c69142763139b2330a2e7.jpg

2.4.2BookKeeper 写一致性:
  • LastAddPushed
  • LastAddConfirmed
  • Fencing 避免脑裂

169e494b38cd994ddd157b01f2fd2e7.jpg

2.4.3 Bookkeeper 读一致性：
  • 所有的Reader都可以安全读取Entry ID 小于或者等于LAC的记录，从而保证reader不会读取未确认的数据，从而保证了reader之间的一致性
2.4.1BookKeeper读写分离：
  • 写入优化：
    • 写入时，不但会写入到Jounal 中还会写入到缓存(memtable)中，定期会做刷盘(刷盘前会做排序，通过聚合+排序优化读取性能)
  • 读取优化:
    • 先读Memtable,没命中再通过索引读磁盘
    • Ledger Device 中会维护一个素引结构，存储在 RocksDB 中，它会将(Ledgerld Entrylid)映射到(EntryLogld,文件中的信移量)

dd6d4d03fa4a3b0f36f11544f933f98.jpg

2.5BookKeeper with pulsar：
  • Topic-Partition:
    • Topic由多个parttion 组成
    • Partition 由多个segment 组成
    • Segment 对应 Ledger
  • 可以发现：
    • Partition<> Broker 之间只是映射关系
    • Broker在扩缩容的过程中只需要更改映射即可
3.Pulsar 功能介绍：

c0f58546fc880e46b921658fd33a987.jpg

3.1 Pulsar生产模式：

81abd00af5337166e810fe1fabc40d3.jpg

3.2 Pulsar消费模式：
  • Exclusive
  • Failover
  • Shared
  • Key_ Shared
3.2.1 Exclusive消费模式（独占模式）
  • 独占订阅(Stream流模型)
    • 独占订阅中，在任何时间，一个消费者组(订阅)中有且只有一个消费者来消费Topic中的消息。

a6393e6f1b041e4e30203d3dc47b8bf.jpg

3.2.2 Failover消费模式
  • 故障切换 Stream流模型)
    • 使用故障切换订阅，多个消费者(Consumer) 可以附加到同一订阅。但是,个订阅中的所有消费者，只会有一个消费者被选为该订阅的主消费者，其他消费者将被指定为故障转移消费者。
3.2.3 Shared消费模式
  • 共享订阅(Queue队列模型)
    • 使用共享订阅，在同一个订阅背后, 用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以循环分发形式发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者。
3.2.4 Key_Shared消费模式
  • 按Key共享订阅(Queue队人列模型)
    • 使用共享订阅, 在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以key-hash发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者。
3.3Pulsar多租户：
  • Pulsar多租户体现在Url中
3.4Pulsar Plugin
  • 当前支持Plugin 类型
    • KOP (Kafka on Pulsar)
    • ROP (RocketMQ on Pulsar)
    • AOP (AMQP on Pulsar)
    • Mop (MQTT on Pulsar)
  • 实现 Plugin 需要支持的功能
    • 路由查询
      • Message Protocol
      • Offset & Msgld
3.5Pulsar GEO Relication
  • 跨数据中心复制
  • 消费其他地域数据
3.6 Pulsar vs Kafka
  • 存储架构
    • 存储计算分离之后带来的优劣势
    • 多层架构，状态分商之后的优势
  • 运维操作
    • 应对突发流量变化, 集群扩缩容是否便捷
    • 运维任务是否影响可用性
    • 集群部看是否灵活
  • 功能特性
    • 多语言&多协议
    • 多租户管理
    • 生产消费模式
  • 生态集成
3.6.1存储计算分离：
  • 分层架构优势：
    • 流量代理层和数据存储层解耦
    • 流量代理层无状态，可快速扩缩容(k8s等弹性平台)
    • 流量代理层可以对接海量的客户端连接
    • 存储层负责数据存储，可以使用多级存储
  • 存储层：
    • 按照数据冷热进行存储介质区分，降低成本
    • 历史数据可海量保存，数据无价
    • 可直接通过存储层接口读取数据，批式计算
  • 计算层
    • 对于写入的数据，可以做预处理，简单ETL
    • 可以做数据缓存， 应对高扇出度场景
    • 无状态，扩缩容之后, 能快速完成负载均衡 Balance

四、周边和生态。

4.1周边生态概览：

490419fe313e7bd42095b5da9834961.jpg

4.1.2Kafka Schema
  • 向Kafka发送数据时，需要先向 Schema Registry 注册 schema 然后序列化发送到Kafka里
  • Schema Registry server为每个注册的schema 提供一个全局唯一D，分配的ID保证单调送增，但不一定是连续的
  • 当我们需要从 Kalka 消费数据时，消费者在反序列化前，会先判断schema 是否在本地内存中，如果不在本地内存中，则需要从Schema Registry 中获取 schema,否则，无需获取

cb6fea1aa65a0adb5bedd7c94181b22.jpg

总结

本次课程主要从消息队列概述、Kafka详解、Pulsar详解、周边和生态四个方面讲述，经过学习我知道了存储计算分离的优势：

  1. 对于不同类型的集群，可以针对性地部署更加合适的服务器；
  2. 计算和存储可以分别按需进行扩展，而不是一起扩展；
  3. 不同集群可以有不同的升级周期；
  4. 划分了运维职责，更加便于管理；
  5. 提高了资源利用率，降低了能耗开销。

等等的诸多内容，但在学习Pulsar详解后半部分时的时候，总感觉云里雾里。

avatar
文章
阅读
粉丝