1. 高并发
高的并发量普通的关系型数据库是顶不住的，这个时候当然可以使用Redis来进行缓存处理，但单机的Redis我感觉3-4W的QPS还是能顶得住的，再高了就没办法了。大量的请求进来，就可能出现缓存雪崩，缓存击穿，缓存穿透等问题，当这个服务挂了可能还会影响其他的服务
解决的方式如下：
① 服务单一职责
现在设计都是微服务的设计思想，然后再用分布式的部署方式
也就是我们下单是有个订单服务，用户登录管理等有个用户服务等等，那为啥我们不给秒杀也开个服务，我们把秒杀的代码业务逻辑放一起。单独给他建立一个数据库，现在的互联网架构部署都是分库的，一样的就是订单服务对应订单库，秒杀我们也给他建立自己的秒杀库，这样就是就算秒杀没抗住，秒杀库崩了，服务挂了，也不会影响到其他的服务。（强行高可用）
② Redis集群
单机的Redis可能顶不住，那就多找几个兄弟啊，使用Redis集群，主从同步、读写分离，我们还搞点哨兵，开启持久化直接无敌高可用
③ 库存预热
开始秒杀前你通过定时任务或者运维同学提前把商品的库存加载到Redis中去，让整个流程都在Redis里面去做，然后等秒杀介绍了，再异步的去修改库存就好了
④ 资源静态化
秒杀一般都是特定的商品还有页面模板，现在一般都是前后端分离的，所以页面一般都是不会经过后端的，但是前端也要自己的服务器啊，那就把能提前放入cdn服务器的东西都放进去，反正把所有能提升效率的步骤都做一下，减少真正秒杀时候服务器的压力
2. 恶意请求
为了避免机器脚本刷单，我们可以对请求进行限流
① 前端限流：
这个很简单，一般秒杀不会让你一直点的，一般都是点击一下或者两下然后几秒之后才可以继续点击，这也是保护服务器的一种手段。
② 后端限流：
秒杀的时候肯定是涉及到后续的订单生成和支付等操作，但是都只是成功的幸运儿才会走到那一步，那一旦100个产品卖光了，return了一个false，前端直接秒杀结束，然后你后端也关闭后续无效请求的介入了。Tip：真正的限流还会有限流组件的加入例如：阿里的Sentinel、Hystrix等
3. 链接暴露
链接要是提前暴露出去可能有人直接访问url就提前秒杀了，为了避免提前秒杀
① 需要做个时间的校验
没到秒杀时间就进来的请求一律不处理
② 按钮控制
没到秒杀前，一般按钮都是置灰的，只有时间到了，才能点击
但是，就算不能提前秒杀，提前知道链接的地址比起页面人工点击的还是有很大优势。
我知道url了，那我通过程序不断获取最新的北京时间，可以达到毫秒级别的，我就在00毫秒的时候请求，我敢说绝对比你人工点的成功率大太多了，而且我可以一毫秒发送N次请求，搞不好你卖100个产品我全拿了
① 解决这个问题就是把URL动态化
通过MD5之类的加密算法加密随机的字符串去做url，然后通过前端代码获取url后台校验才能通过，这样就连写代码的人都无法提前知道真正的url
