说三道四技术文摘-感悟人生的经典句子
说三道四 > 文档快照

磨剑三载,且看从容应对14.3万TPS的Twitter是怎样炼成的!

HTML文档下载 WORD文档下载 PDF文档下载
三年前的世界杯上,Twitter的服务随裁判哨声跌宕起伏;三年后的今天,Twitter的服务已经可以从容应对毁灭“天空之城”的魔咒,并创下每秒143199次tweet的新峰值。

记得刚接触宫崎骏老爷子的作品是在高中时代,然而当时正值青春年少外加深受灌篮高手等动画“荼毒”,对宫老爷子的《千与千寻》、《龙猫》、《魔女宅急便》、《天空之城》之流也就完全不感冒了。再次接触宫老爷子的动画则是在大学期间,记得当时熬了N个通宵把全集都过了好几遍,不得不感慨作品只有在相应的情景下才能释放价值。从这个观点上看,近日网上流传的“宫老爷子还能再战十年!”也并不为过。

NTV电视台于2013年8月2日晚第14次重播了《天空之城》,当剧情发展到男女主角巴鲁和希达共同念出毁灭之咒“Blase”时,一举将tweet发送峰值带到了每秒143199次,这个峰值高于2013日本新年33388次/秒,也高于拉登之死(5106次/秒)、东日本大地震(5530次/秒)、美国流行天后碧昂斯宣布怀孕(8868次/秒)。

毁灭之咒“Blase”摧毁了天空之城,同样也摧毁了经过充分准备的2ch,然而却铸就了当下Twitter的最新峰值。新的峰值是平均值(5700TPS)的25倍,当下用户平均每天发送的tweet是500万条左右。在峰值期间,Twitter一直保持着高可用性,对比3年前世界杯上的表现无疑有着天壤之别。近日Twitter在技术博客上公布了为什么会重铸Twitter以及新系统打造的相关细节,以下为译文:

重铸Twitter决心

当2010年人们将Twitter作为世界杯体验实时分享工具时,每一脚射门、每一次罚球、以及裁判出示的每一张红牌或黄牌产生的tweet都会对系统造成不同程度的影响,同时也会造成程序短时间内的不可用。2010世界杯期间,工程师日以继夜的工作,拼命的改善系统性能。不幸的是,这样的努力瞬间被Twitter的快速增长淹没。

有过这次经历,我们清楚了只有重新架构才能匹配网站的增长,同时让系统变得更加可靠。随后我们就开启了漫漫的重构之路,而当下Twitter已经可以从容应对类似《天空之城》重播、超级碗以及全球新年夜庆典这样的事件,新的架构不仅能弹性的应对负载,还可以帮助工程团队快速发布新特性,包括了跨设备的消息同步,Twitter cards可以让服务变得更加的丰富并拥有更多的内容,同样还带来了囊括用户和故事的搜索体验。为了实现这些,我们甚至改变了工程组织,下面就来一睹服务打造细节:

三年磨剑铸辉煌

重新架构

在2010世界杯尘埃落定后,我们审视了整个系统,并发现众多需要从根本上改善的地方:

1. Twitter曾运行着世界上最大的RoR堆栈,并将这个技术推到了一个绝对高度:那个时候,大约200个工程师在为之奋斗,它确实让Twitter渡过了一个用户爆发性时期,不管是新用户的增加,还是负载增加的处理。这个系统一度支撑了所有运作,从管理数据库、memcache连接到网站的渲染及公共API的呈现,这些全部包含在一个代码库里。它不仅让工程师的整合变的困难,同样也困扰了工程团队的管理及并行作业。

2. 存储系统的吞吐量达到了极限——之前Twitter使用的是纯粹的MySQL存储系统,进行分片,同时系统只有一个主节点。然而从系统展示的速度上来看,tweet的吞吐率确实出现了问题。这样我们就必须重建一个新的数据库以应对增长率,因为热门数据的读取已越来越频繁。

3. 取代从工程方面彻底的解决问题,我们曾尝试过投入更多主机;然而随后就发现,前端Rbuy主机并不能处理预期(根据性能)的事务量——从以往的经验看,这些主机完全可以胜任更多的事务。

4. 最后,从软件角度上看,我们发现我们一直在钻优化这个牛角尖,我们开始在性能和效率与代码库的可读性和灵活性之间做权衡。

综上所述,系统的重新架构已迫在眉睫,我们给自己定下了3个目标和挑战:

1. 我们希望打造出兼具性能、效率及灵活性的大型基础设施——我们希望能改善Twitter上的平均延时,同样我们希望通过离群值给Twitter带来统一的体验。我们希望将赖以运行的服务器降到十分之一。我们希望对故障进行隔离以避免大规模宕机——随着服务器规模的日益增大,这点就尤为重要,因为集群的变大意味着主机故障将愈来愈频繁。故障是不可避免的,所以我们希望它们发生在一个更容易控制的模式下。

2. 我们希望通过将相关的代码放到一起,以获得更清晰的边缘——我们已经感受了整片代码所带来的困扰,所以我们打造一个松耦合、基于服务的架构。我们目标是封装和模块化的最佳实践,当然是在系统级,而不是类、模块或者是包一级。

3. 最重要的是,我们希望能更快的发布特性。我们希望团队能并行的运作,每一个小组都可以在不依赖其它小组的情况下独立的完成局部决策,并将特性发布给用户。

我们POC了新的架构,虽然不是所有的努力最终都能符合上述目标,但是最起码做到了一部分并且解决了工具问题,当然,还得到了比现下更令人满意及可靠的基础设施。

备案号:鲁ICP备13029499号-2 说三道四 www.s3d4.cn 说三道四技术文摘