解决 推ter的“问题”就像玩玩具一样，这是一个很有趣的扩展性比喻。每个人都觉得 推ter很简单，一个菜鸟架构师随便摆弄一下个可伸缩的 推ter就有了，就这么简单。然而事实不是这样， 推ter的工程副总裁 Raffi Krikorian细致深入的描述了在 推ter在可伸缩性上的演化过程，如果你想知道 推ter的如何工作—从这里开始吧。

推ter发展太快，一切转瞬即过，但 推ter已经长大了。它从一开始一个在Ruby on Rails上苦苦挣扎的小网站变成一个以服务为 核心驱动的漂亮站点，服务停掉都难得一见，很大的一个转变。

推ter现在有1.5亿全球活跃用户，300K QPS，22 MB/秒的流量，系统每天处理4亿条推特数据，用5分钟时间将Lady Gaga手尖流淌出的信息传递到她3100万个关注者。

一些需要列出来的要点:

• 推ter不再希望成为一个Web应用程序，推ter想要成为一套驱动全世界手机客户端的API，作为地球上最大的实时交互工具。
• 推ter主要在分发消息，而不是生产消息，300K QPS是在读而每秒仅有6000请求在写。
• 不对称，有数量庞大的粉丝，现在正成为一种常见情况。单个用户发送的消息有很多追随者要看到，这是一个大的扇型输出，分发可能很缓慢，推ter试图保证在5秒以内，但并不能总是达到这个目标，尤其是当名人或名人之间发推特时，这种情况越来越常见，一个可能后果是在还未看到原始消息之前接受到了回复。推ter做工作是在迎接高关注度用户所写推特读取的挑战。
• 你主页的数据储存在由800多个Redis节点组成的集群上。
• 从你关注的人及你点击的链接推ter更了解你。可以通过隐私设置的双向以下时不存在。
• 用户关心推特内容本身，但对推ter而言推特的内容与其基础设施建设几乎无关。
• 需要一个非常复杂的监控和调试系统来跟踪复杂协议栈内的性能问题。传统的遗留问题一直困扰着系统。

推ter是如何工作的？通过Raffi精彩的演讲来发现吧…

面临的挑战

• 可靠的实现150万在线用户及300K QPS（主页和搜索访问），响应慢怎么办？
• 可靠的实现是一个对所有推特的select语句，响应忙死卡死。
• 数据扇形输出的解决方案。当接收到新推特时需要弄清楚应该把它发到哪，这样可以更快速简单的读取，不要在读操作上做任何逻辑计算，性能上写要比读慢得多，能做到4000 QPS。

内部组成

• 平台服务部门负责推ter的核心基础设施的可扩展性。
  • 他们运行的东西为时间轴、微博、用户及社交网络提供服务，包括所有支撑推ter平台的系统设备。
  • 统一内外部客户使用相同的API。
  • 为数百万的第三方应用注册支持
  • 支持产品团队，让他们专注产品无系统支撑方面顾虑。
  • 致力于容量规划、构建可扩展的后端系统等工作，通过不断更换设施使网站达到意想不到的效果。
  </li>
• 推ter有一个架构师部门，负责推ter整体架构，研究技术改进路线（他们想一直走在前面）。
</ul>

Push、Pull模式

• 每时每刻都有用户在推ter上发表内容，推ter工作是规划如何组织内容并把它发送用户的粉丝。 
• 实时是真正的挑战，5秒内将消息呈现给粉丝是现阶段的目标。
  • 投递意味着内容、投入互联网，然后尽可能快的发送接收。
  • 投递将历时数据放入存储栈，推送通知，触发电子邮件，iOS、黑莓及Android手机都能被通知到，还有短信。
  • 推ter是世界上活跃中最大的信息发送机。
  • 推荐是内容产生并快速传播的巨大动力。
  </li>
• 两种主要的时间轴：用户的及主页的。
  • 用户的时间轴特定用户发送的内容。
  • 主页时间表是一段时间内所有你关注用户发布的内容。
  • 线上规则是这样的：@别人是若被@的人你未关注的话将被隔离出来，回复一个转发可以被过滤掉。
  • 这样在推ter对系统是个挑战。
  </ul> </li>
  • Pull模式
    • 有针对性的时间轴。像推ter.com主页和home_timeline的API。你请求它才会得到数据。拉请求的不少：通过REST API请求从推ter获取数据。
    • 查询时间轴，搜索的API。查询并尽可能快的返回所有匹配的推特。
    </ul> </li>
    • Push模式
      • 推ter运行着一个最大的实时事件系统，出口带宽22MB/秒。
        • 和推ter建立一个连接，它将把150毫秒内的所有消息推送给你。
        • 几乎任何时候，Push服务簇上大约有一百万个连接。
        • 像搜索一样往出口发送，所有公共消息都通过这种方式发送。
        • 不，你搞不定。(实际上处理不了那么多)
        </ul> </li>
        • 用户流连接。 TweetDeck 和推ter的Mac版都经过这里。登录的时，推ter会查看你的社交图，只会推送那些你关注的人的消息，重建主页时间轴，而不是在持久的连接过程中使用同一个时间轴 。
        • 查询API，推ter收到持续查询时，如果有新的推特发布并且符合查询条件，系统才会将这条推特发给相应的连接。
        </ul> </li> </ul>

        高观点下的基于Pull（拉取方式）的时间轴：

        • 短消息(Tweet)通过一个写API传递进来。通过负载平衡以及一个TFE(短消息前段)，以及一些其它的没有被提到的设施。
        • 这是一条非常直接的路径。完全预先计算主页的时间轴。所有的业务逻辑在短消息进入的时候就已经被执行了。
        • 紧接着扇出（向外发送短消息）过程开始处理。进来的短消息被放置到大量的Redis集群上面。每个短息下在三个不同的机器上被复制3份。在推ter 每天有大量的机器故障发生。
        • 扇出查询基于Flock的社交图服务。Flock 维护着关注和被关注列表。
        • Flock 返回一个社交图给接受者，接着开始遍历所有存储在Redis 集群中的时间轴。
        • Redis 集群拥有若干T的内存。
        • 同时连接4K的目的地。
        • 在Redis 中使用原生的链表结构。
        • 假设你发出一条短消息，并且你有20K个粉丝。扇出后台进程要做的就是在Redis 集群中找出这20K用户的位置。接着它开始将短消息的ID 注入到所有这些列表中。因此对于每次写一个短消息，都有跨整个Redis集群的20K次的写入操作。
        • 存储的是短消息的ID, 最初短消息的用户ID, 以及4个字节，标识这条短消息是重发还是回复还是其它什么东东。
        • 你的主页的时间轴驻扎在Redis集群中，有800条记录长。如果你向后翻很多页，你将会达到上限。内存是限制资源决定你当前的短消息集合可以多长。
        • 每个活跃用户都存储在内存中，用于降低延迟。
        • 活跃用户是在最近30天内登陆的推ter用户，这个标准会根据推ter的缓存的使用情况而改变。
        • 只有你主页的时间轴会存储到磁盘上。
        • 如果你在Redis 集群上失败了，你将会进入一个叫做重新构建的流程。        
        •      查新社交图服务。找出你关注的人。对每一个人查询磁盘，将它们放入Redis中。
        •      MySQL通过Gizzard 处理磁盘存储，Gizzard 将SQL事务抽象出来，提供了全局复制。
        • 通过复制3次，当一台机器遇到问题，不需要在每个数据中心重新构建那台机器上的时间轴。
        • 如果一条短消息是另外一条的转发，那么一个指向原始短消息的指针将会存储下来。
        • 当你查询你主页的时间轴时候，时间轴服务将会被查询。时间轴服务只会找到一台你的时间轴所在的机器。
        •      高效的运行3个不同的哈希环，因为你的时间轴存储在3个地方。
        •      它们找到最快的第一个，并且以最快速度返回。
        •      需要做的妥协就是，扇出将会花费更多的时间，但是读取流程很快。大概从冷缓存到浏览器有2秒种时间。对于一个API调用，大概400ms。
        • 因为时间轴只包含短消息ID, 它们必须"合成"这些短消息，找到这些短消息的文本。因为一组ID可以做一个多重获取，可以并行地从T-bird 中获取短消息。
        • Gizmoduck 是用户服务，Tweetypie 是短消息对象服务。每个服务都有自己的缓存。用户缓存是一个memcache集群 拥有所有用户的基础信息。Tweetypie将大概最近一个半月的短消息存储在memcache集群中。这些暴露给内部的用户。
        • 在边界将会有一些读时过滤。例如，在法国过滤掉纳粹内容，因此在发送之前，有读时内容剥离工作。

        高级搜索

        • 与Pull相反，所有计算都在读时执行，这样可以使写更简单。
        • 产生一条推特时，Ingester会对其做语法分析找出新建索引的一切东西，然后将其传入一台Early Bird机器。Early Bird是Lucene的修改版本，索引储存在内存中。
        • 在推特的分发过程中可能被储存在多个由粉丝数量决定的主页时间轴中，一条推特只会存入一个Early Bird机器中（不包括备份）。
        • Blender进行时间轴的跨数据中心集散查询。为发现与查询条件匹配的内容它查询每个Early Bird。如果你搜索“纽约时报”，所有分片将被查询，结果返回后还会做分类、合并及重排序等。排序是基于社会化度量的，这些度量基于转发、收藏及评论的数量等。
        • 互动信息是在写上完成的，这里会建立一个互动时间轴。当收藏或回复一条推特时会触发对互动时间轴的修改，类似于主页时间轴，它是一系列的活跃的ID，有最受喜欢的ID，新回复ID等。
        • 所有这些都被送到Blender，在读路径上进行重计算、合并及分类，返回的结果就是搜索时间轴上看到的东西。
        • Discovery是基于你相关信息的定制搜索，推ter通过你关注的人、打开的链接了解你的信息，这些信息被应用在Discovery搜索上，重新排序也基于这些信息。

        Search和Pull是相反的

        • Search和Pull明显的看起来很相似，但是他们在某些属性上却是相反的。
        • 在home timeline时：
        • 写操作。tweet写操作引发O(n)个进程写入Redis集群，n代表你的粉丝，如果是这样，处理Lady Gaga或是Obama百万粉丝的数据就得用10s的时间，那是很难接受的。所有的Redis集群都支持硬盘处理数据，但是一般都是在RAM里操作的。
        • 读操作。通过API或是网络可用O(1)的时间来找到Redis机器。推ter在寻找主页路径方面做了大量的优化。读操作可在10毫秒完成。所有说推ter主导消费机制而不是生产机制。每秒可处理30万个请求和6000 RPS写操作。
        • 在搜索timeline时：
          • 写操作。一个tweet请求由Ingester收到并有一个Early Bird机器来处理。写操作时O(1).一个tweet需要5秒的处理时间，其包括排队等待和寻找路径。
          • 读操作。读操作引发O(n)个集群读操作。大多数人不用search，这样他们可以在存储tweets上面更加有效，但是他们得花时间。读需要100毫秒，search不涉及硬盘操作。全部Lucene 索引表都放入RAM，这样比放在硬盘更加有效。 
          </ul> </li>
          • tweet的内容和基础设施几乎没什么关系。T-bird stores负责tweet所有的东西。大多数tweet内容是放在RAM处理的。如有没再内存中，就用select query将内容抓到内存中。只有在search，Trends，或是What’s Happening pipelines中涉及到内容，hone timeline对此毫不关心。
          </ul>

          展望：

          • 如何使通道更快更有效？
          • Fanout可以慢下来。可以调整到5秒以下，但是有时候不能工作。非常难，特别是当有名人tweet时候，这种情况越来越多。
          • 推ter 关注也是非常不对称的。Tweet只提供给定时间内被关注的信息。推ter更注重你的信息，因为你关注了兰斯.阿姆斯特朗，但是他并没有关注你。由于不存在互相的关注关系，所以社会联系更多是暗示性隐含性。
          • 问题是巨大的基数。@ladygaga 有3100万关注者。@katyperry有2800万。@barackobama有2300万关注着。
          • 当这些人中有人发微博的时候，数据中心需要写大量微薄到各个关注者。当他们开始聊天时候，这是非常大的挑战，而这时刻都在发生着。
          • 这些高关注度的Fanout用户是推ter最大的挑战。在名人原始微薄发出到关注用户之前，回复一直可以看到。这导致整个网站紊乱。Lady Gaga的一条微薄到关注用户需要几分钟的时间，所以关注者看到这条微薄时间是在不同时间点上。有些人可能需要大概5分钟的时间才能看到这条微薄，这远远落后于其他人。可能早期收到微薄的用户已经收到了回复的列表，而这时候回复还正在处理之中，而fanout还一直进行着所以回复被加了进来。这都发生在延迟关注者收到原始微薄之前。这会导致大量用户混乱。微薄发出之前是通过ID排序的，这导致它们主要是单调增长地，但是那种规模下这不能解决问题。对高值的fanouts队列一直在备份。
          • 试图找到解决合并读和写路径的方法。不在分发高关注度用户微薄。对诸如Taylor Swift的人不会在额外的处理，只需要在读时候，他的时间点并入即可。平衡读和写的路径。可以节约百分之10s的计算资源。

          解耦

          • Tweet通过很多的方式解除关联，主要地通过彼此解耦的方式。搜索、推送、邮件兴趣组以及主页时间轴可以彼此独立的工作。
          • F由于性能的原因，系统曾经被解耦过。推ter曾经是完全同步地方式的，由于性能的原因2年前停止了。提取一个tweet到tweet接口需要花费145微秒，接着所有客户端被断开连接。这是历史遗留的问题。写路径是通过MRI用一个Ruby驱动的程序，一个单线程的服务。每次一个独立的woker被分配的时候，处理器都会被耗尽。他们希望有能力尽可能快的去释放客户端连接。一个tweet进来了。Ruby处理了它。把它插入队列，并且断开连接。他们仅仅运行大概45-48进程/盒。所以他们只能并行处理同样多tweets/盒，所以他们希望尽可能快的断开连接。
          • Tweets 被切换到异步路径方式，我们讨论所有东西都被剔除了。

          监控

          • 办公室四处的仪表盘显示了系统在任何给定时间系统的运行状态。
          • 如果你有100万的关注者，将会要花费好几分钟到分发到所有tweets。
          • Tweets 入口统计：每天400兆的tweets。日平均每秒种5000；日高峰时每秒7000；有事件时候是每秒超过12000。
          • 时间轴分发统计：30b分发/日（约21M/分钟）；3.5秒@p50（50%分发率）分发到1M；300k 分发/秒；@p99 大概需要5分钟。
          • 一个名为VIZ的监控系统监控各个集群。时间轴服务检索数据集群数据的平均请求时间是5毫秒。@p99需要100毫秒。@p99.9需要请求磁盘，所以需要大概好几百毫秒。
          • Zipkin 是基于谷歌Dapper的系统。利用它可以探测一个请求，查看他点击的每一个服务，以及请求时间，所以可以获得每个请求的每一部分性能细节信息。你还还可以向下钻取，得到不同时间周期下的每单个的请求的详细信息。大部分的时间是在调试系统，查看请求时间都消耗的什么地方。它也可以展示不同纬度的聚合统计，例如，用来查看fanout和分发了多久。大概用了2年长的一个工程，来把活跃用户时间线降到2毫秒。大部分时间用来克服GC停顿，memchache查询，理解数据中心的拓扑应该是怎么样结构，最后建立这种类型集群。

          本文地址：http://www.oschina.net/translate/the-architecture-推ter-uses-to-deal-with-150m-active-users

          原文地址：http://highscalability.com/blog/2013/7/8/the-architecture-推ter-uses-to-deal-with-150m-active-users.html