秒杀活动系统简单分析

问题点：

1.高并发：
时间短，瞬间并发量大，考虑缓存雪崩，缓存击穿，缓存穿透。
2.超卖：

3.恶意请求：
搞很多服务器脚本疯狂请求。

4.链接暴露：
相信是个开发同学都对这个画面一点都不陌生吧，懂点行的仔都可以打开谷歌的开发者模式，然后看看你的网页代码，有的就有URL，但是我写VUE的时候是事件触发然后去调用文件里面的接口看源码看不到，但是我可以点击一下查看你的请求地址啊，不过你好像可以对按钮在秒杀前置灰。

不管怎么样子都有危险，撇开外面的所有的东西你都挡住了，你卖这个东西实在便宜得过分，有诱惑力，你能保证开发不动心？开发知道地址，在秒杀的时候自己提前请求。。。

5.数据库：
每秒上万甚至十几万的QPS（每秒请求数）直接打到数据库，基本上都要把库打挂掉，而且你服务不单单是做秒杀的还涉及其他的业务，你没做降级、限流、熔断啥的，别的一起挂，小公司的话可能全站崩溃404。

以上问题该怎么解决呢？

1.单一职责：服务单独部署，代码单独一套，数据库单独的一个，即使秒杀崩了也不影响其他的服务。
2.url动态化，特殊字符串通过md5摘要，然后后端校验通过才能使用。
3.限流：
**物理控制：**大家有没有发现没到秒杀前，一般按钮都是置灰的，只有时间到了，才能点击。

这是因为怕大家在时间快到的最后几秒秒疯狂请求服务器，然后还没到秒杀的时候基本上服务器就挂了。

这个时候就需要前端的配合，定时去请求你的后端服务器，获取最新的北京时间，到时间点再给按钮可用状态。

按钮可以点击之后也得给他置灰几秒，不然他一样在开始之后一直点的。

**前端限流：**这个很简单，一般秒杀不会让你一直点的，一般都是点击一下或者两下然后几秒之后才可以继续点击，这也是保护服务器的一种手段。

**后段限流：**秒杀的时候肯定是涉及到后续的订单生成和支付等操作，但是都只是成功的幸运儿才会走到那一步，那一旦100个产品卖光了，return了一个false，前端直接秒杀结束，然后你后端也关闭后续无效请求的介入了。

Tip：真正的限流还会有限流组件的加入例如：阿里的Sentinel、Hystrix等。我这里就不展开了，就说一下物理的限流。

我们卖1000件商品，请求有10W，我们不需要把十万都放进来，你可以放1W请求进来，然后再进行操作，因为秒杀对于用户本身就是黑盒的，所以你怎么做的他们是没感知的，至于为啥放1W进来，而不是刚好1000，是因为会丢掉一些薅羊毛的用户，至于怎么判断，后面的风控阶段我会说。

nginx:
Nginx大家想必都不陌生了吧，这玩意是高性能的web服务器，并发也随便顶几万不是梦，但是我们的Tomcat只能顶几百的并发呀，那简单呀负载均衡嘛，一台服务几百，那就多搞点，在秒杀的时候多租点流量机。
风控：
这个时候就需要风控同学的介入了，在请求到达后端之前，风控可以根据账号行为分析出这个账号机器人的概率大不大，我现在负责公司的某些特殊系统，每个用户的行为都是会送到我们大数据团队进行分析处理，给你打上对应标签的。

redis集群：
之前不是说单机的Redis顶不住嘛，那简单多找几个兄弟啊，秒杀本来就是读多写少，那你们是不是瞬间想起来我之前跟你们提到过的，Redis集群，主从同步、读写分离，我们还搞点哨兵，开启持久化直接无敌高可用！

库存预热：
秒杀的本质，就是对库存的抢夺，每个秒杀的用户来你都去数据库查询库存校验库存，然后扣减库存，撇开性能因数，你不觉得这样好繁琐，对业务开发人员都不友好，而且数据库顶不住啊。
我们要开始秒杀前你通过定时任务或者运维同学提前把商品的库存加载到Redis中去，让整个流程都在Redis里面去做，然后等秒杀介绍了，再异步的去修改库存就好了。
防止超卖：使用redis事务进行处理 , watch, multi, exec, discard

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

这个为啥要做呢，不怕一万就怕万一，万一你真的顶不住了，限流，顶不住就挡一部分出去但是不能说不行，降级，降级了还是被打挂了，熔断，至少不要影响别的系统，隔离，你本身就独立的，但是你会调用其他的系统嘛，你快不行了你别拖累兄弟们啊。

消息队列（削峰填谷）：
一说到这个名词，很多小伙伴就知道了，对的MQ，你买东西少了你直接100个请求改库我觉得没问题，但是万一秒杀一万个，10万个呢？服务器挂了，程序员又要背锅的。

秒杀就是这种瞬间流量很高，但是平时又没有流量的场景，那消息队列完全契合这样的场景了呀，削峰填谷。

数据库
数据库用MySQL只要连接池设置合理一般问题是不大的，不过一般大公司不缺钱而且秒杀这样的活动十分频繁，我之前所在的公司就是这样秒杀特卖这样的场景一直都是不间断的。

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

至于表就看大家怎么设计了，该设置索引的地方还是要设置索引的，建完后记得用explain看看SQL的执行计划。

总结：
到这里我想我已经基本上把该考虑的点还有对应的解决方案也都说了一下，不知道还有没有没考虑到的，但是就算没考虑到我想我这个设计，应该也能撑住一个完整的秒杀流程。

最后大家再看看这个秒杀系统或许会有新的感悟，是不是一个系统真的没有大家想的那么简单，而且我还是有漏掉的细节，这是一定的。

参考：https://zhuanlan.zhihu.com/p/169464555