本文主要是介绍如何应对美国春晚“超级碗”带来的海量访问请求？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
来自：http://www.infoq.com/cn/news/2013/02/advices-on-superbowl-spike
笔者说明：这篇转载的文章列举到的一些站点优化策略，对搭建高性能的服务具有借鉴意义。
美国时间2013年2月4日，美国人民的春晚——美国橄榄球联盟（NFL）第47届“超级碗（Super Bowl）”总决赛——在新奥尔良穹顶体育场上演。“超级碗”有三个最吸引人之处：精彩的比赛、中场表演、比赛中插播的广告。
本届超级碗峰值家庭收视率达到71%，因此是广告主的必争之地，平均价格达到每30秒400万美元。诸多广告中，很多都号召观众去网站互动，因此导致众多网站不堪重负。
Yottaa是一家专门提供网站优化服务的公司，据他们监控，共有13家网站在本次事件中被不同程度拖垮。以可口可乐为例，其网站的加载时间达到62秒。SodaStream、Calvin Klein、Axe、Got Milk？以及其他电影和汽车站点亦受影响中枪。
那么如何避免类似情况呢？Yottaa提供了4点建议：
- 减少网页上的元素数量的大小，创建更小、更轻量级的页面，以保证页面加载更快；
- 使用网站性能监控，以全天候发现任何网站可能发生的问题；
- 使用CDN，从地理位置上离你遍布世界各地的用户更近，减少网站的大部分流量；
- 根据预测的流量执行实时负载测试，要度量你的网站在高负载下的实际表现，这是唯一的方式。
个人开发者Michael Hamrah也在自己的博客上撰写了一篇文章《如何应对“超级碗”这样的高峰流量》，文中也给出了一些建议：
- 做出假设。
要敢于假设你的流量模式。这有助于你针对自己的特定情形进行优化。很多面向大众的网站，其访问都是匿名的，特别是像超级碗这样的流量高峰。因为你可以针对所有的匿名用户提供完全一样的内容，你可以让他们访问完全一样的静态页面。缓存控制决定了内容多久仍有效，并可使用HTTP加速器和CDN进行分发。不用针对每个人都做优化，将用户分类，为大多数优化。把页面上的缓存规则设为1分钟，这都可以降低应用负担，释放有价值的资源。匿名用户可以更快下载静态缓存内容，动态用户将可以更快地访问服务器。
你也可以针对高度动态的内容创建特定的渲染管道，供匿名和已知用户使用。如果你能早些识别匿名用户，就可以避免代价高昂的数据库查询、外部API调用或是页面渲染。
笔者备注：其实是说明需要进行容量模型的设计。
- 理解HTTP
HTTP是web的基础，更深入地理解HTTP，你就更好地利用工具优化页面。要特别注意Http报头的缓存设置，这让你可以利用Varnish和CDN这样的web加速器。使用不同 的报头针对匿名和已知用户，你可以对各自访问的内容有更精细的控制。过期报头决定内容的新旧程度。最糟糕的做法，就是把缓存报头设置为不公开静态内容，阻止浏览器缓存本地内容。
- 使用Varnish和ESI
Varnish是一个HTTP加速器，它可以缓存网站产生的动态内容。Web框架常常有自己的内容缓存特性，但是Varnish让你可以完全越过应用栈，提供更快的响应时间。你可以向更多连接发送已渲染好的动态页面，就像发送内存中的静态页面一样。
Edge Side Includes简称ESI，是将静态和动态内容混合在一起。如果一个页面对所有人来说有90%是接近的，那么你可以在Varnish中缓存90%，然后让应用服务器发送其他10%。ESI刚刚在web框架中出现，在Rails 4中，它会占据更重要的地位。
- 使用CDN和多个数据中心
如果你在多个数据中心中运行Varnish服务器，这就等于创建了自己的CDN。数据库和内容也许存放在东海岸，但如果你在西海岸运行一台Varnish服务器，你在旧金山的用户就会得到更快的响应时间，你也可以减少一个到应用服务器的链接。即使Varnish必须通过东海岸的ESI发送10%动态内容，它也可以利用数据中心之间更快的连接。
- 使用自动扩展组或警告
自动扩展组是AWS的出色功能，尤其达到某个阈值最大值的时候。如果你没有使用AWS，优秀监控工具能帮你采取行动。如果你在设计应用时考虑到了自动扩展，在内部通信使用负载均衡器，也是不错的选择。
- 压缩并序列化数据
如果开启压缩，页面大小就能大幅降低。Web流量主要是文本，易于压缩。别忘了内部通信也可以压缩。在当今这个API驱动的世界里，诸如协议缓存这样的高效序列化协议可以大幅降低网络流量。很多RPC工具支持某种形式的序列化优化。SOAP是二十一世纪早期的热门方法，但从速度角度考虑，XML是最差的数据序列化方法。压缩内容能在缓存内保存更多东西，同时降低网络I/O。
- 关闭某些特性
在高流量时刻，关闭表现不正常的特性是解决问题的最快方式。
笔者备注：设计需要具有柔性可用，具有多级灰度能力。
- 非阻塞的I/O
异步编程充满挑战，也许是扩展性的最后一道关隘。有时，网站服务器崩溃了，却看不出达到任何阈值。也许你曾看到一个缓慢的请求，但是内存、CPU和网络的访问指标都很正常。这种情况常常是由于某种形式的I/O线程被阻塞然后等待造成的。被阻塞的线程让其他事情都停下来。基于异步的框架，比如node.js，将异步编程放在前端，让它们处理更多并发请求。异步编程还为基于队列的架构铺平道路。如果每个请求都通过队列处理，这有助于缓解流量高峰。队列大小会决定你需要多少个队列的worker。异步也许不太好理解，但这是处理扩展的重要方式。
笔者备注：架构具备异步化的能力，对关键路径进行异步化处理。
Michael的最后一个建议是总结性的：
- 以扩展的方式思考
在高负载环境中处理问题时，一切都要考虑在内。针对几千个用户没有问题的方法，要是用来对付几百万用户，可能就失去控制了。即使是最小的问题，也会以指数级增长，变得不可收拾。
扩展不仅仅是要想到用来对付负载的工具，而是要决定你的应用如何表现。最重要的事情，是要判定页面内容对于用户的新旧程度。对于每个用户都提供秒级的更新，或是针对匿名用户提供分钟级的更新，二者的决策完全不同。在应对数百万并发请求时，一个会带来很多工程上的复杂度，另一个则可以快速解决。
笔者备注：架构需要具备横行水平扩展的能力。
这篇关于如何应对美国春晚“超级碗”带来的海量访问请求？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
