粉丝关系链，10亿数据，如何设计？

继续答星球水友提问，大数据量，高并发量，好友关系链、粉丝关系链要如何设计?

什么是关系链业务?

关系链主要分为两类，弱好友关系与强好友关系，两类都有典型的互联网产品应用。

弱好友关系的建立，不需要双方彼此同意：

用户A关注用户B，不需要用户B同意，此时用户A与用户B为弱好友关系，对A而言，暂且理解为“关注”;

用户B关注用户A，也不需要用户A同意，此时用户A与用户B也为弱好友关系，对A而言，暂且理解为“粉丝”;

idol与fans这类微博粉丝关系链，是一个典型的弱好友关系应用。

强好友关系的建立，需要好友关系双方彼此同意：

用户A请求添加用户B为好友，用户B同意，此时用户A与用户B则互为强好友关系，即A是B的好友，B也是A的好友;

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

好友中心是一个典型的多对多业务：

一个用户可以添加多个好友

也可以被多个好友添加

其典型架构为：

friend-service：好友中心服务，对调用者提供友好的RPC接口

db：对好友数据进行存储

弱好友关系，存储层应该如何实现?

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

guanzhu(uid, guanzhu_uid); 

fensi(uid, fensi_uid); 

其中：

guanzhu表，用户记录uid所有关注用户guanzhu_uid

fensi表，用来记录uid所有粉丝用户fensi_uid

需要强调的是，一条弱关系的产生，会产生两条记录，一条关注记录，一条粉丝记录。 例如：用户A(uid=1)关注了用户B(uid=2)，A多关注了一个用户，B多了一个粉丝，于是：

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

fensi表要插入{2, 1}这一条记录，2粉了1

如何查询一个用户关注了谁?回答：在guanzhu的uid上建立索引：

select * from guanzhu where uid=1; 

即可得到结果，1关注了2。 如何查询一个用户粉了谁?回答：在fensi的uid上建立索引：

select * from fensi where uid=2; 

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

强好友关系，存储层应该如何实现?

方案一

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

friend(uid1, uid2); 

其中：

uid1，强好友关系中一方的uid

uid2，强好友关系中另一方的uid

uid=1的用户添加了uid=2的用户，双方都同意加彼此为好友，这个强好友关系，在数据库中应该插入记录{1, 2}还是记录{2,1}呢?

回答：都可以。为了避免歧义，可以人为约定，插入记录时uid1的值必须小于uid2。 例如：有uid=1,2,3三个用户，他们互为强好友关系，那边数据库中可能是这样的三条记录

{1, 2} 

{2, 3} 

{1, 3} 

如何查询一个用户的好友呢?回答：假设要查询uid=2的所有好友，只需在uid1和uid2上建立索引，然后：

select * from friend where uid1=2 

union 

select * from friend where uid2=2 

即可得到结果。

方案二

强好友关系是弱好友关系的一个特例，A和B必须互为关注关系(也可以说，同时互为粉丝关系)，即也可以使用关注表和粉丝表来实现：

guanzhu(uid, guanzhu_uid); 

fensi(uid, fensi_uid); 

例如：用户A(uid=1)和用户B(uid=2)为强好友关系，即相互关注：

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

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

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

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

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

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

两种实现，各有什么优缺点?

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

friend(uid1, uid2)表

数据冗余guanzhu表与fensi表(后文称正表T1与反表T2)

在数据量小时，看似无差异，但数据量大时，数据冗余的优势就体现出来了：

friend表，数据量大时，如果使用uid1来分库，那么uid2上的查询就需要遍历多库