首页 > 架构设计 > Feed系统架构设计

Feed系统架构设计

2012年9月5日 发表评论 阅读评论

(1)完全用nosql轻松打造千万级数据量的微博系统

http://www.cellphp.com/article-read-nosql-20-handlersocket-nosql-zeromq-micro-blog-gps-tokyocabinet.html

(2)微博feed系统的push和pull模式和时间分区拉模式架构探讨

http://www.mysqlops.com/2011/06/21/weibo-sns-feed-push-pull.html

(3)关于如何构建一个微博型广播

http://codecampo.com/topics/61

(4)关于如何构建一个微博型广播2

http://codecampo.com/topics/196

(5)用 mongodb 储存多态消息/提醒类数据

http://codecampo.com/topics/66

(6)构建高性能的微博系统-再谈新浪微博架构

http://www.infoq.com/cn/presentations/ywh-build-high-performance-weibo

http://www.docin.com/p-111074633.html

(7)人人网技术经理张铁安-Feed系统结构浅析

http://wenku.baidu.com/view/64dae9d126fff705cc170afd.html

http://news.csdn.net/a/20100726/277273.html

(8)新浪微博基于MySQL的分布式数据库实践

http://tech.it168.com/a2011/0415/1178/000001178546.shtml

(9)杨卫华谈新浪微博架构:MySQL和NoSQL

http://bbs.phpchina.com/thread-219448-1-1.html

(10)Tumblr:150亿月浏览量背后的架构挑战

http://www.chinaz.com/server/2012/0217/235740.shtml

腾讯微博主要使用拉模型,只有未读的微博数是使用推得模式实现的!拉模型的问题在于一个人跟随了几百或者上千的人的时候,去看关注的人所发的消息要进行多个层次的Map/Reduce才能得到结果,需要非常高效的获取最新Feed的方式以及快速的聚合算法,只用Memcache\Redis之类的从性能上是比较难于实现的,需要从数据层面或者是缓存的层面都进行聚合,再在应用层面进行聚合,技术难度比较大!这个模式属于知易行难,绝大多数公司不具备构建基础设施的能力!
新浪微博使用推拉结合的方式,大号不推送,小号则推送,看Feeds的时候,需要将推过来的Feeds索引数据与关注的大号的Feed进行聚合,小小的牺牲下拉的性能一下子就将大号的推送问题解决掉了!
对于稍微小些的网站,比如Pinterest和花瓣都使用推的方式来实现,PInterest的直接在Redis中保存500个最新的索引信息,使用Python脚本定时来扫描,保证缓存的索引信息始终只保存最新的500个,老的信息则直接丢弃掉,花瓣则将老索引存储到LevelDBA中去了!
Pinterest网站的内容信息缓存在memcache中,关系信息则缓存到Redis中,持久化方式保存!对于那种大号的粉丝,亦或是关注的人数太多则需要将关系数据拆分之后再缓存起来,对于动态变化的部分则需要独立存放,在使用的时候需要将两部分数据聚合,在可变部分达到一定长度的时候,需要与不变的部分进行合并!
当然推送的时候,所有的网站都使用异步的方式来实现!

分类: 架构设计 标签:
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.