并發扣款一致性優化，CAS下ABA問題，這個話題還沒聊完！！！
上一篇答星球水友提問，《并發扣款，如何保證數據的一致性?》中提到：用CAS樂觀鎖，可以在盡量不影響吞吐量的情況下，保證數據的一致性。
大家有非常多的留言，大概有這么幾類：
- 是否存在ABA問題?
- 為什么不能用：
- UPDATE t_yue SET moneymoney=money-$diff AND money>=$diff;
畫外音：請務必閱讀前序文章：《并發扣款，如何保證數據的一致性?》。
問題比較多，今天先聊第一個問題，ABA。
什么是ABA問題?
CAS樂觀鎖機制確實能夠提升吞吐，并保證一致性，但在極端情況下可能會出現ABA問題。
考慮如下操作：
- 并發1(上)：獲取出數據的初始值是A，后續計劃實施CAS樂觀鎖，期望數據仍是A的時候，修改才能成功
- 并發2：將數據修改成B
- 并發3：將數據修改回A
- 并發1(下)：CAS樂觀鎖，檢測發現初始值還是A，進行數據修改
上述并發環境下，并發1在修改數據時，雖然還是A，但已經不是初始條件的A了，中間發生了A變B，B又變A的變化，此A已經非彼A，數據卻成功修改，可能導致錯誤，這就是CAS引發的所謂的ABA問題。
余額操作，出現ABA問題并不會對業務產生影響，因為對于“余額”屬性來說，前一個A為100余額，與后一個A為100余額，本質是相同的。
但其他場景未必是這樣，舉一個堆棧操作的例子：
并發1(上)：讀取棧頂的元素為“A1”
并發2：進行了2次出棧
并發3：又進行了1次出棧
并發1(下)：實施CAS樂觀鎖，發現棧頂還是“A1”，于是修改為A2
此時會出現系統錯誤，因為此“A1”非彼“A1”
ABA問題可以怎么優化?
ABA問題導致的原因，是CAS過程中只簡單進行了“值”的校驗，再有些情況下，“值”相同不會引入錯誤的業務邏輯(例如余額)，有些情況下，“值”雖然相同，卻已經不是原來的數據了(例如堆棧)。
因此，CAS不能只比對“值”，還必須確保是原來的數據，才能修改成功。
常見的實踐是，將“值”比對，升級為“版本號”的比對，一個數據一個版本，版本變化，即使值相同，也不應該修改成功。
余額并發讀寫例子，引入版本號的具體實踐如下：
(1)余額表要升級。
- t_yue(uid, money)
升級為：
- t_yue(uid, money, version)
(2)查詢余額時，同時查詢版本號。
- SELECT money FROM t_yue WHERE sid=$sid
升級為：
- SELECT money,version FROM t_yue WHERE sid=$sid
假設有并發操作，都會將版本號查詢出來。
(3)設置余額時，必須版本號相同，并且版本號要修改。舊版本“值”比對：
- UPDATE t_yue SET money=38 WHERE uid=$uid AND money=100
升級為“版本號”比對：
- UPDATE t_yue SET money=38, version=$version_new WHERE uid=$uid AND version=$version_old
此時假設有并發操作，首先操作的請求會修改版本號，并發操作會執行失敗。
畫外音：version通用，本例是強行用version舉例而已，實際上本例可以用余額“值”比對。
總結
- select&set業務場景，在并發時會出現一致性問題
- 基于“值”的CAS樂觀鎖，可能導致ABA問題
- CAS樂觀鎖，必須保證修改時的“此數據”就是“彼數據”，應該由“值”比對，優化為“版本號”比對
思路比結論重要。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
