悲观锁

有锁,每次只有一个人能访问某个数据,这和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;
  1. (也行, 因为数据库有默认锁)
UPDATE SET a = a - 70

那还有不有其他方式?

  1. 乐观锁试一试
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能正确执行的原因.

文章来源于互联网:乐观锁和悲观锁

发表评论