秒杀的设计

目录

秒杀场景：

可能出现的问题：

 高并发：

 超卖： 

 数据库：

链接暴露：

解决的方案：

服务职责单一：

秒杀连接加盐值：

Redis：

nginx ：

资源静态化

限流：

        前端限流：

        后端限流：

按钮控制：

库存预热：

lua：

RabbitMQ消息队列：

总体流程：

---

秒杀场景：

 一共一千台ps5，几十万的人同时抢。

可能出现的问题：

 高并发：

        同一时间出现同时的大量的请求，时间短，用户量大，对服务器的压力大。

 超卖： 

        同时多个线程来修改数据库，有可能会信息错误，多卖出很多。

 数据库：

        大量用户同时访问数据库，有可能会导致数据库的崩溃；

链接暴露：

         秒杀商品的链接在开始秒杀前暴露了，开始秒杀前有大量用户访问服务；

解决的方案：

服务职责单一：

             利用微服务的设计思想，给秒杀做一个单独的服务，给秒杀建一个单独的数据库，实现低耦合，秒杀崩了不影响其他地方的使用；

秒杀连接加盐值：

        利用md5等加密算法，给秒杀商品的链接进行一个加密，就算是开发者本人都不知道连接；

Redis：

        用redis进行数据处理，redis处理是原子性的还存储在内存里，访问速度快，服务器压力小；一台redis顶不住？多加几台。做好redis集群，主从同步，读写的分离，开启redis持久化，添加哨兵等等

nginx ：

        一台nginx可以顶住几万的并发，还可以实现负载均衡；

资源静态化

        把前端的静态资源提前放到服务器内，减少秒杀时服务器的压力；

限流：

        前端限流：

        点击一次要过一段时间才能点下一次；

        后端限流：

        流量过大后开始限流；限流后流量还是过大要降级；降级后还是过大要熔断，不要影响其他服务的使用；

         利用sentinel和Hystrix组件进行限流；

按钮控制：

        前端的任务，秒杀开始前秒杀按钮要是灰的不可以点击；防止秒杀开始前服务器压力过大；

库存预热：

        秒杀开始以前把商品信息放到redis里，用户在redis里面操作，秒杀过后，把redis里的数据异步修改，去减少数据库里的库存；

 但是有可能超卖

lua：

        lua脚本类似redis的事务，是原子性的，不会被其他的命令插队；把减少库存的操作放到lua脚本里，库存为0就直接返回false；

        lua脚本现在我也不会，后期加强学习；

RabbitMQ消息队列：

        把同时大量的用户消息放到队列里，然后从队列里慢慢拿信息去修改数据库的库存；

总体流程：

参考了：敖丙大佬的文章