Kafka的持久化及副本机制总结

kafka生产者写消息时，并不是直接写到硬盘里，那样太慢了

持久化机制

1.先写到PageCache里 由操作系统决定什么时候要刷盘 当broker写到PageCache里时就认为是写成功 返回ack，而且若是读消息时发现消息在pagecache里 会直接读实现真正的零拷贝

虽然也可以自定义刷盘间隔  但是强烈不建议这么做 会大幅降低kafka的性能和吞吐量

2.由操作系统通过追加写(顺序写)的方式追加到日志文件尾部，当日志文件过大时，会把一个日志文件进行分段，通过偏移量索引文件(.index)和时间戳索引文件(.timeindex)进行快速定位

3.即使消息被消费后，也不会立刻删除 而是按时间或按大小来清理，

所以kafak是通过pagecache+磁盘顺序写的方式来持久化数据,大幅提高了消息读写的性能

副本机制:解决数据持久化问题，提供容灾

若是只把数据存到一个broker里，若该broker宕机，则服务中断，所以kafka用独特的副本机制提供容灾，就是鸡蛋别放在一个篮子里

一个分区的副本会存在不同的broker上  各个分区之间只有一个leader 其余的皆为 follower 且follower仅做备份用，所有的读写操作都在leader上进行，follwer要做的是不断通过异步的方式从leader拉取最新数据，努力与leader保持同步

AR:所有副本的集合

ISR:保持同步的副本 主要是根据时间来(以前的版本会按消息条数来 已废弃)，若是长时间没有同步消息则会被踢出ISR，存在zookeeper内

OSR:不能保持同步的副本

ACK机制:在一定条件下，leader才会把消息标记为已提交 即可读状态

配置:

0:不等待任何ack回应 容易丢消息

1:要等待lead的ack回应 保证至少lead持久化了消息

all:需要等到所有ISR中的副本都收到消息后 lead才回复ACK

Leader选举与故障恢复

一般来说 当分区的leader宕机后，controller 会从isr中选一个新的当leader

可以配置 unclean.leader.election.enable 授予脏副本选举资格

选举机制:创建topic时默认将第一个上线的副本设置为leader

当leader宕机后 controller 会从ISR中选取一个follower来当leader