- 主题:豆瓣 右边实时更新的内容用的什么技术啊
标题是“过去一分钟里 ······”
然后列出了过去一分钟里全站的新增事件,感觉这个比较难啊,要是按照时间轮询数据库,然后生成页面内容的话,万一要是遇到海量事件,那它的服务光在这一块的消耗就很大了。。。
--
FROM 117.12.251.*
放个队列行不?
今天正好看了一篇关于豆瓣服务器的文章:
http://www.dbanotes.net/arch/douban_web_server.html
【 在 TouchUrBody (八斗之财) 的大作中提到: 】
: 标题是“过去一分钟里 ······”
: 然后列出了过去一分钟里全站的新增事件,感觉这个比较难啊,要是按照时间轮询数据库,然后生成页面内容的话,万一要是遇到海量事件,那它的服务光在这一块的消耗就很大了。。。
--
FROM 222.35.98.*
晕什么?觉得人家太能省了?
豆瓣的Server端脚本是Python,当然有些核心代码不是,记得以前阿北说的。
【 在 TouchUrBody (八斗之财) 的大作中提到: 】
: 晕。决定立刻压缩预算!!!!
--
FROM 222.35.98.*
...
凭空压缩啊?
【 在 TouchUrBody (八斗之财) 的大作中提到: 】
: 晕。决定立刻压缩预算!!!!
--
FROM 221.218.128.*
【 在 dhcn (Bipolar|小石) 的大作中提到: 】
: 晕什么?觉得人家太能省了?
: 豆瓣的Server端脚本是Python,当然有些核心代码不是,记得以前阿北说的。
顺藤摸瓜,发现一个lighttp做前端,apache做后端,squid做缓冲的方法,不知道实际效果怎么样:
http://blog.daviesliu.net/2006/09/09/010620/
--
FROM 117.12.251.*
【 在 kabbesy (Arthas) 的大作中提到: 】
: ...
: 凭空压缩啊?
-_-!也不是,只是有种受到启发的感觉。可以在效率上做做文章。
--
FROM 117.12.251.*
这种开销并不大,一个select就出来了
1次取60条,每次显示其中12条,放一个5分钟的cache,普通用户也看不出来
【 在 TouchUrBody (八斗之财) 的大作中提到: 】
: 标题是“过去一分钟里 ······”
: 然后列出了过去一分钟里全站的新增事件,感觉这个比较难啊,要是按照时间轮询数据库,然后生成页面内容的话,万一要是遇到海量事件,那它的服务光在这一块的消耗就很大了。。。
--
FROM 123.116.100.*
有两种应用缓存list可以解决这个问题
一种是高写频率下,强行延迟失效,short_time_list
一种是在内存中维护list次序
再海量事件无非也是秒间10帖的规模
只要业务相关的SNA集群做的好,数据复制可控,这个规模*10也很轻松
【 在 TouchUrBody (八斗之财) 的大作中提到: 】
: 标题是“过去一分钟里 ······”
: 然后列出了过去一分钟里全站的新增事件,感觉这个比较难啊,要是按照时间轮询数据库,然后生成页面内容的话,万一要是遇到海量事件,那它的服务光在这一块的消耗就很大了。。。
--
FROM 221.218.128.*