訂單系統(tǒng)作為電商系統(tǒng)的“紐帶”貫穿了整個電商系統(tǒng)的關(guān)鍵流程。其他模塊都是圍繞訂單系統(tǒng)進行構(gòu)建的,。訂單系統(tǒng)的演變也是隨著電商平臺的業(yè)務(wù)變化而逐漸演變進化著,，接下來就和大家一起來解析電商平臺的“生命紐帶”。

訂單系統(tǒng)的作用是：管理訂單類型,、訂單狀態(tài),，收集關(guān)于商品,、優(yōu)惠、用戶,、收貨信息、支付信息等一系列的訂單實時數(shù)據(jù),，進行庫存更新、訂單下發(fā)等一系列動作,。訂單系統(tǒng)業(yè)務(wù)的基本模型涉及用戶,、商品（庫存）、訂單,、付款,，訂單基本流程是下訂單——>減庫存,，這兩步必須同時完成,，不能下了訂單不減庫存（超賣），或者減了庫存沒有生成訂單（少賣）,。超賣商家?guī)齑娌蛔悖M者下了單買不到東西,，體驗不好；少賣商家?guī)齑娣e壓或者需要反復修改商品信息，反復麻煩,，體驗也不好,。

設(shè)計訂單系統(tǒng)時包含幾個大的方向需要考慮，這些內(nèi)容決定了訂單系統(tǒng)的穩(wěn)定性和可持續(xù)性。

主要由來源和操作的多樣導致了訂單多樣性點,。

訂單字段包含了訂單中需要記錄的信息,，他的作用主要用于溝通其他系統(tǒng)，為下游系統(tǒng)提供信息依據(jù),。

訂單號作為訂單識別的標識,，一般按照某種特定規(guī)則生成,，根據(jù)訂單的增加進行自增，同時在設(shè)計訂單號的時候考慮訂單無序設(shè)置（防止競爭者或者第三方來估算訂單量）,。訂單號后續(xù)用作訂單唯一標示用于對接WMS（倉存管理系統(tǒng)）和TMS（運輸管理系統(tǒng)）時的訂單識別,。

訂單狀態(tài)在下面章節(jié)會詳細描述

指買家的相關(guān)信息，包括名稱,、地址,、手機號。O2O還會多一種情況就是自提點，這樣地址則會變?yōu)樽蕴狳c的地址,。地址信息在后續(xù)會作用在WMS和TMS上用于區(qū)分區(qū)域和配送安排,。

商品的基本信息和庫存，金額由于比較特殊所以我把金額獨立在商品信息以外說,，不過邏輯上其實都屬于商品信息范疇,。商品信息主要影響庫存更新和WMS產(chǎn)生。

訂單產(chǎn)生的商品信息,，這里面除了要記錄最終的金額,，過程金額也需要記錄。比如商品分攤的優(yōu)惠金額,、支付金額,，應(yīng)付金額等。在后續(xù)的訂單結(jié)算,、退換貨,、財務(wù)等環(huán)節(jié)都需要使用。

記錄訂單每個狀態(tài)節(jié)點的觸發(fā)時間,。

訂單流程是指整個訂單從產(chǎn)生到完成整個流轉(zhuǎn)過程,，包括了正向和逆向流程的過程。

這里面主要是涉及主流電商系統(tǒng)中的通用訂單流程,，部分細節(jié)可以根據(jù)自己平臺的特殊性進行調(diào)整,。

1. 訂單生成環(huán)節(jié)存在超時未支付自動取消的過程，庫存的占用會在訂單取消后釋放,。

2. 如果選擇COD（貨到付款）則支付環(huán)節(jié)相應(yīng)轉(zhuǎn)移到訂單配送之后,，而過程中所有與款項相關(guān)的邏輯變?yōu)橹徊僮鹘痤~數(shù)字，不對結(jié)算和賬戶進行打退款操作,。

3. 金額分攤需要到商品

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 部分退的訂單促銷一般保持享用狀態(tài),，但金額按照分攤的金額進行退款

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

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

• 正向預售訂單：預付款已付未確認,、已確認未付尾款（變更）

• 正向問題單：未確認,、未鎖定、未發(fā)貨,、部分付款,、未付款等

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

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

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

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

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

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

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

訂單推送的觸發(fā)依賴于狀態(tài)機的變化,，涉及到的信息包括

• 推送對象（用戶,、物流人員、商家）

• 推送方式（push,、短信,、微信）

• 推送節(jié)點（狀態(tài)改變）

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

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

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

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

4.支持促銷金額的計算

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

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

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

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

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

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

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

第一代：簡單粗暴

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

總結(jié)：

1、服務(wù)單點

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

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

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

總結(jié)：

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

第三代：隊列模式

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

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

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

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

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

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

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

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

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

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

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

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

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

• 可擴展性:

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

• 可靠性:

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

• 可維護性:

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

• 支持版本和升級

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

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

1. 增加冗余

2. 增加了機器的處理能力

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

1. 物理服務(wù)器增加,，負荷增加

2. 主從只負責各自的寫和讀，極大程度的緩解X鎖和S鎖爭用

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

4. 從庫同步主庫的數(shù)據(jù)和主庫直接寫還是有區(qū)別的,，通過主庫發(fā)送來的binlog恢復數(shù)據(jù)，但是,，最重要區(qū)別在于主庫向從庫發(fā)送binlog是異步的,，從庫恢復數(shù)據(jù)也是異步的

5. 讀寫分離適用與讀遠大于寫的場景，如果只有一臺服務(wù)器,，當select很多時,，update和delete會被這些select訪問中的數(shù)據(jù)堵塞，等待select結(jié)束,，并發(fā)性能不高,。 對于寫和讀比例相近的應(yīng)用，應(yīng)該部署雙主相互復制

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

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

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

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

而對于數(shù)據(jù)以什么樣的緯度進行拆分，大家看到很多場景中都是對業(yè)務(wù)數(shù)據(jù)的ID(大部分場景此ID是以自增長的方式)進行HASH取模的方式將數(shù)據(jù)進行平均拆分,，這個簡單的方式確實在很多場景下都是非常合適的拆分方法,，但并不是在所有的場景中這樣拆分的方式都是最優(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ù)量過大而造成性能的瓶頸,，所以需要對他進行數(shù)據(jù)庫的拆分。此時從理論上對訂單拆分是可以由兩個緯度進行的,，一個緯度是通過訂單ID（一般為自增長ID）取模的方式,，即以訂單ID為分庫分表鍵；一個是通過買家用戶ID的緯度進行哈希取模，即以買家用戶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)象,，最終導致這些賣家的訂單數(shù)據(jù)所在的數(shù)據(jù)庫會相對其他數(shù)據(jù)庫提前進入數(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)缺點,。

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