拯救爆表的MySQL：小红书万亿级存储系统自研与迁移之路 _MySQL

作者介绍
空洞，小红书基础架构存储组，负责图存储系统 REDtao 和分布式缓存的研发。
刘备，小红书基础架构存储组负责人，负责REDkv / REDtao / REDtable / REDgraph 的整体架构和技术演进。
小红书是一个社区属性为主的产品，它涵盖了各个领域的生活社区，并存储海量的社交网络关系。为解决社交场景下超大规模数据的更新与关联读取问题，并减少数据库压力和成本，我们自研了面向超大规模社交网络的图存储系统 REDtao，大大提高了系统稳定性。该系统借鉴了 Facebook 的图存储系统设计，将缓存和底层数据库封装起来，并对外提供统一的图查询 API，实现了访问收敛，同时在缓存中实现了高效的边聚合。
一、背景
小红书是以年轻人为主的生活记录、分享平台，用户可以通过短视频、图文等形式记录生活点滴，分享生活方式。在小红书的社交领域里，我们有用户、笔记、商品等实体，这些实体之间有各种各样的关系。例如，用户与笔记之间可能存在“拥有”（发布）、“点赞”、“收藏”等三种关系，同时还存在对应的反向关系“被点赞”，“被收藏”等。

文章插图
小红书的社交图谱数据已经达到了万亿条边的规模，且增长速度非常快。当用户登陆小红书时，每个用户都会看到关注的好友、粉丝、点赞、收藏以及其他为其量身定做的内容。

文章插图
这些信息高度个性化，需要实时从这些海量社交关系数据中读取用户相关信息。这是一个读为主的过程，读取压力非常大。
过去，我们将这些社交图谱数据都存储在运维成熟的 MySQL 数据库中。然而，即使我们只有百万请求每秒的规模，MySQL 的 CPU 使用率仍然到达了 55%。随着用户和 DAU 爆发式的增长，需要不断扩容 MySQL 数据库，这带来了巨大的成本和稳定性压力。为了解决这些问题且考虑到没有合适的开源方案，2021 年初我们开启了从 0 到 1 自研 REDtao 的历程。
二、REDtao的图模型和API
我们充分调研了业内其他厂商的实现，发现有着强社交属性的公司基本上都有一个自研的图存储系统：

文章插图
Facebook 实现了一个叫做 “TAO” 专门的分布式社交图谱数据库，并将其作为最核心的存储系统；Pinterest 和 Facebook 类似，也实现了类似的图存储系统；字节跳动自研了 ByteGraph 并将其用于存储核心的社交图谱数据；Linkedln 在 KV 之上构建了社交图谱服务。
考虑到当时我们的社交图谱数据已经存放在 MySQL 数据库上且规模巨大，而社交图谱数据服务是非常重要的服务，对稳定性的要求非常高。回溯 Facebook 当年遇到的问题和我们类似，数据存储在 Memcache 和 MySQL 中。因此，参考 Facebook 的 Tao 图存储系统更贴合我们的实际情况和已有的技术架构，风险更小。
社交图谱的访问主要是边的关系查询。我们的图模型将关系表示为一个 <key, value> 对，其中 key 是 ( FromId, AssocType, ToId ) 的三元组，value 是属性的 JSON 格式。比如“用户 A ”关注“用户 B ” ，映射到 REDtao 的数据存储结构为：
<FromId:用户A的ID, AssocType：关注， ToId：用户B的ID> -> Value （属性的json字段）
我们对业务方的需求进行分析，封装了 25 个图语义的 API 给业务方使用，满足了其增删改查的需求，并收敛业务方的使用方式。相比于 Facebook 的 Tao，我们还补充了社交图谱所需要的图语义，为反作弊场景提供了额外的过滤参数。同时，在缓存层面，我们支持对不同的字段在缓存中配置局部二级索引。下面给一些典型的使用场景：
场景一：
获取关注了 A 的所有正常用户（并且剔除作弊用户）
getAssocs(“被关注类型”, 用户A的ID, 分页偏移量, 最大返回值, 只返回正常用户，是否按照时间从新到旧)
场景二：
获取 A 的粉丝个数（并且剔除作弊用户）
getAssocCount(“被关注类型”, 用户A的ID, 只返回正常用户)
三、REDtao的架构设计
REDtao 的架构设计考虑了下面这几个关键的要素：