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

一、笔记内容

1.消息队列概述

2.Kafka详解

3.Pulsar详解

4.周边和生态

二、消息队列概述

1.消息队列的应用场景

3.MQ消息通道

graph TD
MQ消息通道 --> 异步解耦

MQ消息通道 --> 削峰填谷

MQ消息通道 --> 高可用

MQ消息通道 --> 发布订阅

4.EventBridge事件总线

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

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

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

5.Data Platform流数据平台

1．提供批/流数据处理能力

2．各类组件提供各类Connect

3．提供Streaming/Function能力

4．根据数据schema灵活的进行数据预处理

2.主流消息队列的相关介绍

	RabbitMQ	RocketMQ	Kafka	Pulsar
推出时间	2007	2012	2010	2016
使用语言	Erlang	Java	Scala/Java	Java
单机吞吐量	一般	较高	高	高
延迟	低	低	一般	低
可用性(分片)	高(主从架构)	高(主从架构)	非常高(分布式)	非常高(分布式)
—致性	较高	高	高	高
扩展性	较高	高	高	非常高

三、Kafka详解

1.Kafka 架构介绍

1.Zookeeper

选举机制：Paxos机制
提供一致性:
- 写入(强一致性)
- 读取(会话一致性)
提供可用性:
- 一半以上节点存活即可读写
提供功能:
- watch机制
- 持久/临时节点能力

Kafka存储数据:

1.Broker Meta信息(临时节点)

2.Controller信息( 临时节点)

3.Topic信息(持久节点)

4.Config信息(持久节点)

2.Broker

Broker角色 ：

若干个Broker节点组成Kafka集群
Broker 作为消息的接收模块，使用React网络模型进行消息数据的接收
Broker作为消息的持久化模块，进行消息的副本复制以及持久化

- Broker作为高可用模块，通过副本间的Failover进行高可用保证

3.Controller

Controller选举：

Broker启动会尝试去zk中注册controller节点
注册上 controller节点的 broker即为controller

- 其余broker会watch controller节点，节点出现异常则进行重新注册

Controller 作用：

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

4.Coordinator

负责topic-partition <-> consumer的负裁均衡

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

Dynamic Membership Protocol
static Membership Protocol
lncremental Cooperative Rebalance

2.Kafka 高可用

1.Kafka高可用

副本同步机制
- 提供Isr副本复制机制，提供热备功能
- 写入端提供ack=0,-1,1机制，控制副本同步强弱
- Ack= 1，Leader副本写入成功，Producer即认为写成功
  - Ack = 0，OneWay模式，Producer发送后即为成功
  - Ack = -1，ISR中所有副本都成功，Producer才认为写成功
副本切换机制
- 提供clean/unclean副本选举机制

2.Kafka副本ISR机制

AR(Assign Replica)：已经分配的所有副本
OSR(Out Sync Replica)：很久没有同步数据的副本
lSR(In sync replica)：一直都在同步数据的副本，可以作为热备进行切换的副本。
min.insync.replicas最少isr数量配置

问题：3副本情况下，如何结合min.insync.replica以及ack的配置，来保证写入kafka系统中的数据不丢失?

min.insync.replica：2，Ack = -1

3.Kafka副本同步

LEO：LogEnd Offset，日志最末尾数据

Hw：ISR中最小的LEO作为Hw，HW的消息为Consumer可见的消息。

4.Kafka副本选举

Clean选举：优先选取Isr中的副本作为 leader，如果Isr中无可用副本，则partition不可用。Unclean选举：优先选取 Isr中的副本作为 leader，如果lsr中无可用副本，则选择其他存活副本。

3.Kafka 集群扩缩容

Kafka集群扩缩容之后的目标：

Topic维度
- partition在各个broker之间分布是均匀的
- 同一个partition的replica不会分布在一台broker
Broker维度
- Broker之间replica的数量是均匀的

1.Kafka 集群扩缩容步骤

1.Kafka集群扩容步骤

(1) 扩容 Broker节点

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

(2) 计算均衡的Replica分布拓扑

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

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

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

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

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

2.Kafka集群缩容步骤

(1) 计算均衡的Replica分布拓扑

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

(2) Controller负责新的副本分布元数据广播

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

(3) Broker负责新副本的数据同步

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

(4) 下线宿容的Broker节点

数据同步完毕之后下线缩容的Broker节点

2.Kafka 集群扩缩容问题

(1) 扩缩容时间长：涉及到数据迁移，在生产环境中一次扩缩容可能要迁移TB甚至PB的数据；

(2) 扩缩容期间集群不稳定：保证数据的完整性，往往会从最老的数据进行同步，这样会导致集群时刻处于从磁盘读取数据的状态，disk/net/cpu负载都会比较高；

(3) 扩缩容期间无法执行其他操作：在一次扩缩容操作结束之前，无法进行其他运维操作(扩缩容)。

4.Kafka 未来演进之路

graph TD
问题与挑战 --> 去除zookeeper依赖

问题与挑战 --> 存储计算分离演进

问题与挑战 --> 使用KRaft作为元数据和数据存储介质

1.Kafka去除zk依赖

依赖ZooKeeper存在问题：

(1) 元数据存取困难：元数据的存取过于困难，每次重新选举的controller需要把整个集群的元数据重新restore，非常的耗时且影响集群的可用性。

(2) 元数据更新网络开销大：整个元数据的更新操作也是以全量推的方式进行，网络的开销也会非常大。

(3) 强耦合违背软件设计原则：Zookeeper对于运维来说，维护Zookeeper也需要一定的开销，并且kafka强耦合与zk也并不好，还得时刻担心zk的宕机问题，违背软件设计的高内聚，低耦合的原则。

(4) 网络分区复杂度高：Zookeeper本身并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂度成几何倍数增长。

(5) 并发访问zk问题多：Zookeeper本身并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂度成几何倍数增长。

2.Kafka依赖KRaft

Process.Roles = Broker：服务器在KRaft模式下充当Broker
Process.Roles = Controller：服务器在KRaft模式下充当Controller
Process.Roles = Broker,Controller：·服务器在KRaft模式下充当Broker 和Controller
Process.Roles = null：集群假定运行在ZooKeeper模式下

5.Kafka 运维/调优经验介绍

graph TD
运维/调优经验 --> 单机吞吐

运维/调优经验 --> 参数配置

运维/调优经验 --> 指标可视化

运维/调优经验 --> 扩缩容优化

扩缩容优化目标：

Topic-Partition均匀分布在 Broker间
Broker 间的Replica是均匀的

四、Pulsar详解

1.Pulsar 架构介绍

1.Pulsar Proxy

Pulsar Proxy的作用及应用场景

部分场景无法知道 Broker地址，如云环境或者Kubernetes环境
Proxy提供类似GateWay代理能力，解耦客户端和Broker，保障Broker安全

Pulsar客户端连接集群的两种方式

Pulsar Client -> Broker
Pulsar Client -> Proxy

2. Pulsar Broker

Pulsar Broker无状态组件，负责运行两个模块

Http服务器：暴露了restful接口，提供生产者和消费者topic查找api
调度分发器：·异步的tcp服务器，通过自定义二进制协议进行数据传输

Pulsar Broker 作为数据层代理

Bookie通讯：作为Ledger 代理负责和Bookie进行通讯
流量代理：消息写入 Ledger存储到Bookie·消息缓存在堆外，负责快速响应

3.Pulsar Storage

Pulsar数据存储Segment在不同存储中的抽象:****

(1) 分布式Journal 系统(Bookeeper)中为Journal/Ledger

(2) 分布式文件系统(GFS/HDFS)中为文件

(3) 普通磁盘中为文件

(4) 分布式 Blob存储中为Blob

(5) 分布式对象存储中为对象

定义好抽象之后，即可实现多介质存储

存储阶段：

L1(缓存):

Broker使用堆外内存短暂存储消息
适用于Tail-Read读场景

L2(Bookkeeper):

Bookkeeper使用Qurom写，能有效降低长尾，latency 低
适用于Catch-Up较短时间内的较热数据

L3(S3等冷存):

存储成本低，扩展性好
适用于Catch-Up长时间内的冷数据

4.Pulsar lO连接器

(1) Pulsar lO 分为输入 (Input)和输出（Output)两个模块，输入代表数据从哪里来，通过Source 实现数据输入。输出代表数据要往哪里去，通过 Sink 实现数据输出

(2) Pulsar提出了IO(也称为Pulsar Connector)，用于解决Pulsar与周边系统的集成问题，帮助用户高效完成工作。

(3) 目前Pulsar IO支持非常多的连接集成操作:例如HDFS、Spark、Flink、Flume、ES、HBase等。

5.Pulsar Functions(轻量级计算框架)

(1) Pulsar Functions是一个轻量级计算框架，提供一个部署简单、运维简单、API简单的FAAS平台。

(2) Pulsar Functions提供基于事件的服务，支持有状态与无状态的多语言计算，是对复杂的人数据处理框架的有力补充。

(3) 使用Pulsar Functions，用户可以轻松地部署和管理function，通过function 从 Pulsar topic读取数据或者生产新数据到 Pulsar topic。

2.Bookkeeper 介绍

1.Bookeeper整体架构

2.Bookeeper基本概念

(1) Ledger: BK的一个基本存储单元，BK Client的读写操作都是以Ledger为粒度的

(2) Fragment: BK的最小分布单元(实际上也是物理上的最小存储单元)，也是 Ledger 的组成单位，默认情况下一个Ledger 会对应的一个 Fragment (一个Ledger也可能由多个Fragment组成)

(3) Entry:每条日志都是一个Entry，它代表一个record，每条record都会有一个对应的entry id

3.Bookkeeper Ledger

Bookkeeper新建 Ledger

Ensemble size(E):一个Ledger所涉及的Bookie集合
Write Quorum Size(Qw):副本数
Ack Quorum Size(Qa):写请求成功需要满足的副本数

Bookkeeper Ledger分布

从Bookie Pool挑选 Bookies构成Ensemble
Write Quorum Size决定发送给哪些Bookies
Ack Quorum Size决定收到几个Ack即为成功

4.Bookkeeper 一致性

Bookkeeper写一致性

LastAddPushed
LastAddConfirmed
Fencing避免脑裂

Bookkeeper读一致性： 所有的 Reader都可以安全读取 Entry ID小于或者等于LAC的记录，从而保证reader不会读取未确认的数据，从而保证了reader之间的一致性。

5.Bookkeeper读写分离

写入优化：写入时，不但会写入到Journal中还会写入到缓存(memtable)中，定期会做刷盘(刷盘前会做排序，通过聚合+排序优化读取性能)

读取优化：先读Memtable，没命中再通过索引读磁盘；Ledger Device中会维护一个索引结构，存储在RocksDB中，它会将(Ledgerld，Entryld)映射到(EntryLogld，文件中的偏移量)

6.Bookkeeper with pulsar

Topic-Partition:

Topic由多个partition组成
Partition由多个segment 组成
Segment对应Ledger

特点：

Partition <-> Broker之间只是映射关系
Broker在扩缩容的过程中只需要更改映射即可

3.Pulsar 特性介绍

1.Pulsar生产模式

Access Mode	Describtion
Shared	多个Producer可以同时往一个Topic中生产消息
Exclusive	独占模式生产，只有一个Producer可以connect并生产消息，其他Producer可以启动成功，作为Stand-by
ExclusiveWithFencing	独占模式生产，只有一个Producer可以connect并生产消息，其他 Producer启动时，老的Producer 会断开连接
WaitForExclusive	独占模式生产，只有一个Producer可以connect并生产消息，其他Producer 会卡在创建Producer环节

2.Pulsar消费模式

Exclusive消费模式： 独占订阅(Stream流模型)，独占订阅中，在任何时间，一个消费者组(订阅)中有且只有一个消费者来消费Topic中的消息。

Failover消费模式：故障切换(Stream流模型)，使用故障切换订阅，多个消费者(Consumer)可以附加到同一订阅。但是，一个订阅中的所有消费者，只会有一个消费者被选为该订阅的主消费者。其他消费者将被指定为故障转移消费者。

Shared消费模式 ：共享订阅(Queue队列模型)，使用共享订阅，在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以循环分发形式发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者。

Key Shared消费模式 ：按Key共享订阅(Queue队列模型)，使用共享订阅，在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以key-hash 发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者。

2.Pulsar 多租户

Pulsar Plugin

当前支持Plugin类型
- KOP (Kafka on Pulsar)
- ROP (RocketMQ on Pulsar)
- AOP (AMQP on Pulsar)
- Mop (MQTT on Pulsar)
实现 Plugin需要支持的功能
- 路由查询
- Message Protocol
- Offset & Msgld

Pulsar GEO Relication

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

4.Pulsar 集群 HA & Scale-up

Topic<-> Bundle完成映射
Bundle分配给Broker

5.Pulsar vs Kafka

(1) 存储架构

存储计算分离之后带来的优劣势
多层架构，状态分离之后的优势

(2) 运维操作

应对突发流量变化，集群扩缩容是否便捷
运维任务是否影响可用性
集群部署是否灵活

(3) 功能特性

多语言&多协议
多租户管理
生产消费模式

(4) 生态集成

分层架构优势

计算层

对于写入的数据，可以做预处理，简单ETL。
可以做数据缓存，应对高扇出度场景
无状态，扩缩容之后，能快速完成负载均衡Balance

存储层

按照数据冷热进行存储介质区分，降低成本历史
数据可海量保存，数据无价
可直接通过存储层接口读取数据，批式计算