2 秒杀系统架构

第一步 思考面临的问题和业务场景

秒杀系统面临的问题: 短时间内并发非常高，如果按照秒杀的并发做相应的承载会造成大量资源的浪费。第二解决超卖的问题。

第二步 思考目前的处境和解决方案

因为秒杀系统属于短时间内的高并发问题，我们不可能使用那么多的硬件资源去部署对应的承载。而且还有个问题，我们其实并卖不到那么多的商品，只是做一个商品促销的噱头吸引用户到我们的平台来，让他们知道我们的平台并记下我们的平台。

那么也就是说其实大部分用户买不到商品是正常行为，所以我们可以通过这个特性把大部分的用户在服务的上游就过滤掉，而不是公平的竞争有限的商品。基于这个思想我们对我们的设计进行一些优化。

1. 用户在进行抢购前肯定是先打开页面，这是第一步。那么我们为了避免服务器资源被短时间大量的请求压垮，需要把页面静态化放到CDN上，减少服务器的压力
2. 用户在到了秒杀的时间节点为了抢到商品肯定快速的点击页面，这个请求会使用到后台的服务，我们为了减少用户频繁的请求，在前端代码做一些控制，点击按钮后置灰不能多次的点击请求后台服务
3. 用户在点击按钮无反应的情况下，可能会重写打开页面再次发起请求，可以利用页面缓存让用户在一段时间内打开的页面是缓存页面
4. 用户打开页面时候，有些实时数据肯定是要最新的，要不然用户发现是假数据或者是缓存在浏览器和CDN上的时候，用户体验很差。比如像剩余库存这些数据，但是我们又不希望这些查询请求落到数据库，所以部分数据放在缓存中，减少数据库的压力(页面缓存也可以但是需要缓存的时间短，不能太长

当我们做了上面的工作之后，还是会有大量的请求涌入到后台服务。因为要解决超卖的问题，我们在买入操作的时候肯定是要给商品的数量加锁。如果请求并发太高，会造成redis分布式锁设置的失效时间失效，也会造成超卖的问题。

我们可以在购买商品，锁库存数量之前再过滤掉一部分请求。例如我们用不加锁的缓存下商品数量，当涌入的人数超过一定数量的时候比如超过商品库存的时候，或者商品库存N倍的时候，后面的请求就不会再进入到后面的处理逻辑。