《京東618：一個中心五個原則，談?wù)勎锪飨到y(tǒng)的大促優(yōu)化實踐》要點：
本文介紹了京東618：一個中心五個原則，談?wù)勎锪飨到y(tǒng)的大促優(yōu)化實踐，希望對您有用。如果有疑問，可以聯(lián)系我們。

作者:者文明

編輯:木環(huán)、郭蕾

在京東的訂單流鏈路中,可以簡單的劃分為訂單前和訂單后兩部分,我們在京東主站上搜索商品、瀏覽商品詳情、把商品加入購物車、提交并支付訂單等環(huán)節(jié)屬于訂單前,訂單提交之后,訂單信息流就進(jìn)入訂單后的物流系統(tǒng)部分.每逢 618 大促期間,大家可能會更多的聚焦到網(wǎng)站 PV、秒殺系統(tǒng)、交易數(shù)據(jù)、廣告收入等等.其實對于京東來說,其很核心的優(yōu)勢來源于精準(zhǔn)的時效承諾、極速的送貨體驗和極致的售后服務(wù),在大促期間,其物流系統(tǒng)的表現(xiàn)對客戶體驗至關(guān)重要.

京東物流系統(tǒng)簡介

京東物流系統(tǒng)屬于訂單生產(chǎn)系統(tǒng),主要包括訂單履約、倉儲、配送、客戶服務(wù)和逆向處置中心等等.圖 1 示意了一個簡單的正向訂單生產(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)會大有不同,在很大程度上系統(tǒng) 70% 以上的性能(容量)取決于 DB 的性能(容量).因此,DB 是我們每次大促備戰(zhàn)的重點.圍繞 DB 側(cè)的備戰(zhàn)工作,主要聚焦在慢 SQL、垂直和水平拆分、讀寫分離、生產(chǎn)庫和報表庫分離、連接池優(yōu)化、參數(shù)調(diào)優(yōu)等方面.

打不死的小強(qiáng)—慢 SQL

記得剛加入京東第一次負(fù)責(zé) 618 的時候,在 618 當(dāng)天就遇到了兩次業(yè)務(wù)反饋系統(tǒng)卡頓的現(xiàn)象,緊急排查發(fā)現(xiàn) DB 中大量連接堆積,再通過查看當(dāng)前線程發(fā)現(xiàn)是一個慢 SQL(耗時 10 多秒)導(dǎo)致了連接堆積,后來把慢 SQL 緊急優(yōu)化上線后系統(tǒng)恢復(fù)正常.從那天以后,我深深感受到了慢 SQL 對我們系統(tǒng)的影響,同時也明白了一點,一個慢 SQL 對我們的系統(tǒng)總是致命的,我們不能放過任何一個慢 SQL.為了說明一個慢 SQL 對系統(tǒng)的影響,截取了兩張數(shù)據(jù)庫 CPU 使用率在一個慢 SQL 優(yōu)化前后的對比圖(如圖 2),從圖中也可以看出,前后對比是非常明顯的.

圖 2 一個慢 SQL 優(yōu)化前后 CPU 負(fù)載對比

在數(shù)據(jù)庫優(yōu)化方面,慢 SQL 優(yōu)化是最重要且效果最好的一項工作,如果要用一個比喻去形容慢 SQL,打不死的小強(qiáng)是再貼切不過的了,慢 SQL 在我們的系統(tǒng)中是滅了一茬又一茬,似乎永遠(yuǎn)消滅不完.通常情況下,慢 SQL 的出現(xiàn)可能是因為過濾條件中沒有索引、SQL 語句寫的過于復(fù)雜、表中數(shù)據(jù)量過大,做了全表掃描等等,因此我們在進(jìn)行慢 SQL 優(yōu)化時,優(yōu)先會通過添加索引解決,索引解決不了的才會去優(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)中總會不斷涌入很多新的業(yè)務(wù)需求,這樣也就不可避免的引入了新的慢 SQL,所以每次大促,慢 SQL 優(yōu)化是一大備戰(zhàn)重點.

數(shù)據(jù)庫垂直和水平拆分

跟傳統(tǒng)的企業(yè)應(yīng)用系統(tǒng)一樣,京東的倉儲系統(tǒng)也經(jīng)歷過 C/S 和 B/S 時代,V3.0 之前用的是 SQLServer 和.Net 平臺,而且整個倉儲管理是一個系統(tǒng),包括基礎(chǔ)資料、庫存、入庫、出庫、在庫等,隨著京東業(yè)務(wù)規(guī)模的迅速增長,每次大促的單量峰值也由早期的萬級增長到了現(xiàn)在的億級,這中間倉儲系統(tǒng)進(jìn)行了垂直拆分,將基礎(chǔ)資料、庫存、入庫、出庫、在庫等拆分為獨立系統(tǒng)獨立部署(如圖 3) .垂直拆分之后倉儲系統(tǒng)一分為多,系統(tǒng)的容量也就成倍上升.

圖 3 倉儲系統(tǒng)數(shù)據(jù)庫垂直拆分

除了倉儲系統(tǒng),其他很多系統(tǒng)(包括配送系統(tǒng))都經(jīng)歷了垂直拆分的過程,垂直拆分不但可以很好的解耦系統(tǒng),還能成倍提升系統(tǒng)容量.

京東的配送系統(tǒng)流量比倉儲系統(tǒng)還要大,垂直拆分之后的系統(tǒng)容量不足以支撐大促期間的單量沖擊,于是在垂直拆分的基礎(chǔ)上又做了水平拆分,水平拆分除了常用的分庫分表之外,還有部分復(fù)雜業(yè)務(wù)表的模型水平拆分,比如運(yùn)單表,拆分成基礎(chǔ)數(shù)據(jù)、擴(kuò)展數(shù)據(jù)和狀態(tài)管理三個表,有的表也會按讀寫比例進(jìn)行拆分,比如將讀多寫少的列放一張表,讀少寫多的列放另一張表.圖 4 是配送系統(tǒng)進(jìn)行水平拆分的一個示意圖.水平拆分之后,目前系統(tǒng)可以輕松應(yīng)對大促期間的億級單量,流量還遠(yuǎn)遠(yuǎn)未到系統(tǒng)的容量上限.

圖 4 配送系統(tǒng)數(shù)據(jù)庫水平拆分

分離技術(shù)

分離技術(shù)也是我們每次大促備戰(zhàn)中的常用方法,主要包括讀 / 寫分離,生產(chǎn) / 監(jiān)控分離和在線 / 離線分離.

我們大部分系統(tǒng)讀寫比例大約 10:1,對于關(guān)系型數(shù)據(jù)庫來說,主要消耗來源于查詢,尤其是復(fù)雜查詢,所以為了提升數(shù)據(jù)庫端的總體容量,必須盡可能的將查詢 SQL 分離到從庫上,主庫只提供寫服務(wù)和一些必要的讀服務(wù),圖 5 中 B 為備份庫,R 為從庫,所有從庫均可提供讀服務(wù),一個主庫下可能會掛多個從庫,多個從庫根據(jù)業(yè)務(wù)場景需求可以做成負(fù)載均衡,也可以按業(yè)務(wù)優(yōu)先級進(jìn)行隔離并支持靈活切換.這樣主庫就只負(fù)責(zé)生產(chǎn),避免了那些比較消耗性能的復(fù)雜查詢影響到生產(chǎn),同時系統(tǒng)的總體容量也會得到大大提升.

生產(chǎn) / 監(jiān)控分離指的是生產(chǎn)報表和監(jiān)控報表必須分離開來,所謂生產(chǎn)報表就是業(yè)務(wù)生產(chǎn)過程中強(qiáng)依賴的報表,比如倉儲系統(tǒng)中的積壓類報表(揀貨、復(fù)核、打包等各環(huán)節(jié)積壓數(shù)量),配送系統(tǒng)中的分揀差異報表、配送差異報表等等.

這兩類報表業(yè)務(wù)優(yōu)先級不一樣,生產(chǎn)報表是要優(yōu)先保障的,所以在系統(tǒng)中需要將這兩類報表進(jìn)行隔離,避免監(jiān)控類報表影響到生產(chǎn)類報表.監(jiān)控報表是一個獨立系統(tǒng),數(shù)據(jù)來源有兩種路徑,一種是從生產(chǎn)庫通過 binlog 復(fù)制過來(我們用的是自研的 Decomb 總線),另一種是從生產(chǎn)庫通過消息方式先進(jìn)入 kafka,再從 kafka 消費到監(jiān)控系統(tǒng).因為監(jiān)控報表業(yè)務(wù)場景的多樣性和復(fù)雜性,監(jiān)控系統(tǒng)的數(shù)據(jù)庫會采用多種技術(shù),比如 MySQL、ElasticSearch、HBase、Cassandra 等等.

在線 / 離線分離指的是在線報表和離線報表分離,在線報表是實時或準(zhǔn)實時報表,查看的是 24 小時之內(nèi)的業(yè)務(wù)數(shù)據(jù),離線報表多為分析類報表,查看的是 24 小時之前的業(yè)務(wù)數(shù)據(jù).因為二者的業(yè)務(wù)優(yōu)先級和技術(shù)方案都不盡相同,所以必須要進(jìn)行分離,避免相互影響.

圖 5 分離技術(shù)

DB+ 技術(shù)

經(jīng)歷過多次大促備戰(zhàn)之后,給我們最大的感觸就是業(yè)務(wù)規(guī)模的增長速度總是快于我們系統(tǒng)的迭代速度,業(yè)務(wù)規(guī)模總是在驅(qū)動著系統(tǒng)的迭代升級.面對億級單量,單純的引入前面提到的技術(shù)已經(jīng)無法讓系統(tǒng)容量發(fā)生質(zhì)的變化,系統(tǒng)容量容易受制于數(shù)據(jù)庫,所以,除了通過分庫分表來實現(xiàn)數(shù)據(jù)庫寫的分布式,還需要引入一些 NoSQL 技術(shù),所謂的 DB+,也就是 DB+NoSQL+ 分布式,主要包括如下幾個方面的改進(jìn)：

1. 引入 KV 引擎,將一些數(shù)據(jù)從關(guān)系型數(shù)據(jù)庫(MySQL)遷移到 KV 引擎中來存儲和處理,這樣不僅可以大大降低關(guān)系型數(shù)據(jù)庫(MySQL)的負(fù)擔(dān),還能提升數(shù)據(jù)的讀寫性能.京東的物流系統(tǒng)中,引入的 KV 引擎主要包括 Redis、HBase、ElasticSearch 和 Cassandra,Redis 用于緩存相對靜態(tài)的熱點數(shù)據(jù),HBase 是存儲,主要存儲海量的業(yè)務(wù)數(shù)據(jù)和歷史數(shù)據(jù),ElasticSearch 主要存儲查詢條件相對復(fù)雜的數(shù)據(jù),Cassandra 主要存儲一些日志、流水類數(shù)據(jù).
2. 引入數(shù)據(jù)庫分庫分表中間件,實現(xiàn)數(shù)據(jù)庫寫的分布式,做到數(shù)據(jù)庫讀寫的水平可擴(kuò)展,真正實現(xiàn)從 Scale up 到 Scale out 的轉(zhuǎn)變.
3. 追求 BASE 模型,容忍分區(qū)失敗,弱化事務(wù),大事務(wù)化小事務(wù),甚至是無事務(wù),舍強(qiáng)一致性取最終一致性.

圖 6 能簡單說明 DB+ 的基本思路,系統(tǒng)的存儲分兩部分,一部分是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(MySQL),用來存儲結(jié)構(gòu)化,強(qiáng)事務(wù)數(shù)據(jù),數(shù)據(jù)庫做了 Sharding,讀寫均為分布式,支持彈性擴(kuò)展.另一個是 KV 引擎,KV 引擎主要包括 Redis、HBase、ElasticSearch 和 Cassandra,Redis 主要用來做熱點緩存,HBase 用來存儲數(shù)據(jù)量級大而且 rowkey 又比較固定的數(shù)據(jù),ElasticSearch 用來存儲查詢條件比較復(fù)雜的報表、查詢類數(shù)據(jù),Cassandra 主要用來存儲日志、流水類數(shù)據(jù),這類數(shù)據(jù)量級大,讀寫性能要求也比較高,但是大多都是按 key 查詢.

圖 6 DB+ 技術(shù)

思考總結(jié)

在經(jīng)歷過多次大促備戰(zhàn)之后,最大的感觸是每次大促的業(yè)務(wù)規(guī)模總是在驅(qū)動著系統(tǒng)的技術(shù)不斷的升級.不同的業(yè)務(wù)量級所需要使用的技術(shù)也大不一樣,前面介紹的都是每次大促備戰(zhàn)的一些技術(shù)實踐.簡而言之,對于 OLTP 類系統(tǒng)來說,面對大促的優(yōu)化可以總結(jié)為 一個中心和五個基本原則.

一個中心就是要以數(shù)據(jù)庫為中心,優(yōu)化數(shù)據(jù)庫性能為先,從數(shù)據(jù)庫端出發(fā)來提升系統(tǒng)容量.五個基本原則就是大系統(tǒng)小做原則、大事務(wù)化小原則、分離原則、分布式原則和數(shù)據(jù)庫弱依賴原則.下面分別介紹下：

• 大系統(tǒng)小做講的就是合理的垂直拆分,將一個業(yè)務(wù)系統(tǒng)按照合理的領(lǐng)域模型拆分成多個可以獨立部署的子系統(tǒng),一方面解耦,一方面提升系統(tǒng)的容量和可擴(kuò)展能力.
• 大事務(wù)化小指的是在業(yè)務(wù)允許的前提下盡可能將大事務(wù)拆成小事務(wù),大事務(wù)會嚴(yán)重影響數(shù)據(jù)庫的性能而且容易造成死鎖；
• 分離原則就是要根據(jù)業(yè)務(wù)的不通場景和要求和數(shù)據(jù)的冷熱程度等進(jìn)行數(shù)據(jù)的分離,避免不同優(yōu)先級的業(yè)務(wù)相互影響；
• 分布式原則主要說的是要將數(shù)據(jù)庫的寫進(jìn)行分布式,并且真正做到寫庫可動態(tài)擴(kuò)展；
• 數(shù)據(jù)庫弱依賴原則簡單說就是要盡可能減少對關(guān)系型數(shù)據(jù)庫的依賴,能用 NoSQL 解決的就不用關(guān)系型數(shù)據(jù)庫,能異步寫庫的就不同步寫,能最終一致性的就不追求強(qiáng)一致性等等.

現(xiàn)階段正處于電商高速發(fā)展的黃金時期,業(yè)務(wù)規(guī)模還將持續(xù)保持快速增長,京東的物流系統(tǒng)也還將持續(xù)迭代和演進(jìn).

作者介紹

者文明,京東商城運(yùn)營研發(fā)部首席架構(gòu)師,中科院碩士,清華大學(xué)學(xué)士,15 年電子商務(wù) / 企業(yè)應(yīng)用領(lǐng)域研發(fā)、架構(gòu)經(jīng)驗,涉及電子商務(wù)、互聯(lián)網(wǎng)、大數(shù)據(jù)、人工智能等領(lǐng)域,專注電商物流系統(tǒng)架構(gòu)、實時大數(shù)據(jù)、智慧物流等解決方案.2012 年初加入京東,主要負(fù)責(zé)京東物流系統(tǒng)架構(gòu).

原文來自微信公眾號：聊聊架構(gòu)

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/2706.html