大战618，决胜双十一 高并发秒杀系统解密
作者：互联网
写在前面
2011年618京东事件可以看出来，高并发对服务器压力还是非常大的，京东去年618最后还是通过延长事件来解决，但是此次苏宁策划好像并非借鉴此次事故的经验，发生了一样的问题，记得不错的话，taobao也发生过一样的事情、12306购票也被骂死，，所以在策划方案中要充分考虑此种特殊情况下该怎么办预案...
image
本文附详细视频，需要的可在文末领取！
秒杀业务分析
image
那些场景属于秒杀业务？
- 商品抢购
- 群红包
- 优惠卷领取
- 抢火车票
- 在线预约
- ……
小蝌蚪跑步比赛 起点线的故事
image
image
关于锁的那些事
悲观锁解析
对于悲观锁的概念解释主要有两种，但本质上悲观锁主要用于数据库访问的并发控制上。
- 解释一
悲观锁是指对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态，在悲观锁的情况下，为了保证事务的隔离性，就需要一致性锁定读。读取数据时给加锁，其它事务无法修改这些数据。修改删除数据时也要加锁，其它事务无法读取这些数据。
- 解释二
在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。
悲观锁处理流程
- 在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）
- 如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常
- 如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了
- 其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常
悲观锁优点
- 悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。
- 悲观锁基于DB层面实现，对业务代码无入侵，使用方便
悲观锁缺点
- 悲观锁适用于可靠的持续性连接，诸如C/S应用。 对于Web应用的HTTP连接，先天不适用
- 锁的使用意味着性能的损耗，在高并发、锁定持续时间长的情况下，尤其严重。 Web应用的性能瓶颈多在数据库处，使用悲观锁，进一步收紧了瓶颈
- 非正常中止情况下的解锁机制，设计和实现起来很麻烦，成本还很高
- 不够严谨的设计下，可能产生莫名其妙的，不易被发现的死锁问题
- 悲观的缺陷是不论是页锁还是行锁，加锁的时间可能会很长，这样可能会长时间的限制其他用户的访问，也就是说悲观锁的并发访问性不好
乐观锁解析
在关系数据库管理系统里，乐观并发控制（又名“乐观锁”，Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。乐观事务控制最早是由孔祥重（H.T.Kung）教授提出。
相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本
优点与不足
乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。
乐观锁实现流程
保证三步操作原子性
image
image
秒杀核心 服务实战
手把手实现核心服务
- 基于mysql通过版本号实现；
- 基于mysql通过状态实现；
- 基于memcached的cas机制实现；
缓存实现乐观锁方案
image
进一步的思考
- CAS机制就能彻底解决秒杀的问题？
- 架构师眼中，秒杀系统的全貌？
标签：618,加锁,决胜,image,事务,解密,并发,悲观,修改 来源： https://www.cnblogs.com/hulianwangjiagoushi/p/10964084.html