# Poppen.de 建筑 > 原文： [http://highscalability.com/blog/2010/4/12/poppende-architecture.html](http://highscalability.com/blog/2010/4/12/poppende-architecture.html) 这是 Alvaro Videla 的来宾，他描述了 [Poppen.de](http://www.poppen.de/) 这个流行的德国约会网站的架构。 该站点非常类似于 NSFW，因此在单击链接之前请多加注意。 我发现最有趣的是，他们如何使用 Nginx，MySQL，CouchDB 和 Erlang，Memcached，RabbitMQ，PHP，Graphite，Red5 和 Tung 等技术，成功地将一些旧代码与一些新代码成功融合。 ## 什么是 Poppen.de？ Poppen.de（NSFW）是德国最热门的约会网站，尽管与 Flickr 或 Facebook 这样的巨头相比，它可能是一个很小的网站，但如果您开始遇到一些扩展问题，我们认为这是一个不错的架构。 ## 统计资料 * 2.000.000 用户 * 20.000 个并发用户 * 每天 300.000 条私人消息 * 每天 250.000 次登录 * 我们有一个由 11 个开发人员，2 个设计师和 2 个 sysadmin 组成的项目团队。 ## 商业模式 该网站使用免费增值模式，用户可以免费执行以下操作： * 搜索其他用户。 * 互相写私信。 * 上传图片和视频。 * 有朋友 * 视频聊天。 * 多得多… 如果他们想发送无限制的消息或上传无限制的图片，则可以根据需要为不同类型的成员付费。 视频聊天和网站的其他部分也是如此。 ## 工具箱 ### Nginx 的 我们所有的网站都通过 Nginx 提供服务。 我们有 2 台 Nginx 前端服务器，在高峰时间每分钟向 www.poppen.de 发送 150.000 个请求。 它们是使用四年的计算机，每个计算机只有一个 CPU 和 3GB RAM。 然后，我们有单独的机器来提供站点图像。 每分钟由 3 个 nginx 服务器处理* .bilder.poppen.de（图像服务器）有 80.000 个请求。 Nginx 让我们做的很酷的事情之一就是从 Memcached 发出很多请求，而无需点击 PHP 机器来获取已经缓存的内容。 因此，例如，用户配置文件是站点中 CPU 占用最大的页面之一。 请求配置文件后，我们会将全部内容缓存在 Memcached 上。 然后 Nginx 服务器将命中 Memcached 并从那里传递内容。 每分钟有 8000 个请求从 Memcached 发送出去。 我们有 3 个 Nginx 服务器正在从本地缓存中传递图像。 用户将他们的图片上传到中央文件服务器。 图片请求将命中 3 台 Nginx 服务器之一。 如果图片不在本地缓存文件系统中，则 Nginx 将从中央服务器下载图片，将其存储在本地缓存中并提供服务。 这使我们可以负载均衡图像分布并减轻主存储机中的负载。 ### PHP-FPM 该站点在 PHP-FPM 上运行。 我们使用 28 台 PHP 机器，每个机器具有两个 CPU 和 6GB 的内存。 他们每个运行 100 个 PHP-FPM 工作进程。 我们使用启用 APC 的 PHP5.3.x。 PHP 5.3 版本使我们可以减少 30％以上的 CPU 和内存使用率。 该代码是使用 symfony 1.2 PHP 框架编写的。 一方面，这意味着额外的资源占用，另一方面，它使我们可以加快开发速度，并拥有众所周知的框架，可以使我们轻松地将新开发人员集成到团队中。 这里并不是所有的东西都是“花和玫瑰”。 因此，尽管我们拥有该框架提供的许多优势，但我们还是不得不对其进行大量调整，以使其达到服务于 www.poppen.de 的任务。 我们所做的就是使用 XHProf（Facebook 的 PHP 概要分析库）对站点进行概要分析，然后优化瓶颈。 由于该框架易于自定义和配置，因此我们能够缓存大多数昂贵的计算，这些计算给 APC 中的服务器增加了额外的负载。 ### 的 MySQL MySQL 是我们的主要 RDBMS。 我们有几台 MySQL 服务器：一台 32GB 的机器，带有 4 个 CPU，用于存储所有与用户有关的信息，例如个人资料，图片元数据等。该机器已有 4 年的历史。 我们计划将其替换为分片群集。 我们仍在设计此系统，以尽量减少对我们的数据访问代码的影响。 我们希望按用户 ID 对数据进行分区，因为网站上的大多数信息都以用户本身为中心，例如图像，视频，消息等。 我们有 3 台机器在用户论坛的主从配置中工作。 然后有一个服务器群集，用作网站自定义消息系统的存储。 目前，它有超过 2.5 亿条消息。 它们是在主从站主/从站从站系统中配置的 4 台机器。 我们还有一个由 4 台计算机组成的 NDB 集群，用于写入大量数据，例如哪个用户访问了哪个其他用户的个人资料的统计信息。 我们尝试尽可能避免像瘟疫这样的联接并缓存。 数据结构被高度非规范化。 为此，我们创建了摘要表，以简化搜索。 大多数表都是 MyISAM，可提供快速查找。 我们看到越来越多的问题是全表锁。 我们正在转向 XtraDB 存储引擎。 ### 记忆快取 我们大量使用 Memcached。 我们有超过 51 个节点的 45 GB 缓存。 我们将其用于会话存储，视图缓存（如用户配置文件）和函数执行缓存（如查询）等。我们对用户表拥有的大多数按主键进行的查询都缓存在 Memcached 中，然后从那里传递 。 我们拥有一个系统，该系统可在每次修改该表的一条记录时自动使缓存无效。 将来改善缓存失效的一种可能解决方案是使用新的 Redis Hash API 或 MongoDB。 使用这些数据库，我们可以以足够的粒度更新缓存，而无需使其无效。 ### 兔子 MQ 自 2009 年中以来，我们将 RabbitMQ 引入了我们的堆栈。 这是一个易于部署并与我们的系统集成的解决方案。 我们在 LVS 后面运行两个 RabbitMQ 服务器。 在上个月，我们一直在将越来越多的东西移到队列中，这意味着目前 28 台 PHP 前端计算机每天大约发布 50 万个作业。 我们向队列发送日志，电子邮件通知，系统消息，图像上传等等。 为了使消息入队，我们使用了 PHP-FPM 提供的最酷的功能之一，即 fastcgi_finish_request（）函数。 这使我们能够以异步方式将消息发送到队列。 在生成必须发送给用户的 HTML 或 JSON 响应后，我们将调用该函数，这意味着用户不必等待我们的 PHP 脚本清理完毕，例如关闭 Memcached 连接，DB 连接等。 同时，所有保存在内存数组中的消息都将发送到 RabbitMQ。 这样，用户也不必等待。 我们有两台专用于处理这些消息的机器，目前总共运行 40 个 PHP 进程以消耗作业。 每个 PHP 进程消耗 250 个工作，然后死亡并重新生成。 我们这样做是为了避免 PHP 出现任何形式的垃圾回收问题。 将来，我们可能会增加每个会话消耗的作业数量，以提高性能，因为事实证明重新分配 PHP 进程会占用大量 CPU。 该系统使我们可以改善资源管理。 例如，在高峰时间，我们甚至每分钟可以登录 1000 次。 这意味着我们将对 users 表进行 1000 个并发更新，以存储用户的上次登录时间。 因为现在我们使这些查询入队，所以我们可以依次依次运行每个查询。 如果我们需要更高的处理速度，我们可以将更多的使用者添加到队列中，甚至可以将机器加入集群中，而无需修改任何配置或部署任何新代码。 ### CouchDB 为了存储日志，我们在一台计算机上运行 CouchDB。 从那里我们可以按模块/动作查询/分组日志； 事实证明，发现问题出在哪里很有用。 在将 CouchDB 用作日志聚合器之前，我们必须在每台 PHP 机器上登录并拖尾-f，然后从那里尝试找出问题所在。 现在，我们将所有日志中继到队列，然后使用者将它们插入 CouchDB。 这样，我们可以在集中的地方检查问题。 ### 石墨 我们使用[石墨](http://graphite.wikidot.com/)从网站收集实时信息和统计信息。 从每个模块/动作的请求到 Memcached 命中/未命中，RabbitMQ 状态监视，服务器的 Unix 负载等等。 Graphite 服务器每分钟进行约 4800 次更新操作。 实践证明，该工具对于查看站点中的实际情况非常有用。 它是简单的文本协议，其图形功能使它易于使用，几乎可以即插即用到我们要监视的任何系统。 我们使用 Graphite 做的一件很酷的事情是监视同时运行的网站的两个版本。 去年一月，我们部署了由新版本的 symfony 框架支持的代码。 这意味着我们可能会遇到性能下降的情况。 我们能够在一半的服务器中运行该站点的一个版本，而新版本则在其他服务器中运行。 然后，在 Graphite 中，我们为每半创建 Unix 负载图，然后进行实时比较。 由于我们发现新版本的 Unix 负载较高，因此我们启动了 XHProf 分析器并比较了这两个版本。 我们使用 APC 存储“标志”，这些标志使我们可以启用/禁用 XHProf，而无需重新部署代码。 我们有一个单独的服务器，在其中发送 XHProf 配置文件，然后从那里汇总它们并进行分析，以找出问题所在。 ### 红色 5 我们的网站还向用户提供视频。 我们有两种。 一种是来自用户配置文件的视频，这些视频是用户制作和上传的电影。 此外，我们还有一个视频聊天功能，可让我们的用户互动并分享他们的视频。 在 2009 年中，我们每月向用户流式传输 17TB 的视频。 ### 宗宗 Tsung 是用 Erlang 编写的分布式基准测试工具。 我们使用它来进行 HTTP 基准测试，并比较我们计划使用的 MySQL 的不同存储引擎，例如新的 XtraDB。 我们有一个工具可以记录到主 MySQL 服务器的流量，并将该流量转换为 Tsung 基准测试会话。 然后，我们重播了这些流量，并通过 Tsung 生成的数千个并发用户访问了实验室中的计算机。 很棒的事情是，我们可以产生更接近实际生产环境中发生情况的测试方案。 ## 得到教训 * 虽然面向 Buzz 的开发很酷，但**仍在寻找具有重要社区的工具**。 当有问题需要解决时，或者需要将人员纳入团队时，文档和良好的社区将非常宝贵。 symfony 规定，可以免费获得 5 本以上的官方书籍。 CouchDB 和 RabbitMQ 的开发人员也提供了良好的支持，它们具有活跃的邮件列表，可以及时回答问题。 * **了解您正在使用什么以及这些系统/库的局限性是**。 我们从 symfony 中学到了很多东西。 可以在哪里进行调整以及可以改进什么。 就 PHP-FPM 而言，我们可以这么说，只是通过阅读文档，我们发现强大的 fastcgi_finish_request（）函数被证明是非常有用的。 另一个例子是 Nginx，Nginx 社区已经解决了一些问题，例如我们对图像存储缓存的解释。 * **扩展工具**。 如果他们运行良好，则无需在当前堆栈中引入新软件。 我们已经编写了几个 Nginx 模块，这些模块甚至已经被 Nginx 社区测试过。 这样，您可以回馈。 * **D** **对于无关紧要的**并不保守。 石墨似乎是在生产中运行的一种很酷的工具，但是关于它的报道并不多。 我们只需要尝试一下。 如果它不起作用，我们可以禁用它。 如果我们无法在系统中得到一个很好的 Unix Load 图，谁也不会哭。 今天，甚至我们的产品经理都喜欢它。 * **测量所有**：Unix 负载，站点使用情况，Memcached 命中率/丢失率，每个模块/动作的请求等。学习解释这些指标。 * **创建工具，使您可以尽快对问题做出反应**。 如果您必须回滚部署，那么您不想花费一秒钟以上的时间。 * **创建工具，使您可以实时分析网站的情况**。 在实验室中，大多数测试都给出了乐观的信息，但随后却无法应对生产负荷。 ## 未来 * 构建一个新的，更具可伸缩性的消息系统，因为当前版本相当旧，并且并非针对如此大量的消息而设计。 * 将越来越多的处理任务移至队列系统。 * 将更多的 Erlang 应用程序添加到我们的系统中。 事实证明，RabbitMQ 对我们和 CouchDB 都适用。 它们是易于安装和部署的系统，从而增加了我们对 Erlang 作为语言/平台的信任。 * 我们正在寻找 Red5 的替代产品，可能是用 Erlang 编写的 Oneteam Media Server。 目前，当我们使用开源 Erlang 产品时，我们可能会开始使用该语言编写我们自己的应用程序，因为现在我们已经有了使用它的经验。 * 改进我们的日志可视化工具。 我要感谢 Alvaro Videla 的出色写作。 如果您想共享 fablous 系统的体系结构，请 [与联系我](http://highscalability.com/contact/)，我们将开始。 让我们做数学。 每分钟有 15 万个请求到 www。*，这意味着每秒有 2500 个请求。 他们有 28 个 PHP 框，每个框有 100 个进程。 这意味着 2800 个 PHP 进程。 您需要尽可能多的 PHP 进程来处理并发请求（不是每秒）。 这意味着它们的脚本要么花费 1 秒来执行每个脚本，要么它们有很多方法可以执行。 不管哪种方式，东西都坏了。 我知道有使用 2-4 台服务器使用 PHP 满足此请求数量的网站。 不是 28。 Quote： **此系统使我们可以改善资源管理。 例如，在高峰时间，我们甚至每分钟可以登录 1000 次。 这意味着我们将对用户表进行 1000 个并发更新，以存储用户的上次登录时间** 不，这并不意味着您有 1000 个并发更新。 这意味着您每秒大约有 16 次登录，这意味着您可能有 10-20 次并发更新。 大多数时候少很多。 还要注意，它们有 50 个 memcached 节点。 他们必须处理多少台服务器来处理这种中等负载？ 太疯狂了 结论：并不令人印象深刻，我还没有看到任何新见解。 我对他们的代码的效率提出了很多质疑。 您好 Alvaro，感谢您对体系结构的有趣了解。 我提出了两个问题：-如何衡量并发用户（超时？），为什么使用这么小的数据集使用如此多的节点进行内存缓存？ 问候，保罗 您可以提供指向 Graphite 的链接吗？ 听起来很有趣，我们已经开始研究这些系统，但是它的含义如此普遍，以至于简单的 Google 都无法提出我认为正确的任何东西。 可以在 [http://graphite.wikidot.com/](http://graphite.wikidot.com/) 上找到石墨网站。 @霜： -对 poppen.de 的 150.000 请求并不意味着它们全部都到达了 PHP 后端。 “我知道使用 2-4 台服务器使用 PHP 满足此请求数量的站点。不是 28 台。” 这取决于他们做什么，他们缓存了什么，可以从请求中缓存多少。 它们显示多少个局部分量？ 网站信息是否完全动态？ 问题列表可以继续。 除此之外，我们将平均负载保持在较低水平，并且我们有足够的服务器来满足计划的增长。 除此之外，当您建立网站时，您还必须做出商业决策。 不像您选择有关网站编程理论的最佳书籍。 在我们的例子中，我们使用框架和 ORM。 这使我们发展很快。 您也必须考虑到这一点。 我了解到，在不了解其他公司背后的背景的情况下很难谈论它们。 关于对数据库和登录号的并发查询，您是对的，我在编号上犯了一个错误。 我向读者道歉，因为他们提供了误导性的信息。 另一方面，我希望您和该站点的其他读者能够理解使用队列服务器可以完成的工作。 如果您已经知道了这一点，并且不需要向我学习，那么对您会更好。 我希望这对至少一名开发人员有用。 50 个 Memcached 节点并不意味着有 50 个专用计算机。 @保罗 p： 我们有一个“谁在线”服务器来跟踪在线用户。 它使用超时将其标记为已注销。 我们使用几个 Memcached 节点，因为根据要缓存的内容，我们有专门的存储桶。 例如，我们有视图缓存，用于缓存模板。 函数缓存，用于将查询缓存到数据库。 然后，一个 Memcached 专门将查询缓存到一个表等。这样，一个 memcached 的使用不会影响其他表。 @理查德： http://graphite.wikidot.com/ 嗨，阿尔瓦罗 我想向您介绍一个更好的流服务器： [erlyvideo](http://erlyvideo.org) ，值得测试，在您的情况下它将处理多少用户（对我来说，它可以从一台计算机上支持 1800 个连接）。 如果需要，请写 [[受电子邮件保护]](/cdn-cgi/l/email-protection) 。 >我们希望按用户 ID 对数据进行分区，因为网站上的大多数信息都以用户本身为中心，例如图像，视频，消息等。 哼...这很有趣...会不会创建太多分区？ 我对 Mysql 不太熟悉，但是我正在研究的那个 MySQL 建议我们不要创建超过 2000 个分区。 但是，在用户 ID 上进行分区将意味着几个 100K +分区。 @Alvaro： 因此，如果他们甚至不使用 PHP，那么我更正确的是您的脚本太慢，进程太多。 但这不是真正的问题。 我正在谈论的站点具有很多动态内容，但是缓存非常聪明，而且它们不使用任何框架或 ORM 包装器。 这就是我认为您可能损失 90％的性能的地方，这些东西往往是绝对的性能杀手。 当然，您可以在开发时间上获得一些优势，但是一旦达到一定的规模，就会希望您没有走这条路。 为使用更智能查询和缓存的对象编写一些类并不难。 您的前端有 2.5k re / s，memcached 可以提供 133 re / s。 这是否意味着您的缓存命中率为 5％？ 而且请不要使用“每分钟的请求数”，没有人对规模感兴趣。 它主要是“每秒请求数”，突然之间您的数字似乎不再那么大了，因为它只有 60 分之一。 @Abhishek： 他没有说每个用户一个分区，而是说了按用户 ID 划分的分区。 这并没有暗示有关分区大小的任何信息。 每个分区可以是 100 个用户或 100 万个用户。 它仅告诉您使用哪个键来决定将值存储在哪个分区中。 同样，这与 MySQL 本身无关。 你在做什么？ 还有 2000 个分区？ 是，对.. 有趣。 您使用任何类型的虚拟化/云服务还是全部物理硬件？ 任何 CDN？ 什么操作系统/发行版？ 阿尔瓦罗 很棒的帖子。 我认为阅读和查看如何解决许多问题很有趣。 关于石墨也不错的技巧。 此致 尼克拉斯 嗨，阿尔瓦罗。 您说过您正在使用 memcached 来缓存诸如用户个人资料之类的视图组件。 您能否说明有关如何使这些视图缓存无效的更多详细信息？ 我了解您在更改数据时编写了自己的代码来使“数据缓存”无效。 但是对于视图缓存，有很多数据，任何数据更改都将使该视图缓存无效。 你是怎样做的？ 我的第一感觉：太多的 PHP 服务器。 我认为在这种情况下，Symfony 对于他们来说 PHP 框架太慢了。 从我的经验中得知，Symfony 吃了很多 CPU。 我真的认为他们应该用更具扩展性和轻量级的 PHP 框架取代 Symfony @Max Lapshin 感谢您对 Erlyvideo 的提示，几个月前我们也对此进行了调查。 我们尚未决定。 @Maxim R 我们使用 EC2 进行视频传输，其他系统则托管在我们的物理服务器中。 服务器正在运行 SLES10。 @尼尔·H 我们对键进行“命名空间”，因此可以立即使相关的键集失效。 但这取决于网站的哪一部分。 因此，在这里很难解释所有这一切。 参见此处，了解许多常见模式：http://code.google.com/p/memcached/wiki/FAQ @pcdinh 如果您是 http://twitter.com/pcdinh，那么我可以告诉您，我们不使用 16 核 Dell / HP 之类的计算机。 我们使用具有 8 核的 6G Ram 的旧刀片服务器。 除此之外，我们将这些机器的平均负载保持得非常低。 然后，关于 symfony 或任何 PHP 框架，尽管它们不是比普通的 PHP 代码或更轻量级的框架最快的解决方案，但速度并不是选择框架时唯一考虑的问题。 symfony 拥有强大的支持，强大的社区和大量文档。 这意味着我们可以轻松雇用已经知道我们所使用技术的人员。 那么，如果我们使用超快速的自定义框架，然后编写它的“黑客”离开了公司，会发生什么呢？ 谁来维护他的代码？ 从理论上讲，您关于迁移到另一个框架的建议听起来不错，但是您知道将站点代码移植到另一个框架可能需要花费几个月的时间吗？ 我们还必须支付开发人员的薪水，而在大多数情况下，这些薪水都比其中一台刀片服务器贵。 因此，正如我在之前的回答中所说，公司会做出业务决策，而不仅仅是因为速度快而选择了这种框架。 因此，请不要将服务器数量归咎于 symfony，因为虽然 yes 比普通的 PHP 代码重，但这不是我们使用那么多服务器的原因。 如果不是，那为什么要使用 PHP？C 的速度要快得多。 Alvaro，我绝不会质疑您的基础架构，因为您比这里的其他任何人都了解它，尤其是其中一些“扶手椅系统架构师”。 :) 但是该语句 > 我们还必须支付开发人员的薪水，而在大多数情况下，这些薪水都比其中一台刀片服务器贵。 can lead you into a corner. you can throw money at hardware only for so long until your investment start to produce diminishing returns and your infrastructure becomes too unwieldy and then it'll be that much harder to do any meaningful code changes. 保持服务器负载“ *非常*低”又有什么意义呢？ 如果服务器在可接受的时间内返回数​​据，负载是多少（故障或严重超载除外）有关系吗？ 听起来您所有的服务器都在内存缓存池中。 我很好奇，PHP 服务器具有更大的 APC 缓存大小而不是将其用于内存缓存会更好吗？ @马克西姆 R. 感谢您的见解。 我同意你的看法。 不是说您去硬件上花钱，应该有一个平衡点。 我们也会在可能的情况下尝试改进代码。 e .：每当我们向站点功能添加功能时，我们都会尝试提高性能，重构代码等，因为我们需要在腐烂之前对其进行维护。 我们正在开发一种用于 SQL 查询的轻量级解决方案，根据我们的基准测试，该解决方案将减轻站点的大量负载，因为我们可以删除我们使用的 ORM，这是很沉重的。 我们的网站在不断发展，我们正在像每个人一样从错误中学习。 关于平均负载语句，我说过，因为对于某些评论者来说，我们有 28 台完全过载的计算机。 除此之外，我们拥有这些机器是因为我们正在计划未来的增长，如果一切都按计划进行，那么到将来我们的意思是迫在眉睫。 关于 APC 与 Memcache。 我们必须考虑更多。 有时我们讨论的与您刚才所说的相同。 同时，一些经验丰富的 PHP 开发人员告诉我，APC 在拥有大量 RAM 时不能很好地工作。 我没有与此相关的经验可以发表意见。 另外，APC 缓存不共享，如果这也是一个问题，我们必须考虑。 我们也将一些计算缓存到 APC 中。 阿尔瓦罗 感谢**很棒的文章**！ 我对您的 nginx 和 memcached 有一个问题。 您写道，许多请求甚至都没有达到 PHP，因为 Nginx 从 memcached 获取了缓存的内容-您能再描述一下吗？ 您是否缓存 HTML 页面？ 问候， @阿尔瓦罗 Erlyvideo 发展非常迅速。 几个月前，您可以看到它的前一代，什么也做不了。 因此，如果您有兴趣，最好通过电子邮件进行交流。 +1 感谢您的精彩文章！ Alvaro，我认为您应该尝试 Erlyvideo-它在 Erlang 中很烂，而且发展非常迅速。 我认为，erlyvideo 的作者 Max Lapshin（привет，Макс:)可以提供支持并实现所需的所有功能。 Alvaro，您尝试过 Facebook 的 HipHopPHP 编译器吗？ > 我发现最有趣的是他们如何成功地将一些旧的和一些新的 不，他们没有成功地将新旧融合在一起。 poppen.de 以运行缓慢而闻名。 它几乎从来没有真正快过，而且每隔几（6-8）周就会额外减速至少几小时，通常是 1-2 周。 当前的缓慢周期自大约 6 周开始，至今仍未结束。 poppen.de 的性能给 a * s 带来了痛苦。.远非成功... > 我们有 2 个前端 Nginx 服务器 Alvaro, are these 2 servers in a master/master setup? Which is the solution to make them highly available/load balanced? Regards