scalability - 社交网站如何计算好友更新？

Question

社交网站可能会为用户、朋友和活动维护表格......

他们如何使用这些表以高效且可扩展的方式计算好友事件？

Answer 1

许多社交网站（如 Twitter）根本不使用 RDBMS，而是使用 Message Queue 应用程序。其中很多都是从已经存在的应用程序开始的，比如 RabbitMQ。其中一些变得足够大，他们必须大量定制或构建自己的。Twitter 正在第二次这样做。

消息队列应用程序通过为一项或多项其他服务保存来自一项服务的消息来工作。例如说服务弗兰克正在向队列 foo 发布消息。Joe 和 Jill 订阅了 Franks foo 队列。应用程序将跟踪 Joe 或 Jill 是否收到了消息，并且一旦队列的每个订阅者都收到了消息，它就会丢弃它。弗兰克发送消息并忘记了它。Joe 和 Jill 向 foo 请求消息并获取他们尚未收到的任何消息。乔和吉尔对消息做任何他们需要做的事情。也许保留它也许不会。

消息队列应用程序保证应该得到消息的每个人都能够并且将在他们请求时得到消息。发布者可以自信地发送消息，订阅者最终可以获得它们。这样做的好处是完全异步并且不需要昂贵的连接。

编辑：我还应该提到，通常这些大规模存储的东西是严重非规范化的。因此，Joe 和 Jill 可能正在存储完全相同的消息的副本。这被认为是可以的，因为它有助于将应用程序扩展到数十亿用户。

其他阅读：

1. http://www.rabbitmq.com/
2. http://qpid.apache.org/

Answer 2

社交网站的主要数据结构是图。在 facebook 上，图表是无向的（当你是某人的朋友时，他们就是你的朋友）。在 twitter 上，图表是定向的（您关注某人，但他们不一定关注您）。

表示图的两种流行方法是邻接表和邻接矩阵。

邻接列表只是图上的边列表。考虑一个具有整数用户 ID 的用户。

User1, User2
  1      2
  1      3
  2      3

这些记录的无向解释是用户 1 是用户 2 和用户 3 的朋友，用户 2 也是用户 3 的朋友。

在数据库表中表示这一点很简单。就是我们熟悉的多对多关系连接表。查找特定用户的朋友的 SQL 查询很容易编写。

既然您知道特定用户的朋友，您只需将这些结果加入更新表。此表包含由用户 ID 索引的所有用户更新。

只要所有这些表都被正确索引，您就可以很容易地设计高效的查询来回答您感兴趣的问题。

Answer 3

特拉维斯为此写了一篇很棒的文章，

Rails 和 pfeed 上的活动日志和好友动态

Answer 4

对于小规模来说，在 users.friends 和 users.events 上进行连接和查询缓存可能很好，但随着朋友和事件的增长，速度会很快减慢。您还可以尝试基于事件的模型，其中每次用户创建事件时，都会在连接表中创建一个条目（可能称为“friends_events”）。因此，每当用户想要查看他们的朋友创建了哪些事件时，他们可以简单地在他们自己的 id 和 friends_events 表之间进行连接并找出答案。通过这种方式，您可以避免抓住所有有朋友的用户，然后将他们的朋友加入事件表。