乐观锁和悲观锁
悲观锁
有锁，每次只有一个人能访问某个数据，这和Golang中的互斥锁一样。
如果是在分布式下使用锁，可以使用如 redlock这样的外部服务。
既然是外部服务，业务复杂度会更高 性能也差，所以如果业务中使用了数据库，也可以使用数据库的锁，这会更简单高效。
乐观锁
和悲观锁相反，乐观锁不具备真正的锁，所以可以同时访问和更新，但是为了保证数据不出错，需要做额外的判断，如版本号对比。
用一个并发扣款的例子来说明"乐观锁"的作用
进程1
SELECT money // 100
// 扣除40元，计算余额: 100 - 40 = 60
SET money = 60
------
于此同时进程2也正在执行以下代码
SELECT money // 100
// 扣除30元，计算余额 100 - 30 = 70
SET money = 70
这个时候最终结果可能是 60 也可能是 70，但不是正确的 30，这就是典型的并发下数据不一致的问题。
用行锁当然可以解决这个问题:
BEGIN;
SELECT a FOR UPDATE;
UPDATE SET a = 30; // a = 100 - 70
COMMIT;
- (也行, 因为数据库有默认锁)
UPDATE SET a = a - 70
那还有不有其他方式?
- 乐观锁试一试
SELECT a
// a = 100 - 70
UPDATE SET a = 30 WHERE a = 100
看好了 WHERE a = 100就是乐观锁, 就能解决刚刚的 60或70被错误保存的问题, 因为 UPDATE SET a=70 WHERE a =100; 和 UPDATE SET a=60 WHERE a =100 永远只有一个会执行成功.
执行失败了怎么办?
- 让用户重试, 比如抢票时, 如果没抢到就提示让用户重试就可以了.
- 系统自动重试.
可以看出在高并发下乐观锁会有很多操作执行不成功, 乐观锁是否就没有存在的必要?
个人认为需要结合自己业务而定, 如:
- 对于用户购买订单等核心但并发不高的业务逻辑, 还是使用悲观锁更好, 原因是对成功率的要求 > 对性能的要求.
- 对于如抢票等并发巨大且用户期望的成功率不高的情况下, 可以使用乐观锁, 以免过大的性能要求压垮服务器.
PS: 当然别忘了消息队列也是解决高并发下数据一致性的不错方案.
ABA问题
在刚才的例子中, 最初用户有100元余额, A B会话同时读取到余额为100, 然后A会话将钱更新为60元以后, C会话将余额有更新到100元, 这时候B会话在更新余额的时候发现还是100元, 就会更新成功, 但是这时候的余额状态已经不是最初的100元的状态了, B的更新很可能就会造成错误数据.
如何避免这个问题呢?
其实正确的乐观锁实现方式应该是版本号, 而不是上面例子提到的余额字段, 每当数据需要更新 都应该更新版本号SET version = version + 1, 这样就能保住不会出现ABA问题.
幂等问题
有时, 服务会发生重试, 如网络抖动等情况, 就拿用户充值来说, 如果用户只支付成功一次, 如果加钱逻辑执行两次那肯定是不行的.
如果你有使用消息队列, 也会知道消息会保证至少被投递一次, 而不能保证只投递一次, 所以做好幂等逻辑是有必要的.
无疑, 任何锁都解决不了幂等问题, 这时候需要一个如"流水表"一样的状态表去记录并检查状态:
- 如只有订单支付状态由待支付变为支付成功才会增加余额, 在增加余额之前必须要判断订单状态.
- 如添加事件/事务ID逻辑, 在增加余额的时候需要去判断这个事件是否已经处理过了.
在分布式事务中一定会处理这个问题, 而分布式事务则是一个更复杂的系统 需要另开文章, 所以我会在另一篇文章: 分布式事务中详细说到如何实现幂等.
QA
问: 并发执行 UPDATE SET a=70 WHERE a =100; 和 UPDATE SET a=60 WHERE a =100 为什么永远只有一个成功?
答:
先弄懂数据库的默认锁:
InnDB引擎会在UPDATE, DELETE , INSERT语句时为涉及到的记录添加 排它锁 (X)
这也是为什么UPDATE SET a=a+1能正确执行的原因.
