这是我参与「第四届青训营 」笔记创作活动的的第12天。
本节课程主要分为 4 个方面：
1.消息队列概述
2.Kafka详解
3.Pulsar详解
4.周边和生态
一.消息队列概述
1.1.消息队列的应用场景
1.1.1. MQ消息通道
□ 异步解耦
□ 削峰填谷
□ 发布订阅
□ 高可用
1.1.2.EventBridge数据总线
○ 事件源：将云服务、自定义应用、SaaS应用等应用程序产生的事件消息发布到事件集。
○ 事件集：存储接受到的事件消息，并根据事件规则将事件消息路由到事件目标。
○ 事件目标：消费事件消息。
1.1.3.Data Platform流数据平台
◇ 提供批/流数据处理能力
◇ 各类组件提供各类Connect
◇ 提供Steaming/Function能力
◇ 根据数据schema灵活的进行数据预处理
1.2.主流消息队列的相关介绍
二.kafka详解
2.1.Kafka架构介绍
2.1.1.Zookeeper
◌ 选举机制：Paxos机制
◌ 提供一致性：
● 写入(强一致性)
● 读取(会话一致性)
◌ 提供可用性：一半以上节点存活即可读写
◌ 提供机制：
● watch机制
● 持久/临时节点能力
2.1.2.Broker
▶ Broker角色
◌ 若干个Broker节点组成Kafka集群
◌ Broker作为消息的接收模块，使用React网络模型进行消息数据的接收
◌ Broker作为消息的持久化模块，进行消息的副本复制以及持久化
◌ Broker作为高可用模块，通过副本间的Failover进行高可用保证
2.1.3.Controller
▶ Controller选举
◌ Broker启动会尝试去zk中注册controller节点
◌ 注册上controller节点的broker即为controller
◌ 剩余broker会watch controller节点，节点出现异常则进行重新注册
▶ Controller作用
◌ Broker重启/宕机时，负责副本的Failover切换
◌ Topic创建/删除时，负责Topic meta信息广播
◌ 集群扩缩容时，进行状态控制
◌ Partition/Replica状态机维护
2.1.4.Coordinator
● 负责topic-partition <-> consumer的负载均衡
● 根据不同场景提供不同的分配策略
◎ Dynamic Membership Protocol
◎ Static Membership Protocol
◎ Incremental Cooperative Rebalance
2.2.Kafka高可用
● 副本同步机制：
◎ 提供Isr副本复制机制，提供热备功能
◎ 写入端提供ack=0，-1，1机制，控制副本同步强弱
● 副本切换机制：
◎ 提供clean/unclean
2.2.1.Kafka副本ISR机制
◆ AR：
◎ Assign Replica，已经分配的所有副本
◆ OSR：
◎ Out Sync Replica
◎ 很久没有同步数据的副本
◆ ISR：
◎ 一直都在同步数据的副本
◎ 可以作为热备进行切换的副本
◎ min.insync.replicas最少isr数量配置
2.2.2.Kafka写入Ack机制
◆ Ack = 1
◇ Leader副本写入成功，Producer即认为写成功
◆ Ack = 0
◇ OneWay模式
◇ Producer发送后即为成功
◆ Ack = -1
◇ ISR中所有副本都成功，Producer才认为写成功
2.2.3.Kafka如何保证消息不丢失？
▶ Kafka副本同步
△ LEO：
◎ Log End Offset，日志最末尾的数据
△ HW：
◎ ISR中最小的LEO作为HW
◎ HW的消息为Consumer可见的消息
▶ Kafka副本选举
▽ Clean选举：
● 优先选取Isr中的副本作为leader
● 如果Isr中无可用副本，则partition不可用
▽ Unclean选举：
● 优先选取Isr中的副本作为leader
● 如果Isr中无可用副本，则选择其他存活副本
2.3.Kafka集群扩缩容
Kafka集群扩缩容之后的目标：
◀ Topic维度：
● partition在各个broker之间分布是均匀的
● 同一个partition的replica不会分布在一台broker
◀ Borker维度：
● Borker之间replica的数据时均匀的。
2.3.1.Kafka集群扩容步骤
● 扩容Broker节点
◆ Leader副本写入成功，Producer即认为写成功
● 计算均衡的Replica分布拓扑
◆ 保证Topic的partition在broker间分布均匀
◆ 保证Broker之间Replica分布均匀
● Controller负责新的副本分布元数据广播
◆ Controller将新的leader/foollower信息广播给broker
● Broker负责新副本的数据同步
◆ Broker上有需要同步数据的副本则进行数据同步
2.3.2.Kafka集群缩容步骤
● 计算均衡的Replica分布拓扑
◆ 保证Topic的partition在broker间分布均匀
◆ 保证Broker之间Replica分布均匀
● Controller负责新的副本分布元数据广播
◆ Controller将新的leader/follower信息广播给broker
● Broker负责新副本的数据同步
◆ Broker上有需要同步数据的副本则进行数据同步
● 下线缩容的Broker节点
◆ 数据同步完毕之后 下线缩容的Broker节点
2.3.3.Kafka集群扩缩容问题
● 扩缩容时间长
◆ 涉及到数据迁移，在生产环境中一次扩缩容可能要迁移TB甚至PB的数据
● 扩缩容期间集权不稳定
◆ 保证数据的完整性，往往会从最老的数据进行同步，这样会导致集群时刻处于从次哦按读取数据的状态，disk/net/cpu负载都会比较高
● 扩缩容期间无法执行其他操作
◆ 再一次扩缩容操作结束之前，无法进行其他运维操作(扩缩容)
2.4.Kafka未来演进之路
2.4.1.问题与挑战：
1).去除Zookeeper依赖
2).使用KPaft作为元数据和数据存储介质
3).存储计算分离演进
2.4.2.Kafka去除zk依赖
◉ 元数据存取困难
◆ 元数据的存取过于困难，每次重新选举的controller需要把整个集群的元数据重新restore，非常耗时且影响集群的可用性
◉ 元数据更新网络开销大
◆ 整个元数据的更新操作也是以全量推的方式进行，网络的开销也会非常大
◉ 强耦和违背软件设计原则
◆ Zookeeper对于运维来说，维护Zookeeper也需要一定的开销，并且Kafka强耦合与zk也并不好，还得时刻担心zk的宕机问题，违背软件设计的高内聚，低耦合的原则
◉ 网络分区复杂度高
◆ Zookeeper本身并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂程度成几何倍数增长
◉ 并发访问zk问题多
◆ Zookeeper本省并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂程度成几何倍数增长
2.4.3.Kafka依赖KRaft
◉ Process.Roles = Broker
● 服务器在KPaft模式下充当Broker
◉ Process.Roles = Controller
●服务器在KPaft模式下充当Controller
◉ Process.Roles = Broker,Controller
● 服务器在KPaft模式下充当Broker和Controller
◉ Process.Roles = null
● 那么集群就假定是运行在Zookeeper模式下
2.5.Kafka运维/调优经验介绍
2.5.1. Kafka单机吞吐
◊ Kafka Version：2.3.1
◊ 机器配置：40C 500GB 12*1TB 25GB
◊ 写入配置：
▪ Ack=-1，replica=3，in_sync_replica=3
▪ 单条消息5KB
◊ 吞吐：单机150MB/s
2.5.2.Kafka集群参数配置
○ zookeeper.session.timeout.ms = 30000
○ auto.create.topics.enable = false
○ auto.leader.rebalance.enable = false
○ unclean.leader.election.enable = false
2.5.3.扩缩容优化
三.Pulsar详解
3.1.Pulsar架构介绍
3.1.1.Pulsar Proxy
✔ Pulsar Proxy的作业及应用场景：
◯ 部分场景无法知道Broker地址，如云环境或者Kubernetes环境
◯ Proxy提供类似GateWay代理能力，解耦客户端和Broker，保障Broker安全
✔ Pulsar客户端连接集群的两种方式：
◯ Pulsar Client -> Broker
◯ Pulsar Client -> Proxy
3.1.2.Pulsar Broker
✔ Pulsar Broker无状态组件，负责运行两个模块
● Http服务器
暴露了restful接口，提供生产者和消费者topic查找api
● 调度分发器
异步的tcp服务器，通过自定义二进制协议进行数据传输
✔ Pulsar Broker作为数据层代理
● Bookie通讯
作为Ledger代理负责和Bookie进行通讯
● 流量代理
消息写入Ledger存储到Bookie
消息缓存在推外，负责快速响应
3.1.3.Pulsar Storage
✔ Pulsar Storage塑化剂存储Segment在不同存储中的抽象：
◽ 分布式Journal系统(Bookkeeper)中为Journal/Ledger
◽ 分布式文件系统(GFS/HDFS)中为文件
◽ 普通磁盘中为文件
◽ 分布式Blob存储中为Blob
◽ 分布式对象存储中为对象
✔ 定义好抽象之后，即可实现
✔ 三级存储：
◎ L1(缓存)：
◽ Broker使用推外内存短暂存储信息
◽ 适用于Tail-Read读场景
◎ L2(Bookkeeper)：
◽ Bookkeeper使用Qurom写，能有效降低长尾
◽ 适用于Catch-Up较短时间内的较热数据
◎ L3(S3等冷存)：
◽ 存储成本低，扩张性好
◽ 适用于Catch-Up长时间内的冷数据
3.1.4.Pulsar IO连接器
■ Pulsar IO分为输入(Input)和输出(Output)两个模块，输入代表数据从哪里来，通过Source实现数据输入。输出代表数据要往哪里去，通过Sink实现数据输出。
■ Pulsar提出了IO(也成为Pulsar Connector)，用于解决Pulsar与周边系统的集成问题，帮助用户高效完成工作。
■ 目前Pulsar IO支持非常多的连接集成操作
3.1.5.Pulsar Functions
■ Pulsar Functions是一个轻量级计算框架，提供一个部署简单、运维简单、API简单的FAAS平台。
■ Pulsar Functions提供基于事件的服务，支持有状态与无状态的多语言计算，是对复杂的大数据处理框架的有利补充。
■ 使用Pulsar Functions，用户可以轻松地部署和管理function，通过function从Pulsar topic读取数据或者产生新数据到Pulsar topic。
3.2.Bookkeeper介绍
3.2.1.Bookkeeper基本概念
◆ Ledger：BK的一个基本存储单元，BK Client 的读写操作都是以Ledger为粒度的
◆ Fragment：BK的最小分布单元(实际上也是物理上的最小存储元)，也是Ledger的组成单位，默认情况下一个Ledger会对应的一个Fragment(一个Ledger也可能由多个Fragment组成)
◆ Entry：每条日志都是一个Entry，它代表一个record，每条record都会有一个对应的entry id
3.2.2.Bookkeeper新建Ledger
◆ Ensemble size(E)：一个Ledger所涉及的Bookie集合
◆ Writer Quorum Size(Qw)：副本数
◆ Ack Quorum Size(Qa)：写请求成功需要满足的副本数
Bookkeeper Ledger分布：
◆ 从Bookie Pool挑选Bookies构成Ensemble
◆ Writer Quorum Size决定发送给哪些Bookies
◆ Ack Quorum Size决定收到几个Ack即为成功
3.2.3.Bookkeeper读写分离
▶写入优化
▶读取优化
Bookkeeper写一致性
◇ LastAddPushed ◇ LastAddConfirmed ◇ Fencing避免脑裂
Bookkeeper读一致性
◇ 所有的Reader都可以安全读取Entry ID小于或者等于LAC的记录，从而保证reader不会读取未确认的数据，从而保证了reader之间的一致性
3.2.4.Bookkeeper with pulsar
◀ Topic-Partitiom
◾ Topic由多个partition组成
◾ Partition由多个segment组成
◾ Segment对应Ledger
◀ 可以发现
◾ Partition <-> Broker之间只是映射关系
◾ Broker在扩缩容的过程中只需要更改映射即可
3.3.Pulsar特性介绍
3.3.1.生产模式
◌ Shared
◌ Exclusive
◌ ExclusiveWithFencing
◌ WaitForExclusive
3.3.2.消费模式
◌ 独占模式
◌ 故障切换(Stream流模型)
◌ 共享订阅(Queue队列模型)
◌ 按Key共享模型(Queue队列模型)
3.3.3.多租户
3.3.4.Pulsar Plugin
◌ 当前支持Plugin类型
◌ 实现Pulgin需要支持的功能
3.3.5.Pulsar GEO Relication
◌ 跨数据中心复制
● KOP
● ROP
● AOP
● MOP
◌ 实现Plugin需要支持的功能
● 路由查询
● Message Protocol
● Offset & Msgid
3.4.集群HA & Scale-up
□ Topic <-> Bundle完成映射
□ Bundle分配给Broker
3.4.1.Pulsar HA & Scale-up
◎ Lookup Topic
◎ Lookup Result
◎ Establish TCP Connection
3.5.Pulsar vs Kafka
◈ 存储架构
◈ 运维操作
◈ 功能特性
◈ 生态集成
3.5.1.存储计算分离
■ 计算层：
✔ 对于写入的数据,可以做预处理,简单ETL
✔ 可以做数据缓存,应对高扇出度场景
✔ 无状态，扩缩容之后，能快速完成负载均衡Balance
■ 存储层：
✔ 按照数据冷热进行存储介质区分,降低成本
✔ 历史数据可海量保存,数据无价
✔ 可直接通过寻相互层接口读取数据,批式计算
■ 分层架构优势：
✔ 流量代理层和数据存储层解耦
✔ 流量代理无状态,可快速扩缩容(k8s等弹性平台)
✔ 流量代理层可以对接海量的客户连接
✔ 存储层负载数据存储,可以使用多级存储
四.周边和生态
4.1.周边生态概览
4.1.2.Kafka Schema
4.1.3.Pulsar SQL
