巧用CAS解决数据一致性问题

原文地址：http://mp.weixin.qq.com/s/_XlzbmBSj_i-S2PkE5tI_w

 

缘起：在高并发的分布式环境下，对于数据的查询与修改容易引发一致性问题，本文将分享一种非常简单但有效的优化方法。

 

一、业务场景

业务场景为，购买商品的过程要对余额进行查询与修改，大致的业务流程如下：

（1）从数据库查询用户现有余额 SELECT money FROM t_yue WHERE uid=$uid，不妨设查询出来的$old_money=100元

 

（2）业务层实施业务逻辑，比如购买一个80元的商品，并且打九折

if($old_money> 80*0.9) $new_money=$old_money-80*0.9=28

 

（3）将数据库中的余额进行修改 UPDAtE t_yue SET money=$new_money WHERE uid=$uid

 

在并发量低的情况下，这个流程没有任何问题，原有金额100元，购买了80元的九折商品（72元），剩余28元。

 

二、潜在的问题

在分布式环境中，如果并发量很大，这种“查询+修改”的业务很容易出现数据不一致。极限情况下，可能出现这样的异常流程：

（1）业务1和业务2同时查询余额，是100元

 

（2）业务1和业务2进行逻辑计算，算出各自业务的余额，假设业务1算出的余额是28元，业务2算出的余额是38元

 

 

（3）业务1对数据库中的余额先进行修改，设置成28元。

业务2对数据库中的余额后进行修改，设置成38元。

此时异常出现了，原有金额100元，业务1扣除了72元，业务2扣除了62元，最后剩余38元。

 

三、问题原因

高并发环境下，对同一个数据的并发读（两边都读出余额是100）与并发写（一个写回28，一个写回38）导致的数据一致性问题。

 

四、原因分析

业务1的写回：原有金额100，这是一个初始状态，写回金额28，理论上只有在原有金额为100的时候才允许写回成功，这一步没问题。

业务2的写回：的原有金额100，这是一个初始状态，写回金额38，理论上只有在原有金额为100的时候才允许写回成功，可实际上，这个时候数据库中的金额已经变为28了，这一步的写操作不应该成功。

 

五、简易解决方案

在set写回的时候，加上初始状态的条件compare，只有初始状态不变时，才允许set写回成功，这正是大家常说的“Compare And Swap”（CAS，比较并替换），也可以叫做“Compare And Set”，是一种常见的降低读写锁冲突，保证数据一致性的方法，类似于乐观锁。

 

六、业务的升级

业务线使用CAS解决高并发时数据一致性问题，只需要在进行set操作时，compare一下初始值，如果初始值变换，不允许set成功。

对于上文中的业务场景，只需要将“UPDAtEt_yue SET money=$new_money WHERE uid=$uid”升级为

“UPDAtE t_yue SETmoney=$new_money WHERE uid=$uid AND money=$old_money”即可。

并发操作发生时：

业务1执行 => UPDAtE t_yue SET money=28 WHERE uid=$uid AND money=100

业务2执行 => UPDAtE t_yue SET money=38 WHERE uid=$uid AND money=100

【这两个操作同时进行时，只能有一个执行成功】。

 

七、怎么判断哪个执行成功，哪个执行失败

set操作，其实无所谓成功或者失败，业务能通过affect rows得知哪个修改没有成功：

执行成功的业务，affect rows为1

执行失败的业务，affect rows为0

 

八、总结

高并发“查询并修改”的场景，可以用CAS（Compare and Swap）的方式解决数据一致性问题。对应到业务，即在set的时候，加上初始条件的比对。

CAS对比Synchronized的缺点：

1、CAS对cpu开销比较大，并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却一直更新不成功，循环往复，会给cpu带来很大压力

2、不能保证代码块的原子性，CAS机制所保证的只是一个变量的原子性操作

3、ABA问题，CAS容易出现ABA问题，有三个线程使用CAS更新某一变量：

（1）线程1：获取当前值A，期望更新为B

（2）线程2：获取当前值A，期望更新为B

（3）线程3：期望更新为A

接下来，线程1执行成功，把当前值更新为B，线程2由于某种原因被阻塞，没有做更新操作，线程3在线程1更新之后，获取当前值B，线程3成功把当前值B更新

为A，此时线程2恢复运行状态，由于阻塞之前获取“当前值”为A，并且经过compare检测，内存地址中的实际值也是A，所以检测通过，成功将变量A更新为B。

这个过程中，线程2获取的变量值A是一个旧值，尽管和当前的实际值相同，当时内存地址中的变量已经经历了A->B->A的改变。

实际例子：

假设有一个遵循CAS原理的提款机，小灰有100元存款，需要提款50元；由于提款机硬件出现问题，小灰的提款操作被同时提交了两次，开启了两个线程去处理，

两个线程都是获取当前值100元，要更新为50元。理想情况下，应该一个线程更新成功，另一个线程更新失败，小灰的存款只被扣取一

次。线程1首先执行成功，把余额从100改成50，线程2由于某种原因阻塞了，这时候小灰的妈妈刚好给小灰汇款50元，使用线程3进行处理。

（1）线程1（提款机）：获取当前值100，成功更新为50

（2）线程2（提款机）：获取当前值100，更新为50（BLOCK阻塞）

（3）线程3（小灰妈）：获取当前值50，期望更新为100

线程2仍然是阻塞状态，线程3执行成功，把余额从50改成100，此时线程2恢复运行，通过CAS检测阻塞之前获取的“当前值”100和此时实际存款100，检测通过，

成功更新变量值100为50。小灰的余额被扣取了两次。

从思想上来说，CAS属于乐观锁，Synchronized属于悲观锁，CAS代码性能比Synchronized高，CAS的ABA问题可以使用版本号进行解决，java的AtomicInteger、AtomicLong、AtomicBoolean等原子类操作都使用了CAS和版本号。