# 將 Kim Kardashian 擴展到 1 億個頁面 > 原文： [http://highscalability.com/blog/2015/2/16/scaling-kim-kardashian-to-100-million-page-views.html](http://highscalability.com/blog/2015/2/16/scaling-kim-kardashian-to-100-million-page-views.html)  [PAPER](http://www.papermag.com/) 小組估計他們的 [文章](http://www.papermag.com/2014/11/kim_kardashian.php) （NSFW）包含 非常裸露的 [Kim Kardashian](http://en.wikipedia.org/wiki/Kim_Kardashian) 的圖片將很快獲得超過 1 億的頁面瀏覽量。 突發性病毒驅動流量的非常定義。 與 2013 年相比， [估計為](http://www.cnet.com/news/google-search-scratches-its-brain-500-million-times-a-day/) Google 每天處理超過 5 億次搜索。 因此，裸露的金·卡戴珊（Kim Kardashian）值得擁有 Google 的五分之一。 奇怪的是，我可以相信。 他們如何處理這個交通金礦？ 保羅·福特（Paul Ford）在 [中完整講述了幕后的故事，《 PAPER Magazine》的網絡工程師如何為 Kim Kardashian](https://medium.com/message/how-paper-magazines-web-engineers-scaled-kim-kardashians-back-end-sfw-6367f8d37688) （SFW）擴展后端 。 （順便說一句，在這個故事中，只有一個雙關語是故意制作的，其他都是偶然的）。 我們可以從經驗中學到什么？ 我知道你在想什么 這只是一個靜態頁面，帶有一些靜態圖片。 這不是一個復雜的問題，例如 [搜索](http://highscalability.com/display/Search?moduleId=4876569&searchQuery=google) 或 [社交網絡](http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html) 。 像樣的 CDN 不足以處理這個問題嗎？ 您是正確的，但這還不是全部內容： 1. **突發流量**。 有一個非正式的規則，即網站的設計應能處理比一般流量大一個數量級的突發事件。 PAPER 通常在給定的月份中可以處理數十萬人，因此在壓縮的時間內增加兩個數量級的流量無疑是值得擔心的事情。 2. **提前計劃** 。 PAPER 并不信任命運，而是知道他們有一個大故事，因此他們聯系了他們的 Web 基礎架構團隊，并給了他們五天的準備時間，以確保該網站能夠處理即將來臨的觀眾。 3. **卡戴珊前堆棧**。 PAPER 在單個實例上運行在單個 AWS 區域（大小未知）中，MySQL 可能是數據庫， [可移動類型](https://movabletype.org/) 是 CMS， [龍卷風](http://www.tornadoweb.org/en/stable/) 是 Web 服務器， [Varnish](https://www.varnish-cache.org/) 是緩存。 該設置每月可為 50 萬至 100 萬的唯一身份訪問者提供服務。 4. **后卡戴珊式堆棧**。 Kardashian 之前的站點已轉換為使用預熱的負載平衡器，四臺前端計算機，共享文件系統和 Amazon 的 CloudFront CDN 的站點。 這是用于處理照片釋放的 PAPER 紙疊的 [漂亮圖](https://d262ilb51hltx0.cloudfront.net/max/2000/1*NRRjxiTzjIFBK4UlJ3m2ww.jpeg) 。 添加了四臺 m3.large 前端計算機，用于托管可移動類型，龍卷風和光油。 然后，在橫向擴展的網絡附加存儲文件系統 [GlusterFS](http://glusterfs) 上構建分布式文件系統層。 將所有媒體復制到運行在 m3.xlarge 上的 Gluster Filesystem Server。 可以根據需要添加更多的存儲節點，這就是 Gluster 帶來的好處。 前端計算機將 Gluster 用作其虛擬磁盤。 ELB 用于平衡前端計算機之間的流量。 5. **測試** 。 CDN 將處理靜態內容的負載，Varnish 將緩存網站的動態內容，ELB 將分發流量，但網站仍必須處理流量。 [帶機槍的蜜蜂](https://github.com/newsapps/beeswithmachineguns) 以每秒 2,000 個請求的速度測試系統。 目標是每秒測試 10,000 個請求，但顯然無法使用該工具來達到該速度。 6. **應急響應計劃** 。 據估計，該系統在第一個小時內可接待 3000 萬訪客，但已計劃如何根據需要啟動更多的前端服務器。 該計劃沒有使用 Chef，Puppet 甚至 Docker，顯然所需的命令存儲在 Google Docs 文檔中。 7. **Instagram 偷走了流量！** 內容創建者通常會輸給內容聚合者。 到 PAPER 網站的訪問量遠遠低于預期。 這就說明了一切。 她的 2500 萬關注者去了那里，而不是去 PAPER 的網站。” 明智的選擇：推出計劃的**部分應包括確保您從工作**中獲得最大收益的策略。 8. **紙張通過完全正面** 進行報復。 PAPER 通過發布 Kardashian 的全額裸照從 Instagram 收回了主動權。 Instagram 不允許這類圖片，因此這次訪問量流向了 PAPER。 幾天來，訪問量激增，有 3000 萬獨立訪問者。 該站點可以毫無問題地處理所有流量。 9. **返回到卡戴珊前堆棧**。 幾周后，新堆棧被拆除，舊堆棧又重新運行了該站點。 不完全是自動可伸縮性的先驅者，但是靈活性仍然很高。 10. **您的評論系統可以處理負載嗎？** 這種文章將獲得很多評論。 不要忘記評論系統的負擔。 如果失敗，即使網站的其余部分運行正常，您也會看起來很糟糕。 PAPER 使用 Facebook 的評論插件，該插件似乎可以毫無問題地處理 5,100 多個評論。 11. **估算？** 我感興趣的故事之一是 PAPER 如何將頁面瀏覽量預測為 1 億？ 這個估計推動了所有變化。 如果太大，他們會浪費很多錢。 如果它太小，它們將以不止一種方式被壓碎。 這種預測的過程是什么？ 本文非常獨特，我認為我從未讀過類似的文章。 它將許多不同的主題和受眾聚集到一個地方，并試圖將它們聯系在一起……同時保持娛樂性。 如果您是 DevOp，那么這篇文章對您來說就沒什么用了。 但是，它在與普通觀眾打交道方面做得很好，向他們解釋了運行網站所需的資源。 或者作為匿名恩人寫給我： > 我之所以喜歡它，是因為幾乎所有人（包括需要理解有關使用云資源進行擴展的信息的許多非技術人員）都可以閱讀它，以了解構建基于 Java 的動機，活動和收益。 云平臺，并將其用于可能破壞非云 IT 基礎架構的挑戰。 一個很好的故事，講述得足夠詳細，傳達了有關縮放的有用信息。 毫無疑問，某些決定值得商,，但總是如此。 保羅·福特（Paul Ford）對這種攻勢做出了強烈回應： > 書呆子喜歡做的事情之一就是看著別人的籌碼，然后說：“紙牌屋！” 實際上，我完全希望人們鏈接到本文，并寫出諸如“聽起來還不錯，但他們本應在所有串流中都使用帶有 Zastring 擴展名的 Jizzawatt 和 Graunt.ns 的東西。” ## 相關文章 * [在 Reddit 上](http://www.reddit.com/r/programming/comments/2w3mis/scaling_kim_kardashian_to_100_million_page_views/) * [策略：通過快速擴展您的網站來緩解流量激增的三種技術](http://highscalability.com/blog/2014/3/19/strategy-three-techniques-to-survive-traffic-surges-by-quick.html) * [超級碗廣告商準備好了流量嗎？ 不，它熄滅了](http://highscalability.com/blog/2013/2/6/super-bowl-advertisers-ready-for-the-traffic-nopeits-lights.html) 。 * [關于構建有效的高流量 Web 軟件的 22 條建議](http://highscalability.com/blog/2013/12/16/22-recommendations-for-building-effective-high-traffic-web-s.html) * [StubHub 架構：全球最大的票務市場背后的驚人復雜性](http://highscalability.com/blog/2012/6/25/stubhub-architecture-the-surprising-complexity-behind-the-wo.html) * [使用內存網格](http://highscalability.com/handle-1-billion-events-day-using-memory-grid) 每天處理 10 億個事件 * [技術星期二：我們的技術堆棧](http://imgur.com/blog/2013/06/04/tech-tuesday-our-technology-stack/) * [在 ELB 前面放上清漆的兩個問題](http://www.reddit.com/r/devops/comments/2t8ib2/how_paper_magazines_web_engineers_scaled_their/cnx7n13)