技术决策须要在不同限度条件下做出衡量，本文介绍了Twitter晚期应答用户大规模增长所做出的技术架构决策。原文：Twitter’s Tough Architectural Decision[1]

钻研大规模互联网利用能够学到很多货色，像Netflix这样的公司，其简单的架构不仅可能向数百万用户提供内容，而且还改善了用户体验，减少了用户粘性。

在一家小公司中，像推送告诉这样的机制能够是主代码库的一部分，并且能够在同一台机器上与应用程序的其余局部一起运行。

但在Netflix，负责推送告诉的服务器部署在寰球多个数据中心，在本文的最初有一个对于这一架构演进的具体探讨的链接。

尽管学习这些案例钻研很乏味，但大多数人依然没有在如此大的规模下工作的教训。在某些状况下，咱们更容易理解公司如何从传统的支流应用服务形式转变为投合用户体验的古代解决方案。

上面咱们以Twitter为例加以阐明。

10年前，大概在2012 - 2013年，Twitter呈指数级增长，服务1.5亿用户。

过后Twitter每秒钟解决6000条来自用户的推文。我想说的是，这依然在可控范畴之内，咱们领有高吞吐量的数据库能够解决这一写入速率。

但对于浏览推文的用户来说，就有问题了。当每个用户查问Twitter主页时，必须获取到所关注的每个人的推文组合，这就是每秒钟30万申请!!

如果间接从数据库读取，这个读取速率会让人发疯!

每个申请是什么样子？我举个例子。设想一个人关注了5000个用户，当他关上Twitter网站时，后端应用如下查问拜访数据库：

Get all the tweets ordered according to time, if it belongs to any of these 5000 users如果某个用户在这5000个用户内，获取该用户所有的推文，并按工夫排序

即便将查问限度为几条推文，依然会给数据库带来惨重的累赘。

Twitter如何解决容量问题

Twitter有两条工夫线：

  1. 用户工夫线： 用户本人所有推文的汇合，从磁盘中获取。
  2. 主页工夫线： 用户关注的人的推文的汇合，组成了用户的主页。
在设计数据库时，最简略的数据库只是将所有写操作附加到文件的开端，并在须要时读取。没有什么比简略的附加到文件中更快的了，然而，随着数据库文件的增长，从这种类型的数据库中查问某些内容将破费很长时间。\
\
为了缩小查问工夫，咱们在其中增加索引。然而增加索引将意味着写入将破费更长的工夫，因为必须在将其写入数据库之前编辑索引。但因为读取的数量将远远多于写入的数量，这是一种偏心的衡量。

同样，Twitter的浏览量也远远超过了写入量。所以他们构建了一个零碎，能够更好的为用户的主页工夫线服务。他们事后计算出所有用户的主页工夫线，并将其存储在Redis集群中。就这么简略!

当初，无论用户何时公布音讯，该音讯都会被插入每个关注者的工夫线队列中。所以如果你有5000个粉丝，你的推文就会有5000个写操作!!外加上1个数据库自身的写操作

这听起来很疯狂，但你认真想想，这是有情理的。当初能够同时为数百万用户提供服务而不须要拜访磁盘，这能够从根本上缩小提早。这个过程叫做扇出（fan-out）！

那么到目前为止，Twitter的架构是怎么的呢？

  1. 用户拜访Twitter的主页。
  2. Twitter在Redis集群中查找用户的主页工夫线。
  3. 一旦找到，就向用户间接展现。
  4. 当用户发送一条推文时，该推文会被复制到用户的所有关注者的工夫线上。

还有一些其余的细节：

  1. Twitter保护了一个图数据库[2]，其保留了用户关注关系的所有数据。当产生扇出时，扇出服务查问这个图数据库以确定将推文推送到何处。
  2. 扇出将在数据中心的3台不同的机器上进行复制，即每个用户的工夫线存储在3台不同的机器上。这是必须的，因为如果其中一台机器呈现故障，其余机器能够作为备份提供服务。
  3. 推文自身并不存储在集群中，而只存储推文ID。推文将在传递给用户的同时被检索进去。
  4. 如果用户超过30天没有登录Twitter，该用户的工夫线将不会保留在Redis集群中。对于这类用户，只有当他们返回并向主页工夫线发出请求时，才会从磁盘重构他们的工夫线。

每个用户的主页工夫线上存储的推文数量是有限度的，每次只向用户显示800条推文，这是为了管制内存应用而做出的设计决策！

名人用户的非凡解决

上述优化实用于普通用户，但名人有非凡的解决，上面咱们以Lady Gaga为例，她过后有大概3100万粉丝。

当Lady Gaga公布推文时，会产生3100万次扇出操作!!而且要复制3次!!

后果就是，有些用户可能会在Lady Gaga的推文公布5分钟后能力看到，因为他们的工夫线没有被及时更新。

这就产生了一个不太好的成果，一个能够看到Lady Gaga推文的用户会回复这条推文，这条回复将会在其余用户的工夫线中呈现，而这些用户还没有收到lady Gaga的原始推文，兴许能够称之为无头推文（Headless tweets）

为了防止这种状况，Twitter想出了一种混合办法：

  1. 如果一个人有太多的关注者，那么就不对他们的推文做扇出操作。
  2. 这些用户的推文只有在有人申请主页时才会被合并到工夫线中。

又一个简略的解决方案！

总结

钻研Twitter的整个架构是十分艰难的，尤其是当初曾经成为了大公司当前。

但从他们过来解决大规模问题的形式中学习，也能够帮忙咱们在工作的时候做出决策。即便在成千上万的中央存储一条推文听起来很荒诞，如果可能无效解决问题并且没有任何副作用，这就一个很好的解决方案！

参考
  1. Timelines at Scale[3]
  2. The Infrastructure Behind Twitter: Scale[4]
  3. Scaling Push Messaging for Millions of Devices @Netflix[5]

References: \
[1] Twitter’s Tough Architectural Decision: https://dennysam.medium.com/twitters-tough-architectural-deci... \
[2] SQL, NoSQL, Graph: A Commentary on Databases: https://softwareengineeringwk.substack.com/p/nosql-sql-graph-... \
[3] Timelines at Scale: https://www.infoq.com/presentations/Twitter-Timeline-Scalabil... \
[4] The Infrastructure Behind Twitter: Scale: https://blog.twitter.com/engineering/en_us/topics/infrastruct... \
[5] Scaling Push Messaging for Millions of Devices @Netflix: https://www.youtube.com/watch?v=6w6E_B55p0E

你好，我是俞凡，在Motorola做过研发，当初在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓重的趣味，平时喜爱浏览、思考，置信继续学习、一生成长，欢送一起交流学习。 \
微信公众号：DeepNoMind

本文由mdnice多平台公布