• Part One
• Part Two

Part One

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

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

直接sql更新

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

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

CAS

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

/**
*用戶余額增加20
*newBal為新值
*oldBal為庫中查出的值
**/
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}

樂觀鎖

樂觀鎖其實就是使用version去進(jìn)行版本控制，在更新時判斷是否更新數(shù)據(jù)的版本與現(xiàn)庫內(nèi)版本是一致的，若一致則更改并上升版本號，否則認(rèn)為在此期間有其它線程進(jìn)行數(shù)據(jù)更新。假如更新失敗的話，同樣進(jìn)行重試處理。這樣的好處就是可以避免aba問題，同時也可以使用增加后的余額進(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分布式鎖

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

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

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

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

Part Two

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

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

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

}

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

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

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

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

解決方案&一些思考

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

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

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

publicclassOrderService{

lock()

select()

unlock()

}

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

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

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

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

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

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