秒杀系统设计方案

微服务设计思想，分布式部署

前端方面
静态页面，CDN抗衡峰值
灰色按钮，禁止重复提交
用户限流，ip限流

访问接口
隐藏秒杀接口，URL动态化，MD5加密防止脚本毫秒级别的秒杀，高安全
通过拦截器和自定义注解来控制接口访问频率，高安全
设置登录验证，用户带上加密字符串来合法访问，高安全

高并发问题
单机redis一般几万的QPS没问题，如果再高就得考虑集群了
既然用到了redis做缓存的话，缓存雪崩，缓存击穿，缓存穿透也是我们应该考虑到的问题
最后通过redis的主从架构，读写分离，主节点负责写，并将数据同步给其他节点，从节点负责读，从而实现高并发
如果采用了主从架构，读写分离，搭建了redis集群，开启master的持久化也是必要的，达到高可用效果
tomcat服务器支持几百的并发量，使用Nginx做负载均衡

超卖问题
提前把商品的库存加载到redis中去，redis的decr预减库，
当我们采用主从架构的时候在遇到高并发的时候到可能会超卖这时候就会用到redis的Lua脚本，
Lua脚本就相当于是redis的事务来解决redis的事务操作，
接下来我们可以用用户id和商品id作为redis的key值，通过布隆过滤器的标识来判断是否秒杀成功，然后减库，
最后当判断到库存为0后把开关变为false秒杀结束

秒杀成功
100个请求当然没啥问题，如果秒杀上万，数据库又得GG，这时候就得用到消息队列MQ的异步处理，先把请求放到消息队列里面然后再一点一点的去修改库存，最终达到削峰的效果

数据库
每秒10几万的QPS打在数据库上面，直接把数据库打炸，牵扯到其他服务，全站404
单独建立秒杀数据库，写sql的时候explain执行计划，秒杀库崩了也不会影响到其他服务，高可用
秒杀订单添加用户id和商品id联合的唯一索引
update数据库where库存>0，防止超卖

全局考虑
限流，降级，熔断，即使秒杀挂了也不影响到其他服务

参与架构分析，搭建eureka集群，编写生产消费者，业务逻辑，熔断降级，config配置中心