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

二粒砂
97 阅读6分钟

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

1.消息队列概述

消息队列在各个领域扮演的角色

①消息队列的应用场景

MQ消息通道

image.png

  • 异步解耦
  • 削峰填谷
  • 发布订阅
  • 高可用

EventBridge数据总线

image.png

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

Data Platform流数据平台

image.png

  • 提供批/流数据处理能力
  • 各类组件提供各类Connect
  • 提供Streaming/Function能力
  • 根据数据Schema灵活的进行数据预处理

②主流消息队列的相关介绍

image.png

2.Kafka详解

Kafka架构解析以及未来演进方向

①Kafka架构介绍

image.png

Zookeeper

image.png

  • Kafka存储数据

    • Broker Meta信息（临时节点）
    • Controller信息（临时节点）
    • Topic信息（持久节点）
    • Config信息（持久节点）

  • 选举机制：Paxos机制

    • leader和follower会进行投票，获得大部分选票的节点会成为leader，其他节点会变成observer节点，observer节点是为了扩展读能力产生的节点
    • 数据会从leader向follower和observer进行拷贝

  • 提供一致性

    • 写入（强一致性）
    • 读取（会话一致性）

  • 提供可用性：一半以上节点存活即可读写

  • 提供功能：watch机制，持久/临时节点能力

Broker

  • 若干个Broker节点组成Kafka集群
  • Broker作为消息的接收模块，使用React网络模型进行消息数据的接收
  • Broker作为消息的持久化模块，进行消息的副本复制以及持久化
  • Broker作为高可用模块，通过副本间的Failover进行高可用保证
  • follower会从leader处进行数据同步，并持久化到本地的磁盘中

Controller选举

image.png

  • Broker启动会尝试去zk中注册controller节点
  • 注册上controller节点的broker即为controller
  • 其余broker会watch controller节点，节点出现异常则重新注册（注册都是临时节点，临时节点是会话时绑定的，只要会话过期了，该节点就会下线）

Controller作用

image.png

  • Broker重启/宕机时，负责副本的Failover切换
  • Topic创建/删除时，负责Topic mata信息广播
  • 集群扩缩容时，进行状态控制
  • Partition/Replica状态机维护

Coordinator

  • 负责topic-partition<->consumer的负载均衡

  • 根据不同的场景提供不同的分配策略

    • Dynamic Membership Protocol
    • Static Membership Protocol
    • Incremental Cooperative Rebalance

②Kafka高可用

  • 副本同步机制

    • 提供lsr副本复制机制，提供热备功能
    • 写入端提供ack=0、-1、1机制，控制副本同步强弱

  • 副本切换机制

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

Kafka副本ISR机制

  • AR：Assign Replica，已经分配的所有副本
  • OSR：Out Sync Replica，很久没有同步数据的副本
  • ISR：一直都在同步数据，可以作为热备进行切换的副本；min.insync.replicas：最小isr数量配置，副本保证可用的情况下最少要有多少Isr成员

Kafka写入ack机制

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

Kafka副本同步

image.png

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

Kafka副本选举

  • Clean选举（注重数据的一致性）

    • 优先选取ISR中的副本作为leader
    • 如果ISR中无可用副本，则partition不可用

  • Unclean选举（注重可用性）

    • 优先选取ISR中的副本作为leader
    • 二u过ISR中无可用副本，则选择其他存活副本

③Kafka集群扩缩容

image.png

Kafka集群扩缩容之后的目标

  • Topic维度

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

  • Broker维度

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

Kafka集群扩容步骤

  • 扩容Broker节点

    • Leader副本写入成功，Producer即认为写成功

  • 计算均衡的Replica分布拓扑

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

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

    • Controller将新的leader/follower信息广播给broker

  • Broker负责新副本的数据同步

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

Kafka集群缩容步骤

  • 计算均衡的Replica分布拓扑

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

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

    • Controller将新的leader/follower信息广播给broker

  • Broker负责新副本的数据同步

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

  • 下线缩容的Broker节点

    • 流量迁移完毕，数据同步完毕后下线缩容的Broker节点

Kafka集群扩缩容问题

  • 扩缩容时间长

    • 涉及到数据迁移，在生产环境中一次扩缩容可能要迁移TB甚至PB的数据

  • 扩缩容间集群不稳定

    • 保证数据的完整性，往往会从最老的数据进行同步，这样会导致集群时刻处于从磁盘读取数据的状态，disk/net/cpu负载都会比较高

  • 扩缩容间无法执行其他操作

    • 在一次扩缩容操作结束之前，无法进行其他运维操作（扩缩容）

④Kafka未来演进之路

去除zookeeper依赖

  • 依赖Zookeeper存在问题

    • 元数据存取困难：元数据的存取过于困难，每次重新选举的controller需要把整个集群的元数据重新restore，非常耗时而且影响集群的可用性
    • 元数据更新网络开销大：整个元数据的更新操作也是以全量推的方式及逆行，网络开销也会非常大
    • 强耦合违背软件设计原则：Zookeeper对于运维来说，维护zk也需要一定的开销，并且kafka强耦合与于zk也不好，还得时刻担心zk宕机的问题，违背软件设计的高内聚，低耦合的原则
    • 网络分区复杂度高：zk本身并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂度几何倍数增长
    • 并发访问zk问题多

  • Kafka依赖KRaft

    • Process.Roles = Broker：服务器在KRaft模式下只充当Broker进行数据存储
    • Process.Roles = Controller：服务器在KRaft模式下充当Controller进行元数据的广播
    • Process.Roles = Broker,Controller：服务器在KRaft模式下充当Broker和Controller
    • Process.Roles = null：那么集群就假定是运行在Zookeeper模式下
avatar
文章
阅读
粉丝