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

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

一、业务场景

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

(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元

>need-to-insert-img

(2)业务1和业务2进行逻辑计算,算出各自业务的余额,假设业务1算出的余额是28元,业务2算出的余额是38元

>need-to-insert-img

(3)业务1对数据库中的余额先进行修改,设置成28元。

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

>need-to-insert-img

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

三、问题原因

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

四、原因分析

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

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

五、简易解决方案

在set写回的时候,加上初始状态的条件compare,只有初始状态不变时,才允许set写回成功,这正是大家常说的“Compare And Set”(CAS),是一种常见的降低读写锁冲突,保证数据一致性的方法。

六、业务的升级

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

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

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

并发操作发生时:

业务1执行 => UPDAtE t_yueSET money=28WHERE uid=$uidAND money=100

业务2执行 => UPDAtE t_yueSET money=38WHERE uid=$uidAND money=100

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

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

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

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

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

八、总结

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

作者:沈剑

简介:58同城高级架构师,本文由原作者58沈剑授权转发

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏韩伟的专栏

经典游戏服务器端架构概述 (2)

现代电子游戏,基本上都会使用一定的网络功能。从验证正版,到多人交互等等,都需要架设一些专用的服务器,以及编写在服务器上的程序。因此,游戏服务器端软件的架构,本质...

2.2K0
来自专栏腾讯大讲堂的专栏

数据库schema设计与优化

1、 前言 对于数据库而言,在日常开发中我们主要的关注点有两块,一个是schema的结构设计,另一个就是索引的优化,这两块是影响我们最终系统结构和性能的关键部分...

2715
来自专栏企鹅号快讯

分布式架构的套路No.74

今天小蕉跟大伙一起聊聊分布式系统的架构的套路。在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构? 大多数的开发者大多数的系统可能从来没接触过分布式系...

3579
来自专栏美团技术团队

【沙龙干货】RDS平台介绍

今天我就给大家讲一下我们这边做的数据库运维的自动化平台,他是怎么样子的。首先我会给大家简单介绍一下我们做平台的背景,以及平台的一些技术架构,以及针对我们DBA和...

3874
来自专栏ATYUN订阅号

数据虚拟化:为人工智能和机器学习解锁数据

在可靠性、准确性和性能方面,人工智能和机器学习都严重依赖于大型设备。因为数据池越大,你就越能对模型进行训练。这就是为什么重要的数据平台能够高效地处理不同的数据流...

35811
来自专栏数据库

开放的计算能力为数据库瘦身

开放的计算能力为数据库瘦身 计算封闭性导致臃肿的数据库 我们在上一期谈到,数据库的臃肿,也就是过多的中间表以及相关存储过程,是由于其计算封闭性造成的。如果能够实...

1699
来自专栏沈唁志

整合ThinkPHP功能系列之使用聚合数据查询快递物流数据

聚合数据的快递类接口价格还是比较实惠的,而且在去年的时候受菜鸟顺丰互撕影响,聚合数据快递类接口接入量猛增

983
来自专栏ACM小冰成长之路

UVA-12260-Free Goodies

ACM模版 描述 ? ? 题解 image.png 代码 #include <iostream> #include <cstdio> #include <cst...

1809
来自专栏韩伟的专栏

经典游戏服务器端架构概述(下)

经典游戏服务器端架构概述(下) 今天将详细说明全服分线模型和全服全线模型,正文如下: 1全服分线模型 一、模型描述 由于多进程服务器模型的发展,游戏开发者...

3715
来自专栏架构之美

以IM为例看58同城典型技术架构演变

1354

扫码关注云+社区