中庸之道的newsfeed的设计
follows大道至简,道道相同,其实世界本没有那么复杂,不过人们把它描写的多样化了,他就那么复杂了,抽象到一定程度发现互不相关的东西都有他的共性,无论在任何领域都少不了change,有change都有质变,质变点就有极值点,min,max,在数学中尤为常见。但有时需要结合最大和最小结合运用才能创造出合理,譬如在web2.0时代颇为流行的newsfeed。twitter,facebook,其实googlereader等都一样,一个生产者,一个消费者。设计往往经常是大家谈论的两种,一种是存储一份,消费者就登陆时候就pull过来,例如你登陆豆瓣,就会看到你好多好友的信息,都是pull过来的,如果你比较强大可以把生产者的内容给每一个消费者发一份。但是也会面临瞬间分发的压力,虽然在发的时候有一定的延时性。但用户读取的时候就很容易,读跟自己相关的就可以了。目前好多有这种应用的都是这种操作。以下是facebooke的。
在看看一篇有关校内的http://www.54chen.com/uncategorized/net-new-to-live-for-all-to-share.html
用的是一些key value的数据库。也是push的思想,即给所有的相关的好友dispatch一份。 但是想twitter这样的有些突发事件或者名人
follows过多的话会有多大的压力无论是写还是读。 后来躲到一篇follows的论文,好像一个普林斯顿大学大学的人写的,专门解决这种臭名昭著的棘手问题,没看的太明白,但是大概思想是把生产者和消费者分类,因为有些生成者是高产者,而有些消费者是高消费者,无论单一的产用pull的方式
或者是push的方式都不是太合适,他们会根据用户的生产效率和登录比率来判断到底给用pull的方式或者是push的方式,当然作者也说类似follows的应用时臭名昭著的应用
难于设计扩展等,作者也做了性能优化方面的分析,用了yahoo的开源的pnuts的key value的一个系统。把用户的好友关系抽象成一张图,然后利用一定的算法来优化这种follows的应用。而且作者通过调用twitter的api进行了一些测试,测试效果还不错。
仔细想想也是,以前总以为设计这种系统要么是是push给用户,要么是pull给用户,但是其实两者是可以结合的,相互弥补。
看来世事没有绝对性有时候需要结合两个极端来思考问题,中庸也许是一种更好的解决办法。就像老子的思想那样,物极必反。事不能要一个极端。我会附加上作者的论文,本身我也
不全明白,多读几篇follows pdf
建议继续学习:
- 消息系统该Push/Pull模式分析 (阅读:4984)
- Push Or Pull? (阅读:3781)
- iOS push服务 (阅读:3554)
- APP的推送是咋回事 (阅读:3315)
- Array的push与unshift方法性能分析 (阅读:2593)
- Android最方便的推送框架 (阅读:2530)
- 苹果iOS系统下的推送机制及实现 (阅读:2475)
- 微信收费事件背后被广泛忽略的技术细节 (阅读:2407)
- 苹果信息推送服务(Apple Push Notification Service)使用总结 (阅读:1656)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:思维改变一切 来源: 思维改变一切
- 标签: follows push 中庸之道
- 发布时间:2010-10-28 22:19:54
- [68] Go Reflect 性能
- [68] 如何拿下简短的域名
- [67] Oracle MTS模式下 进程地址与会话信
- [62] IOS安全–浅谈关于IOS加固的几种方法
- [61] 图书馆的世界纪录
- [60] 【社会化设计】自我(self)部分――欢迎区
- [58] android 开发入门
- [56] 视觉调整-设计师 vs. 逻辑
- [49] 给自己的字体课(一)——英文字体基础
- [48] 读书笔记-壹百度:百度十年千倍的29条法则