More Related Content Similar to Twitter架构剖析 语录 Similar to Twitter架构剖析 语录 (12) 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
