問題由來

假設(shè)在訂單管理系統(tǒng)開發(fā)方案中（以火車票訂單系統(tǒng)為例），用戶A，用戶B都要預定從成都到北京的火車票，A、B在不同的售票窗口均同時查詢到了某車廂臥鋪中、下鋪位有空位。用戶A正在猶豫訂中鋪還是下鋪，這時用戶B果斷訂購了下鋪。當用戶A決定訂下鋪時，系統(tǒng)提示下鋪已經(jīng)被預訂，請重新選擇鋪位。在這個系統(tǒng)場景中，我們來探討一下，火車票系統(tǒng)是怎樣處理并發(fā)事件以及怎么利用鎖機制來避免重復訂票的。

方案1：

為了避免重復訂票，大部分人會想到在做訂票操作前，去數(shù)據(jù)庫查詢該鋪位是否已經(jīng)被預訂，假設(shè)“鋪位”數(shù)據(jù)庫表增加標記字段FLAG（空閑：0；已預訂：1），如果查詢到鋪位的FLAG字段值為1,那么預訂就不成功，如果為0就成功預訂，并把FLAG置為1。這種方案如果在業(yè)務(wù)量很少的系統(tǒng)中，或許可行。但業(yè)務(wù)量較大時，特別是火車票這樣的業(yè)務(wù)量，就會出現(xiàn)問題。問題在，當用戶A、用戶B同時對同一鋪位預訂時，雖說是“同時”，但對于數(shù)據(jù)庫操作來說一定是有先后順序的，假設(shè)A在查詢該鋪位的FLAG時，值為0，準備預訂并將值設(shè)為1，而與此同時B已經(jīng)預訂成功，并已將FLAG設(shè)為1。而A因為沒有即時查詢到FLAG=1，因此也預訂成功，又將FLAG設(shè)為1。

這樣就造成了重復訂票，在購票高峰期，使用這樣的方案，重復訂票不可避免。

方案2：

我們想到了利用數(shù)據(jù)庫的悲觀鎖來解決這個問題，設(shè)想假如用戶A查詢到想預訂的票，用戶B根本都查詢不到，只有A一個人能看到，那是不是沒有重復訂票的可能了，因為壓根沒人跟他搶。

可以這樣實現(xiàn)這個方案：

select * from table where …… for update skip locked，該語句是查詢用戶指定條件的票信息，并加鎖（for update），如果有記錄已經(jīng)被鎖則自動跳到下一條記錄（skip locked），這樣誰先查詢誰就可以慢慢的考慮要上鋪還是下鋪。但火車票系統(tǒng)是這樣做的嗎？顯然不是，因為這樣用戶體驗太不好，票實際還很多，但確看不到買不到，這顯然不合理。

方案3：

我們又想到了從訂單管理系統(tǒng)程序?qū)用鎭斫鉀Q并發(fā)問題，最簡便的方式是利用synchronized來處理，但我們要知道一個大型系統(tǒng)必然是集群方式部署的，synchronized只能解決單節(jié)點環(huán)境的并發(fā)問題，要解決此問題還是必須依賴全局性的鎖機制。

方案4：

既然又回到了在數(shù)據(jù)庫上加鎖，我們又想一下如果我們在查詢時，使用樂觀鎖，但在預訂之前使用悲觀鎖會怎樣呢？例如我們查詢時：

select * from table where ……

用戶A、用戶B都查詢到了相同的票信息（中鋪和下鋪），用戶A或用戶B在預訂時做一次悲觀鎖：

select * from table where …… for update（只對預訂的票做悲觀鎖）

此時后者在預訂時，無法獲取該記錄的鎖，自然就無法預訂，避免了重復預訂的問題。

文章來源：博客園

<數(shù)商云（www.zhimaihui.cn）是國內(nèi)知名企業(yè)級電商平臺提供商，為企業(yè)級商家提供最佳的系統(tǒng)開發(fā)（多種模式電商平臺搭建：B2B/B2B2C/B2C/O2O/新零售等）、供應(yīng)商系統(tǒng)搭建及電商解決方案服務(wù)>