甜品网页设计毕业论文seo常规优化

目录

副本数据同步原理

HW和LEO的更新流程

第一种情况

第二种情况

数据丢失的情况

解决方案

Leader副本的选举过程

日志清除策略和压缩策略

日志清除策略

日志压缩策略

Kafka存储手段

零拷贝（Zero-Copy）

页缓存（Page Cache）

Kafka的消息可靠性

---

在ISR中，只要有一个Follower存活就能确保Commit的数据不会丢失。那如果分区所有副本都失效了，会发生什么？

无法确保Commit数据不丢失，会出现可用性和一致性问题。需要采取折中方案：

1. 等待ISR中第一个“活”过来的副本，选举它为Leader。

2. 选择第一个“活”过来的副本，但它不一定是Leader。

第一种方案的问题就是不可用的时间会相对较长。第二种方案的问题是不保证包含所有Commit的消息。所以往往采取的是第一种方案。

副本数据同步原理

Kafka 的数据副本同步原理是确保消息的高可用性和数据冗余的关键机制。在 Kafka 中，每个分区通常都有多个副本，其中一个是领导副本（Leader Replication）负责读写操作，其他是追随者副本（Follower Replication）用于数据备份和容错。

以其中一个分区的副本同步通信举例，当producer将消息发布到某个partition时：

1. 通过zookeeper找到分区的leader，将消息发送给leader(无论多少个副本，生产者只将消息发送给leader)。

2. leader将消息写入本地log。每个follower从leader拉取数据，follower存储顺序与leader一致。

3. follower在收到消息并写入自身log后，向leader发送Ack。

4. 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继续处理。

在初始状态下，会出现两种情况：

1. leader处理完生产者请求后，follower发送一个fetch请求。

2. 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请求，后面和第一种情况一致。

1. leader将消息写入本地日志，更新leader的LEO

2. 唤醒follower的fetch请求

3. 更新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 的作用：

1. 数据丢失恢复：Epoch 机制用于解决因为领导副本故障而导致的数据丢失问题。当一个新的领导副本被选定时，Kafka 会使用 Epoch 来确定哪些追随者副本具有相同的数据，并将数据从这些追随者副本中恢复。

2. 数据冲突解决：Epoch 也用于解决数据冲突问题，确保只有具有最新数据的副本成为新的领导副本。

举个例子：

在分区的本地磁盘上持久化了一个/tmp/kafkalog/topic/leader-epoch-checkpoint的文件，文件的内容类似于[0,50],[1,89],[2,100]...leader broker会保存这样一个缓存，定期写入文件中。

当leader写log时，会尝试更新整个缓存。

• 如果leader首次写，缓存中新加一条数据。

• 如果leader不是首次写，那就不更新。

副本每次成为loader时都会查询这部分缓存，获取对应的leader版本的offset。

针对数据丢失的场景，就有了对应的解决办法：

1. follower宕机恢复后

   • leader没有发生改变：发送OffsetForLeaderEpochRequest请求给leader，leader返回LEO

   • leader发生改变：follower发送的Request中的epoch和leader不同，leader会去查找follower的epoch+1对应的StartOffset，也就是新leader的LEO，返回给follower。

2. leader宕机了，重新选举了leader：原本的follower就变成了leader，epoch从0变为了1，原本follower中的LEO值得到了保留。

Leader副本的选举过程

KafkaController会监听Zookeeper的/broker/ids节点路径，有broker挂了的时候，对应broker中分区的leader副本就需要重新选举。

选举策略：

1. 优先从ISR列表中选取第一个作为leader副本，叫优先副本。

2. 如果ISR列表为空，查看topic的unclean.leader.election.enable配置。

   • true：允许选择非ISR列表的副本作为leader，有可能数据丢失

   • false：不允许选择非ISR列表的副本作为leader，抛出异常，选举失败

3. 在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 中，零拷贝技术用于以下几个方面：

1. 生产者：Kafka 生产者使用零拷贝来将消息从内存传输到网络套接字，从而提高发送性能。

2. 消费者：Kafka 消费者使用零拷贝来将消息从网络套接字传输到内存，从而提高接收性能。

3. 磁盘写入：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 服务重启，数据也不会丢失。