Twitter高并发高可用架构

一些需要列出来的要点:

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

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

面临的挑战

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

内部组成

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

Push、Pull模式

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

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

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