存储成本降 60%、效率增 10 倍，小红书云原生 Kafka 技术升级实践_AI阅读总结 — 包阅AI

小红书 Kafka 集群规模伴随着公司业务的蓬勃发展而显著扩张。目前，集群的峰值吞吐量已经达到 TB 级别，并且随着 AI 大模型和大数据技术的持续扩展，数据量仍在快速增长。

尽管经典的 Apache Kafka 架构在提供高吞吐、高性能数据传输方面表现出色，但也逐渐暴露出了一些弊端。一方面，基于多副本和云盘/SSD 的模式，Apache Kafka 的存储成本居高不下，难以满足业务长期存储数据的需要；另一方面，数据与计算节点之前的强绑定关系，严重阻碍了集群的扩缩容效率，在弹性和调度能力方面受到了很大的挑战。

随着小红书 Kafka 集群规模的持续扩大，一系列挑战也随之而来，涉及成本、能效、运维和系统稳定性等多个方面：

成本：

效率：

稳定性：

综上所述，Kafka 集群面临的主要痛点可归纳为两个核心问题：存算一体化架构的局限性，以及虚拟机部署方式带来的运维和资源调度难题。解决这些问题，对于提升 Kafka 集群的整体性能和运维效率，具有重要意义。

1）如何解决“存算一体化”带来的问题？

为了解决存算一体化架构弊端，我们需要引入「Cloud-Native」弹性架构模式，来解耦存储与计算，下述为方案对比：

①自研存算分离（on ObjectStore）：

该方案通过对象存储作为统一的存储基础，实现了计算层与数据绑定关系的解耦。存储层利用对象存储的纠删码技术和规模经济效应，能同时获得秒级弹性与成本两大收益，是较为理想的解决方案。

然而，对象存储本身延迟较高，想要达到整体较高的性能，需要有独立的读写加速层配合，这一部分也需要考虑弹性化的架构设计。整体架构复杂度较高，因此方案研发周期会比较长。

②冷热分层存储（on ObjectStore）：

冷热分层的概念，即为本地仅保留少量的热数据，将大部分冷数据卸载到较为便宜的对象存储中，以实现成本节约。Kafka 和其他 MQ 类社区，近年来陆续提出该概念并进行发展。

此架构不改变数据核心的写入流程和高可用性（HA）机制，而是异步卸载数据以减少对核心架构的改动，实现难度较低。不过弊端也正是因为没有触动核心的副本机制，数据与计算节点之间仍然存在部分的耦合，在弹性能力方面稍逊一筹。

③Apache Pulsar

Apache Pulsar 是近年来非常火热的一款云原生消息引擎，它天生支持存算分离架构，具备快速的弹性扩展特性，同样是一个选择。不过其底下的存储底座 Bookkeeper 仍然基于磁盘存储，单节点受限于磁盘容量，在存储成本上没有明显收益（但 Pulsar 近期也引入了分层存储能力）。此外，考虑到历史大量的存量作业，转向 Pulsar 可能面临较高的推广难度和替换周期，眼下难以快速拿到收益。

在当前阶段，“成本”是我们最关心的问题。如何获得大量成本节省？如何缩短收益获取周期？都是需要核心考虑的因素。在经过大量对比和取舍后，「分层存储」架构依靠其低成本、中等弹性、短落地周期的特点，成为了我们当下的最佳选择。

与社区版本相比，小红书分层架构经过了完全的重新设计，解决了原有方案的多项问题，并显著提升了数据迁移速度和冷数据读取性能。在新架构上线六个月内，我们已完成线上 80% 的集群升级覆盖，充分地获得了新架构带来的各项收益。

2）如何解决“虚机部署”带来的问题？

为了解决虚机部署带来的问题，关键在于提升混部与调度能力、优化算力资源的使用、以及增强自动化运维的水平。以下是几种方案的对比分析：

综合考虑，采用小红书容器底座结合 PaaS 平台托管的新型容器化架构，不仅能够平滑地将 Kafka 迁移至云端，还能显著提升算力资源的利用率，加强运维自动化。

小红书 Kafka 云原生架构共分为四层：

分层存储作为 Kafka 云原生化的核心能力，提供成本优化、消费隔离、弹性扩展等多重优势。其整体架构如下图所示。基本原理是基于冷热分层，即将近实时的热数据保留在高性能云盘中，而将冷数据下沉至低成本、可靠性极高的对象存储中。

对象存储具有无限扩展、低成本、可靠性极高的特点。通过利用对象存储来存储数据，我们能够从根本上解决不断增长的数据存储需求，摆脱了传统数据存储所带来的诸多烦恼。对象存储的架构设计理念，使其在处理大规模数据时表现出色，同时确保了数据的高可用性和安全性，为 Kafka 架构的云原生化提供了强大的支撑。

1）存储成本优化

在大数据场景下，业务方经常需要回溯过去多天的数据，以进行各种分析、回溯和审计等操作。然而，传统的基于云盘的 Kafka 存储解决方案不仅成本高昂，而且在存储能力上也存在限制，只能满足短期数据的存储需求，这对于需要长期数据保留的业务场景构成了重大挑战。

为了突破这一瓶颈，我们采用基于对象存储的分层存储架构。这一创新举措显著降低了存储成本并提升了数据存储的灵活性。对象存储的低成本特性，结合其出色的扩展能力，使得小红书 Kafka 能够经济高效地存储大量数据，同时保证了数据的高可靠性和安全性。

在实施分层存储架构的过程中，我们采取了以下策略：

通过这种新型的存储架构，小红书 Kafka 实现了存储成本的大幅度降低——最高可达 60%。此外，这种架构还允许 Topic 的存储时间从原来的 1 天延长至 7 天或更久，极大地增强了业务数据的回溯能力，为业务数据驱动决策提供更加坚实的基础。

2）分钟级弹性迁移

在 Kafka 原生架构中，集群扩容是一个复杂且耗时的过程。由于冷数据存储在磁盘上，扩容时需要搬迁海量数据，这不仅会导致磁盘和网络 IO 的负载达到极限，也会对集群的稳定性造成影响。

我们引入了分层存储机制后，Topic 的所有副本可以共享同一份冷数据。这意味着对于 Topic 的新副本，在集群扩容时不再需要复制 Leader 本地的所有热数据，而只需拷贝远端尚未拥有的部分，通常是 Leader 本地存储的最后一个 segment。

这种优化显著减少了迁移数据的量，从而将 Topic 迁移的时间从天级别缩短到分钟级别。在实际应用场景中，即使是对于具有 10GB/s 吞吐量的 Topic，在流量高峰期的迁移过程也仅需 5 分钟即可完成。

3）高性能缓存策略

引入对象存储后，虽然解决了存储成本和弹性等问题，但也面临了一些挑战，主要包括访问速度和延迟等方面，具体表现为：

针对这些问题，我们采取了以下优化策略：

这些策略的实施带来了显著的性能提升：

下图为小红书 Kafka 容器化的整体架构：

PaaS 能力托管：通过小红书容器化调度 PaaS 平台来托管 Kafka 集群，这不仅简化了部署和运维流程，降低了运维成本，而且通过图形化界面实现了集群版本和配置的直观管理，即所谓的「白屏化操作」。

服务状态管理：为了保证有状态应用服务的连续性和状态的一致性，我们采用 DupicateSet(StatefulSet) 来管理 Kafka 服务。

异常保护机制：

1）状态管理

在 Kubernetes 环境中部署有状态服务如 Kafka 时，确保其状态的持久性和可靠性是至关重要的。

Kafka 的状态主要包括拓扑状态和存储状态，以下是对这两部分状态的管理策略：

拓扑状态：拓扑状态涉及 Pod 的网络和身份标识，确保每个 Pod 具有固定的标识和访问方式。我们通过容器底座提供的能力保障了 Pod IP 不变。

存储状态：存储状态包括云盘数据、日志数据和配置文件等，这些数据需要在 Pod 迁移、重启或升级时保持不变。

2）离线混部

在上云之前，Kafka 作为存储产品，面临着单机 CPU 能效低下的问题，大约只有 10% 的效率，这主要是由于夜间流量低谷以及 IO-bound 特性所致。在这种情况下，往往存在大量的闲置 CPU 资源，导致资源利用率不高。

上云后通过容器提供的混部能力，我们可以将离线业务调度至 Kafka Kubernetes 机器池中，填平 CPU 低谷，从而保证全天利用率达到一个较高的水平。这种整合策略显著提升了资源的全天利用率，上云后的能效利用率提高到了 40% 以上，远高于之前的水平。

利用容器技术的混部能力，使得我们能够更加灵活地管理和调度资源，根据实际情况对资源进行动态分配和利用，从而最大限度地提高了系统的整体性能和资源利用率。

3）CA 资源调度

除了上述提及能力外，容器技术还为我们带来了资源层面的弹性调度能力，其中 Cluster Autoscaler（CA）是一项关键技术。

在未采用 Cluster Autoscaler 的传统模式下，系统工程师（SRE）需要手动执行服务器的启动和关闭操作，这不仅效率低下，而且在面对紧急的扩容需求时，现有的流程显得繁琐且响应迟缓，无法及时适应业务需求的波动。

引入 Cluster Autoscaler 之后，这一状况得到了根本性的改善。CA 能够自动管理业务集群的扩缩容流程，以缓冲区（Buffer）的形式智能地调整资源分配。它通过实时监控集群的负载情况，动态地增加或减少节点数量，实现了快速且精准的资源弹性调度。这种自动化的调度机制不仅提升了系统的适应性和稳定性，而且显著降低了运维团队的工作负担，确保了业务的持续稳定运行。

在线上部署的 Apache Kafka 集群中，流量波动、Topic 的增减以及 Broker 的启动与关闭是常态。这些动态变化可能导致集群中节点的流量分布不均衡，进而引起资源浪费和影响业务的稳定性。为了解决这一问题，需要对 Topic 的分区进行主动调整，以实现流量和数据的均衡分配。

原生 Apache Kafka 由于磁盘上存储大量历史数据，因此在进行均衡调度时会打满磁盘 IO 和网络带宽，从而影响实时业务的正常运行，导致集群负载均衡较为困难。

相比之下，分层的弹性架构则为负载均衡提供了可能。这种架构设计使得在进行负载均衡调度时可以避免过多的 IO 压力，从而减少对实时业务的影响，使得负载均衡的调整更加灵活和高效。

因此，除了分层和容器两大关键 『弹性』 技术，我们还自研了负载均衡服务 「Balance Control」，其能够充分利用分层和容器的软硬件弹性能力，实现持续数据平衡和自动弹性扩缩容，使得集群能够更加灵活地应对流量波动和业务变化，从而保障了系统的稳定性和可靠性。

1）持续数据自平衡（Auto-Balancing）

Balance Control 采用多目标优化算法来实现资源分配的最优化。其能够综合考虑 Topic 副本、网络带宽、磁盘存储、计算资源等多种因素，自动调整 Partition 分配，以达到最佳的资源负载平衡。整体自平衡流程如下：

2）自动弹性扩缩容（Auto-Scaling）

原生 Kafka 扩容需要搬迁海量数据，耗时通常为小时甚至天级，几乎无法做到按需扩缩容。为了维持集群的稳定性，运维团队不得不提前规划资源，以应对可能的流量高峰，这种做法往往导致资源的浪费和效率的降低。

云原生时代，通过借助分层和容器的软硬件弹性能力，Balance Control 可以在分钟级自动完成集群的原地扩缩容和流量的重新调度，以适应业务负载的变化，做到 「弹性伸缩、按量付费」 的目标。这一关键能力我们称之为 AutoScala。

AutoScala：实时监控 Kafka 集群的负载，并根据预设的策略自动调整集群规模。例如，当集群负载超过某个阈值（如 70%）并保持一段时间时，系统会自动增加集群规模；从而实现快速、高效的集群扩缩容，优化资源利用率。

整体流程如下：