面对 Kafka 规模快速增长带来的成本、效率和稳定性挑战时，小红书大数据存储团队采取云原生架构实践：通过引入冷热数据分层存储、容器化技术以及自研的负载均衡服务「Balance Control」，成功实现了集群存储成本的显著降低、分钟级的集群弹性迁移、高性能的数据访问策略和自动化的资源调度。

这些技术革新不仅极大提升了 Kafka 集群的运维效率，还为小红书业务带来了更优质的服务体验，同时为未来在存算分离、多活容灾等方向的进一步优化奠定了基础。

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

• 成本：

• 存储成本昂贵：Kafka 的存储成本较高，按当前内部机器规格配比，在充分利用带宽的情况下，数据存储的生命周期非常有限。

• 算力资源浪费：Kafka 的性能瓶颈主要集中在 IO 操作上，存在大量的 CPU 资源处于闲置状态。加之现有的虚拟机部署方式在资源共享和隔离方面表现不佳，进一步限制了 CPU 资源的有效分配。

• 效率：

• 集群运维耗时长：因磁盘和节点绑定，Kafka 集群的扩缩容需要搬迁海量数据，这不仅速度缓慢，而且耗时可能从数天到数周不等。

• 调度能力弱：因虚机部署，缺乏灵活的资源调度能力，一旦坏机，补货效率低。

• 稳定性：

• 应急能力差：缓慢的扩缩容速度导致性能指标在高负载下显著下降，请求响应时间可能延长至正常情况的两倍，影响整体服务质量。

• 追赶读期间稳定性受损：在追赶读操作期间，系统资源的大量消耗会使得资源使用率飙升，从而影响到实时读写任务的稳定性

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

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

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

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

• 接入层：小红书 Kafka 特色 SDK，提供鉴权、限流、服务发现等丰富功能，实现更加灵活和安全的数据流管理
• 计算层：Kafka Broker 基于「分层存储」技术，实现本地数据“弱状态化”，有效地解决了系统的弹性问题，保障系统的稳定性和可扩展性
• 调度层：负载均衡调度器向北可均衡 Broker 间流量负载，向南结合容器实现自动化弹性扩缩容，保障系统能够根据实际需求动态调整资源，实现 “弹性伸缩、按量付费”
• 基建层：容器和对象存储底座，为整个系统提供了强大的 PaaS 平台化运维管理调度能力和低成本无限存储能力

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

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

• 访问速度： 对象存储的总吞吐上限理论只受带宽限制，但单线程访问速度较低，远远低于传统磁盘存储。

• 延迟： 目前对象存储主要通过 HTTP 协议进行访问，因此存在较高的延迟，包括建立连接等操作的延迟可达到 20 毫秒级别，对于部分小文件访问极不友好。

• 批量读取： 以 8MB 对齐的方式读取 Segment 数据，减少访问次数，从而提升数据读取的效率。

• 缓存预加载： 结合数据访问的局部性原理和消息队列的顺序读特性，实现了并发的预读机制，以提高数据的访问速度和响应性。同时，通过内存隔离技术，避免了 pagecache 被污染的问题。

• 高缓存命中率： 缓存命中率达到了 99%，有效地提高了数据访问的效率和速度。
• 性能提升：冷数据读取性能相比开源架构提升了 30%，这在大规模数据处理场景中尤为重要。

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

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

• 异常保护机制：

• 基于 Supervisord 的进程监控：在容器内部，Supervisord 作为主要的进程管理工具，监控 Kafka 进程。一旦 Kafka 进程异常退出，Supervisord 能够迅速重启进程，避免了容器级别的重建，从而减少了服务中断时间。

• 快速修复（HotFix）：当基础环境如数据存储出现问题时，业务团队可以直接进入容器进行快速修复，这种即时的干预能力大大提高了系统的稳定性和恢复速度。

• 集群状态的删除保护：我们实现了基于 Kafka 集群状态的删除防护机制。当集群中掉队实例的数量超过预设阈值时，通过 Webhook 技术自动拒绝所有可能恶化集群状态的操作请求，从而保护集群不受进一步损害。

• 存储状态：存储状态包括云盘数据、日志数据和配置文件等，这些数据需要在 Pod 迁移、重启或升级时保持不变。
  
• 持久卷（PV）和持久卷声明（PVC）：使用 DupicateSet 使用，为每个 Pod 分配专用的存储资源，确保存储状态的持久性和一致性。
• 配置管理：使用 ConfigMap 和环境变量来管理 Kafka 的配置，确保 Pod 即使重启，配置也能保持不变。

• 日志管理：将日志目录放置在持久化数据卷中，保障日志数据在 Pod 重启或迁移时不会丢失。

总体来看，云原生弹性架构为小红书 Kafka 带来了巨大的成本收益和运维效率提升。从落地效果上看，我们实现了 60% 的存储成本节省和 10 倍的扩缩容运维效率提升，并成功实现了「弹性伸缩、按量付费」的商品化模式。

此外，我们正不断探索和优化云原生消息引擎的能力，以期提供更稳定和高效的服务。未来，我们计划持续研究存算分离技术和多活容灾方案，以实现极致的系统可扩展性和稳定性，满足业务日益增长的服务需求。

随着技术的不断演进，我们将不断引入新的技术能力和创新方案，为业务提供更加卓越的消息引擎服务，期待您加入团队！‍‍‍

• 六娃(张亿皓)

  小红书大数据存储架构团队负责人，现负责小红书流存储引擎 Kafka、分布式文件加速系统等领域建设。

• 剑尘(黄章衡)

  小红书消息引擎内核研发专家，Apache RocketMQ Committer & SOFASTACK SOFAJRaft Committer，现负责小红书 Kafka 分层存储、负载均衡、存算分离等技术领域建设。

• 阿坎(焦南)

  小红书消息引擎内核研发专家，现负责小红书 Kafka 流批一体、容器化等生态探索和建设。