拆解小红书存储底座 01｜多源数据传输总线 RedDTS 2.0

导读

小红书的存储与数据库体系覆盖 MySQL、RedKV、Redis、ROS 等产品。数据源各有读写协议，业务又需要在它们之间以及不同地域之间迁移、同步和订阅数据。RedDTS 是这套体系中的数据传输公共能力：连接不同数据源，为各产品提供可复用的传输底座。

RedDTS 作为小红书自研的数据传输服务，提供数据迁移、同步与订阅能力。存储数据库团队从 2025 年 8 月开始，历时 6 个月完成 RedDTS 2.0 从 0 到 1 上线。本文围绕架构分工、关键取舍与数据传输实践，介绍数据总线的建设过程。

早期，小红书的数据传输能力主要围绕不同数据源和业务场景分别建设，分别面向不同数据源与传输场景，由多个团队独立建设与维护，运维体系与能力边界互不统一。但随着业务发展，数据传输共性问题需要各套服务解决，造成大量重复投入，交付周期无法匹配业务发展节奏。

为此，存储数据库团队提出了架构融合、统一传输底座的思路，解决数据传输中共性问题，各数据源适配接入，以实现“一套架构、多源受益”。

团队从两个维度重新定义数据传输服务：

对内，以多数据源统一接入为目标，终结 MySQL / Redis / RedKV 等各数据源各自建设的碎片化局面；
对外，以多区双向传输为需求，攻坚多区级联、弱网传输和数据冲突等核心难题。

设计了小红书数据总线服务（第二代 RedDTS），完成多项关键技术突破，实现数据“接得进、存得住、传得快、传得对”。

接得进：架构融合，统一传输底座

团队拆解了既有的多套数据传输服务（MySQL DTS、Gunyu、Replicator 与 Canal 等），发现不同系统的主干流程高度一致，都是“采集 → 传输 → 写入”，差异主要集中在日志格式、两端读写协议和治理方式。RedDTS 2.0 据此把系统重新抽象为 Reader、Storage 和 Writer 三层。

链路抽象，统一主干：传输链路统一为 Reader（日志读取）→ Storage（日志存储）→ Writer（日志写入）三层总线架构；
接入抽象，收敛差异：制定统一数据格式与标准接口族，将数据源差异收敛至适配层；新数据源实现一组接口即可接入。

截至目前，MySQL、RedKV、Redis、ROS 等数据源已接入数据总线架构，覆盖同步、订阅、迁移等传输场景，实现了数据“接得进”。

存得住：数据持久化，可回放可恢复

业界多数数据传输框架无数据持久化能力，增量日志数据“即读即传、过后即失”，故障恢复完全受制于源端日志保留窗口。日志一旦轮转清理，链路失去续传锚点，只能全量重同步，恢复周期达小时级，并伴随数据丢失风险。

RedDTS 2.0 引入独立的 Storage 层，将“传输通道”升级为“带存储的总线”。日志一次采集、持久沉淀，以可靠存储为基础底座支持重复消费与故障自愈，采集与消费的生命周期也随之解耦。

但带存储的总线引入了新的工程约束 —— 日志数据长期留存推高存储成本，而实时传输要求读写低延迟。低成本留存与低延迟读写难以兼得，RedDTS 2.0 在 Storage 模块构建了多级存储体系。

L0 内存短期数据：毫秒级读写，服务在线实时传输；
L1 本地化中期数据：本地热数据层提供低延迟访问，服务高吞吐同步与追赶消费；
L2 对象存储远期数据：冷数据层以低成本长期保留，服务故障恢复与数据回溯。

至此，日志数据留存不再依赖源端保留窗口，接入传输总线的 MySQL、RedKV、Redis 集群天然具备7~15 天增量日志持久化，并基于存储底座，衍生出数据恢复、数据迁移等解决方案，做到数据“存得住”。

传得快：全链路传输性能优化

接得进、存得住之后，数据传输进一步面临性能挑战：在跨地域传输场景中，高 RTT、网络抖动与带宽限制相互叠加，传输效率被急剧削弱，高峰时段同步延迟可达小时级。为此，RedDTS 2.0 沿“读取 → 存储 → 传输 → 写入”全链路逐段治理：存储读取侧以预读消解磁盘时延，传输侧以压缩降低带宽占用，写入侧以无锁并发提升回放吞吐。

经全链路优化，极限场景下单任务传输速率达到100 MB/s（同城场景），性能对齐云厂商同类产品。核心集群跨区同步在高峰时段的数据积压得到消除，实现数据“传得快”。

传得对：多区域防回环与错区写入保护

吞吐提升后，在跨区双向同步中还需要保证两件事：传输路径正确，数据在多区级联流转中需杜绝环形回流导致的反复覆写；落地数据不被误改，各区已存数据不因错区流量而被错误覆盖。RedDTS 2.0 以防回环与错区写入保护两项能力分别予以应对。

4.1 多区域防回环

让数据仅送达目标区域，首先需要解决级联双向同步的回环问题：多区间双向流转时，同一份数据可能沿环形链路回流、覆写源数据。RedDTS 2.0 设计级联双向同步方案，以“数据分区 → 血缘过滤”机制治理环路，在公司内首次实现多区域级联双向同步。

① 数据分区

将多区机器与数据统一划分为大区（vcr）→ 逻辑区（region）→ 逻辑机房（zone）三层分区。数据在总线传输时，依据源集群的分区归属自动附加地域标记，业务零改造，每条数据都拥有确定的分区身份。

② 血缘过滤

每条数据携带Source（数据逻辑分区）与 Path（途经逻辑分区，逐跳追加）双血缘标记，若目标的逻辑分区信息命中 Path，即判环丢弃。一套逻辑覆盖 MySQL / Redis / RedKV 数据源，不依赖引擎内核标识（server_id / GTID / 事务表）。

4.2 错区写入保护

数据沿正确路径落地后，还需防范来自流量侧的破坏。业务流量打偏至非归属区时，错区写入将覆盖正确数据，并经双向同步向其他区域扩散。业界通用解法为业务侧透传“单元 ID”实现流量纠偏，但社区业务历史架构缺乏该字段，改造成本极高、短期无法落地。RedDTS 2.0 提出新的设计路径：数据归属不由流量声明，而在首次写入时由存储侧裁定，将纠偏责任从业务层下沉至存储层，业务无需感知任何路由逻辑。

错区写入保护：