Kafka 痛点专题｜AutoMQ 如何解决 Kafka 冷读副作用

背景

Apche Kafka （下文简称 Kafka）作为一款成功的流处理平台已经在各行各业中有广泛的应用，并且具备极其强大的软件生态。但是，其一些缺点也给使用者带来了很大的挑战。AutoMQ 是基于云原生架构实现的新一代 Kafka ，与 Kafka 100% 完全兼容。致力于解决 Kafka 原有的迁移复制低效、缺乏弹性、成本高昂等缺点，成为新一代云原生 Kafka 解决方案。

为了让读者更好地理解 AutoMQ 相比 Kafka 的优势，我们推出了 《Kafka 痛点专题》 这个系列，帮助读者更好地理解当前 Kafka 存在的痛点问题以及 AutoMQ 是如何解决这些问题的。今天主要分享的是 Kafka 中冷读（也可称追赶读，即 Catch-up Read ）副作用的产生原理，以及 AutoMQ 是如何通过云原生的架构设计来避免原 Kafka 冷读带来的副作用的。

冷读是如何产生的

在消息和流系统中，冷读是常见且具有重要价值的场景，包括以下几点：

• 保证削峰填谷的效果： 消息系统通常用于业务解耦和削峰填谷。在削峰填谷场景中，消息队列可暂时保存上游数据，以便下游逐步消费。这些数据通常不在内存中，而是需要进行冷读取。因此，优化冷读效率对于提高削峰填谷的效果至关重要。

• 批处理场景广泛应用： 在与大数据分析结合时，Kafka 通常用于处理批处理场景。在这种情况下，任务需要从几个小时甚至一天前的数据开始扫描计算。冷读的效率直接影响了批处理的时效性。

• 故障恢复效率： 在实际生产环境中，消费者由于逻辑问题或业务 BUG 导致故障宕机是常见问题。消费者恢复后，需要快速消费堆积的历史数据。提高冷读效率可以帮助业务更快从消费者宕机故障中恢复，减少中断时间。

• Kafka 分区迁移时数据复制引发冷读： Kafka 在扩容时需要迁移分区数据，这时候也会引发冷读。

冷读是 Kafka 中实际应用中必然需要面临的正常需求。对于 AutoMQ 而言，我们并不会去尝试消除冷读，而是重点在于解决好 Kafka 冷读本身带来的副作用。

冷读带来的副作用

接下来我们会分析 Kafka 冷读具体会带来哪些副作用，以及为什么 Kafka 没有办法解决这些问题。

硬盘 I/O 争抢问题

Kafka 运维中的一个重要挑战是处理冷读时对硬盘 I/O 的大量占用。硬盘或云盘的单盘 IOPS 和吞吐能力有限。冷读会导致从硬盘大量读取数据，当某些分区数据在节点上分布不均时，容易造成热点访问。对大量数据的分区进行冷读会快速占用单盘的 IOPS 和吞吐资源，直接影响节点上其他 Topic 分区数据的读写性能。

Kafka 没法解决该副作用的主要原因是其本身存储实现强依赖本地存储。Kafka 的数据全部存储在 Broker 的本地磁盘上，冷读时消耗大量磁盘 I/O 导致其他读写请求需要访问磁盘时性能受限。即使像 Kafka 商业化公司 Confluent 实现了 KIP-405 所描绘的分层存储，该问题仍然没有得到彻底的解决。在 Kafka 分层存储的实现中，Kafka 仍然要求分区的最后一个 LogSegment 必须在本地磁盘上，Broker 和本地存储仍然是强依赖的。因此，Kafka 冷读时则并不能完全从 S3 或者内存从读取数据，其必然有请求需要从分区的最后一个 LogSegment 中读取数据。当 LogSegment 的数据比较大时，硬盘 I/O 的争抢问题也将会更加严重。总的来说，Kafka 采用分层存储试图一定程度去降低冷读副作用的影响，但是并没有在根本上解决问题。

Page Cache 污染

Kafka 冷读时，从磁盘加载大量数据经过 Page Cache 供消费者读取，会造成 Page Cache 的数据污染。Page Cache 的大小是比较有限的，由于本质是个缓存，当新的对象需要加入 Page Cache 时，如果其容量不足，就会驱逐一些旧的对象。

Kafka 没有做冷热隔离，当冷读发生时，大量冷数据的读取会迅速抢占 Page Cache 的容量，将其中其他 Topic 的数据驱逐出去。当其他 Topic 的消费者需要从 Page Cache 读取数据的时候就会发生 Cache Miss，进而必须从硬盘中读取数据，此时读取的延迟将会大大增加。在这种情况下，由于从硬盘加载数据，整体的吞吐性能也会快速退化。Kafka 利用 Pache Cache 结合 sendfile 系统调用在没有发生冷读时有很好的性能表现，但是一旦发生冷读，其对吞吐和读写延迟的影响将会令人非常头疼。
Kafka 没法很好的解决该问题主要还是因为其读写模型本身设计上强依赖 Page Cache 来兑现其强大的性能和吞吐的。

Zero Copy 在冷读时阻塞网络请求

Kafka 采用零拷贝技术sendfile 来避免内核态和用户态交互的开销来提升性能一直以来被大家津津乐道。但是不可否认的是， sendfile 在冷读时，会带来额外的副作用。

在 Kafka 的网络线程模型中，读写请求会共享一个网络线程池来处理网络请求。在没有冷读的理想场景下，网络线程经过 Kafka 的处理后，需要向网络返回数据时，直接从 Page Cache 加载数据返回，整个请求响应在几微秒内可以完成，整个读写流程是非常高效的。

但是如果产生了冷读，Kafka 网络线程向网络的内核发送缓冲区写数据时，调用 sendfile 需要先将磁盘加载到 Page Cache 中，然后再写到网络的内核发送缓冲区。在这个零拷贝过程中，Linux 内核态从磁盘加载数据到 Page Cache 的过程中是个同步的系统调用，因此网络线程只能同步