奥运会观众入场管理办法与网络应用四种应对突发访问的方法的对比

Travis Reeder在Spikability一文中给出了四种应对突发访问的方法：

1. 资源充裕。预先评估峰值，部署足够多的服务器，保证系统可靠运行在任何环境下。缺点是系统空闲时资源利用率低。

2. 功能降级。禁用部分不太重要的功能，保证基本功能的可用性。

3. 自动扩容。当系统繁忙时自动向系统中添加新的服务器并部署应用。缺点是部署复杂，响应不迅速。另外还有一个缺点，当系统访问量不稳定时，可能导致颠簸，有服务器反复上线下线。

4. 请求队列。在突发请求出现的时候，队列会充满。利用充满队列的时间差，可以启用更多的服务器来处理队列上的请求。这么做的好处是不会浪费资源，峰值出现的时候服务器会满负荷运转。缺点是延迟增加了。

我的一个朋友（ @monkey59）曾参加过2008年北京奥运会某个体育馆的志愿者服务工作。她描写了奥运会组织者是在观众入场环节是如何运营和调控的。他们用到的方法跟以上4中策略不谋而合。

1、场馆设置了足够多的入口。即：所有观众都选择在同一时间点进入场馆也不会出现大规模的混乱。对于一般赛事，这意味着“资源充裕”。
2、场馆设置了特别通道：包括残疾人通道、老年人通道等绿色通道，方便某些在入场环节有特别需求的观众能够有专属于自己的入场渠道，不必和其他通道的观众争抢。这与“功能降级”策略刚好相反，是一种“功能升级”。如果我们将保证老弱病残顺利进场理解成核心功能，那么这也是一种“功能降级”的思想。
3、场馆实现轮班制，入口根据情况全部开放或部分开放。事实上所有观众都选择在同一时间点入场的情况是非常少见的。根据好运北京测试赛的数据统计，大部分观众会选择提前一个小时至一个半小时入场。那么也就存在高峰期和非高峰期的区别。高峰期时开放所有入口，每个入口大约有2-3名志愿者负责引导和检票。比赛开始后观众流量会明显减少，这时不必浪费人力资源，选择性的关闭某些入口，并减少志愿者的数量。“动态入口开放”策略，实际上就是一种“自动扩容”策略。

4. 显然，进管必须排队，这在现实场景中是自然满足的。

参考英文：

1. http://blog.iron.io/2012/06/spikability-applications-ability-to.html

2.http://highscalability.com/blog/2012/7/12/4-strategies-for-punching-down-traffic-spikes.html

Travis Reeder in Spikability - An Application's Ability to Handle Unknown and/or Inconsistent Load gives four good ways of handling spikey loads:

1. Have more resources than you'll ever need. Estimate the maximum traffic you'll need and keep that many servers running. Downside is you are paying for capacity you aren't using.
2. Disable features during high loads. Reduce load by disabling features or substituting in lighter weight features. Downside is users to have access to features.
3. Auto scaling. Launch new servers in response to load. Downsidesare it's complicated to setup and slow to respond. Random spikes will cause cycling of instances going up and down.
4. Use message queues. Queues soak up work requests during traffic spikes. More servers can be started to process work from the queue. Resources aren't wasted and features are disabled. Downside is increased latency.