現(xiàn)在，很多飯館的點餐都是掃桌碼點餐，這種場景中，店面內(nèi)的不同桌碼產(chǎn)生的訂單會根據(jù)下單時間先后順序進行排號，以規(guī)范管理客戶點單的次序，方便客戶根據(jù)取餐碼取餐。

當(dāng)然我們也很容易就能想到，這個取餐號碼是自增的，這種場景再熟悉不過了，在以往我們?nèi)ワ埖瓿燥埬玫降奶栆驗槭窃诠衽_口頭下單，服務(wù)員掃碼支付，所以小票機器打出來的單號就很容易是看的出來自增的，這種序號就+1就行了，只有一個地方在點單，這樣的邏輯當(dāng)然沒問題。

現(xiàn)在是桌面掃碼了，就出現(xiàn)了我們開發(fā)最常見也最頭疼的問題，并發(fā)問題。如果現(xiàn)在的最大取餐號是30,兩人同時下單，或者同時支付，怎么保證兩人取到的一個是31 一個是32 ，而不是都是31？

假設(shè)現(xiàn)在訂單表如下：

表格內(nèi)容如下：

這是 百變機獸之洛洛歷險記 的主要角色和人物，我們采用這些人物角色帶入他們在餐廳點單的場景。

1號洛洛和2號晶晶已經(jīng)先下單，拿到游戲，開始體驗，我們看到我們應(yīng)該自動分配出 0001 給洛洛 ， 0002 給晶晶，然后其余的機車族戰(zhàn)士和猛獸族戰(zhàn)士也紛紛下單獲得技能卡，各自得到取餐號，現(xiàn)在最大取餐號是0012，下一個應(yīng)該是0013。

現(xiàn)在金鐵獸也要下單，該如何正確的分到這個0013的取餐號碼呢？

方案1：

如果按最簡單的開發(fā)思路，我們獲取當(dāng)前最大的 get_order_number ，將其取出來，然后 +1 ，之后再插入記錄，那么程序設(shè)計如下：

可以看到我們的代碼先是取出最大number，然后對其做00前綴的補齊，之后我們做一個拼接SQL，然后插入數(shù)據(jù)庫，當(dāng)然實際業(yè)務(wù)肯定比這個復(fù)雜很多，但我們這里簡化了模型就用來講解現(xiàn)在的自增序號問題。

這是最容易想到的實現(xiàn)方案，但是這個方案必然會有數(shù)據(jù)并發(fā)問題，假如實際情況是現(xiàn)在金鐵獸和銀鐵獸都要下單，那他們都要買極光神風(fēng)爪技能卡，會不會他們都分到了0013這個編號呢？

答案是顯而易見的啊，非常有可能都分到這個號碼，那么該如何避免這個問題呢？我們想到是不是可以設(shè)定加鎖來控制寫入呢，由此我們推導(dǎo)出方案2。

方案2

通過加鎖(分布式鎖 這里以redis為例)，能夠讓代碼順序的執(zhí)行，我們可以在代碼執(zhí)行之前設(shè)定一個變量來加鎖判斷一下，比如這樣：

這里我們對這個當(dāng)前點單的1號店鋪進行設(shè)置key并加鎖判斷，只有拿到鎖的人才能進行點單，才能走下一步，那么顯然問題出現(xiàn)了，這樣別人就得等了，這就是阻塞住了，等于程序上降低了應(yīng)用可并發(fā)的數(shù)量。這樣也還是有點問題，有沒有更好的方法呢？這里我們介紹方案3.

方案3

我們直接使用 redis incr 方法能對一個數(shù)進行自增且返回這個自增后的結(jié)果，那不就是我們要的了嗎？大道至簡??！

注：本文轉(zhuǎn)載自“李照耀”，如有侵權(quán)，請聯(lián)系刪除！