kafka08-生产者消息发送流程详解2：PageCache持久化

PageCache持久化的时机

消息存储及可靠性

1. 多副本机制：Kafka 通过在不同的 Broker 节点上存储数据副本来实现高可用性。每个 TopicPartition 都有一个 Leader 和多个 Follower（ISR）。所有的读写操作首先在 Leader 上执行，然后 Follower 从 Leader 那里同步数据。这样即使 Leader 故障，Follower 可以被选举为新的 Leader，继续提供服务。

2. TopicPartition 的存储：Kafka 将消息按照 TopicPartition 为单位存储，每个 TopicPartition 由一个或多个 Segment 组成。这种分片机制是 Kafka 进行负载均衡的基本单位。

3. Segment 文件：每个 TopicPartition 包含以下三种类型的文件：

   • log 文件：实际存储消息数据的文件，也称为数据分片文件。
   • index 文件：消息的索引文件，存储了 <offset, position> 的映射，其中 offset 是消息的索引值，position 是消息在 log 文件中的相对位置。
   • timeindex 文件（从 Kafka 0.10.1.1 版本开始）：时间索引文件，存储了 <timestamp, offset> 的映射，允许按照时间戳来查询消息。

多副本的复制

1. 数据复制：为了保证数据的高可用性，Kafka 需要将数据复制到不同的 Broker 节点上。这是通过多副本机制实现的，每个 TopicPartition 都有一个 Leader 和多个 Follower。

2. 写入确认：在数据被复制到其他 Broker 节点之前，默认情况下，Broker 不会向生产者反馈数据写入成功。这意味着生产者可能需要等待数据被复制到所有同步副本（ISR）后才能得到确认。

3. 炼狱（Purgatory）：为了提高复制数据的效率，Leader 节点会将需要复制的数据生成一个请求对象，并存储在 map 结构的炼狱中。炼狱是一种特殊的数据结构，用于存储尚未完成的复制请求。

4. Follower 的 I/O 线程：Follower 副本的 I/O 线程负责从 Leader 接收数据，并将其复制到自己的 PageCache 中。这个过程是异步的，并且通常在后台进行。

5. 复制完成：一旦数据被完全复制到其他 Broker 节点的 PageCache 中，Follower 会向 Leader 发送复制完成的确认。

6. 响应生产者：收到所有 Follower 的复制确认后，Broker 会将请求对象从炼狱中取出，生成一个响应对象，并将其放在响应队列中。这样，生产者就可以从响应队列中获取到写入成功的反馈。

7. 生产者配置：生产者可以通过设置 acks 参数来控制何时收到写入确认。例如，acks=0 表示不需要 Leader 的确认，acks=1 表示只需要 Leader 的确认，而 acks=all 表示需要所有同步副本的确认。

8. 数据的持久性：尽管 Kafka 允许异步刷盘，但它仍然提供了持久性保证，通过多副本机制确保数据在多个节点上可用，从而在发生故障时可以快速恢复。

向客户端反馈响应信息

1. 写入确认级别：当 acks=all 时，生产者需要等待所有参与复制的节点（即 ISR 列表中的所有副本）都收到消息后，才会收到来自 Leader 副本所在 Broker 节点的响应，并认为消息 "写入成功"。

2. 最小同步副本数：min.insync.replicas 参数控制消息至少需要被写入到多少个副本才算 "真正写入" 成功。这个参数的常见设置为 replication.factor-1。例如，如果 replication.factor=3，则 min.insync.replicas 应设置为 2。

3. 复制完成：当数据被复制到至少 min.insync.replicas 数量的 Broker 上时，复制过程被认为是成功的。

4. 响应生成：一旦数据复制成功，Broker 端的 Network Thread 会从响应队列中提取生成的响应。

5. 发送响应：Network Thread 将响应数据发送到 socket send buffer 中，准备通过网络发送给客户端。

6. 请求排序和响应发送：Network Thread 会对来自每个客户端的请求进行排序，确保在从 Request Queue 中获取下一个请求对象之前，向该客户端发送完所有的响应信息。

7. 客户端接收响应：客户端从 socket receive buffer 中读取数据，根据响应信息判断消息是否发送成功。

8. 生产者确认：客户端（生产者）根据接收到的响应信息，确定消息是否成功写入 Kafka 集群。如果写入成功，生产者可以继续发送下一批消息。

消息发送流程的总结

• 生产者客户端向 Broker 端循环生成发送数据请求：

  • 生产者客户端生成消息，并使用 NetworkClient 类通过 Java NIO 向 Kafka 集群中的 Broker 发送 Produce 请求，将消息发送到指定的 TopicPartition。

• Broker 端的 Network Thread 和 IO Thread 处理收到的数据请求：

  • 当 Broker 端的 Network Thread 接收到生产者的 Produce 请求时，它负责从网络连接中读取请求数据，并将其转化为请求对象。
  • IO Thread 负责进一步处理这些请求对象，例如执行验证（如 CRC 校验）并将数据写入 PageCache。

• Request Queue 负责缓存发送消息的请求：

  • Broker 端维护一个 Request Queue，用于按照请求到达的顺序缓存和管理所有的请求对象。这确保了请求的有序处理。

• IO Threads 负责将消息写入 PageCache 中，并最终将消息写入 TopicPartition 日志中：

  • IO 线程从 Request Queue 中获取请求对象，将经过验证的数据（RecordBatch）追加到对应 TopicPartition 的 Leader Broker 的 PageCache 中。
  • 数据在 PageCache 中暂存，待后续进一步处理，最终会被持久化到硬盘上的日志文件中。

• Kafka 集群中的炼狱（purgatory）在将日志复制到其他 Broker 节点时扮演的重要作用：

  • 炼狱（purgatory）在 Kafka 中是一种等待处理条件的机制，特别在处理消息复制过程中起到关键作用。
  • 当消息需要被复制到其他 Broker 的副本时，炼狱会管理等待复制确认或同步的状态。它确保了消息复制的正确性和可靠性，处理了各种复制操作中可能出现的等待条件。

• Network Thread 负责从 Response Queue 中获取数据写入的 ack 信息，并将 ack 信息反馈给客户端：

  • 在消息成功写入 Leader Broker 的所有副本后，Leader Broker 会生成 ack（确认）信息，并将其返回给生产者客户端。
  • Network Thread 负责从 Response Queue 中获取这些 ack 信息，并将它们传递给对应的生产者客户端，以通知消息的成功写入和处理状态。