Kafka的三高设计原理

2024-09-07 05:04

文章标签 设计原理 kafka 三高

本文主要是介绍Kafka的三高设计原理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1.生产者缓存机制--高性能

生产者缓存机制的主要目的是将消息打包，减少网络IO频率

kafka生产者端存在消息累加器RecordAccumulator，它会对每个Partition维护一个双端队列，队列中消息到达一定数量后或者到达一定时间后，通过sender线程批量的将消息发送给kafka服务端。（批量发送）

2.发送应答机制--高可用

发送应发机制保证了消息可以安全到达服务端！

Producer端一个不太起眼的属性ACKS_CONFIG：

acks = 0，生产者不关心broker的应答；不安全，但是速度快
acks = all or -1，生产者需要所有partition的应答；最安全，但是效率低一些
acks = 1，生产者只需要Leader partition的应答；中和

3.生产者消息幂等性--高可用

防止消息重复发送到服务端Broker

（解决了单分区发送的问题）

每个Producer发送消息到Broker的时候，会携带<PID,SN>给Broker，PID是该Producer的唯一标识，SN是消息序号。Broker端会维护这个SN的序列号。如果发送端SN<=服务端SN，则重复应答即可；如果发送端SN>服务端SN，则说明发送的消息有丢失！如果发送端SN=服务端SN+1，则正常接收消息。

（多分区发送的幂等性问题需要事务机制来保证）

4.Controller Broker和Leader Partition--高可用

监控作用

基于Zookeeper的Controller选举机制，Controller Broker管理所有Broker的健康状态；

Leader Partition管理该Topic下的所有partition；

当一个broker中存在多个Leader partition的时候，会触发Leader partition的自平衡机制，涉及到大量消息的转移和同步。

5.Partition的故障恢复机制--高可用

保证各partition的数据一致性

LEO(Log End Offset): 每个Partition的最后一个Offset
HW(High Watermark): 一组Partiton中最小的LEO

当follower partition故障时，该Follower节点会读取本地记录的上一次的HW，将自己的日志中高于HW的部分信息全部删除掉，然后从HW开始，向Leader进行消息同步。

当Leader partition故障时，会选举出新的Leader partition，其他Follower会将各自的Log文件中高于HW的部分全部清理掉，然后从新的Leader中同步数据。

如果follower partition的HW不一致，那kafka通过epoch机制来进行数据同步。

（每个Leader Partition在上任之初，都会新增一个新的Epoch记录。这个记录包含更新后的epoch版本号，以及当前Leader Partition写入的第一个消息的偏移量。接下来其他Follower Partition要更新数据时，就可以不再依靠自己记录的HW值判断拉取消息的起点，而是根据这个最新的epoch条目来同步）