加入收藏 | 设为首页 | 会员中心 | 我要投稿 PHP编程网 - 黄冈站长网 (http://www.0713zz.com/)- 数据应用、建站、人体识别、智能机器人、语音技术!
当前位置: 首页 > 运营中心 > 建站资源 > 优化 > 正文

粉丝关系链,10亿数据,如何设计?

发布时间:2019-08-20 22:54:42 所属栏目:优化 来源:58沈剑
导读:副标题#e# 继续答星球水友提问,大数据量,高并发量,好友关系链、粉丝关系链要如何设计? 什么是关系链业务? 关系链主要分为两类,弱好友关系与强好友关系,两类都有典型的互联网产品应用。 弱好友关系的建立,不需要双方彼此同意: 用户A关注用户B,不需要
副标题[/!--empirenews.page--]

粉丝关系链,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好友关系链,是一个典型的强好友关系应用。

粉丝关系链,10亿数据,如何设计?

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

  • 一个用户可以添加多个好友
  • 也可以被多个好友添加

其典型架构为:

粉丝关系链,10亿数据,如何设计?

  • friend-service:好友中心服务,对调用者提供友好的RPC接口
  • db:对好友数据进行存储

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

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

  1. guanzhu(uid, guanzhu_uid); 
  2. 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上建立索引:

  1. select * from guanzhu where uid=1; 

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

  1. select * from fensi where uid=2; 

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

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

方案一

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

  1. friend(uid1, uid2); 

其中:

  • uid1,强好友关系中一方的uid
  • uid2,强好友关系中另一方的uid

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

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

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

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

  1. select * from friend where uid1=2 
  2. union 
  3. select * from friend where uid2=2 

即可得到结果。

方案二

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

  1. guanzhu(uid, guanzhu_uid); 
  2. 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上的查询就需要遍历多库
  • 正表T1与反表T2通过数据冗余来实现好友关系,{1,2}{2,1}分别存在于两表中,故两个表都使用uid来分库,均只需要进行一次查询,就能找到对应的关注与粉丝,而不需要多个库扫描

画外音:假如有10亿关系链,必须水平切分。

数据冗余,是多对多关系,在数据量大时,数据水平切分的常用实践。

如何进行数据冗余?

接下来的问题转化为,好友中心服务如何来进行数据冗余,常见有三种方法。

(编辑:PHP编程网 - 黄冈站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读