昨日京東618大促，最終以1199億的銷售額完美落幕 。也意味著接下來至少一個(gè)月的時(shí)間將有過千億的產(chǎn)品流動(dòng)，   那我們知道 在京東的訂單流鏈路中，可以簡單的劃分為訂單前和訂單后兩部分，我們在京東主站上搜索商品、瀏覽商品詳情、把商品加入購物車、提交并支付訂單等環(huán)節(jié)屬于訂單前，訂單提交之后，訂單信息流就進(jìn)入訂單后的物流系統(tǒng)部分。每逢 618 大促期間，大家可能會(huì)更多的聚焦到網(wǎng)站 PV、秒殺系統(tǒng)、交易數(shù)據(jù)、廣告收入等等。其實(shí)對(duì)于京東來說，其很核心的優(yōu)勢來源于精準(zhǔn)的時(shí)效承諾、極速的送貨體驗(yàn)和極致的售后服務(wù)，在大促期間，其物流系統(tǒng)的表現(xiàn)對(duì)客戶體驗(yàn)至關(guān)重要。
　　京東物流系統(tǒng)簡介
京東物流系統(tǒng)屬于訂單生產(chǎn)系統(tǒng)，主要包括訂單履約、倉儲(chǔ)、配送、客戶服務(wù)和逆向處置中心等等。圖 1 示意了一個(gè)簡單的正向訂單生產(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)依賴關(guān)系型數(shù)據(jù)庫
· 
以上特性也決定了物流系統(tǒng)的大促備戰(zhàn)和電商網(wǎng)站、訂單交易、秒殺、搜索推薦、廣告等系統(tǒng)會(huì)大有不同，在很大程度上系統(tǒng) 70% 以上的性能（容量）取決于 DB 的性能（容量）。因此，DB 是我們每次大促備戰(zhàn)的重點(diǎn)。圍繞 DB 側(cè)的備戰(zhàn)工作，主要聚焦在慢 SQL、垂直和水平拆分、讀寫分離、生產(chǎn)庫和報(bào)表庫分離、連接池優(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 中大量連接堆積，再通過查看當(dāng)前線程發(fā)現(xiàn)是一個(gè)慢 SQL（耗時(shí) 10 多秒）導(dǎo)致了連接堆積，后來把慢 SQL 緊急優(yōu)化上線后系統(tǒng)恢復(fù)正常。從那天以后，我深深感受到了慢 SQL 對(duì)我們系統(tǒng)的影響，同時(shí)也明白了一點(diǎn)，一個(gè)慢 SQL 對(duì)我們的系統(tǒng)總是致命的，我們不能放過任何一個(gè)慢 SQL。為了說明一個(gè)慢 SQL 對(duì)系統(tǒng)的影響，截取了兩張數(shù)據(jù)庫 CPU 使用率在一個(gè)慢 SQL 優(yōu)化前后的對(duì)比圖（如圖 2），從圖中也可以看出，前后對(duì)比是非常明顯的。

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

圖 3 倉儲(chǔ)系統(tǒng)數(shù)據(jù)庫垂直拆分
除了倉儲(chǔ)系統(tǒng)，其他很多系統(tǒng)（包括配送系統(tǒng)）都經(jīng)歷了垂直拆分的過程，垂直拆分不但可以很好的解耦系統(tǒng)，還能成倍提升系統(tǒng)容量。
京東的配送系統(tǒng)流量比倉儲(chǔ)系統(tǒng)還要大，垂直拆分之后的系統(tǒng)容量不足以支撐大促期間的單量沖擊，于是在垂直拆分的基礎(chǔ)上又做了水平拆分，水平拆分除了常用的分庫分表之外，還有部分復(fù)雜業(yè)務(wù)表的模型水平拆分，比如運(yùn)單表，拆分成基礎(chǔ)數(shù)據(jù)、擴(kuò)展數(shù)據(jù)和狀態(tài)管理三個(gè)表，有的表也會(huì)按讀寫比例進(jìn)行拆分，比如將讀多寫少的列放一張表，讀少寫多的列放另一張表。圖 4 是配送系統(tǒng)進(jìn)行水平拆分的一個(gè)示意圖。水平拆分之后，目前系統(tǒng)可以輕松應(yīng)對(duì)大促期間的億級(jí)單量，流量還遠(yuǎn)遠(yuǎn)未到系統(tǒng)的容量上限。
　　
圖 4 配送系統(tǒng)數(shù)據(jù)庫水平拆分
　　分離技術(shù)
分離技術(shù)也是我們每次大促備戰(zhàn)中的常用方法，主要包括讀 / 寫分離，生產(chǎn) / 監(jiān)控分離和在線 / 離線分離。
我們大部分系統(tǒng)讀寫比例大約 10:1，對(duì)于關(guān)系型數(shù)據(jù)庫來說，主要消耗來源于查詢，尤其是復(fù)雜查詢，所以為了提升數(shù)據(jù)庫端的總體容量，必須盡可能的將查詢 SQL 分離到從庫上，主庫只提供寫服務(wù)和一些必要的讀服務(wù)，圖 5 中 B 為備份庫，R 為從庫，所有從庫均可提供讀服務(wù)，一個(gè)主庫下可能會(huì)掛多個(gè)從庫，多個(gè)從庫根據(jù)業(yè)務(wù)場景需求可以做成負(fù)載均衡，也可以按業(yè)務(wù)優(yōu)先級(jí)進(jìn)行隔離并支持靈活切換。這樣主庫就只負(fù)責(zé)生產(chǎn)，避免了那些比較消耗性能的復(fù)雜查詢影響到生產(chǎn)，同時(shí)系統(tǒng)的總體容量也會(huì)得到大大提升。
生產(chǎn) / 監(jiān)控分離指的是生產(chǎn)報(bào)表和監(jiān)控報(bào)表必須分離開來，所謂生產(chǎn)報(bào)表就是業(yè)務(wù)生產(chǎn)過程中強(qiáng)依賴的報(bào)表，比如倉儲(chǔ)系統(tǒng)中的積壓類報(bào)表（揀貨、復(fù)核、打包等各環(huán)節(jié)積壓數(shù)量），配送系統(tǒng)中的分揀差異報(bào)表、配送差異報(bào)表等等。
這兩類報(bào)表業(yè)務(wù)優(yōu)先級(jí)不一樣，生產(chǎn)報(bào)表是要優(yōu)先保障的，所以在系統(tǒng)中需要將這兩類報(bào)表進(jìn)行隔離，避免監(jiān)控類報(bào)表影響到生產(chǎn)類報(bào)表。監(jiān)控報(bào)表是一個(gè)獨(dú)立系統(tǒng)，數(shù)據(jù)來源有兩種路徑，一種是從生產(chǎn)庫通過 binlog 復(fù)制過來（我們用的是自研的 Decomb 總線），另一種是從生產(chǎn)庫通過消息方式先進(jìn)入 kafka，再從 kafka 消費(fèi)到監(jiān)控系統(tǒng)。因?yàn)楸O(jiān)控報(bào)表業(yè)務(wù)場景的多樣性和復(fù)雜性，監(jiān)控系統(tǒng)的數(shù)據(jù)庫會(huì)采用多種技術(shù)，比如 MySQL、ElasticSearch、HBase、Cassandra 等等。
在線 / 離線分離指的是在線報(bào)表和離線報(bào)表分離，在線報(bào)表是實(shí)時(shí)或準(zhǔn)實(shí)時(shí)報(bào)表，查看的是 24 小時(shí)之內(nèi)的業(yè)務(wù)數(shù)據(jù)，離線報(bào)表多為分析類報(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)歷過多次大促備戰(zhàn)之后，給我們最大的感觸就是業(yè)務(wù)規(guī)模的增長速度總是快于我們系統(tǒng)的迭代速度，業(yè)務(wù)規(guī)?？偸窃隍?qū)動(dòng)著系統(tǒng)的迭代升級(jí)。面對(duì)億級(jí)單量，單純的引入前面提到的技術(shù)已經(jīng)無法讓系統(tǒng)容量發(fā)生質(zhì)的變化，系統(tǒng)容量容易受制于數(shù)據(jù)庫，所以，除了通過分庫分表來實(shí)現(xiàn)數(shù)據(jù)庫寫的分布式，還需要引入一些 NoSQL 技術(shù)，所謂的 DB+，也就是 DB+NoSQL+ 分布式，主要包括如下幾個(gè)方面的改進(jìn)：
1. 
引入 KV 引擎，將一些數(shù)據(jù)從關(guān)系型數(shù)據(jù)庫（MySQL）遷移到 KV 引擎中來存儲(chǔ)和處理，這樣不僅可以大大降低關(guān)系型數(shù)據(jù)庫（MySQL）的負(fù)擔(dān)，還能提升數(shù)據(jù)的讀寫性能。京東的物流系統(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ǔ)查詢條件相對(duì)復(fù)雜的數(shù)據(jù)，Cassandra 主要存儲(chǔ)一些日志、流水類數(shù)據(jù)。
2. 
3. 
引入數(shù)據(jù)庫分庫分表中間件，實(shí)現(xiàn)數(shù)據(jù)庫寫的分布式，做到數(shù)據(jù)庫讀寫的水平可擴(kuò)展，真正實(shí)現(xiàn)從 Scale up 到 Scale out 的轉(zhuǎn)變。
4. 
5. 
追求 BASE 模型，容忍分區(qū)失敗，弱化事務(wù)，大事務(wù)化小事務(wù)，甚至是無事務(wù)，舍強(qiáng)一致性取最終一致性。
6. 
圖 6 能簡單說明 DB+ 的基本思路，系統(tǒng)的存儲(chǔ)分兩部分，一部分是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫（MySQL），用來存儲(chǔ)結(jié)構(gòu)化，強(qiáng)事務(wù)數(shù)據(jù)，數(shù)據(jù)庫做了 Sharding，讀寫均為分布式，支持彈性擴(kuò)展。另一個(gè)是 KV 引擎，KV 引擎主要包括 Redis、HBase、ElasticSearch 和 Cassandra，Redis 主要用來做熱點(diǎn)緩存，HBase 用來存儲(chǔ)數(shù)據(jù)量級(jí)大而且 rowkey 又比較固定的數(shù)據(jù)，ElasticSearch 用來存儲(chǔ)查詢條件比較復(fù)雜的報(bào)表、查詢類數(shù)據(jù)，Cassandra 主要用來存儲(chǔ)日志、流水類數(shù)據(jù)，這類數(shù)據(jù)量級(jí)大，讀寫性能要求也比較高，但是大多都是按 key 查詢。

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

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

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