初识“锁”：解决线上作业提交系统 多人阅卷时 产生的并发问题

零、并发问题

假设，有一个线上作业系统，当阅卷时，会从数据库取出第一个未评阅的作业。
评阅完成后，会把作业状态改为“已评阅”：

这样没什么问题。

如果是两个人同时评阅呢？如果B获取作业时，A已经把作业1评阅完毕，此时B获取的是作业2。这样，似乎看上去也没什么问题。（①②③④代表时序）：

但是，这是不现实的，B不可能每次都等到A评阅完成之后再发起请求。
如果AB同时评阅，就会出现问题（①②③④代表时序）：

A和B先后从后台获取一个作业，假设A先发起请求，那么当B获取作业时，A还没有评阅完成，此时作业1还是未评阅状态。
于是B也会获取到作业1，而不是作业2。接下来，A评阅完成，此时作业1变成已评阅状态。再轮到B评阅作业1时，系统就报错了。

因此，目前的系统，由于出现了并发问题，无法实现多人同时评阅作业。

一、初识“锁”

锁的好处之一，就是在一定程度上解决了并发问题，上面提到的多人阅卷，就是一个生动的例子，此外还有其他场景，比如：取钱。
数据库的锁和事务是相关的，关于这部分内容，张喜硕学长在《MySQL RR 与 锁》中有详细的介绍。

值得注意的是，由于是第一次接触，并且这个项目比较简单，因此没必要使用Mysql中真正的事务和锁，而是用代码来实现类似“锁”效果。具体逻辑如下：

• 增加一个字段，当前评阅人CurrentUserId。
• A获取作业时，查询此字段为空的作业，查询成功后，返回作业1，设置评阅人为自己（相当于加入读锁）。
• 此时，B如果再获取作业，就不会再获取到作业1。
• 当A提交之后，清空当前评阅人字段（解锁），状态改为已评阅。

（下图①②③④代表时序）

这样，就成功解决了并发问题，无论有多少人同时评阅，也不会冲突了。

二、带时间的“锁”

以上的解决方式还存在问题，如果A获取作业1之后，并没有提交分数（比如A掉线了、或者A没有点击评阅按钮），作业1的锁，就永远不会被解除了。

这就导致，作业1不会再被别人获取到。

因此，需要为锁自动加上倒计时，一旦时间结束，如果阅卷人仍然没有评阅的话，就自动解锁，清空CurrentUserId。（下图①②③④⑤代表时序）

这样，即使在A获取作业之后没有完成阅卷，也不会遗漏掉任何作业。

总结

本文中，我们通过手写代码，实现了Mysql中“读锁”（共享锁）的功能（事实上，这段代码有点麻烦，涉及到改字段、多线程、定时任务...所以文中只谈思路）。

随着知识了解的越来越多，我们思考问题的角度，已经从如何生产一个新项目，变成了如何更新已经上线的项目。后者的要求更高，这需要我们进行更新时，必须考虑和原有数据的无缝衔接。

相信不久后的将来，我们就能学会使用真正的锁和事务来处理并发问题了。

版权声明

本文作者：河北工业大学梦云智开发团队 - 刘宇轩