大流量活动的应对
大流量活动的特性是生命周期短，推广资源集中，突增流量多，对系统负载有较大的挑战，可能会对现有业务产生冲击。 在有大流量活动上线之前我们一定要做好提前准备，提前预估容量，做好扩容准备，做好应急预案。
容量预估
在确认为大流量的活动上线前需要对活动做容量预估，预估总用户量有多少，用户同时参与的可能峰值是多少？确认后评估系统能力是否能够支撑，如果不能，进行优化或扩容。评估系统时需要考虑系统本身以及支撑系统的服务的承载量。
控制节奏
控制节奏是指控制资源投放量的节奏，要有层次的将资源投放出去，不要一次性将所有资源全部砸出去，以渐进的方式，慢慢放量。如果一次性将几千万甚至上亿的量放出去，可能会导致整个活动的后台支撑系统超负载，从而影响整体活动效果。
关注用户行为
评估时考量用户的行为，识别用户的页面访问路径，如常规的活动只有一个页面，可以直接按用户数评估访问量。 如果活动一个用户一次体验流程可能会访问4到5个页面，而每个页面对后端的cgi至少产生3个请求（2个pv上报，1个用户参与状态查询），则如果有500万用户进入页面，则可能会对后端产生至少2000多万的cgi请求。如果还有页面定制的用户状态区分等，则会有更多的请求到应用服务器。
服务定制
针对大规模推广活动进行定制。此定制相对于常规逻辑来说，去掉与当前活动不相关的旁支逻辑。毕竟相对于整个系统来说，需要考虑的逻辑点会比较全，而如果只是一个活动的话，有些功能是不需要用到的，可以针对这些点做功能优化。可以考虑从入口处直接隔离，或增加定制开关。
业务隔离
承载活动运营的系统现已成为平台性的产品，有较多的业务依赖于此系统，特别是有一些非活动性的，如体系类、固化入口类的业务。 此时，当有大流量活动发布推广时需要考虑到活动本身不会对平台上其它产品产生影响，毕竟大流量活动其访问量级较大，在大资源推广时会占用服务较多的的资源，从而可能会影响其它产品的服务质量。
为保证系统上其它业务的高可用性，我们需要做业务隔离。此处业务隔离的原则：
- 代码保持一份，主干开发，保证主干的可用。
- 短期和长期的业务隔离，如通过域名分割，大流量短期活动业务启用新域名，直接扩容，流量到新机器。
如果一切顺利还好，但是往往事不与人愿，总会出一些你预想不到的情况，比如之前说好的节奏没有把控好，比如做的容量预估不够，比如……，这些比如都是我们在事前需要考虑的风险点，当这些风险出现时，我们需要做异常应对了。
假设现在流量一下子太大，已经到了服务器的负载极限，有许多用户直接被服务器拒绝服务，此时我们能够做些什么呢？ 面对这种情况我们经常做的事情是扩容。
紧急扩容
扩容说白了就是加机器，其主要是考验系统的伸缩性，在不改变其它内容，仅通过增加或减少服务器的数量来扩大或缩小应用的服务处理能力。
由于业务的调用是链式的，一环扣一环，如当我们扩容后，能够应对这些流量冲击后，这个冲击可能就会触达到后端的server，或其它给我们提供服务的第三方服务，可能会一下子把第三方整得服务不可用，因此在紧急扩容前需要梳理我们依赖于哪些服务，大流量的请求中与这些服务相关的有哪些，大概有多少量级的请求会转发到这些服务上，他们的支撑能力有多少，整体容量预估是否够用，并且需要提前沟通。
假如因为某些特殊的原因，而无法扩容。此时为保证大部分用户的服务可用，我们可能需要选择服务降级。
服务降级
当应用访问遇到高峰时，超出了应用所能处理的最大能力时，为了保证整个应用的安全可用，需要进行降级，通过拒绝部分请求及关闭部分不重要的服务将系统负载降到一个安全的水平。
降级服务可以从功能和用户两个维度实现，功能降级需要将系统拆分成独立的若干个功能点，当遇到问题需要降级服务时，保证主功能的可用，一些旁支功能可以先关闭；用户降级需要在服务端实现某种策略的服务不可用，如直接抛弃用户请求。比较简单的实现就是各种系统开关，针对可以降级的功能点和服务使用开关， 当出现需要降级的情况的时候, 就可以在后台使用开关来降级。
服务降级前需要和产品侧沟通确认。
以上忝为某活动总结。