kobe 说:
缓存、apache
我想把这一条线串起来
lc 说:
web server->cache/db 这条线?
kobe 说:
对
lc 说:
现在web 2.0的cache机制和web1.0的不太一样
web 2.0的cache大多数在部分cache
kobe 说:
这几天也在看twitter
lc 说:
o, twitter的框架?还是他的源代码?
kobe 说:
框架
源码哪里能看到????
lc 说:
有部分
kobe 说:
给我行吗??
lc 说:
你不在myspace,不然我发的邮件中都有
kobe 说:
哼哼
lc 说:
总的来说,twitter框架不复杂
cache主体分成verticle cache和row cache两种,fregment cache主要是为生成页面/json/xml准备的
他们用的cache系统性能不高
每秒写入/读取只有15000 OPS
kobe 说:
咱们现在是分布式cache了嘛?
lc 说:
恩
kobe 说:
人家有cache直写db
lc 说:
这个其实和cache系统设计没关系的
kobe 说:
cache中有队列,维护
lc 说:
我们可以写SQL Server Relay Component,一样可以直写 d
cache系统都会有队列的
特别是写的
kobe 说:
verticle cache和row cache 很想知道,怎样考虑一些数据该存放在哪里
lc 说:
Non-sql db
kobe 说:
还有 fragment和page cache的
lc 说:
row cache好理解,就是比如用户的数据,feed的数据
verticle cache是指聚合数据,比如following/feedlist
verticle cache仅仅存储ID,不存取内容
这样的设计主要是为了减少存储体积
还有就是适应更新操作
twitter目前的feed是push模式的,不是poll模式的
他们需要处理比如奥巴马这种几百万用户的feed散发的问题
kobe 说:
那比如我们的微博客的缓存,如果要改进,有哪些地方?
lc 说:
1. 将feed内容很feedid分开,现在我们的统一存储是存在一起的
另外一个就是建立真正的dispatch机制(消息路由)
现在的消息路由机制不能有效处理大量并发
3. 要将部分逻辑实现异步处理
php本身不能有效支持异步,需要有单独的服务比如java/.net这种语言写的多线程服务去handle
比如写reply,写随便看看,dispatch到审核后台等等
这些逻辑不必要在开始的时候,就写数据库
当然,现在我们的量还没这么大,性能低一些问题不大
如果大了的话,异步处理是很重要的
kobe 说:
估计现在也是先做功能,再考虑性能了 但是提前问问,可以留下扩展的余地 嘿嘿
lc 说:
恩,太早设计会over design了
kobe 说:
但是不能一开始就没设计
我这几天思考了下你说的设计轮子的问题,我目前的阶段跟你差的太远了
我应该是先看别人的轮子,学习用,并且用好他们
等到了你的阶段,再考虑自己做轮子
lc 说:
其实twitter自己并没有作轮子
他们是改装
kobe 说:
咳咳 聪聪别扣字眼
lc 说:
设计是非常化脑力的事情
relay是myspace完全设计的
这是造轮子
Activity Service也是自己设计的,也是造轮子
造论子有以下问题需要考虑
1. 文档 2. 其他语言支持 3. 管理工具
这几个问题都是造论子最大的问题
kobe 说:
咱们的relay和Activity 有文档吗?
lc 说:
relay有,activity没有
有ppt
介绍架构的
kobe 说:
但是只有架构不够吧
那现在想要用好别人的轮子,有什么建议吗?
lc 说:
http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/
twitter基于cassandra改造的
这个数据库性能并不好
现在用别人的轮子,看你做什么
kobe 说:
比如memcache
apache
lc 说:
如果作cache, 主要注意看是否需要支持永久华
kobe 说:
我一开始是看源码,但是看了就忘,也看不下去了。陈大夫说要从表象往里挖
lc 说:
tokyo cabinet在小数据量的时候,非常好
你要有一个比较好的工具
比如VS.NET/Eclipse之类的
帮你整理函数之间关系
还要自己搭建一次
kobe 说:
对了 有什么能看到内存里数据的工具吗?
lc 说:
在windows下就是windbg和vs.net,在linux下用gdb
直接attach到进程中去看
http://timyang.net/
这个人对twitter架构研究得比较多
你可以看看