• 1. Twitter架构剖析夏松江 2010-06
  • 2. Twitter奇迹域名:www.twitter.com 一个社交和微博的服务网站; 埃文·威廉姆斯(Evan Williams)与2006年创建; Twitter用户数过亿;(2010-4-15) Twitter被收录在英文字典中;
  • 3. Twitter奇迹简单的产品模式—140个字符模式 允许用户广播或发送跟随者(followers)140个字符短信; 最初是应用在手机短信,后来发展到Web、第三方App应用; 完全免费;
  • 4. Twitter的成功开放API 大部分流量来自第三方API 简单 操作太简单了 实时性 有几次世界性事件比任何媒体都快 病毒性传播 SNS关系
  • 5. 因为简单,所以复杂背后一定有一个非常强大的架构!
  • 6. 进入Twitter架构一些架构数据 Twitter目前有105,779,710注册用户数; Twitter现在每天有300,000的新注册用户数; 每月有180万独立访问用户数; 75%的流量来自Twitter.com网以外的网站; 每天通过API有30亿请求总次数; Twitter用户每天平均有5500万次tweet; 37%的活跃用户为手机用户; 超过一半(60%)的tweet来自第三方应用;Twitter 2010 Chirp开发者大会
  • 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就能读到最新发表的短信了。
  • 8. 平台构成—概述Twitter.com手机第三方Twitter平台
  • 9. 平台构成—工具Ruby on Rails:Web应用程序的框架 Erlang:通用的面向并发的编程语言,开源 http://www.erlang.org/ C Java Scala Google Analytics AWStats:实时日志分析统计系统 http://awstats.sourceforge.net/
  • 10. 平台构成—前端Rails 前台页面展示 数据库查询 缓存组合
  • 11. 平台构成—中间件Memcached Starling:Ruby开发的轻量级的消息队列 Varnish:高性能开源HTTP加速器(取代Squid?) Kestrel:scala编写的消息中间件 http://github.com/robey/kestrel Comet server:Comet 是一种新的 Web 应用架构。基于这种架构开发的应用中,服务器端会主动以异步的方式向客户端程序推送数据,而不需要客户端显式的发出请求。 Memcached客户端-- libmemcached
  • 12. 平台构成—服务器MySQL Mongrel:Ruby的HTTP服务器,专为rails应用;http://rubyforge.org/projects/mongrel/ Munin:服务端监控程序 http://munin-monitoring.org/ Nagios:网络监控系统 http://www.nagios.org/
  • 13. 架构思想Mongrel Rails Server发布消息Kestrel (MQ)Mongrel Rails Server获取消息缓存聚合器Vector Cache Tweet/userRow Cache Items/userFragment Cache Items/tweetPage Cache Items/user (Varnish)MySql99%hits95%hits95%hits40%hits
  • 14. 架构1—缓存Web2.0网站所有的一切都是运行在内存中
  • 15. Cache通常架构
  • 16. 架构1—缓存每个tweet平均被126个用户跟踪,所以这里有着明显的缓存需求; 只有API有着一个页面缓存,当每次从一个用户那里来了一个tweet时就会失效,而应用的其它部分都是无缓存的;
  • 17. 架构1—缓存改进进程 1、创建一个直写式向量缓存Vector Cache,包含了一个tweet ID的数组,tweet ID是序列化的64位整数。命中率是99%。 2、加入一个直写式行缓存Row Cache,它包含了数据库记录:用户和tweets。这一缓存有着95%的命中率并且使用了Nick Kallen的名为Cache Money的Rails插件。 3、引入了一个直读式的碎片缓存Fragment Cache,它包含了通过API客户端访问到的tweets的序列化版本,这些tweets可以被打包成 JSON,XML或者是Atom的格式,有着同样是95%的命中率。 4、为页面缓存创建一个单独的缓存池Page Cache。根据Evan的说法,该页面缓存池使用了一个分代的键模式,而不是直接的失效;
  • 18. 架构1—缓存
  • 19. 架构1用三层结构表示
  • 20. 架构2—消息队列发布Tweet后,放到队列中,并转发到各个Follower中去; Twitter的MQ很简单:基于Memcached的协议,job之间是无序的,服务器之间没有共享的状态,所有的东西都保存在RAM里,并且是事务性的。 最初Starling,因为Ruby的GC机制,后来改为Scala编写的Kestrel; 做一个格式的转换桥,转换成其他设备所需要的格式,并负责转发;
  • 21. 架构3--Memcached客户端Libmemcached Memcached客户端的优化目的是试图优化集群负载; 持续一年的碎片缓存优化带来了50倍的每秒页面请求服务增加;
  • 22. (本页无文本内容)
  • 23. 来自架构师的建议10万用户级别 单服务器,前端、后端、cache、db在一起。 百万级 db和cache单独部署服务器,db或按业务进行拆分(sharding) cache或使用一致性hash扩展。 前端后端还是在一起,但是根据业务拆分,每个业务可分配不同数量的服务器 千万级 开始重视架构设计,有专门技术架构师 需跨机房部署,前端在远程增加反向代理加速,数据库在异地机房使用slave数据库副本 后端拆分出来,系统内部需要远程调用,内部需远程调用协议。 亿级 架构更细分,或增加数据架构师,cache架构师,分布式架构师 数据库sharding碰到烦恼,开始考虑分布式数据服务 数据访问需要根据业务特点细分。 开发、运维、测量、调优具备有自己的专有工具。 所有服务需要地理多机房分布,具备IDC容灾设计。 服务可降级--Tim Yang