京東物流系統(tǒng)如何運(yùn)轉(zhuǎn)才能支撐618后1199億的物流

 　
     昨日京東618大促，最終以1199億的銷(xiāo)售額完美落幕 。也意味著接下來(lái)至少一個(gè)月的時(shí)間將有過(guò)千億的產(chǎn)品流動(dòng)，   那我們知道 在京東的訂單流鏈路中，可以簡(jiǎn)單的劃分為訂單前和訂單后兩部分，我們?cè)诰〇|主站上搜索商品、瀏覽商品詳情、把商品加入購(gòu)物車(chē)、提交并支付訂單等環(huán)節(jié)屬于訂單前，訂單提交之后，訂單信息流就進(jìn)入訂單后的物流系統(tǒng)部分。每逢 618 大促期間，大家可能會(huì)更多的聚焦到網(wǎng)站 PV、秒殺系統(tǒng)、交易數(shù)據(jù)、廣告收入等等。其實(shí)對(duì)于京東來(lái)說(shuō)，其很核心的優(yōu)勢(shì)來(lái)源于精準(zhǔn)的時(shí)效承諾、極速的送貨體驗(yàn)和極致的售后服務(wù)，在大促期間，其物流系統(tǒng)的表現(xiàn)對(duì)客戶(hù)體驗(yàn)至關(guān)重要。
　　京東物流系統(tǒng)簡(jiǎn)介
京東物流系統(tǒng)屬于訂單生產(chǎn)系統(tǒng)，主要包括訂單履約、倉(cāng)儲(chǔ)、配送、客戶(hù)服務(wù)和逆向處置中心等等。圖 1 示意了一個(gè)簡(jiǎn)單的正向訂單生產(chǎn)流程，逆向生產(chǎn)流程主要由逆向處置中心發(fā)起，主要包括售后服務(wù)單（退換貨等）和安裝維修單。

圖 1 訂單生產(chǎn)流程
京東物流系統(tǒng)有如下 3 大特性：
· 
90% 以上為 OLTP 系統(tǒng)，承載著訂單生產(chǎn)相關(guān)的所有核心交易流程
· 
· 
領(lǐng)域模型和業(yè)務(wù)邏輯復(fù)雜
· 
· 
強(qiáng)依賴(lài)關(guān)系型數(shù)據(jù)庫(kù)
· 
以上特性也決定了物流系統(tǒng)的大促備戰(zhàn)和電商網(wǎng)站、訂單交易、秒殺、搜索推薦、廣告等系統(tǒng)會(huì)大有不同，在很大程度上系統(tǒng) 70% 以上的性能（容量）取決于 DB 的性能（容量）。因此，DB 是我們每次大促備戰(zhàn)的重點(diǎn)。圍繞 DB 側(cè)的備戰(zhàn)工作，主要聚焦在慢 SQL、垂直和水平拆分、讀寫(xiě)分離、生產(chǎn)庫(kù)和報(bào)表庫(kù)分離、連接池優(yōu)化、參數(shù)調(diào)優(yōu)等方面。
　　打不死的小強(qiáng)—慢 SQL
記得剛加入京東第一次負(fù)責(zé) 618 的時(shí)候，在 618 當(dāng)天就遇到了兩次業(yè)務(wù)反饋系統(tǒng)卡頓的現(xiàn)象，緊急排查發(fā)現(xiàn) DB 中大量連接堆積，再通過(guò)查看當(dāng)前線(xiàn)程發(fā)現(xiàn)是一個(gè)慢 SQL（耗時(shí) 10 多秒）導(dǎo)致了連接堆積，后來(lái)把慢 SQL 緊急優(yōu)化上線(xiàn)后系統(tǒng)恢復(fù)正常。從那天以后，我深深感受到了慢 SQL 對(duì)我們系統(tǒng)的影響，同時(shí)也明白了一點(diǎn)，一個(gè)慢 SQL 對(duì)我們的系統(tǒng)總是致命的，我們不能放過(guò)任何一個(gè)慢 SQL。為了說(shuō)明一個(gè)慢 SQL 對(duì)系統(tǒng)的影響，截取了兩張數(shù)據(jù)庫(kù) CPU 使用率在一個(gè)慢 SQL 優(yōu)化前后的對(duì)比圖（如圖 2），從圖中也可以看出，前后對(duì)比是非常明顯的。

圖 2 一個(gè)慢 SQL 優(yōu)化前后 CPU 負(fù)載對(duì)比
在數(shù)據(jù)庫(kù)優(yōu)化方面，慢 SQL 優(yōu)化是最重要且效果最好的一項(xiàng)工作，如果要用一個(gè)比喻去形容慢 SQL，打不死的小強(qiáng)是再貼切不過(guò)的了，慢 SQL 在我們的系統(tǒng)中是滅了一茬又一茬，似乎永遠(yuǎn)消滅不完。通常情況下，慢 SQL 的出現(xiàn)可能是因?yàn)檫^(guò)濾條件中沒(méi)有索引、SQL 語(yǔ)句寫(xiě)的過(guò)于復(fù)雜、表中數(shù)據(jù)量過(guò)大，做了全表掃描等等，因此我們?cè)谶M(jìn)行慢 SQL 優(yōu)化時(shí)，優(yōu)先會(huì)通過(guò)添加索引解決，索引解決不了的才會(huì)去優(yōu)化語(yǔ)法，拆解 SQL 語(yǔ)句，將大事務(wù)化小，通過(guò)適當(dāng)冗余來(lái)減少關(guān)聯(lián)，優(yōu)化數(shù)據(jù)模型，通過(guò)歷史數(shù)據(jù)結(jié)轉(zhuǎn)減少數(shù)據(jù)量等等?？傊畠?yōu)化慢 SQL 的方法很多，各系統(tǒng)要根據(jù)各自的特性和場(chǎng)景選擇最優(yōu)且成本最低的方案。
近幾年來(lái)，京東的業(yè)務(wù)一直處于持續(xù)膨脹之中，系統(tǒng)中總會(huì)不斷涌入很多新的業(yè)務(wù)需求，這樣也就不可避免的引入了新的慢 SQL，所以每次大促，慢 SQL 優(yōu)化是一大備戰(zhàn)重點(diǎn)。
　　數(shù)據(jù)庫(kù)垂直和水平拆分
跟傳統(tǒng)的企業(yè)應(yīng)用系統(tǒng)一樣，京東的倉(cāng)儲(chǔ)系統(tǒng)也經(jīng)歷過(guò) C/S 和 B/S 時(shí)代，V3.0 之前用的是 SQLServer 和.Net 平臺(tái)，而且整個(gè)倉(cāng)儲(chǔ)管理是一個(gè)系統(tǒng)，包括基礎(chǔ)資料、庫(kù)存、入庫(kù)、出庫(kù)、在庫(kù)等，隨著京東業(yè)務(wù)規(guī)模的迅速增長(zhǎng)，每次大促的單量峰值也由早期的萬(wàn)級(jí)增長(zhǎng)到了現(xiàn)在的億級(jí)，這中間倉(cāng)儲(chǔ)系統(tǒng)進(jìn)行了垂直拆分，將基礎(chǔ)資料、庫(kù)存、入庫(kù)、出庫(kù)、在庫(kù)等拆分為獨(dú)立系統(tǒng)獨(dú)立部署（如圖 3） 。垂直拆分之后倉(cāng)儲(chǔ)系統(tǒng)一分為多，系統(tǒng)的容量也就成倍上升。

圖 3 倉(cāng)儲(chǔ)系統(tǒng)數(shù)據(jù)庫(kù)垂直拆分
除了倉(cāng)儲(chǔ)系統(tǒng)，其他很多系統(tǒng)（包括配送系統(tǒng)）都經(jīng)歷了垂直拆分的過(guò)程，垂直拆分不但可以很好的解耦系統(tǒng)，還能成倍提升系統(tǒng)容量。
京東的配送系統(tǒng)流量比倉(cāng)儲(chǔ)系統(tǒng)還要大，垂直拆分之后的系統(tǒng)容量不足以支撐大促期間的單量沖擊，于是在垂直拆分的基礎(chǔ)上又做了水平拆分，水平拆分除了常用的分庫(kù)分表之外，還有部分復(fù)雜業(yè)務(wù)表的模型水平拆分，比如運(yùn)單表，拆分成基礎(chǔ)數(shù)據(jù)、擴(kuò)展數(shù)據(jù)和狀態(tài)管理三個(gè)表，有的表也會(huì)按讀寫(xiě)比例進(jìn)行拆分，比如將讀多寫(xiě)少的列放一張表，讀少寫(xiě)多的列放另一張表。圖 4 是配送系統(tǒng)進(jìn)行水平拆分的一個(gè)示意圖。水平拆分之后，目前系統(tǒng)可以輕松應(yīng)對(duì)大促期間的億級(jí)單量，流量還遠(yuǎn)遠(yuǎn)未到系統(tǒng)的容量上限。
　　
圖 4 配送系統(tǒng)數(shù)據(jù)庫(kù)水平拆分
　　分離技術(shù)
分離技術(shù)也是我們每次大促備戰(zhàn)中的常用方法，主要包括讀 / 寫(xiě)分離，生產(chǎn) / 監(jiān)控分離和在線(xiàn) / 離線(xiàn)分離。
我們大部分系統(tǒng)讀寫(xiě)比例大約 10:1，對(duì)于關(guān)系型數(shù)據(jù)庫(kù)來(lái)說(shuō)，主要消耗來(lái)源于查詢(xún)，尤其是復(fù)雜查詢(xún)，所以為了提升數(shù)據(jù)庫(kù)端的總體容量，必須盡可能的將查詢(xún) SQL 分離到從庫(kù)上，主庫(kù)只提供寫(xiě)服務(wù)和一些必要的讀服務(wù)，圖 5 中 B 為備份庫(kù)，R 為從庫(kù)，所有從庫(kù)均可提供讀服務(wù)，一個(gè)主庫(kù)下可能會(huì)掛多個(gè)從庫(kù)，多個(gè)從庫(kù)根據(jù)業(yè)務(wù)場(chǎng)景需求可以做成負(fù)載均衡，也可以按業(yè)務(wù)優(yōu)先級(jí)進(jìn)行隔離并支持靈活切換。這樣主庫(kù)就只負(fù)責(zé)生產(chǎn)，避免了那些比較消耗性能的復(fù)雜查詢(xún)影響到生產(chǎn)，同時(shí)系統(tǒng)的總體容量也會(huì)得到大大提升。
生產(chǎn) / 監(jiān)控分離指的是生產(chǎn)報(bào)表和監(jiān)控報(bào)表必須分離開(kāi)來(lái)，所謂生產(chǎn)報(bào)表就是業(yè)務(wù)生產(chǎn)過(guò)程中強(qiáng)依賴(lài)的報(bào)表，比如倉(cāng)儲(chǔ)系統(tǒng)中的積壓類(lèi)報(bào)表（揀貨、復(fù)核、打包等各環(huán)節(jié)積壓數(shù)量），配送系統(tǒng)中的分揀差異報(bào)表、配送差異報(bào)表等等。
這兩類(lèi)報(bào)表業(yè)務(wù)優(yōu)先級(jí)不一樣，生產(chǎn)報(bào)表是要優(yōu)先保障的，所以在系統(tǒng)中需要將這兩類(lèi)報(bào)表進(jìn)行隔離，避免監(jiān)控類(lèi)報(bào)表影響到生產(chǎn)類(lèi)報(bào)表。監(jiān)控報(bào)表是一個(gè)獨(dú)立系統(tǒng)，數(shù)據(jù)來(lái)源有兩種路徑，一種是從生產(chǎn)庫(kù)通過(guò) binlog 復(fù)制過(guò)來(lái)（我們用的是自研的 Decomb 總線(xiàn)），另一種是從生產(chǎn)庫(kù)通過(guò)消息方式先進(jìn)入 kafka，再?gòu)?kafka 消費(fèi)到監(jiān)控系統(tǒng)。因?yàn)楸O(jiān)控報(bào)表業(yè)務(wù)場(chǎng)景的多樣性和復(fù)雜性，監(jiān)控系統(tǒng)的數(shù)據(jù)庫(kù)會(huì)采用多種技術(shù)，比如 MySQL、ElasticSearch、HBase、Cassandra 等等。
在線(xiàn) / 離線(xiàn)分離指的是在線(xiàn)報(bào)表和離線(xiàn)報(bào)表分離，在線(xiàn)報(bào)表是實(shí)時(shí)或準(zhǔn)實(shí)時(shí)報(bào)表，查看的是 24 小時(shí)之內(nèi)的業(yè)務(wù)數(shù)據(jù)，離線(xiàn)報(bào)表多為分析類(lèi)報(bào)表，查看的是 24 小時(shí)之前的業(yè)務(wù)數(shù)據(jù)。因?yàn)槎叩臉I(yè)務(wù)優(yōu)先級(jí)和技術(shù)方案都不盡相同，所以必須要進(jìn)行分離，避免相互影響。

圖 5 分離技術(shù)
　　DB+ 技術(shù)
經(jīng)歷過(guò)多次大促備戰(zhàn)之后，給我們最大的感觸就是業(yè)務(wù)規(guī)模的增長(zhǎng)速度總是快于我們系統(tǒng)的迭代速度，業(yè)務(wù)規(guī)?？偸窃隍?qū)動(dòng)著系統(tǒng)的迭代升級(jí)。面對(duì)億級(jí)單量，單純的引入前面提到的技術(shù)已經(jīng)無(wú)法讓系統(tǒng)容量發(fā)生質(zhì)的變化，系統(tǒng)容量容易受制于數(shù)據(jù)庫(kù)，所以，除了通過(guò)分庫(kù)分表來(lái)實(shí)現(xiàn)數(shù)據(jù)庫(kù)寫(xiě)的分布式，還需要引入一些 NoSQL 技術(shù)，所謂的 DB+，也就是 DB+NoSQL+ 分布式，主要包括如下幾個(gè)方面的改進(jìn)：
1. 
引入 KV 引擎，將一些數(shù)據(jù)從關(guān)系型數(shù)據(jù)庫(kù)（MySQL）遷移到 KV 引擎中來(lái)存儲(chǔ)和處理，這樣不僅可以大大降低關(guān)系型數(shù)據(jù)庫(kù)（MySQL）的負(fù)擔(dān)，還能提升數(shù)據(jù)的讀寫(xiě)性能。京東的物流系統(tǒng)中，引入的 KV 引擎主要包括 Redis、HBase、ElasticSearch 和 Cassandra，Redis 用于緩存相對(duì)靜態(tài)的熱點(diǎn)數(shù)據(jù)，HBase 是存儲(chǔ)，主要存儲(chǔ)海量的業(yè)務(wù)數(shù)據(jù)和歷史數(shù)據(jù)，ElasticSearch 主要存儲(chǔ)查詢(xún)條件相對(duì)復(fù)雜的數(shù)據(jù)，Cassandra 主要存儲(chǔ)一些日志、流水類(lèi)數(shù)據(jù)。
2. 
3. 
引入數(shù)據(jù)庫(kù)分庫(kù)分表中間件，實(shí)現(xiàn)數(shù)據(jù)庫(kù)寫(xiě)的分布式，做到數(shù)據(jù)庫(kù)讀寫(xiě)的水平可擴(kuò)展，真正實(shí)現(xiàn)從 Scale up 到 Scale out 的轉(zhuǎn)變。
4. 
5. 
追求 BASE 模型，容忍分區(qū)失敗，弱化事務(wù)，大事務(wù)化小事務(wù)，甚至是無(wú)事務(wù)，舍強(qiáng)一致性取最終一致性。
6. 
圖 6 能簡(jiǎn)單說(shuō)明 DB+ 的基本思路，系統(tǒng)的存儲(chǔ)分兩部分，一部分是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)（MySQL），用來(lái)存儲(chǔ)結(jié)構(gòu)化，強(qiáng)事務(wù)數(shù)據(jù)，數(shù)據(jù)庫(kù)做了 Sharding，讀寫(xiě)均為分布式，支持彈性擴(kuò)展。另一個(gè)是 KV 引擎，KV 引擎主要包括 Redis、HBase、ElasticSearch 和 Cassandra，Redis 主要用來(lái)做熱點(diǎn)緩存，HBase 用來(lái)存儲(chǔ)數(shù)據(jù)量級(jí)大而且 rowkey 又比較固定的數(shù)據(jù)，ElasticSearch 用來(lái)存儲(chǔ)查詢(xún)條件比較復(fù)雜的報(bào)表、查詢(xún)類(lèi)數(shù)據(jù)，Cassandra 主要用來(lái)存儲(chǔ)日志、流水類(lèi)數(shù)據(jù)，這類(lèi)數(shù)據(jù)量級(jí)大，讀寫(xiě)性能要求也比較高，但是大多都是按 key 查詢(xún)。

圖 6 DB+ 技術(shù)
　　思考總結(jié)
在經(jīng)歷過(guò)多次大促備戰(zhàn)之后，最大的感觸是每次大促的業(yè)務(wù)規(guī)?？偸窃隍?qū)動(dòng)著系統(tǒng)的技術(shù)不斷的升級(jí)。不同的業(yè)務(wù)量級(jí)所需要使用的技術(shù)也大不一樣，前面介紹的都是每次大促備戰(zhàn)的一些技術(shù)實(shí)踐。簡(jiǎn)而言之，對(duì)于 OLTP 類(lèi)系統(tǒng)來(lái)說(shuō)，面對(duì)大促的優(yōu)化可以總結(jié)為 一個(gè)中心和五個(gè)基本原則。
一個(gè)中心就是要以數(shù)據(jù)庫(kù)為中心，優(yōu)化數(shù)據(jù)庫(kù)性能為先，從數(shù)據(jù)庫(kù)端出發(fā)來(lái)提升系統(tǒng)容量。五個(gè)基本原則就是大系統(tǒng)小做原則、大事務(wù)化小原則、分離原則、分布式原則和數(shù)據(jù)庫(kù)弱依賴(lài)原則。下面分別介紹下：
· 
大系統(tǒng)小做講的就是合理的垂直拆分，將一個(gè)業(yè)務(wù)系統(tǒng)按照合理的領(lǐng)域模型拆分成多個(gè)可以獨(dú)立部署的子系統(tǒng)，一方面解耦，一方面提升系統(tǒng)的容量和可擴(kuò)展能力。
· 
· 
大事務(wù)化小指的是在業(yè)務(wù)允許的前提下盡可能將大事務(wù)拆成小事務(wù)，大事務(wù)會(huì)嚴(yán)重影響數(shù)據(jù)庫(kù)的性能而且容易造成死鎖；
· 
· 
分離原則就是要根據(jù)業(yè)務(wù)的不通場(chǎng)景和要求和數(shù)據(jù)的冷熱程度等進(jìn)行數(shù)據(jù)的分離，避免不同優(yōu)先級(jí)的業(yè)務(wù)相互影響；
· 
· 
分布式原則主要說(shuō)的是要將數(shù)據(jù)庫(kù)的寫(xiě)進(jìn)行分布式，并且真正做到寫(xiě)庫(kù)可動(dòng)態(tài)擴(kuò)展；
· 
· 
數(shù)據(jù)庫(kù)弱依賴(lài)原則簡(jiǎn)單說(shuō)就是要盡可能減少對(duì)關(guān)系型數(shù)據(jù)庫(kù)的依賴(lài)，能用 NoSQL 解決的就不用關(guān)系型數(shù)據(jù)庫(kù)，能異步寫(xiě)庫(kù)的就不同步寫(xiě)，能最終一致性的就不追求強(qiáng)一致性等等。
· 
現(xiàn)階段正處于電商高速發(fā)展的黃金時(shí)期，業(yè)務(wù)規(guī)模還將持續(xù)保持快速增長(zhǎng)，任何物流企業(yè)都必須要一套完善的物流系統(tǒng)及體系才能更高效的運(yùn)作
 
    為助力企業(yè)物流信息化發(fā)展，好伙伴科技精心打造好伙伴物流管理系統(tǒng)有貨運(yùn)管理、財(cái)務(wù)管理、公司管理、增值服務(wù)、系統(tǒng)設(shè)置五大板塊。即涵蓋開(kāi)具、打印貨運(yùn)單、收發(fā)貨管理、貨運(yùn)單及發(fā)貨批次管理、貨運(yùn)查詢(xún)、倉(cāng)儲(chǔ)管理、回單管理、人力資源管理等基本功能，還包括網(wǎng)上開(kāi)單、預(yù)約開(kāi)單、同城中轉(zhuǎn)公司的自動(dòng)篩選、業(yè)務(wù)公司之間的信息交互、異常處理、財(cái)務(wù)管理、BOSS短信、業(yè)務(wù)狀況異地監(jiān)控等特色功能。
　

                                           ------聯(lián)系我們-------

                                                              客服電話(huà)：4008-880-826
                                                              新浪微博：好伙伴物流軟
                                                              微信公眾號(hào)：HHB_56Soft