好友关系

粉丝与关注，社交好友，都是典型的“多对多关系”的业务，这类业务的核心服务是好友中心，当关系链达到百亿之后，好友中心架构设计要考虑哪些因素，是本文将要分享的内容。

什么是“多对多”关系？

所谓的“多对多”，来自数据库设计中的“实体-关系”ER模型，用来描述实体之间的关联关系，一个学生可以选修多个课程，一个课程可以被多个学生选修，这里学生与课程时间的关系，就是多对多关系。

什么是好友关系？

好友关系主要分为两类：

  1. 弱好友关系；
  2. 强好友关系；

两类都有典型的互联网产品应用。

什么是弱好友关系？

弱好友关系的建立，不需要双方彼此同意：用户A关注用户B，不需要用户B同意，此时用户A与用户B为弱好友关系，对A而言，他多“关注”了一个人，对B而言，他多了一个“粉丝”。

微博粉丝是一个典型的弱好友关系应用。

什么是强好友关系？

强好友关系的建立，需要好友关系双方彼此同意：用户A请求添加用户B为好友，用户B同意，此时用户A与用户B则互为强好友关系，即A是B的好友，B也是A的好友。

QQ好友是一个典型的强好友关系应用。

什么是好友中心？

好友中心是一个典型的多对多业务，一个用户可以添加多个好友，也可以被多个好友添加。

其典型架构如上：

  1. friend-service：好友中心服务，对调用者提供友好的RPC接口；
  2. db：对好友数据进行存储；

服务的接口，不外乎：关注，取关，增加好友，删除好友，同意好友申请，不同意好友申请。其核心，在于元数据的设计。

元数据设计

弱好友关系

弱好友关系，如何设计元数据？

通过弱好友关系业务分析，很容易了解到，其核心元数据为：

  1. guanzhu(uid, guanzhu_uid);
  2. fensi(uid, fensi_uid);

其中：

  1. guanzhu表，用户记录uid所有关注用户guanzhu_uid；
  2. fensi表，用来记录uid所有粉丝用户fensi_uid；

需要强调的是，一条弱关系的产生，会产生两条记录，一条关注记录，一条粉丝记录。

例如：用户A(uid=1)关注了用户B(uid=2)，A多关注了一个用户，B多了一个粉丝，于是：

  1. guanzhu表要插入{1, 2}这一条记录，1关注了2；
  2. fensi表要插入{2, 1}这一条记录，2粉了1；

如何查询一个用户关注了谁呢？

在guanzhu的uid上建立索引：

1

select * from guanzhu where uid=1;

即可得到结果，1关注了2。

如何查询一个用户粉了谁呢？

在fensi的uid上建立索引：

1

select * from fensi where uid=2;

即可得到结果，2粉了1。

强好友关系

强好友关系，如何设计元数据？

通过强好友关系业务分析，很容易了解到，其核心元数据为：

  1. friend(uid1, uid2);

其中：

  1. uid1，强好友关系中一方的uid；
  2. uid2，强好友关系中另一方的uid；

uid=1的用户添加了uid=2的用户，双方都同意加彼此为好友，强好友关系，在数据库中应该插入记录{1, 2}还是记录{2,1}呢？ 都可以，为了避免歧义，可以人为约定，插入记录时uid1的值必须小于uid2。

例如：有uid=1,2,3三个用户，他们互为强好友关系，那边数据库中可能是这样的三条记录：

1
2
3

{1, 2}
{2, 3}
{1, 3}

如何查询一个用户的好友呢？

假设要查询uid=2的所有好友，只需在uid1和uid2上建立索引，然后：

1
2
3

select *from friend where uid1=2
union
select* from friend where uid2=2

即可得到结果。

使用一个表记录所有关系链，如果数据量大了，数据库进行分库以后，不久无法同时满足uid1和uid2上的查询了么，此时要怎么办呢？ 此时，可以使用类似于弱关系实现的方案，用数据冗余的方式，即使分库后，依然能够满足两种查询需求。

即，强好友关系也可以使用关注表和粉丝表来实现：

  1. guanzhu(uid, guanzhu_uid);
  2. fensi(uid, fensi_uid);

例如：用户A(uid=1)和用户B(uid=2)为强好友关系，即相互关注： 用户A(uid=1)关注了用户B(uid=2)，A多关注了一个用户，B多了一个粉丝，于是：

  1. guanzhu表要插入{1, 2}这一条记录；
  2. fensi表要插入{2, 1}这一条记录；

同时，用户B(uid=2)也关注了用户A(uid=1)，B多关注了一个用户，A多了一个粉丝，于是：

  1. guanzhu表要插入{2, 1}这一条记录；
  2. fensi表要插入{1, 2}这一条记录；

强调一下：数据冗余，是多对多关系，满足不同维度的查询需求，在数据量大时，数据水平切分的常用实践。

对于强好友关系的两类实现：

第一类：friend(uid1, uid2)表；

第二类：数据冗余guanzhu表与fensi表（后文称正表T1与反表T2）；

在数据量小时，看似无差异，但数据量大时，只有后者，才能满足两类查询需求：

  1. friend表，数据量大时，如果使用uid1来分库，那么uid2上的查询就需要遍历多库；
  2. 正表T1与反表T2通过数据冗余来实现好友关系，{1, 2}{2,1}分别存在于两表中，故两个表都使用uid来分库，均只需要进行一次查询，就能找到对应的关注与粉丝，而不需要多个库扫描；

问题转化为，T1和T2正反表，如何进行数据冗余呢？

数据冗余

数据冗余，常见有三种方法。

服务同步冗余

顾名思义，由好友中心服务同步写冗余数据，如上图1-4流程：

  1. 业务方调用服务，新增数据；
  2. 服务先插入T1数据；
  3. 服务再插入T2数据；
  4. 服务返回业务方新增数据成功；

这个方法，有什么优点呢？

  1. 不复杂，服务层由单次写，变两次写；
  2. 数据一致性相对较高（因为双写成功才返回）；

这个方法，有什么不足呢？

  1. 请求的处理时间增加（要插入次，时间加倍）；
  2. 数据仍可能不一致，例如第二步写入T1完成后服务重启，则数据不会写入T2；

如果系统对处理时间比较敏感，引出常用的第二种方案。

服务异步冗余

数据的双写并不再由好友中心服务来完成，服务层异步发出一个消息，通过消息总线发送给一个专门的数据复制服务来写入冗余数据，如上图1-6流程：

  1. 业务方调用服务，新增数据；
  2. 服务先插入T1数据；
  3. 服务向消息总线发送一个异步消息（发出即可，不用等返回，通常很快就能完成）；
  4. 服务返回业务方新增数据成功；
  5. 消息总线将消息投递给数据同步中心；
  6. 数据同步中心插入T2数据；

这个方法，有什么优点呢？

  1. 请求处理时间短（只插入1次）；

这个方法，有什么不足呢？

  1. 系统的复杂性增加了，多引入了一个组件（消息总线）和一个服务（专用的数据复制服务）；
  2. 因为返回业务线数据插入成功时，数据还不一定插入到T2中，因此数据有一个不一致时间窗口（这个窗口很短，最终是一致的）；
  3. 在消息总线丢失消息时，冗余表数据会不一致；

如果想解除“数据冗余”对系统的耦合，引出常用的第三种方案。

线下异步冗余

数据的双写不再由好友中心服务来完成，而是由线下的一个服务或者任务来完成，如上图1-6流程：

  1. 业务方调用服务，新增数据；
  2. 服务先插入T1数据；
  3. 服务返回业务方新增数据成功；
  4. 数据会被写入到数据库的log中；
  5. 线下服务或者任务读取数据库的log；
  6. 线下服务或者任务插入T2数据；

这个方法，有什么优点呢？

  1. 数据双写与业务完全解耦；
  2. 请求处理时间短（只插入1次）；

这个方法，有什么不足呢？

  1. 返回业务线数据插入成功时，数据还不一定插入到T2中，因此数据有一个不一致时间窗口（这个窗口很短，最终是一致的）；
  2. 数据的一致性依赖于线下服务或者任务的可靠性；

数据一致性

数据冗余固然能够解决多对多关系的数据库水平切分问题，但又带来了新的问题，如何保证正表T1与反表T2的数据一致性呢？

可以看到，不管哪种方案，因为两步操作不能保证原子性，总有出现数据不一致的可能，高吞吐分布式事务是业内尚未解决的难题，此时的架构优化方向，并不是完全保证数据的一致，而是尽早的发现不一致，并修复不一致。

需要强调的是，最终一致性，是高吞吐互联网业务一致性的常用实践。

更具体的，保证数据最终一致性的方案有三种。

线下扫面正反冗余表全部数据

如上图所示，线下启动一个离线的扫描工具，不停的比对正表T1和反表T2，如果发现数据不一致，就进行补偿修复。

这个方法，有什么优点呢？

  1. 比较简单，开发代价小；
  2. 线上服务无需修改，修复工具与线上服务解耦；

这个方法，有什么不足呢？

  1. 扫描效率低，会扫描大量的“已经能够保证一致”的数据；
  2. 由于扫描的数据量大，扫描一轮的时间比较长，即数据如果不一致，不一致的时间窗口比较长；

有没有只扫描“可能存在不一致可能性”的数据，而不是每次扫描全部数据，以提高效率的优化方法呢？

线下扫描增量数据

每次只扫描增量的日志数据，就能够极大提高效率，缩短数据不一致的时间窗口，如上图1-4流程所示：

  1. 写入正表T1；
  2. 第一步成功后，写入日志log1；
  3. 写入反表T2；
  4. 第二步成功后，写入日志log2；

当然，我们还是需要一个离线的扫描工具，不停的比对日志log1和日志log2，如果发现数据不一致，就进行补偿修复。

这个方法，有什么优点呢？

  1. 虽比方法一复杂，但仍然是比较简单的；
  2. 数据扫描效率高，只扫描增量数据；

这个方法，有什么不足呢？

  1. 线上服务略有修改（代价不高，多写了2条日志）；
  2. 虽然比方法一更实时，但时效性还是不高，不一致窗口取决于扫描的周期；

有没有实时检测一致性并进行修复的方法呢？

实时线上“消息对”检测

这次不是写日志了，而是向消息总线发送消息，如上图1-4流程所示：

  1. 写入正表T1；
  2. 第一步成功后，发送消息msg1；
  3. 写入反表T2；
  4. 第二步成功后，发送消息msg2；

这次不是需要一个周期扫描的离线工具了，而是一个实时订阅消息的服务不停的收消息。

假设正常情况下，msg1和msg2的接收时间应该在3s以内，如果检测服务在收到msg1后没有收到msg2，就尝试检测数据的一致性，不一致时进行补偿修复。

这个方法，有什么优点呢？

  1. 效率高；
  2. 实时性高；

这个方法，有什么不足呢？

  1. 方案比较复杂，上线引入了消息总线这个组件；
  2. 线下多了一个订阅总线的检测服务；

缓存优化

2009 年微博刚刚上线的时候，微博关系服务使用的是最传统的 Memcache+Mysql 的方案。Mysql 按 uid hash 进行了分库分表，表结构非常简单：

tid fromuid touid addTime 自增 id 关系主体 关系客体 加关注时间业务方存在两种查询：

  • 查询用户的关注列表：select touid from table where fromuid=？order by addTime desc
  • 查询用户的粉丝列表：select fromuid from table where touid=？order by addTime desc

两种查询的业务需求与分库分表的架构设计存在矛盾，最终导致了冗余存储：以 fromuid 为 hash key 存一份，以 touid 为 hash key 再存一份。memcache key 为 fromuid.suffix ，使用不同的 suffix 来区分是关注列表还是粉丝列表，

微博关系存储 Redis 结构

需求实现：

  • 查询用户关注列表：hgetAll uid.following ，then sort
  • 查询用户粉丝列表：hgetAll uid.follower，then sort
  • 查询用户双向关注列表：hgetAll uid.bifollow，then sort
  • 判断两个用户关系：hget uidA.following uidB && hget uidB.following uidA

2011 年微博进行平台化改造过程中，业务提出了新的需求：在核心接口中增加了“判断两个用户的关系”的步骤，并增加了“双向关注”的概念。因此两个用户的关系存在四种状态：关注，粉丝，双向关注和无任何关系。为了高效的实现这个需求，平台引入了 Redis 来存储关系,批量判断元素在集合中是否存在，redis hash 依然是最佳的数据结构，。平台使用 Redis 的 hash 来存储关系：key 依然是 uid.suffix，关注列表，粉丝列表及双向关注列表各自有一个不同的 suffix，value 是一个 hash，field 是 touid，value 是 addTime。order by addTime 的功能则由ˇ Service 内部 sort 实现。

需求实现：

  • 查询用户关注列表：hgetAll uid.following ，then sort
  • 查询用户粉丝列表：hgetAll uid.follower，then sort
  • 查询用户双向关注列表：hgetAll uid.bifollow，then sort
  • 判断两个用户关系：hget uidA.following uidB && hget uidB.following uidA

对于微博关系服务，最大的挑战还是容量和访问量的快速增长，这给我们的 Redis 方案带来了不少的麻烦：

第一个碰到的麻烦是 Redis 的 hgetAll 在 hash size 较大的场景下慢请求比例较高。我们调整了 hash-max-zip-size，节约了 1/3 的内存，但对业务整体性能的提升有限。最后，我们不得不在 Redis 前面又挡了一层 memcache，用来抗 hgetAll 读的问题。

第二个麻烦是新上的需求：“我关注的人里谁关注了他”，由于用户的粉丝列表可能不全，在这种情况下就不能用关注列表与粉丝列表求交集的方式来计算结果，只能降级到需求的字面描述步骤：取我的关注人列表，然后逐个判断这些人里谁关注了他。client 端分批并行发起请求，还好 Redis 的单个关系判断非常快。

为了从根本上解决容量的问题，我们开始寻找一种本质的解决方案。最初选择引入 Redis 作为一个 storage，是因为用户关系判断功能请求的数据热点不是很集中，长尾效果明显，cache miss 可能会影响核心接口性能，而保证一个可接受的 cache 命中率，耗费的内存与 storage 差别不大。但微博经过了 3 年的演化，最初作为选择依据的那些假设前提，数据指标都已经发生了变化：随着用户基数的增大，冷用户的绝对数量也在增大；Redis 作为存储，为了数据可靠性必须开启 rdb 和 aof，而这会导致业务只能使用一半的机器内存；Redis hash 存储效率太低，特别是与内部极度优化过的 RedisCounter 对比。种种因素加在一起，最终确定下来的方向就是：将 Redis 在这里的 storage 角色降低为 cache 角色。

前面提到的微博关系服务当前的业务场景，可以归纳为两类：一类是取列表，一类是判断元素在集合中是否存在，而且是批量的。即使是 Redis 作为 storage 的时代，取列表都要依赖前面的 memcache 帮忙抗，那么作为 cache 方案，取列表就全部由 memcache 代劳了。批量判断元素在集合中是否存在，redis hash 依然是最佳的数据结构，但存在两个问题：cache miss 的时候，从 db 中获取数据后，set cache 性能太差：对于那些关注了 3000 人的微博会员们，set cache 偶尔耗时可达到 10ms 左右，这对于单线程的 Redis 来说是致命的，意味着这 10ms 内，这个端口无法提供任何其它的服务。另一个问题是 Redis hash 的内存使用效率太低，对于目标的 cache 命中率来说，需要的 cache 容量还是太大。于是，我们又祭出 “Redis 定制化”的法宝：将 redis hash 替换成一个“固定长度开放 hash 寻址数组”，在 Redis 看来就是一个 byte 数组，set cache 只需要一次 redis set。通过精心选择的 hash 算法及数组填充率，能做到批量判断元素是否存在的性能与原生的 redis hash 相当。

简单KV

简单总结一下，通过简单KV数据类型的存储，我们实际上以MC为主的，层内HASH节点不漂移，Miss穿透到下一层去读取。通过多组L1读取性能提升，能够抗住峰值、突发流量，而且成本会大大降低。对读写策略，采取多写，读的话采用逐层穿透，如果Miss的话就进行回写。对存在里面的数据，我们最初采用Json/xml，2012年之后就直接采用Protocol Buffer格式，对一些比较大的用QuickL进行压缩。

集合类数据

比如我关注了2000人，新增一个人，就涉及到部分修改。有一种方式是把2000个ID全部拿下来进行修改，但这种对带宽、机器压力会很大。还有一些分页获取，我存了2000个，只需要取其中的第几页，比如第二页，也就是第十到第二十个，能不能不要全量把所有数据取回去。还有一些资源的联动计算，会计算到我关注的某些人里面ABC也关注了用户D。这种涉及到部分数据的修改、获取，包括计算，对MC来说实际上是不太擅长的。

各种关注关系都存在Redis里面取，通过Hash分布、储存，一组多存的方式来进行读写分离。现在Redis的内存大概有30个T，每天都有2-3万亿的请求。

在使用Redis的过程中，实际上还是遇到其他一些问题。比如从关注关系，我关注了2000个UID，有一种方式是全量存储，但微博有大量的用户，有些用户登陆得比较少，有些用户特别活跃，这样全部放在内存里成本开销是比较大的。所以我们就把Redis使用改成Cache，比如只存活跃的用户，如果你最近一段时间没有活跃，会把你从Redis里踢掉，再次有访问的时候再把你加进来。

这时存在一个问题，因为Redis工作机制是单线程模式，如果它加某一个UV，关注2000个用户，可能扩展到两万个UID，两万个UID塞回去基本上Redis就卡住了，没办法提供其他服务。所以我们扩展一种新的数据结构，两万个UID直接开了端，写的时候直接依次把它写到Redis里面去，读写的整个效率就会非常高。它的实现是一个long型的开放数组，通过Double Hash进行寻址。

参考

百亿关系链，架构如何设计？

微博关系服务与 Redis 的故事