Twitter要在同一时间内处理大量的实时信息请求，看看他的信息处理经验。

一、twitter的核心业务twitter的核心业务在于following和befollowed(1)following-*个人主页，你会看到follow的人发表的信息(不超过140个字)，这是following的过程；(2)followed-如果你被*，你会发表一条信息，你的人会看到这个信息，这是befollowed的过程；2、twitter的业务逻辑twitter的业务逻辑并不复杂。following业务，查看follow的人，以及这些人发表的信息；followed业务，前端js轮询后端，看follow的人有没有新消息，有的更新(更新的及时性取决于轮询时间)；三、三层结构（three-tierarchitecture）传统的网站架构设计方法是三层架构，所谓“传统”并不意味着“过时”（1）表示层（presentationtier）：apachewebserver，主要任务是分析http协议，将请求分发给逻辑层；(2)逻辑层（logictier）：mongrelrailsserver，使用rails现成的模块，减少工作量；(3)数据层（datatier）：mysql；表示层:表示层有两个主要功能:(1)http协议处理（httpprocessor）；（2）分发器（dispatcher）；当然，访问twitter的不仅仅是浏览器，还有手机，因为可能有其他协议，所以可能有其他processor。逻辑层:用户发布消息时，依次执行:(1)将消息存储到msg表；(2)查看用户relation表，找出其followed_ids；(3)获取followed_ids中用户的状态；(4)在线ids，将消息push进入队列queuee；(5)queue中的msg，更新ids主页；在这里使用队列，实现它的方法有很多，比如apachemina，twitter团队自己实现了一个kestrel。数据层：twitter的核心是用户；新闻；用户关系。Schema围绕这些核心设计：(1)用户表userid，name,pass,status,...(2)消息表msgid，author_id,msg,time,..(3)用户关系表relationid，following_ids,followed_ids。无论如何，架构框架清晰如下：四、cache=cash是指缓存等于使用收入cache对大型网站架构至关重要。网站响应速度是影响用户体验最明显的因素，影响响响应速度最大的敌人是磁盘I/O。无论如何，架构框架清晰如下：四、cache=cash是指缓存等于使用收入cache对大型网站架构至关重要。网站响应速度是影响用户体验最明显的因素，影响响响应速度最大的敌人是磁盘I/O。twitter工程师认为，体验好的网站平均响应时间应该在500ms左右，理想时间应该在200-300ms左右。使用cache是twitter架构的一大亮点，带cache的架构清晰如下：哪里需要cache？IO越频繁，就越需要cache。数据库是IO访问最频繁的地方。是否有必要将三个核心表放入内存？twitter的做法是将表拆分，并将访问最频繁的字段装入cache。(1)vectorcacheandrowcache即数组cache和行cache数组缓存:新发布的msgids，相关作者的ids，访问频率高，存储的cache称为vectorcache；缓存:消息正文行cache；在内存有限的情况下，vectorcache优先，vectorcache的实际命中率为99%，rowcache为95%；(2)fragmentcacheandpagecache访问twitter的用户，除了网页(web通道)，还有手机(API通道)，占总流量的80%-90%。除了mysqlcache，cache的重心将在API通道上。除了mysqlcache，cache的重点将在API通道上。手机屏幕的主体是一个屏幕和一个屏幕的新闻。你不妨把整个页面分成几个部分，每个部分对应一些/一个新闻。这些是fragment。人气高的作者，缓存页面的fragment，可以提高读取其发布消息的效率，这就是fragmentcache的使命。受欢迎的作者，人们也会访问他们的主页，这就是pagecache的使命。实际上，fragmentcache命中率为95%，pagecache命中率为40%。虽然pagecache的命中率很低，但它占用了很大的空间，因为它访问了主页。为了防止两种cache相互影响，这两种cache需要部署在不同的物理机器上。twitter的fragmentcache和pagecache都是memcached。(3)httpacelerator加速器web通道的缓存问题也需要解决。经过分析，web通道的压力主要来自搜索。在紧急情况下，读者会搜索相关信息，而不会忽视这些信息的作者是否是自己的follow。为了降低搜索压力，可以将搜索关键词与搜索内容cache联系起来。在这里，twitter的工程师使用varnish。有趣的是，varnish通常部署在webserver外层，在访问webserver之前，先访问varnish，没有相关内容；twitter的工程师将varnish放在apachewebserver的内层，因为他们认为varnish操作复杂，担心varnish崩溃导致系统瘫痪，因此，采用了这种保守的部署方式。twitter没有公开varnish的命中率，他们声称使用varnish后，全站负荷下降了50%。twitter没有公开varnish的命中率。他们声称，使用varnish后，整个站的负载下降了50%。5、防洪需要隔离twitter架构的另一个亮点是其新闻队列：隔离用户的操作平衡了流量高峰。餐厅客满时，虽然不能为新顾客服务，但不是拒之门外，而是让他们现在在休息室等待。当用户访问twitter时，接待他的是apachewebserver，而apache不能接待无限用户。2009年1月20日，奥巴马发表就职演讲，twitter流量飙升，此时该怎么办？面对洪峰，如何保证网站不崩溃？快速接受，但推迟服务。apache收到请求，转发给mongrel，由mongrel实际处理，apache腾出手来迎接下一个用户。然而，apache可以接收的用户数量总是有限的，其并发数量可以容纳apache的工作流程数量。这里没有详细研究apache的内部原理。图如下：6、数据流和控制流快速接受和延迟服务只是一个缓慢的计划，目的是防止用户收到503（serviceunavailable）。真正的抗洪能力体现在蓄洪和泄洪两个方面:(1)twitter拥有庞大的memcached集群，可以大容量蓄洪；(2)twitter自己的kestrel消息队列作为引流和泄洪的手段，传递控制指令(引流和渠道)；当洪峰到达时，twitter控制数据流，及时将数据疏散到多台机器，避免压力集中，导致系统瘫痪。以下是twitter内部流程的例子。假设有两个作者通过浏览器发送信息，一个读者也通过浏览器阅读他们的信息。(1)登录apachewebserver，apache为其分配工作流程，登录，查看id，编写cookie等；(2)上传新写的消息，将作者的id、消息等转发给mongrel，apache等待mongrel回复，以便更新作者的主页，更新新写的消息；(3)Mongrel收到消息后，分配一个msgid，将msgid和作者id缓存到vectormemcached上；同时，mongrel让vectormemcached找出作者是谁。如果缓存不被击中，它将在后端mysql中搜索，并将其纳入cache；读者ids将返回Mongrel，mongrel将msgid和短信文本缓存到rowmemcacheded；(4)Mongrel通知kestrel消息队列服务器，每个作者和读者都有一个队列(如果没有，则创建)；Mongrel将msgid放入读者队列和作者自己队列；(5)某个mongrel，它可能正在处理某个id队列，这个信息会添加到id用户的主页上；(6)Mongrel将更新作者的主页给前端等待的apache，apache将返回浏览器。洪峰和云计算没有详细说明，洪峰扛不住的时候，只能加机器。七、洪峰和云计算不细说，洪峰扛不住的时候，只能加机器。机器从哪里来？租用云计算平台公司的设备。当然，设备只需要在洪峰期租用，省钱。从push和pull的折衷可以看出，mongrel的工作流程：(1)将相关ids放入vectormemecached和rowmemecached中，即使消息发布成功，不负责存储mysql数据库；（2）将相关msgid放入kestrel消息队列，即使消息推送成功；mongrel没有以任何方式通知作者或读者，并要求他们再次提取消息。上述工作方法反映了twitter架构设计分离的概念：（1）将一个完整的过程分为独立工作的子过程，每个服务都可以负责一项工作（三层架构本身就是一种分离）；(2)多机器之间的合作，细化数据流和控制流，强调其分离；twitter业务流程的分离是事件驱动的设计，主要体现在两个方面:(1)Mongrel和mysql的分离，前者不直接干预mysql的操作，而是委托memcached全权负责；(2)上传和下载逻辑分离:指令只通过kestrel队列传递；用户一直在twitter上发布内容，twitter工作是计划如何组织内容并发送给用户的粉丝。实时是真正的挑战，现阶段的目标是在5秒内向粉丝呈现消息。实时性是一个真正的挑战。现阶段的目标是在5秒内向粉丝呈现消息。交付意味着将内容投入互联网，然后尽快发送和接收。将历时数据放入存储栈，推送通知，触发电子邮件，iOS、黑莓和Android手机都可以通知，还有短信。Twitter是世界上最活跃的信息发送机。推荐是内容产生和快速传播的巨大动力。两个主要时间轴：用户和主页。特定用户发送的用户时间轴内容。主页时间表是您在一段时间内*用户发布的所有内容。网上规则是这样的:@如果别人被@你不注意的人隔离出来，回复转发可以过滤掉。这对Twitter来说是一个挑战。1.有针对性的Pull模式时间轴。像twitter.com主页和home_timelineAPI。您要求它获取数据。许多拉请求：通过RESTAPI请求从Twitter获取数据。查询时间轴，搜索API。查询并尽快返回所有匹配的推特。2.Push模式Twitter运行最大的实时事件系统，出口带宽为22MB/秒。与Twitter建立连接，它将在150毫秒内将所有信息推送给您。Push服务簇上几乎任何时候都有100万个连接。像搜索一样发送到出口，所有的公共信息都是这样发送的。不，你做不到。(其实处理不了那么多)用户流连接。Tweetdeck和Twitter的Mac版都经过这里。登录时，Twitter会查看你的社交图片，只会推送你*的人的信息，重建主页时间轴，而不是在持久的连接过程中使用同一时间轴。查询API，Twitter收到持续查询时，如果有新的推特发布并满足查询条件，系统会将推特发送到相应的连接处。3.基于Pull(拉法)的时间轴在高观点下:短信(Tweet)通过写API传输。通过负载平衡和TFE(短信前段)，以及其他一些未提及的设施。这是一条非常直接的路径。完全提前计算主页的时间轴。短信进入时，所有的业务逻辑都被执行了。然后扇出(向外发送短信)的过程开始处理。进来的短信被放在大量的Redis集群上。在三台不同的机器上复制每个短息3份。每天都有大量的机器故障发生在Twitter。基于Flock的社交图片服务进行扇出查询。Flock维护*和*列表。Flock将社交图片返回给接受者，然后开始遍历所有存储在Redis集群中的时间轴。Redis集群有几个T内存。同时连接4K目的地。原链表结构用于Redis。假设你发短信，你有20K粉丝。在Redis集群中找出这20K用户的位置，是风扇后台过程中需要做的。然后它开始在所有这些列表中注入短信ID。所以每次写短信，都有20K次跨整个Redis集群的写入操作。存储短信ID、最初短信用户ID和四个字节，以识别短信是重新发送还是回复或回复