没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
解剖 Twitter
时常听到“浮躁”这个词,批评现代人不求甚解,缺乏严谨踏实的作风。这种批评有狭
隘之嫌。每代人所处的环境不同,面临的问题不同,所以逐渐养成一种风气,去适应新的
环境,解决新的问题。
几百年前,人们读长篇小说、看歌剧、听交响乐。到了二十世纪,大家读杂志报纸、
看电影电视、听流行歌曲。信息时代,人们上网、读博客、看视频。在这些表象的背后,
促成这些风气进化的,是信息的产量与传播速度的激增。面对海量而且迅速更新的信息,
人人捧读红楼梦,一唱三咏的局面是难以想象的。取而代之的,是要求信息的篇幅简短,
而重点突出。
随着信息爆炸的加剧,微博客网站 Twitter 横空出世了。用横空出世这个词来形容
Twitter 的成长,并不夸张。从 2006 年 5 月 Twitter 上线,到 2007 年 12 月,一年半的时间
里,Twitter 用户数从 0 增长到 6.6 万;又过了一年,2008 年 12 月,Twitter 的用户数达到
5 百万
[1]
。
Twitter 用户数的急剧攀升,与几次重大事件有关:2007 年 3 月美国 SXSW 音乐节;
2008 年 11 月印度孟买的恐怖事件;2009 年 1 月奥巴马总统就职;2009 年 6 月伊朗选举
危机等等重大事件的报导,特点是读者多、更新快。所以,Twitter 网站的成功,先决条件
是能够同时给千万用户提供服务,而且提供服务的速度要快
[2,3,4]
。
有观点认为,Twitter 的业务逻辑简单,所以竞争门槛低。前半句正确,但是后半句有
商榷余地。Twitter 的竞争力,离不开严谨的系统架构设计。
一、万事开头易
Twitter 的核心业务逻辑,在于 Following 和 Be followed
[5]
。
进入 Twitter 个人主页,你会看到你 following 的那些作者,最近发表的微博客。所谓
微博客,就是一则短信,Twitter 规定,短信的长度不得超过 140 个字。短信不仅可以包含
普通文字信息,也可以包含 URL,指向某个网页,或者照片及视频等等。这就是 following
的过程。
当你写了一则短信并发表以后,你的 followers 会立刻在他们的个人主页中看到你写的
最新短信。这就是 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 就能读到最新发表的短信了。
从作者发表到读者获取,中间的延迟,取决于 JavaScript 更新的间隔,以及 Twitter 服
务器更新每个 follower 的主页的时间。
从系统架构上来说,似乎传统的三段论(Three-tier architecture
[6]
),足够满足这个业务
逻辑的需要。事实上,最初的 Twitter 系统架构,的确就是三段论。
Reference:
[1] Fixing Twitter.
http://www.bookfm.com/courseware/coursewaredetail.html?cid=100777
[2] Twitter blows up at SXSW conference.
http://gawker.com/tech/next-big-thing/twitter-blows-up-at-sxsw- conference-243634.php
[3] First Hand Accounts of Terrorist Attacks in India on Twitter and Flickr.
http://www.techcrunch.com/2008/11/26/first-hand-accounts-of-terrorist- attacks-in-india-on-twitter/
[4] Social Media Takes Center Stage in Iran.
http://www.findingdulcinea.com/news/technology/2009/June/Twitter-on- Iran-a-Go-to-Source-or-Almost-
Useless.html
[5] Twitter 的这些那些.
http://www.ccthere.com/article/2363334
http:// www.ccthere.com/article/2369092
[6] Three tier architecture.
http://en.wikipedia.org/wiki/Multitier_architecture
二、三段论
网站的架构设计,传统的做法是三段论。所谓“传统的”,并不等同于“过时的”。大型网
站的架构设计,强调实用。新潮的设计,固然吸引人,但是技术可能不成熟,风险高。所
以,很多大型网站,走的是稳妥的传统的路子。
2006 年 5 月 Twitter 刚上线的时候,为了简化网站的开发,他们使用了 Ruby-On-Rails
工具,而 Ruby-On-Rails 的设计思想,就是三段论。
1、前段,即表述层(Presentation Tier) 用的工具是 Apache Web Server,主要任务是
解析 HTTP 协议,把来自不同用户的,不同类型的请求,分发给逻辑层。
2、中段,即逻辑层 (Logic Tier)用的工具是 Mongrel Rails Server,利用 Rails 现成
的模块,降低开发的工作量。
3、后段,即数据层 (Data Tier) 用的工具是 MySQL 数据库。
先说后段,数据层。
Twitter 的服务,可以概括为两个核心:1、用户;2、短信。用户与用户之间的关系,
是追与被追的关系,也就是 Following 和 Be followed。对于一个用户来说,他只读自己
“追”的那些人写的短信。而他自己写的短信,只有那些“追”自己的人才会读。抓住这两个核
心,就不难理解 Twitter 的其它功能是如何实现的
[7]
。
围绕这两个核心,就可以着手设计 Data Schema,也就是存放在数据层(Data Tier)中
的数据的组织方式。不妨设置三个表
[8]
:
1、用户表:用户 ID,姓名,登录名和密码,状态(在线与否)。
2、短信表:短信 ID,作者 ID,正文(定长,140 字),时间戳。
3、用户关系表,记录追与被追的关系:用户 ID,他追的用户 IDs (Following),追他
的用户 IDs (Be followed)。
再说中段,逻辑层。
当用户发表一条短信的时候,执行以下五个步骤:
1、把该短信记录到“短信表”中去。
2、从“用户关系表”中取出追他的用户的 IDs。
3、有些追他的用户目前在线,另一些可能离线。在线与否的状态,可以在“用户表”中
查到。过滤掉那些离线的用户的 IDs。
4、把那些追他的并且目前在线的用户的 IDs,逐个推进一个队列(Queue)中去。
5、从这个队列中,逐个取出那些追他的并且目前在线的用户的 IDs,并且更新这些人
的主页,也就是添加最新发表的这条短信。
以上这五个步骤,都由逻辑层(Logic Tier)负责。前三步容易解决,都是简单的数据库
操作。最后两步,需要用到一个辅助工具,队列。队列的意义在于,分离了任务的产生与
任务的执行。
队列的实现方式有多种,例如 Apache Mina
[9]
就可以用来做队列。但是 Twitter 团队自
己动手实现了一个队列,Kestrel
[10,11]
。Mina 与 Kestrel,各自有什么优缺点,似乎还没人做
过详细比较。
不管是 Kestrel 还是 Mina,看起来都很复杂。或许有人问,为什么不用简单的数据结
构来实现队列,例如动态链表,甚至静态数组?如果逻辑层只在一台服务器上运行,那么
对动态链表和静态数组这样的简单的数据结构,稍加改造,的确可以当作队列使用
Kestrel 和 Mina 这些“重量级”的队列,意义在于支持联络多台机器的,分布式的队列。在本
系列以后的篇幅中,将会重点介绍。
最后说说前段,表述层。
表述层的主要职能有两个:1、HTTP 协议处理器(HTTP Processor),包括拆解接收到
的用户请求,以及封装需要发出的结果。2、分发器(Dispatcher),把接收到的用户请求,
分发给逻辑层的机器处理。如果逻辑层只有一台机器,那么分发器无意义。但是如果逻辑
层由多台机器组成,什么样的请求,发给逻辑层里面哪一台机器,就大有讲究了。逻辑层
里众多机器,可能各自专门负责特定的功能,而在同功能的机器之间,要分摊工作,使负
载均衡。
访问 Twitter 网站的,不仅仅是浏览器,而且还有手机,还有像 QQ 那样的电脑桌面工
具,另外还有各式各样的网站插件,以便把其它网站联系到 Twitter.com 上来
[12]
。因此,
Twitter 的访问者与 Twitter 网站之间的通讯协议,不一定是 HTTP,也存在其它协议。
三段论的 Twitter 架构,主要是针对 HTTP 协议的终端。但是对于其它协议的终端 ,
Twitter 的架构没有明显地划分成三段,而是把表述层和逻辑层合二为一,在 Twitter 的文献
中,这二合一经常被称为“API”。
综上所述,一个能够完成 Twitter 基本功能的,简单的架构如 Figure 1 所示。或许大家
会觉得疑惑,这么出名的网站,架构就这么简单?Yes and No,2006 年 5 月 Twitter 刚上
线的时候,Twitter 架构与 Figure 1 差距不大,不一样的地方在于加了一些简单的缓存
(Cache)。即便到了现在,Twitter 的架构依然可以清晰地看到 Figure 1 的轮廓。
Figure 1. The essential 3-tier of Twitter architecture
Reference:
[7] Tweets 中常用的工具
http://www.ccthere.com/article/2383833
[8] 构建基于 PHP 的微博客服务
http://webservices.ctocio.com.cn/188/9092188.shtml
[9] Apache Mina Homepage
http://mina.apache.org/
[10] Kestrel Readme
http://github.com/robey/kestrel
[11] A Working Guide to Kestrel.
http://github.com/robey/kestrel/blob/master/docs/guide.md
[12] Alphabetical List of Twitter Services and Applications
http://en.wikipedia.org/wiki/List_of_Twitter_services_and_applications
三、Cache == Cash
Cache == Cash,缓存等于现金收入。虽然这话有点夸张,但是正确使用缓存,对于
大型网站的建设,是至关重要的大事。网站在回应用户请求时的反应速度,是影响用户体
验的一大因素。而影响速度的原因有很多,其中一个重要的原因在于硬盘的读写 (Disk
IO)。
Table 1 比较了内存(RAM),硬盘(Disk),以及新型的闪存(Flash),在读写方面的速度
比较。硬盘的读写,速度比内存的慢了百万倍。所以,要提高网站的速度,一个重要措施
是尽可能把数据缓存在内存里。当然,在硬盘里也必须保留一个拷贝,以此防范万一由于
断电,内存里的数据丢失的情况发生。
Table 1. Storage media comparison of Disk, Flash and RAM
[13]
Twitter 工程师认为,一个用户体验良好的网站,当一个用户请求到达以后,应该在平
均 500ms 以内完成回应。而 Twitter 的理想,是达到 200ms- 300ms 的反应速度
[17]
。因此
在网站架构上,Twitter 大规模地,多层次多方式地使用缓存。Twitter 在缓存使用方面的实
践,以及从这些实践中总结出来的经验教训,是 Twitter 网站架构的一大看点。
剩余23页未读,继续阅读
资源评论
- haohaojiahuo2015-08-29谢谢,论文使用材料。
Labradoor
- 粉丝: 0
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功