目录
副本数据同步原理
HW和LEO的更新流程
第一种情况
第二种情况
数据丢失的情况
解决方案
Leader副本的选举过程
日志清除策略和压缩策略
日志清除策略
日志压缩策略
Kafka存储手段
零拷贝(Zero-Copy)
页缓存(Page Cache)
Kafka的消息可靠性
在ISR中,只要有一个Follower存活就能确保Commit的数据不会丢失。那如果分区所有副本都失效了,会发生什么?
无法确保Commit数据不丢失,会出现可用性和一致性问题。需要采取折中方案:
-
等待ISR中第一个“活”过来的副本,选举它为Leader。
-
选择第一个“活”过来的副本,但它不一定是Leader。
第一种方案的问题就是不可用的时间会相对较长。第二种方案的问题是不保证包含所有Commit的消息。所以往往采取的是第一种方案。
副本数据同步原理
Kafka 的数据副本同步原理是确保消息的高可用性和数据冗余的关键机制。在 Kafka 中,每个分区通常都有多个副本,其中一个是领导副本(Leader Replication)负责读写操作,其他是追随者副本(Follower Replication)用于数据备份和容错。
以其中一个分区的副本同步通信举例,当producer将消息发布到某个partition时:
-
通过zookeeper找到分区的leader,将消息发送给leader(无论多少个副本,生产者只将消息发送给leader)。
-
leader将消息写入本地log。每个follower从leader拉取数据,follower存储顺序与leader一致。
-
follower在收到消息并写入自身log后,向leader发送Ack。
-
leader收到ISR中所有的副本的Ack后,消息被认为commit成功,leader更新HW并向生产者发送Ack。
HW(High Water): 水位线。代表的是小于等于HW值的所有消息是已备份的。
LEO(Log End Offset):日志末端位移。代表的是下一条消息的位移,如LEO=10,表示已有[0,9]共10条消息。
HW和LEO的更新流程
初始状态的HW和LEO都是0。Leader中存放了一个表示follower的LEO值 remote leo也为0。
当前生产者没有发送消息,但是Follower会不断地向leader发送fetch请求,因为leader没有接收到消息,follower的fetch会阻塞。参数配置replicas.fetch.wait.,ax.ms决定阻塞时间。时间内,生产者发送消息给leader的话,fetch请求会被唤醒,让leader继续处理。
在初始状态下,会出现两种情况:
-
leader处理完生产者请求后,follower发送一个fetch请求。
-
follower的fetch请求阻塞时间内,leader收到生产者发送的请求
第一种情况
生产者发送一条消息,leader处理后,消息追加到本地log,更新LEO为1。
follower第一次发起fetch请求,offset=0;
leader收到后确认remote LEO为0,
HW由LEO和remote LEO的最小值决定,HW = 0,
leader回复response,包含消息和HW=0。
follower收到response,追加消息到本地log,更新LEO=1。
follower第二次发起fetch请求,offset=1;
leader收到后确认remote LEO为1,
HW由LEO和remote LEO的最小值决定,HW = 1,
leader回复response,包含消息(没有数据就返回空)和HW=1。
follower收到response,追加消息到本地log(有就写入本地日志),更新HW=1。
第一种情况到此就完成了数据同步,消费者就可以消费offset=1的这条消息了。
第二种情况
fetch在阻塞的过程中leader收到了生产者发送的消息,就会唤醒fetch请求,后面和第一种情况一致。
-
leader将消息写入本地日志,更新leader的LEO
-
唤醒follower的fetch请求
-
更新HW
数据丢失的情况
Kafka中min.insync.replicas=1默认设定ISR中的最小副本数为1,并且acks设置为-1(需要所有副本确认)才生效。
意思就是需要至少1个副本同步才能表示消息时提交的,当min.insync.replicas=1时,只要leader将消息写入log就认为是“已提交”,而延迟一轮fetch rpc更新HW值的设计使得follower HW的值是异步延迟更新的。
假设这个过程中,leader发生变更,那新leader中的HW值就有可能是过期的,使得“已提交” 的消息被删除。
acks表示生产者发送消息到broker上以后的确认之。
-
0:表示不需要确认。时延小风险大(server宕机,数据就会丢失)
-
1:表示只需要leader确认。时延小同时确保leader接收成功
-
all(-1):需要ISR所有replicas确认。速度慢,安全性最高,但ISR会缩小到只有一个replicas,也不一定能避免数据丢失。
解决方案
Kafka的0.11版本引入了leader epoch解决数据丢失问题。 leader epoch是一对值(epoch,offset),epoch从0递增,当leader变更会epoch+1,offset是对应的leader写入第一条消息的offset。
Epoch 的作用:
-
数据丢失恢复:Epoch 机制用于解决因为领导副本故障而导致的数据丢失问题。当一个新的领导副本被选定时,Kafka 会使用 Epoch 来确定哪些追随者副本具有相同的数据,并将数据从这些追随者副本中恢复。
-
数据冲突解决:Epoch 也用于解决数据冲突问题,确保只有具有最新数据的副本成为新的领导副本。
举个例子:
在分区的本地磁盘上持久化了一个/tmp/kafkalog/topic/leader-epoch-checkpoint的文件,文件的内容类似于[0,50],[1,89],[2,100]...leader broker会保存这样一个缓存,定期写入文件中。
当leader写log时,会尝试更新整个缓存。
-
如果leader首次写,缓存中新加一条数据。
-
如果leader不是首次写,那就不更新。
副本每次成为loader时都会查询这部分缓存,获取对应的leader版本的offset。
针对数据丢失的场景,就有了对应的解决办法:
-
follower宕机恢复后
-
leader没有发生改变:发送OffsetForLeaderEpochRequest请求给leader,leader返回LEO
-
leader发生改变:follower发送的Request中的epoch和leader不同,leader会去查找follower的epoch+1对应的StartOffset,也就是新leader的LEO,返回给follower。
-
-
leader宕机了,重新选举了leader:原本的follower就变成了leader,epoch从0变为了1,原本follower中的LEO值得到了保留。
Leader副本的选举过程
KafkaController会监听Zookeeper的/broker/ids节点路径,有broker挂了的时候,对应broker中分区的leader副本就需要重新选举。
选举策略:
-
优先从ISR列表中选取第一个作为leader副本,叫优先副本。
-
如果ISR列表为空,查看topic的unclean.leader.election.enable配置。
-
true:允许选择非ISR列表的副本作为leader,有可能数据丢失
-
false:不允许选择非ISR列表的副本作为leader,抛出异常,选举失败
-
-
在2的配置为true的基础上,选出一个leader副本,并且ISR列表只包含该leader副本。选举成功后,将leader和ISR其他副本信息写入该分区对应的Zookeeper路径上。
日志清除策略和压缩策略
日志清除策略
kafka的日志使用的分段存储,一方面能减少文件内容的大小,另一方面方便kafka日志清理。日志清理策略有两个:
-
根据消息的保留时间,超过指定时间的消息会被清理
-
根据存储的数据大小,当日志文件大于一定的阈值就删除最旧的消息。
kafka有一个后台线程,定期检查是否存在可以删除的消息。对应的两个参数配置:log.retention.bytes和log.retention.hours。消息默认保留时间是7天。
日志压缩策略
消息的保存方式是key-value的形式,消费者只关心相同的key最新的value,kafka的压缩原理就是后台启动Cleaner线程,定期将相同的key进行合并,保存最新的value。
Kafka存储手段
零拷贝(Zero-Copy)
零拷贝是一种技术,通过它可以将数据从一个缓冲区(如内存)传输到另一个缓冲区,而不需要在中间进行数据的复制。这可以提高数据传输的效率和降低CPU和内存的开销。在 Kafka 中,零拷贝技术用于以下几个方面:
-
生产者:Kafka 生产者使用零拷贝来将消息从内存传输到网络套接字,从而提高发送性能。
-
消费者:Kafka 消费者使用零拷贝来将消息从网络套接字传输到内存,从而提高接收性能。
-
磁盘写入:Kafka 使用零拷贝来将数据从内存缓冲区写入到磁盘,这可以提高磁盘写入的效率。
页缓存(Page Cache)
Kafka 使用操作系统的页缓存来管理磁盘上的数据。Page Cache 是操作系统的一部分,它将磁盘上的数据缓存在内存中,以便快速读取和写入。Kafka 利用了页缓存来加速磁盘的读写操作,提高了消息的持久性和性能。
具体来说,Kafka 将消息写入到磁盘时,首先将消息写入到操作系统的页缓存中,然后异步刷写到磁盘上。这样,Kafka 可以将多个小的写操作合并成更大的写操作,减少磁盘 I/O 操作的次数,提高写入性能。
另外,当 Kafka 消费者读取消息时,它可以从页缓存中读取消息,而不必每次都直接访问磁盘,这降低了读取的延迟。
Kafka的消息可靠性
消息的可靠性很难达到百分百完全可靠的地步,常常会用几个9作为衡量标准。kafka保证消息可靠性的手段:
-
分区和副本:Kafka 的消息被分布到多个分区中,每个分区通常有多个副本。这样即使其中一个节点或分区发生故障,消息仍然可以从其他节点或副本中获取,从而提高可用性和可靠性。
-
Leader-Follower 架构:每个分区都有一个领导副本(Leader)和多个追随者副本(Followers)。生产者写入消息到领导副本,然后领导副本负责将消息复制到追随者副本,确保数据冗余。
-
消息持久性:Kafka 使用文件系统和操作系统的缓存来提高消息的持久性。消息首先写入到文件系统缓存,然后异步刷写到磁盘,以避免写入性能的下降。
-
复制同步:Kafka 使用复制同步机制来确保数据同步。只有当追随者副本确认已成功复制数据后,生产者才会收到确认。
-
消息确认:生产者和消费者可以配置确认机制,确保消息的可靠性。生产者可以等待所有副本都确认成功后才发送确认,而消费者可以等待消息处理成功后才发送确认。
-
数据冗余:消息在多个副本之间进行冗余,如果一个副本出现故障,仍然可以从其他副本获取数据。
-
再均衡(Rebalance):在消费者组中,Kafka 使用再均衡机制来确保分区的重新分配,以提供高可用性和数据冗余。
-
持久性日志:Kafka 的日志文件具有持久性,即使 Kafka 服务重启,数据也不会丢失。