# 《 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 萬用戶的事實，這在游戲界確實是一個龐大的數字，而且寫工作量很大。