欧美午夜精品久久久久免费视/欧美黄色精品/国产一级A片在线播出/A片免费视频在线观看

偉山老師出品

01

概述

訂單系統(tǒng)作為電商系統(tǒng)的“紐帶”貫穿了整個(gè)電商系統(tǒng)的關(guān)鍵流程。其他模塊都是圍繞訂單系統(tǒng)進(jìn)行完善的。訂單系統(tǒng)的演化也是隨著電商平臺(tái)的業(yè)務(wù)變化而漸漸演化進(jìn)化著，接出來(lái)就和你們一上去解析電商平臺(tái)的“生命紐帶”。

上帝視角訂單系統(tǒng)

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

02

訂單基本概念

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

訂單的多樣性特征

主要來(lái)歷源和操作的多樣造成了訂單多樣性點(diǎn)。

訂單數(shù)組

訂單數(shù)組包含了訂單中須要記錄的信息，他的作用主要用于溝通其他系統(tǒng)，為下游系統(tǒng)提供信息根據(jù)。

訂單信息

訂單號(hào)作為訂單辨識(shí)的標(biāo)示，通常依照某種特定規(guī)則生成，依照訂單的降低進(jìn)行自增，同時(shí)在設(shè)計(jì)訂單號(hào)的時(shí)侯考慮訂單無(wú)序設(shè)置（避免競(jìng)爭(zhēng)者或則第三方來(lái)計(jì)算訂單量）。訂單號(hào)后續(xù)用作訂單惟一標(biāo)識(shí)用于對(duì)接WMS（倉(cāng)存管理系統(tǒng)）和TMS（運(yùn)輸管理系統(tǒng)）時(shí)的訂單辨識(shí)。

訂單狀態(tài)

訂單狀態(tài)在下邊章節(jié)會(huì)詳盡描述

用戶信息

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

商品信息

商品的基本信息和庫(kù)存，金額因?yàn)楸容^特殊所以我把金額獨(dú)立在商品信息以外說(shuō)，不過(guò)邏輯上似乎都屬于商品信息范疇。商品信息主要影響庫(kù)存更新和WMS形成。

金額信息

訂單形成的商品信息，這兒面不僅要記錄最終的金額，過(guò)程金額也須要記錄。例如商品均攤的讓利金額、支付金額，應(yīng)付金額等。在后續(xù)的訂單結(jié)算、退換貨、財(cái)務(wù)等環(huán)節(jié)都須要使用。

時(shí)間信息

記錄訂單每位狀態(tài)節(jié)點(diǎn)的觸發(fā)時(shí)間。

03

訂單流程

訂單流程是指整個(gè)訂單從形成到完成整個(gè)流轉(zhuǎn)過(guò)程，包括了正向和逆向流程的過(guò)程。

正向流程

這兒面主要是涉及主流電商系統(tǒng)中的通用訂單流程，部份細(xì)節(jié)可以依照自己平臺(tái)的特殊性進(jìn)行調(diào)整。

須要注意的地方

訂單生成環(huán)節(jié)存在超時(shí)未支付手動(dòng)取消的過(guò)程，庫(kù)存的占用會(huì)在訂單取消后釋放。

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

金額平攤須要到商品

訂單系統(tǒng)初審主要對(duì)惡意用戶或則刷單情況進(jìn)行處理。系統(tǒng)可依照白名單、黑名單、消費(fèi)頻次、促銷品訂購(gòu)量方面做風(fēng)控規(guī)則。假如后續(xù)會(huì)步入到人工初審，則規(guī)則上可以適當(dāng)從寬。當(dāng)觸發(fā)規(guī)則須要進(jìn)行訂單退訂的行為。此處設(shè)計(jì)時(shí)要當(dāng)心對(duì)用戶體驗(yàn)的損害，常常前臺(tái)文案上說(shuō)明當(dāng)前節(jié)點(diǎn)是初審狀態(tài)或則是等待接單。

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

預(yù)售等貨和移倉(cāng)須要弄成SOA服務(wù)，便于在交易頁(yè)面估算預(yù)計(jì)時(shí)間和預(yù)計(jì)到貨時(shí)間。移倉(cāng)處理依賴庫(kù)房的情況，也會(huì)涉及到后續(xù)分拆和合并包裹的邏輯。

訂單形成時(shí)先要判定報(bào)缺情況，若果出現(xiàn)報(bào)缺問(wèn)題則要考慮整單報(bào)缺、部分報(bào)缺、換貨或則換轉(zhuǎn)退的情況（庫(kù)存，匆忙調(diào)撥和退票）。報(bào)缺情況分為系統(tǒng)報(bào)缺和實(shí)物報(bào)缺，這是承接但相對(duì)獨(dú)立的兩個(gè)環(huán)節(jié)。

電商系統(tǒng)要考慮7天無(wú)理由退款的情境，即訂單狀態(tài)完成后申請(qǐng)退款。此時(shí)主要涉及的是金額上的估算以及一些財(cái)務(wù)程序（如收據(jù)等）問(wèn)題的處理。

逆向流程

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

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

關(guān)注點(diǎn)

訂單狀態(tài)（某一節(jié)點(diǎn)后如訂單形成后不容許取消訂單）

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

部份退的訂單促銷通常保持享用狀態(tài)，但金額根據(jù)均攤的金額進(jìn)行退票

訂單狀態(tài)

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

1.正向和逆向流程維度

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

訂單推送

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

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

04

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

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

第一步：實(shí)現(xiàn)訂購(gòu)流程

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

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

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

4.支持促銷金額的估算

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

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

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

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

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

第三步：支持不同營(yíng)銷手段下的訂單類型

平臺(tái)發(fā)展到足夠大的規(guī)模，提效、穩(wěn)定弄成一個(gè)重要的話題。可以提供不同營(yíng)銷場(chǎng)景下的訂單，如：團(tuán)購(gòu)、預(yù)購(gòu)等。

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

第一代：簡(jiǎn)單粗魯

第一代的問(wèn)題

第一代系統(tǒng)因?yàn)椋唵螤顟B(tài)是在特定的服務(wù)器進(jìn)行處理，假如服務(wù)一旦出現(xiàn)問(wèn)題都會(huì)導(dǎo)致訂單的遺失，造成訂單流程難以進(jìn)行下去。

總結(jié)：

1、服務(wù)單點(diǎn)

2、數(shù)據(jù)庫(kù)單點(diǎn)

第二代：無(wú)狀態(tài)異步驅(qū)動(dòng)

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

總結(jié)：

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

第三代：隊(duì)列模式

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

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

實(shí)踐1:重試和補(bǔ)償

實(shí)踐2:冪等性

實(shí)踐3:一致性實(shí)踐

實(shí)踐4:工作流()

無(wú)狀態(tài)的，分布式布署，分布式儲(chǔ)存工作流狀態(tài)

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

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

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

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

基本的原理是讓主數(shù)據(jù)庫(kù)處理事務(wù)性查詢，而從數(shù)據(jù)庫(kù)處理查詢。數(shù)據(jù)庫(kù)復(fù)制被拿來(lái)把事務(wù)性查詢?cè)斐傻淖兏降郊褐械膹臄?shù)據(jù)庫(kù)。其實(shí)，主服務(wù)器也可以提供查詢服務(wù)。使用讀寫分離最大的作用無(wú)非是環(huán)境服務(wù)器壓力。

用處

降低冗余

降低了機(jī)器的處理能力

對(duì)于讀操作為主的應(yīng)用，使用讀寫分離是最好的場(chǎng)景，由于可以確保寫的服務(wù)器壓力更小，而讀又可以接受點(diǎn)時(shí)間上的延后。

讀寫分離提升性能之緣由

化學(xué)服務(wù)器降低，負(fù)荷降低

主從只負(fù)責(zé)各自的寫和讀，極大程度的減輕X鎖和S鎖爭(zhēng)用

從庫(kù)可配置引擎，提高查詢性能以及節(jié)省系統(tǒng)開(kāi)支

從庫(kù)同步主庫(kù)的數(shù)據(jù)和主庫(kù)直接寫還是有區(qū)別的，通過(guò)主庫(kù)發(fā)送來(lái)的恢復(fù)數(shù)據(jù)，并且，最重要區(qū)別在于主庫(kù)向從庫(kù)發(fā)送是異步的，從庫(kù)恢復(fù)數(shù)據(jù)也是異步的

讀寫分離適用與讀遠(yuǎn)小于寫的場(chǎng)景，假如只有一臺(tái)服務(wù)器，當(dāng)好多時(shí)，和會(huì)被那些訪問(wèn)中的數(shù)據(jù)堵塞，等待結(jié)束，并發(fā)性能不高。對(duì)于寫和讀比列相仿的應(yīng)用，應(yīng)當(dāng)布署雙主互相復(fù)制

可以在從庫(kù)啟動(dòng)是降低一些參數(shù)來(lái)提升其讀的性能，比如--skip-、--skip-bdb、--low--以及--delay-key-write=ALL。其實(shí)這種設(shè)置也是須要依照具體業(yè)務(wù)需求來(lái)定得，不一定能用上

平攤讀取。如果我們有1主3從，不考慮上述1中提及的從庫(kù)單方面設(shè)置，假定現(xiàn)今1分鐘內(nèi)有10條寫入，150條讀取。這么，1主3從相當(dāng)于共計(jì)40條寫入，而讀取總量沒(méi)變，因而平均出來(lái)每臺(tái)服務(wù)器承當(dāng)了10條寫入和50條讀取（主庫(kù)不承當(dāng)讀取操作）。為此，即使寫入沒(méi)變，然而讀取大大平攤了，增強(qiáng)了系統(tǒng)性能。另外，當(dāng)讀取被平攤后，又間接提升了寫入的性能。所以，總體性能提升了，說(shuō)白了就是拿機(jī)器和帶寬換性能。

MySQL復(fù)制另外一大功能是降低冗余，提升可用性，當(dāng)一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器宕機(jī)后能通過(guò)調(diào)整另外一臺(tái)從庫(kù)來(lái)以最快的速率恢復(fù)服務(wù)，因而不能光看性能，也就是說(shuō)1主1從也是可以的。

實(shí)現(xiàn)方案

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

不管是采用何種分庫(kù)分表框架或則平臺(tái)微信訂貨系統(tǒng)，其核心的思路都是將原先保存在單表中太大的數(shù)據(jù)進(jìn)行分拆，將那些數(shù)據(jù)分散保存到多個(gè)數(shù)據(jù)庫(kù)的多個(gè)表中，防止由于單表數(shù)據(jù)量太大給數(shù)據(jù)的訪問(wèn)帶來(lái)讀寫性能的問(wèn)題。所以在分庫(kù)分表場(chǎng)景下，最重要的一個(gè)原則就是被分拆的數(shù)據(jù)盡可能的平均拆分到前端的數(shù)據(jù)庫(kù)中，假如分拆的不均勻，就會(huì)形成數(shù)據(jù)訪問(wèn)熱點(diǎn)，同樣存在熱點(diǎn)數(shù)據(jù)由于下降過(guò)快而又面臨數(shù)據(jù)單表數(shù)據(jù)量過(guò)大的問(wèn)題。

而對(duì)于數(shù)據(jù)以哪些樣的經(jīng)度進(jìn)行分拆，你們看見(jiàn)好多場(chǎng)景中都是對(duì)業(yè)務(wù)數(shù)據(jù)的ID(大部份場(chǎng)景此ID是以自下降的形式)進(jìn)行HASH取模的方法將數(shù)據(jù)進(jìn)行平均分拆，這個(gè)簡(jiǎn)單的方法確實(shí)在好多場(chǎng)景下都是十分合適的分拆方式，但并不是在所有的場(chǎng)景中這樣分拆的方法都是最優(yōu)的選擇。也就是說(shuō)數(shù)據(jù)怎么分拆并沒(méi)有所謂的金科玉律，更多的是須要結(jié)合業(yè)務(wù)數(shù)據(jù)的結(jié)構(gòu)和業(yè)務(wù)場(chǎng)景來(lái)決定。

下邊以你們最熟悉的電商訂單數(shù)據(jù)分拆為例，訂單是任何一個(gè)電商平臺(tái)都有的業(yè)務(wù)數(shù)據(jù)，每位平臺(tái)用戶遞交訂單就會(huì)在平臺(tái)前端生成訂單相關(guān)的數(shù)據(jù)，通常記錄一條訂單數(shù)據(jù)的數(shù)據(jù)庫(kù)表結(jié)構(gòu)如下：

訂單數(shù)據(jù)主要由三張數(shù)據(jù)庫(kù)表組成，主訂單表對(duì)應(yīng)的就是用戶的一個(gè)訂單，每遞交一次就會(huì)生成一條主訂單表的數(shù)據(jù)。在有些情況下，用戶可能在一個(gè)訂單中選擇不同買家的商品微信訂貨系統(tǒng)，而每位買家又會(huì)根據(jù)該訂單中自己提供的商品估算相關(guān)的商品讓利（如滿100元減10元）以及根據(jù)不同的收貨地址設(shè)置不同的貨運(yùn)配送，所以會(huì)出現(xiàn)子訂單的相關(guān)概念，即一個(gè)主訂單會(huì)由多個(gè)子訂單組成，而真正對(duì)應(yīng)到具體每位商品訂單信息，則保存在訂單詳情表中。

假如一個(gè)電商平臺(tái)的業(yè)務(wù)發(fā)展健康的話，訂單數(shù)據(jù)是比較容易出現(xiàn)由于單個(gè)數(shù)據(jù)庫(kù)表中的數(shù)據(jù)量過(guò)大而導(dǎo)致性能的困局，所以須要對(duì)他進(jìn)行數(shù)據(jù)庫(kù)的分拆。此時(shí)從理論上對(duì)訂單分拆是可以由兩個(gè)經(jīng)度進(jìn)行的，一個(gè)經(jīng)度是通過(guò)訂單ID（通常為自下降ID）取模的方法，即以訂單ID為分庫(kù)分表鍵；一個(gè)是通過(guò)賣家用戶ID的經(jīng)度進(jìn)行哈希取模，即以賣家用戶ID為分庫(kù)分表鍵。

兩種方案做一下對(duì)比：

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

2、通過(guò)采用賣家ID取模的方法，例如也是根據(jù)1024取模，技術(shù)上則也能保證訂單數(shù)據(jù)分拆到前端的1024個(gè)數(shù)據(jù)庫(kù)表中，但這兒都會(huì)出現(xiàn)一個(gè)業(yè)務(wù)場(chǎng)景中帶來(lái)的問(wèn)題，就是假如有些買家是交易量十分大的，那這種買家的訂單數(shù)據(jù)量（非常是訂單詳情表的數(shù)據(jù)量）會(huì)比其他買家要多處不少，也就是會(huì)出現(xiàn)數(shù)據(jù)不平均的現(xiàn)象，最終造成這種買家的訂單數(shù)據(jù)所在的數(shù)據(jù)庫(kù)會(huì)相對(duì)其他數(shù)據(jù)庫(kù)提早步入數(shù)據(jù)歸檔（為防止在線交易數(shù)據(jù)庫(kù)的數(shù)據(jù)的減小帶來(lái)數(shù)據(jù)庫(kù)性能的問(wèn)題，通常將3個(gè)月內(nèi)的訂單數(shù)據(jù)保存在線交易數(shù)據(jù)庫(kù)中，超過(guò)3個(gè)月的訂單會(huì)歸檔前端專門的歸檔數(shù)據(jù)庫(kù)）。

所以從對(duì)『數(shù)據(jù)盡可能平均分拆』這條原則來(lái)看，根據(jù)訂單ID取模的形式看上去更能保證訂單數(shù)據(jù)的平均分拆，但我們暫時(shí)不要那么快下推論，也要按照不同的業(yè)務(wù)場(chǎng)景和最佳實(shí)踐角度多思索不同經(jīng)度帶來(lái)的異同點(diǎn)。

總結(jié)

電商平臺(tái)的需求始終在變化，驟然訂單系統(tǒng)的構(gòu)架也會(huì)急劇變化，構(gòu)架設(shè)計(jì)就是一個(gè)持續(xù)改進(jìn)的過(guò)程，這篇文章還有很多細(xì)節(jié)未提到，假如你想把訂單系統(tǒng)做的更好，須要愈發(fā)深入系統(tǒng)的每一個(gè)環(huán)節(jié)，例如：容災(zāi)、災(zāi)備、分流、流控都須要漸漸雕鑿，在構(gòu)架中沒(méi)有完美的構(gòu)架只有平衡的架構(gòu)，不要追求單點(diǎn)的完美，而是要追求多點(diǎn)的平衡。

作者介紹：李偉山，江湖人稱山哥，85年出品。以前在米么金服中級(jí)研制經(jīng)理，更早在華為、阿里巴巴任職，格言：Fakeituntilyoumakeit。"技術(shù)瑣話"、"三疊紀(jì)技術(shù)"專家團(tuán)成員，個(gè)人經(jīng)營(yíng)公眾號(hào)：技術(shù)方舟。

福利推薦：

1、公眾號(hào)回復(fù)：技術(shù)群，加入技術(shù)瑣話粉絲群

2、技術(shù)瑣話直播系列之《蘇寧促銷中心建設(shè)思路與架構(gòu)實(shí)踐》
時(shí)間：7/14 20:00-21:00
地點(diǎn)：B站，掃碼關(guān)注
講師介紹：
陳波旭，蘇寧易購(gòu)IT總部零售中臺(tái)BU交易中臺(tái)研發(fā)中心技術(shù)管理部高級(jí)架構(gòu)
師。十年研發(fā)于設(shè)計(jì)經(jīng)驗(yàn)，善于打造高可用，高性能，高并發(fā)的服務(wù)系統(tǒng)。
2015年加入蘇寧易購(gòu)，先后負(fù)責(zé)或參與過(guò)中臺(tái)多活改造，促銷優(yōu)惠券系統(tǒng)
拆分及架構(gòu)升級(jí)，家樂(lè)福交易能力融合等項(xiàng)目的架構(gòu)工作。目前主要負(fù)責(zé)
交易中臺(tái)促銷，會(huì)員域系統(tǒng)的架構(gòu)工作。

往期推薦：

技術(shù)瑣話

以分布式設(shè)計(jì)、架構(gòu)、體系思想為基礎(chǔ)，兼論研制相關(guān)的點(diǎn)點(diǎn)嘀嘀，不限于代碼、質(zhì)量體系和研制管理。

上一篇：做餐飲小程序是怎樣掙錢的？餐飲外賣平臺(tái)怎么掙錢？

下一篇：校園外賣微信訂餐系統(tǒng)在食堂訂餐中的設(shè)計(jì)、實(shí)現(xiàn)及優(yōu)化

• 鄉(xiāng)村小鎮(zhèn)外賣騎手的故事：互聯(lián)網(wǎng)快車下的新生活與兼職收入
• 掃碼點(diǎn)餐成電子時(shí)代新常態(tài)，消費(fèi)者體驗(yàn)與隱私保護(hù)需平衡
• 了解外賣平臺(tái)發(fā)展前景后，作者發(fā)表看法，技術(shù)推動(dòng)平臺(tái)升級(jí)
• 同城活動(dòng)報(bào)名系統(tǒng)：連接你我，開(kāi)啟無(wú)限可能
• 校園外賣_配送系統(tǒng)：打造本地智慧生活服務(wù)的專業(yè) SaaS 系統(tǒng)
• 外賣小程序開(kāi)發(fā)攻略：從需求明確到平臺(tái)選擇，全方位指南