作者：Scott Shi

简介

11月13日，马斯克为Twitter做了超过1000个RPC来渲染用户的主页时间线而道歉。乍一看，如此高的RPC数量似乎很荒谬。今天，Twitter为2.6亿月度活跃用户提供服务，并能以接近实时的方式进行。为了解决在亚秒级延迟下的大规模采用，Twitter开创了许多解决方案，包括Apache Storm、Heron、DistributedLog和Aurora；是Scala的主要贡献者，包括finagle RPC框架，以及lambda架构、Snowflake ID和Segcache等创新。那么，为什么像Twitter这样一个创新的全球性公司需要这么多调用来获取用户的时间线数据呢？

Twitter所面临的问题让我们想起了目前Web3的成长之痛：开发人员往往被迫逐一串行调用许多API，以获得用于组装业务逻辑的数据。这导致了不可靠和不可预测的性能，即使是最简单的用例，如获取用户的交易历史。而在增长方面，前10名区块链的交易在两年内翻了100倍。在图1中，我们展示了每秒推文量（2006-2013年，蓝色）和每秒Web3交易量（2017-2022年，红色，不包括非用户交易）的对比。如果Web3继续沿着图中描绘的轨迹发展，那么今天的大多数Web3数据基础设施解决方案将没有能力处理这种增长。

图1：推文和Web3前10名链之间的早期写入流量QPS比较。

在这篇博文中，我们强调了Web3可以从Twitter的规模解决方案中学习到的东西。具体来说，我们讨论了以下几点：

• 我们概述了Twitter的时间线基础设施之旅，认为他们目前的架构对于特定的用例确实是有意义的，并得出结论，一些批评（例如Elon Musk最近在推特上为渲染主时间线的大量RPC道歉）可能是错误的。
• 我们深入研究了Twitter和Web3之间的技术相似性，并探讨了前者的解决方案如何有利于后者的解决方案。
• 我们分析了当前Web3的增长趋势，以及现有的高性能数据基础设施解决方案的缺乏，并得出结论，如果我们想支持实时的Web3数据访问，就需要进行重大的升级，以及ZettaBlock解决方案如何帮助开发者减少70%的开发时间并提高10倍的性能。

推特的数据基础设施之旅

一开始，Twitter是用Vanilla MySQL开始的。这很快就成了一个问题，因为在最初的几年里，推文的数量同比增长了10倍。从2007年到2012年，Twitter的月活跃用户从几千人增长到超过1.38亿人。已知的水平和垂直分片的智慧无法为Twitter提供处理带给平台的高水平流量的性能，特别是在渲染主时间线方面。

时间线是Twitter的主要平台功能之一。一般来说，Twitter的时间线有两个主要操作，列举如下：

1. 写作路径：这个路径是为用户发布Tweet时使用的。在2012年，Twitter平均每秒钟处理4600次写请求，或在高峰期处理12000次RPS。
2. 读取路径：这条路径是为用户请求他们的时间线。在2012年，Twitter每秒处理约30万个读取请求。

为了更好地理解Twitter是如何渲染时间线的，让我们深入了解图2所描述的渲染流程。当一个Twitter用户今天发布一条推文时，Twitter首先将其写入Manhattan，这是一个分布式的键值数据库，用于存储用户的推文、直接信息、账户细节等。这条推文会在时间线缓存中向该用户的所有追随者扩散。虽然这增加了写入放大率，从每秒4600次请求增加到每秒345000次请求，但它也大大减少了用户的读取延迟。因此，时间线渲染没有在关注者和推文之间做一个连接表，而只是从一个表中获取缓存中的推文。这些扇出操作通常在5秒内完成。通过分配被写入的数据，系统通过移除表的连接，在超增长中存活下来。因此，读取延迟被提高到几百毫秒，这是在99%的范围内。

图2：Twitter的时间线渲染流程。请注意，时间线中的每条推文至少需要一个RPC。

前面提到的渲染流程可能对绝大多数用户来说是足够的（在大多数情况下，写入放大率<100），但 “超级枢纽用户”呢？超级枢纽用户是指拥有许多追随者的用户（几十到几百万）。所描述的扇出模式，在超级枢纽用户的情况下，可以被放大1.2亿倍以上 这就是为什么在Twitter的早期，有专门为贾斯汀-比伯准备的服务器机架。为了满足超级中枢用户的需求，使用了一项名为Earlybird的特殊服务。通过Earlybird，对超级中心和普通用户的推文进行不同的提取，并分别进行处理。这个过程在下面的图3中描述。

图3：左边描述的是Twitter用户的混合时间线的抽象图，右边描述的是相应的阅读SQL。

既然我们已经描述了提供实时Tweet时间线背后的复杂性，就很清楚为什么单条时间线的渲染需要许多RPC。例如，对于一个只有100条推文的时间线，RPC调用很容易超过1000次，因为仅仅获取一条推文就需要多次RPC调用。这个解决方案乍一看可能并不直观，但这是一个刻意的权衡，为终端用户提供优化和可预测的读取性能。

Twitter实施的最终结果是非常积极的：延迟的第99百分位数只有大约几百毫秒。在过去的10年里，这种基础设施被证明是可靠的，可以处理Twitter流量的超速增长，而没有发生重大变化。

请注意，我们忽略了Twitter时间线的一些其他方面，包括评分、排名和水作用。关于这方面的更多细节，请看本帖末尾列出的参考文献。

Web3和Twitter数据的相似之处

图4：Twitter和Web3数据的相似性

Twitter和Web3生态圈之间有很多相似之处：

1. Web3自然是一个社交图谱，推文类似于交易，而回复类似于日志。这在图4中得到了描述，图中比较了顺序的时间线渲染和顺序的区块链区块。
2. Web3协议和Twitter存在超级枢纽效应。最受欢迎的NFT平台的交易量比第10个平台多1000倍。
3. Web3和twitter都是开放平台，对所有用户可见，并允许某些API访问。

如果我们再放大一点，Twitter和Web3之间有更多的数据访问模式的相似之处：

1. 读取量大，但每条记录都非常小。在EVM链上，日志和事务的平均大小只有几KB。
2. 最近的数据会被更频繁地浏览，其中大部分的浏览来自于发布后的前几个小时。
3. 数据在很短的时间内是不可改变的。链上数据可以通过reorg对最新的区块进行还原。同样地，现在的用户可以在发布后的有限时间内编辑推文。

Web3可以从Twitter的架构中学到什么

与2020年早期相比，前10名区块链的交易量已经增加了近100倍。Web3数据基础设施的现状类似于2008年左右的早期Twitter时代，当时大部分流量依赖于不同供应商的水平分片数据库。因此，随着Web3的不断发展，现有的Web3数据基础设施将很难提供对数据的高性能访问。

Twitter的扇出服务就是把相关数据同时放在同一个地方（如内存）。因此，当一个请求到来时，系统可以很容易地在一个地方找到相关的数据，这导致数据已经被预处理并准备使用。这使得系统具有可扩展性，并具有可预测的性能。

遵循当前现状的Web3应用程序缺少一个重要的组成部分来有效地聚合相关数据。具体来说，开发人员必须一个一个地调用API来获取数据。这导致了不可靠和不可预测的性能，即使是最简单的用例，如获取用户的交易历史（如图5所示）。

图5：目前的Web3应用程序如何需要串行调用许多不同的API，即使是简单的事务聚合。

由于所有的Web3数据都是公开的，ZettaBlock已经建立了一个最先进的数据基础设施，为所有的Web3开发者处理扇出部分。一个应用程序的开发者只需要指定他们想通过一个API查询哪些相关数据，并让ZettaBlock汇总所有相关数据。这在图6中得到了描述。通过使用ZettaBlock，开发时间和API延迟分别减少70%和90%。请看我们的演示，https://demo.zettablock.dev/。更多的技术细节将在未来分享。

图6：与图5相比，ZettaBlock将多个Web3数据集抽象为一个单一的、用户友好的、高效的API。

总结

在这篇博文中，我们剖析了Twitter的架构，并将其数据模型与Web3进行了比较，发现了许多相似之处。如果我们能从中得到一个信息，那就是许多现有的Web3数据基础设施解决方案，就像Twitter的早期一样，将无法跟上未来的数据需求。

这就是我们建立ZettaBlock的原因。ZettaBlock是一个全栈式的Web3数据基础设施平台，提供实时、可靠的API和分析，在几分钟内为你的应用程序提供动力。前面提到的扇出过程（将相关数据同时放在同一个地方）只是ZettaBlock上提供给开发者和企业的众多功能之一。我们得到了Polygon、Crypto.com、Circle等领先的web3公司的信任。我们的愿景是成为web3数据基础设施的首选平台。

参考文献

1. 规模化的时间线：https://www.infoq.com/presentations/Twitter-Timeline-Scalability/
2. Twitter如何使用redis来扩展105TB的内存：http://highscalability.com/blog/2014/9/8/how-twitter-uses-redis-to-scale-105tb-ram-39mm-qps-10000-ins.html
3. Twitter使用什么数据库？https://scaleyourapp.com/what-database-does-twitter-use-a-deep-dive/
4. Twitter的数据存储和处理: https://ankush-chavan.medium.com/twitter-data-storage-and-processing-dd13fd0fdb30#:~:text=That%20equals%20to%2084,time%20the%20request%20is%20made