业务分析
技术挑战
请求响应要快：无论成功失败，需要尽快返回给用户
架构设计
前端：静态化
站点层：限制请求数
服务层：乐观锁写缓存
数据库CAP：读写高可用，一致性，扩容
高并发核心问题
数据负载，网络带宽
站点层（web服务器压力）
服务器层（应用服务器压力）
数据层（数据库压力）
吞吐量
- 控制流量标准
应该根据库存总量进行流量控制，假如库存总量是1万，需要10台服务器处理，但参与秒杀的访客可能有5万，
理论上需要50台服务器支撑，但是完全没有必要为了那4万将要被淘汰的访客去新增40台服务器，因为根本没有意义。
需要多少太服务器是根据业务量和服务器处理能力来决定，而不是根据QPS来决定的。
数据安全一致性：超卖，数据库和缓存同步
悲观锁思路
队列思路
乐观锁思路
雪崩，过载保护
防作弊
通过一个账号，一次性发出多个请求
多个账号，相同IP，一次性发送多个请求
多个账号，不同IP，一次性发送多个请求
https://my.oschina.net/xianggao/blog/524943
https://my.oschina.net/u/2458458/blog/649822
http://www.csdn.net/article/2014-11-28/2822858
http://hansionxu.blog.163.com/