Digg 建筑 · HighScalability 中文示例

# Digg 建筑 > 原文： [http://highscalability.com/blog/2009/4/4/digg-architecture.html](http://highscalability.com/blog/2009/4/4/digg-architecture.html) **更新 4：**：[由 Joe Stump 介绍 Digg 的 IDDB 基础结构](http://blog.digg.com/?p=607)。 *IDDB 是一种在多个存储服务器之间分区索引（例如整数序列和唯一字符索引）和实际表的方式（目前支持 MySQL 和 MemcacheDB，后面还会有更多内容）。* **更新 3：**：[扩展 Digg 和其他 Web 应用程序](http://highscalability.com/scaling-digg-and-other-web-applications)。 **Update 2：**： [Digg 的工作方式](http://blog.digg.com/?p=168)和 [Digg 的实际工作方式](http://blog.digg.com/?p=177)（佩戴耳塞）。直接从 Digg 的博客带给您。在跟踪系统中的请求时，对 Digg 架构的主要元素进行了非常简洁的解释。我已经使用新信息更新了此配置文件。 **更新：** [Digg 现在每月获得 2.3 亿以上的页面浏览量和 2600 万独立访问者-流量，这需要进行重大内部升级](http://www.readwriteweb.com/archives/digg_townhall_2_wrapup.php)。 Digg 的超过 2200 万名着急信息的用户和 2.3 亿页面访问量所产生的访问量，可能会毫无疑问地将网站直接撞入其 CPU，内存和带宽限制。 Digg 每月如何处理数十亿个请求？网站：http：//digg.com ## 信息来源 * [Digg 的工作原理](http://blog.digg.com/?p=168)作者 Digg* [Digg.com 如何使用 LAMP 堆栈向上扩展](http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9017778)* [Digg PHP 的可伸缩性和性能](http://www.oreillynet.com/onlamp/blog/2006/04/digg_phps_scalability_and_perf.html) ## 平台 * 的 MySQL* 的 Linux* 的 PHP* Lucene* 蟒蛇* [APC PHP 加速器](http://us.php.net/apc)* [MCache](http://www.mohawksoft.org/?q=node/8)* [Gearman](http://www.danga.com/gearman/) -作业调度系统* [MogileFS](http://www.danga.com/mogilefs/) -开源分布式文件系统* 阿帕奇* Memcached ## 统计资料 * 从 2004 年末开始，当时只有一台运行 Apache 1.3，PHP 4 和 MySQL 的 Linux 服务器。 4.0 使用默认的 MyISAM 存储引擎* 超过 2200 万用户。* 每月超过 2.3 亿的页面浏览量* 每月 2600 万唯一身份访问者* 每月数十亿的页面浏览量* 所面临的扩展挑战都与 PHP 没有任何关系。面临的最大问题是与数据库有关的。* 数十个 Web 服务器。* 数十个数据库服务器。* 六个专门的图形数据库服务器运行推荐引擎。* Six to ten machines that serve files from MogileFS. ## 里面有什么 * 专用的负载平衡器设备可监视应用程序服务器，处理故障转移，根据运行状况不断调整群集，平衡传入请求以及缓存 JavaScript，CSS 和图像。如果您没有合适的负载均衡器，请查看 Linux Virtual Server 和 Squid 作为替代产品。* 请求被传递到 Application Server 群集。应用程序服务器包括：Apache + PHP，Memcached，Gearman 和其他守护程序。他们负责协调对不同服务（DB，MogileFS 等）的访问，并创建发送到浏览器的响应。* 使用 MySQL 主从设置。 -四个主数据库按功能划分：升级，配置文件，注释，主要。每个主服务器都挂有许多从数据库。 -写入主机，读取发送给从机。 -大量事务的服务器使用 InnoDB 存储引擎。 -OLAP 繁重的服务器使用 MyISAM 存储引擎。 -他们没有注意到从 MySQL 4.1 到版本 5 的性能下降。 -与“您的平均数据库设计”相比，该架构的规格化程度更高。 -分片用于将数据库分为几个较小的数据库。* Digg 的使用模式使他们更易于扩展。大多数人只是查看首页而离开。因此，Digg 的数据库访问中有 98％是读取的。凭借这种平衡的操作，他们不必担心为写入而设计的复杂工作，这使他们进行扩展变得容易得多。* 他们的存储系统出现问题，告诉他们写的确实不在磁盘上。控制器这样做是为了改善其性能外观。但是，这样做的结果是在故障场景中保留了巨大的数据完整性。这确实是一个非常普遍的问题，可能很难解决，具体取决于您的硬件设置。* 为了减轻数据库负载，他们使用了 APC PHP 加速器 MCache。* Memcached 用于缓存，memcached 服务器似乎分布在其数据库和应用程序服务器中。专门的守护程序监视连接并终止打开时间过长的连接。* 您可以结合使用 Apache 2 的工作线程，FastCGI 和 PHP 加速器，将 PHP 配置为不在每次加载时进行解析和编译。在页面的第一次加载中，将编译 PHP 代码，因此任何后续页面加载都非常快。* MogileFS 是一种分布式文件系统，提供故事图标，用户图标，并存储每个故事来源的副本。分布式文件系统在许多磁盘上分布和复制文件，从而支持快速和可扩展的文件访问。* 建立了专门的推荐引擎服务以充当其分布式图形数据库。关系数据库的结构不佳，无法生成建议，因此创建了单独的服务。 LinkedIn 为他们的图表做了类似的事情。 ## 得到教训 * 机器的数量并不重要，它们是什么以及它们如何组装在一起。* 不要把数据库当作锤子。建议与关系模型不符，因此他们提供了专门的服务。* 通过选择数据库引擎来调整 MySQL。在需要事务时使用 InnoDB，在不需要事务时使用 MyISAM。例如，主服务器上的事务表可以将 MyISAM 用于只读从服务器。* 在增长曲线的某个时刻，他们无法通过添加 RAM 来增长，因此必须通过架构来增长。* 人们经常抱怨 Digg 很慢。这可能是由于其庞大的 javascript 库而不是其后端体系结构。* 他们扩展的一种方法是注意在系统上部署的应用程序。他们注意不要释放使用过多 CPU 的应用程序。显然，Digg 具有一个相当标准的 LAMP 体系结构，但是我认为这很有趣。工程师通常有很多很酷的功能要发布，但是如果这些功能不能随功能一起增长，那么这些功能可能会破坏该功能。因此，请向后推，直到系统可以处理新功能为止。这涉及容量规划，这是 Flickr 在扩展过程中强调的内容。* 您是否想知道，通过限制新功能以匹配其基础架构，Digg 可能会与其他快速发展的社交书签服务相比而失去优势吗？也许，如果基础架构更容易扩展，他们可以更快地添加功能以帮助他们更好地竞争吗？另一方面，仅添加功能是因为您也没有任何意义。在数据层中，最容易发现扩展性和性能问题，并且这些问题是特定于语言的。您将使用 Java，PHP，Ruby 或它们插入您喜欢的语言。 ## 相关文章 * [LinkedIn 架构](http://highscalability.com/linkedin-architecture-0) * [](http://highscalability.com/linkedin-architecture-0)[实时日志体系结构](http://highscalability.com/livejournal-architecture) * [Flickr 架构](http://highscalability.com/flickr-architecture) * [数据库设计的非传统方法：碎片](http://highscalability.com/unorthodox-approach-database-design-coming-shard)的来临 * [Ebay 架构](http://highscalability.com/ebay-architecture) 是的，为什么 digg 只有 30 GB 的数据？如果这份报告是真实的，我会很高兴。 30gb 是数据库数据，是 HUUUUUGE！我已经写博客了将近 4 年，而我只使用了大约 15 mb 的数据库数据。 30 gb 的数据库数据非常庞大。如果他们仅跟踪有关其 120 万用户的一些历史数据，则 30 gb 的数据库并不多。我不相信。 Digg 需要的容量远远超过此处显示的 30GB 数据（无论如何）。您想知道为什么“只有” 30GB 吗？数据库是文本。字符是一个字节。算一算。也许我会一个人，但对我来说，没有什么值得骄傲的。它看起来像是标准的美国公司，那里的箱子比人的便宜，因此，购买 EXPLAIN 命令更容易购买 100 台服务器，然后只需支付 10 人即可。您可能来自某个时代，当时您确实必须竭尽全力从硬件中获得所有性能提升。但是，（某种程度上）事实是，成本/收益分析正朝着仅将更多硬件投入问题的方向发展。工程师，特别是优秀的工程师，并不便宜。硬件是。因此，虽然您可能不会留下深刻的印象，但我发现知道何时花更少的钱来完成同一任务“智能”。现在，这并不意味着应该放弃适当的数据库设计。实际上，在关系，约束，索引等方面，我有点加法。但是有时候，做具有成本效益的事情才有意义，我希望这就是 digg 所做的。哇，直到现在我才意识到我的最后一个问题有多糟。最后一件事，要水平缩放实际上需要花费很多精力。仅仅因为他们使用了很多盒子，并不意味着他们没有在整个系统架构和数据库设计上花费很多时间和精力。这是我目前正在设计的系统可以做到的事情，并不是这样，所以我不必担心优化代码，这样我就可以进行容量规划和购买资源，以逐步处理增加的负载并节省成本。我发现能够做到这一点令人印象深刻。他指的 30 GB 可能是每个群集节点上所需的空间。 OS +应用程序等我将是第一个不同意的人。首先，如果没有合适的人设计整个体系结构，那么在一个问题上丢箱子只会增加您的电费。我已经看到了与客户的第一手资料。实际上，我已经看到使用集群的“解决方案”实际上降低了性能，因为设计反表明集群的使用（换句话说，它不是可扩展的设计）。就个人而言，我宁愿选择一些架构师和管理员以及许多功能强大的机器，而不是忙于工作人员并且没有足够的服务器资源。 :) - Dustin Puryear 作者， [http://www.puryear-it.com/pubs/linux-unix-best-practices“](<a rel=) >管理 Linux 和 UNIX 的最佳做法服务器 [http://www.puryear-it.com“](<a rel=) > [http://www.puryear-it.com](http://www.puryear-it.com) Digg 使用哪种负载均衡解决方案/产品？确定他们可以廉价地添加服务器，但是每月要有 100 台服务器才能获得 2 亿次观看？相比之下，每月有 2 箱装满大量鱼的鱼有 1.1B 次浏览，digg sux？知道 Digg 使用哪种形式的 FastCGI？或者其他人用于 PHP / Apache 配置？为了清理。 30GB 的数据库*为 closal* 。在 DIGG 上，您只需要在数据库中存储一个简短的标题，简短的上下文，链接 URL，日期，作者以及 Diggs 的数目，也就是这样。然后再添加一些用户帐户数据...没什么。 30 GB 为 30,000,000,000 字节（大约），每个字符为一个字节（UTF8）我的意思是，对于**来说，对于**，30GB 听起来可能很小，因为您存储视频/音乐/游戏，但是我们在这里谈论的是纯文本。克服它。一个 30GB 的数据库确实不是那么大。您忘记了该网站不仅存储了数字，还存储了谁，谁评论了哪些评论，最有可能存储点击（我怀疑他们用来检测欺诈）。一个受欢迎的故事可能包含数千个挖掘，然后评论中包含数千个挖掘。此数据已全部存储。我们还知道 digg 正在分片，因此我怀疑数据库的大小远大于此大小。我相信 BIG-IP :) 我非常怀疑这是真的，他们使用两个框进行的浏览量可能不足 2000 万。我曾与银行的 MS SQL Server 合作，主要开发了业务核心和 BI 应用程序，其中 SQL Server MDF 已达到 100GB 以上。该数据库在 5 个奇数年的时间内跟踪了每个客户针对每个帐户进行的每笔交易。那就好那就是 SQL2000。它的速度非常快。 SQL Server 和可靠，可靠的企业体系结构是在.NET 框架>上开发的。认为他可以使用其他（劣等）工具集可以做得更好的任何反 MS 专家，只是在做梦。如前所述-30GB 是一个很大的数据库。我不会说巨大，因为（对我而言）意味着在其界限的边缘没有任何增长空间的东西。但是，数据库很大。在 www.freecrm.com 上，我们在 1 台快速服务器上的 mySql 5 设置上达到了 30GB 的数据库大小，但是在修剪了旧的电子邮件日志后，我们将其减少到 18GB 左右。在超过 60,000 个用户的 CRM 应用程序中，这已超过 4 年的大量使用。到目前为止，mySql 可以顺利进行，并且到目前为止，任何慢速查询都是由于索引不足。 -Harel Malka ------------------------ [http://www.harelmalka.com](http://www.harelmalka.com) [http://www.freecrm.com](http://www.freecrm.com) [http://www.kadoink.com](http://www.kadoink.com) 与我管理的数据库相比，30gb 很小。我管理的大多数生产数据库的范围从 600gb 到 2tb 不等，所有数据库都运行 Oracle 10g。这些网站大多数都有麻烦，因为他们选择 mysql 而不是真实的数据库。像 Bebo 这样的使用 Oracle 的网站都可以很好地扩展。 Bebo.com 的基础架构每天仅使用 6 cpus 即可支持超过 1 亿个网站页面浏览量和每天约 120 万张图片上传。链接在这里： [http://searchoracle.techtarget.com/originalContent/0,289142,sid41_gci1241597,00.html](http://searchoracle.techtarget.com/originalContent/0,289142,sid41_gci1241597,00.html) Lucene 数据的大小是多少？每个人都可能想注意到任何人说 30gb 是大型甚至中型的。当涉及到与高可伸缩性相关的任何事情时，您可能不希望听取他们的意见。对于他们来说，显然并不需要扩展。我想进一步了解他们如何/为什么使用 MCache。 APC 应该适合本地服务器缓存，memcached 适合分布式缓存。 MCache 有什么帮助？我曾经使用过 msession，在每个页面上都有一些奇怪的启动开销。我改用 MySQL 进行会话，而不是使用 msession，这很棒。我不确定为什么他们将 MCache 添加到组合中，并且想知道如何以及为什么... 我猜每个服务器都有 30G 我认为将 30GB 的内存称为小型磁盘的意义在于，您可以购买具有 128GB 以上的 RAM 的计算机，并将整个数据库放入缓存中。考虑到戴尔提供的具有 32GB RAM 的四核 opteron 的价格为 6600 美元，看来浪费在 memcached 以及所有这些 Web 服务器上的资源，据我的数学计算，每秒 77 个请求有点过分。