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

  • 郑柯

2013 年 2 月 6 日

话题:AWSCDNDevOpsNode.js架构

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

  • 以扩展的方式思考

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

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

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

AWSCDNDevOpsNode.js架构