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

概述

2022の夏天，半壶水响叮当的我决定充实一下自我

一、内容介绍

青训营

总述

本节课程主要分为四个方面：

消息队列概述
Kafka 详解
Pulsar 详解
周边和生态

课前部分主要罗列课程中涉及到的概念。对于不熟悉的概念，同学们可以提前查询预习；课中部分主要罗列每一部分的关键思路，帮助同学们跟上课程的进度；课后部分是一些问题，帮助同学们在课后梳理本课程的重点。

消息队列的使用场景

消息队列在业界主要使用在那些场景
消息队列在大数据场景下的用途

常见消息队列

常见消息队列，如: Kafka、RocketMQ、Pulsar 架构、高级特性

Replica的主从设计

冗余，可以理解为一个动作，就是把一份数据多拷贝了几份出来。

而拷贝出来的数据我们就称之为副本，这也是Replica的真正含义，那么多副本之间就必然存在着数据同步的问题：

也就是不同副本之间，以哪个副本的数据为准，如何保持数据一致这两个主要问题。

二、消息队列概述

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

2.1 消息队列概述

消息队列的应用场景
- MQ 消息通道
- EventBridge 事件总线
- Data Platform 数据流平台
主流消息队列的相关介绍
- RabbitMQ
- RocketMQ
- Kafka
- Pulsar

2.2 消息队列的应用场景

2.2.1 MQ 消息通道

2.2.2 EventBridge 事件总线

事件源:将云服务、自定义应用、SaaS应用等应用程序产生的事件消息发布到事件集。

事件集:存储接收到的事件消息，并根据事件规则将事件消息路由到事件目标。

事件目标:消费事件消息。

image (19).jpeg

2.2.3 Data Platform 数据流平台

提供批/流数据处理能力
各类组件提供各类Connect/链接
提供Streaming/Function(流/函数)能力
根据数据 schema/模式灵活的进行数据预处理

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

2.3.1 RabbitMQ

2.3.2 RocketMQ

2.3.3 Kafka

2.3.4 Pulsar

三、Kafka 详解

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

3.1 Kafka架构介绍

image - 2022-08-15T174745.408.png

3.1.1 Zookeeper

3.1.2 Broker/经纪人

Broker/经纪人角色
- 若干个 Broker节点组成 Kafka集群
- Broker作为消息的接收模块，使用React网络模型进行消息数据的接收
- Broker作为消息的持久化模块，进行消息的副本复制以及持久化
- Broker作为高可用模块，通过副本间的 Failover/故障转移进行高可用保证

3.1.3 Controller/控制器

3.1.3.1 Controller/控制器选举

Controller/控制器选举
- Broker启动会尝试去水k中注册controller节点
- 注册上 controller 节点的 broker即为controller
- 其余 broker会 watch controller节点，节点出现异常则进行重新注册

3.1.3.2 Controller作用

Controller 作用
- Broker 重启/宕机时，负责副本的 Failover/故障转移切换. Topic创建/删除时，负责 Topic meta/主题元信息广播·集群扩缩容时，进行状态控制
- Partition/Replica(分区/复制) 状态机维护

3.1.4 Coordinator/协调员

Coordinator/协调员介绍
- 负责 topic-partition/主题-分区 <-> consumer/消费者的负载均衡
- 根据不同的场景提供不同的分配策略
  - Dynamic Membership Protocol/动态成员议定书
  - Static Membership Protocol/静态成员协议
  - lncremental Cooperative Rebalance/加强合作再平衡

3.2 Kafka高可用

Kafka高可用
- 副本同步机制
  - 提供LSR副本复制机制，提供热备功能
  - 写入端提供ack=0,-1,1机制，控制副本同步强弱
- 副本切换机制
  - 提供clean/unclean（清洁/不洁净）副本选举机制

可用性定义 image - 2022-08-15T222327.085.png

3.2.1 Kafka副本ISR机制

AR
- Assign Replica/指定副本，已经分配的所有副本
OSR
- Out Sync Replica/同步副本
- 很久没有同步数据的副本
ISR
- 一直都在同步数据的副本
- 可以作为热备进行切换的副本
- min.insync.replicas最少isr数量配置

image - 2022-08-15T224917.392.png

3.2.2 Kafka写入Ack机制

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

3.2.3 Kafka

3.2.3.1 Kafka如何保证消息不丢?

问题1
- 3副本情况下，如何结合min.insync.replica=2以及ack=-1的配置，来保证写入kafka系统中的数据不丢失?
问题2
- 如果是5副本呢?
- min.insync.replica=2,ack=-1

3.2.3.2 Kafka副本同步

image - 2022-08-15T231323.689.png

LEO
- Log End Offset/日志端偏移量，日志最末尾的数据
HW
- ISR最小由LEO作为HW
- HW的当息为Consumer可见的消息

3.2.3.3 Kafka 副本选取

image - 2022-08-15T232848.162.png

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

3.3 Kafka集群扩缩容

3.3.1 Kafka集群扩缩容

Kafka集群打扩缩容之后的目标
- Topic/特应性维度
  - partition/分区在各个broker之间分布是均匀的
  - 同一个partition的replica不会分布在一台broker
- Broker 维度
  - Broker之间 replica/复制品的数量是均匀的

3.3.2 Kafka集群扩容步骤

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

3.3.3 Kafka集群缩容步骤

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

3.3.4 Kafka集群扩缩容问题

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

3.4 Kafka未来演进之路

3.4.1 Kafka去除zk依赖

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

3.4.2 Kafka依赖 KRaft

3.5 Kafka运维/调优经验介绍

3.5.1 Kafka单机吞吐

Kafka Version/版本
- 2.3.1
机器配置
- 40C 500GB内存 12块*1TB机械硬盘 25GB网卡
写入配置
- Ack = -1, replica(副本) = 3（重要一致性）/2, in sync replica（同步复） = 3
- 单条消息5KB
吞吐
- 单机150MB/s以上扩容

3.5.2 Kafka集群参数配置

zookeeper.session.timeout.ms = 30 000，kafka给zookeeper心跳报回，防止网络抖动延迟，频繁上下线，leader切换，越小越敏感，大则宕机时间反馈长，30s
auto.create.topics.enable = false，系统可掌控行，自动创建topics，会滥用Didois，浪费资源
auto.leader.rebalance.enable = false，运行中leader的租聘平衡，负载平衡，不建议，因为高峰期影响数据可用性
unclean.leader.election.enable = false，一致性与可用性，选数据一致性