前言

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

當前京東的庫房已經遍佈全國，京東倉儲管理系統（簡稱WMS系統）是最核心的生產系統，涵蓋了從入庫，複核，打包，出庫、庫存和報表等等環節。

而作為系統最後端的資料庫，不僅僅承擔著儲存資料的任務，還是系統可用性的最後一道防線，如何保證倉儲系統資料庫的高效能和高可用，直接決定了庫房生產是否能順暢進行。

在本篇我們將會詳細介紹京東物流倉儲系統的資料庫架構，以及如何通過運維自動化平臺、效能優化、故障自愈和資料結轉等步驟進行資料庫運維架構的演進。

一、資料庫架構

倉儲系統的資料庫架構，主要分為兩種模式，一種是本地模式，一種是集中模式：

1.1   本地模式

本地模式是指當前WMS系統的應用和資料庫伺服器都部署在本地庫房，目的是減少網路延遲，提高作業效率。缺點是機房的電力和網路環境略差，運維難度較高。部署架構圖如下：

1.2   集中模式

集中模式是指在IDC機房部署一套WMS系統，多個區域的園區或庫房都通過網路專線訪問，優點是減少資源部署，架構更為合理，便於運維管理，缺點是部分割槽域網路延遲較高，一旦IDC發生故障影響範圍較廣。部署架構圖如下：

以上是京東倉儲系統資料庫的兩種主要部署模式，目前主要是園區部署模式，也就是一個或多個庫房園區共用一個叢集（屬於本地模式的一種）。

但是隨著業務規模的增長，全國各地庫房建設日益增多，資料量也與日倍增，而對系統的高效能和高可用的要求卻越來越高，如何在現有架構模式下，還能保障系統的高效穩定執行，故障及時恢復，都對倉儲系統的運維帶來極大的挑戰。

以下章節就詳細闡述一下我們是如何應對這些挑戰的。

二、UDBA運維自動化平臺

工欲善其事必先利其器，想要做好大規模系統的運維管理，一定需要有自動化的運維平臺作為支援，同時也為了提高工作效率，減少和研發的溝通成本，庫房運維DBA開發了UDBA資料庫自動化運維平臺。該平臺除了是DBA日常自動化運維的操作平臺，還為WMS研發、運營人員提供了日常所需的技術支援和資訊查詢。

UDBA資料庫自動化運維平臺的主要功能模組如下所示：

三、效能優化

由於倉儲業務邏輯複雜，並且系統是從早期的SQLServer遷移到MySQL的，對資料庫是強依賴的關係。很多業務場景尤其WMS5的報表業務會涉及很多超大表(單表資料量超過1千萬行)的關聯，且查詢條件根據現場工作人員需求進行組合修改，再加上部分表設計不合理以及查詢SQL語法不規範等問題，給資料庫優化帶來極大挑戰。

我們主要通過以下方式來保證資料高效能：

• 實時監控資料庫效能，針對突發性資料庫出現效能問題及時進行故障排查和故障恢復，保證業務生產正常進行。

• 每天對MySQL慢日誌進行分析彙總後郵件抄送給相關研發同事，配合研發同事一起進行資料庫優化。

• 週期性對資料庫進行巡檢，檢查資料庫執行狀態，對壓力較大的資料庫進行重點分析優化。

• 定期對研發同事尤其新入職同事進行SQL培訓，主要針對MySQL語法規範、MySQL表設計、MySQL查詢優化等方面，提升研發同事的資料庫設計能力和SQL編寫能力，在開發過程中提前規避常見的效能問題。

• 將優化過程中遇到的問題歸納分析整理，幫助研發同事認識效能問題後的本質原因，避免重複出現相同故障。

• 積極與研發同事溝通學習，深入瞭解業務以便更好地從業務角度對資料庫進行優化。

在一次伺服器巡檢中，我們使用SHOW ENGINE INNODB STATUS檢視MySQL伺服器執行狀態時，發現該資料庫存在死鎖問題，通過多次排查，發現死鎖發生頻率較高，由於死鎖告警資訊中的事務資訊不全，我們第一時間聯絡相關業務人員，瞭解相關業務實現邏輯，該業務通過程式來保證資料唯一性，採用“先嚐試更新，後嘗試插入”的事務順序來操作，在詳細瞭解業務邏輯後，通過模擬測試幫助研發同事認識到該死鎖的核心原因，並在此基礎上提供改進建議，最後將該問題優化方案整理成文件抄送給更多研發同事。

四、故障自愈

倉儲資料庫故障自愈系統主要解決兩個問題，一個是故障的自動切換，一個是元件的自動恢復。系統功能圖如下所示：

首先硬體作為應用系統的底層基礎設施，一旦出現故障將大大降低系統的可用性，倉儲業務的資料庫叢集分散在全國各地幾百個庫房，資料庫服務如何在遇到硬體等異常時快速的故障轉移，如何能降低各地網路等外界環境對資料庫的效能影響？

其次系統在日常執行中，因為Bug或者其他原因，可能會導致資料庫宕機，從庫複製程序中斷，複製延遲過大等等問題，如何快速解決這些問題，也成為服務質量優良的關鍵衡量標準。

基於以上這些考慮和實際需求，我們結合基礎資訊系統，監控系統，以及業界成熟的MHA高可用方案，實現了故障的自動切換，當資料庫主庫或者從庫遇到異常，能夠順利得進行自動切換，保障資料庫服務的持續性，當伺服器有維護需求時，提供手動切換管理，更方便的進行硬體維護。

同時基於UDBA資料庫自動運維平臺，對全部MySQL群集複製情況進行自動探測，自動識別高延遲例項，並通過修改innodb_flush_log_at_trx_commit和sync_binlog的刷盤策略引數進行快速恢復，一旦複製正常，引數將自動調整為標準值，同時複製的IO執行緒或SQL執行緒異常停止，也可進行自動啟動。

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

五、資料結轉

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

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

針對庫房資料結轉的各項痛點，在對結轉流程的抽象分析基礎上開發了自動化結轉平臺，其架構為：

自動化優化平臺有以下優點：

• 排程作業集中管理，無需DBA再到每套伺服器上部署代理作業，結轉平臺根據排程配置自動將排程作業推送到庫房伺服器上執行，可以根據業務需求輕鬆調整排程時間和結轉條件以及結轉伺服器。

• 歷史庫動態擴容，在京東率先引入新一代分散式關係型資料庫CockroachDB作為歷史歸檔伺服器，支援高併發的密集寫入操作，可以按需對叢集進行動態擴容，且能很好動態適應報表庫上表結構變化。

• 資料職責分離，DBA作為資料庫管理員而不是資料管理員，能提供資料庫伺服器相關資訊但無法定義資料結轉條件，自動結轉平臺將結轉條件的管理介面在許可權控制的基礎上提供給資料管理員，明確劃分職責許可權。

• 實時掌握結轉排程資訊，自動結轉平臺提供豐富的報表和管理介面，幫助DBA輕鬆掌握當前結轉排程資訊和歷史結轉情況。

六、升級擴容

由於各種歷史原因，目前庫房資料庫仍主要使用2011年釋出的MySQL 5.5版本，隨著MySQL 5.7版本的逐漸穩定，我們通過謹慎測試評估發現，MySQL 5.7可以帶來極大的效能提升，並且其完善和改進了很多高可用性及可維護性方面的功能，能幫助DBA更好的管理MySQL資料庫。

升級MySQL 5.7可以帶來如下優勢：

• 效能提升，在官方測試報告中，MySQL 5.7在高併發環境下的處理能力相對MySQL 5.5有數十倍提升。

• 高可用性，MySQL5.7版本引入多執行緒複製和基於AfterSync模式的半同步等複製特性，能有效減少主從複製延遲，提升資料安全。

• 可維護性，MySQL5.7版本引入GTID複製、Online DDL及新版系統檢視和管理函式等，極大提升資料庫可維護性，降低DBA運維風險和管理難度

由於庫房資料庫伺服器長期執行在惡劣的機房環境中，從而產生RAID卡電源故障、伺服器硬體老化、過保等引起老舊伺服器效能變差的問題，導致DBA疲於處理伺服器宕機或伺服器硬體引起效能瓶頸的各種事件，因此在升級MySQL版本同時，我們也優先對業務操作頻繁的重點倉進行升級擴容，使用IO效能更好的SSD硬碟以及CPU和記憶體配置更高的伺服器，提升資料庫高效能和高可用性，為庫房順利且高效生產提供有力保障。

為避免資料庫升級擴容影響現有生產，我們將所有風險操作安排到半夜庫房停產執行，將升級過程進行拆分細化，對每個升級環節進行評估論證，編寫大量升級工具和檢查指令碼來提升升級效率和降低誤操作風險，並積極配合研發同事進行測試驗證，努力將升級擴容帶來的負面影響降到最低，保障庫房正常生產。