并发扣款一致性优化,CAS下ABA问题,这个话题还没聊完!!!

2,227 阅读3分钟

上一篇答星球水友提问,《并发扣款,如何保证数据的一致性?》中提到:用 CAS 乐观锁,可以在尽量不影响吞吐量的情况下,保证数据的一致性。

大家有非常多的留言,大概有这么几类:

(1)是否存在 ABA 问题?

(2)为什么不能用:

UPDATE t_yue SET money=money-diffANDmoney>=diff AND **money>=diff**;

(3)能否借助 redis 事务来扣减余额;

画外音:请务必阅读前序文章:《并发扣款,如何保证数据的一致性?》。

问题比较多,今天先聊第一个问题,ABA。

什么是 ABA 问题?

CAS 乐观锁机制确实能够提升吞吐,并保证一致性,但在极端情况下可能会出现 ABA 问题。

考虑如下操作:

  • 并发 1(上):获取出数据的初始值是 A,后续计划实施 CAS 乐观锁,期望数据仍是 A 的时候,修改才能成功

  • 并发 2:将数据修改成 B

  • 并发 3:将数据修改回 A

  • 并发 1(下):CAS 乐观锁,检测发现初始值还是 A,进行数据修改

上述并发环境下,并发 1 在修改数据时,虽然还是 A,但已经不是初始条件的 A 了,中间发生了 A 变 B,B 又变 A 的变化,此 A 已经非彼 A,数据却成功修改,可能导致错误,这就是 CAS 引发的所谓的 ABA 问题。

余额操作,出现 ABA 问题并不会对业务产生影响,因为对于 “余额” 属性来说,前一个 A 为 100 余额,与后一个 A 为 100 余额,本质是相同的。

但其他场景未必是这样,举一个堆栈操作的例子:

并发 1(上):读取栈顶的元素为 “A1”

并发 2:进行了 2 次出栈

并发 3:又进行了 1 次出栈

并发 1(下):实施 CAS 乐观锁,发现栈顶还是 “A1”,于是修改为 A2

此时会出现系统错误,因为此 “A1” 非彼“A1”

ABA 问题可以怎么优化?

ABA 问题导致的原因,是 CAS 过程中只简单进行了 “值” 的校验,再有些情况下,“值”相同不会引入错误的业务逻辑(例如余额),有些情况下,“值”虽然相同,却已经不是原来的数据了(例如堆栈)。

因此,CAS 不能只比对 “值”,还必须确保是原来的数据,才能修改成功。

常见的实践是,将 “值” 比对,升级为 “版本号” 的比对,一个数据一个版本,版本变化,即使值相同,也不应该修改成功

余额并发读写例子,引入版本号的具体实践如下:

(1)余额表要升级。

t_yue(uid, money)

升级为:

t_yue(uid, money, version_)_

(2)查询余额时,同时查询版本号。

SELECT money FROM t_yue WHERE sid=$sid

升级为:

_SELECT money,_version FROM t_yue WHERE sid=$sid

假设有并发操作,都会将版本号查询出来。

(3)设置余额时,必须版本号相同,并且版本号要修改。

旧版本 “值” 比对:

UPDATE t_yue SET money=38 WHERE uid=$uid AND money=100

升级为 “版本号” 比对:

UPDATE t_yue SET money=38, version=version_new_ _WHERE uid=uid AND version=$version_old

此时假设有并发操作,首先操作的请求会修改版本号,并发操作会执行失败。

_画外音:_version 通用,本例是强行用 version 举例而已,实际上本例可以用余额 “值” 比对。

总结

  • select&set 业务场景,在并发时会出现一致性问题

  • 基于 “值” 的 CAS 乐观锁,可能导致 ABA 问题

  • CAS 乐观锁,必须保证修改时的 “此数据” 就是 “彼数据”,应该由“值” 比对,优化为 “版本号” 比对

思路比结论重要。

架构师之路 - 分享技术思路

关于并发扣款中幂等性,redis 事务的问题,会在接下来几篇分享。希望大家有收获。