Twitter高并发高可用架构.docxVIP

解决 Twitter的“问题”就像玩玩具一样，这是一个很有趣的扩展性比喻。每个人都觉得 Twitter很简单，一个菜鸟架构师随便摆弄一下个可伸缩的 Twitter就有了，就这么简单。然而事实不是这样， Twitter的工程副总裁RaffiKrikorian细致深入的描述了在 Twitter在可伸缩性上的演化过程，如果你想知道 Twitter的如何工作—从这里开始吧。Twitter发展太快，一切转瞬即过，但 Twitter已经长大了。它从一开始一个在Ruby on Rails上苦苦挣扎的小网站变成一个以服务为核心驱动的漂亮站点，服务停掉都难得一见，很大的一个转变。Twitter现在有1.5亿全球活跃用户，300K QPS，22 MB/秒的流量，系统每天处理4亿条推特数据，用5分钟时间将Lady Gaga手尖流淌出的信息传递到她3100万个关注者。一些需要列出来的要点: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模式有针对性的时间轴。像主页和home_timeline的API。你请求它才会得到数据。拉请求的不少：通过REST API请求从Twitter获取数据。查询时间轴，搜索的API。查询并尽可能快的返回所有匹配的推特。Push模式Twitter运行着一个最大的实时事件系统，出口带宽22MB/秒。和Twitter建立一个连接，它将把150毫秒内的所有消息推送给你。几乎任何时候，Push服务簇上大约有一百万个连接。像搜索一样往出口发送，所有公共消息都通过这种方式发送。不，你搞不定。(实际上处理不了那么多)用户流连接。TweetDeck和Twitter的Mac版都经过这里。登录的时，Twitter会查看你的社交图，只会推送那些你关注的人的消息，重建主页时间轴，而不是在持久的连接过程中使用同一个时间轴。查询API，Twitter收到持续查询时，如果有新的推特发布并且符合查询条件，系统才会将这条推特发给相应的连接。高观点下的基于Pul