大家好，我是Leo。

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

重復(fù)下單

我們?cè)谙聠螘r(shí)，往往會(huì)因?yàn)榫W(wǎng)絡(luò)問題出現(xiàn)多次下單的情況，比如點(diǎn)了下單一直沒反應(yīng)，我們就會(huì)多次的重復(fù)點(diǎn)擊，如果服務(wù)端做了校驗(yàn)可能不會(huì)出現(xiàn)什么問題，如果沒做的話在訂單列表里可能就會(huì)出現(xiàn)多個(gè)訂單。

【資料圖】

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

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

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

當(dāng)用戶從購(gòu)物車界面點(diǎn)結(jié)算挑戰(zhàn)到訂單詳情界面就請(qǐng)求一次生成訂單號(hào)，使這個(gè)訂單詳情頁(yè)的緩存中保存一條唯一的訂單號(hào)只要每次下單請(qǐng)求的訂單號(hào)是唯一的，我們?cè)俳柚鷶?shù)據(jù)庫(kù)中主鍵唯一約束性來實(shí)現(xiàn)，訂單數(shù)據(jù)的唯一性。

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

ABA問題

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

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

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

解決方案就是我們?cè)谟唵伪碇屑右粋€(gè)版本號(hào)這個(gè)字段。

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

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

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

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

關(guān)鍵詞： 數(shù)據(jù)一致性 解決方案 快遞單號(hào)