回忆一下数据库中的锁问题

在我们日常的工作中，有些业务是需要严格控制顺序和次数的，比如我今天要说的关于微信上面体现的逻辑。

业务场景:

微信用户发起提现请求，用户输入提现金额，请求接口！然后我们就会生成一条提现的请求，一个定时任务扫描这张表，进行企业大款的操作。

那么问题在哪里呢？假设用户连续两次发起请求，提现6元，请求几乎同步的情况下。代码中两次验证可提现金额都通过了(因为取出来都是10，都大于6)，这个时候去操作表，减少这个可提现金额，就可能减到负数，然后生产了两条提现的记录到表中，定时任务一扫，就进行了两次打款，血亏！所以需要避免这种情况！

解决方式是什么呢！像这种情况下，一般的思路是用乐观锁的方式去解决(乐观锁只是一种概念，没有具体的锁)，当然也可以用悲观锁，for update暴力锁住这条记录，然后修改，提交。但是这样一来就效率比较低下。

那么乐观锁，顾名思义就是比较乐观了，相信一般情况下是不会发生这种情况的，所以直到提交更新的时候才去检测是不是有数据的冲突，如果有冲突就直接告诉用户有问题就完事了

那么具体是什么意思呢？就微信提现这个业务逻辑来说 update user set have_money = （have_money - 6） where (have_money - 6) > 0 and id=2;

这样如果这条语句执行失败，说明可提现余额不足了，也不需要新增一个提现请求记录了。这种方式是条件限制式的乐观锁，另外一种方式是版本号的形式，这种形式大家可以自行百度。

原文地址：https://www.cnblogs.com/changeCode/p/11272745.html