秒杀系统设计
知乎上就有好多现成的例子，我就拿敖丙的来举例吧
# 秒杀系统会遇到的几个问题
- 高并发
- 超卖
- 恶意请求
- 链接暴露 暴露了请求地址，被人恶意请求
- 数据库 请求太多，导致数据库挂掉
# 解决办法
# 单一职责
就是使用微服务思想，创建一个单独的数据库和使用独立的服务器。这样即使秒杀系统挂了，也不会影响其他服务
# 秒杀链接加盐
就是把URL动态化，每次请求都生成一个随机链接，避免重复请求
# Redis集群
单机的Redis顶不住，我们可以使用集群，秒杀本来就是读多写少，Redis集群，主从同步、读写分离，我们还搞点哨兵，开启持久化直接无敌高可用！
# NGINX
Nginx大家想必都不陌生了吧，这玩意是高性能的web服务器，并发也随便顶几万不是梦，但是我们的Tomcat只能顶几百的并发呀，那简单呀负载均衡嘛，一台服务几百，那就多搞点，在秒杀的时候多租点流量机。
恶意请求拦截也需要用到它，一般单个用户请求次数太夸张，不像人为的请求在网关那一层就得拦截掉了，不然请求多了他抢不抢得到是一回事，服务器压力上去了，可能占用网络带宽或者把服务器打崩、缓存击穿等等。
# 资源静态化
前端页面有专门的服务器，我们可以提前把内容都放入CDN中，减少服务器压力
# 按钮控制
大家有没有发现没到秒杀前，一般按钮都是置灰的，只有时间到了，才能点击。
这是因为怕大家在时间快到的最后几秒秒疯狂请求服务器，然后还没到秒杀的时候基本上服务器就挂了。
这个时候就需要前端的配合，定时去请求你的后端服务器，获取最新的北京时间，到时间点再给按钮可用状态。
按钮可以点击之后也得给他置灰几秒，不然他一样在开始之后一直点的。你敢说你们秒杀的时候不是这样的？
# 限流
限流这里我觉得应该分为前端限流和后端限流。
前端限流：这个很简单，一般秒杀不会让你一直点的，一般都是点击一下或者两下然后几秒之后才可以继续点击，这也是保护服务器的一种手段。
后端限流：秒杀的时候肯定是涉及到后续的订单生成和支付等操作，但是都只是成功的幸运儿才会走到那一步，那一旦100个产品卖光了，return了一个false，前端直接秒杀结束，然后你后端也关闭后续无效请求的介入了。
Tip：真正的限流还会有限流组件的加入例如：阿里的Sentinel、Hystrix等。我这里就不展开了，就说一下物理的限流。
# 库存预热
秒杀的本质，就是对库存的抢夺，每个秒杀的用户来你都去数据库查询库存校验库存，然后扣减库存，撇开性能因数，你不觉得这样好繁琐，对业务开发人员都不友好，而且数据库顶不住啊，所以我们可以使用Redis
那不简单了，我们要开始秒杀前你通过定时任务或者运维同学提前把商品的库存加载到Redis中去，让整个流程都在Redis里面去做，然后等秒杀介绍了，再异步的去修改库存就好了。
# Lua
Lua 脚本功能是 Reids在 2.6 版本的最大亮点， 通过内嵌对 Lua 环境的支持， Redis 解决了长久以来不能高效地处理 CAS （check-and-set）命令的缺点， 并且可以通过组合使用多个命令， 轻松实现以前很难实现或者不能高效实现的模式。
**Lua脚本是类似Redis事务，有一定的原子性，不会被其他命令插队，可以完成一些Redis事务性的操作。**这点是关键。
知道原理了，我们就写一个脚本把判断库存扣减库存的操作都写在一个脚本丢给Redis去做，那到0了后面的都Return False了是吧，一个失败了你修改一个开关，直接挡住所有的请求，然后再做后面的事情嘛。
# 限流&降级&熔断&隔离
这个为啥要做呢，不怕一万就怕万一，万一你真的顶不住了，限流，顶不住就挡一部分出去但是不能说不行，降级，降级了还是被打挂了，熔断，至少不要影响别的系统，隔离，你本身就独立的，但是你会调用其他的系统嘛，你快不行了你别拖累兄弟们啊。
# 削峰填谷
一说到这个名词，很多小伙伴就知道了，对的MQ，你买东西少了你直接100个请求改库我觉得没问题，但是万一秒杀一万个，10万个呢？服务器挂了，程序员又要背锅的。
你可以把它放消息队列，然后一点点消费去改库存就好了嘛，不过单个商品其实一次修改就够了，我这里说的是某个点多个商品一起秒杀的场景，像极了双十一零点。
# 总结
