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

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

大家有非常多的留言，大概有这么几类：

（1）是否存在ABA问题？

（2）为什么不能用：

UPDATE t_yue SET money=money-$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事务的问题，会在接下来几篇分享。希望大家有收获。