如何应对美国春晚“超级碗”带来的海量访问请求？

美国时间 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 的最后一个建议是总结性的：

• 以扩展的方式思考

在高负载环境中处理问题时，一切都要考虑在内。针对几千个用户没有问题的方法，要是用来对付几百万用户，可能就失去控制了。即使是最小的问题，也会以指数级增长，变得不可收拾。

扩展不仅仅是要想到用来对付负载的工具，而是要决定你的应用如何表现。最重要的事情，是要判定页面内容对于用户的新旧程度。对于每个用户都提供秒级的更新，或是针对匿名用户提供分钟级的更新，二者的决策完全不同。在应对数百万并发请求时，一个会带来很多工程上的复杂度，另一个则可以快速解决。

看到美国人民的春晚导致的网站崩溃之后，你认为会在中国人民的春晚播放时发生吗？