解剖Twitter:Twitter系统架构设计分析-1

这个周末在家学习Twitter的架构设计原理,发现了很多精妙的地方,也验证了之前的很多猜想。

 

 

 

随着信息爆炸的加剧,微博客网站Twitter横空出世了。用横空出世这个词来形容Twitter的成长,并不夸张。从2006年5月 Twitter上线,到2007年12月,一年半的时间里,Twitter用户数从0增长到6.6万。又过了一年,2008年12月,Twitter的用 户数达到5百万。[1] 

  Twitter网站的成功,先决条件是能够同时给千万用户提供服务,而且提供服务的速度要快。[2,3,4] 

  有观点认为,Twitter的业务逻辑简单,所以竞争门槛低。前半句正确,但是后半句有商榷余地。Twitter的竞争力,离不开严谨的系统架构设 计。 

  【1】万事开头易 

  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-blow s-up-at-sxsw-conference-243634.php) 

  [3] First Hand Accounts of Terrorist Attacks in India width=500 height=496 TYPE="audio/mpeg"> 

  Figure 1. The essential 3-tier of Twitter architecture 

  Courtesy http://farm3.static.flickr.com/2683/4051785892_e67 7ae9d33_o.png 

  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/g uide.md) 

  [12] Alphabetical List of Twitter Services and Applications (http://en.wikipedia.org/wiki/List_of_Twitter_servi ces_and_applications) 

  【3】Cache == Cash 

  Cache == Cash,缓存等于现金收入。虽然这话有点夸张,但是正确使用缓存,对于大型网站的建设,是至关重要的大事。网站在回应用户请求时的反应速度,是影响用户 体验的一大因素。而影响速度的原因有很多,其中一个重要的原因在于硬盘的读写(Disk IO)。 

  Table 1 比较了内存(RAM),硬盘(Disk),以及新型的闪存(Flash),在读写方面的速度比较。硬盘的读写,速度比内存的慢了百万倍。所以,要提高网站 的速度,一个重要措施是尽可能把数据缓存在内存里。当然,在硬盘里也必须保留一个拷贝,以此防范万一由于断电,内存里的数据丢失的情况发生。 

   

  Table 1. Storage media comparison of Disk, Flash and RAM [13] 

  Courtesy http://farm3.static.flickr.com/2736/4060534279_f57 5212c12_o.png 

  Twitter 工程师认为,一个用户体验良好的网站,当一个用户请求到达以后,应该在平均500ms以内完成回应。而Twitter的理想,是达到200ms- 300ms的反应速度[17]。因此在网站架构上,Twitter大规模地,多层次多方式地使用缓存。Twitter在缓存使用方面的实践,以及从这些实 践中总结出来的经验教训,是Twitter网站架构的一大看点。 

   

  Figure 2. Twitter architecture with Cache 

  Courtesy http://farm3.static.flickr.com/2783/4065827637_bb2 ccc8e3f_o.png 

  哪里需要缓存?越是Disk IO频繁的地方,越需要缓存。 

  前面说到,Twitter业务的核心有两个,用户和短信(Tweet)。围绕这两个核心,数据库中存放着若干表,其中最重要的有三个,如下所示。这 三个表的设置,是旁观者的猜测,不一定与Twitter的设置完全一致。但是万变不离其宗,相信即便有所不同,也不会本质区别。 

  1. 用户表:用户ID,姓名,登录名和密码,状态(在线与否)。 

  2. 短信表:短信ID,作者ID,正文(定长,140字),时间戳。 

  3. 用户关系表,记录追与被追的关系:用户ID,他追的用户IDs (Following),追他的用户IDs (Be followed)。 

  有没有必要把这几个核心的数据库表统统存放到缓存中去?Twitter的做法是把这些表拆解,把其中读写最频繁的列放进缓存。 

  1. Vector Cache and Row Cache 

  具体来说,Twitter工程师认为最重要的列是IDs。即新发表的短信的IDs,以及被频繁阅读的热门短信的IDs,相关作者的IDs,以及订阅 这些作者的读者的IDs。把这些IDs存放进缓存 (Stores arrays of tweet pkeys [14])。在Twitter文献中,把存放这些IDs的缓存空间,称为Vector Cache [14]。 Twitter工程师认为,读取最频繁的内容是这些IDs,而短信的正文在其次。所以他们决定,在优先保证Vector Cache所需资源的前提下,其次重要的工作才是设立Row Cache,用于存放短信正文。 

  命中率(Hit Rate or Hit Ratio)是测量缓存效果的最重要指标。如果一个或者多个用户读取100条内容,其中99条内容存放在缓存中,那么缓存的命中率就是99%。命中率越 高,说明缓存的贡献越大。 

  设立Vector Cache和Row Cache后,观测实际运行的结果,发现Vector Cache的命中率是99%,而Row Cache的命中率是95%,证实了Twitter工程师早先押注的,先IDs后正文的判断。 

  Vector Cache和Row Cache,使用的工具都是开源的MemCached [15]。 

  2. Fragment Cache and Page Cache 

  前文说到,访问Twitter网站的,不仅仅是浏览器,而且还有手机,还有像QQ那样的电脑桌面工具,另外还有各式各样的网站插件,以便把其它网站 联系到Twitter.com上来[12]。接待这两类用户的,是以Apache Web Server为门户的Web通道,以及被称为“API”的通道。其中API通道受理的流量占总流量的80%-90% [16]。 

  所以,继Vector Cache和Row Cache以后,Twitter工程师们把进一步建筑缓存的工作,重点放在如何提高API通道的反应速度上。 

  读者页面的主体,显示的是一条又一条短信。不妨把整个页面分割成若干局部,每个局部对应一条短信。所谓Fragment,就是指页面的局部。除短信 外,其它内容例如Twitter logo等等,也是Fragment。如果一个作者拥有众多读者,那么缓存这个作者写的短信的布局页面(Fragment),就可以提高网站整体的读取效 率。这就是Fragment Cache的使命。 

  对于一些人气很旺的作者,读者们不仅会读他写的短信,而且会访问他的主页,所以,也有必要缓存这些人气作者的个人主页。这就是Page Cache的使命。 

  Fragment Cache和Page Cache,使用的工具也是MemCached。 

  观测实际运行的结果,Fragment Cache的命中率高达95%,而Page Cache的命中率只有40%。虽然Page Cache的命中率低,但是它的内容是整个个人主页,所以占用的空间却不小。为了防止Page Cache争夺Fragment Cache的空间,在物理部署时,Twitter工程师们把Page Cache分离到不同的机器上去。 

  3. HTTP Accelerator 

  解决了API通道的缓存问题,接下去Twitter工程师们着手处理Web通道的缓存问题。经过分析,他们认为Web通道的压力,主要来自于搜索。 尤其是面临突发事件时,读者们会搜索相关短信,而不理会这些短信的作者,是不是自己“追”的那些作者。 

  要降低搜索的压力,不妨把搜索关键词,及其对应的搜索结果,缓存起来。Twitter工程师们使用的缓存工具,是开源项目Varnish [18]。

Java企业场景下的实战入门课(Spring Boot+Redis)

04-20
<p> 企业场景下的Java实战课程!  </p> <p> 【超实用课程内容】 本课程主要是从最基础的技术要点一步一个脚印的介绍Spring Boot2.0相关的核心技术栈和缓存中间件Redis常见且典型的数据结构、相关的核心技术栈及典型的应用场景的实战。并附带业务场景实战用户注册和点赞系统中点赞功能模块的设计与实现为各位小伙伴提供企业级项目开发中常见且典型的Java核心技术,可以说是拒绝纸上谈兵、注重实战并学以致用!  </p> <p> <br> </p> <p> 套餐中一共包含2门实战入门课程(共82讲)  </p> <p> 课程1:《Java实战之Spring Boot入门到精通》  </p> <p> 课程2:《Java实战之Redis入门到精通》  </p> <p> <br> </p> <p> 【基础要求】  </p> <p> 1、基本要求:具备一定的JavaSE以及Java Web项目的开发基础、了解spring boot更佳  </p> <p> 2、工具要求:会使用Intellij IDEA、Navicat以及Postman  </p> <p> <br> </p> <p> 【你能收获到什么?】  </p> <p> 1、帮助学员了解并掌握springboot和缓存中间件Redis的方方面面、包括其典型及常用的数据结构及其在实际项目开发中典型的应用场景!  </p> <p> 2、掌握如何基于Spring Boot搭建企业级项目,整合加入中间件Redis相关的依赖配置,并以此为扩展,为后续学习其他中间件做铺垫;可以提升学员Java中间件的实战能力。  </p> <p> 3、帮助学员了解并掌握缓存中间件Redis在实际应用中有哪些常见、典型的应用场景,如对象信息存储、列表存储、队列特性分发消息、试题库随机获取、排行榜等等,这对于学员在平时项目开发、跳槽面试等情况下将有很大的帮助  </p> <p> 4、本课程介绍的基于Redis相关数据结构的特性独立设计并实战项目中典型功能模块,如会员到期自动提醒、点赞功能模块等内容,将有助于学员将所学的技术栈真正应用到实际中、提升自身的数据库设计能力、业务理解能力、代码实战能力以及性能优化方面的能力  </p> <p> <br> </p> <p> 【课程如何观看?】  </p> <p> 1、登录CSDN学院 APP 在我的课程中进行学习;  </p> <p> 2、移动端:CSDN 学院APP(注意不是CSDN APP哦) 本课程为录播课,课程2年有效观看时长 【资料开放】 课件、课程案例代码完全开放给你,你可以根据所学知识,自行修改、优化 下载方式:电脑登录课程观看页面,点击右下方课程资料、代码、课件等打包下载 </p> <p> <img src="https://img-bss.csdn.net/202004200821078434.png" alt=""> </p>
©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值