[[177350]]

在高并發(fā)的分布式環(huán)境下，對于數(shù)據(jù)的查詢與修改容易引發(fā)一致性問題，本文將分享一種非常簡單但有效的優(yōu)化方法。

一、業(yè)務場景

業(yè)務場景為，購買商品的過程要對余額進行查詢與修改，大致的業(yè)務流程如下：

(1)從數(shù)據(jù)庫查詢用戶現(xiàn)有余額 SELECT money FROM t_yue WHERE uid=$uid，不妨設查詢出來的$old_money=100元

(2)業(yè)務層實施業(yè)務邏輯，比如購買一個80元的商品，并且打九折

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

(3)將數(shù)據(jù)庫中的余額進行修改 UPDAtE t_yue SET money=$new_money WHERE uid=$uid

在并發(fā)量低的情況下，這個流程沒有任何問題，原有金額100元，購買了80元的九折商品(72元)，剩余28元。

二、潛在的問題

在分布式環(huán)境中，如果并發(fā)量很大，這種“查詢+修改”的業(yè)務很容易出現(xiàn)數(shù)據(jù)不一***限情況下，可能出現(xiàn)這樣的異常流程：

(1)業(yè)務1和業(yè)務2同時查詢余額，是100元

(2)業(yè)務1和業(yè)務2進行邏輯計算，算出各自業(yè)務的余額，假設業(yè)務1算出的余額是28元，業(yè)務2算出的余額是38元

(3)業(yè)務1對數(shù)據(jù)庫中的余額先進行修改，設置成28元。

業(yè)務2對數(shù)據(jù)庫中的余額后進行修改，設置成38元。

此時異常出現(xiàn)了，原有金額100元，業(yè)務1扣除了72元，業(yè)務2扣除了62元，***剩余38元。

三、問題原因

高并發(fā)環(huán)境下，對同一個數(shù)據(jù)的并發(fā)讀(兩邊都讀出余額是100)與并發(fā)寫(一個寫回28，一個寫回38)導致的數(shù)據(jù)一致性問題。

四、原因分析

業(yè)務1的寫回：原有金額100，這是一個初始狀態(tài)，寫回金額28，理論上只有在原有金額為100的時候才允許寫回成功，這一步沒問題。

業(yè)務2的寫回：的原有金額100，這是一個初始狀態(tài)，寫回金額38，理論上只有在原有金額為100的時候才允許寫回成功，可實際上，這個時候數(shù)據(jù)庫中的金額已經變?yōu)?8了，這一步的寫操作不應該成功。

五、簡易解決方案

在set寫回的時候，加上初始狀態(tài)的條件compare，只有初始狀態(tài)不變時，才允許set寫回成功，這正是大家常說的“Compare And Set”(CAS)，是一種常見的降低讀寫鎖沖突，保證數(shù)據(jù)一致性的方法。

六、業(yè)務的升級

業(yè)務線使用CAS解決高并發(fā)時數(shù)據(jù)一致性問題，只需要在進行set操作時，compare一下初始值，如果初始值變換，不允許set成功。

對于上文中的業(yè)務場景，只需要將“UPDAtEt_yue SET money=$new_money WHERE uid=$uid”升級為

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

并發(fā)操作發(fā)生時：

業(yè)務1執(zhí)行 => UPDAtE t_yue SET money=28 WHERE uid=$uid AND money=100

業(yè)務2執(zhí)行 => UPDAtE t_yue SET money=38 WHERE uid=$uid AND money=100

【這兩個操作同時進行時，只能有一個執(zhí)行成功】。

七、怎么判斷哪個執(zhí)行成功，哪個執(zhí)行失敗

set操作，其實無所謂成功或者失敗，業(yè)務能通過affect rows得知哪個修改沒有成功：

執(zhí)行成功的業(yè)務，affect rows為1

執(zhí)行失敗的業(yè)務，affect rows為0

八、總結

高并發(fā)“查詢并修改”的場景，可以用CAS(Compare and Set)的方式解決數(shù)據(jù)一致性問題。對應到業(yè)務，即在set的時候，加上初始條件的比對。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉載請聯(lián)系原作者】