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

阿韩很菜
113 阅读6分钟

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

这是我参与「第四届青训营 」笔记创作活动的的第12天，本篇笔记主要是关于第十二次大数据课程《从 Kafka 到 Pulsar：数据流演进之路》的课堂笔记

消息队列

消息队列应用场景：

  • MQ 消息通道
  • EventBridge 事件总线
  • Data Platform 数据流平台

主流消息队列： image.png

Kafka

Kafka架构：

image.png Kafka存储数据:

  1. Broker Meta信息(临时节点)
  2. Controller信息(临时节点)
  3. Topic信息(持久节点)
  4. Config信息(持久节点)
  • Zookeeper：主要用来进行源数据的存储，提供强一致性。
    • 选举机制: Paxos机制
    • 提供一致性:
      1. 写入(强一致性)
      2. 读取(会话一致性)
    • 提供可用性: 一半以上节点存活即可读写
    • 提供功能:
      1. watch机制
      2. 持久/临时节点能力
  • Broker角色：
    • 若干个Broker节点组成Kafka集群
    • Broker作为消息的接收模块，使用React网络模型进行消息数据的接收
    • Broker作为消息的持久化模块，进行消息的副本复制以及持久化
    • Broker作为高可用模块，通过副本间的Failover进行高可用保证
  • Controller选举：
    • Broker启动会尝试去zk中注册controller节点
    • 注册上controller节点的broker即为controller
    • 其余broker会 watch controller 节点，节点出现异常则进行重新注册
  • Controller作用：
    • Broker重启/宕机时，负责副本的Failover切换
    • Topic创建/删除时，负责Topic meta信息广播
    • 集群扩缩容时，进行状态控制
    • Partition/Replica状态机维护
  • Coordinator介绍：
    • 负责topic-partition <-> consumer的负载均衡
    • 根据不同的场景提供不同的分配策略
      1. Dynamic Membership Protocol
      2. Static Membership Protocol
      3. Incremental Cooperative Rebalance
  • Kafka高可用
    • 副本同步机制
      1. 提供lsr副本复制机制，提供热备功能
      2. 写入端提供ack=0,1,1机制，控制副本同步强弱
    • 副本切换机制
      • 提供clean/unclean副本选举机制
  • Kafka副本ISR机制
    • AR
      • Assign Replica,已经分配的所有副本
    • OSR
      • Out Sync Replica
      • 很久没有同步数据的副本
    • ISR
      • 一直都在同步数据的副本
      • 可以作为热备进行切换的副本
      • min.insync.replicas最少isr数量配置

image.png

Ack= 1：
    Leader副本写入成功，Producer 即认为写成功
Ack=0：
    OneWay 模式
    Producer发送后即为成功
Ack =-1：
    ISR中所有副本都成功，Producer 才认为写成功

Kafka集群缩容步骤：

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

Kafka集群扩缩容问题：

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

Pulsar

架构介绍：

image.png 客户端（Producer/Consumer）进行服务发现，也就是消息的生产和消费，跟他交互的是Broker，Bookie可以看成是一个storage，同时有ZK来进行Bookie和Broker元数据的存储。

Pulsar Broker：

  • Pulsar Broker无状态组件，负责运行两个模块
  1. Http服务器 暴露了restful接口，提供生产者和消费者topic 查找api
  2. 调度分发器 异步的tcp服务器，通过自定义=进制协议进行数据传输
  • Pulsar Broker作为数据层代理

  1. Bookie通讯 作为Ledger代理负责和Bookie进行通讯

  2. 流量代理

    • 消息写入Ledger存储到Bookie
    • 消息缓存在堆外，负责快速响应

Pulsar Storage：

  • Pulsar数据存储Segment在不同存储中的抽象
  • 定义好抽象之后，即可实现多介质存储

image.png

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

Bookkeeper基本概念：

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

image.png

Pulsar生产模式：

image.png

Pulsar消费模式：

image.png

  1. Exclusive：独占订阅(Stream流模型)，在任何时间，一个消费者组(订阅)中有且只有一个消费者来消费Topic中的消息。
  2. Failover
  3. Shared
  4. Key_ Shared：按Key共享订阅(Queue队列模型)，在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以key-hash发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者。

Pulsar多租户： 分层级从而合理进行资源分配

image.png

Pulsar GEO Relication： 容灾机制 image.png

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

存储计算分离：

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