SNS,微博 好友关注和推送功能的数据库设计是怎么实现的底层设计？

1.假如a有1000万粉丝，a发表了一篇博客,这个行为要通知这1000万粉丝，那么就会有两种情况, 

(1) 这1000万粉丝每个人都有一个消息中心表，则发送1000万条信息在系统里通知这个1000万个粉丝, 

(2) 系统只有一个消息表，这1000万粉丝固定来这个表里拉取自己的消息,那么这个消息是无状态的，怎么让这个消息在用户那里就是有状态了，未读的消息数，以读消息 

（3）采用mongdb设计数据库,则消息表和用户粉丝表 该怎能么存储呢？ 

希望搞sns的人能给我点知道 多谢！！！修改

举报添加评论 分享 • 邀请回答

赞同8
反对，不会显示你的姓名

w浩森，Engineering
Enthusiast

姜小狮lion、陈客丁、赵寄筌 等人赞同

这就是服务器缓存技术，有的使用推，有的使用拉。 

比如新浪微博FEED使用了拉，但是讲拉做了很大程度的优化，每次拉取数据时参考上次拉取的时间，也就是说每次拉去的时候只是拉去新的，这样就减少了很多资源。每次拉出来的数据是暂存在缓存结构中。而且新浪微博将后台的数据按时间分区存储，这样冷热结合平衡资源配置。 

再比如人人网使用的是推，因为每个人的好友一般都是三位数，并不像新浪那样，所以推可以满足人人网的需求。每当有action的时候就向所有的好友推送，每个用户的接受的feed表都是单独的，是现成的，如果有好友动作的话单独添加此用户的feed表 

而twitter已经使用nosql来进行新的部署 

google+的圈子又是另一种结构，所以存储和拉推的结构肯定又不一样 

总之，具体看你的社交结构是怎么样子的所以具体情况使用，根据你的数据量进行分析。一开始用户少就没有必要考虑那么多，等到用户爆机之后才会优化。当用户10万以上的时候，数据库技术的优化就微不足道了，这时候往往开始使用其他手段优化。 

互联网的海量存储与快速更新技术都是现在才出现的，所以，每个人都可以想出更多好的方法去实现。或者靠技术人员进行技术代码层次的优化。或者依靠强大的财力进行硬件层次的扩张。