京東物流極速的購(gòu)物體驗(yàn)背后隱藏著怎樣的秘訣？倉(cāng)儲(chǔ)和配送時(shí)效是其中最為關(guān)鍵的一環(huán)。京東物流超強(qiáng)倉(cāng)配體系，特別是在電商行業(yè)中獨(dú)有的倉(cāng)儲(chǔ)系統(tǒng)，在其中起到了決定性的作用。

當(dāng)前京東的庫(kù)房已經(jīng)遍布全國(guó)，京東倉(cāng)儲(chǔ)管理系統(tǒng)（簡(jiǎn)稱 WMS 系統(tǒng)）是最核心的生產(chǎn)系統(tǒng)，涵蓋了從入庫(kù)，復(fù)核，打包，出庫(kù)、庫(kù)存和報(bào)表等等環(huán)節(jié)。

而作為系統(tǒng)最后端的數(shù)據(jù)庫(kù)，不僅僅承擔(dān)著存儲(chǔ)數(shù)據(jù)的任務(wù)，還是系統(tǒng)可用性的最后一道防線，如何保證倉(cāng)儲(chǔ)系統(tǒng)數(shù)據(jù)庫(kù)的高性能和高可用，直接決定了庫(kù)房生產(chǎn)是否能順暢進(jìn)行。

在本篇我們將會(huì)詳細(xì)介紹京東物流倉(cāng)儲(chǔ)系統(tǒng)的數(shù)據(jù)庫(kù)架構(gòu)，以及如何通過(guò)運(yùn)維自動(dòng)化平臺(tái)、性能優(yōu)化、故障自愈和數(shù)據(jù)結(jié)轉(zhuǎn)等步驟進(jìn)行數(shù)據(jù)庫(kù)運(yùn)維架構(gòu)的演進(jìn)。

一、數(shù)據(jù)庫(kù)架構(gòu)

倉(cāng)儲(chǔ)系統(tǒng)的數(shù)據(jù)庫(kù)架構(gòu)，主要分為兩種模式，一種是本地模式，一種是集中模式：

1.1   本地模式

本地模式是指當(dāng)前 WMS 系統(tǒng)的應(yīng)用和數(shù)據(jù)庫(kù)服務(wù)器都部署在本地庫(kù)房，目的是減少網(wǎng)絡(luò)延遲，提高作業(yè)效率。缺點(diǎn)是機(jī)房的電力和網(wǎng)絡(luò)環(huán)境略差，運(yùn)維難度較高。部署架構(gòu)圖如下：

1.2   集中模式

集中模式是指在 IDC 機(jī)房部署一套 WMS 系統(tǒng)，多個(gè)區(qū)域的園區(qū)或庫(kù)房都通過(guò)網(wǎng)絡(luò)專線訪問(wèn)，優(yōu)點(diǎn)是減少資源部署，架構(gòu)更為合理，便于運(yùn)維管理，缺點(diǎn)是部分區(qū)域網(wǎng)絡(luò)延遲較高，一旦 IDC 發(fā)生故障影響范圍較廣。部署架構(gòu)圖如下：

以上是京東倉(cāng)儲(chǔ)系統(tǒng)數(shù)據(jù)庫(kù)的兩種主要部署模式，目前主要是園區(qū)部署模式，也就是一個(gè)或多個(gè)庫(kù)房園區(qū)共用一個(gè)集群（屬于本地模式的一種）。

但是隨著業(yè)務(wù)規(guī)模的增長(zhǎng)，全國(guó)各地庫(kù)房建設(shè)日益增多，數(shù)據(jù)量也與日倍增，而對(duì)系統(tǒng)的高性能和高可用的要求卻越來(lái)越高，如何在現(xiàn)有架構(gòu)模式下，還能保障系統(tǒng)的高效穩(wěn)定運(yùn)行，故障及時(shí)恢復(fù)，都對(duì)倉(cāng)儲(chǔ)系統(tǒng)的運(yùn)維帶來(lái)極大的挑戰(zhàn)。

以下章節(jié)就詳細(xì)闡述一下我們是如何應(yīng)對(duì)這些挑戰(zhàn)的。

二、UDBA 運(yùn)維自動(dòng)化平臺(tái)

工欲善其事必先利其器，想要做好大規(guī)模系統(tǒng)的運(yùn)維管理，一定需要有自動(dòng)化的運(yùn)維平臺(tái)作為支持，同時(shí)也為了提高工作效率，減少和研發(fā)的溝通成本，庫(kù)房運(yùn)維 DBA 開(kāi)發(fā)了 UDBA 數(shù)據(jù)庫(kù)自動(dòng)化運(yùn)維平臺(tái)。該平臺(tái)除了是 DBA 日常自動(dòng)化運(yùn)維的操作平臺(tái)，還為 WMS 研發(fā)、運(yùn)營(yíng)人員提供了日常所需的技術(shù)支持和信息查詢。

UDBA 數(shù)據(jù)庫(kù)自動(dòng)化運(yùn)維平臺(tái)的主要功能模塊如下所示：

三、性能優(yōu)化

由于倉(cāng)儲(chǔ)業(yè)務(wù)邏輯復(fù)雜，并且系統(tǒng)是從早期的 SQLServer 遷移到 MySQL 的，對(duì)數(shù)據(jù)庫(kù)是強(qiáng)依賴的關(guān)系。很多業(yè)務(wù)場(chǎng)景尤其 WMS5 的報(bào)表業(yè)務(wù)會(huì)涉及很多超大表 (單表數(shù)據(jù)量超過(guò) 1 千萬(wàn)行) 的關(guān)聯(lián)，且查詢條件根據(jù)現(xiàn)場(chǎng)工作人員需求進(jìn)行組合修改，再加上部分表設(shè)計(jì)不合理以及查詢 SQL 語(yǔ)法不規(guī)范等問(wèn)題，給數(shù)據(jù)庫(kù)優(yōu)化帶來(lái)極大挑戰(zhàn)。

我們主要通過(guò)以下方式來(lái)保證數(shù)據(jù)高性能：

• 實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)庫(kù)性能，針對(duì)突發(fā)性數(shù)據(jù)庫(kù)出現(xiàn)性能問(wèn)題及時(shí)進(jìn)行故障排查和故障恢復(fù)，保證業(yè)務(wù)生產(chǎn)正常進(jìn)行。
• 每天對(duì) MySQL 慢日志進(jìn)行分析匯總后郵件抄送給相關(guān)研發(fā)同事，配合研發(fā)同事一起進(jìn)行數(shù)據(jù)庫(kù)優(yōu)化。
• 周期性對(duì)數(shù)據(jù)庫(kù)進(jìn)行巡檢，檢查數(shù)據(jù)庫(kù)運(yùn)行狀態(tài)，對(duì)壓力較大的數(shù)據(jù)庫(kù)進(jìn)行重點(diǎn)分析優(yōu)化。
• 定期對(duì)研發(fā)同事尤其新入職同事進(jìn)行 SQL 培訓(xùn)，主要針對(duì) MySQL 語(yǔ)法規(guī)范、MySQL 表設(shè)計(jì)、MySQL 查詢優(yōu)化等方面，提升研發(fā)同事的數(shù)據(jù)庫(kù)設(shè)計(jì)能力和 SQL 編寫能力，在開(kāi)發(fā)過(guò)程中提前規(guī)避常見(jiàn)的性能問(wèn)題。
• 將優(yōu)化過(guò)程中遇到的問(wèn)題歸納分析整理，幫助研發(fā)同事認(rèn)識(shí)性能問(wèn)題后的本質(zhì)原因，避免重復(fù)出現(xiàn)相同故障。
• 積極與研發(fā)同事溝通學(xué)習(xí)，深入了解業(yè)務(wù)以便更好地從業(yè)務(wù)角度對(duì)數(shù)據(jù)庫(kù)進(jìn)行優(yōu)化。

在一次服務(wù)器巡檢中，我們使用 SHOW ENGINE INNODB STATUS 查看 MySQL 服務(wù)器運(yùn)行狀態(tài)時(shí)，發(fā)現(xiàn)該數(shù)據(jù)庫(kù)存在死鎖問(wèn)題，通過(guò)多次排查，發(fā)現(xiàn)死鎖發(fā)生頻率較高，由于死鎖告警信息中的事務(wù)信息不全，我們第一時(shí)間聯(lián)系相關(guān)業(yè)務(wù)人員，了解相關(guān)業(yè)務(wù)實(shí)現(xiàn)邏輯，該業(yè)務(wù)通過(guò)程序來(lái)保證數(shù)據(jù)唯一性，采用 “先嘗試更新，后嘗試插入” 的事務(wù)順序來(lái)操作，在詳細(xì)了解業(yè)務(wù)邏輯后，通過(guò)模擬測(cè)試幫助研發(fā)同事認(rèn)識(shí)到該死鎖的核心原因，并在此基礎(chǔ)上提供改進(jìn)建議，最后將該問(wèn)題優(yōu)化方案整理成文檔抄送給更多研發(fā)同事。

四、故障自愈

倉(cāng)儲(chǔ)數(shù)據(jù)庫(kù)故障自愈系統(tǒng)主要解決兩個(gè)問(wèn)題，一個(gè)是故障的自動(dòng)切換，一個(gè)是組件的自動(dòng)恢復(fù)。系統(tǒng)功能圖如下所示：

首先硬件作為應(yīng)用系統(tǒng)的底層基礎(chǔ)設(shè)施，一旦出現(xiàn)故障將大大降低系統(tǒng)的可用性，倉(cāng)儲(chǔ)業(yè)務(wù)的數(shù)據(jù)庫(kù)集群分散在全國(guó)各地幾百個(gè)庫(kù)房，數(shù)據(jù)庫(kù)服務(wù)如何在遇到硬件等異常時(shí)快速的故障轉(zhuǎn)移，如何能降低各地網(wǎng)絡(luò)等外界環(huán)境對(duì)數(shù)據(jù)庫(kù)的性能影響？

其次系統(tǒng)在日常運(yùn)行中，因?yàn)?Bug 或者其他原因，可能會(huì)導(dǎo)致數(shù)據(jù)庫(kù)宕機(jī)，從庫(kù)復(fù)制進(jìn)程中斷，復(fù)制延遲過(guò)大等等問(wèn)題，如何快速解決這些問(wèn)題，也成為服務(wù)質(zhì)量?jī)?yōu)良的關(guān)鍵衡量標(biāo)準(zhǔn)。

基于以上這些考慮和實(shí)際需求，我們結(jié)合基礎(chǔ)信息系統(tǒng)，監(jiān)控系統(tǒng)，以及業(yè)界成熟的 MHA 高可用方案，實(shí)現(xiàn)了故障的自動(dòng)切換，當(dāng)數(shù)據(jù)庫(kù)主庫(kù)或者從庫(kù)遇到異常，能夠順利得進(jìn)行自動(dòng)切換，保障數(shù)據(jù)庫(kù)服務(wù)的持續(xù)性，當(dāng)服務(wù)器有維護(hù)需求時(shí)，提供手動(dòng)切換管理，更方便的進(jìn)行硬件維護(hù)。

同時(shí)基于 UDBA 數(shù)據(jù)庫(kù)自動(dòng)運(yùn)維平臺(tái)，對(duì)全部 MySQL 群集復(fù)制情況進(jìn)行自動(dòng)探測(cè)，自動(dòng)識(shí)別高延遲實(shí)例，并通過(guò)修改 innodb_flush_log_at_trx_commit 和 sync_binlog 的刷盤策略參數(shù)進(jìn)行快速恢復(fù)，一旦復(fù)制正常，參數(shù)將自動(dòng)調(diào)整為標(biāo)準(zhǔn)值，同時(shí)復(fù)制的 IO 線程或 SQL 線程異常停止，也可進(jìn)行自動(dòng)啟動(dòng)。

上面的處理結(jié)果都將以短信、微信和郵件等方式，通知值班同事，處理過(guò)程在 UDBA 自動(dòng)運(yùn)維平臺(tái)上同樣可以查詢，方便對(duì)故障切換的進(jìn)一步分析和統(tǒng)計(jì)。

五、數(shù)據(jù)結(jié)轉(zhuǎn)

庫(kù)房數(shù)據(jù)有時(shí)效性強(qiáng)和生命周期短的特點(diǎn)，對(duì)于數(shù)據(jù)量較大且操作頻繁的業(yè)務(wù)表，如果不進(jìn)行歷史數(shù)據(jù)歸檔，會(huì)存在嚴(yán)重性能問(wèn)題和磁盤存儲(chǔ)瓶頸，因此我們采用生產(chǎn)庫(kù)保留三月 + 報(bào)表庫(kù)保留一年的歸檔策略，對(duì)生產(chǎn)庫(kù)上超過(guò)三月” 歷史數(shù)據(jù)” 進(jìn)行刪除，對(duì)報(bào)表庫(kù)上超過(guò)一年的 “歷史數(shù)據(jù)” 結(jié)轉(zhuǎn)到 IDC 機(jī)房進(jìn)行存放。

在未引入自動(dòng)化結(jié)轉(zhuǎn)平臺(tái)前，需要 DBA 手動(dòng)在每套服務(wù)器上部署結(jié)轉(zhuǎn)程序，當(dāng)結(jié)轉(zhuǎn)條件發(fā)生變化時(shí)需要通過(guò)命令行共計(jì)批量更新每套服務(wù)器上的配置信息，DBA 無(wú)法準(zhǔn)確掌握每套服務(wù)器的結(jié)轉(zhuǎn)情況，導(dǎo)致運(yùn)維難度高且存在較高的誤操作風(fēng)險(xiǎn)。

針對(duì)庫(kù)房數(shù)據(jù)結(jié)轉(zhuǎn)的各項(xiàng)痛點(diǎn)，在對(duì)結(jié)轉(zhuǎn)流程的抽象分析基礎(chǔ)上開(kāi)發(fā)了自動(dòng)化結(jié)轉(zhuǎn)平臺(tái)，其架構(gòu)為：

自動(dòng)化優(yōu)化平臺(tái)有以下優(yōu)點(diǎn)：

• 調(diào)度作業(yè)集中管理，無(wú)需 DBA 再到每套服務(wù)器上部署代理作業(yè)，結(jié)轉(zhuǎn)平臺(tái)根據(jù)調(diào)度配置自動(dòng)將調(diào)度作業(yè)推送到庫(kù)房服務(wù)器上運(yùn)行，可以根據(jù)業(yè)務(wù)需求輕松調(diào)整調(diào)度時(shí)間和結(jié)轉(zhuǎn)條件以及結(jié)轉(zhuǎn)服務(wù)器。
• 歷史庫(kù)動(dòng)態(tài)擴(kuò)容，在京東率先引入新一代分布式關(guān)系型數(shù)據(jù)庫(kù) CockroachDB 作為歷史歸檔服務(wù)器，支持高并發(fā)的密集寫入操作，可以按需對(duì)集群進(jìn)行動(dòng)態(tài)擴(kuò)容，且能很好動(dòng)態(tài)適應(yīng)報(bào)表庫(kù)上表結(jié)構(gòu)變化。
• 數(shù)據(jù)職責(zé)分離，DBA 作為數(shù)據(jù)庫(kù)管理員而不是數(shù)據(jù)管理員，能提供數(shù)據(jù)庫(kù)服務(wù)器相關(guān)信息但無(wú)法定義數(shù)據(jù)結(jié)轉(zhuǎn)條件，自動(dòng)結(jié)轉(zhuǎn)平臺(tái)將結(jié)轉(zhuǎn)條件的管理接口在權(quán)限控制的基礎(chǔ)上提供給數(shù)據(jù)管理員，明確劃分職責(zé)權(quán)限。
• 實(shí)時(shí)掌握結(jié)轉(zhuǎn)調(diào)度信息，自動(dòng)結(jié)轉(zhuǎn)平臺(tái)提供豐富的報(bào)表和管理界面，幫助 DBA 輕松掌握當(dāng)前結(jié)轉(zhuǎn)調(diào)度信息和歷史結(jié)轉(zhuǎn)情況。

六、升級(jí)擴(kuò)容

由于各種歷史原因，目前庫(kù)房數(shù)據(jù)庫(kù)仍主要使用 2011 年發(fā)布的 MySQL 5.5 版本，隨著 MySQL 5.7 版本的逐漸穩(wěn)定，我們通過(guò)謹(jǐn)慎測(cè)試評(píng)估發(fā)現(xiàn)，MySQL 5.7 可以帶來(lái)極大的性能提升，并且其完善和改進(jìn)了很多高可用性及可維護(hù)性方面的功能，能幫助 DBA 更好的管理 MySQL 數(shù)據(jù)庫(kù)。

• 升級(jí) MySQL 5.7 可以帶來(lái)如下優(yōu)勢(shì)：
• 性能提升，在官方測(cè)試報(bào)告中，MySQL 5.7 在高并發(fā)環(huán)境下的處理能力相對(duì) MySQL 5.5 有數(shù)十倍提升。
• 高可用性，MySQL5.7 版本引入多線程復(fù)制和基于 AfterSync 模式的半同步等復(fù)制特性，能有效減少主從復(fù)制延遲，提升數(shù)據(jù)安全。
• 可維護(hù)性，MySQL5.7 版本引入 GTID 復(fù)制、Online DDL 及新版系統(tǒng)視圖和管理函數(shù)等，極大提升數(shù)據(jù)庫(kù)可維護(hù)性，降低 DBA 運(yùn)維風(fēng)險(xiǎn)和管理難度

由于庫(kù)房數(shù)據(jù)庫(kù)服務(wù)器長(zhǎng)期運(yùn)行在惡劣的機(jī)房環(huán)境中，從而產(chǎn)生 RAID 卡電源故障、服務(wù)器硬件老化、過(guò)保等引起老舊服務(wù)器性能變差的問(wèn)題，導(dǎo)致 DBA 疲于處理服務(wù)器宕機(jī)或服務(wù)器硬件引起性能瓶頸的各種事件，因此在升級(jí) MySQL 版本同時(shí)，我們也優(yōu)先對(duì)業(yè)務(wù)操作頻繁的重點(diǎn)倉(cāng)進(jìn)行升級(jí)擴(kuò)容，使用 IO 性能更好的 SSD 硬盤以及 CPU 和內(nèi)存配置更高的服務(wù)器，提升數(shù)據(jù)庫(kù)高性能和高可用性，為庫(kù)房順利且高效生產(chǎn)提供有力保障。 

為避免數(shù)據(jù)庫(kù)升級(jí)擴(kuò)容影響現(xiàn)有生產(chǎn)，我們將所有風(fēng)險(xiǎn)操作安排到半夜庫(kù)房停產(chǎn)運(yùn)行，將升級(jí)過(guò)程進(jìn)行拆分細(xì)化，對(duì)每個(gè)升級(jí)環(huán)節(jié)進(jìn)行評(píng)估論證，編寫大量升級(jí)工具和檢查腳本來(lái)提升升級(jí)效率和降低誤操作風(fēng)險(xiǎn)，并積極配合研發(fā)同事進(jìn)行測(cè)試驗(yàn)證，努力將升級(jí)擴(kuò)容帶來(lái)的負(fù)面影響降到最低，保障庫(kù)房正常生產(chǎn)。