这是我参与「第四届青训营」笔记创作活动的的第12天
01.消息队列概述
1.1.消息队列的应用场景
1.1.1. MQ消息通道
1.1.2 EventBridge 数据总线
事件源:将云服务、自定义应用、SaaS 应用等应用程序产生的事件消息发布到事件集。
事件集:存储接收到的事件消息，并根据事件规则将事件消息路由到事件目标。
事件目标:消费事件消息。
1.1.3 Data Platform流数据平台
1.提供批/流数据处理能力
2.各类组件提供各类Connect
3.提供Streaming/Function能力
4.根据数据schema灵活的进行数据预处理
1.2主流消息队列的相关介绍
02.Kafka详解
2.1 Kafka 架构介绍
2.1.1 Zookeeper
Kafka存储数据:
-
Broker Meta信息(临时节点)
-
Controller信息(临时节点)
-
Topic信息(持久节点)
-
Config信息(持久节点)
● 选举机制: Paxos机制
● 提供一致性: 写入(强一致性) 读取(会话一致性)
● 提供可用性: 一半以上节点存活即可读写
● 提供功能: watch机制 持久/临时节点能力
2.1.2 Broker
● Broker角色
1)若干个Broker节点组成Kafka集群
2)Broker作为消息的接收模块，使用React网络模型进行消息数据的接收
3)Broker作为消息的持久化模块，进行消息的副本复制以及持久化
4)Broker作为高可用模块，通过副本间的Failover进行高可用保证
2.1.3.2 Controller 选举
Controller选举
1）Broker启动会尝试去zk中注册controller节点
2）注册_上controller节点的broker即为controller
3）其余broker会watch controller节点，节点出现异常则进行重新注册
2.1.3.2 Controller作用
● Controller作用
1）Broker重启/宕机时，负责副本的Failover切换
2）Topic创建/删除时，负责Topic meta信息广播
3）集群扩缩容时，进行状态控制
4）Partition/Replica状态机维护
2.1.4 Coordinator
● Coordinator介绍
1）负责topic partition <-> consumer的负载均衡
2）根据不同的场景提供不同的分配策略
（1）Dynamic Membership Protocol
（2）Static Membership Protocol
（3）Incremental Cooperative Rebalance
2.2 Kafka 高可用
可用性定义
● Kafka高可用
1）副本同步机制
（1）提供lsr副本复制机制，提供热备功能
（2）写入端提供ack=0,-1,1机制，控制副本同步强弱
2）副本切换机制
（1）提供clean/unclean副本选举机制
2.2.1 Kafka 副本ISR机制
● AR
Assign Replica,已经分配的所有副本
● OSR
1）Out Sync Replica
2）很久没有同步数据的副本
● ISR
1）一直都在同步数据的副本
2）可以作为热备进行切换的副本
3）min.insync.replicas最少isr数量配置
2.2.2 Kafka写入Ack机制
● Ack= 1
1）Leader副本写入成功，Producer 即认为写成功
● Ack= 0
1）OneWay模式
2）Producer发送后即为成功
● Ack =-1
1）ISR中所有副本都成功，Producer 才认为写成功
2.2.3 Kafka如何保证消息不丢?
▪️ 问题1
1）3副本情况下，如何结合min.insync.replica以及ack的配置，来保证 写入kafka系统中的数据不丢失?
▪️ 问题2
如果是5副本呢?
2.2.3 Kafka副本同步
● LEO
Log End Offset,日志最末尾的数据
● HW
1）ISR中最小的LEO作为HW
2）HW的消息为Consumer可见的消息
2.2.3 Kafka 副本选举
● Clean选举
1）优先选取Isr中的副本作为leader
2）如果Isr中无可用副本，则partition 不可用
● Unclean选举
1）优先选取Isr中的副本作为leader
2）如果Isr 中无可用副本，则选择其他存活副本
3.1.1 Kafka集群扩缩容
● Kafka集群扩缩容之后的目标
1）Topic维度
（1）partition在各个broker之间分布是均匀的
（2）同一个partition的replica不会分布在一台broker
2）Broker维度
（1）Broker之间replica的数量是均匀的
3.1.2 Kafka集群扩容步骤
▪️ 扩容Broker节点
1）Leader副本写入成功，Producer 即认为写成功
▪️ 计算均衡的Replica分布拓扑
1）保证Topic的partition 在broker间分布均匀
2）保证Broker之间Replica分布均匀
▪️ Controller负责新的副本分布元数据广播
1）Controller将新的leader/follower信息广播给broker
▪️ Broker负责新副本的数据同步
1）Broker上有需要同步数据的副本则进行数据同步
3.1.2 Kafka集群缩容步骤
▪️ 计算均衡的Replica分布拓扑
1）保证Topic的partition 在broker间分布均匀
2）保证Broker之间Replica分布均匀
▪️ Controller负责新的副本分布元数据广播
1）Controller将新的leader/follower信息广播给broker
▪️ Broker负责新副本的数据同步
1）Broker上有需要同步数据的副本则进行数据同步
▪️ 下线缩容的Broker节点
1）数据同步完毕之后下线缩容的Broker节点
3.1.2 Kafka集群扩缩容问题
● 扩缩容时间长
1）涉及到数据迁移，在生产环境中一次扩缩容可能要迁移TB甚至PB的数据
● 扩缩容期间集群不稳定
1）保证数据的完整性，往往会从最老的数据进行同步，这样会导致集群时刻处于从磁盘读取数据的状态，disk/net/cpu 负载都会比较高
● 扩缩容期间无法执行其他操作
1）在一次扩缩容操作结束之前，无法进行其他运维操作(扩缩容)
4.1 Kafka未来演进之路
4.1.1 Kafka去除zk依赖
▪️ 依赖ZooKeeper存在问题
1）元数据存取困难
（1）元数据的存取过于困难，每次重新选举的controller需要把整个集群的元数据重新restore,非常的耗时且影响集群的可用性。
2）元数据更新网络开销大
（1）整个元数据的更新操作也是以全量推的方式进行，网络的开销也会非常大。
3）强耦合违背软件设计原则
（1）Zookeeper对于运维来说，维护Zookeeper也需要一 定的开销， 并且kafka强耦合与zk也并不好，还得时刻担心zk的宕机问题，违背软件设计 的高内聚，低耦合的原则。
4）网络分区复杂度高
（1）Zookeeper本身并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂度成几何倍数增长。
5）并发访问zk问题多
（1）Zookeeper本身并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂度成几何倍数增长。
4.1.2 Kafka 依赖 KRaft
● Process. Roles = Broker
1）服务器在KRaft模式下充当Broker
● Process. Roles = Controller
1）服务器在KRaft模式下充当Controller
● Process. Roles = Broker, Controller
1）服务器在KRaft模式下充当Broker和Controlle
● Process. Roles = null
1）那么集群就假定是运行在ZooKeeper模式下。
5.1 Kafka 运维/调优经验介绍
5.1.1 Kafka单机吞吐
● Kafka Version
1）2.3.1
● 机器配置
1）40C 500GB 12 * 1TB 25GB
● 写入配置
1）Ack =-1, replica=3, in_ sync_ replica = 3
2）单条消息5 KB
● 吞吐
1）单机150MB/s
5.1.2 Kafka集群参数配置
zookeeper. session.timeout.ms = 30000
log.segment.bytes = 536870912
log.retention.hours - 36
log.retention.bytes = 274877906944
num.network.threads = 32
num.io.threads = 200
auto.create.topics enable = false
auto.leader.rebalance.enable = false
unclean.leader.election.enable = false
advertised.listeners = SASL PL AINTEXT://:,PL AINTEXT://:
security.inter.broker.protocol = SASL PL AINTEXT
5.1.3 扩缩容优化
● 目标
1）Topic Partition均匀分布在Broker间
2）Broker间的Replica是均匀的
5.1.4 指标可视化
03.Pulsar详解
3.1 Pulsar架构介绍
3.1.1 Pulsar Proxy
▪️ Pulsar客户端连接集群的两种方式
1）Pulsar Client -> Broker
2）Pulsar Client -> Proxy
▪️ Pulsar Proxy的作用及应用场景
1）部分场景无法知道Broker地址，如云环境或者Kubernetes环境
2）Proxy提供类似GateWay代理能力，解耦客户端和Broker,保障Broker安全
3.1.2 Pulsar Broker
▪️ Pulsar Broker无状态组件，负责运行两个模块
1）Http服务器
（1）暴露了restful接口，提供生产者和消费者topic查找api
2）调度分发器
（1）异步的tcp服务器，通过自定义二进制协议进行数据传输
3）Pulsar Broker作为数据层代理
（1）Bookie通讯
i.作为Ledger代理负责和Bookie进行通讯
4)流量代理
(1) 消息写入Ledger存储到Bookie
(2)消息缓存在堆外，负责快速响应
3.1.3 Pulsar Storage
● Pulsar数据存储Segment在不同存储中的抽象
-
分布式Journal系统(Bookeeper)中为Journal/L .edger
-
分布式文件系统(GFS/HDFS)中为文件
-
普通磁盘中为文件
-
分布式Blob存储中为Blob
-
分布式对象存储中为对象
● 定义好抽象之后，即可实现多介质存储
● L1(缓存):
-
Broker使用堆外内存短暂存储消息
-
适用于Tail-Read读场景
● L2(Bookkeeper):
-
Bookkeeper使用Qurom写，能有效降低长尾，latency 低
-
适用于Catch-Up较短时间内的较热数据
● L3(S3等冷存):
-
存储成本低，扩展性好
-
适用于Catch-Up长时间内的冷数据
3.1.4 Pulsar IO 连接器
▪️ Pulsar I0分为输入(Input) 和输出(Output) 两个模块，输入代表数据从哪里来，通过Source实现数据输入。输出代表数据要往哪里去，通过Sink实现数据输出。
▪️ Pulsar提出了I0 (也称为 Pulsar Connector)，用于解决Pulsar与周边系统的集成问题，帮助用户高效完成工作。
▪️ 目前Pulsar 10支持非常多的连接集成操作:例如HDFS、Spark、Flink、 Flume、 ES、HBase等。
3.1.5 Pulsar Functions (轻量级计算框架)
● Pulsar Functions是一个轻量级计算框架， 提供一个部署 简单、运维简单、API简单的FAAS平台。
● Pulsar Functions提供基于事件的服务，支持有状态与无状态的多语言计算，是对复杂的大数据处理框架的有力补充。
● 使用Pulsar Functions,用户可以轻松地部署和管理function,通过function从Pulsar topic读取数据或者生产新数据到Pulsar topic.
3.2.1 Bookeeper整体架构
3.2.2 Bookkeeper基本概念
● Ledger: BK的一个基本存储单元，BK Client的读写操作都是以Ledger为粒度的
● Fragment: BK的最小分布单元(实际上也是物理上的最小存储单元)，也是Ledger的组成单位，默认情况下一个Ledger会对应的一个Fragment (- 个Ledger也可能由多个Fragment组成)
● Entry:每条日志都是一个Entry,它代表一一个 record,每条record都会有一个对应的entry id
3.2.3.1 Bookkeeper 新建 Ledger
1）Ensemble size(E): 一个Ledger 所涉及的 Bookie 集合
2）Write Quorum Size(Qw): 副本数
3）Ack Quorum Size(Qa): 写请求成功需要满足的副本数
3.2.3.2 Bookkeeper Ledger 分布
从 Bookie Pool 挑选 Bookies 构成 Ensemble
Write Quorum Size 决定发送给哪些 Bookies
Асk Quоrum Ѕіzе 决定收到几个 Асk 即为成功
3.2.4.2 Bookkeeper 写一致性
▪️ LastAddPushed
▪️ LastAddConfirmed
▪️ Fencing避免脑裂
3.2.4.3 Bookkeeper 读一致性
所有的Reader都可以安全读取Entry ID小于或者等于LAC的记录，从而保证reader不会读取未确认的数据，从而保证了reader之间的一致性。
3.2.4.1 Bookkeeper 读写分离
▪️ 写入优化:
写入时，不但会写入到Journal中还会写入到缓存(memtable)中，定期会做刷盘(刷盘前会做排序，通过聚合+排序优化读取性能)
▪️ 读取优化:
1）先读Memtable,没命中再通过索引读磁盘
2）Ledger Device中会维护一个索引结构，存储在RocksDB中，它会将(Ledgerld, Entryld) 映射到(EntryLogld,文件中的偏移量)
3.2.5 Bookkeeper with pulsar
1）Topic-Partition:
（1）Topic由多个partition组成
（2）Partition由多个segment组成
（3）Segment对应Ledger
2）可以发现:
（1）Partition <-> Broker之间只是映射关系
（2）Broker在扩缩容的过程中只需要更改映射即可
3.3 Pulsar功能介绍
3.3.1 Pulsar 生产模式
3.3.2 Pulsar消费模式
1）Exclusive 2）Failover 3）Shared 4）Key_ Shared
3.3.2.1 Exclusive消费模式
● 独占订阅(Stream流模型)
独占订阅中，在任何时间，一个消费者组(订阅)中有且只有一个消费者来消费Topic中的消息。
3.3.2.2 Failover消费模式
● 故障切换(Stream流模型)
1）使用故障切换订阅，多个消费者(Consumer) 可以附加到同一订阅。但是，个订阅中的所有消费者，只会有一个消费者被选为该订阅的主消费者。其他消费者将被指定为故障转移消费者。
3.3.2.3 Shared消费模式
● 共享订阅(Queue队列模型)
1）使用共享订阅，在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。 订阅中的所有消息以循环分发形式发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者。
3.3.2.4 Key_ Shared 消费模式
● 按Key共享订阅(Queue队列模型)
1）使用共享订阅，在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以key-hash发送给订阅背后的多个消费者，并且一个消息仅传递给-个消费者。
3.3.3 Pulsar 多租户
Pulsar 多租户体现在 Url 中
▪️ persistent://tenant/namespace/topic
3.3.4 Pulsar Plugin
● 当前支持Plugin类型
1）KOP (Kafka on Pulsar)
2）ROP (RocketMQ on Pulsar)
3）AOP (AMQP on Pulsar)
4）Mop (MQTT on Pulsar)
● 实现Plugin需要支持的功能
1）路由查询
2）Message Protocol
3）Offset & Msgld
3.3.5 Pulsar GEO Relication
▪️ 跨数据中心复制
▪️ 消费其他地域数据
3.4.1 Pulsar HA & Scale-up
▪️ Topic <-> Bundle 完成映射
▪️ Bundle 分配给 Broker
3.4.2 Pulsar HA & Scale-up
▪️ Lookup Topic
▪️ Lookup Result
▪️ Establish TCP Connection
3.5 Pulsar VS Kafka
● 存储架构
1）存储计算分离之后带来的优劣势
2）多层架构，状态分离之后的优势
● 运维操作
1）应对突发流量变化，集群扩缩容是否便捷
2）运维任务是否影响可用性
3）集群部署是否灵活
● 功能特性
1）多语言&多协议
2）多租户管理
3）生产消费模式
● 生态集成
3.5.1存储计算分离
▪️ 分层架构优势
1）流量代理层和数据存储层解耦
2）流量代理层无状态，可快速扩缩容(k8s等弹性平台)
3）流量代理层可以对接海量的客户端连接
4）存储层负责数据存储，
5）可以使用多级存储
▪️ 计算层
1）对于写入的数据，可以做预处理，简单ETL
2）可以做数据缓存，应对高扇出度场景
3）无状态，扩缩容之后，能快速完成负载均衡Balance
▪️ 存储层
1）按照数据冷热进行存储介质区分，降低成本
2）历史数据可海量保存，数据无价
3）可直接通过存储层接口读取数据，批式计算
04.周边和生态
4.1 周边生态概览
4.1 4 Pulsar I0
4.1.2 Kafka Schema
▪️ - 向Kafka发送数据时，需要先向Schema Registry注册schema,然后序列化发送到Kafka里
▪️ - Schema Registry server为每个注册的schema提供一个全局唯一ID,分配的ID保证单调递增，但不一定是连续的
▪️ -当我们需要从Kafka消费数据时，消费者在反序列化前，会先判断schema是否在本地内存中，如果不在本地内存中，则需要从Schema Registry中获取schema,否则，无需获取
