主要解决瞬时高并发、处理速度、商品超卖的问题。

1、秒杀的相关服务要单独开发，单独部署。与正常的服务实例做隔离。绝不要傻乎乎地使用原来商城的相关接口。

2、不用DB，用缓存（本地缓存、Redis）存库存。

3、基于MQ的异步。

商品详情页的处理

秒杀前用户会停留在此页面，不停地刷新。可以将页面存入Redis、服务实例的本地缓存，甚至是使用用户浏览器的本地缓存（此者最佳），从而减少服务端的处理压力。

秒杀的开始时间

详情页的倒计时都是JS根据用户本地时间计算的，但对有编程经验的人来说，完全可以拿到下单的URL直接访问，所以服务端必须校验时间，不到开售时间不通过。

因为机房肯定有时钟，保证了所有服务器时间一致，就可以在Redis或服务实例的本地缓存上设一个标识available_spu_111:false。下单请求过来时校验，如果是false，再校验时间，如已过开售时间，请求通过，false->true。

库存的处理

既要防止超卖，又要处理迅速，减少用户等待时间。

假设本次秒杀准备了10万个库存，我们准备放出20万个名额供用户参与秒杀。在用户预订时，就下发token（0~9），直至发放完毕。后来预订的用户token就为-1等特殊标识，或者不给token，代表本次秒杀就只能请您捧个人场了，服务端只需服务20万用户的请求即可。

假设我们准备了10个服务实例，秒杀服务数据预热的时候，将10万个库存均分其中，可以用RedisX10，也可以直接用服务实例的本地缓存。用户的请求根据token（0~9）转发至这10个服务实例上。可以用服务端的网关（Nginx、Zuul、Gateway等），也可以准备10个URL，让前端控制访问。

至于没拿到token的用户，在秒杀的时候前端根本不发请求到服务端，减少并发，前端页面就做个排队的样子即可。如果防止有编程经验的人抓包发现没发请求的尴尬局面，那就专门拿出一个服务实例接收这些用户的请求，啥也不做直接返回200，页面继续显示排队抢购。这只是限流方案的一种，如果不想给人一种钦定的感觉，也有其他方案，比如通过扩展Nginx进行限流、令牌桶等。

拿到token的用户，被均分到某一实例上。2万个用户去抢1万个库存，这时不论用JVM的锁还是Redis自身的原子性，都能保证快速处理且不超卖。

当然，这种处理方式也会带来一些问题，例如：

实例A，2万个用户，前1万用户把库存抢完了。实例B，2万个用户就是进来看看，一个库存都没抢。这就造成了1万用户想秒没秒到，1万个库存想卖没卖出去的尴尬局面。

如果服务实例还能承受更高的并发，且业务也要求库存必须秒出去，那可以把这1万用户的请求转到其他服务实例上碰碰运气。也可以就直接认了这个局面，但是我们可以在一定时间后（30、45分钟等），以“追加”、“从可疑订单处回收”、“未支付订单”的名义再放出来，二次秒杀。

最后

就是其他流程了，用MQ即可，不再详述。

秒杀结束后，数据再同步至数据库。