Timeline at Scale in Twitter

link: https://www.infoq.com/presentations/Real-Time-Delivery-Twitter @ 2013

http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html


twitter timeline 整体架构如下图:

timeline-at-scale-in-twitter.png

按照功能分成了很多services, 每个service由不同的service group来管理:Timeline Service, Tweet Service, User Service, Social Graph Service, 这些service可以说是见名知意。

这些服务基本和对外提供的没有太大差别,每个service之间会相互调用,之间不需要考虑扩展性问题,但是需要做好容量规划。

这篇文章是在2013年写的,但是我觉得基本架构上没有太多变化,可能的变化最多是集中在social graph管理上,使用机器学习来更加精准地为用户提供信息。

twitter已经远不是将自己定位成为一个web app, 而是想通过一些系列的API集合,可以服务于全球移动客户端,将自己打造成为最大的实时消息平台。当时twitter timeline 指标如下:

在实时性上,tweet从发出到所有followers收到,整个过程大部分在5s以内。这个时间和followers的数量相关,对Lady Gaga这种东西31M粉丝来说,延迟会到5m.

我理解对于twitter当前系统最大的挑战性,一方面在于是否可以更加地快速信息流动,另外一方面是否可以更好地观测和监控每个services以及整个系统。我记得Raffi在talk里面讲到了,他们会做一个bot不断地发送信息以及接受消息,一旦出现问题就会报警。


Push Me Pull Me

我记得在talk的slide里面将timeline分为4个维度

  pull push
targeted timeline/twiter.com user/site streams, mobile push
queried search api track/follow streams

主要有两个类型的timeline, 一个是用户自己发的,一个是自己关注的。

push是通过http长连接来实现的,延迟大约在150ms, 1m个socket connections.


High Level For Pull Based Timelines

tweet一旦写入queue之后就ack, 这个过程是同步行为。从queue到剩余的系统就是异步行为包括:创建索引用于检索,放入redis用于user timeline, 写入firehose用于推送


High Level For Search

另外一篇 文章 里面谈到了twitter search system. 这里再补充一些细节:


Search And Pull Are Inverses

Raffi在talk里面花了一点时间来讨论两者的差异性和相似性,算是架构上的总结吧。这个总结可以用来解决high fanout的问题。

high fanout是因为名人产生的,他们有很多的粉丝。这个问题的后果有两个:1. 延迟 2. 乱序。可以看看当时fanout有多大量,当然这些名人已经不止这个量级了。

Problem is for large cardinality graphs. @ladygaga has 31 million followers. @katyperry has 28 million followers. @justinbieber has 28 million followers. @barackobama has 23 million followers.

timeline-at-scale-ts.png

根据上面一节的分析,Search/Pull可以认为是逆操作,所以对于high fanout tweet, 可以使用search不是pull模型。这样taylor swift发推就不是问题了。

Trying to figure out how to merge the read and write paths. Not fanning out the high value users anymore. For people like Taylor Swift don’t bother with fanout anymore, instead merge in her timeline at read time. Balances read and write paths. Saves 10s of percents of computational resources.


Monitoring