模拟朋友圈数据存储原理
【引言】
首先说一下问题的出处：公司某个项目组有一个需求，获取所有关注人的文章列表。乍一看，感觉貌似挺简单，那就获取吧，通过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是多对多的结构。此思路是我之前一个同事，孙雪超借鉴网上谈论朋友圈存储数据的文章想的。在这里特别感谢。
