关于类朋友圈设计架构分析

前言

类朋友圈架构设计一直是一个很有意思的话题，虽然没有绝对正确的答案，不妨深入探究一下其中的奥秘。

设计思路

首先一款产品的设计方案，与公司目标、产品需求、项目预算、员工知识偏好与水平结构等等都有着紧密的联系。在离开这些细节来空谈如何设计，是很有问题的。因此我们分析问题，着重去考虑核心的点，忽略具体的实现细节。
我们以新浪微博、微信、twitter去入手分析。

新浪微博

feed是将用户主动订阅的若干消息源组合在一起形成内容聚合器，帮助用户持续地获取最新的订阅源内容。

为什么要先介绍feed流的概念？朋友圈也好微博也好，都是由用户主动订阅消息源并向用户提供消息内容。
新浪微博推拉并存，以拉为主。若粉丝数很大的用户，采用拉模式更为合理，当粉丝上线的时候，对微博进行数据拉取，这样可以有效避免数据过度冗余产生的浪费，尤其是大量僵尸粉存在的情况。若关注的用户很多，则需要在后端进行多次拉取再取并集，但是查询效率会降低，因此一般的微博都有关注上限。大多时候应该是推拉模式并存。
另外，新浪微博的「拉」做了很大程度的优化，每次拉取数据时参考上次拉取的时间，也就是说每次拉去的时候只是拉去新的，这样就减少了很多资源。每次拉出来的数据是暂存在缓存结构中。而且新浪微博将后台的数据按时间分区存储，这样冷热结合平衡资源配置。 当数据量庞大了之后自然需要考虑分库分表，因此分布式存储层面的设计也尤为重要。
新浪微博的feed流从曾经的timeline已经变成了rank，根据计算的权重推送给用户。最常见的是feed流中插入商业变现的广告内容，虽然会有部分用户抵触，但是feed流广告带给平台的收入是实实在在的。

微信

再比如微信使用的是「推」，因为每个人的好友一般不超过三位数，并不像新浪那样，所以推可以满足微信的需求。
每当有action的时候就向所有的好友推送，每个用户的接受的feed表都是单独的，是现成的，如果有好友动作的话单独添加此用户的feed表 。因此，每次刷新朋友圈不会一次次都去遍历所有朋友圈内容，而是去feed表抓取数据。所以微信目前也不支持编辑操作，只有添加/删除。

twitter

twitter用了哪些数据库？

• Hadoop 作社交图分析、推荐喜好、API分析、广告投放以及MySQL、Manhattan备份和log存储等非核心业务的数据。
• MySQL & Manhattan 作用户数据存储的首选。
• Memcache, Redis 作缓存
• FlockDB 存储社交图
• MetricsDB 存储平台数据记录
• Blobstore 存储图片、视频和大文件

早期的文章提到Twitter弃用MySQL换成了NoSQL型的Cassandra，但是后来也无法满足增长庞大的用户量，开始使用Manhattan。
Manhattan是Twitter基于目前需求及长远考虑，自行开发的分布式数据库系统。在设计Manhattan时主要遵循了保持核心轻量和简单、能够更快地带来价值、有限考虑多租户、服务质量（QoS）和自助服务、专注于可预测性、存储作为服务，而不仅仅是技术的原则。
大致可以看出twitter的重心更加侧重在了数据库的研发上，更加针对业务。

总结

总之，虽然没有详细的去列举表结构应该如何去设计，但是中间提供的几种实现的思路都是可以借鉴的。另外，可扩展性也是需要重点关照的一环，最初需要具体看所要开发的社交结构是什么样子，根据可预见的数据量进行分析。一开始用户少就没有必要考虑那么多，等到用户爆机之后就需要去做优化了。

最后推荐下阿里的这篇文章，应该是非常详细的案例了亿级规模的 Feed 流系统，如何轻松设计？

参考

NoSQL 还是 SQL ？这一篇讲清楚
微博的数据库设计，如何解答？
微博分布式存储作业实现方法
what database does twitter use