一、秒杀系统为什么难？（难点在哪里？）
1、场景分析
场景1：QQ即时通讯业务
业务特点：细粒度的数据查询
业务场景：
查询个人用户信息
查询好友列表
查询加入的群列表
......
场景分析：
上述的即时通讯的业务场景可看到，无论是个人用户信息，还是好友列表，这部分数据均是用户自己的信息，只有自己才会查询，所以与他人发生锁冲突的几率极低。即使并发大，数据量大，也可以通过水平切分数据的方式进行支持。
场景2：微博Feed流业务
业务特点：读多写少，少量的锁冲突
业务场景：
加载关注的用户列表
获取用户的Feed消息列表
对消息进行排序
返回排好序的第一页数据
场景分析：
大多数的用户都是读取数据的操作，只有少部分人是写数据操作，当读取数据的时候，对方正在写数据时，会出现一定的锁冲突。
场景3：秒杀业务
业务特点：读多写少，少量的锁冲突
业务场景：
读取是否还有剩余商品（余票），是读取操作。
抢购商品（余票），是写入操作。
剩余商品（余票）的数量是有限的，且是公用资源。
场景分析：
业务场景中，需要发生大量的读取请求，读取的是公共资源，因为公共资源较少，所以需要抢占资源，导致很多写请求进入，出现极大的锁冲突。
2、总结归纳
由上面的三个场景，我们可以看到，其实系统的难度是如何解决数据库锁冲突的问题，秒杀系统的读多好解决，我们引入缓存，即可支撑该读多的操作，但是写多的操作才是解决大量锁冲突的关键。
二、秒杀业务的架构解决方案
架构的解决原则：降低数据层的锁冲突。
架构的解决方案：
降读（降低数据库读取操作）：引入缓存
降写（降低数据库读取操作）：将请求拦截在上游
系统架构的分层方案：
- 浏览器（前端）
- 站点层（Tomcat）
- 服务层（后台服务）
- 数据层（MySQL、Redis）
将请求拦截在上游的方案：
1、浏览器的拦截
请求防重处理：例如每5s只能发起一次请求
2、站点层的拦截
去除无效请求：根据用户id进行计数，控制每个用户id，5秒内只能发起一次请求。
3、服务层的拦截
使用削峰限速：按库存和数据库抗压能力进行请求的透过。
4、数据层
支持高可用：设置两个数据节点，支持高可用。
架构设计上常见的问题及解决方案：
问题1：压力最大的在站点层，如何解决?
解决方案：做服务降低操作，对重复请求进行默认返回。
问题2：站点层如何进行计数？
解决方案：可以引入Redis进行中间件计数，Redis一秒可支持几十万个请求，使用Redis集群即可支持100W的请求。
问题3：Redis为外部中间件，大量的并发会有带宽瓶颈问题，如何解决？
解决方案：可以考虑使用服务本机内存进行计数，虽然违背了微服务无状态化设计，但是这部分数据丢失对服务的影响不大，所以可以考虑。
问题4：采用内存进行计数，如果解决用户访问单一服务器的问题？
解决方案：可以通过Nginx配置通过用户id进行分发请求的策略，这样同一个用户id就会落到同一个站点服务。
问题5：为什么服务层释放请求的数量要按库存数和数据库抗压能力来释放？
解决方案：如果释放的数量大于库存数，一部分请求是失败的，给数据库增加和浪费系统IO，如果大于数据库的抗压能力，数据库会发生宕机，无法办理业务，那导致服务不可用，重启数据库也无法解决。
三、产品的设计折中方案
方案1：支付和下单流程分离
业务分离，可以降低数据库的写压力，例如买票业务，下单后，45分钟内完成支付，支付业务在另一个服务内，另一个数据库内。
方案2：分城市差异化销售流程
不同班次，不同城市，在不同的时间点进行销售，完成业务的分流。
方案3：按钮只能点击一次
页面防重点，这样可以减少页面的无效请求。
方案4：库存的显示粒度加粗
例如显示班次余票，只显示有无余票，并不显示具体余票数，这样缓存信息只需要更新两次。
四、秒杀业务的缓存结构设计
待更新........
