您现在的位置是: 首页 >  技术分享 > 

模拟朋友圈数据存储原理
叶子 2017-03-01 10:30:37

【引言】

首先说一下问题的出处:公司某个项目组有一个需求,获取所有关注人的文章列表。乍一看,感觉貌似挺简单,那就获取吧,通过uid获取所有关注人的uid数据集合,然后通过对应的uid,获取文章id不就可以了吗。可是细想,不对。一个人可以关注N个人,N可能是100,也可能是1000,关注的人发得可不是一篇文章,人家心情好,可能发个10篇,20篇,那这样算下来如果关注1万个,一个人平均发文一千篇,那两级就是千万数据。

【最初思路一】

一遇到这种千万级的数据,就相当于nosql的作用了。我们最初思路一致认为redis处理最是合适,因为mysql服务器承担千万级的数据,容易崩溃。所以得出以下方法:

这样的弊端就是redis数据存储会越来越多,如果redis服务器哪天一抽风,所有数据就丢了,并且关注上限没有设定,发文也没有上限,数据量会随着时间推移进行增长。

【思路二】

上面的方法类似于订阅数据存储,后来经过讨论想到redis队列推送数据,同事说php-request消息队列是不是可以实现这个功能,可是数据量太大的话,推送显然不合适。然后我们就想到朋友圈类似这个功能,只要互加好友,就可以查看该好友的朋友圈信息,一个人有多个好友,一个好友会每天发朋友圈,所以我们每天刷新朋友圈的时候,为什么觉得人家的数据怎么超快呢。然后就细思考朋友圈数据存储的原理。

【思路三】

就是新建一个数据表,设定关注uid,被关注uid,文章id,还有其他信息存储。关注uid,被关注uid,文章id建立唯一索引。关注uid,搜索时建立查询索引。文章id如果需要,也可以建立查询索引。每次定时同步这个数据表,单表查询,外层再和redis结合,我想速度一定不会太慢,因为所有字段都是int类型,也不会耗费数据内存。后期这个表会越来越大,反正是一个表,怎么都好处理,数据量如果特别大,可以分表,减少查询数据列,提高查询数据。如图所示,表结构如下

具体逻辑比较清晰,关注UID和文章ID是多对多的结构。此思路是我之前一个同事,孙雪超借鉴网上谈论朋友圈存储数据的文章想的。在这里特别感谢。

yezismile wechat
欢迎关注博主公众号
分享:

上一篇: 上传图片旋转问题

下一篇: 雪一直下

Copyright © 2018
www.yezismile.com All rights reserved. 京ICP备15029736号-1