- 主题:豆瓣 右边实时更新的内容用的什么技术啊
标题是“过去一分钟里 ······”
然后列出了过去一分钟里全站的新增事件，感觉这个比较难啊，要是按照时间轮询数据库，然后生成页面内容的话，万一要是遇到海量事件，那它的服务光在这一块的消耗就很大了。。。
--
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.*