大家好，我是Leo。

(資料圖片)

聊一下創(chuàng)建訂單和更新訂單的數(shù)據(jù)一致性問題，文章分類主要是MySQL，Redis，秒殺系統(tǒng)，RocketMQ，計算機(jī)網(wǎng)絡(luò)，大廠面試，設(shè)計模式，Nginx。先整理一下。方便粉絲更好的閱讀，同時也方便自己不斷的復(fù)習(xí)沉淀。

我們在下單時，往往會因為網(wǎng)絡(luò)問題出現(xiàn)多次下單的情況，比如點了下單一直沒反應(yīng)，我們就會多次的重復(fù)點擊，如果服務(wù)端做了校驗可能不會出現(xiàn)什么問題，如果沒做的話在訂單列表里可能就會出現(xiàn)多個訂單。

解決方案就是我們可以對訂單實現(xiàn)具備冪等性。

冪等性就是無論點擊多少次下單，始終只會創(chuàng)建一條記錄。

如果系統(tǒng)體量比較大的話，我們可以獨立一個生成訂單號服務(wù)，體量不大的話可以封裝成一個API給訂單服務(wù)使用。

當(dāng)用戶從購物車界面點結(jié)算挑戰(zhàn)到訂單詳情界面就請求一次生成訂單號，使這個訂單詳情頁的緩存中保存一條唯一的訂單號

只要每次下單請求的訂單號是唯一的，我們再借助數(shù)據(jù)庫中主鍵唯一約束性來實現(xiàn)，訂單數(shù)據(jù)的唯一性。

如果主鍵是訂單號的話，主鍵自動幫我們實現(xiàn)了。如果主鍵是時間戳ID的話，我們把訂單號字段設(shè)為唯一索引，同時也可以避免重復(fù)下單的校驗需求。

訂單服務(wù)會經(jīng)常出現(xiàn)ABA問題。

什么是 ABA 問題呢？我們舉個例子，訂單支付之后，小二要發(fā)貨，發(fā)貨完成后要填個快遞單號。假如小二填了一個單號 666，剛填完，發(fā)現(xiàn)填錯了，趕緊再修改成 888。對訂單服務(wù)來說，這就是 2 個更新訂單的請求。

正常情況下，訂單中的快遞單號會先更新成 666，再更新成 888，這是沒問題的。那不正常情況呢？666 請求到了，單號更新成 666，然后 888 請求到了，單號又更新成 888，但是 666 更新成功的響應(yīng)丟了，調(diào)用方?jīng)]收到成功響應(yīng)，自動重試，再次發(fā)起 666 請求，單號又被更新成 666 了，這數(shù)據(jù)顯然就錯了。這就是ABA 問題。

解決方案就是我們在訂單表中加一個版本號這個字段。

在查詢訂單時，我們可以把版本號返回給前端，前端在處理下單時，以參數(shù)的形式傳遞給后端，后端收到版本號之后與數(shù)據(jù)庫的實際數(shù)據(jù)對比，如果版本號符合，修改數(shù)據(jù)，版本號遞增。

為了考慮數(shù)據(jù)安全性，我們一般會將 校驗版本號，修改數(shù)據(jù)，修改版本號在一個事務(wù)中執(zhí)行

UPDATE orders set tracking_number = 666, version = version + 1WHERE version = 8;

通過版本號，我們就可以得知，在每次修改數(shù)據(jù)時，是否有其他人修改過。這樣就不會出現(xiàn)ABA問題了。