twitter系统架构分析

twitter系统架构分析

(一)twitter的核心业务 twitter的核心业务,在于following和be followed: (1)following-关注 进入个人主页,会看到你follow的人发表的留言(不超过140个字),这是following的过程; (2)followed-被关注 你发布一条留言,follow你的人将看到这条信息,这是be followed的过程;

(二)twitter的业务逻辑 twitter的业务逻辑也不复杂 following业务,查follow了哪些人,以及这些人发表的留言; followed业务,前端js轮询后端,看follow了的人有没有新留言,有则更新(更新及时性取决于轮询时间);

(三)三层架构(three-tier architecture) 网站的架构设计,传统的做法是三层架构,所谓“传统”不意味着“过时”,新潮的技术不成熟,传统的路子更稳健。 (1)表示层(presentation tier):apache web server,主要任务是解析http协议,将请求分发给逻辑层; (2)逻辑层(logic tier):mongrel rails server,利用rails现成的模块,降低工作量; (3)数据层(data tier):mysql;

数据层先来吧: twitter的核心是(1)用户;(2)消息;(3)用户关系; 围绕这几个核心,其核心数据的schema设计: (1)用户表user id, name, pass, status, … (2)消息表msg msgid, author_id, msg, time, … (3)用户关系表relation id, following_ids, followed_ids

逻辑层: 当用户发布消息时,依次执行: (1)存消息至msg表; (2)查用户relation表,找出其followed_ids; (3)获取followed_ids中用户的状态; (4)在线的ids,将消息push进一个队列queue; (5)queue中的msg,更新ids的主页; 这里面要用到队列,其实现方式有很多种,例如apache mina,twitter团队自己实现了一个kestrel。

表示层: 表示层的主要职能有2个: (1)http协议处理(http processor); (2)分发器(dispatcher); 当然,访问twitter的不仅仅是浏览器,可能还有手机,由于可能存在其他协议,故可能存在其他processor。

无论如何,架构框架清晰如下:

图1:架构版本1

(四)cache=cash即缓存等于收入 cache的使用对大型网站架构至关重要,网站响应速度是影响用户体验最明显的因素,而影响响应速度最大的敌人又是磁盘io。 twitter工程师认为,良好体验的网站平均响应时间应该在500ms左右,理想的时间是200-300ms。 关于cache的使用,是twitter架构的一大看点,带cache的架构清晰如下:

图2:带cache架构版本2

哪里需要cache?IO越频繁的地方,越需要cache。 数据库是IO访问最频繁处,三大核心表是否有必要放入内存中? twitter的做法是,将表拆分,将其中访问最频繁的字段装入cache。 (1)vector cache and row cache即数组cache与行cache vector cache:新发表消息的msgids,相关作者的ids,这些id的访问频率很高,存放它们的cache称为vector cache; row cache:消息正文的行cache; 内存有限的情况下,优先vector cache,实际结果vector cache的命中率是99%,row cache为95%;

(2)fragment cache and page cache 访问twitter的用户除了网页(web通道),还有手机(API通道),而后者的比例占总流量的80%-90%。 mysql cache之外,cache的重心会在API通道上。 手机屏幕的主体,是一屏一屏的消息,不妨把整个页面分割成若干局部,每个局部对应一些/一条消息,这些就是fragment。 人气高的作者,缓存其页面的fragment,可以提高读取其发布消息效率,这就是fragment cache的使命。 人气旺的作者,人们也会访问其主页,这就是page cache的使命。 实际结果,fragment cache的命中率为95%,page cache为40%。 虽然page cache的命中率低,但由于是访问主页,其占用的空间是很大的,为了防止两种cache相互影响,这两种cache需要部署在不同的物理机器上。 twitter的fragment cache和page cache都是使用的memcached。

(3)http accelerator web通道的缓存问题也需要解决,分析之后,web通道的压力主要来自搜索。 面临突发事件时,读者们会搜索相关信息,而不会理会这些信息的作者是不是自己follow的那些人。 为了降低搜索压力,可以将搜索关键词与搜索内容cache起来,这里,twitter的工程师使用了varnish。 有趣的是,varnish通常部署在web server外层,先访问varnish,其中没有先关的内容,才访问web server; twitter的工程师却将varnish放在apache web server的内层,原因是他们认为varnish操作复杂,担心varnish崩溃造成系统的瘫痪,故采用了这种保守型部署方式。 twitter没有公开varnish的命中率,他们声称,使用了varnish之后,整站的负载下降了50%。

(五)抗洪需要隔离 twitter架构的另一大看点是其消息队列:隔离用户的操作,将流量高峰摊平。 餐厅客满时,对于新来的顾客,虽然不能服务,但不是拒之门外,而是让他们现在休息厅等待。 用户访问twitter时,接待他的是apache web server,而apache不能接待无限多的用户。 2009年1月20日,奥巴马发表就职演说,twitter流量猛增,此时如何是好。 面对洪峰,如何保证网站不奔溃?迅速接纳,但推迟服务。 apache收到请求,转发给Mongrel,由Mongrel负责实际处理,apache则腾出手来,迎接下一位用户。 但apache能够接待的用户数总是有限的,它的并发数受apache能够容纳的工作进程数量,这里不细究apache内部原理,图如下:

图3:apache内部架构

(六)数据流与控制流 快速接纳,推迟服务,只是缓兵之计,目的是让用户不至于收到503(service unavailable)。 真正的抗洪能力,体现在蓄洪与泄洪两个方面: (1)twitter有庞大的memcached集群,能大容量蓄洪; (2)twitter自己的kestrel消息队列,作为引流泄洪手段,传递控制指令(引流和渠道); 洪峰到达时,twitter控制数据流,将数据及时疏散到多个机器,避免压力集中,造成系统瘫痪。 下面举例说明twitter内部流程,假设有两个作者,通过浏览器发消息,一个读者也通过浏览器阅读他们的消息。

图4:twitter流

(1)登陆apache web server,apache分配一个工作进程为其服务,登陆,查id,写cookie等; (2)上传新写的消息,把作者id,消息等转发给Mongrel,apache等待Mongrel回复,以便更新作者主页,将新写的消息更新上去; (3)Mongrel收到消息后,分配一个msgid,将其与捉着id等缓存到vector memcached上去; 同时,Mongrel让vector memcached查找作者被哪些人follow,缓存如果没有命中会去后端mysql查找,并入cache; 读者ids会返回给Mongrel,Mongrel把msgid与短信正文缓存至row memcached; (4)Mongrel通知kestrel消息队列服务器,每个作者及读者都有一个队列(没有则创建); Mongrel将msgid放入读者的队列,以及作者本人的队列; (5)某一台Mongrel,它可能正在处理某一个id的队列,就会往返回该id用户的主页上添加上此条信息; (6)Mongrel将更新后作者的主页给前端等待着的apache,apache则返回浏览器。

(七)洪峰与云计算 不细说了,洪峰扛不住时,只能加机器。 机器哪里来?租云计算平台公司的设备。 当然,设备只需要在洪峰时租用,省钱呀(@58沈剑 疑问:twitter怎么知道什么时候是洪峰?)。

(八)push与pull的折衷 可以看到,Mongrel的工作流程: (1)将相关ids放入vector memcached和row memecached就算消息发布成功,而不负责mysql数据库的存入; (2)将相关msgid放入kestrel消息队列就算消息推送成功; Mongrel没有使用任何方式去通知作者、读者,让他们重新拉取消息。 上述工作方式,反映了twitter架构设计“分拆”的理念: (1)将一个完整的流程分拆成独立工作的子流程,一个工作可以由各个服务负责(三层架构本身是一种分拆); (2)多机器之间协作,细化数据流与控制流,并强调其分离;

twitter业务流程的分隔,是一种事件驱动式的设计,主要体现在两个方面: (1)Mongrel与mysql的分离,前者不直接插手mysql的操作,而委托memcached全权负责; (2)上传、下载逻辑分离:只通过kestrel队列来传递指令;

原文发布于微信公众号 - 架构师之路(road5858)

原文发表时间:2014-12-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏华章科技

GitHub 到底为啥这么受欢迎?我们为你整理了一份使用攻略

导读:GitHub,全世界开发者的安全空间,在这里,你可以分享你的代码为大家所用,也可以和全世界的开发者一起共建完善你的代码。在这里,你可以学习借鉴前辈的经验快...

15940

使用Apprenda和R分析应用程序工作负载数据

平台即服务(PaaS)可以利用的最重要的数据类型之一就是它在其权限范围内运行的访客应用程序的内容。PaaS服务应该了解关于访客应用程序的各种各样的事情 - 包括...

19060
来自专栏北京马哥教育

『九个月实现破亿用户的可扩展架构』学习笔记

昨晚把美拍架构负责人洪小军在Qcon上的『九个月实现破亿用户的可扩展架构』分享看了一遍(其实那场QCon我也在现场,但是当时小军这个会场实在太多人了,而且当时北...

37150
来自专栏SAP最佳业务实践

SAP最佳业务实践:ETO–项目装配(240)-14开始生产

CJ20N开始生产 image.png 在此步骤中审批 WBS 要素生产。 角色项目经理 后勤®项目系统®项目®项目构造器 1. 在工作清单中选择相关项目 (...

39860
来自专栏带你撸出一手好代码

如何正确使用缓存技术

缓存技术是用来提升程序运行性能的常见手段,君不见, 阿里巴巴、新浪微博、美团网等互联网龙头企业都是用缓存技术来提升自己家网站的性能。然而,任何事物都有两面性, ...

38960
来自专栏北京马哥教育

关于泰捷商城项目与如何做一个高可用的网站

hi 各位, 上两周一直都在做泰捷商城这个项目。这个项目的目的就是卖泰捷出品的WEBOX。这是我第一次做有关电子商务的网站。各种头绪。其实原始需求很简单,只卖一...

394120
来自专栏Golang语言社区

优酷、YouTube、Twitter及JustinTV几个视频网站的架构

优酷视频网站架构 一、网站基本数据概览 据2010年统计,优酷网日均独立访问人数(uv)达到了8900万,日均访问量(pv)更是达到了17亿,优酷凭借这一数据成...

1.7K70
来自专栏IT大咖说

MySQL 高扩展架构构建百万在线系统实践

20530
来自专栏网络

学web前端开发写给新手的建议,超实用!

如今我们使用的互联网,客户端与服务器端的交互无时无刻不在发生。比如我们在浏览器打开网页,浏览器就是客户端,将网页数据发过来的也就是服务器。其实服务器,并没有什么...

24290
来自专栏喔家ArchiSelf

程序员眼中的测试

码农的产品和服务大都是以软件形式存在的,我们存在的价值之一就是快速提供高质量的软件产品或服务。如何保障软件的高质量呢?这与软件测试分不开的,测试是保证软件质量的...

19240

扫码关注云+社区

领取腾讯云代金券