网站特色栏目重要性,网站推广策划案seo教程,网站开发进度确认单,投资公司取名字大全目录
副本数据同步原理
HW和LEO的更新流程
第一种情况
第二种情况
数据丢失的情况
解决方案
Leader副本的选举过程
日志清除策略和压缩策略
日志清除策略
日志压缩策略
Kafka存储手段
零拷贝#xff08;Zero-Copy#xff09;
页缓存#xff08;Page Cache…目录
副本数据同步原理
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。
HWHigh Water: 水位线。代表的是小于等于HW值的所有消息是已备份的。
LEOLog End Offset日志末端位移。代表的是下一条消息的位移如LEO10表示已有[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请求offset0;
leader收到后确认remote LEO为0
HW由LEO和remote LEO的最小值决定HW 0,
leader回复response包含消息和HW0。
follower收到response追加消息到本地log更新LEO1。 follower第二次发起fetch请求offset1;
leader收到后确认remote LEO为1
HW由LEO和remote LEO的最小值决定HW 1,
leader回复response包含消息(没有数据就返回空)和HW1。
follower收到response追加消息到本地log(有就写入本地日志)更新HW1。 第一种情况到此就完成了数据同步消费者就可以消费offset1的这条消息了。
第二种情况
fetch在阻塞的过程中leader收到了生产者发送的消息就会唤醒fetch请求后面和第一种情况一致。 leader将消息写入本地日志更新leader的LEO 唤醒follower的fetch请求 更新HW
数据丢失的情况
Kafka中min.insync.replicas1默认设定ISR中的最小副本数为1并且acks设置为-1(需要所有副本确认)才生效。
意思就是需要至少1个副本同步才能表示消息时提交的当min.insync.replicas1时只要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是一对值(epochoffset)epoch从0递增当leader变更会epoch1offset是对应的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请求给leaderleader返回LEO leader发生改变follower发送的Request中的epoch和leader不同leader会去查找follower的epoch1对应的StartOffset也就是新leader的LEO返回给follower。 leader宕机了重新选举了leader原本的follower就变成了leaderepoch从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最新的valuekafka的压缩原理就是后台启动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 服务重启数据也不会丢失。
