本文轉(zhuǎn)載自微信公眾號(hào)「微觀技術(shù)」，作者微觀技術(shù)。轉(zhuǎn)載本文請(qǐng)聯(lián)系微觀技術(shù)公眾號(hào)。

大家好，我是Tom哥。

做為一名程序員，發(fā)展方向大致可以分為兩個(gè)方面：一個(gè)是業(yè)務(wù)架構(gòu)，一個(gè)是技術(shù)架構(gòu)(中間件方向)。

業(yè)務(wù)架構(gòu)，取其核心關(guān)鍵詞，主要是圍繞這不同的業(yè)務(wù)場景、業(yè)務(wù)規(guī)則，完成業(yè)務(wù)系統(tǒng)的落地建設(shè)，為用戶提供在線化的信息服務(wù)。

既然說到業(yè)務(wù)，那方向可就多了去了，如：出行、外賣、充電寶、O2O、內(nèi)容、社交、生鮮、電商，不同的業(yè)務(wù)有不同的特點(diǎn)。

面對(duì)這么多的業(yè)務(wù)域，有沒有通用技術(shù)經(jīng)驗(yàn)可以抽取，讓我們可以以一應(yīng)百。

這里，首推電商業(yè)務(wù)，電商系統(tǒng)的復(fù)雜性很高，對(duì)高并發(fā)、高性能、高可用、高擴(kuò)展，等方面要求很高。你在其他業(yè)務(wù)中可能遇到的問題，在電商系統(tǒng)中基本都會(huì)遇到。

作為開發(fā)，希望自己成為某幾個(gè)業(yè)務(wù)領(lǐng)域的技術(shù)專家，最好能先精通電商領(lǐng)域，有很強(qiáng)的借鑒意義。對(duì)于你后續(xù)拓展熟悉其他業(yè)務(wù)領(lǐng)域的個(gè)性化玩法有很大幫助。

那么，電商領(lǐng)域的技術(shù)架構(gòu)有哪些常見問題?

一、避免重復(fù)下單

用戶快速點(diǎn)了兩次 “提交訂單” 按鈕，瀏覽器會(huì)向后端發(fā)送兩條創(chuàng)建訂單的請(qǐng)求，最終會(huì)創(chuàng)建兩條一模一樣的訂單。

解決方案：

解決方案就是采用冪等機(jī)制，多次請(qǐng)求和一次請(qǐng)求產(chǎn)生的效果是一樣的。

方案一：

利用數(shù)據(jù)庫自身特性 “主鍵唯一約束”，在插入訂單記錄時(shí)，帶上主鍵值，如果訂單重復(fù)，記錄插入會(huì)失敗。

操作過程：

• 引入一個(gè)服務(wù)，用于生成一個(gè)“全局唯一的訂單號(hào)”。
• 進(jìn)入創(chuàng)建訂單頁面時(shí)，前端請(qǐng)求該服務(wù)，預(yù)生成訂單ID。
• 提交訂單時(shí)，請(qǐng)求參數(shù)除了業(yè)務(wù)參數(shù)外，還要帶上這個(gè)預(yù)生成訂單ID。

方案二：

前端通過js腳本控制，無法解決用戶刷新提交的請(qǐng)求。另外也無法解決惡意提交。

不建議采用該方案，如果想用，也只是作為一個(gè)補(bǔ)充方案。

方案三：

前后約定附加參數(shù)校驗(yàn)。

當(dāng)用戶點(diǎn)擊購買按鈕時(shí)，渲染下單頁面，展示商品、收貨地址、運(yùn)費(fèi)、價(jià)格等信息，同時(shí)頁面會(huì)埋上Token 信息，用戶提交訂單時(shí)，后端業(yè)務(wù)邏輯會(huì)校驗(yàn)token，有且匹配才認(rèn)為是合理請(qǐng)求。

注意：同一個(gè) Token 只能用一次，用完后立馬失效掉。

<form action="/add-name-v2" method="post">
    {% csrf_token %}
    <input type="text" name="name">
    <input type="submit" value="提交">
</form>

二、訂單快照，減少存儲(chǔ)成本

商品信息是可以修改的，當(dāng)用戶下單后，為了更好解決后面可能存在的買賣糾紛，創(chuàng)建訂單時(shí)會(huì)同步保存一份商品詳情信息，稱之為訂單快照。

同一件商品，會(huì)有很多用戶會(huì)購買，如果熱銷商品，短時(shí)間就會(huì)有上萬的訂單。如果每個(gè)訂單都創(chuàng)建一份快照，存儲(chǔ)成本太高。另外商品信息雖然支持修改，但畢竟是一個(gè)低頻動(dòng)作。我們可以理解成，大部分訂單的商品快照信息都是一樣的，除非下單時(shí)用戶修改過。

如何實(shí)時(shí)識(shí)別修改動(dòng)作是解決快照成本的關(guān)鍵所在。我們采用摘要比對(duì)的方法?。創(chuàng)建訂單時(shí)，先檢查商品信息摘要是否已經(jīng)存在，如果不存在，會(huì)創(chuàng)建快照記錄。訂單明細(xì)會(huì)關(guān)聯(lián)商品的快照主鍵。

public class DigestTest {
    public static void encodeStr(String data) {
        String encodeS = DigestUtils.md5Hex(data);
        System.out.println(encodeS);
    }
    public static void main(String[] args) {
        String data = "網(wǎng)銷投連險(xiǎn)是保險(xiǎn)公司的一款保險(xiǎn)產(chǎn)品，在互聯(lián)網(wǎng)金融上還是很常見的。" + "比如京東天天盈，網(wǎng)易有錢零錢++。這些保險(xiǎn)削弱了保險(xiǎn)的保障功能，降低成本，從而提高保險(xiǎn)的理財(cái)功能提高理財(cái)收益。"
                      + "投連險(xiǎn)基本和銀行結(jié)構(gòu)性理財(cái)產(chǎn)品一樣，信息披露度不高，但是有保險(xiǎn)公司兜底，不至于整個(gè)平臺(tái)跑路。"
                      + "投資投連險(xiǎn)可以想象為投資一個(gè)起點(diǎn)低的銀行理財(cái)產(chǎn)品吧。網(wǎng)銷投連險(xiǎn)一般都受益在4-6%，不承諾保本。"
                      + "經(jīng)常爆出保險(xiǎn)公司的保障型長期投連險(xiǎn)出現(xiàn)投資虧損新聞，但是網(wǎng)銷短期投連險(xiǎn)投資型投連險(xiǎn)目前沒有出現(xiàn)虧損，基本也能按照預(yù)期收益兌付。"
                      + "網(wǎng)銷投連險(xiǎn)安全性和收益性都比較居中，短期產(chǎn)品危險(xiǎn)系數(shù)不高，但是在債券違約的大環(huán)境下，長期產(chǎn)品安全性沒有太大保障。" + "不過好在保險(xiǎn)公司沒有跑路風(fēng)險(xiǎn)，至少不會(huì)把本金損失殆盡啊。";
        encodeStr(data);
    }
}

由于訂單快照屬于非核心操作，即使失敗也不應(yīng)該影響用戶正常購買流程，所以通常采用異步流程執(zhí)行。

三、購物車，混合存儲(chǔ)

購物車是電商系統(tǒng)的標(biāo)配功能，暫存用戶想要購買的商品。分為添加商品、列表查看、結(jié)算下單三個(gè)動(dòng)作。

技術(shù)設(shè)計(jì)并不是特別復(fù)雜，存儲(chǔ)的信息也相對(duì)有限(用戶id、商品id、sku_id、數(shù)量、添加時(shí)間)。這里特別拿出來單講主要是用戶體驗(yàn)層面要注意幾個(gè)問題：

添加購物車時(shí)，后端校驗(yàn)用戶未登錄，常規(guī)思路，引導(dǎo)用戶跳轉(zhuǎn)登錄頁，待登錄成功后，再添加購物車。多了一步操作，給用戶一種強(qiáng)迫的感覺，體驗(yàn)會(huì)比較差。有沒有更好的方式?

如果細(xì)心體驗(yàn)京東、淘寶等大平臺(tái)，你會(huì)發(fā)現(xiàn)即使未登錄態(tài)也可以添加購物車，這到底是怎么實(shí)現(xiàn)的?

細(xì)細(xì)琢磨其實(shí)原理并不復(fù)雜，服務(wù)端這邊在用戶登錄態(tài)校驗(yàn)時(shí)，做了分支路由，當(dāng)用戶未登錄時(shí)，會(huì)創(chuàng)建一個(gè)臨時(shí)Token，作為用戶的唯一標(biāo)識(shí)，購物車數(shù)據(jù)掛載在該Token下，為了避免購物車數(shù)據(jù)相互影響以及設(shè)計(jì)的復(fù)雜度，這里會(huì)有一個(gè)臨時(shí)購物車表。

當(dāng)然，臨時(shí)購物車表的數(shù)據(jù)量并不會(huì)太大，why?用戶不會(huì)一直閑著添加購物車玩，當(dāng)用戶登錄后，查看自己的購物車，服務(wù)端會(huì)從請(qǐng)求的cookie里查找購物車Token標(biāo)識(shí)，并查詢臨時(shí)購物車表是否有數(shù)據(jù)，然后合并到正式購物車表里。

特別說明：

臨時(shí)購物車是不是一定要在服務(wù)端存儲(chǔ)?未必。

有架構(gòu)師傾向前置存儲(chǔ)，將數(shù)據(jù)存儲(chǔ)在瀏覽器或者APP LocalStorage，這部分?jǐn)?shù)據(jù)畢竟不是共享的，但是不太好的增加了設(shè)計(jì)的復(fù)雜度。

• 客戶端需要借助本地?cái)?shù)據(jù)索引，遠(yuǎn)程請(qǐng)求查完整信息。
• 如果是登錄態(tài)，還要增加數(shù)據(jù)合并邏輯。

考慮到這兩部分?jǐn)?shù)據(jù)只是用戶標(biāo)識(shí)的差異性，所以作者還是建議統(tǒng)一存到服務(wù)端，日后即使業(yè)務(wù)邏輯變更，只需要改一處就可以了，畢竟自運(yùn)營系統(tǒng)，良好的可維護(hù)性也需要我們非常關(guān)注的。

四、庫存超賣

常見的庫存扣減方式有：

• 下單減庫存：即當(dāng)買家下單后，在商品的總庫存中減去買家購買數(shù)量。下單減庫存是最簡單的減庫存方式，也是控制最精確的一種，下單時(shí)直接通過數(shù)據(jù)庫的事務(wù)機(jī)制控制商品庫存，這樣一定不會(huì)出現(xiàn)超賣的情況。但是你要知道，有些人下完單可能并不會(huì)付款。
• 付款減庫存：即買家下單后，并不立即減庫存，而是等到有用戶付款后才真正減庫存，否則庫存一直保留給其他買家。但因?yàn)楦犊顣r(shí)才減庫存，如果并發(fā)比較高，有可能出現(xiàn)買家下單后付不了款的情況，因?yàn)榭赡苌唐芬呀?jīng)被其他人買走了。
• 預(yù)扣庫存：這種方式相對(duì)復(fù)雜一些，買家下單后，庫存為其保留一定的時(shí)間(如 30 分鐘)，超過這個(gè)時(shí)間，庫存將會(huì)自動(dòng)釋放，釋放后其他買家就可以繼續(xù)購買。在買家付款前，系統(tǒng)會(huì)校驗(yàn)該訂單的庫存是否還有保留：如果沒有保留，則再次嘗試預(yù)扣;如果庫存不足(也就是預(yù)扣失敗)則不允許繼續(xù)付款;如果預(yù)扣成功，則完成付款并實(shí)際地減去庫存。

至于采用哪一種減庫存方式更多是業(yè)務(wù)層面的考慮，減庫存最核心的是大并發(fā)請(qǐng)求時(shí)保證數(shù)據(jù)庫中的庫存字段值不能為負(fù)數(shù)。

方案一：

通常在扣減庫存的場景下使用行級(jí)鎖，通過數(shù)據(jù)庫引擎本身對(duì)記錄加鎖的控制，保證數(shù)據(jù)庫的更新的安全性，并且通過where語句的條件，保證庫存不會(huì)被減到 0 以下，也就是能夠有效的控制超賣的場景。

update ... set amount = amount - 1 where id = $id and amount - 1 >=0

方案二：

設(shè)置數(shù)據(jù)庫的字段數(shù)據(jù)為無符號(hào)整數(shù)，這樣減后庫存字段值小于零時(shí) SQL 語句會(huì)報(bào)錯(cuò)。

五、商家發(fā)貨，物流單更新 ABA 問題

舉個(gè)例子：

商家發(fā)貨，填寫運(yùn)單號(hào)，開始填了 123，后來發(fā)現(xiàn)填錯(cuò)了，然后又修改為 456。

此時(shí)，如果就為某種特殊場景埋下錯(cuò)誤伏筆，具體我們來看下：

過程：

• 開始「請(qǐng)求A」發(fā)貨，調(diào)訂單服務(wù)接口，更新運(yùn)單號(hào) 123。
• 但是響應(yīng)有點(diǎn)慢，超時(shí)了。
• 此時(shí)，商家發(fā)現(xiàn)運(yùn)單號(hào)填錯(cuò)了，發(fā)起了「請(qǐng)求B」，更新運(yùn)單號(hào)為456 ，訂單服務(wù)也響應(yīng)成功了。
• 這時(shí)，「請(qǐng)求A」觸發(fā)了重試，再次調(diào)用訂單服務(wù)，更新運(yùn)單號(hào)123，訂單服務(wù)也響應(yīng)成功了。
• 訂單服務(wù)最后保存的 運(yùn)單號(hào) 是 123。

是不是犯錯(cuò)了!!!!

那么有什么好的解決方案嗎?

很多人可能會(huì)說，不重試不就可以了，要知道重試機(jī)制 是高可用服務(wù)的重要保障手段，很多重試是框架自動(dòng)發(fā)起的。

理想的解決方案：

數(shù)據(jù)庫表引入一個(gè)額外字段 version，每次更新時(shí)，判斷表中的版本號(hào)與請(qǐng)求參數(shù)攜帶的版本號(hào)是否一致。

update order
set logistics_num = #{logistics_num} , version = #{version} + 1
where order_id= 1111 and version = #{version}

• 一致：才觸發(fā)更新。
• 不一致：說明這期間執(zhí)行過數(shù)據(jù)更新，可能會(huì)引發(fā)錯(cuò)誤，拒絕執(zhí)行。

六、賬戶余額更新，保證事務(wù)

用戶支付，我們要從買家賬戶減掉一定金額，再往賣家增加一定金額，為了保證數(shù)據(jù)的完整性、可追溯性，變更余額時(shí)，我們通常會(huì)同時(shí)插入一條記錄流水。

賬戶流水核心字段：流水ID、金額、交易雙方賬戶、交易時(shí)間戳、訂單號(hào)。

注意：賬戶流水只能新增，不能修改和刪除。流水號(hào)必須是自增的。

后續(xù)，系統(tǒng)對(duì)賬時(shí)，我們只需要對(duì)交易流水明細(xì)數(shù)據(jù)做累計(jì)即可，如果出現(xiàn)和余額不一致情況，一般以交易流水為準(zhǔn)來修復(fù)余額數(shù)據(jù)。

更新余額、記錄流水 雖屬于兩個(gè)操作，但是要保證要么都成功，要么都失敗。要做到事務(wù)。

數(shù)據(jù)庫的事務(wù)隔離級(jí)別有：讀未提交(RU)、讀已提交(RC)、可重復(fù)讀(RR)、串行化(Serializable)。

常用的隔離級(jí)別是 RC 和 RR ，因?yàn)檫@兩種隔離級(jí)別都可以避免臟讀。

當(dāng)然，如果涉及多個(gè)微服務(wù)調(diào)用，會(huì)用到分布式事務(wù)。

分布式事務(wù)，細(xì)想下也很容易理解，就是將一個(gè)大事務(wù)拆分為多個(gè)本地事務(wù)，本地事務(wù)依然借助于數(shù)據(jù)庫自身事務(wù)來解決，難點(diǎn)在于解決這個(gè)分布式一致性問題，借助重試機(jī)制，保證最終一致是我們常用的方案。

七、MySQL讀寫分離帶來的數(shù)據(jù)不一致問題

互聯(lián)網(wǎng)業(yè)務(wù)大部分都是 讀多寫少，為了提升數(shù)據(jù)庫集群的吞吐性能，我們通常會(huì)采用 主從架構(gòu)、讀寫分離。

部署一個(gè)主庫實(shí)例，客戶端請(qǐng)求所有寫操作全部寫到主庫，然后借助 MySQL 自帶的 主從同步 功能，做一些簡單配置，可以近乎實(shí)時(shí)的將主庫的數(shù)據(jù)同步給 多個(gè)從庫實(shí)例，主從延遲非常小，一般不超過 1 毫秒。

客戶端請(qǐng)求的所有讀操作全部打到 從庫，借助多實(shí)例集群提升讀請(qǐng)求的整體處理能力。

這個(gè)方案看似天衣無縫，但實(shí)際有個(gè) 副作用。

主從同步雖然近乎實(shí)時(shí)，但還是有個(gè) 時(shí)間差 ，主庫數(shù)據(jù)剛更新完，但數(shù)據(jù)還沒來得及同步到從庫，后續(xù)讀請(qǐng)求直接訪問了從庫，看到的還是舊數(shù)據(jù)，影響用戶體驗(yàn)。

任何事情都不是完美的，從主同步也是一樣，沒有完美的解決方案，我們要找到其中的平衡取舍點(diǎn)。

我們以電商為例，看看如何從 產(chǎn)品層面 來化解這個(gè)問題。

為了實(shí)驗(yàn)的真實(shí)性，Tom哥 特意在淘寶下了一筆購物訂單。

在下單確認(rèn)頁面，點(diǎn)擊購買按鈕，進(jìn)入了支付頁面：

輸入支付寶支付密碼，進(jìn)入支付成功頁面，頁面有查看訂單詳情的入口。

點(diǎn)擊 查看交易詳情 ，才跳到真正的 訂單詳情頁，可以查看訂單的支付狀態(tài)(訂單數(shù)據(jù)取自從庫)。

看懂了嗎?

我們?cè)谥Ц冻晒?，并沒有立即跳到 訂單詳情頁，而是增加了一個(gè) 無關(guān)緊要的 中間頁(支付成功頁)，一是告訴你支付的結(jié)果是成功的，錢沒丟，不要擔(dān)心;另外也可以增加一些推薦商品，引流提升網(wǎng)站的GMV。最重要的，增加了一個(gè)緩沖期，為 訂單的主從庫數(shù)據(jù)同步爭取了更多的時(shí)間。

可謂一舉多得，其他互聯(lián)網(wǎng)業(yè)務(wù)也是類似道理。

是不是又學(xué)了一招。????

八、歷史訂單，歸檔

根據(jù)二八定律，系統(tǒng)絕大部分的性能開銷花在20%的業(yè)務(wù)。數(shù)據(jù)也不例外，從數(shù)據(jù)的使用頻率來看，經(jīng)常被業(yè)務(wù)訪問的數(shù)據(jù)稱為熱點(diǎn)數(shù)據(jù);反之，稱之為冷數(shù)據(jù)。

在了解的數(shù)據(jù)的冷、熱特性后，便可以指導(dǎo)我們做一些有針對(duì)性的性能優(yōu)化。這里面有業(yè)務(wù)層面的優(yōu)化，也有技術(shù)層面的優(yōu)化。比如：電商網(wǎng)站，一般只能查詢3個(gè)月內(nèi)的訂單，如果你想看看3個(gè)月前的訂單，需要訪問歷史訂單頁面。

實(shí)現(xiàn)思路：

1.冷熱數(shù)據(jù)區(qū)分的標(biāo)準(zhǔn)是什么?要結(jié)合業(yè)務(wù)思考，可能要找產(chǎn)品同學(xué)一塊討論才能做決策，切記不要拍腦袋。以電商訂單為例：

• 方案一：以“下單時(shí)間”為標(biāo)準(zhǔn)，將3 個(gè)月前的訂單數(shù)據(jù)當(dāng)作冷數(shù)據(jù)，3 個(gè)月內(nèi)的當(dāng)作熱數(shù)據(jù)。
• 方案二：根據(jù)“訂單狀態(tài)”字段來區(qū)分，已完結(jié)的訂單當(dāng)作冷數(shù)據(jù)，未完結(jié)的訂單當(dāng)作熱數(shù)據(jù)。
• 方案三：組合方式，把下單時(shí)間 > 3 個(gè)月且狀態(tài)為“已完結(jié)”的訂單標(biāo)識(shí)為冷數(shù)據(jù)，其他的當(dāng)作熱數(shù)據(jù)。

2.如何觸發(fā)冷熱數(shù)據(jù)的分離

• 方案一：直接修改業(yè)務(wù)代碼，每次業(yè)務(wù)請(qǐng)求觸發(fā)冷熱數(shù)據(jù)判斷，根據(jù)結(jié)果路由到對(duì)應(yīng)的冷數(shù)據(jù)表或熱數(shù)據(jù)表。缺點(diǎn)：如果判斷標(biāo)準(zhǔn)是 。 時(shí)間維度，數(shù)據(jù)過期了無法主動(dòng)感知。
• 方案二：如果覺得修改業(yè)務(wù)代碼，耦合性高，不易于后期維護(hù)。可以通過監(jiān)聽數(shù)據(jù)庫變更日志 binlog 方式來觸發(fā)。
• 方案三：常用的手段是跑定時(shí)任務(wù)，一般是選擇凌晨系統(tǒng)壓力小的時(shí)候，通過跑批任務(wù)，將滿足條件的冷數(shù)據(jù)遷移到其他存儲(chǔ)介質(zhì)。在途業(yè)務(wù)表中只留下來少量的熱點(diǎn)數(shù)據(jù)。

3.如何實(shí)現(xiàn)冷熱數(shù)據(jù)分離，過程大概分為三步：

• 判斷數(shù)據(jù)是冷、還是熱。
• 將冷數(shù)據(jù)插入冷數(shù)據(jù)表中。
• 然后，從原來的熱庫中刪除遷移的數(shù)據(jù)。

4.如何使用冷熱數(shù)據(jù)

• 方案一：界面設(shè)計(jì)時(shí)會(huì)有選項(xiàng)區(qū)分，如上面舉例的電商訂單。
• 方案二：直接在業(yè)務(wù)代碼里區(qū)分。

九、訂單分庫分表，多維度查詢

如果電商網(wǎng)站的訂單數(shù)過多，我們一般會(huì)想到 分庫分表 解決策略。沒問題，這個(gè)方向是對(duì)的。

但是查詢維度很多

1.買家，查詢 我的訂單 列表，需要根據(jù) buyer_id 來查詢。

2.查看訂單詳情，需要根據(jù) order_id 來查詢。

3.賣家，查詢 我的銷售 列表，需要根據(jù) seller_id 來查詢。

而訂單分表只有一個(gè)分表鍵，如何滿足多維度 SQL 操作呢?

我們一般是基于買家維度來設(shè)計(jì)，下圖是 淘寶 的訂單列表：

一個(gè)訂單號(hào) 19 位，我們會(huì)發(fā)現(xiàn)同一個(gè)用戶不同訂單的最后 6 位都是一樣的，沒錯(cuò)，那是用戶id的后6位。

這樣，上文中 場景1、場景2 的查詢可以共性抽取， 采用 buyer_id 或 order_id 的 后六位 作為分表鍵，對(duì) 1 000 000 取模，得到買家維度的訂單分表的編號(hào)。

至于 場景3 賣家維度的訂單查詢，我們可以采用數(shù)據(jù)異構(gòu)方式，按seller_id 維度另外存儲(chǔ)一份數(shù)據(jù)，專門供賣家使用。