业务测试中我遇到的乐观锁小栗子

今天刚好看到龙哥的「开发中常遇到的接口幂等性问题及实现」深有体会，在业务中接触过也大概总结过，今天就举个小栗子给大伙说明一下乐观锁，欢迎大家学习讨论~

悲观锁和乐观锁概念

悲观锁

对数据修改抱有悲观态度的并发控制方式，成为悲观锁；通俗点就是，ABCD同时对数据库一条数据进行修改，A打架赢了BCD（竞争资源），A在修改该条数据进行上锁，告诉BCD，我在修改这条数据，你们谁都不能动！

数据库中的行锁，表锁，读锁，写锁，以及 syncronized 实现的锁均为悲观锁。

乐观锁

乐观锁是对于数据冲突保持一种乐观态度，操作数据时不会对操作的数据进行加锁，只有到数据提交的时候才通过一种机制来验证数据是否存在冲突。AB同时对数据库一条数据进行修改，且带上版本号v1，A打架赢了B（竞争资源），A修改数据后，这条数据版本号为v2，到了B去修改时，原先带上的v1版本号和这条数据的版本号v2不一致，B就会执行失败，提示数据冲突。

乐观锁小栗子

供应链这边有个业务场景相对来说操作比较频繁（实时调度页面），业务经常在页面上进行排线操作，随意拖动事项，这时候司机在进行运输任务，有可能实际路线上的事项已经变更了，但司机看到的还是旧路线的事项，为了避免这一情况，可以引入乐观锁+版本号解决锁竞争问题，从而友好提示司机路线已经变更。

举个demo说明一下：

司机A请求进来，查询到的承运计划为以下数据

SELECT * FROM scs_shipping_order_plan WHERE shipping_order_id = '202211033878' ORDER BY arrival_time

这时候后台运输调度员进行事项实时调度，对事项数据进行update，这里相当于事项绑定了承运单号时

UPDATE scs_shipping_order_plan SET shipping_order_id = '202211033878' WHERE id = 5994

这时候司机A去完成承运单下的事项，但因为页面没有刷新，导致新加入的事项跳过了，没被完成

UPDATE scs_shipping_order_plan a JOIN scs_shipping_order b ON a.shipping_order_id = b.shipping_order_id  SET a.complete_status = 3 WHERE a.shipping_order_id = '202211033878' AND a.id = 5991

为避免上述情况，引入乐观锁+版本号，后台运输调度员进行事项实时调度，除了对事项数据进行update，还需要将承运单的版本号进行+1，这样就能友好提示司机

UPDATE scs_shipping_order_plan SET shipping_order_id = '202211033878' WHERE id = 5994
UPDATE scs_shipping_order SET version_no = version_no+1 WHERE shipping_order_id = '202211033878'

司机A选中承运单下的某一个事项，带上版本号去操作

UPDATE scs_shipping_order_plan a JOIN scs_shipping_order b ON a.shipping_order_id = b.shipping_order_id  SET a.complete_status = 3 WHERE a.shipping_order_id = '202211033878' AND a.id = 5991 AND b.version_no = 10