目录
副本数据同步原理
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 使用再均衡机制来确保分区的重新分配，以提供高可用性和数据冗余。文章来源：https://www.toymoban.com/news/detail-717628.html
-
持久性日志：Kafka 的日志文件具有持久性，即使 Kafka 服务重启，数据也不会丢失。文章来源地址https://www.toymoban.com/news/detail-717628.html
到了这里，关于Kafka入门05——基础知识的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
