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

发布消息

Kestrel(MQ)

Mongrel Rails Server

获取消息

缓存聚合器

Vector CacheTweet/user Row Cache

Items/user

Fragment Cache

Items/tweet

Page CacheItems/user(Varnish)

MySql

99%hits 95%hits95%hits

40%hits

架构 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