这是我参与「第四届青训营 」笔记创作活动的第17天
本次笔记重点内容
- 消息队列概述
- Kafka 详解
- Pulsar 详解
- 周边和生态
消息队列概述
应用场景
MQ消息通道
实现了上下游解耦，下游不用关注上游变化；下游出现故障时，消息可以缓存在此；上游不用知道下游有哪些业务，下游只需要订阅数据即可消费，扩展性强；把大模块解耦成小模块，小模块各个功能是解耦的，具备高可用。
EventBridge数据总线
Data Platform流数据平台
中间的Kafka是常见的MQ系统，数据写入通过它进入系统。
主流消息队列
Kafka
架构
Producer进行数据生产，写入Kafka存储系统；Consumer进行数据消费；Zookeeper负责元数据存储，提供读写一致性，有watch机制，观测某节点数据变化；Broker集群由多个Broke节点构成，Topic/Partition均匀分布在各个Broker中，分为主（Leader）从（Follower）节点，主节点负责数据的写入，从节点负责副本备份。
Kafka高可用
副本同步机制
lsr副本复制机制——提供热备功能
min.insync.replicas保证最少的isr数量配置，如果过少，不能保证数据的安全。
写入ACK机制
Ack=1，Leader副本写入成功，Producer则认为写成功；Ack=0，OneWay模式，Producer发送后即为成功；Ack=-1，ISR中所有副本都成功Producer才认为写成功。
如何保证信息不丢失？
min.insync.replicas配置成2，Ack配置成-1。
副本切换机制——Kafka副本选举
Clean选举
优先选择lsr中的副本作为leader，如果无可用副本，则partition不可用
Unclean选举
优先选择lsr中的副本作为leader，如果无可用副本，则选择其他存活副本
集群扩缩容
- Topic维度：partition在各个broker之间分布是均匀的，同一个partition的副本replica不会分布在一台broker上
- Broker维度：Broker之间的副本数量是均匀的
集群扩容步骤
扩容Broker节点，计算均衡的副本拓扑，Controller负责将新的leader/follower信息广播给broker，Broker上有需要同步数据的副本则进行数据同步
集群缩容步骤
与集群扩容仅一处不同，就是扩容Broker节点放到了最后变成了下线缩容的Broker节点
扩缩容问题
- 时间过长，涉及到数据迁移
- 期间集群不稳定，集群时刻从磁盘读取数据，disk/net/cpu负载高
- 期间无法执行其他操作
Kafka未来演进——问题与挑战
- 去除zookeeper依赖
- 存储计算分离
Pulsar
架构
Pulsar客户端连接集群的两种方式——Proxy/Broker
Pulsar Proxy
部分场景无法知道Broker地址，Proxy解耦客户端和Broker保障Broker安全，让用户不用知道Broker地址就能生产
Pulsar Broker
作为Http服务器，提供生产者和消费者topic查找api能力；调度分发器，通过自定义二进制协议进行消息数据传输；作为流量代理层，用JAVA堆外内存进行缓存，负责快速响应
Pulsar Storage
L1级缓存，Broker使用堆外内存短暂存储消息；L2级Bookkeeper缓存，有效降低长尾延迟，适用于Catch-up较短时间内的较热数据；L3级存储成本低，扩展性好，适用于Catch-up长时间内的冷数据
Bookkeeper整体架构
写流程
读流程
Ledger是Bookkeeper的一个基本存储单元；Fragment是Bookkeeper最小分布单元；Entry是每条日志的称呼
Bookkeeper写一致性
Pulsar功能介绍
- 生产模式
- 消费模式
- 独占订阅——Stream流模型
- Failover订阅——故障切换，Stream流模型
- Shared订阅——共享订阅，Queue队列模型
- Key_Shared订阅——共享订阅，Queue队列模型
Pulsar Plugin
支持插件
- KOP
- ROP
- AOP
- MOP
