小红书如何应对万亿级社交网络关系挑战？图存储系统 REDtao 来了！( 四 ) _REDtao

● 将老的大 MySQL 集群按优先级拆分成了四个 REDtao 集群。这样，我们可以先将优先级最低的服务迁移到一个 REDtao 集群，充分灰度后再迁移高优先级的集群。
● 专门开发了一个 Tao Proxy SDK，支持对原来的 MySQL 集群和 REDtao 集群进行双写双读，数据校验比对。
迁移时，我们首先将低优先级的数据从 MySQL 通过 DTS 服务迁移到了一个 REDtao 集群，并升级好业务方的 SDK。DTS 服务一直对增量数据进行同步。业务方 SDK 会订阅配置中心的配置变更，我们修改配置让 Tao Proxy SDK 同时读写 MySQL 集群和 REDtao 集群，并关闭 DTS 服务。此时会使用 MySQL 集群的结果返回给用户。
在停止 DTS 服务时，有可能会有新的 MySQL 数据通过 DTS 同步过来，造成了 REDtao 集群新写的数据被同步过来的老数据覆盖。因此，在关闭 DTS 服务后，我们会通过工具读取开双写之后到关闭 DTS 服务这个时间段的 binlog 对数据进行校验和修复。
修复完成之后，Tao Proxy SDK 的双读会展示两边不一致的数据量，并过滤掉因为双写时延不一致导致数据不一致的请求。灰度一段时间后观察到 diff 的数目基本为 0，将 Tao Proxy SDK 的配置改为只读写新的 REDtao 集群。
最终，我们在 22 年初完成小红书所有核心社交图谱万亿边级别数据的迁移和正确性校验，并做到了整个迁移服务无感知，迁移过程没有发生一起故障。
5.上线的结果和收益我们的社交图谱数据访问中，90% 以上的请求都是读请求，并且社交图谱的数据有非常强的时间局部性（即最近更新的数据最容易被访问）。REDtao 上线后，获得 90% 以上的 cache 命中率，对MySQL 的 QPS 降低了 70%+，大大降低了 MySQL 的 CPU 使用率。在缩容 MySQL 的副本数目后，整体成本降低了21.3% 。

文章插图
图片
业务的访问方式都全部收敛到 REDtao 提供的 API 接口上，在迁移过程中，我们还治理了一些老的不合理访问 MySQL 数据库的方式，以及自定义某些字段赋予特殊含义的不合理做法，通过 REDtao 规范了数据访问。
对比 2022 年初和 2023 年初，随着 DAU 的增长，社交图谱的请求增长了 250% 以上，如果是之前 MySQL 的老架构，扩容资源基本上和请求增长速度成正比，至少需要扩容 1 倍的资源成本（数万核）。而得益于 REDtao 系统的存在，因其 90% 的缓存命中率，实际上整体成本只增加了 14.7%（数千核）就能扛下 2.5 倍的请求增长。在成本和稳定性上有了较大的提升。

文章插图
6.总结和未来一些展望在较短的时间，我们自研了图存储系统 REDtao，解决了社交图谱关系数据快速增长的问题。
REDtao 借鉴了 FaceBook Tao 的论文，并对整体架构、跨云多活做了较多的改进，全新实现了一个高性能的分布式图缓存，更加贴合我们自身的业务特点和提供了更好的弹性。同时，利用 k8s 能力进一步实现了云原生化。
随着 DAU 的持续增长，万亿的数据规模也在继续增长，我们也面临着更多的技术挑战。目前公司内部的 OLTP 图场景主要分为三块：
●社交图谱数据服务：通过自研图存储系统 REDtao 满足了社交场景超大规模数据的更新与关联读取问题。目前已经存储了万亿规模的关系。
●风控场景：通过自研图数据库 REDgraph，满足多跳的实时在线查询。目前存储了千亿点和边的关系，满足 2 跳以及 2 跳以上的查询。（关于 REDgraph 的介绍我们将放在下一篇文章中分享）
●社交推荐：这块主要是两跳的查询。每天通过 Hive 批量地导入全量的数据，通过 DTS 服务近实时的写入更新数据。因为是在线场景，对时延的要求非常高，当前的 REDgraph 还无法满足这么高的要求，因此业务方主要是用 REDkv 来存储。
针对以上场景，为了快速满足业务需求，我们使用了三套不同的自研存储系统：REDtao 、REDgraph 和 REDkv。显然相对于 3 套存储系统，用一个统一的架构和系统去解决这几个图相关的场景是更加合适的。未来，我们会将 REDgraph 和 REDtao 融合成一个统一的数据库产品，打造业内顶尖的图技术，对公司内部更多的场景进行赋能。最后，欢迎对技术有着极致追求，志同道合的同学一起加入我们。
7.作者简介空洞：小红书基础架构存储组，负责图存储系统 REDtao 和分布式缓存的研发
刘备：小红书基础架构存储组负责人，负责REDkv / REDtao / REDtable / REDgraph 的整体架构和技术演进