前端
资源静态化
提前将静态资源放到cdn，用户请求从最近的cdn服务器获取，减少请求静态资源服务器的压力
秒杀链接加盐
把URL动态化，就连写代码的人都不知道，通过MD5之类的摘要算法加密随机的字符串去做URL，通过前端代码去获取URL 后端校验
限流
前端
秒杀之前将按钮置灰，点击秒杀按钮之后，将按钮置灰几秒
后端
加入限流组件，比如 阿里的Sentinel，Hystrix
物理限流，如果秒杀1000件商品，有10万个请求，那么放一万个请求进去，因为有很多是薅羊毛的，这些请求可以通过风控系统拦截一部分
风控
后端
服务职责单一
开辟新的单独的秒杀微服务，建立新的秒杀库，使秒杀业务不影响现有的服务
Redis集群
主从同步、读写分离，开启哨兵，持久化
库存预热
通过运维人员提前将商品库存数据预热到Redis，减少秒杀活动开启时的瞬时压力，等秒杀活动结束后再异步的去修改库存数据
事务
如果Redis内只有一个库存，但是同时有三个人请求，那这个库存该给谁呢？如果库存扣减失败必须要启用事务，使一个事务内的所有操作失败
熔断、降级、限流、隔离
限流，顶不住就挡一部分请求回去
降级，下游的服务挂了返回统一的失败提示
熔断，不影响别的系统，不能导致服务雪崩
隔离，单个URL使用独立的线程池，当某个服务不可用不会无限制的新建线程，你不行了你别拖累其它兄弟们啊
消息队列
削峰填谷，将消息放到消息队列，然后开启一个单独的消费服务，一点点去扣减库存<br>
数据库
单独建一个秒杀的数据库，当流量上来了挂的也只是秒杀的数据库，不会影响到其它的数据库，数据体量大就涉及到分库分表<br>
分布式事务
TCC
不适合，TCC开发成本太大，所有的接口都要写三遍，因为涉及到TCC的三个阶段<br>
最终一致性
不适合，最终一致性基本上是靠轮训去保证一个操作一定成功，那实时性就大打折扣了
2PC，3PC
推荐，虽然不一定能保证数据最终一致，但是效率上还是OK的
