大战618，决胜双十一 高并发秒杀系统解密

写在前面

2011年618京东事件能够看出来，高并发对服务器压力仍是很是大的，京东去年618最后仍是经过延长事件来解决，可是这次苏宁策划好像并不是借鉴这次事故的经验，发生了同样的问题，记得不错的话，taobao也发生过同样的事情、12306购票也被骂死，，因此在策划方案中要充分考虑此种特殊状况下该怎么办预案...

image

本文附详细视频，须要的可在文末领取！

秒杀业务分析

image

那些场景属于秒杀业务？

1. 商品抢购
2. 群红包
3. 优惠卷领取
4. 抢火车票
5. 在线预定
6. ……

小蝌蚪跑步比赛 起点线的故事

image

image

关于锁的那些事

悲观锁解析

对于悲观锁的概念解释主要有两种，但本质上悲观锁主要用于数据库访问的并发控制上。

• 解释一

悲观锁是指对数据被外界（包括本系统当前的其余事务，以及来自外部系统的事务处理）修改持保守态度，所以，在整个数据处理过程当中，将数据处于锁定状态，在悲观锁的状况下，为了保证事务的隔离性，就须要一致性锁定读。读取数据时给加锁，其它事务没法修改这些数据。修改删除数据时也要加锁，其它事务没法读取这些数据。

• 解释二

在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它能够阻止一个事务以影响其余用户的方式来修改数据。若是一个事务执行的操做都某行数据应用了锁，那只有当这个事务把锁释放，其余事务才可以执行与该锁冲突的操做。

悲观锁处理流程

1. 在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）
2. 若是加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常
3. 若是成功加锁，那么就能够对记录作修改，事务完成后就会解锁了
4. 其间若是有其余对该记录作修改或加排他锁的操做，都会等待咱们解锁或直接抛出异常

悲观锁优势

• 悲观并发控制其实是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。
• 悲观锁基于DB层面实现，对业务代码无入侵，使用方便

悲观锁缺点

• 悲观锁适用于可靠的持续性链接，诸如C/S应用。 对于Web应用的HTTP链接，先天不适用
• 锁的使用意味着性能的损耗，在高并发、锁定持续时间长的状况下，尤为严重。 Web应用的性能瓶颈多在数据库处，使用悲观锁，进一步收紧了瓶颈
• 非正常停止状况下的解锁机制，设计和实现起来很麻烦，成本还很高
• 不够严谨的设计下，可能产生莫名其妙的，不易被发现的死锁问题
• 悲观的缺陷是不管是页锁仍是行锁，加锁的时间可能会很长，这样可能会长时间的限制其余用户的访问，也就是说悲观锁的并发访问性很差

乐观锁解析

在关系数据库管理系统里，乐观并发控制（又名“乐观锁”，Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务可以在不产生锁的状况下处理各自影响的那部分数据。在提交数据更新以前，每一个事务会先检查在该事务读取数据后，有没有其余事务又修改了该数据。若是其余事务有更新的话，正在提交的事务会进行回滚。乐观事务控制最先是由孔祥重（H.T.Kung）教授提出。

相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。通常的实现乐观锁的方式就是记录数据版本

优势与不足

乐观并发控制相信事务之间的数据竞争(data race)的几率是比较小的，所以尽量直接作下去，直到提交的时候才去锁定，因此不会产生任何锁和死锁。但若是直接简单这么作，仍是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，通过修改之后写回数据库，这时就遇到了问题。

乐观锁实现流程

保证三步操做原子性

image

image

秒杀核心 服务实战

手把手实现核心服务

• 基于mysql经过版本号实现；
• 基于mysql经过状态实现；
• 基于memcached的cas机制实现；

缓存实现乐观锁方案

image

进一步的思考

1. CAS机制就能完全解决秒杀的问题？
2. 架构师眼中，秒杀系统的全貌？