1.业务分析
商品查询---->创建订单----->订单支付----->卖家发货
其中创建订单又可以分为以下流程:
加入购物车----->确定订单------->修改库存------>待支付
核心在于修改库存
2.秒杀的技术难点
1.短时高并发，负载压力大
2.读多写少
3.竞争资源是有限的，不能多卖，不能少卖，不能重卖
使用synchronized相当于变成了单并发，性能太差
关于锁的那些事
乐观锁和悲观锁
悲观锁：对数据被外界修改持保守态度（悲观），因此在整个数据处理过程中，将数据处于锁定状态，旺旺依靠数据库提供的锁机制实现。使用场景：写多读少，保证数据安全。样例：行锁、页锁、表锁、共享锁（读锁）、排它锁（写锁）
乐观锁：假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突 了，则让返回用户错误的信息，让用户决定如何去做或者程序自动去充实。使用场景：读多写少，提高系统吞吐量。样例：数据库乐观锁。缓存乐观锁。
数据库乐观锁实现
1.基于mysql通过版本号实现
update t_goods_info
set amount = amount - #{buys},version = version + 1
where code = #{code and version = #{version}
2.基于mysql通过状态实现
update t_goods_info
set amount = amount - #{buys}
where code = #{code} and amount - #{buys} >= 0
tips:数据库乐观锁实现的优点在于简单高效、稳定可靠；缺点在于并发能力低；
机械硬盘，数据库并发能力300，固态700，所以数据库连接一般在300-700
3.基于memcached的CAS机制
流程：gets命令获取库存数以及版本号，检查库存是否大于购买数量，如果有足够库存则是用CAS更新商品库存，更新成功即购买成功,更新失败则当前线程随机休眠N毫秒，然后重新回到gets命令；如果库存不够，则购买失败。
进一步的思考
CAS机制就能彻底解决秒杀的问题？
架构师眼中，秒杀系统的全貌？
更深层次的架构层面：
页面层：按钮置灰，禁止用户重复提交请求，通过JS在一定时间段内只能提交一次请求
应用层：动静分离，压缩缓存处理（CDN，导流技术），即用于存放加载页面的静态资源，比如js，css之类；根据UID限频，页面缓存技术（web服务器），即你同一用户怼了1000个请求，我只让你的一个请求通过；反向代理+负载均衡（nginx）
服务层：读写操作基于缓存（memcached，redis）；请求处理排队，分批放行（队列）；热点分离
数据库层：读写分离，分库分表，数据库集群
