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

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

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

在本篇我們將會詳細介紹京東物流倉儲系統(tǒng)的數(shù)據(jù)庫架構，以及如何通過運維自動化平臺、性能優(yōu)化、故障自愈和數(shù)據(jù)結轉等步驟進行數(shù)據(jù)庫運維架構的演進。

一、數(shù)據(jù)庫架構

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

1.1   本地模式

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

1.2   集中模式

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

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

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

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

二、UDBA 運維自動化平臺

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

UDBA 數(shù)據(jù)庫自動化運維平臺的主要功能模塊如下所示：

三、性能優(yōu)化

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

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

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

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

四、故障自愈

倉儲數(shù)據(jù)庫故障自愈系統(tǒng)主要解決兩個問題，一個是故障的自動切換，一個是組件的自動恢復。系統(tǒng)功能圖如下所示：

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

其次系統(tǒng)在日常運行中，因為 Bug 或者其他原因，可能會導致數(shù)據(jù)庫宕機，從庫復制進程中斷，復制延遲過大等等問題，如何快速解決這些問題，也成為服務質量優(yōu)良的關鍵衡量標準。

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

同時基于 UDBA 數(shù)據(jù)庫自動運維平臺，對全部 MySQL 群集復制情況進行自動探測，自動識別高延遲實例，并通過修改 innodb_flush_log_at_trx_commit 和 sync_binlog 的刷盤策略參數(shù)進行快速恢復，一旦復制正常，參數(shù)將自動調整為標準值，同時復制的 IO 線程或 SQL 線程異常停止，也可進行自動啟動。

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

五、數(shù)據(jù)結轉

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

在未引入自動化結轉平臺前，需要 DBA 手動在每套服務器上部署結轉程序，當結轉條件發(fā)生變化時需要通過命令行共計批量更新每套服務器上的配置信息，DBA 無法準確掌握每套服務器的結轉情況，導致運維難度高且存在較高的誤操作風險。

針對庫房數(shù)據(jù)結轉的各項痛點，在對結轉流程的抽象分析基礎上開發(fā)了自動化結轉平臺，其架構為：

自動化優(yōu)化平臺有以下優(yōu)點：

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

六、升級擴容

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

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

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

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