大促跟秒杀系统最大的不同在于——秒杀大部份下单请求是被拒绝的。而双十一这种活动，是尽可能将所有请求都受理。否则就会出现损失。 持续时长一般比秒杀业务长，秒杀的高并发可能是几分钟内的，而大促活动，可能持续几小时。 并发数预测大幅度小于秒杀。
基于以上的前提设计系统。 首先，基础架构方面。大促持续时长虽然高于秒杀。但是仍然并非常态。所以，计算资源应该是支持弹性伸缩的。应对大促时，增加服务副本数量，平时将资源释放。 cdn 静态资源缓存的设计可以沿用。 网关层面，根据源IP或者用户控制请求频率。还是之前的问题，秒杀，你可以把处理不了的请求直接拒绝掉，但是大促情况下不可以。损失一个订单，就是一笔收益。所以根据ip或者用户，进行限流。 为了节约短时间内的高并发请求，也可以尝试引入消息队列中间间，将部分请求先受理，排队处理，服务器空闲时候再处理这些业务。
总结一下的话，核心就是：弹性伸缩，资源预留；用户限流，限制请求；短时间高并发，MQ削峰填谷；
