阅读 9

大战618,决胜双十一 高并发秒杀系统解密—后端java程序员力荐

写在前面

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. 架构师眼中,秒杀系统的全貌?

本文到此结束!喜欢的朋友可以转发文章和关注一下!感谢!

关注下面的标签,发现更多相似文章
评论