開篇同一個用戶并發(fā)扣款時，有一定概率出現(xiàn)數(shù)據(jù)不一致，可以使用CAS樂觀鎖的方式，在不降低吞吐量，保證數(shù)據(jù)的一致性：

UPDATE t_yue SET money=$new_money 
WHERE uid=$uid AND money=$old_money; 

[[276283]]

更詳細(xì)的描述，詳見《并發(fā)扣款，如何保證數(shù)據(jù)的一致性?》。 不能采用直接扣減的方式：

UPDATE t_yue SET moneymoney=money-$diff WHERE uid=$uid; 

更詳細(xì)的描述，詳見《并發(fā)扣款一致性，冪等性問題》。 當(dāng)然，更通用的方式，可以使用版本號來實現(xiàn)CAS樂觀鎖：

UPDATE t_yue SET money=$new_money,ver=$ver_new 
WHERE uid=$uid AND ver=$ver_old; 

更詳細(xì)的描述，詳見《并發(fā)扣款一致性優(yōu)化，CAS下ABA問題》。

對于這個CAS樂觀鎖方案，很有朋友有疑問：當(dāng)并發(fā)量高時，版本號比對會導(dǎo)致大量的更新失敗，這個方案不適用于高并發(fā)場景嗎?

究竟是不是這樣呢?大家對高并發(fā)是不是有什么誤解呢?今天來聊一聊這個話題。

先分析三個業(yè)務(wù)場景。

一、QQ

QQ的一些核心業(yè)務(wù)有：

• 個人：user(uid, user_info, …)
• 好友：user_friends(uid, friend_id, …)
• 加入的群：user_groups(uid, group_id, …)
• 群：group(gid, group_info, …)
• 群成員：group_members(gid, uid, …)
• 個人消息：msgs_user(msg_id, uid, …)
• 群消息：msgs_group(msg_id, gid, …)

這些信息的讀寫有一個特點，都會帶上uid/gid/msgid屬性。

例如，拉取好友列表：

select friend_id from user_friends where uid=$uid; 

在用戶量很大，并發(fā)量很大時，不同用戶/群/消息數(shù)據(jù)的讀寫并沒有鎖沖突。

畫外音：10W個用戶同時讀寫，彼此沒有鎖沖突。

只有當(dāng)，同一個用戶，很短的時間內(nèi)，有大量并發(fā)時，才可能存在鎖沖突。

畫外音：例如，1個用戶，1秒鐘讀寫1W次。

二、微博

微博的核心業(yè)務(wù)是feed流：

• 發(fā)消息，寫操作
• 刷消息，讀操作

微博業(yè)務(wù)顯然是讀多寫少的，在用戶刷消息時，自己feed流里的消息，是由別人發(fā)出的。

查看自己主頁feed流，最樸素的實現(xiàn)方法是：

• 拉取自己關(guān)注的用戶id_list;
• 拉取這些用戶最近N條消息;
• 將這N*id_list條消息排序;
• 返回第一頁消息，得到自己主頁feed流;

在用戶量很大，并發(fā)量很大時，會有一定數(shù)據(jù)的讀寫鎖沖突。

畫外音：不像QQ，基本是讀寫自己的數(shù)據(jù)，微博要寫自己的數(shù)據(jù)，讀別人的數(shù)據(jù)。

三、12306

12306的核心業(yè)務(wù)是：

• 查票，讀操作
• 買票，寫操作

stock(id, num) // 某一列車有多少張余票 

在用戶量很大，并發(fā)量很大時，有極大的鎖沖突。

畫外音：這個業(yè)務(wù)，數(shù)據(jù)量并不大。

這類“秒殺”業(yè)務(wù)，如果不做特殊的優(yōu)化，數(shù)據(jù)庫很容易死鎖卡死，沒有任何人能買票成功。

畫外音：要做什么特殊的優(yōu)化呢?

收尾

QQ，微博、12306，同樣是高并發(fā)業(yè)務(wù)，就數(shù)據(jù)存儲鎖沖突來說，各自的難度，數(shù)據(jù)不一致的概率是不同的。

畫外音：你不能說，QQ不是高并發(fā)業(yè)務(wù)吧。

回到開篇，使用CAS樂觀鎖進(jìn)庫存扣減：

UPDATE t_yue SET money=$new_money,ver=$ver_new 
WHERE uid=$uid AND ver=$ver_old; 

只要有uid這個過濾屬性，即使10W用戶同時扣款，也不容易出現(xiàn)數(shù)據(jù)不一致。

只有當(dāng)同一個用戶，同一秒鐘，有大量扣減時，才有一定幾率會沖撞，但也不會導(dǎo)致數(shù)據(jù)不一致。畫外音：有一位很可愛的水友，說萬一PC端和APP端同時下單怎么辦。

結(jié)論

高并發(fā)的扣款場景，可以使用CAS樂觀鎖，采用select&set方式進(jìn)行扣款，既能夠保證吞吐量，又能夠保證一致性。

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

戳這里，看該作者更多好文