推特的关注者是怎么排序的呢（推特正在关注和关注者区别）

2023-02-03twitter引流推广静态 HTML 文章

杰里米·贝赞格在Unsplash上拍摄的照片

研究大规模运行的网络应用程序可以教会我们很多东西。像 Netflix 这样的公司的复杂架构不仅使他们能够为数百万用户提供内容，而且还改善了用户体验并增加了参与度。

例如，在一家小公司中，推送通知之类的机制可以是主代码库的一部分，并且可以与同一台机器中的应用程序的其余部分一起运行。

但在 Netflix，他们在全球拥有多台服务器，负责推送通知。我附上了一个链接，该链接指向正在详细讨论架构的谈话，在时事通讯的末尾。

虽然学习这些案例研究很有趣，但大多数人仍然没有进行如此大规模的工作。在某些情况下，了解公司如何从旧的主流应用程序服务方式转变为现代解决方案以迎合用户体验会更容易。

让我们以推特为例！

10 年前，也就是 2012-13 年左右，Twitter 呈指数级增长并为 1.5 亿用户提供服务。

他们每秒处理来自这些用户的大约 6000 条推文。我会说，这仍然是可控的。我们拥有可以处理它的具有高吞吐量和写入速度的数据库。

但是对于阅读推文的用户会出现问题。每个用户都查询 Twitter 的主页，并且必须为他们提供来自他们关注的每个人的推文组合。结果是 300k 请求/秒！！

直接从数据库中进行的读取量非常大！

这些请求中的每一个是什么样的？让我给你一些观点。想象一个人正在关注 5000 个用户。他们打开 Twitter 网站。后端使用如下查询访问数据库

获取所有按时间排序的推文，如果它属于这 5000 个用户中的任何一个

即使我将查询限制为几条推文，这仍然会给数据库带来沉重的负担。

Twitter 如何解决他们的扩展问题

Twitter有2个时间线

用户时间线：这是您所有推文的集合。这是从磁盘中获取的。主页时间线：这是您关注的人的推文集合，基本上是您的主页。

在设计数据库时，蕞简单的数据库就是将所有写入内容附加到文件末尾，并在需要时读取它。没有什么比简单地附加到文件更快的了。但是随着数据库文件的增长，从这种类型的数据库中查询一些东西需要很长时间

为了减少查询时间，我们为其添加索引。但是添加索引意味着您的写入将花费更长的时间，因为您必须在将索引写入数据库之前对其进行编辑。但是由于您的读取次数将远远超过写入次数，因此这似乎是一个公平的权衡。

同样，Twitter 的读取量远大于写入量。所以他们想出了一个可以更好地为用户的家庭时间线服务的系统。他们预先计算了所有用户的家庭时间线并将其存储在 Redis 集群中。就如此容易！

现在，每当用户发推文时，该推文都会插入到每个关注者的时间线队列中。因此，如果您有 5000 个关注者，那么您的推文将有 5000 条评论！！加 1 写入数据库本身

刚开始这听起来像是一个疯狂的想法，但当您考虑它时，它是有道理的。您现在可以立即为数百万用户提供服务，而无需敲击磁盘，这可以从根本上减少延迟。这个过程称为扇出！

那么到目前为止，Twitter 架构看起来如何？

用户访问 Twitter 的主页。Twitter 在其中一个 Redis 集群中查找用户的主页时间线。一旦找到它，它将按原样显示给用户。当用户发送推文时，该推文将在用户关注者的所有时间线上复制。

对此的一些额外细节

Twitter 维护一个图形数据库，其中包含有关谁关注谁的所有数据。当扇出发生时，扇出服务会查询此图数据库以确定将推文推送到何处。此扇出在数据中心的 3 台不同机器上复制，即每个用户的时间线存储在 3 台单独的机器中。这是必需的，因为如果其中一台机器发生故障，其他机器可以为流量提供服务。推文本身不存储在集群中。仅存储推文 ID。在将推文传送给用户的同时检索推文。如果您在 Twitter 上闲置超过 30 天，您的时间线将不会出现在 Redis 集群中。对于这样的用户，他们的时间线是在他们返回并向主时间线发出请求时从磁盘重建的。