# 《 FarmVille》如何扩展以每月收获 7500 万玩家 > 原文： [http://highscalability.com/blog/2010/2/8/how-farmville-scales-to-harvest-75-million-players-a-month.html](http://highscalability.com/blog/2010/2/8/how-farmville-scales-to-harvest-75-million-players-a-month.html) *一些读者对本文有后续问题。 可以在[《 FarmVille 如何缩放-后续行动》](http://highscalability.com/blog/2010/3/10/how-farmville-scales-the-follow-up.html) 中找到卢克的回应。* 如果像 Zynga 的大热门《 Farmville 》中的真实耕种一样令人振奋，那么我的家人可能永远不会离开北达科他州那些严酷的冬天。 我的祖母过去讲的关于农业的可怕的睡前故事，在 FarmVille 中都不是真的。 [农民](http://w.good.is/post/What-Does-Farmville-Mean-for-Farmers/)赚钱，植物生长，动物从不拜访[红色谷仓](http://www.youtube.com/watch?v=eUJz3137EQ8)。 我想仅仅是因为保持鞋子干净整洁的魅力，才使得 FarmVille 在如此短的时间内成为“世界上最大的游戏”。 FarmVille 如何扩展 Web 应用程序以每月处理 7500 万玩家？ 幸运的是，FarmVille 的卢克·拉吉里奇（Luke Rajlich）同意让我们了解他们的一些挑战和秘密。 这是卢克必须说的... 采访的形式是，我向卢克发送了一些一般性问题，他回答了以下答复： > FarmVille 具有一组独特的扩展挑战，这是应用程序所特有的。 游戏必须迅速扩展。 该游戏在 4 天后每天有 100 万玩家，在 60 天后每天有 1000 万玩家。 在发布时，最大的社交游戏是每天 500 万玩家。 目前，《 FarmVille》推出后 9 个月的每日玩家有 2800 万，每月玩家有 7500 万。 这使得 FarmVille 的每月玩家人数超过了法国的全部人口。 FarmVille 有两个基本特征，这是独特的扩展挑战：它是世界上最大的游戏，并且是 Web 平台上最大的应用程序。 这两个方面都带来了 FarmVille 必须克服的一系列独特的扩展挑战。 在技​​术投资方面，FarmVille 主要利用开源组件，并且其核心是基于 LAMP 堆栈构建的。 > > 为了使 FarmVille 可扩展为游戏，我们必须适应游戏的工作量要求。 用户状态包含大量具有微妙而复杂的关系的数据。 例如，在服务器场中，对象无法相互碰撞，因此，如果用户在其服务器场上放置房屋，则后端需要检查该用户服务器场中是否没有其他对象占用重叠空间。 与大多数主要网站（如 Google 或 Facebook）读取量大不同，FarmVille 的写入工作量非常大。 数据读取与写入的比率为 3：1，这是令人难以置信的高写入速率。 到达 FarmVille 后端的大部分请求都以某种方式修改了玩游戏的用户的状态。 为了使其具有可扩展性，我们努力使我们的应用程序主要与缓存组件进行交互。 此外，由于我们正在有效地扩展游戏，因此发布新内容和功能往往会导致使用量激增。 新功能发布之日，负载峰值可能高达 50％。 我们必须能够容纳这种高峰流量。 > > 另一个方面使 FarmVille 规模成为 Web 平台上最大的应用程序，并且与世界上一些最大的网站一样大。 由于该游戏在 Facebook 平台内运行，因此我们对平台的延迟和性能差异非常敏感。 结果，我们做了很多工作来减轻延迟差异：我们大量缓存 Facebook 数据，并在性能下降时优雅地提高了平台的使用率。 FarmVille 已为 Facebook 平台部署了整个缓存服务器集群。 FarmVille 和 Facebook 平台之间的流量巨大：高峰时，FarmVille 和 Facebook 之间的流量大约为 3 Gigabit / sec，而我们的缓存群集又为应用程序提供了 1.5 Gigabit / sec。 此外，由于性能可以变化，因此应用程序可以动态关闭对平台的任何调用。 我们有一个可以调整的拨号盘，可以逐渐关闭返回平台的更多呼叫。 我们还努力使所有调用都返回平台，以避免阻塞应用程序本身的加载。 这里的想法是，如果其他所有方法都失败了，则玩家至少可以继续玩游戏。 > > 对于任何 Web 应用程序，高延迟都会杀死您的应用程序，而高度可变的延迟最终会杀死您的应用程序。 为了解决高延迟问题，FarmVille 致力于在高延迟组件之前放置大量缓存。 高度可变的延迟是另一个挑战，因为它需要重新考虑应用程序如何依赖其体系结构中通常具有可接受的延迟的部分。 几乎每个组件都容易受到这种可变延迟的影响，其中一些比其他组件更容易受到影响。 由于 FarmVille 的性质（工作量非常大且事务繁重），与传统的 Web 应用程序相比，延迟的变化对用户体验的影响更大。 FarmVille 处理这些情况的方式是通过将每个组件都视为可降级的服务来考虑。 Memcache，数据库，REST Apis 等都被视为可降解服务。 服务降级的方式是为该服务的错误限制率并实施服务使用限制。 关键思想是通过使用错误和超时限制来隔离故障和高延迟的服务，以免在其他地方引起延迟和性能问题，并在需要时使用打开/关闭开关和基于功能的调节器禁用应用程序中的功能。 > > 为了帮助管理和监视 FarmVille 的 Web 场，我们利用了许多开源的监视和管理工具。 我们使用 nagios 进行警报，使用 munin 进行监视，并使用 puppet 进行配置。 我们大量利用内部统计系统来跟踪应用程序使用的服务（例如 Facebook，DB 和 Memcache）的性能。 此外，当我们发现性能下降时，我们会以采样为基础来分析请求的 IO 事件。 ## 得到教训 关于某些事情，我没有那么多的细节，但是我认为人们仍然可以从中学习很多有趣的观点： 1. **交互式游戏写得很重**。 典型的 Web 应用程序读取的内容多于编写的内容，因此许多常见的架构可能还不够。 读取繁重的应用程序通常可以通过单个数据库前面的缓存层来解决。 写繁重的应用程序需要分区，以便写操作可以分散和/或使用内存架构。 2. **将每个组件设计为可降解服务**。 隔离组件，以使一个区域中的延迟增加不会破坏另一个区域。 节气门使用有助于缓解问题。 必要时关闭功能。 3. **缓存 Facebook 数据**。 当您非常依赖外部组件时，请考虑缓存该组件的数据以提高延迟。 4. **提前计划新的与发布有关的使用峰值**。 5. **样本**。 在分析大型数据流时，例如查找问题，并不是每个数据都需要处理。 采样数据可以产生相同的结果，从而减少工作量。 我要感谢 Zynga 和 Luke Rajlich 抽出宝贵的时间进行这次采访。 如果其他人有他们想要的架构，请告诉我，我们会进行设置。 ## 相关文章 1. [建立大型社交游戏](http://www.slideshare.net/amittmahajan/building-big-social-games)-讨论 FarmVille 背后的游戏机制。 2. [BuddyPoke 如何使用 Google App Engine 在 Facebook 上扩展](http://highscalability.com/blog/2010/1/22/how-buddypoke-scales-on-facebook-using-google-app-engine.html) 3. [策略：减少数据集的样本](http://highscalability.com/blog/2008/4/29/strategy-sample-to-reduce-data-set.html) 4. HighScalability 发布了[缓存](http://highscalability.com/blog/category/caching)和[内存缓存](http://highscalability.com/blog/category/memcached)的信息。 5. HighScalability 发布了[分片](http://highscalability.com/blog/category/sharding)。 6. 高扩展性发布在[内存网格](http://highscalability.com/blog/category/memory-grid)上。 7. [如何在不进行实际尝试的情况下成功完成容量规划：Flickr 的 John Allspaw 专访他的新书](../../blog/2009/6/29/how-to-succeed-at-capacity-planning-without-really-trying-an.html) 8. [缩放 FarmVille](http://perspectives.mvdirona.com/2010/02/13/ScalingFarmVille.aspx) ，作者是 James Hamilton 哇！ Farville 只是从“最烦人的网络事物”发展为“技术挑战的最酷示例。在我的个人词典中，那是:) 我要做的最后一件事是贬低 Zynga 的优秀人才所取得的成就，但是这里存在一个巨大的疏忽错误……Zynga 运行着一个 200 节点的 Vertica 集群。 数据存储的可伸缩性非常重要，不是吗？ 同事： “运行 Vertica 的 200 个节点...如果您无法进行横向扩展，则应该改用 7-11 计数器工作” 披露：我不为 Vertica 工作，呵呵。 @森林 有趣。 我认为 200 个节点运行起来不是很昂贵吗？ 否则，似乎值得指出的是开发自己开发的产品还是购买现成产品的决定。 令人失望的是，太笼统的:( 会令人着迷，以至于它们实际上没有读懂一些细节。 他们使用的是云服务器还是专用服务器？有多少服务器？什么数据库？LAMP 中的哪个“ P”（php，perl，python， 等）？降低服务质量的示例？ 多肉，少起毛.. :) 至少与先前 CNBC 文章中详述的内容相同。 我怀疑游戏是否触及了 Verica 集群。 那是一个离线处理系统 本文并未明确说明使用哪个数据存储来保存每个数据库及其服务器场。 是 MySQL 吗？ MySQL 集群？ 其他一些 NoSQL DB？ 这是一个很好的简介。 但与往常一样，细节中还是“恶魔”。 我们在哪里可以获得有关实际应用程序堆栈/硬件的更多指标，从而可以很好地了解可扩展性和可扩展性？ 显然，它在 Amazon EC2 上运行。 只需在上面放一个嗅探器，您就会看到详细信息。 因此，他们的 Web 2.0 策略是尽可能利用用户的驱动器和资源并减少净流量。 哇。 我永远不会认为它是 2.0，因为所有 0.1 游戏都在本地运行并且 MMRPG 相对较新，但是我知道什么。 在其他新闻中，显然有 7500 万人需要工作。 我尝试了几种网络应用程序游戏，发现它们乏味，有限且普遍乏味。 我也鄙视 facebook 上不可避免的重复性和不可避免的通知，以至于我不再使用它，而不是每月一次向远处的朋友签入。 令人惊讶的是，一个设计欠佳的博客引擎如何将新闻发布为 myspace，以及大量广告如何将数百万个广告吸引到了 Facebook。 我仍然收到不存在者的 Facebook 邀请。 仅在过去的两年中，我就已经拥有了一百多个。 似乎没人对此多说。 商业道德规则 1： 如果一家公司必须撒谎，欺骗或窃取才能开展业务，那么您会尽力避免这种情况。 除非，当然，除非您喜欢与它们进行比较，并与 yahoo（启用垃圾邮件的公司），Friendfinder（曾经是世界上最大的垃圾邮件发送者）进行比较。 这些公司通过几乎不提供任何服务来为自己做得很好。 欢迎来到炒作无所不在的美国。 @paul 我想你错过了一些事情。 这些游戏绝对可以打到 Vertica 集群。 Vertica 的一些最大客户是高频交易者，他们使用它来处理实时数据流。 您为什么认为这是一个“离线处理系统”？ 有了这样大小的集群，我相信 Zynga 可以很好地汇总其 3TB 的每日 Farmville 数据。 这是一篇带有更多参考数字的文章： http://tdwi.org/Blogs/WayneEckerson/2010/02/Zynga.aspx 我相信他们正在使用 [Wink Streaming 的 CDN](http://www.winkstreaming.com) 来执行此操作。 我想这都是关于负载分配的。 麦克风 7500 万听上去很酷，但请想象一下中国网站面临的挑战。 我的未婚夫是中国人，他们玩的农业游戏拥有数亿活跃玩家。 尊重该游戏的编码团队：） 我认为这是一个非常有趣的领域（高流量在线游戏） 谢谢 我喜欢这篇文章，但是我想了解更多有关如何实现的信息。 使用了什么“胶水”的高层次视图来将所有抽象片段组合在一起？ LAMP 堆栈是一个不错的开始，但是主要零件的快速飞越（使用的设备可获得加分）将非常酷。 无论哪种方式，Farmville 绝对是可扩展性的令人印象深刻的示例。 我喜欢它！ > 它是网络平台上最大的应用程序 嗯...闻起来像是胡说八道！ 实际上，他没有办法知道这一点。 即使无法证明，也可以确保“听起来不错”。 可降解服务的概念看起来非常不错。 有谁知道其他案例研究已经解释了吗？ 我当然想了解更多。 @Robert Schultz 仅在没有最大定义的意义上才是 BS。 即使定义了它，也可能是值得商 bat 的指标。 这是故事的另一面： http://techcrunch.com/2009/10/31/scamville-the-social-gaming-ecosystem-of-hell/ Spyder， 关于技术紧缩的文章充斥着错误的信息。 不良报价在被发现后立即被取消。 制定了一个流程来确保它不再发生。 有趣的文章，但是对他们正在使用的 LAMP 标度的技术方面有更多的了解将是很棒的。 他们正在使用 MySql 群集吗？ MySQL 复制？ 他们如何管理故障转移？ 显然他们也使用 EC2。 这对我们所有人来说都是一个很好的例子。 我真的很喜欢一个网站每天最多可扩展到 2800 万用户的事实，这在游戏界确实是一个庞大的数字，而且写工作量很大。