# MocoSpace Architecture-一個月有 30 億個移動頁面瀏覽量 > 原文： [http://highscalability.com/blog/2010/5/3/mocospace-architecture-3-billion-mobile-page-views-a-month.html](http://highscalability.com/blog/2010/5/3/mocospace-architecture-3-billion-mobile-page-views-a-month.html)  這是 [MocoSpace](http://www.mocospace.com/) 的聯合創始人&首席技術官 Jamie Hall 的客座帖子，描述了他們的移動社交網絡的體系結構。 這是一個及時的體系結構，因為它結合了多個熱門趨勢：它非常大，具有移動性和社交性。 他們認為對他們的系統特別酷的是：如何針對移動 Web 上的設備/瀏覽器碎片進行優化； 他們的多層，讀/寫，本地/分布式緩存系統； 選擇 MySQL 之上的 PostgreSQL 作為可擴展的關系數據庫。 MocoSpace 是一個移動社交網絡，每月有 1200 萬會員，頁面瀏覽量達 30 億，這使其成為美國流量最高的移動網站之一。 成員主要通過其手機 Web 瀏覽器訪問該站點，從高端智能手機到低端設備以及 Web 都可以訪問。 該網站上的活動包括自定義配置文件，聊天，即時消息，音樂，共享照片&，視頻，游戲，電子賀卡和博客。 獲利策略的重點是在移動和網站上投放廣告，以及虛擬貨幣系統和少量高級功能升級。 ## 統計資料 1. 每月 30 億頁面瀏覽量 2. 僅次于 MySpace，Facebook 和 Google（http://www.groundtruth.com/mobile-is-mobile）的流量最大的 4 個移動網站 3. 75％的行動網路，25％的網路 4. 1200 萬會員 5. 每月 600 萬唯一身份訪問者 6. 10 萬個并發用戶 7. 每月上傳 1200 萬張照片 8. 每天收到 200 萬封電子郵件，垃圾郵件 90％，每天發送 250 萬封 9. 8 位開發人員，2 位質量檢查人員和 1 位系統管理員組成的團隊 ## 平臺 1. CentOS +紅帽 2. 樹脂應用服務器-Java Servlet，JavaServer Pages，Comet 3. PostgreSQL 的 4. 記憶快取 5. ActiveMQ 的工作+消息隊列，在 Red Hat 集群中以實現高可用性 6. Squid-靜態內容緩存，嘗試使用 Varnish 但存在穩定性問題 7. jQuery + Ajax 8. S3 用于用戶照片&視頻存儲（8 TB），EC2 用于照片處理 9. F5 BigIP 負載平衡器-粘性會話，所有頁面上的 gzip 壓縮 10. Akamai CDN-每天 2 TB，每天有 2.5 億個請求 11. 監視-Nagios 發出警報，Zabbix 發出趨勢 12. EMC SAN-通過 RAID（RAID 10）大量磁盤為數據庫提供高 IO 性能，用高性能 Fusion-io 固態閃存 ioDrive 代替，成本效益更高 13. PowerMTA 用于郵件傳遞，梭子魚垃圾郵件防火墻 14. Subversion 源代碼控制，Hudson 進行持續集成 15. FFMPEG 用于移動到 Web 和 Web 到移動視頻的轉碼 16. 用于瀏覽器測試用例自動化的硒 17. 網絡層 1. 5 個 Dell 1950、2 個雙核，16G RAM 2. 5 個 Dell 6950 / R905、4 個雙核，32G RAM 18. 數據庫層 1. 2 個 Sun Fire X4600 M2 服務器，8 個四核，256G RAM 2. 2 個 Dell 6950、4 個雙核，64G RAM ## 建筑 1. 所有頁面都是動態的，具有用戶數據和自定義以及許多針對瀏覽器和設備的優化。 移動設備上的瀏覽器和設備碎片問題比 Web 上的問題要嚴重得多。 許多優化，基于瀏覽器功能的改編，對 CSS / JavaScript 的有限支持，屏幕尺寸等。移動 Web 流量通常通過網絡代理（網關）提供，而對 Cookie 的支持較差，因此會話管理和用戶標識成為一個挑戰。 2. 一個巨大的挑戰是處理移動 Web 上的設備/瀏覽器碎片-為各種設備功能進行優化（從帶觸摸屏的 iPhone 到 5 歲摩托羅拉 Razrs 的所有產品），屏幕尺寸，缺乏/不一致的 Web 標準合規性等。 我們將表示層抽象出來，以便我們可以從同一代碼庫向所有移動設備提供頁面，并維護一個大型設備功能數據庫（包含諸如屏幕尺寸，支持的文件類型，最大允許的頁面尺寸等內容），用于 推動我們網頁的生成。 該數據庫包含數百種設備和移動瀏覽器類型的功能詳細信息。 3. 根據用戶密鑰對數據庫進行分片，并具有將用戶映射到分片的主查詢表。 我們滾動了自己的查詢和聚合層，使我們可以跨碎片查詢和聯接數據，盡管這種方式并不經常使用。 通過分片，我們可以犧牲一些一致性，但是只要您不經營銀行就可以。 我們分批離線進行數據一致性檢查，目標是最終實現一致性。 大表被分成較小的子表，以提高訪問效率，減少了為更新和操作維護活動而鎖定表的時間。 用于熱備份的日志傳送。 4. 使用了多層緩存系統，數據在應用程序服務器中本地緩存，并通過 Memcached 分發。 進行更新時，我們不僅使緩存無效，然后在再次從數據庫中讀取后重新填充緩存，而是使用新數據更新 Memcached 并保存另一次數據庫訪問。 更新緩存時，無效指令會通過消息隊列發送到每個應用程序服務器上的本地緩存。 5. 分布式消息隊列用于分布式服務器通信，從用戶之間實時發送消息到系統消息（例如本地緩存無效指令），應有盡有。 6. 專用服務器，用于完全在內存中構建和遍歷社交圖，用于生成好友推薦等。 7. 負載平衡器，用于在不影響性能/流量的情況下滾動部署網站的新版本。 8. 每 2 周發布一次。 較長的發布周期=指數復雜性，更難進行故障排除和回滾。 負責部署和管理生產系統的開發團隊（由您構建，管理）。 9. Kickstart 用于自動從裸機構建服務器。 Puppet 用于將服務器配置為特定的個性，即 Web 服務器，數據庫服務器，緩存服務器等，以及將更新的策略推送到正在運行的節點。 ## 得到教訓 1. **讓您的箱子流汗**。 只要響應時間可以接受，就不要擔心系統負載過大。 我們將多達五個應用程序服務器實例包裝在一個盒子中，每個實例在不同的端口上運行。 在擴展之前，請先擴展到高端商品硬件。 可以廉價購買二手或翻新的強大 4U 盒子。 2. **了解您的瓶頸在各個層次中的位置**。 您是否綁定了 CPU 或 IO（磁盤，網絡）？ 數據庫幾乎總是受 IO（磁盤）約束。 一旦數據庫無法容納在 RAM 中，您就會碰壁。 3. **認真地配置數據庫**。 專注于優化數據庫。 擴展 Web 層既便宜又容易，而數據庫層則又困難又昂貴。 通過執行時間和執行頻率，了解系統上最重要的查詢。 跟蹤和基準化每個版本的主要查詢，需要及早發現并解決數據庫的性能問題。 我們使用 pgFouine 日志分析器和新的 PostgreSQL pg_stat_statements 實用程序實時生成概要分析快照。 4. **設計為禁用**。 能夠配置和關閉即時發布的任何內容，而無需更改或部署代碼。 負載和壓力測試很重要，但沒有什么比通過逐步分階段推出的實時生產流量進行測試了。 5. **僅在絕對必要時才進行同步通信**。 當一個組件或服務發生故障時，不應關閉系統的其他部分。 在后臺或作為單獨的線程或進程來做您可以做的所有事情，不要讓用戶等待。 盡可能批量更新數據庫。 任何在網絡外部發出請求的系統都需要主動監控，超時設置以及故障處理/重試。 例如，我們發現 S3 延遲和故障率可能很高，因此我們將失敗的呼叫排隊，然后重試。 6. **考慮在設計期間進行監視，而不是在**之后進行監視。 每個組件都應產生性能，運行狀況，吞吐量等數據。 當警報超過閾值時設置警報。 顯示所有實例（而不是每個實例）的指標的綜合圖表對于一目了然地發現問題和趨勢特別有幫助，應該每天進行檢查-如果不能很好地理解正常的操作行為，則無法識別和應對不正常的情況。 t。 我們嘗試了許多監視系統-仙人掌，神經節，Hyperic，Zabbix，Nagios，以及一些定制的解決方案。 無論您使用哪個最重要的東西，都要對它感到舒服，否則您將不會足夠使用它。 使用模板等可以輕松監視新包裝盒和服務，并在放置它們時迅速進行。 7. **分布式會話可能會產生很多開銷**。 只要有可能就進入無狀態狀態，但是當您不考慮粘性會話時。 如果服務器發生故障，用戶將丟失其狀態，可能需要重新登錄，但這很少見并且可以接受，具體取決于您需要執行的操作。 8. **監視并提防 Java** 中的全部/主要垃圾回收事件，該事件最多可以鎖定整個 JVM 30 秒。 我們使用并發標記掃描（CMS）垃圾收集器，該垃圾收集器引入了一些額外的系統開銷，但能夠消除完整的垃圾收集。 9. 當站點足夠大時，無論是站點內部還是外部，通過電子郵件等，它都會吸引垃圾郵件散布者和黑客，而 Captcha 和 IP 監視是不夠的。 必須**積極投資于檢測和圍堵系統**，這是檢測可疑用戶行為并發出警報和/或嘗試自動圍堵的內部工具。 10. **盡可能軟刪除**。 將數據標記為以后刪除，而不是立即刪除。 刪除的成本可能很高，因此要花幾個小時才能排隊，此外，如果有人犯了一個錯誤并刪除了他們不應該擁有的東西，那么回滾很容易。 11. **N + 1 設計**。 不得少于兩個。 我非常感謝 Jamie 花時間編寫此體驗報告。 這是對其他人學習的真正有用的貢獻。 如果您想共享 fablous 系統的體系結構，請 [與聯系我](../../contact/)，我們將開始。 ## 相關文章 * [移動社交網絡 MocoSpace 現已擁有 1100 萬會員](http://techcrunch.com/2010/03/17/mobile-social-network-mocospace-now-11-million-members-strong/ "Mobile Social Network MocoSpace Now 11 Million Members?Strong") * [MocoSpace 的工作方式](http://computer.howstuffworks.com/internet/social-networking/networks/mocospace.htm) 我想知道 ActiveMQ 工作意味著什么？ 很棒的帖子。 這是我們真正了解戰 the 的帖子。 保持良好的工作。 費利佩 我很好奇為什么 Sun Fire 支持數據庫？ 關于第 7 課：粘性會議更好？ 通過將用戶鎖定到特定服務器，您是否限制了更有效地進行負載平衡的能力？ 你們有 10 臺 Web 服務器。 粗略地說，如果您丟失一臺服務器，則會損失 10％的容量，并且 10％的當前訪問者將丟失會話。 使用無粘性設置，如果您丟失一臺服務器，則只會丟失 10％的容量，但不會有用戶丟失會話。 從負載平衡設置中刪除服務器將更加容易。 您正在使用 F5 進行哪種負載均衡？ 愚蠢的循環賽嗎？ 還是從每個服務器收集更具體的指標并基于此加載？ 您是將客戶端連接一直傳遞到每??個 Web 服務器，還是將 F5 用作反向代理？ 您在哪里進行 ffmpeg 編碼？ 在那些列出的服務器上還是其他地方？ 你們為什么要選擇 Zabbix 和 Nagios？ 為什么其他解決方案對您不起作用？ 您在地理上分布嗎？ 如果您在某些方面使用 S3 和 EC2，為什么不將其余基礎架構移至亞馬遜或其他云呢？ 即使有所有緩存，你們還是需要 Fusion-io 嗎？ 這真的是非常有用的帖子。 感謝您分享這一點。 是什么讓他們選擇了 PostgreSQL 而不是 MySQL？ 使用了什么標準？ 他們使用任何 Java 框架嗎？ 最好的祝福 @Maxim R 1.我們不在地理上分布 2\. F5 是基于會話的負載平衡。 有許多 iRules 導致一些流量直接傳遞到 Web 服務器，從 F5 緩存提供服務，或從 Squid 緩存提供服務 3\. ffmpeg 編碼在批處理服務器 上完成。4\. S3 和 EC2 相當 昂貴。 我們可以從戴爾購買一個全新的盒子，然后在幾個月內拿回我們的錢，而不是幾個大型實例。 由于我們不必處理“嘈雜的鄰居” ，因此性能也更可預測。5。顯然，使用分布式會話將為我們提供更大的靈活性，但是會帶來較大的開銷。 使用粘性會話是/有中間立場。 6.關于 Fusion-IO，所有頁面都是動態創建的，因此我們需要很高的 I / O 吞吐量。 隨著站點的增長，I / O 要求也隨之提高。 您曾想過[哇，這些家伙看起來不錯/專業]直到 `Development team responsible for deploying to and managing production systems "you built it, you manage it"` 部分。 如果我是你，我會在投資者會議上保密。