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

团鱼
134 阅读5分钟

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

1. 消息队列概述

  • 消息队列应用场景

    • MQ 消息通道
    • EventBridge 事件总线
    • Data Platform 数据流平台
  • 常见消息队列，如: RabbitMQ、RocketMQ、 Kafka、Pulsar

2. Kafka 详解

image-20220807104428813

image.png

  • Kafka 架构介绍

    • ZooKeeper：元数据存储，强一致性的提供

      • watch观察节点状态
      • 持久/临时节点能力

    • Broker：由多个Broker节点组成，主节点负责数据写入，副节点负责数据备份

      • 消息接收：使用React网络模型进行消息数据的接收
      • 进行消息的副本复制以及持久化
      • 作为高可用模块，通过副本间的Failover进行高可用保证

    • Controller：掌控节点的变更和决策，特殊Broker

      • 选举：zk注册controller节点，其他就是watch controller节点

    • Coordinator：消费端的控制，根据不同场景提供不同的分配策略

  • Kafka 高可用

    • 副本同步机制

      • 提供lsr副本复制机制，提供热备机制
      • 写入ack机制；1：leader写入成功就成功；0：produver发送后即成功；-1:所有副本都成功

    • 副本切换机制

      • 提供clean/unclean副本选举机制

        • clean：优先选取isr中的副本作为leader；无可用，partition不可用【更注重数据一致性】
        • unclean：优选选取isr中的副本作为leader，无可用选择其他存活副本【不能保证一致性，保证可用性】

  • Kafka 集群扩缩容

    • Topic维度

      • partition在各个broker之间的分布是均匀的
      • 同一个partition的replica不会分布在一台broker上

    • Broker维度

      • Broker之间的replica的数量是均匀的

  • Kafka 未来演进之路

    • 去除zkp依赖
    • 存储计算分离演进
    • 使用KRaft作为元数据和数据存储介质

  • Kafka 运维/调优经验介绍

    • 单机吞吐，参数配置，指标可视化，扩缩容优化

副本同步机制

ISR

  • AR：已经分配的所有副本
  • OSR：很久没有同步数据的副本
  • ISR：一直都在同步数据的副本；可以作为热备份进行切换的副本；min.insync.replicas:最少isr数量的配置

副本同步

  • LEO：Log End Offset，日志最末尾的数据
  • HW：ISR中最小的LEO作为HW；HW的消息为Consumer可见的消息

集群扩缩容问题

  1. 评判维度：见上文

  2. 扩容步骤：

    1. 扩容Broker节点：Leader副本写入成功，Producer 即认为写成功

    2. 计算均衡的Replica 分布拓扑

      • 保证Topic的partition在broker间分布均匀
      • 保证Broker之间Replica 分布均匀

    3. Controller负责新的副本分布元数据广播

      • Controller 将新的leaderl/ollower 信息广播给broker

    4. Broker负责新副本的数据同步

      • Broker上有需要同步数据的副本则进行数据同步

  3. 缩容步骤: 2⃣️->3⃣️->4⃣️>下线缩容的Broker节点：数据同步完成之后下线缩容的Broker节点

  4. 扩缩容存在的问题

    1. 扩缩容时间长
    2. 扩缩容期间集群不稳定
    3. 扩缩容期间无法执行其他操作

  5. 可以优化的方向

    • 把随机打散优化成黏性副本迁移

3. Pulsar 详解

image.png

  • Pulsar 架构介绍

    • Proxy：云原生体系下的网络隔离

    • Broker：http服务器，调度分发器；

    • Storage：Pulsar数据存储Segment在不同存储中的抽象

      • 多级存储，L1缓存；L2Bookkeeper；L3S3等冷存

    • IO连接器

  • Bookkeeper 介绍

    • BookKeeper 的定位是一个可用于实时场景下的高扩展性、强容错、低延迟的存储服务。

    • 架构设计：Clients、ZooKeeper、Bookie pool；Bookies 在启动的时候向 ZooKeeper 注册节点，Client 通过 ZooKeeper 发现可用的 Bookie。

    • Ledger：BK中的基本存储单元；Fragment：BK的最小分布单元；Entry：日志

    • 新建Ledger：

      • Ensemble：可以控制一个 Ledger 的读写带宽；
      • Write Quorum：控制一条记录的复本数；
      • Ack Quorum：写每条记录需要等待的 Ack 数 ，控制时延；
      • 增加 Ensemble，可以增加读写带宽（增加了可写的机器数）；
      • 减少 Ack Quorum，可以减长尾时延。

    • 读/写一致性

      • 写：每条记录会被 writer 赋予一个严格递增的 id，写成功更新Last-Add-Confirm指针。LAC 与 LAP（Pushed）差值为正在写数据
      • 读：所有的 Reader 都可以安全读取 Entry ID 小于或者等于 LAC 的记录

    • 读写分离

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

    • Partition<->Broker之间只是映射关系

    • Broker在扩缩容的过程中只需要更改映射即可

  • Pulsar 功能介绍

    • 生产模式：
    • 消费模式
    • 多租户
    • Plugin
    • 多节点复制
  • Pulsar 集群 HA & Scale-up

image.png

  • Pulsar vs Kafka

    • Apache Pulsar 将高性能的流（Apache Kafka 所追求的）和灵活的传统队列（RabbitMQ 所追求的）结合到一个统一的消息模型和 API 中。
    • Pulsar 使用统一的 API 为用户提供一个支持流和队列的系统，且具有同样的高性能。 应用程序可以将此统一的 API 用于高性能队列和流式传输，而无需维护两套系统：RabbitMQ 进行队列处理，Kafka 进行流式处理。

存储计算分离带来的优势？

  • 首先是系统的扩容性比较好，可以分开的扩容计算层和存储层。
  • 其次是计算是无状态的，所以说当扩容计算层的时候，它对系统的影响非常小，而且扩容速度极快。

参考

BookKeeper 基本原理

比拼 Kafka, 大数据分析新秀 Pulsar 到底好在哪

avatar
文章
阅读
粉丝