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

01.消息队列概述

1.1消息队列应用场景

MQ消息队列
EventBridge实践总线
Data Platform流数据平台

1.1.1 MQ消息通道

优势：异步解耦(下游无需关注上游)、削峰填谷（消息缓存，等故障恢复继续提供服务）、发布订阅、高可用

1.1.2 EventBridge数据总线

1.1.3 Data Platform 流数据平台

优势：
1．提供批/流数据处理能力
2. 各类组件提供各类Connect
3. 提供 Streaming/Function能力
4．根据数据schema灵活的进行数据预处理

1.2主流消息队列的相关介绍

02.kafka详解

2.1Kafka架构介绍

2.1.1.Zookeeper

选举机制:Paxos机制
提供一致性:写入(强一致性)、读取(会话一致性)
提供可用性:一半以上节点存活即可读写
提供功能:watch机制、持久/临时节点能力
Kafka存储数据:
1.Broker Meta 信息(临时节点)
2.Controller信息(临时节点)
3.Topic信息(持久节点)
4.Config信息(持久节点)

2.1.2.Broker

Broker角色

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

2.1.3.Controller选举

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

Controller作用

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

Coordinator介绍

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

2.2 Kafka高可用

副本同步机制

提供lsr副本复制机制，提供热备功能
写入端提供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如何保证消息不丢失？

Q1：3副本情况下，如何结合min.insync.replica以及ack的配置，来保证写入kafka系统中的数据不丢失？ ans: min.insync.replica = 2 , ack = -1 Q2：如果是5副本呢？ ans:同上

kafka如何进行副本同步？

LEO:日志最末尾的数据
HW：ISR中最小的LEO作为HW，HW的消息为Consumer可见的消息

Kafka副本选举

N[)K@OM]2T2GDY@~${W%)14.png

Clean选举（更注重数据一致性）

优先选取Isr中的副本作为leader
如果lsr中无可用副本，则partition不可用 Unclean选举（不能保证数据一致性的情况下，保证可用性）
优先选取 lsr中的副本作为leader
如果lsr中无可用副本，则选择其他存活副本

2.3.1. Kafka集群运维

2.3.1.1.Kafka集群扩缩容

Kafka集群扩缩容之后的目标

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

2.3.1.2 Kafka集群扩容步骤

扩容 Broker节点 ·Leader副本写入成功，Producer即认为写成功
计算均衡的 Replica分布拓扑 ·保证Topic 的partition在 broker 间分布均匀 ·保证 Broker之间Replica分布均匀
Controller负责新的副本分布元数据广播 .Controller 将新的leader/follower信息广播给broker
Broker负责新副本的数据同步 ·Broker上有需要同步数据的副本则进行数据同步

8UITY8@XP~URPF@BIOW%~J4.png

2.4.1 Kafka未来演进之路

问题与挑战：1.去除zk依赖；2.存储计算分离；3.使用KRaft作为元数据和数据存储介质

2.4.1.1 Kafka为什么要去除zk依赖？

元数据存取困难
·元数据的存取过于困难，每次重新选举的controller需要把整个集群的元数据重restore，非常的耗时且影响集群的可用性。
元数据更新网络开销大
·整个元数据的更新操作也是以全量推的方式进行，网络的开销也会非常大。
强耦合违背软件设计原则
Zookeeper对于运维来说，维护Zookeeper也需要一定的开销，并且kafka强耦合与zk也并不好，还得时刻担心zk的宕机问题，违背软件设计的高内聚，低耦合的原则。
网络分区复杂度高
Zookeeper本身并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂度成几何倍数增长。
并发访问zk问题多
·Zookeeper本身并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂度成几何倍数增长