拆解小红书存储底座 00｜从孤岛走向融合：小红书存储与数据库架构进化

小红书社区、广告、电商、推荐、搜索等业务的数据底座，是一套自研的存储与数据库体系。产品矩阵覆盖四族：关系型数据库（MySQL、PG、分库分表 RedHub 等）、缓存数据库（Redis、RedKV）、多模数据库（宽表、图、向量），以及自研存储（对象存储 ROS、高性能文件系统 RedFS 等，统一落在池化底座 RedStore 上）；往上再由 DMS 云平台、运维 Agent SDBP、全球数据总线 RedDTS 等公共能力把各产品贯通起来。业务场景多、数据规模大，选型散、部署重、运维难，是团队要解决的主要问题。

团队用两年时间，把10多个存储和数据库类产品从各自建设带入统一管控、分层复用、业务原生的融合架构：ROS、RedFS、DTS、MySQL、RedTao等产品多项指标在行业领先，产品 NPS 提升到 60% 以上的同时，研发运维投入从 40% 降至 10% 以下。

作为「拆解小红书存储数据库底座」系列的首发篇，本文将完整回顾这条演进路径的判断、取舍与阶段成果，讲清“整张地图” —— 如何从各产品孤岛式建设走向统一融合。

过去几年，小红书业务快速发展。自 2023 年起，存储与数据库资源规模几乎每年翻倍，场景也从单一社区流量支撑扩展到电商交易、全球化、AI 训练与推理等。规模扩大后，产品种类、功能、稳定性、性能、交付效率、产品体验和资源成本都面临更高要求。有限的人力难以支撑各产品持续单点补齐，团队由此开始围绕统一管控、分层复用、业务原生推进体系化演进。

01

业务增长之后，挑战从单点变为系统性

2024 年年中，团队系统梳理了当时的产品矩阵。7 个数据库类产品分别由 4～8 人的小组建设，用户入口、运维平台和底层组件相对独立，研发精力更多投在线上交付与运维，能投入产品架构迭代的人力受到挤压。与此同时，业务对基础设施的期待也在变化：电商需要高并发与强一致能力，国际化需要跨地域数据流动，AI 训练需要高吞吐和高性能密度，AI 推理则带来向量、图与 KV Cache 等新型负载。

业务需求场景的多样化，也导致不同存储和数据库产品在能力上建设各有侧重。缓存数据库更关注响应延迟波动和可用性，交易数据库强调热点处理、一致性和可靠性，对象与文件存储强调吞吐、容量和成本，全球化数据链路还要处理弱网质量与合规边界。若每个产品各自建设管控、Proxy、存储层、容灾和数据流转能力，交付周期会变长，长期维护成本也会持续上升。

基础设施建设周期通常较长，而业务从提出需求到上线却要求更快。团队规模也比行业大型基础设施团队精干，无法同时铺开所有方向。因此核心问题是如何判断趋势、排定优先级，并用可复用的分层架构降低研发投入，这样既响应当期业务，也为下一阶段留出空间。

02

以四个判断确定方向，以四条逻辑决定取舍

2024 年下半年，团队形成了四个面向未来的业务判断：

• 第一，面向消费者的流量变现主要由广告与电商驱动，高并发交易、秒杀与强一致能力需要提前准备。

• 第二，AI 训练和推理将成为基础设施的重要增量。

• 第三，国际化会逐步推进，跨地域、弱网和合规约束下的数据总线能力不可缺位。

• 第四，业务体量扩大后，成本与供应链韧性会更受关注，自建云与公有云结合的多云基础设施将成为长期形态。

基于这些判断，团队确定了四条产品技术演进逻辑：

• 一是效率先行，用平台化、自动化和 AI 减少重复运维，从被动响应转向主动规划。

• 二是分层复用，在管控、接入、传输和存储底座等层面跨产品复用，少造轮子，以小团队支撑多类数据库和自建云大存储。

• 三是业务原生，按电商、国际化、AI 等业务节奏布局 MySQL 高并发交易与强一致、全球数据总线、AI 训练大存储等能力。

• 四是阶段取舍，对 NewSQL、存算分离、Serverless 和分布式块存储等长周期方向，结合规模、收益和技术成熟度择机启动。

实际落地时，统一管控先覆盖高频、共性的用户与运维流程，不取代各产品的管控面。分层复用抽取 Proxy、数据传输和存储底座等公共能力，不强行合并所有产品。业务原生则根据负载特征选择缓存、关系型数据库、对象存储、文件系统或多模态数据库。这样既保留产品的针对性，也让公共投入能跨方向复用。

03

三阶段演进：先筑基础，再做融合

阶段一（2024 年下半年—2025 年下半年）：夯实效率与稳定性基础

这一阶段先处理日常运维投入较高、操作入口分散和硬件故障处置能力不足的问题。团队将各产品用户平台与运维平台逐步统一到存储与数据库云平台 DMS，复用工单、工作流、前端和基础运维能力；管控面也开始自动处置常见硬件故障，完善止损和治理机制，缩小故障影响范围。

以 Redis、RedKV 为例，早期研发用于交付和运维的时间一度高达 40%。团队先整合两个产品的 Proxy 层，在统一代理中治理异常流量，识别、拦截慢节点和突发流量，避免局部异常扩散后导致集群流量跌零。团队也重构了部分用户和运维平台，把操作校验、审批、执行与回滚纳入标准流程，减少黑屏操作和人为差异。截至 2025 年下半年，研发日常运维投入占比从高峰期的40%降至 20% 以下；同期集群规模增长约一倍，百万核口径下的故障数量仍明显下降。

大存储方向也完成基础布局。分布式池化存储底座RedStore、HDD 标准对象存储 ROS 完成研发和灰度，开始承接自建机房存储需求。面向 AI 场景的高性能对象存储ROS-Express 启动建设，成为国内首批采用大容量 QLC NVMe 提升对象存储性能密度的企业。多云存储网关统一多家云的对象与文件存储访问、管控、数据调度和多活能力，把基础设施差异留在网关，把一致、简单的体验交给业务。

阶段二（2025 年下半年—2026 年下半年）：形成可持续的融合架构

基础问题得到改善后，团队进入以分层和跨产品复用为主题的第二代架构演进，以提高后续研发迭代。统一存储&数据库平台 DMS 继续收敛容量预警与管理、批量运维等共性能力，成为统一的业务和运维入口。存储&数据库运维治理 AI Agent 助手 SDBP正式上线，经过半年多实践，On-call 和运维有效覆盖率超过 50%，自主闭环率超过 30%；研发日常运维投入进一步降至 10% 以下，运维由自动化逐步走向智能化。

面向国际化，全球数据总线 DTS 2.0统一了各个数据库与存储产品在全球多站点、弱网传输和合规约束下的数据迁移、容灾与多活能力。过去分散在不同产品中的跨地域链路，由此具备共同的数据通道和治理框架。这既缩短新产品接入周期，也为后续站点扩展、合规治理保留一致的能力边界。

面向 AI 训练，ROS-Express 改善了稀疏模型训练所需的存储性能密度，并提升 GPU 资源利用效率。RedStore持续优化底层性能，支撑高性能并行文件系统RedFS 满足大模型训练的高读写吞吐，以及算法开发目录对小文件低时延访问的需求。相较于 SOTA 开源产品，带宽和延迟均有大幅度优化。

面向 AI 推理，向量和图数据库开始承接 Agent 类场景需求，基于 RedKV 的混合KV Cache开始承接大模型推理 L3 级缓存。面向 Vibe Coding 和 Agent 开发，团队也开始布局 BaaS（Backend as a Service），尝试降低业务使用和管理基础设施的门槛。截至 2026 年 10 月，统一入口、共享组件、存储底座、全球数据传输和 AI 存储能力共同构成新一代存储与数据库体系，产品矩阵和分层架构基本成型。

阶段三（2026 年下半年—2027 年下半年）：向 SOTA 技术架构更进一步

以下内容是截至 2026 年 10 月在研内容，或面向未来 1～1.5 年的小红书存储&数据库第三代产品技术规划。团队将以业务收益、稳定性验证和技术成熟度为前提，分阶段推进：

• 存算分离与 Serverless：随着电商和社区运营活动增多，探索存算分离的 Serverless 数据库架构，提升快速扩容、紧急扩容的时效和资源利用率。

• 缓存数据库技术架构整合：整合内存型与硬盘型缓存，同时兼顾大模型推理 L3 KV Cache；探索多租户和 Serverless 能力，让容量自动弹性，减少业务选型和运维负担。

• 协议互通与多模融合：探索 ROS-Express 与 RedFS 的 S3、POSIX 协议透明互访，减少对象与文件存储间的数据复制和切换。以 RedDB 为底座，逐步融合标量、向量、全文与图数据的存储和检索能力。

• RedStore 承接数据库负载：由 RedStore 支撑大规模 RedDB 宽表和多租户 Serverless 版 RedKV。为保障高负载下 P999 时延平稳，还需持续优化请求排队、RDMA 通信、内存使用和后台任务调度。

• 关系型数据库与 K8S 计算节点存储拉远：为 MySQL 等核心数据库和自建机房 Kubernetes 负载建设单机故障域的远程盘方案，由上层保障数据可靠性，并平衡投入、性能和故障影响。RedDisk 接入层、元数据与管控接口会考虑向后演进；是否发展为类似云厂商 EBS 的分布式块存储，将结合 RedStore 成熟度评估。

• SDBP 智能化 Harness 工程闭环：完善 Agent Harness，探索问题发现、分析、修改、持续集成、发布和灰度等环节的 AI 闭环能力，并结合全局记忆开展场景化治理。推进过程中坚持人机协同和权限控制，在国际化业务升级前完成海外团队运维无人化。

这些规划仍以业务价值为核心导向、把控好技术先进性和稳定性之间的平衡、兜住底情况下尽量激进，更快的为业务赋能。

04

成效与未来展望

回顾 2024 年以来的演进，集群规模持续增长的背景下，研发日常运维投入从高峰期的40%降至 10% 以下，产品 NPS 提升到60%以上，ROS、RedFS、DTS、MySQL、RedTao等产品多项指标在行业领先，故障治理能力和产品体验也得到改善。DMS 成为统一管控入口，多云存储网关与 DTS 2.0 承接跨云、跨地域数据流动，SDBP 推动运维从自动化走向智能化。RedStore、ROS、ROS-Express 与 RedFS 形成分层存储能力，向量、图数据库则开始承接多模数据场景。

多个产品融合、互通后，业务不必分别理解多套底层实现，研发也能在共享能力上组合场景化方案。架构建设由“一个产品解决一个问题”转向“公共能力沉淀、产品按需组合”，让规模增长与团队投入逐步解耦。团队以远低于行业平均水位的人员投入规模，建设了能全面支撑业务快速发展的存储与数据库产品矩阵，同时团队同学的工作幸福感在持续改善。

后续建设仍以业务价值为导向、平衡好技术先进性和稳定性，按照架构能兜底稳定性的方式来追求快速演进。评估时会关注业务收益、交付速度、故障影响范围、资源效率和成本等，避免盲目追求技术先进性偏离实际需求。

05

结束语

过去两年，团队逐步把公共能力沉入平台和底座，再由各产品按业务场景组合。统一管控、分层复用和业务原生，是这条演进路径上的几项关键做法。本文是系列总览，后续文章会继续拆解各产品的技术架构。

感谢小红书存储与数据库团队成员过去两年的投入。小红书的存储和数据库产品技术体系仍在快速演进，我们期待与行业伙伴持续交流，在实践中探索更稳定、更高效、更开放的基础设施。

///

作者简介

少锋，小红书存储&数据库部负责人。主要负责小红书存储和数据库相关产品技术体系建设和核心竞争力打造。

部门介绍：

存储&数据库部，为小红书全业务场景打造行业一流的高可用、高可靠、高性能、低成本的存储和数据库类产品技术服务。团队致力于用精英化的组织和行业领先的技术理念，先于业务布局和行动，为公司业务的快速发展提供充足“弹药“，同时也让小红书存储和数据库成为行业该领域的标杆。