Twitter高并发高可用架构

2013-7-24 11:19| 发布者: joejoe0332| 查看: 1213| 评论: 0|原作者: YANGL|来自: 开源中国社区

摘要: 　　解决 Twitter的“问题”就像玩玩具一样，这是一个很有趣的扩展性比喻。每个人都觉得 Twitter很简单，一个菜鸟架构师随便摆弄一下个可伸缩的 Twitter就有了，就这么简单。然而事实不是这样， Twitter的工程副总裁 ...

高级搜索

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

Search和Pull是相反的

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

展望：

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

解耦

Tweet通过很多的方式解除关联，主要地通过彼此解耦的方式。搜索、推送、邮件兴趣组以及主页时间轴可以彼此独立的工作。
F由于性能的原因，系统曾经被解耦过。Twitter曾经是完全同步地方式的，由于性能的原因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查询，理解数据中心的拓扑应该是怎么样结构，最后建立这种类型集群。

英文原文：The Architecture Twitter Uses To Deal With 150M Active Users, 300K QPS, A 22 MB/S Firehose, And S...

12 / 2 页在本页阅读全文