秒杀架构思路

总体思路
削峰限流：
前端+Redis拦截，只有redis扣减成功的请求才能进入到下游
MQ堆积订单，保护订单处理层的负载，Consumer根据自己的消费能力来取Task，实际上下游的压力就可控了。重点做好路由层和MQ的安全
引入答题验证码、请求的随机休眠等措施，削峰填谷
安全保护：
页面和前端要做判断，防止活动未开始就抢单，防止重复点击按钮连续抢单
防止秒杀器恶意抢单，IP限流、UserId限流限购、引入答题干扰答题器，并且对答题器答题时间做常理推断
IP黑名单、UserId黑名单功能
过载丢弃：QPS或者CPU等核心指标超过一定限额时，丢弃请求，避免服务器挂掉，保证大部分用户可用
页面优化，动静分离
秒杀商品的网页内容尽可能做的简单：图片小、js css 体积小数量少，内容尽可能的做到动静分离
秒杀的抢宝过程中做成异步刷新抢宝，而不需要用户刷新页面来抢，降低服务器交互的压力
可以使用Nginx的动静分离，不通过传统web浏览器获取静态资源
nginx开启gzip压缩，压缩静态资源，减少传输带宽，提升传输速度
或者使用Varnish，把静态资源缓存到内存当中，避免静态资源的获取给服务器造成的压力
异步处理：
redis抢单成功后，把后续的业务丢到线程池中异步的处理，提高抢单的响应速度
线程池处理时，把任务丢到MQ中，异步的等待各个子系统处理（订单系统、库存系统、支付系统、优惠券系统）
异步操作有事务问题，本地事务和分布式事务，但是为了提升并发度，最好牺牲一致性。通过定时扫描统计日志，来发现有问题的订单，并且及时处理
热点分离：
尽量的避免秒杀功能给正常功能带来的影响，比如秒杀把服务器某个功能拖垮了
分离可以提升系统的容灾性，但是完全的隔离的改造成本太高了，尽量借助中间件的配置，来实现冷热分离
集群节点的分离：nginx配置让秒杀业务走的集群节点和普通业务走的集群不一样。
MQ的分离：避免秒杀业务把消息队列堆满了，普通业务的交易延迟也特别厉害。
数据库的分离：根据实际的秒杀的QPS来选择，热点数据分库以后，增加了分布式事务的问题，以及查询的时候跨库查询性能要差一些（ShardingJDBC有这种功能），所以要权衡以后再决定是否需要分库
避免单点：各个环节都要尽力避免

降级：临时关闭一些没那么重要的功能，比如秒杀商品的转赠功能、红包的提现功能，待秒杀峰值过了，设置开关，再动态开放这些次要的功能