用CAS方案解决高并发一致性问题

详见：http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt395

 

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

1、业务场景

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

（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元。

2、潜在的问题

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

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

 

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

 

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

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

 

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

3、问题缘由

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

4、缘由分析

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

业务2的写回：的原有金额10038100的时候才容许写回成功，可实际上，这个时候数据库中的金额已经变为28了，这一步的写操做不该该成功。

5、简易解决方案

在set写回的时候，加上初始状态的条件compare，只有初始状态不变时，才容许set写回成功，这正是你们常说的“Compare And Set”（CAS），是一种常见的下降读写锁冲突，保证数据一致性的方法。

6、业务的升级

业务线使用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执行SET money=38 WHERE uid=$uid

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

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

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

执行成功的业务，为1

执行失败的业务，为0

8、总结

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