秒杀（二）关于秒杀系统的思考与解决方案

目录

1、思考

2、解决方案

3、技术选型

---

 

1、思考

软件开发过程中的可行性分析就不分析了，别人都已经做出来来了，说明开发秒杀系统本身就是可行的。接下来我们要思考一下秒杀系统会遇到哪些问题？以下的内容有参考各种的资料整理出来的。

• 高并发

秒杀的特点就是这样时间极短、 瞬间⽤户量⼤。缓存雪崩，缓存击穿，缓存穿透这些都是有可能发⽣的，出现问题后请求全部到DB那就很难受了，活动失败⽤户体验差，后果很严重

• 超卖

本来准备秒杀10个MacBook pro，超卖多了20个，那就尴尬了，那最后只能杀个开发祭天了

• 恶意请求

对于懂技术的人，那很简单啊，我知道你什么时候抢，我搞个⼏⼗台机器搞点脚本，我也模拟出来⼗⼏万个⼈左右的请求

• 链接暴露

秒杀链接暴露，提前请求，稍微有点技术的人看下html和js代码就能看到秒杀的链接

• 数据库

每秒上万甚⾄⼗⼏万的QPS（每秒请求数）直接打到数据库，基本上都要把库打挂掉，⽽且服务可能不单单是做秒杀的还涉及其他的业务，如果没做降级、限流、熔断啥的，别的⼀起挂掉

2、解决方案

既然我们遇到上面的这些问题，那我们应该考虑一下怎么解决这些问题？

首先，秒杀的时候瞬间并发量很大，但是不是所有的请求都是有效的，可能是恶意请求，那么第一步应该是降低到达服务器的流量，降低服务器的压力，可以从以下方面展开：

• 限流：

前端限流

（1）秒杀前，⼀般按钮都是置灰的，只有时间到了，才能点击

（2）按钮可以点击之后也得给他置灰⼏秒，不然他⼀样在开始之后⼀直点的

后端限流

Hystrix/Sentinel

• nginx负载均衡

使用⾼性能的web服务器

• 资源静态化

秒杀⼀般都是特定的商品，现在⼀般做法都是前后端分离的，⻚⾯⼀般都是不会经过后端的， 前端也要⾃⼰的服务器啊，那就把能提前放⼊cdn服务器的东⻄都放进去，反正把所有能提升效率的步骤都做⼀下，减少真正秒杀时候服务器的压⼒。

• 秒杀链接加盐

把URL动态化，通过MD5之类的摘要算法加密随机的字符串去拼 url，然后通过前端代码获取url后台校验才能通过

接着，有些人员可能是一些羊毛党人员，就是疯狂的薅羊毛，这些人员应该通过风控拦截掉

• ⻛控

拦住羊毛党

最后需要考虑如何处理已经到达服务器的请求？可以从以下方面处理：

• Redis集群

秒杀本来就是读多写少，Redis集群，主从同步、读写分离，库存预热，提前把商品的库存加载到Redis中，Redis本身是⽀持事务的，⽽且他有很多原⼦命令的，⼤家也可以⽤LUA，解决超卖问题

• 服务单⼀职责

部署微服务，当其中一台机器挂了，不会影响别的业务

• 限流&降级&熔断&隔离

进行了降级和熔断，可以较为友好给用户提示，例如跳转到服务器正在处理的页面，而不是直接报错！

• 消息队列（削峰填⾕）

消息队列真的是削峰利器

• 数据库

单独给秒杀建⽴⼀个数据库，为秒杀服务，表的设计也是尽可能的简单点，现在的互联⽹架构部署都是 分库的。

3、技术选型

根据上面的思考内容，我们可以确定技术选型：SpringBoot + Spring Cloud + Mysql + Redis + RabbitMQ + gateway + Sentinel + Nocas