More Related Content Similar to Twitter架构剖析 语录 Similar to Twitter架构剖析 语录 (12) Twitter架构剖析 语录7. 核心业务 Following和Be followed 1. 为每一个注册用户订制一个Be-followed的表,主要内容是每一个follower的ID。同时,也订制一个Following的表,主要内容是每一个following作者的ID。 2. 当用户打开自己的个人空间时,Twitter先查阅Following表,找到所有following的作者的ID。然后去数据库读取每一位作者最近写的短信。汇总后按时间顺序显示在用户的个人主页上。 3. 当用户写了一则短信时,Twitter先查阅Be-followed表,找到所有followers的IDs。然后逐个更新那些followers的主页。 如果有follower正在阅读他的Twitter个人主页,主页里暗含的JavaScript会自动每隔几十秒,访问一下Twitter服务器,检查正在看的这个个人主页是否有更新。如果有更新,立刻下载新的主页内容。这样follower就能读到最新发表的短信了。 9. 平台构成—工具 Ruby on Rails:Web应用程序的框架 Erlang:通用的面向并发的编程语言,开源 http://www.erlang.org/ C Java Scala Google Analytics AWStats:实时日志分析统计系统 http://awstats.sourceforge.net/ 11. 平台构成—中间件 Memcached Starling:Ruby开发的轻量级的消息队列 Varnish:高性能开源HTTP加速器(取代Squid?) Kestrel:scala编写的消息中间件 http://github.com/robey/kestrel Comet server:Comet 是一种新的 Web 应用架构。基于这种架构开发的应用中,服务器端会主动以异步的方式向客户端程序推送数据,而不需要客户端显式的发出请求。 Memcached客户端--libmemcached 13. 架构思想 发布消息 获取消息 Mongrel Rails Server Mongrel Rails Server 40%hits Kestrel (MQ) 缓存聚合器 Page Cache Items/user (Varnish) 95%hits 99%hits 95%hits Vector Cache Tweet/user Fragment Cache Items/tweet Row Cache Items/user MySql 23. 来自架构师的建议 10万用户级别 单服务器,前端、后端、cache、db在一起。 百万级 db和cache单独部署服务器,db或按业务进行拆分(sharding) cache或使用一致性hash扩展。 前端后端还是在一起,但是根据业务拆分,每个业务可分配不同数量的服务器 千万级 开始重视架构设计,有专门技术架构师 需跨机房部署,前端在远程增加反向代理加速,数据库在异地机房使用slave数据库副本 后端拆分出来,系统内部需要远程调用,内部需远程调用协议。 亿级 架构更细分,或增加数据架构师,cache架构师,分布式架构师 数据库sharding碰到烦恼,开始考虑分布式数据服务 数据访问需要根据业务特点细分。 开发、运维、测量、调优具备有自己的专有工具。 所有服务需要地理多机房分布,具备IDC容灾设计。 服务可降级 --Tim Yang