# 为什么 Facebook，Digg 和 Twitter 很难扩展？ > 原文： [http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html](http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html) 实时社交图（人，地方和事物之间的连通性）。 这就是为什么要扩展 Facebook 很难[的原因，Facebook 技术副总裁 Jeff Rothschild](/blog/2009/10/12/high-performance-at-massive-scale-lessons-learned-at-faceboo-1.html) 说。 像 Facebook，Digg 和 Twitter 这样的社交网站要比传统网站难于扩展。 这是为什么？ 为什么社交网站比传统网站更难扩展？ 让我们找出答案。 传统网站比社交网站更易于扩展，原因有两个： * 他们通常仅访问自己的数据和公共缓存的数据。 * 一次只有 1-2％的用户在该站点上处于活动状态。 想象一下像 Yahoo 这样的大型网站。 当您来到 Yahoo 时，他们可以一键获取您的个人资料记录，足以为您建立网站视图。 使用[分布式哈希方案](http://highscalability.com/blog/2009/8/5/anti-rdbms-a-list-of-distributed-key-value-stores.html)基于单个记录扩展系统相对简单。 而且由于一次只有很少一部分人同时访问该站点，因此只需较少的 RAM 缓存即可处理所有活动用户。 现在想想在 Facebook 上发生了什么。 假设您有 200 个朋友。 当您打您的 Facebook 帐户时，必须同时**收集所有 200 个朋友的状态**，以便您可以查看对他们有什么新变化。 这意味着需要同时发出 200 个请求，需要将答复合并在一起，需要联系其他服务以获取更多详细信息，所有这些都需要合并在一起并通过 PHP 和 Web 服务器发送，因此您可以看到 Facebook 页面在合理的时间内。 天啊。 这里有几个含义，特别是考虑到在社交网站上一次有大量用户同时在系统上（这是社交部分，人们闲逛）： * 所有数据始终处于活动状态。 * 由于每个人都已连接，因此很难对这种系统进行分区。 * 所有内容都必须保存在 RAM 缓存中，以便可以尽快访问数据。 分区意味着您希望找到某种方法将常用数据聚类在一起，以便可以更有效地对其进行访问。 由于数据的互连性，Facebook 没有找到任何可行的集群方案。 因此，Facebook **不会对数据进行分区和非规范化，而是保持数据规范化，并在数以千计的数据库中随机分配**数据。 这种方法需要非常快的缓存。 Facebook 使用 [memcached](http://highscalability.com/blog/category/memcached) 作为其缓存层。 所有数据都保存在缓存中，并且他们对 memcached 进行了大量修改，以加快数据传输速度并帮助其处理更多请求（所有信息都回馈社区）。 他们的**缓存层服务每秒提供 1.2 亿个查询**，这是站点的核心。 问题是 memcached 难以使用，因为它需要程序员的配合。 腐败也很容易。 他们开发了一个复杂的系统，以使缓存层中的数据与数据库保持一致，即使跨多个分布式数据中心也是如此。 请记住，它们是在此处缓存用户数据，而不是 HTML 页面或页面片段。 考虑到他们的数据更改量，将很难使页面缓存起作用。 我们在 Digg 看到了类似的问题。 例如，每当凯文·罗斯（Kevin Rose）挖掘链接时，Digg 就必须处理将更新发送给 [40,000 个关注者](http://highscalability.com/blog/2009/2/14/scaling-digg-and-other-web-applications.html)的问题。 Digg 和我认为 Twitter 也采取了与 Facebook 不同的方法。 Facebook 采用**按需拉动**方法。 要重新创建页面或显示片段，他们需要运行完整的查询。 为了确定您的朋友中是否添加了一个新的喜爱的乐队，Facebook 实际查询了所有朋友，以查找最新消息。 他们可以摆脱这种情况，但是由于其强大的基础架构。 但是，如果您曾经想过**，为什么 Facebook 的朋友数限制为 5,000 个用户**，这就是为什么。 在某一点上很难实现“按需”规模。 找出新功能的另一种方法是**随推即用**模型。 在此模型中，当用户进行更改时，会将其推送到所有相关用户，并且更改（以某种形式）与每个用户一起存储。 因此，当用户要查看其更新时，他们需要访问的就是他们自己的帐户数据。 无需轮询所有朋友的更改。 有了安全性和权限，要确定谁应该看到更新，可能会非常复杂。 如果用户拥有 200 万关注者，那么它的速度也可能令人惊讶地慢。 还有一个重复的问题。 存储了大量重复数据（或引用），因此这是一种非规范化方法，可能会导致一些一致性问题。 例如，在生产或使用数据时是否应征得许可？ 或者，如果数据已经被复制后又被删除了怎么办？ 尽管所有这些一致性和重复性问题都很有趣，但``推动变革''似乎为真正的追随者提供了更具可扩展性的方法。 推动所有更改确实需要很多工作，但是可以由作业排队系统处理，因此工作可以分布在整个集群中。 随着我们拥有越来越多的人，越来越多的相互联系，越来越快的变革以及对实时消耗所有这些的渴望，挑战将越来越大。 我们距离能够应对这个勇敢的新世界还有很长的路要走。 关于社交网站的整个可伸缩性问题的非常不错的概述。 但是，我确定下一个要紧推模型，特别是在经典聊天应用程序之外使用 XMPP 之类的协议。 感谢您的精彩文章。 我一直想知道 Facebook 如何摆脱庞大的互连数据库。 “他们的缓存层服务每秒提供 1.2 亿个查询，这是站点的核心。” 您可以为此找到参考吗？ 在他的演讲中吗？ 如果是这样，我会去看的。 网络行业可以向金融行业学习。 多年来，股票市场一直在以非常低的延迟向大量节点传递消息的股价信息。 有多种商业产品，例如 Tibco Rendezvous，都提供了这样的消息总线。 那时，向 40,000 个关注者（可能驻留在更少的分区上）发布更新不是一个真正的挑战。 Facebook 的限制也反映出我们注意力经济的自然限制：没有人可能知道（或保留）约 5000 名其他人的一切。 只要 Web 体系结构只需要围绕我们弱小的人脑扩展，我们就处于相当安全的领域。 我喜欢这篇文章，非常有帮助。 分布式系统和缓存始终是我感兴趣的主题：） 好帖子。 嗯..有趣的点。 涉及到影响可访问量如此大的站点的可伸缩性的一些重要点。 你好 我们最近有一篇文章涉及 OSN 的扩展，并且我们处理了 您提到的一些问题-包括分区问题。 可以在以下网站找到该论文：http://bit.ly/18Gqmx 请随时与作者联系以获取更多信息。 干杯， 欢呼 伟大的话题和问题的解释。 如果您对解决此问题的绝佳方法感兴趣，请查看附件链接和网络研讨会。 http://budurl.com/oct15wbnr 不错的发人深省的文章。 我想我有一个想法如何处理“同时收集所有 200 个朋友的状态”。 根本不要。 人们不太可能希望甚至无法一次查看全部大小的数据，因此请以不占优势的块形式提供数据。 不错的文章，但您错失了 5,000 个用户限制。 我记得前一段时间看过一位 Facebook 工程师的演讲（我认为那是 Yahoo Brickhouse 的 Jeff Hammerbacher 的演讲），他说限制是“产品决定”，而不是工程决定。 他还说，粉丝专页使用的样式与普通人完全一样，那里没有限制。 因此，基本上，5,000 个朋友的限制是完全任意的，明天他们可以毫无问题地将其删除。 有趣且很有见地。 从很长时间以来，我一直在寻找可扩展性问题的答案，甚至在博客上都对此发表了看法，但这是我遇到的最好的解释。 很棒的帖子。 当我们处理扩展这些大型站点的软件架构时，这真的变得很有趣：) 首先，facebook 和 dig 使用的方法是最好的方法。 然而，他们寻找更优化的解决方案的努力可能会触发数据管理的新发明。 如您所知，技术是在战争中最发达的，这就是在竞争激烈的市场中为金钱而战：) 是的，我为 Facebook，Flickr，Digg 等购买此产品。 它们具有相对简单的数据结构和非常小的数据库。 他们最近声称，在迈克尔·杰克逊（Michael Jackson）事件期间，他们每秒最多有 5,000 条消息。 即使我很慷慨地说，他们平均每秒平均连续发送 5,000 条消息，但一年仍然只能收到 20Tb 的消息。 当然他们有很多要求，但是要提取的数据并不多。 如果他们只愿意执行某种形式的实时推送而不是让人们投票，那么他们发现的 api 调用也可能会大大减少。 与 Facebook 相比，Twitter 并没有太多的借口来应对近期的所有故障。 帕特里克 听起来是时候将某个人的社交网络直接构建到硬件中了。 也许是社交网络 ASIC？ 极端情况下的社交网络问题最终与神经网络面临的经典问题以及其他大规模并行计算问题（互连的阶乘扩展）密切相关。 每个附加节点 N 将潜在连接数增加 N-1 倍。 在大脑中，典型的神经元与大约 10,000 个接收器和 10,000 个发送器连接，因此乘数仅约为 10,000，而不是数十亿。 因此，Facebook 限制的数量级相似。 有趣的是，分组交换网络比硬交换具有更好的可伸缩性，因此，除非实现了类似于网络的总线层，否则 ASIC 可能不是走的路。 那是我一直在研究的设计。 生物神经网络还通过不修剪不带明显信号的互连部分解决了这一问题，而“表决权”得不到定期使用的神经元（它们的输出并未受到任何接收神经元的高度加权）实际上会死亡。 可悲的是，用户不在乎并且不容忍由可伸缩性问题（或缺乏可伸缩性问题）引起的可见错误。 非常有趣的文章。 谢谢！