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