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

消息队列

MQ消息通道

EventBridge数据总线

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

Data Platform流数据平台

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

Kafka

Kafka架构介绍

ZooKeeper

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

Kafka存储数据：

1. Broker Meta信息（临时节点）
2. Controller信息（临时节点）
3. Topic信息（持久节点）
4. Config信息（持久节点）

Broker

Broker角色：

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

Controller

Controller选举

• Broker启动会尝试去zk中注册controller节点
• 注册上controller节点的broker即为controller
• 其余broker会watch controller节点，节点出现异常则进行重新注册

Controller作用

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

Coordinator

Coordinator介绍

• 负责topic-partition<->consumer的负载均衡
• 根据不同的场景提供不同的分配策略
  • Dynamic Membership Protocol
  • Static Membership Protocol
  • Incremental Cooperative Rebalance

Kafka高可用

Kafka高可用

• 副本同步机制
  • 提供sr副本复制机制，提供热备功能
  • 写入端提供ack=0,-1,1机制，控制副本同步强弱
• 副本切换机制
  • 提供clean/unclean副本选举机制

副本ISR机制

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

写入ACK机制

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

副本同步

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

副本选举

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

Kafka集群扩缩容

Kafka集群扩缩容之后的目标

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

扩容

扩容Broker节点

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

计算均衡的Replica分布拓扑

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

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

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

Broker负责新副本的数据同步

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

缩容

计算均衡的Replica分布拓扑

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

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

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

Broker负责新副本的数据同步

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

下线缩容的Broker节点

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

扩缩容问题

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

Pulsar

Pulsar架构介绍

Pulsar Proxy

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

• Pulsar Client -Broker
• Pulsar Client -Proxy

Pulsar Proxy的作用及应用场景

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

Pulsar Broker

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

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

Pulsar Broker作为数据层代理

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

Pulsar Storage

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

• 分布式Journal系统(Bookeeper)中为Journal/Ledger
• 分布式文件系统(GFS/HDFS)中为文件
• 普通磁盘中为文件
• 分布式B引ob存储中为B引ob
• 分布式对象存储中为对象

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

L1(缓存)：

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

L2(Bookkeeper):

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

L3(S3等冷存)：

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

Pulsar IO 连接器

• Pulsar IO分为输入(Input)和输出(Output)两个模块，输入代表数据从哪里来，通过Source实现数据输入。输出代表数据要往哪里去，通过Sik实现数据输出。
• Pulsar提出了IO(也称为Pulsar Connector),用于解决Pulsar与周边系统的集成问题，帮助用户高效完成工作。
• 目前Pulsar 1O支持非常多的连接集成操作：例如HDFS、Spark、Flink、Flume、ES、HBase等。

Pulsar Functions（轻量级计算框架）

• Pulsar Functions是一个轻量级计算框架，提供一个部署简单、运维简单、API简单的FAAS平台。
• Pulsar Functions提供基于事件的服务，支持有状态与无状态的多语言计算，是对复杂的大数据处理框架的有力补充。
• 使用Pulsar Functions,用户可以轻松地部署和管理function,通过function从Pulsar topic读取数据或者生产新数据到Pulsar topico

Bookkeeper

Bookkeeper整体架构

Bookkeeper基本概念

• Ledger：BK的一个基本存储单元，BK Client的读写操作都是以Ledger:为粒度的
• Fragment：BK的最小分布单元（实际上也是物理上的最小存储单元)，也是Ledger的组成单位，默认情况下一个Ledger会对应的一个Fragment(一个Ledger也可能由多个Fragment组成)
• Entry：每条日志都是一个Entry，它代表一个record,每条record都会有一个对应的entry id

Bookkeeper新建Ledger

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

Bookkeeper Ledger分布

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

Bookkeeper写一致性

• LastAddPushed
• LastAddConfirmed
• Fencing避免脑裂

Bookkeeper读一致性

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

Bookkeeper读写分离

• 写入优化：写入时，不但会写入到Journal中还会写入到缓存(memtable)中，定期会做刷盘（刷盘前会做排序，通过聚合+排序优化读取性能)
• 读取优化：先读Memtable,没命中再通过索引读磁盘、Ledger Device中会维护一个索引结构，存储在RocksDB中，它会将(Ledgerld,Entryld)映射到(EntryLogld,文件中的偏移量)

Bookkeeper with pulsar

Topic-Partition

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

可以发现：

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

Pulsar功能介绍

Pulsar生产模式

Pulsar消费模式

Exclusive：

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

Failover

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

Shared

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

Key_Shared

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

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

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

Pulsar HA & Scale-up

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

• Lookup Topic
• Lookup Result
• Establish TCP Connection

Pulsar vs Kafka

存储架构

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

运维操作

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

功能特性

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

生态集成

存储计算分离

计算层

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

存储层

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

分层架构优势

• 流量代理层和数据存储层解耦
• 流量代理层无状态，可快速扩缩容（k8s等弹性平台）
• 流量代理层可以对接海量的客户端连接
• 存储层负责数据存储，可以使用多级存储