悲观锁
有锁, 每次只有一个人能访问某个数据. 这和Go中的互斥锁一样, 只不过在生产环境中分布式锁用得更多. 如 redlock.
分布式锁最大的问题就是性能很差, 在高并发下的需要做额外的性能优化.
乐观锁
可以同时访问, 但是为了保证数据不出错, 需要做额外的判断, 如版本号对比, 下面会详细说.
用一个例子来说明"乐观锁"的作用
进程1
SELECT money
计算余额: 100 - 40 = 60
SET money=60
进程2
SELECT money
计算余额 100 - 30 = 70
SET money = 70
这个时候最终结果可能是 60 也可能是 70, 但不是正确的 30.
用行锁当然可以解决这个问题:
你可以:
BEGIN;
SELECT a FOR UPDATE;
// a = 100 - 70
UPDATE SET a = 30;
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能正确执行的原因.