訂單系統(tǒng)審核主要對惡意用戶或者刷單情況進(jìn)行處理。系統(tǒng)可根據(jù)白名單、黑名單、消費頻次、促銷品購買量方面做風(fēng)控規(guī)則。如果后續(xù)會進(jìn)入到人工審核，則規(guī)則上可以適當(dāng)從寬。當(dāng)觸發(fā)規(guī)則需要進(jìn)行訂單退訂的行為。此處設(shè)計時要小心對用戶體驗的損害，往往前臺文案上說明當(dāng)前節(jié)點是審核狀態(tài)或者是等待接單。

傳統(tǒng)電商則是通過關(guān)聯(lián)第三方物流的物流信息進(jìn)行跟蹤。

預(yù)售等貨和移倉需要做成SOA服務(wù)，以便在交易頁面計算預(yù)計時間和預(yù)計到貨時間。移倉處理依賴倉庫的情況，也會涉及到后續(xù)拆分和合并包裹的邏輯。

訂單產(chǎn)生時先要判斷報缺情況，如果出現(xiàn)報缺問題則要考慮整單報缺、部分報缺、換貨或者換轉(zhuǎn)退的情況（庫存，倉促調(diào)撥和退款）。報缺情況分為系統(tǒng)報缺和實物報缺，這是承接但相對獨立的兩個環(huán)節(jié)。

電商系統(tǒng)要考慮7天無理由退貨的情景，即訂單狀態(tài)完成后申請退貨。此時主要涉及的是金額上的計算以及一些財務(wù)程序（如發(fā)票等）問題的處理。

逆向流程

逆向流程指訂單發(fā)生取消、退貨等情況時引發(fā)的訂單流程過程。

觸發(fā)逆向流程的觸發(fā)主要有幾種情況：

用戶自主取消訂單（整單）；

風(fēng)控系統(tǒng)觸發(fā)取消訂單（整單）；

客服接到客訴仲裁后觸發(fā)取消訂單（整單）；

超時未支付取消訂單（整單）；

換貨報缺轉(zhuǎn)為退單（整單、部分報缺）；

關(guān)注點

訂單狀態(tài)（某一節(jié)點后如訂單產(chǎn)生后不允許取消訂單）；

當(dāng)退單被商家拒絕后需要轉(zhuǎn)入客服仲裁的環(huán)節(jié)；

部分退的訂單促銷一般保持享用狀態(tài)，但金額按照分?jǐn)偟慕痤~進(jìn)行退款；

訂單狀態(tài)

從訂單狀態(tài)設(shè)計目的和存在價值去分析和理解它背后設(shè)計機制：維度及維度顆粒度大小。

1. 正向和逆向流程維度

正向訂單：已鎖定、已確認(rèn)、已付款、已發(fā)貨、已結(jié)算、已完成、已取消等；

正向預(yù)售訂單：預(yù)付款已付未確認(rèn)、已確認(rèn)未付尾款（變更）；

正向問題單：未確認(rèn)、未鎖定、未發(fā)貨、部分付款、未付款等；

逆向退單：待結(jié)算、未收到貨、未入庫、質(zhì)檢不通過、部分收貨、已取消、客戶已收貨等；

逆向換單：完成、已結(jié)算、客服已收貨等；

2.服務(wù)對象維度

顧客/用戶：待付款、待發(fā)貨、待收貨、待評價、買家已付款、交易成功/失敗、賣家已發(fā)貨、退款成功、交易關(guān)閉；

ERP等其他交互系統(tǒng)：已鎖定、已確認(rèn)、已分倉、已分配、已出庫、已收貨、已完成等；

等待買家付款、待付款和待發(fā)貨訂單、退款中的訂單、定金已付、買家已付款；

賣家已發(fā)貨、交易成功、交易失敗、異常訂單；

訂單推送

當(dāng)狀態(tài)發(fā)生變化時，需要將對應(yīng)的變化情況告知給相關(guān)人員以便了解當(dāng)前訂單的情況，這就是訂單推送的作用。

訂單推送的觸發(fā)依賴于狀態(tài)機的變化，涉及到的信息包括：推送對象（用戶、物流人員、商家），推送方式（push、短信、微信），推送節(jié)點（狀態(tài)改變）。

04 訂單系統(tǒng)設(shè)計的挑戰(zhàn)和實踐

訂單系統(tǒng)需求演變

第一步：實現(xiàn)購買流程

1.實現(xiàn)訂單的創(chuàng)建、發(fā)貨、確認(rèn)等信息閉環(huán)；

2.支持訂單審核（初期可支持人工審核即可）；

3.支持用戶端顯示訂單相關(guān)信息；

4.支持促銷金額的計算；

第二步：提供服務(wù)

1.提供訂單分布式服務(wù)；

2.支持跨平臺交易單生成（即同一個大交易單內(nèi)既有商家商品又有自營商品或者是多個商家的商品）；

3.支持拆單、合并邏輯（配送單、支付單等）；

4.提供更豐富的訂單推送服務(wù)，完善訂單狀態(tài)；

第三步：支持不同營銷手段下的訂單類型

平臺發(fā)展到足夠大的規(guī)模，提效、穩(wěn)定變成一個重要的話題?？梢蕴峁┎煌瑺I銷場景下的訂單，如：團(tuán)購、預(yù)購等。

訂單系統(tǒng)架構(gòu)的演變

第一代：簡單粗暴

第一代的問題

第一代系統(tǒng)由于，訂單狀態(tài)是在特定的服務(wù)器進(jìn)行處理，如果服務(wù)一旦出現(xiàn)問題就會造成訂單的丟失，導(dǎo)致訂單流程無法進(jìn)行下去。

總結(jié)：

1、服務(wù)單點

2、數(shù)據(jù)庫單點

第二代：無狀態(tài)異步驅(qū)動

第二代系統(tǒng)對于第一代有了很好的提升，應(yīng)用服務(wù)器不再保留訂單狀態(tài)，但是這樣的系統(tǒng)設(shè)計同時也給數(shù)據(jù)庫服務(wù)器造成了高頻查詢帶來的壓力，導(dǎo)致數(shù)據(jù)庫相對比較脆弱。

總結(jié)：

狀態(tài)掃描帶來的負(fù)載

第三代：隊列模式

第三代是對于第二代的升級，訂單的狀態(tài)流轉(zhuǎn)不再依靠高頻查詢數(shù)據(jù)庫來獲得，通過隊列模式，很好減輕了數(shù)據(jù)庫的壓力，但是第三代依然有問題，就是該系統(tǒng)中server2成了核心，該模塊的維護(hù)就會變得很復(fù)雜，這也是架構(gòu)設(shè)計的關(guān)鍵，沒有完全的完美架構(gòu)，只能得到一個平衡架構(gòu)。

三代系統(tǒng)演變中的最佳實踐

實踐1: 重試和補償

多個機器重試不能同步, 需要隨機跳躍(Jitter)和指數(shù)回退 (exponential back-off)

正在重試的服務(wù)也可能宕機，需要保存狀態(tài) (State)

實踐2: 冪等性

你沒收到響應(yīng)不見得失敗了

你響應(yīng)了不見得別人以為你成功了 

重試必需帶上唯一的有意義的ID 

每一個服務(wù)的調(diào)用都必須是冪等的 

非只讀的服務(wù)必須保存狀態(tài)

實踐3: 一致性實踐

訂單系統(tǒng)有強一致性需求

無單點故障的分布式系統(tǒng)的一致性是非常困難的問題

已有算法:Paxos，現(xiàn)有開源系統(tǒng)(e.g. Zookeeper)

有時候單點故障并不可怕，常用的，成熟的關(guān)系數(shù)據(jù)庫方案也是一個不錯的選擇

云端分布式無單點故障的系統(tǒng)

實踐4: 工作流 (Workflow)

可擴(kuò)展性:

無狀態(tài)的Worker，分布式部署，分布式存儲 工作流狀態(tài)

可靠性:

定時器、重試、冪等性、強一致性的狀態(tài)

可維護(hù)性:

工作流的描述和執(zhí)行Activity描述相分離, 支持異步觸發(fā)

支持版本和升級

系統(tǒng)優(yōu)化；

數(shù)據(jù)庫讀寫分離；

基本的原理是讓主數(shù)據(jù)庫處理事務(wù)性查詢，而從數(shù)據(jù)庫處理SELECT查詢。數(shù)據(jù)庫復(fù)制被用來把事務(wù)性查詢導(dǎo)致的變更同步到集群中的從數(shù)據(jù)庫。 當(dāng)然，主服務(wù)器也可以提供查詢服務(wù)。使用讀寫分離最大的作用無非是環(huán)境服務(wù)器壓力。

好處

增加冗余；

增加了機器的處理能力；

對于讀操作為主的應(yīng)用，使用讀寫分離是最好的場景，因為可以確保寫的服務(wù)器壓力更小，而讀又可以接受點時間上的延遲；

讀寫分離提高性能之原因；

物理服務(wù)器增加，負(fù)荷增加；

主從只負(fù)責(zé)各自的寫和讀，極大程度的緩解X鎖和S鎖爭用；

從庫可配置myisam引擎，提升查詢性能以及節(jié)約系統(tǒng)開銷；

從庫同步主庫的數(shù)據(jù)和主庫直接寫還是有區(qū)別的，通過主庫發(fā)送來的binlog恢復(fù)數(shù)據(jù)，但是，最重要區(qū)別在于主庫向從庫發(fā)送binlog是異步的，從庫恢復(fù)數(shù)據(jù)也是異步的讀寫分離適用與讀遠(yuǎn)大于寫的場景，如果只有一臺服務(wù)器，當(dāng)select很多時，update和delete會被這些select訪問中的數(shù)據(jù)堵塞，等待select結(jié)束，并發(fā)性能不高。 對于寫和讀比例相近的應(yīng)用，應(yīng)該部署雙主相互復(fù)制。

可以在從庫啟動是增加一些參數(shù)來提高其讀的性能，例如--skip-innodb、--skip-bdb、--low-priority-updates以及--delay-key-write=ALL。當(dāng)然這些設(shè)置也是需要根據(jù)具體業(yè)務(wù)需求來定得，不一定能用上

分?jǐn)傋x取。假如我們有1主3從，不考慮上述1中提到的從庫單方面設(shè)置，假設(shè)現(xiàn)在1分鐘內(nèi)有10條寫入，150條讀取。那么，1主3從相當(dāng)于共計40條寫入，而讀取總數(shù)沒變，因此平均下來每臺服務(wù)器承擔(dān)了10條寫入和50條讀?。ㄖ鲙觳怀袚?dān)讀取操作）。因此，雖然寫入沒變，但是讀取大大分?jǐn)偭?，提高了系統(tǒng)性能。另外，當(dāng)讀取被分?jǐn)偤螅珠g接提高了寫入的性能。所以，總體性能提高了，說白了就是拿機器和帶寬換性能。

MySQL復(fù)制另外一大功能是增加冗余，提高可用性，當(dāng)一臺數(shù)據(jù)庫服務(wù)器宕機后能通過調(diào)整另外一臺從庫來以最快的速度恢復(fù)服務(wù)，因此不能光看性能，也就是說1主1從也是可以的。

實現(xiàn)方案

數(shù)據(jù)庫分庫分表

不管是采用何種分庫分表框架或者平臺，其核心的思路都是將原本保存在單表中太大的數(shù)據(jù)進(jìn)行拆分，將這些數(shù)據(jù)分散保存到多個數(shù)據(jù)庫的多個表中，避免因為單表數(shù)據(jù)量太大給數(shù)據(jù)的訪問帶來讀寫性能的問題。所以在分庫分表場景下，最重要的一個原則就是被拆分的數(shù)據(jù)盡可能的平均拆分到后端的數(shù)據(jù)庫中，如果拆分的不均勻，還會產(chǎn)生數(shù)據(jù)訪問熱點，同樣存在熱點數(shù)據(jù)因為增長過快而又面臨數(shù)據(jù)單表數(shù)據(jù)量過大的問題。

而對于數(shù)據(jù)以什么樣的緯度進(jìn)行拆分，大家看到很多場景中都是對業(yè)務(wù)數(shù)據(jù)的ID(大部分場景此ID是以自增長的方式)進(jìn)行HASH取模的方式將數(shù)據(jù)進(jìn)行平均拆分，這個簡單的方式確實在很多場景下都是非常合適的拆分方法，但并不是在所有的場景中這樣拆分的方式都是最優(yōu)的選擇。也就是說數(shù)據(jù)如何拆分并沒有所謂的金科玉律，更多的是需要結(jié)合業(yè)務(wù)數(shù)據(jù)的結(jié)構(gòu)和業(yè)務(wù)場景來決定。

下面以大家最熟悉的電商訂單數(shù)據(jù)拆分為例，訂單是任何一個電商平臺都有的業(yè)務(wù)數(shù)據(jù)，每個平臺用戶提交訂單都會在平臺后端生成訂單相關(guān)的數(shù)據(jù)，一般記錄一條訂單數(shù)據(jù)的數(shù)據(jù)庫表結(jié)構(gòu)如下：

訂單數(shù)據(jù)主要由三張數(shù)據(jù)庫表組成，主訂單表對應(yīng)的就是用戶的一個訂單，每提交一次都會生成一條主訂單表的數(shù)據(jù)。在有些情況下，用戶可能在一個訂單中選擇不同賣家的商品，而每個賣家又會按照該訂單中自己提供的商品計算相關(guān)的商品優(yōu)惠（如滿100元減10元）以及按照不同的收貨地址設(shè)置不同的物流配送，所以會出現(xiàn)子訂單的相關(guān)概念，即一個主訂單會由多個子訂單組成，而真正對應(yīng)到具體每個商品訂單信息，則保存在訂單詳情表中。

如果一個電商平臺的業(yè)務(wù)發(fā)展健康的話，訂單數(shù)據(jù)是比較容易出現(xiàn)因為單個數(shù)據(jù)庫表中的數(shù)據(jù)量過大而造成性能的瓶頸，所以需要對他進(jìn)行數(shù)據(jù)庫的拆分。此時從理論上對訂單拆分是可以由兩個緯度進(jìn)行的，一個緯度是通過訂單ID（一般為自增長ID）取模的方式，即以訂單ID為分庫分表鍵；一個是通過買家用戶ID的緯度進(jìn)行哈希取模，即以買家用戶ID為分庫分表鍵。

兩種方案做一下對比

1、如果是按照訂單ID取模的方式，比如按1024取模，則可以保證主訂單以及相關(guān)子訂單，訂單詳情數(shù)據(jù)平均落入到后端1024個數(shù)據(jù)庫表中，原則上很好地滿足了數(shù)據(jù)盡可能平均拆分的原則。

2、通過采用買家ID取模的方式，比如也是按照1024取模，技術(shù)上則也能保證訂單數(shù)據(jù)拆分到后端的1024個數(shù)據(jù)庫表中，但這里就會出現(xiàn)一個業(yè)務(wù)場景中帶來的問題，就是如果有些賣家是交易量非常大的，那這些賣家的訂單數(shù)據(jù)量（特別是訂單詳情表的數(shù)據(jù)量）會比其他賣家要多處不少，也就是會出現(xiàn)數(shù)據(jù)不平均的現(xiàn)象，最終導(dǎo)致這些賣家的訂單數(shù)據(jù)所在的數(shù)據(jù)庫會相對其他數(shù)據(jù)庫提前進(jìn)入數(shù)據(jù)歸檔（為避免在線交易數(shù)據(jù)庫的數(shù)據(jù)的增大帶來數(shù)據(jù)庫性能的問題，一般將3個月內(nèi)的訂單數(shù)據(jù)保存在線交易數(shù)據(jù)庫中，超過3個月的訂單會歸檔后端專門的歸檔數(shù)據(jù)庫）。

所以從對『數(shù)據(jù)盡可能平均拆分』這條原則來看，按照訂單ID取模的方式看起來更能保證訂單數(shù)據(jù)的平均拆分，但我們暫時不要這么快下結(jié)論，也要根據(jù)不同的業(yè)務(wù)場景和最佳實踐角度多思考不同緯度帶來的優(yōu)缺點。

總結(jié)

電商平臺的需求一直在變化，訂單系統(tǒng)的架構(gòu)也會隨之變化，架構(gòu)設(shè)計就是一個持續(xù)改進(jìn)的過程，這篇文章還有好多細(xì)節(jié)未提及，如果你想把訂單系統(tǒng)做的更好，需要更加深入系統(tǒng)的每一個環(huán)節(jié)，比如：容災(zāi)、災(zāi)備、分流、流控都需要慢慢雕琢，在架構(gòu)中沒有完美的架構(gòu)只有平衡的架構(gòu)，無需追求單點的完美，而是要追求多點的平衡。

數(shù)商云全鏈數(shù)字化產(chǎn)品解決方案， 實現(xiàn)供應(yīng)鏈上中下游資源整合管理

--------

供應(yīng)鏈系統(tǒng) / 供應(yīng)商系統(tǒng) / B2B電商系統(tǒng) / 采購系統(tǒng) / 渠道商系統(tǒng) / 經(jīng)銷商系統(tǒng)

0 費 用 系 統(tǒng) 演 示

▼

文章來源：CSDN

<數(shù)商云（www.zhimaihui.cn）是國內(nèi)知名全鏈數(shù)字化產(chǎn)品以及解決方案服務(wù)商，為企業(yè)級商家提供專業(yè)的系統(tǒng)開發(fā)（多種模式電商平臺搭建：B2B/B2B2C/B2C/O2O/新零售等）、供應(yīng)鏈系統(tǒng)搭建及電商行業(yè)解決方案服務(wù)>