简介
秒杀：同一时刻有大量的请求争抢购买同一个商品并完成交易的过程。
秒杀系统本质上就是一个满足大并发，高性能和高可用的分布式系统。
原则
架构原则：4要1不要
- 数据要尽量少
- 用户请求的数据能少就少(包括上行和下行数据，数据传输需要时间，网络阐述涉及到压缩，字符编码，消耗CPU)
- 系统依赖的数据能少就少(后台服务，数据库交互。序列化反序列化消耗CPU，数据库本身可能瓶颈)
- 请求数要尽量少(CSS/JS/imgs 额外的请求需要三次握手，不同的域名 dns解析，解决：http://www.baidu.com??a.jpg,b.css,c.js)
- 路径要尽量短(发起请求到返回数据全链路，99%99%99%99%99%=95%，解决：RPC→JVM内部消化)
- 依赖要尽量少(系统分依赖等级，不被非核心模块拖垮，如优惠券服务)
- 不要有单点(没有备份，风险不可控，解决：服务无状态，MCC配置)
总结如下：
1.请求数据尽量少，从而减少cpu消耗
2.访问路径尽量短，减少节点消耗
3.强依赖尽量少，减少加载时间
4.不要有单点，要有备份
5.减少额外请求，减少加载时间
实战不同场景下的不同架构案例
1.商品购买页增加定时按钮，秒杀开始按钮可见，库存卖完，活动结束。
2.秒杀系统单独成立未一个系统，便于针对性优化。如去掉店铺装修等非核心功能；独立部署集群机器，不影响正常的商品售卖；热点数据(库存)单独放到一个缓存系统，提高读性能；增加秒杀答题，减少机器抢单。
3.页面彻底动静分离，抢宝按钮，刷新少量数据；服务端缓存商品数据，减少第三方系统依赖；增加系统限流，防止最坏情况发生。
缺点，性能越优化，越缺少通用性
