对于资源加锁的一些思考

本文主要介绍"微信抢票"与“THU琴房预约”项目中处理资源访问竞争问题的一些对比与思考。

1. 项目简介

“微信抢票“是一个基于Django框架、用于微信公众号的抢票系统，主要功能是创建活动、处理抢票。

"THU琴房预约"是一个基于Koa框架、用于微信小程序的琴房资源预约系统，主要功能是管理琴房，处理预约。

这两个项目均比较复杂，这里仅仅挑出存在资源访问竞争的模块进行分析。

2. 加锁问题

2.1 为什么要加锁？

对于以上两个项目，我们首先考虑其核心流程：

• 用户看到这个活动仍然有余票之后，用户开始抢票（“微信抢票“）
• 用户看到这个琴房这个时间段没有被占用，用户开始预约（"THU琴房预约"）

考虑如下情形：

竞争现象

用户A和B同时看到这个活动还剩一张票，（即，这两个用户均认为自己用获得此资源的能力），A和B同时抢票，（因为这两个用户的系统通过先前的数据获取已经判定这两个人均可以抢票）。于是，A和B同时获得了这张票，同时总票数变成了-1。即出现逻辑错误。

因此为了使得一个资源不能被两个人同时使用，我们提出了”加锁“的方案。

2.2 什么情况加锁？

经过上面的分析，我们可以发现问题：在A、B之中某个人抢到票之后，另一个人依然依据的是之前所获得的数据，在老数据中显示仍然有余票。

2.2.1 有读有写才加锁

上述过程其实是有锁的，在A和B更改数据的过程中其实有一个”写锁“，使得一个资源只能被一个进程更改。但是尴尬的是，A和B一前一后对数据进行的更改，一个把余票从1改为0，另一个从0再改为-1。

如果让A、B在他们更改数据的时候也准确获得到能否更改此数据就可以了。这样后面更改的人会获取到“此时资源已经被占用了，不能抢占了“的信息，即一张票不会重复被抢占。

打包方案

所以解决方案就是，我把”读取”与“更改”打包成一个事件M，我们使得对于M，每次只能有一个资源进行M操作即可，这样保证了，A和B按照顺序执行M，假设A首先执行完成M操作，B再执行的时候，会首先获取”是否可以抢票“，这样完成了资源的加锁。

2.2.2 新增删除不必加锁

这里是指”新增与更改“、”删除与更改“不必加锁呢，因为这两个操作不会造成数据错误（就是一张票被两个人抢到）。

• 新增：在新增之前，还没有这条数据，所以不必担心与更改的竞争

• 删除：在删除之后，不会有这条数据，所以也不必担心与更改的竞争

  但是删除需要的是：在删除一个活动之前需要查看这个活动是否有票在用户手中，并且票可用。

2.3 如何加锁（乐观与悲观、阻塞与非阻塞）？

• 悲观与乐观：

  刚刚提到的使得A和B只能有一个人在执行操作M的方案，其实是”悲观锁“，就是指，不允许无依据的更改。同时还有乐观锁，就是将检查放在更改后，如果检查数据不符合规范，则再改回去。

乐观锁

• 阻塞与非阻塞：

  阻塞锁是指在A进行操作的时候，B会等待，在A访问结束之后，B获取资源，会形成一个阻塞队列。非阻塞锁是指，A进行操作的时候，B不会等待，直接返回。

  两者各有利弊。比如票数这个数字，这就是需要阻塞锁的，因为在它被改了一次之后，依然可以更改；但是，比如对于每一张票，如果要删除一张票，两次删除操作不需要等待，因为改过一次之后就不用再更改了。

2.4 真的锁住了吗？

2.4.1 定义事务的缺陷

在Django中采用了我们提到的打包操作的方案，定义了事务with transaction，即同一时刻，只能有一个进程在这个”事务“所定义的代码流程中。对于抢票这一个操作，这样是可以保证票数资源被锁住的。因为票数只可能被抢票更改。

但是如果增加一个操作，比如管理员可以随之新增或者减小若干票。

这样对于票数这个资源，”抢票“和”管理员更改“这两个操作均可以更改，这就十分尴尬了，因为，我们如果打包M（查看信息+抢票），N（查看信息+管理员更改），这样不能解决M和N同时发生的情况。

其实可以这样打包一个MN（判断操作+选择M或者N），这样所有操作均调用一个函数，这个函数会变得非常庞大。

这不是一个好方法。

2.4.2 使用信号量

对于前面的情形，其实我们只需要让M和N也不会在同一时刻发生即可。

这样就可以定义一个信号量X，如果X为1，可以发生M和N之中的一个，如果X为0，则不能发生。在M和N发生前，首先获取这个信号量，如果获取到，就把信号量置0，在结束值置1。

对于这个方案，在RedLock中有实现。之后会有一个详细的介绍。