并發(fā)場(chǎng)景下如何保證數(shù)據(jù)操作的準(zhǔn)確性？

• Part One
• Part Two

Part One

我們假想一個(gè)場(chǎng)景，在并發(fā)場(chǎng)景下，假如要對(duì)賬戶余額(tb_balance.balance)進(jìn)行增加和減少余額，要怎么設(shè)計(jì)才能保證數(shù)據(jù)不出錯(cuò)呢?

下面是我的一些設(shè)想(假設(shè)余額更新20或減少20)：

直接sql更新

直接balance自增20，怎么并發(fā)都余額都不會(huì)錯(cuò)了是不是~，但這里會(huì)有問(wèn)題，1.假如是減余額的話，要注意余額不能小于0 2.假如后續(xù)需要用這個(gè)余額結(jié)果再進(jìn)行一些業(yè)務(wù)操作的話，是取不到這個(gè)余額的sql

updatetb_balancesetbalance=balance+20wherebalance=#{old_bal}anduser_id=#{user_id}

CAS

經(jīng)典的compare and swap，就是入庫(kù)時(shí)去對(duì)比舊值是否與現(xiàn)數(shù)據(jù)庫(kù)中的值相等，若相等則更新否則不更新，但是會(huì)有風(fēng)險(xiǎn)，就是經(jīng)典的aba問(wèn)題。假如更新返回的影響數(shù)為0的話，說(shuō)明余額已經(jīng)發(fā)生了變化，所以需要拋出異常并進(jìn)行重試。（這里需要寫一些補(bǔ)償?shù)臉I(yè)務(wù)邏輯去處理余額更新失敗的問(wèn)題）

/**
*用戶余額增加20
*newBal為新值
*oldBal為庫(kù)中查出的值
**/
oldBal=balService.getBal(userId);
newBal=oldBal+20;

intcount=balService.updateBal(newBal,oldBal,userId);
Assert.businessInvalid(count==0,"updateerror");

//todosomebuisness

updatetb_balancesetbalance=#{new_bal}wherebalance=#{old_bal}anduser_id=#{user_id}

樂(lè)觀鎖

樂(lè)觀鎖其實(shí)就是使用version去進(jìn)行版本控制，在更新時(shí)判斷是否更新數(shù)據(jù)的版本與現(xiàn)庫(kù)內(nèi)版本是一致的，若一致則更改并上升版本號(hào)，否則認(rèn)為在此期間有其它線程進(jìn)行數(shù)據(jù)更新。假如更新失敗的話，同樣進(jìn)行重試處理。這樣的好處就是可以避免aba問(wèn)題，同時(shí)也可以使用增加后的余額進(jìn)行后續(xù)的操作。目前已知有些公司就是這么操作的

try{
//dosomebuisness
intcount=balService.updateBal(newBal,old_version,new_version,userId);
Assert.businessInvalid(count==0,"updateerror");
//dosomebuisness
}catch(){
//iffailtodosomethingtryagain
}

updatetb_balancesetbalance=#{balance}andbalance=#{new_version}whereversion=#{old_version}anduser_id=#{user_id}

--ifaffectcount>1success
--ifaffectcount=0retry

redission分布式鎖

像集群的項(xiàng)目，我們經(jīng)常會(huì)使用分布式鎖去保證冪等性，如果只有單一接口會(huì)去操作賬戶余額那使用分布式鎖沒(méi)有問(wèn)題，只要在該接口加上鎖，保證同一時(shí)間只有單一線程進(jìn)行該業(yè)務(wù)操作即可；但往往實(shí)際業(yè)務(wù)場(chǎng)景并不會(huì)那么簡(jiǎn)單，比如一個(gè)商城，可能會(huì)有幾十上百個(gè)入口可以對(duì)余額進(jìn)行變更，比如定時(shí)扣費(fèi)、訂單支付、替他人代付等等；那其實(shí)可以通過(guò)面向?qū)ο蟮乃枷?，將余額的操作進(jìn)行抽象，抽象出一個(gè)余額類，將該類的方法加上鎖，然后所有的業(yè)務(wù)都強(qiáng)制通過(guò)該類進(jìn)行余額變更的操作，即可保證操作的可靠性。

所以也就是說(shuō)，訂單系統(tǒng)、服務(wù)管理中心等等服務(wù)都不應(yīng)該能直接操作到余額數(shù)據(jù)，還是得抽出一個(gè)類型財(cái)務(wù)中臺(tái)的東東去統(tǒng)一處理余額，然后財(cái)務(wù)中臺(tái)中又維護(hù)這么一個(gè)余額類去保證更新的可靠性? 這其實(shí)也就是軟件工程中的單一入口 思想吧

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

Part Two

業(yè)務(wù)背景：現(xiàn)在實(shí)際開(kāi)發(fā)過(guò)程中會(huì)有這樣一種場(chǎng)景，訂單表a作為訂單業(yè)務(wù)核心表，而會(huì)有a1,a2,a3...an個(gè)業(yè)務(wù)會(huì)去更新訂單表a的狀態(tài)，而同時(shí)a.status(訂單狀態(tài))也是作為b,c,d...業(yè)務(wù)操作的核心判斷依據(jù)(也就是在不同的訂單狀態(tài)下可能做的操作是截然相反的)

在代碼層面上，我們一般的寫法是直接用注解開(kāi)個(gè)事務(wù)，以保證操作的原子性。這種寫法目前讓我們的業(yè)務(wù)還是平穩(wěn)運(yùn)行的~

//@apiLock是redis鎖
@ApiLock
@Transactional
publicvoiddosomething(){

}

那么假設(shè)用戶量激增，并發(fā)量暴漲，那么會(huì)出現(xiàn)什么情況呢？

搞事情的時(shí)間來(lái)了，事務(wù)只能保證單個(gè)操作的事務(wù)性，假如并發(fā)量高的時(shí)候，可能就會(huì)出現(xiàn)(假設(shè)b業(yè)務(wù)的前提是a訂單再待接單[wait_acceipt]的狀態(tài))：

b業(yè)務(wù)查詢時(shí)，a.status=wait_acceipt，然后b業(yè)務(wù)開(kāi)始處理；而此時(shí)，a1業(yè)務(wù)對(duì)a訂單進(jìn)行操作，并且先于b業(yè)務(wù)處理完，這時(shí)a訂單走到了待服務(wù)(wait_service)，而b還在進(jìn)行業(yè)務(wù)處理；然后b業(yè)務(wù)處理完成，并進(jìn)行提交。

那么就會(huì)產(chǎn)生很多異常的數(shù)據(jù)了，而且影響范圍會(huì)很大

解決方案&一些思考

我們可以關(guān)注到，這個(gè)場(chǎng)景的問(wèn)題點(diǎn)其實(shí)并不在數(shù)據(jù)的插入與更新，而是在讀取，在業(yè)務(wù)處理過(guò)程怎么在確定訂單狀態(tài)沒(méi)有發(fā)生改變

使用redis鎖，在讀取訂單時(shí)候?qū)τ唵芜M(jìn)行上鎖，業(yè)務(wù)結(jié)束之后再釋放

單一入口 ：將訂單類的操作抽象成一個(gè)order類，然后在這個(gè)order類中去進(jìn)行查詢 操作，或者在不同服務(wù)中用一個(gè)redis-key也是OK的

publicclassOrderService{

lock()

select()

unlock()

}

publicvoiddosomeB(){
try{
orderService.lock(serviceOrderId);
//todo
}finally(){
orderService.unlock(serviceOrderId);
}
}

使用mysql共享鎖(讀鎖)，在數(shù)據(jù)庫(kù)層面進(jìn)行阻塞，更加精準(zhǔn)，并且不使用單一入口也是可以的，但是可能存在索引失效鎖表的風(fēng)險(xiǎn)(核心表被鎖就炸了)

publicclassOrderService{
/**
*讀取并且上鎖
*/
selectAndLock()

/**
*讀取
*/
select()
}

--讀鎖會(huì)阻塞寫(X)，但是不會(huì)堵塞讀(S)，在事務(wù)提交后，讀鎖會(huì)自動(dòng)釋放
selectxxxfromorderwhereservice_order_id=xxxlockinsharemode;

總體來(lái)說(shuō) ，思想就是對(duì)正在操作的數(shù)據(jù)進(jìn)行加讀鎖，阻塞其它的線程。當(dāng)然這種方案也是雙刃劍，畢竟會(huì)減少吞吐量，還是應(yīng)該進(jìn)行業(yè)務(wù)梳理，確定加鎖的必要性，避免過(guò)分設(shè)計(jì)~像現(xiàn)在的系統(tǒng)，我就沒(méi)去動(dòng)它，hh~