【秒杀系统】概要设计

1 查看商品详情页

接下来介绍并发量从低到高设计查看商品详情页

第一种：

用户 -> 浏览器 -> 后端系统 -> MySQL (弊端：无法抗住高并发)

第二种

用户 -> 浏览器 -> 后端系统 -> Redis -> MySQL（通过缓存可以加快用户查看商品详情的速度，但还有优化空间）

第三种

用户 -> 浏览器 -> 后端系统 -> JVM内存 -> Redis -> MySQL （在加入一级缓存来减少与Redis的交互，减少IO，也可以优化速度；但是，加入JVM内存它能抗住的并发也是有限的，如果想让它抗住10万并发它肯定不行）

第四种

假设单台机器能抗住1万并发的访问，那么部署多台服务，通过Ngingx来做负载均衡将请求转发到各个服务中；同时在nginx这一层可以直接访问Redis，将商品详情通过这一步来完成

第五种

商品详情页中有很多静态资源，例如CSS JS HTML等，如果这些静态资源都到服务器上获取，则会浪费服务器的性能；这时我们可以将这些静态资源缓存到 CDN(内容分发网络) 上去，这样浏览器就可以直接到CDN上取静态资源了，要比去服务器上取静态资源要快的多。

但还有一种优化空间，就是这个页面显示的数据还得去后端查询出来；

第六种

利用页面静态化技术，提前把后端的数据渲染到页面上，让后把这个渲染好的页面放到CDN给用户访问，这样用户看到的页面就有数据了，就不用到后端去请求数据了，从而减轻服务器的压力；

2 秒杀下单

第一种

用户发送秒杀下单请求 -> 浏览器 -> 后端系统（创建订单，扣减库存）-> MySQL
弊端：高并发下操作数据库会产生锁竞争，导致数据不安全即系统整体性能下降；

第二种

可将库存数量提前读取到 Redis 中，然后扣减库存的操作都在 Redis中进行；这种操作需要解决缓存与数据库数据保持一致问题；

第三种

添加消息队列，扣减库存的操作还是在 Redis 中进行，将扣减库的信息发给 mq，然后 mq 去通知 MySQL 去扣减库存，用这种异步的方式去同步数据库中的库存；但是这边还涉及到两个问题，一个是 MySQL 消费mq消息失败怎么办，另一个是数据库创建订单时失败了怎么办；这边就涉及到了分布式事务，可以使用支持事务的 Rocket mq

第四种

解决库存商品被秒杀完，用户还不停地秒杀商品的问题：
可以添加一个令牌的概念，即用户在秒杀之前需要先到系统获取一个令牌，再去秒杀商品；如果用户没有带着令牌去请求秒杀接口则直接返回失败；那么限制这个令牌数就可以防止用户不断地发送秒杀请求了；另外这个令牌数一般要设置比秒杀商品数大，需要防止一些用户秒杀到了商品不付款的情况；

第五种

虽然加入了令牌的概念，但是我们的秒杀活动不可能只秒杀一件商品，这个秒杀的接口承载的压力还是很大，那么我们要加入限流的操作，比如说我们的系统只能承载10000的并发，那么我们就可以进行限流，比如限流到8000qps，这个限流的好处是不至于让太大的流量把系统打垮。

第六种

尽管做了8000qps限流操作，如果发送意外情况，这个8000qps的请求也很可能打垮系统，这时我们需要做一个熔断降级的操作去短暂保护我们的系统，暂时只能让一小部分的流量去请求我们的接口，等接口恢复时再把接口完全开放出来，同时配合降级逻辑即提示系统繁忙请稍后再试的操作；且运维的人员也要实时检测系统的可用性，一旦系统被打垮，需要给我们整一个秒杀系统集群动态地添加节点去抗高并发；