# 将 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)