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

大家好，我是Tom哥。

做為一名程序員，發(fā)展方向大致可以分為兩個方面：一個是業(yè)務(wù)架構(gòu)，一個是技術(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ù)有不同的特點。

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

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

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

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

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

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

解決方案：

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

方案一：

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

操作過程：

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

方案二：

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

不建議采用該方案，如果想用，也只是作為一個補充方案。

方案三：

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

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

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

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

二、訂單快照，減少存儲成本

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

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

如何實時識別修改動作是解決快照成本的關(guān)鍵所在。我們采用摘要比對的方法?。創(chuàng)建訂單時，先檢查商品信息摘要是否已經(jīng)存在，如果不存在，會創(chuàng)建快照記錄。訂單明細會關(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)銷投連險是保險公司的一款保險產(chǎn)品，在互聯(lián)網(wǎng)金融上還是很常見的。" + "比如京東天天盈，網(wǎng)易有錢零錢++。這些保險削弱了保險的保障功能，降低成本，從而提高保險的理財功能提高理財收益。"
                      + "投連險基本和銀行結(jié)構(gòu)性理財產(chǎn)品一樣，信息披露度不高，但是有保險公司兜底，不至于整個平臺跑路。"
                      + "投資投連險可以想象為投資一個起點低的銀行理財產(chǎn)品吧。網(wǎng)銷投連險一般都受益在4-6%，不承諾保本。"
                      + "經(jīng)常爆出保險公司的保障型長期投連險出現(xiàn)投資虧損新聞，但是網(wǎng)銷短期投連險投資型投連險目前沒有出現(xiàn)虧損，基本也能按照預(yù)期收益兌付。"
                      + "網(wǎng)銷投連險安全性和收益性都比較居中，短期產(chǎn)品危險系數(shù)不高，但是在債券違約的大環(huán)境下，長期產(chǎn)品安全性沒有太大保障。" + "不過好在保險公司沒有跑路風險，至少不會把本金損失殆盡啊。";
        encodeStr(data);
    }
}

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

三、購物車，混合存儲

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

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

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

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

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

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

特別說明：

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

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

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

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

四、庫存超賣

常見的庫存扣減方式有：

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

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

方案一：

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

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

方案二：

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

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

舉個例子：

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

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

過程：

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

是不是犯錯了!!!!

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

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

理想的解決方案：

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

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

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

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

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

賬戶流水核心字段：流水ID、金額、交易雙方賬戶、交易時間戳、訂單號。

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

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

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

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

常用的隔離級別是 RC 和 RR ，因為這兩種隔離級別都可以避免臟讀。

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

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

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

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

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

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

這個方案看似天衣無縫，但實際有個 副作用。

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

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

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

為了實驗的真實性，Tom哥 特意在淘寶下了一筆購物訂單。

在下單確認頁面，點擊購買按鈕，進入了支付頁面：

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

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

看懂了嗎?

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

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

是不是又學了一招。????

八、歷史訂單，歸檔

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

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

實現(xiàn)思路：

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

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

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

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

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

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

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

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

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

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

但是查詢維度很多

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

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

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

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

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

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

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

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