Twitter架构剖析语录

Twitter架构剖析
夏松江
2010-06

Twitter奇迹
域名：www.twitter.com
一个社交和微博的服务网站；
埃文·威廉姆斯(Evan Williams)与2006年创建；
Twitter用户数过亿；(2010-4-15)
Twitter被收录在英文字典中；

Twitter奇迹
简单的产品模式—140个字符模式
允许用户广播或发送跟随者(followers)140个字符短信；
最初是应用在手机短信，后来发展到Web、第三方App应用；
完全免费；

Twitter的成功
开放API
大部分流量来自第三方API
简单
操作太简单了
实时性
有几次世界性事件比任何媒体都快
病毒性传播
SNS关系

因为简单，所以复杂
背后一定有一个非常强大的架构！

进入Twitter架构
一些架构数据
Twitter目前有105,779,710注册用户数；
Twitter现在每天有300,000的新注册用户数；
每月有180万独立访问用户数；
75%的流量来自Twitter.com网以外的网站；
每天通过API有30亿请求总次数；
Twitter用户每天平均有5500万次tweet；
37%的活跃用户为手机用户；
超过一半（60%）的tweet来自第三方应用；
Twitter 2010 Chirp开发者大会

核心业务
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就能读到最新发表的短信了。

平台构成—概述
手机
Twitter.com
第三方
Twitter平台

平台构成—工具
Ruby on Rails：Web应用程序的框架
Erlang：通用的面向并发的编程语言，开源 http://www.erlang.org/
C
Java
Scala
Google Analytics
AWStats：实时日志分析统计系统 http://awstats.sourceforge.net/

平台构成—前端
Rails
前台页面展示
数据库查询
缓存组合

平台构成—中间件
Memcached
Starling：Ruby开发的轻量级的消息队列
Varnish：高性能开源HTTP加速器(取代Squid？)
Kestrel：scala编写的消息中间件 http://github.com/robey/kestrel
Comet server：Comet 是一种新的 Web 应用架构。基于这种架构开发的应用中，服务器端会主动以异步的方式向客户端程序推送数据，而不需要客户端显式的发出请求。
Memcached客户端--libmemcached

平台构成—服务器
MySQL
Mongrel：Ruby的HTTP服务器，专为rails应用；http://rubyforge.org/projects/mongrel/
Munin：服务端监控程序 http://munin-monitoring.org/
Nagios：网络监控系统 http://www.nagios.org/

架构思想
发布消息
获取消息
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

架构1—缓存
Web2.0网站所有的一切都是运行在内存中

Cache通常架构

架构1—缓存
每个tweet平均被126个用户跟踪，所以这里有着明显的缓存需求;
只有API有着一个页面缓存，当每次从一个用户那里来了一个tweet时就会失效，而应用的其它部分都是无缓存的;

架构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的说法，该页面缓存池使用了一个分代的键模式，而不是直接的失效；

架构1—缓存

架构1
用三层结构表示

架构2—消息队列
发布Tweet后，放到队列中，并转发到各个Follower中去；
Twitter的MQ很简单：基于Memcached的协议，job之间是无序的，服务器之间没有共享的状态，所有的东西都保存在RAM里，并且是事务性的。
最初Starling，因为Ruby的GC机制，后来改为Scala编写的Kestrel；
做一个格式的转换桥，转换成其他设备所需要的格式，并负责转发；

架构3--Memcached客户端
Libmemcached
Memcached客户端的优化目的是试图优化集群负载；
持续一年的碎片缓存优化带来了50倍的每秒页面请求服务增加；

来自架构师的建议
10万用户级别
单服务器，前端、后端、cache、db在一起。
百万级
db和cache单独部署服务器，db或按业务进行拆分(sharding)
cache或使用一致性hash扩展。
前端后端还是在一起，但是根据业务拆分，每个业务可分配不同数量的服务器
千万级
开始重视架构设计，有专门技术架构师
需跨机房部署，前端在远程增加反向代理加速，数据库在异地机房使用slave数据库副本
后端拆分出来，系统内部需要远程调用，内部需远程调用协议。
亿级
架构更细分，或增加数据架构师，cache架构师，分布式架构师
数据库sharding碰到烦恼，开始考虑分布式数据服务
数据访问需要根据业务特点细分。
开发、运维、测量、调优具备有自己的专有工具。
所有服务需要地理多机房分布，具备IDC容灾设计。
服务可降级
--Tim Yang

Twitter架构剖析语录

by haiwei8086

Accessibility

Categories

Upload Details

Usage Rights

Statistics