从主站业务角度来看，关系链指的是用户A与用户B的关注关系。以关注属性细分，以关注（订阅）为主，还涉及拉黑、悄悄关注、互相关注、特别关注等多种属性或状态。目前主站关系链量级较大，且还以较快速度持续增长。作为一个平台型的业务，关系链服务对外提供一对多关系点查、全量关系列表、关系计数等基础查询，综合查询峰值QPS近百万，被动态、评论等核心业务依赖。

在持续增长的数据量和查询请求的趋势下，保证数据的实时准确、保持服务高可用是关系链架构演进的核心目标。

关系链在空间页的业务场景

关系链状态机

关注的写事件对应的就是单纯的状态属性流转，所以使用关系型数据库是非常适合的。在主站社区发展的早期，关系链量级较少，直接使用mysql有着天然的优势：开发维护简单、逻辑清晰，只需要直接维护一张关系表、一张计数表即可满足线上使用。考虑到社区的发展速度，前人的设计分别采用了分500表（关系表）和50表（计数表）来分散压力。

关系表的结构示例

计数表的结构示例

在这种存储结构下，以一次mid新增关注fid请求为例，mysql需要以事务执行下述操作：

这种架构一直保持到2021年，随着社区的不断发展壮大，架构的缺点也日益显现：一方面，即使做了分表，关系链数据整体规模仍然超出了建议的整体存储容量（目前已经TB级）；另一方面，繁重的事务导致mysql无法支撑很高的写流量，在原始的同步写架构下，表现就是关注失败率变高；如果只是单纯地升级到异步写架构，表现就是消息积压，当消息积压持续时间超过临时缓存有效期时，会引起客诉，治标不治本。

使用mysql作为核心存储的“同步”写关系流程图

*关于B站自研分布式KV存储的介绍可以参阅：B站分布式KV存储实践

最终决定使用的升级方案是：数据存储从mysql迁移到KV存储，逻辑方面把”同步写mysql“改为”异步写KV“。未选择”同步写KV“的原因，一方面是一条关系对应着多条KV记录，而KV不支持事务；另一方面是异步的架构可以扛住可能存在的瞬时大量关注请求。为了兼容订阅了mysql binlog的业务，在“异步写KV”之后还会”异步写mysql“。

在新架构下，对于每一次用户关注请求，投递databus即视为请求成功，mysql binlog只提供给一些对实时性不太敏感的业务方（如数据平台），所以对于异步写mysql事件的偶尔的轻微积压我们并不需要关心，而对实时性要求比较高的业务方，我们在处理完异步写KV事件后，会投递了databus供这些业务订阅。

使用KV作为核心存储、mysql冗余存储的异步写关系流程图

KV存储最大的优势在于，底层能提供计数（count）方法以替代冗余的mysql计数表，这样的好处是，我们只需要维护一张单纯保存关系的KV表即可。我们设计的存储结构是：

attr和attribute容易混淆，两者的区别如下：

midA的五种关系拉链如图：

midA的五种关系拉链

综上所述，升级到KV存储后，读操作相对来说并没有很复杂：

稍微复杂一点的逻辑在于关系的写入：

还是以mid新增关注fid为例，对于每一条关注事件：

线上查询请求中，有一定比例是查询全量关注列表、全量黑名单。上一节中提到，为了不冗余存储一份关系链计数，KV的存储设计得比较特殊，一个用户的正向关注关系分布在3个不同的attr（即3个不同的关系拉链）里。如果想从KV存储拉取一个用户的全量关系列表，那么同时需要分别对3种正向关系拉链都做循环scan（因为每次scan有数量上限），但由于scan方法性能相对较差，所以需要在KV存储的上层加一套缓存，通过降低回源比例严格控制scan QPS。

鉴于memcached对大key有比较好的性能，前人在KV存储的上层加了一个memcached缓存，用于存储用户的全量关系列表，具体业务流程如下：

全量关系列表的查询业务流程

从高峰时期的缓存回源数据来看，memcached为KV存储抵挡住了97%-99%的请求，只有不到6K的QPS会miss缓存，效果比较明显。

memcached的QPS和缓存回源率

除了关注列表的请求外，很大一部分请求是一对多的点查关系（查询用户和其他一个或多个用户的关系），如果每次都从memcached拉全量关系列表然后内存中取交集，网络的开销会非常大，因此对这种查询场景，也需要设计一套适用于点查的缓存。

活跃用户的关注数一般都在几十到几百的区间，用于点查的缓存不需要严格有序，但要支持指定hashkey的查询，redis hash和其提供的hget、hmget、hset、hmset方法都是非常适合这一场景的。因此查询层缓存设计如下：key为mid，hashkey为mid有关系的每一个用户id，value为他们的关系数据，和前面midA在KV存储的数据对应如下：

redis hash缓存中关注关系的存储结构

由于hash里保存的是midA的全部正向关注关系，当缓存miss需要回源时，要获取全量关注关系，可以和前面的memcached配合使用，业务流程如下：

redis hash架构下的一对多关系的查询业务流程

基于这套缓存，点查一对一、一对多关注关系的接口耗时平均基本维持在1ms，且hash的命中率能达到70%-75%，因此目前能比较轻松地支持近百万的QPS，并随着redis集群的横向扩展，可以支持更多的业务请求。

redis hash缓存的QPS和缓存回源率

到2022年下半年，一方面产品提出“我关注的xx也关注了ta”需求，此类二度关系的查询在hash架构下是非常吃力的：

切换架构前后的KV存储 scan操作RPC错误数情况

另一方面，产品提出放开关注上限的想法，我们考虑在此类需求上线后，高关注量的用户会越来越多，甚至部分用户会在功能上线后迅速把关注拉满，hash结构的缺陷和风险也会日渐显现。其风险点在于：当同一个redis实例有多个高关注量的用户miss缓存、触发回源、hmset回填缓存时，持续性的高写入QPS可能会让redis cpu利用率打满（比如每秒2个用户需要回填缓存，且他们的关系列表5000个，实际写入QPS是1万）。

在上述大背景下，经团队内部讨论，我们先引入了redis kv结构缓存，希望能一步到位、通过简单缓存直接替换hash，key为用户A和用户B的用户id，value为用户A与用户B的关系，示例如下：

redis kv缓存中关注关系的存储结构

在这个缓存结构下，回源KV存储就只需要点查了，因为KV存储点查操作（get、batch_get）的性能远远好于scan操作，同时为了减少对memcached的依赖，因此当redis kv缓存miss时，我们直接回源KV存储执行点查（get、batch_get），然后回填缓存，流程图如下：

redis kv架构下的一对多关系的查询业务流程

我们灰度了2%的用户，发现kv结构缓存的命中率逐渐收敛在60%，而且缓存内存的使用率和key的数量却远远超出预期。这意味着有40%的请求会miss缓存并回源到kv，在百万QPS的压力下，这明显是不能接受的。分析miss缓存的请求后，我们发现主要的业务来源是评论，其大部分请求的返回是“无关系”，即评论场景会查询大量陌生人的关注关系，那么空哨兵会特别多且大部分不会被二次访问到（对于一个用户而言，空哨兵的数量可以认为是他看的评论用户数），这也就能对单kv结构缓存的表现做出合理解释了。

对于大量空哨兵场景，在上面套一层布隆过滤器是一个公认比较合理的方案。我们决定对每一个用户维护一个布隆过滤器，先把存量的所有关系链都添加到布隆过滤器，并消费新的写关系事件并更新布隆过滤器，使其作为一个常驻缓存过滤器。命中布隆过滤器有三种可能：

命中布隆过滤器的才会走到下层的kv缓存，这样就解决了绝大部分空哨兵的问题了，具体流程图如下：

bloom filter + redis kv架构下的一对多关系的查询业务流程

目前关系链场景已经100%流量切到布隆的新架构下，布隆的命中率达到了80%+，hash的老架构正在灰度下线，这一技改不仅解决了关系链上限放开可能带来的问题、二度关系告警噪音问题、难以支持类似”多对一“的反向查询的问题，预计还能节省一部分缓存资源。

关系链的主要场景还是查询“用户A”与其他用户的关注关系。在同一时刻的请求里，当“用户A”的请求分散时，对Redis的压力会被均摊到集群的几十台实例上，此时系统所能承受的最大压力等于集群中每一个实例之和；而在极端情况下，如果“用户A”集中在少数几个用户上，那么压力都会集中在Redis的少数几台实例上，木桶短板效应就会非常明显。

回到去年的某次热点场景，流量都集中在环球网等热门up的动态详情页或稿件播放页上，而这些页面依赖实时查询up主与各个评论人的关注关系，当同一时刻大量用户加载评论时，即形成了该up主的查询热点。

当时关系链服务的架构对于热点的处理是相对滞后的，当发现热点up主（或已在事前知晓热点up主）时，会手动将其配置到热点名单中。对于热点用户，在请求Redis前会先查询本地Localcache（Localcache中存储的up主关系列表数据，隔十几秒更新一次）。虽然在这十几秒内可能会存在数据不一致的情况，但从实际业务角度看，引发热点请求的都是大up主，这些up主的关系列表较少发生变动，因此几乎不会对用户体验造成影响。

当天晚上热点请求发生时，随着用户的增长，Redis集群几个实例的CPU使用率逐步突破了70%，个别实例甚至突破了90%。

热点事件当时的Redis单实例CPU使用率告警

由于缺少热点探测能力，运维人员看到告警后，需要人工抓取当前的热点Key（在Redis实例CPU利用率已经几乎被打满的前提下，直连实例统计Key是一个高风险的操作），然后手动配置入库，随后Redis的压力就直线下降。为了避免可能存在的风险，后续又逐步把其他官媒号临时加到热点用户名单中，关系链服务算是有惊无险地度过此次流量高峰。

配置本地缓存前后单实例Redis QPS

事后，业务架构提供了热点检测工具，接入后能基于配置的阈值，自动地统计热点并临时性地使用本地缓存；在今年年初，热点检测工具和本地缓存sdk融合在了一起，热点自动检测与自动降级变得更加便捷，业务侧只需要简单修改本地缓存类型，即可低代码拥有防热点能力。经过英雄联盟S12和拜年祭的验证，关系链服务在上述活动期间各指标都比较平稳。

某天中午被自动感知到并缓存的热key数量监控

如何使用关系链能力赋能上层业务、如何让关系链基础服务更加靠谱，也是我们持续需要思考的问题，中期来看，还是有很多方向可以发力，这里仅列出几个方向：