
文章插图
四、老服务的平滑升级
但凡变革,皆属不易 。实现全新的 REDtao 只是完成了相对容易的那部分工作 。小红书的社交图谱数据服务已经在 MySQL 上运行多年 , 有很多不同的业务跑在上面,任何小的问题都会影响到小红书的在线用户 。因此 , 如何保证不停服的情况下让现有业务无感知地迁移到 REDtao 上成为一个非常大的挑战 。我们的迁移工作关键有两点:
- 将老的大 MySQL 集群按优先级拆分成了四个 REDtao 集群 。这样,我们可以先将优先级最低的服务迁移到一个 REDtao 集群,充分灰度后再迁移高优先级的集群 。
- 专门开发了一个 Tao Proxy SDK,支持对原来的 MySQL 集群和 REDtao 集群进行双写双读,数据校验比对 。
在停止 DTS 服务时 , 有可能会有新的 MySQL 数据通过 DTS 同步过来,造成了 REDtao 集群新写的数据被同步过来的老数据覆盖 。因此,在关闭 DTS 服务后,我们会通过工具读取开双写之后到关闭 DTS 服务这个时间段的 binlog 对数据进行校验和修复 。
修复完成之后,Tao Proxy SDK 的双读会展示两边不一致的数据量,并过滤掉因为双写时延不一致导致数据不一致的请求 。灰度一段时间后观察到 diff 的数目基本为 0,将 Tao Proxy SDK 的配置改为只读写新的 REDtao 集群 。
最终,我们在 22 年初完成小红书所有核心社交图谱万亿边级别数据的迁移和正确性校验,并做到了整个迁移服务无感知,迁移过程没有发生一起故障 。
五、上线的结果和收益
我们的社交图谱数据访问中,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 倍的请求增长 。在成本和稳定性上有了较大的提升 。

文章插图
六、总结和未来一些展望
在较短的时间,我们自研了图存储系统 REDtao ,解决了社交图谱关系数据快速增长的问题 。
REDtao 借鉴了 FaceBook Tao 的论文,并对整体架构、跨云多活做了较多的改进,全新实现了一个高性能的分布式图缓存,更加贴合我们自身的业务特点和提供了更好的弹性 。同时 , 利用 k8s 能力进一步实现了云原生化 。
随着 DAU 的持续增长,万亿的数据规模也在继续增长,我们也面临着更多的技术挑战 。目前公司内部的 OLTP 图场景主要分为三块:
- 社交图谱数据服务:通过自研图存储系统 REDtao 满足了社交场景超大规模数据的更新与关联读取问题 。目前已经存储了万亿规模的关系 。
- 风控场景:通过自研图数据库 REDgraph,满足多跳的实时在线查询 。目前存储了千亿点和边的关系,满足 2 跳以及 2 跳以上的查询 。(关于 REDgraph 的介绍我们将放在下一篇文章中分享)
- 社交推荐:这块主要是两跳的查询 。每天通过 Hive 批量地导入全量的数据,通过 DTS 服务近实时的写入更新数据 。因为是在线场景,对时延的要求非常高,当前的 REDgraph 还无法满足这么高的要求,因此业务方主要是用 REDkv 来存储 。
推荐阅读
- 常见的负载均衡算法及其适用场景
- 远程运维是什么?运维是什么?运维工程师是干嘛的?
- 反向代理服务器与CDN的协同作用
- 号称“可穿在身上”的ChatGPT,爆火的Ai Pin是创新还是又一次概念炒作?
- 轻松玩转Python,五个步骤打造惊艳的折线图
- C++初始化列表:探索多种初始化方式
- .NET Core中一些优秀的项目和框架
- 掌握Python的解包技巧:*和**的最全用法
- 从零到SQL注入防护大师,打造安全的Python应用程序
- 下雪的九寨沟有多绝?戳图欣赏!
