SNS网站Feed功能设计
来源:互联网 发布:mac隐藏下面的图标 编辑:程序博客网 时间:2024/05/17 03:15
在SNS的网站中,最核心的功能就是Feed功能,Feed就是一条twitter或一条好友动态。该功能面临的挑战是:每天产生成千上万条数据,数据推送的需要实时性等,做网站其实最大的难点就是对海量数据和高并发的处理。本人通过对Twitter和新浪微博架构的一些资料的学习,大致了解了如何实现一个Feed功能。一个Feed功能往往有多种实现方式,最常见的是这3种:推模式、拉模式、推拉结合模式。
推模式:
推就是把自己的发的feed推送到每个粉丝那里,就是一条feed在数据库中存储多份,做法就将feed表按userId分库,对应粉丝Id的库中插一条记录。这种做法的缺点就是数据量大,数据冗余太严重,如一个明星用户有1000万粉丝,那么他发一条feed,就要产生1000万条记录。Feed的推送需要异步队列,队列的好处就是降并发,推送是需要时间的,所以一个明星发了一条feed后,当最后那个粉丝看到这条feed可能已经是几分钟后的事情了。这种模式的优点是用户查看Feed就很容易了,根据userId查询就可以了。这种做法是牺牲大量储存空间来换取网站的查看性能。
拉模式:
拉就是用户要查看动态时就去每个关注者那边找,然后聚合并展现。Feed数据只储存一份,省了很多空间。这种模式在用户量较小的网站就很容易实现,展示只要一条SQL语句。但是当用户多了以后就会遇到问题,比如我关注了2000个用户,而这2000个用户都是活跃用户,每天都会产生很多feed。我查看feed时就要去2000个关注者那里找最新的几条,合并和按时间排序,每次查看一条查询语句就快把数据库搞得累死,而且合并和排序这些feed计算量太大。拉模式在用户关注人数很多的网站不太适合。
推拉结合:
顾名思义就是两种模式的结合,将两者的优点结合。不活跃的用户(偶偶上线,关注人数又少的僵死用户等)推送的时候就不要推送给他们,省点资源,当他们上线查看时就直接拉,因为他们关注的人比较少,拉也不是很耗性能。
最后,不管采用什么方法实现,少不了异步队列,nosql等工具。比如发表feed的时候就往队列里一扔,前端马上返回,异步慢慢处理,而用户一点也察觉不出来。Nosql缓存,比如一些计数(关注数、粉丝数神马的)直接用redis、TT等储存,还有feed列表可以存储在memcached或redis中,redis的list功能很适合这种情形,但是一些大网站还不敢这么做。
以上是本人对Feed功能设计的一点浅薄认识,TimYang的新浪微博架构的PPT对我的学习有很大的帮助,感谢所有分享知识的人!
原文:http://javanotes.net/archives/29094- SNS网站Feed功能设计
- SNS网站Feed功能设计
- 类SNS网站feed系统设计
- SNS网站feed的设计思考
- (研究)SNS类网站之feed架构
- 飞信SNS FEED分享
- SNS应用好友动态Feed模块设计
- 什么是SNS?什么是SNS网站?
- 门户网站功能设计的准则
- SNS网站一览
- 点评国内SNS网站
- sns网站使用
- 关于SNS网站架构
- SNS网站的转变
- SNS网站优势
- sns网站开发小结
- 视采网站采集器功能设计
- 17joys网站后台功能设计-阶段1
- 隐马尔可夫(HMM)模型
- VC/MFC的CArray使用
- 备忘:python matplotlib
- 喜迎下一个挑战WebRTC, 博客的内容会更新的慢一些, 当然还是会持续记录下去的:)
- TCP协议三次握手连接四次握手断开和DOS攻击
- SNS网站Feed功能设计
- CSS让TD中间的内容多出部分变成“...”
- Java操作Microsoft office
- 控制pb鼠标的移动
- 关于linux文件系统监控(2)
- Perl 最佳实践(节选) --- 11
- QMapControl介绍
- linux之tar命令参数分析
- iOS Dev 深入浅出 导航控制器(二)with表视图相关操作