关于秒杀系统的思考

关键点：
1. 秒杀是一种在短时间内极其耗费资源的活动，其收益比需要仔细评估。秒杀不应该做为一种常规活动运营，甚至，应该尽可能避免上线秒杀活动
2. 秒杀的最终压力是库存并发修改。系统设计的核心在于流量层层疏导，使最终落地到库存操作上的请求在设计能承担的范围内。同时保证接入层在瞬时巨大流量的冲击下，仍能正常响应提供服务


秒杀活动的挑战在于：
1. 大规模高并发请求量
2. 集中在对秒杀商品的库存值修改上，要保证修改操作是原子性
3. 防作弊，防刷防机器自动请求
4. 柔性能力，防雪崩
5. 部署能力，不影响非秒杀的正常业务




基本的解决思路：


一、资源配置判断
1. 判断请求量大小。一般至少按正常时的访问量放大15到20倍吧，视具体业务。但这个不会很准，所以有可能的话应该尽可能放大这个值（我们曾经按15倍的请求量估算过，然而最后实际的量是30倍！当然这个要视商品的热度）
2. 判断接入机单机能撑起的最大量。比如说单个请求耗时100ms，单机运行20个进程，那理论上单机支持能力是1000/100*20=200个左右。注意要评估下若达到峰值请求时，单机资源(cpu/内存, 主要是cpu)负载不应该超过80%，最多不能超过90%，否则系统将变得不稳定
3. 由1和2判断需要接入机数量
4. 判断落到后端server(或其它逻辑层、DB层)请求量的大小。评估当前配置下后端能否支撑起前端的请求量。若不能，考虑采用削峰等一系列优化策略。
5. 判断依赖的其它支撑服务，比如登录，鉴权，资格判断等，容量是否能支撑本次活动，是否需要扩容或做柔性降级处理


二、优化策略
1. 动静分离。主要是页面上，不变的部分放到cdn去，js更新改变的部分（大多就是价格和库存）。
2. 防刷。比如禁止同ip访问频率过高，禁止同用户访问频率过高等。很多人认为这个步骤较为繁琐，而且“可能”作用不大。但我们实际证明，这一条是很有效的，可以帮你挡掉差不多一半的无效请求量
3. 如果还是撑不住，考虑削峰。比如从产品层面上，将秒杀设置在一段时间的几个点上，比如4个小时内的每个整点，或者从技术上，比如粗暴的，直接随机丢掉一部分请求。要明白决定做秒杀，就不可能也无法保证绝对公平
4. 缓存，预热。可以在接入机上做缓存，比如把库存量直接推到每个接入机的内存中，这样从接入层面上，至少可以保证当库存为0后，可以立即返回失败。但并不能保证放到后端去的请求就一定能秒杀成功。注意有的服务是需要“预热”的，特别是有使用了一些缓存的服务。否则在请求启动之初，大量请求命中不到缓存，造成堆积，加剧系统负载。
另外使用缓存其实也是一种系统的负担，容易造成数据不一致的，需要仔细考量。
5. 从代码层面上看，代码必须要简洁，避免一些复杂的架构设计，越简单越好，代码路径越短越好。在条件判断上，尽早启动一些否定性判断，一票否决丢弃无效请求(实际上大部分请求可能在接入层就被一些活动限制条件直接否决了)
6. 柔性服务，注意保护，防雪崩。当用户发现响应缓慢或失败时，会立即重试，数倍放大了请求量。再比如当所有服务机器都处于满负荷运转时，突然某一台挂了。这台机器的请求量会被自动调度到其它机器上，使其它机器负载加大。很可能再一次触发机器down掉。通常来说这都会滚雪球式加剧系统的压力。因此在接入层、服务层，应该有判断，当请求量超出系统设定的阈值时，应启动防雪崩机制，比如丢弃掉部分请求，或者放到队列中异步处理。
7. 可配置的开关策略。不管一切准备的如何完备，线上实际运行时总会出现各种问题。我的建议是把一些柔性策略做成开关的形式，一旦发现情况不对，直接修改开关来打开或关闭某种特性，比如说某个鉴权服务出故障了，可以立即通过开关决定不再鉴权，避免因为这个失败导致系统不可用。但如果这一切得等下重新修改代码，编译上传等重启，那就太晚了。
8. 其它一些策略，比如说通过请求队列判断（队列长度就是商品库存值），页面脚本控制刷一次就灰个几秒钟，给每个请求打上时间戳，放入队列后立即返回，然后异步处理，提示用户稍候查看等。这一类策略用户体验不够好，慎用。


三、部署及运维问题
1. 秒杀占用资源量较多，如果与正常服务的机器混合部署，有可能累耗费太多资源导致正常的服务体验受损。可以考虑分开部署。但对某些不太关键的服务、资源利用率低的服务，也可以考虑借用其机器资源，采用混合部署的方式扩大能力
2. 最好有能力支持一键扩容。在发现实际机器能力不足时，迅速扩容
3. 每个请求须打上流水信息。防止出现问题后，有补救机会(比如因某种故障，你提示用户秒杀成功，但实际用户是秒杀失败的。或者说你不明所以，但用户坚持说秒杀成功了。怎么查证的问题)