facebook 如何实现写入可扩展性？ [关闭]答案

【问题标题】：How does facebook achieve write scalability? [closed]facebook 如何实现写入可扩展性？ [关闭]
【发布时间】：2013-11-06 18:45:10
【问题描述】：

我研究了 facebook 发表的一篇关于 memcached 的论文。在那里我发现他们有一个主区域，而所有其他地理区域都是奴隶。

我想知道在如此高负载的情况下，facebook 如何处理主区域的写入可扩展性？
为什么只有一个master region？
除了手动分片来实现写入可扩展性，还有哪些其他选择？

【问题讨论】：

我有兴趣知道主区域是如何处理的？就像他们维护了多少副本一样！显然，他们不能有一个服务器作为主服务器......他们必须有一个主服务器集群和某种划分写入请求的方式。
我刚刚发现人们每天在 Facebook 上分享超过 47.5 亿条内容，例如状态更新、墙贴、照片、视频和 cmets，Facebook 表示。他们每天还“点赞”超过 45 亿条内容，发送超过 100 亿条消息。

标签： php mysql facebook memcached scalability

【解决方案1】：

Facebook 西雅图办事处前负责人 Ari Steinberg 参加了我在华盛顿大学的数据库课程，讨论 Facebook 如何扩展他们的服务器。

据我所知，Facebook 将所有写入请求都发送到主服务器，然后将该信息传播到其他地区的服务器。这是因为写请求的数量远小于读请求的数量，所以一组服务器能够处理所有的写请求。（想想 Facebook 的典型用法……阅读帖子，阅读帖子，也许偶尔发表评论或留言）。

这意味着，如果您发出读取请求并且您的请求被发送到一组不是主组的服务器，那么您有可能正在查看旧帖子。如果有人发布了一个新状态并且主服务器没有将帖子转发到您正在读取的服务器，它不会知道这个写入并给您旧数据。 Facebook 重视快速页面加载而不是最准确的数据，因此他们使用这种设计。大多数用户永远不会意识到他们正在查看旧信息，因为他们不知道新帖子的存在。

注意：我相信他们提到当您尝试阅读自己的作品时，他们有一个特殊情况。如果您更新个人资料图片，然后刷新页面，他们将确保您的请求被发送到主服务器，以便您获得最新信息。如果您更新您的个人资料图片，然后在刷新页面时看到您的旧图片，那么用户体验会很差。但是，如果其他人查看您的个人资料，则显示什么图片并不重要，因为用户不知道您已经更新了它。

【讨论】：

点赞应该会产生相当数量的写入请求，重要的是它们的存储方式
我认为存储空间不是问题。每个数据中心都存储了所有信息。问题是每个数据中心每秒可以处理的请求数，以及最小化返回请求所需的时间。即使有点赞，阅读量仍然是>>>点赞数。然而，他们也有可能以不同的方式处理喜欢和其他类似的东西，因为它们对准确来说不太重要。
我还记得 Ari 提到过，对于有大量点赞的帖子，点赞数实际上是非常不准确的。不，不记得为什么会这样。可能是因为like count的准确性不是很重要，所以他们不会花很多资源去担心它的准确性。
我有兴趣知道主区域是如何处理的？就像他们维护了多少副本一样！显然，他们不能有一个服务器作为主服务器......他们必须有一个主服务器集群和某种划分写入请求的方式。
要回答这个问题，您应该研究分片数据库。基本思想是他们将对请求的一些唯一标识符进行哈希处理，并使用它来确定将请求发送到哪个服务器。我相信在 Facebook 的早期，他们使用您的学校来确定将请求发送到哪个服务器（所有哈佛请求都发送到一个服务器，所有杜克请求发送到另一个服务器，依此类推）。今天他们可能使用帐户 ID 或类似的东西来对请求进行排序。