作者 ｜ 初八，攜程資深研發(fā)經(jīng)理，專注于訂單后臺(tái)系統(tǒng)架構(gòu)優(yōu)化工作；JefferyXin，攜程高級后端開發(fā)專家，專注系統(tǒng)性能、業(yè)務(wù)架構(gòu)等領(lǐng)域。

 一、背景

隨著機(jī)票訂單業(yè)務(wù)的不斷增長，當(dāng)前訂單處理系統(tǒng)的架構(gòu)已經(jīng)不能滿足日益增長的業(yè)務(wù)需求，系統(tǒng)性能捉襟見肘，主要體現(xiàn)在以下方面：

• 數(shù)據(jù)庫CPU資源在業(yè)務(wù)高峰期經(jīng)常達(dá)到50%以上，運(yùn)行狀況亮起了黃燈
• 磁盤存儲(chǔ)空間嚴(yán)重不足，需要經(jīng)常清理磁盤數(shù)據(jù)騰挪可用空間
• 系統(tǒng)擴(kuò)容能力不足，如果需要提升處理能力只能更換配置更好的硬件資源

因此我們迫切需要調(diào)整和優(yōu)化機(jī)票訂單數(shù)據(jù)庫的架構(gòu)，從而提升訂單系統(tǒng)的處理性能。通過建立良好的水平擴(kuò)展能力，來滿足日益增長的業(yè)務(wù)需求，為后續(xù)系統(tǒng)優(yōu)化和支撐10x訂單量的增長打下良好基礎(chǔ)。

1.1 存儲(chǔ)架構(gòu)的演進(jìn)

我們選擇一個(gè)新的系統(tǒng)架構(gòu)，應(yīng)該基于當(dāng)下面臨的問題，綜合成本、風(fēng)險(xiǎn)、收益等多方面因素，選擇出的最合適的方案。機(jī)票訂單庫的架構(gòu)演進(jìn)也不例外。

我們最開始接觸機(jī)票訂單數(shù)據(jù)庫時(shí)，它是一個(gè)非常龐大的數(shù)據(jù)集合，所有的訂單業(yè)務(wù)全部都集中一個(gè)數(shù)據(jù)庫上，因此整體BR非常高。同時(shí)，我們的SQL語句也非常復(fù)雜，混雜著很多歷史遺留下來的存儲(chǔ)過程。可想而之，整個(gè)數(shù)據(jù)庫當(dāng)時(shí)的壓力巨大，維護(hù)成本居高不下。DBA每天的工作也非常忙碌，想方設(shè)法降高頻，解決慢SQL等線上問題。生產(chǎn)偶爾也會(huì)因?yàn)槟承]有review的SQL導(dǎo)致數(shù)據(jù)庫短暫的停止服務(wù)。

初期，我們采用了最常見的幾種手段進(jìn)行優(yōu)化，包括：

• 索引優(yōu)化
• 讀寫分離
• 降高頻

雖然手段比較常規(guī)，通過一段時(shí)間的治理，訂單庫的穩(wěn)定性也得到了一定的增強(qiáng)?？傮w實(shí)施成本較低，效果也是立竿見影的。

隨著時(shí)間的推移和數(shù)據(jù)的積累，新的性能瓶頸逐漸顯露。我們再次對系統(tǒng)進(jìn)行了升級，對數(shù)據(jù)庫架構(gòu)做了改進(jìn)。主要包括以下幾個(gè)方面：

垂直拆分

 訂單庫根據(jù)業(yè)務(wù)屬性拆分成了多個(gè)數(shù)據(jù)庫

基于業(yè)務(wù)對數(shù)據(jù)庫進(jìn)行垂直拆分在很大程度上提高了系統(tǒng)的可靠性和可維護(hù)性。一個(gè)上百人的團(tuán)隊(duì)，同時(shí)對一套數(shù)據(jù)庫進(jìn)行維護(hù)，對于發(fā)布變更來說是一種煎熬，同時(shí)也存在很大的風(fēng)險(xiǎn)。當(dāng)一個(gè)非核心鏈路上的發(fā)布出現(xiàn)了問題，例如某些操作導(dǎo)致了鎖表或者占用過多的系統(tǒng)資源，其他關(guān)鍵鏈路的數(shù)據(jù)庫訪問都會(huì)因此受到影響。

我們根據(jù)不同的業(yè)務(wù)場景，例如：訂單管理系統(tǒng)、出票、退票、改簽等業(yè)務(wù)，將數(shù)據(jù)庫進(jìn)行垂直拆分。使各自業(yè)務(wù)系統(tǒng)數(shù)據(jù)隔離，減少相互的影響。這些拆分的數(shù)據(jù)庫，可以根據(jù)不同性能要求，靈活調(diào)整數(shù)據(jù)庫的部署方式，來降低總體成本。

水平拆分（冷熱數(shù)據(jù)分離）

通常來說，當(dāng)航班過了起飛時(shí)間并且用戶已經(jīng)使用了當(dāng)前機(jī)票，那么我們認(rèn)為該訂單服務(wù)已經(jīng)完成，后續(xù)訂單數(shù)據(jù)發(fā)生改變的可能性很小，于是會(huì)將該數(shù)據(jù)遷移到一個(gè)具有相同結(jié)構(gòu)的冷數(shù)據(jù)庫中。該數(shù)據(jù)庫僅提供查詢功能，不提供修改功能。但是我們發(fā)現(xiàn)少數(shù)場景仍然需要對這些數(shù)據(jù)進(jìn)行修改。于是我們開發(fā)了一套數(shù)據(jù)還原功能，將處于冷數(shù)據(jù)庫中的數(shù)據(jù)，還原到熱數(shù)據(jù)庫中，然后再進(jìn)行操作。

注：我們當(dāng)時(shí)采用的數(shù)據(jù)庫和數(shù)據(jù)結(jié)構(gòu)是完全一致的，這樣做備份和還原、查詢會(huì)比較方便。其實(shí)也可以采用其他類型的數(shù)據(jù)庫，例如Mongo等。在讀取性能和使用成本等方面可能會(huì)更具優(yōu)勢。

這次升級同樣解決了不少問題，使數(shù)據(jù)庫的穩(wěn)定性得到了很大的增強(qiáng)。

1.2 基于冷熱數(shù)據(jù)分離的適用性

雖然基于冷熱數(shù)據(jù)的分庫方案，在目前來看遇到了瓶頸。但是我認(rèn)為它是一個(gè)非常值得借鑒的方案。我們現(xiàn)在仍然有大量的業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫采用這種方案對數(shù)據(jù)進(jìn)行拆分。它不僅實(shí)施簡單，同時(shí)運(yùn)維成本也相對較低。

優(yōu)勢：

• 功能簡單
• 實(shí)施成本低

局限性：

• 數(shù)據(jù)冷處理的規(guī)則應(yīng)該相對簡單，不應(yīng)該經(jīng)常發(fā)生變化
• 熱數(shù)據(jù)的膨脹需要受到限制，否則熱數(shù)據(jù)的量一旦累積過多，性能瓶頸仍然會(huì)出現(xiàn)
• 需要額外的查詢來找到訂單所處的位置（冷/熱數(shù)據(jù)庫）
• 因?yàn)槔鋽?shù)據(jù)量龐大，冷數(shù)據(jù)的查詢能力、表結(jié)構(gòu)調(diào)整能力都收到了限制，不能進(jìn)行復(fù)雜的業(yè)務(wù)查詢操作

根據(jù)我們的系統(tǒng)規(guī)劃，在當(dāng)下或者可預(yù)見的未來滿足以上提到原因中的多個(gè)，那么就得謹(jǐn)慎選擇采用此方案?；蛘咴诟姆桨傅幕A(chǔ)上進(jìn)行優(yōu)化。

正是由于我們目前的業(yè)務(wù)場景恰好命中了上面列舉的所有問題，我們才需要對這個(gè)架構(gòu)進(jìn)行進(jìn)一步調(diào)整，選擇一個(gè)更好的水平擴(kuò)展的方式，解決當(dāng)前系統(tǒng)面臨的問題。

1.3 當(dāng)時(shí)面臨的主要問題

從2019年開始，我們就開始著手研究和規(guī)劃訂單數(shù)據(jù)庫sharding項(xiàng)目。當(dāng)時(shí)主要面臨如下問題：

1.3.1 訂單的存儲(chǔ)要求

受制于當(dāng)前訂單數(shù)據(jù)庫架構(gòu)的限制以及機(jī)票業(yè)務(wù)的特殊性（通常不超過2年的處理生命周期），改造前的訂單數(shù)據(jù)庫僅能夠支持2年的訂單存儲(chǔ)。超過2年，我們會(huì)將數(shù)據(jù)進(jìn)行歸檔。用戶和員工都無法通過在線查詢的方式獲取訂單信息。

但是基于以下幾個(gè)方面原因，原本2年的存儲(chǔ)和處理周期已經(jīng)不能滿足客戶和業(yè)務(wù)的需要：

• 從客戶的角度出發(fā)，仍然有查詢歷史訂單的需求；
• 業(yè)務(wù)場景的拓展導(dǎo)致機(jī)票訂單整個(gè)服務(wù)周期變長；

原先機(jī)票使用完成（出行）一段時(shí)間后就可以視為服務(wù)結(jié)束，大部分訂單3個(gè)月后就不會(huì)發(fā)生變化，但是由于新業(yè)務(wù)的推出，熱點(diǎn)數(shù)據(jù)查詢和處理周期明顯變長。

1.3.2 系統(tǒng)架構(gòu)瓶頸

1）熱數(shù)據(jù)膨脹

熱數(shù)據(jù)原本僅千萬級別，由于業(yè)務(wù)的變化熱數(shù)據(jù)數(shù)量不斷膨脹。

2）冷數(shù)據(jù)量龐大

由于訂單存儲(chǔ)周期拉長和訂單量的增長，冷數(shù)據(jù)的數(shù)量也不斷攀升。冷數(shù)據(jù)庫查詢性能不斷下降；索引調(diào)整也變得非常困難，經(jīng)常出現(xiàn)修改失敗的場景。

3）數(shù)據(jù)庫高峰期BR達(dá)到了10w+；

4）系統(tǒng)存儲(chǔ)了20TB的數(shù)據(jù)，磁盤使用率達(dá)到80%以上，經(jīng)常觸發(fā)使用容量告警；

5）主庫的CPU使用率高峰期接近50%；

6）由于采用了讀寫分離的架構(gòu)，當(dāng)主庫的服務(wù)器的性能受到影響的時(shí)候，AG延遲變得非常高，偶爾達(dá)到分鐘級，有的時(shí)候甚至更長。

主從同步的延遲，導(dǎo)致了數(shù)據(jù)新鮮度的降低。我們之前的ORM層封裝了一個(gè)新鮮容忍度的參數(shù)。當(dāng)不能滿足新鮮度要求的時(shí)候，讀取會(huì)切換到主庫，從而進(jìn)一步加重了主庫的負(fù)擔(dān)。

因此，訂單庫的整體性能壓力非常大，如果想快速解決性能問題，只能對機(jī)器進(jìn)行擴(kuò)容。但是由于數(shù)據(jù)庫本身就是消耗資源大戶，CPU和內(nèi)存消耗非常高，只能通過進(jìn)一步提高數(shù)據(jù)庫的硬件配置來解決問題，因此整體升級的成本居高不下。另外硬件升級完成后，SQLServer的授權(quán)成本可能也會(huì)進(jìn)一步提升。

為了徹底解決以上問題，我們計(jì)劃通過優(yōu)化架構(gòu)來提升系統(tǒng)的水平擴(kuò)展能力，從而進(jìn)一步提升我們系統(tǒng)的性能和服務(wù)水平。

二、項(xiàng)目目標(biāo)和實(shí)施方案

2.1 目標(biāo)

基于上文提到的這些問題，為了確保系統(tǒng)能夠長久持續(xù)的穩(wěn)定運(yùn)行并且提升訂單系統(tǒng)的處理能力，我們計(jì)劃對數(shù)據(jù)庫的架構(gòu)進(jìn)行升級，總體實(shí)現(xiàn)以下目標(biāo)：

• 訂單的存儲(chǔ)和處理周期至少達(dá)到5年
• 提升訂單系統(tǒng)的處理能力，支撐訂單QPS10倍的規(guī)模增長
• 在提升系統(tǒng)性能的前提下，降低總體成本
• 提高系統(tǒng)的水平擴(kuò)展能力，通過簡便的操作可以快速擴(kuò)容以應(yīng)對長期的業(yè)務(wù)增長

我們希望通過1-2年的時(shí)間，實(shí)現(xiàn)對數(shù)據(jù)庫架構(gòu)升級改造以及完成SQLServer遷移到MySQL的目標(biāo)。

2.2 架構(gòu)改造

2.2.1 新舊架構(gòu)的對比

舊系統(tǒng)架構(gòu)：

架構(gòu)說明：

1）訂單數(shù)據(jù)庫

為熱數(shù)據(jù)的主庫，提供讀寫功能

2）訂單數(shù)據(jù)庫 Slave

為熱數(shù)據(jù)的從庫，在保障新鮮度的前提下提供只讀功能，采用SQLServer的AlwaysOn技術(shù)

3）訂單備份數(shù)據(jù)庫

為冷數(shù)據(jù)庫（沒有主從之分），僅提供只讀功能

4）Archive

備份機(jī)制，根據(jù)業(yè)務(wù)的需要，為了緩解主數(shù)據(jù)庫的壓力，對于符合條件的訂單（通常時(shí)起飛后+已出行）定時(shí)遷移到冷數(shù)據(jù)庫的操作

5）Restore

還原機(jī)制。在一些特殊情況下，需要對已經(jīng)備份的數(shù)據(jù)進(jìn)行修改，我們需要將數(shù)據(jù)從冷數(shù)據(jù)庫中恢復(fù)到熱數(shù)據(jù)庫然后才能進(jìn)行操作。這個(gè)操作叫做還原。

當(dāng)前存在的問題：

1）數(shù)據(jù)量變多，業(yè)務(wù)場景變得復(fù)雜后，主庫的數(shù)據(jù)量從千萬級增長到億級別，對數(shù)據(jù)庫的性能產(chǎn)生明顯影響

2）冷數(shù)據(jù)庫的歷史累計(jì)數(shù)據(jù)量也在不斷膨脹，受到本地SSD磁盤容量的限制，磁盤空間使用率達(dá)到了80%以上

3）冷數(shù)據(jù)庫的訂單數(shù)量達(dá)到了十億級，數(shù)據(jù)庫索引調(diào)整，結(jié)構(gòu)調(diào)整變得較為困難；查詢性能也受到了很大的影響

4）備份和還原邏輯需要根據(jù)業(yè)務(wù)要求不斷調(diào)整

新系統(tǒng)架構(gòu)：

架構(gòu)說明：

1）訂單數(shù)據(jù)庫Shard Cluster

新數(shù)據(jù)庫基于訂單號將數(shù)據(jù)水平拆分成64個(gè)分片，目前部署在16臺(tái)物理機(jī)上

2）訂單聚合數(shù)據(jù)庫

針對熱點(diǎn)數(shù)據(jù)，通過Binglog和有序消息隊(duì)列同步到訂單聚合數(shù)據(jù)庫，方便數(shù)據(jù)監(jiān)控，并且用于提高數(shù)據(jù)聚合查詢的性能

2.2.2 新舊架構(gòu)的差異

新舊系統(tǒng)的主要差別包括：

• 新數(shù)據(jù)庫的拆分維度從冷熱數(shù)據(jù)變更成了根據(jù)訂單號進(jìn)行水平拆分
• 數(shù)據(jù)庫從1拆2，變成了1拆64解決了磁盤存儲(chǔ)空間不足的問題
• 新數(shù)據(jù)庫的部署方式更加靈活，如果16臺(tái)物理機(jī)器資源不足時(shí)，可以通過增加服務(wù)器的數(shù)量快速提高數(shù)據(jù)庫的處理性能
• 如果64個(gè)分片的數(shù)量不足時(shí)，可以通過調(diào)整分片計(jì)算的組件功能，擴(kuò)展分片數(shù)量
• 原先的SQLServer采用的一主多從一DR的模式進(jìn)行配置。當(dāng)前系統(tǒng)每個(gè)分片物理服務(wù)器采用一主一從一DR的模式進(jìn)行配置
• 通過增加訂單聚合數(shù)據(jù)庫將部分跨分片的數(shù)據(jù)通過Binglog+有序消息的方式聚合到新的數(shù)據(jù)庫上，降低跨分片查詢帶來的性能損失

2.3 技術(shù)方案

在項(xiàng)目執(zhí)行過程中有非常多的技術(shù)細(xì)節(jié)問題需要分析和解決。我們列舉一些在項(xiàng)目過程中可能會(huì)遇到的問題：

• 如何選擇分片鍵
• 如何解決跨分片查詢性能的損失
• 如何提高開發(fā)效率，降低項(xiàng)目風(fēng)險(xiǎn)
• 全鏈路的灰度切換方案
• 分片故障的處理方案

下面我們就選擇幾個(gè)典型的例子，來說明我們在項(xiàng)目過程中遇到的問題，以及解決這些問題的方案。

2.3.1 分片鍵選擇

分庫的第一步也是最重要的一步，就是選擇分片鍵。選擇的原則是：

• 分片鍵必須是不會(huì)被更新的字段
• 各個(gè)分庫的數(shù)據(jù)量和讀寫壓力要均勻，避免熱點(diǎn)分庫
• 要盡量減少單次查詢涉及的分庫數(shù)量，降低DB壓力

分片鍵的選擇，是需要根據(jù)具體的業(yè)務(wù)場景來確定。對于訂單數(shù)據(jù)的拆分，常見的選擇是訂單ID和用戶ID兩個(gè)維度，這也是業(yè)內(nèi)最常用的兩個(gè)分片鍵。我們最終采用的是主訂單ID，主要是基于四個(gè)因素：

• 90%的請求都是基于訂單ID進(jìn)行查詢
• 主訂單ID是對應(yīng)于用戶的一個(gè)訂單，包含多個(gè)行程和貴賓休息室等附加產(chǎn)品，后臺(tái)會(huì)可能將這些拆分為多個(gè)子訂單，而子訂單之間會(huì)做Join等關(guān)聯(lián)處理，所以不能選擇子訂單維度
• 一個(gè)主訂單可能關(guān)聯(lián)多個(gè)用戶ID，比如用戶A為用戶B購買機(jī)票，用戶B又可以自己為這個(gè)訂單添加值機(jī)的功能。一個(gè)訂單ID關(guān)聯(lián)了兩個(gè)用戶ID，從而使用用戶ID用作分片鍵會(huì)導(dǎo)致訂單分布在不同的分片
• 分銷商的訂單量非常大，按用戶ID分庫會(huì)導(dǎo)致數(shù)據(jù)不均衡

我們決定采用主訂單號作為分片鍵后，進(jìn)行了下列改造，用于實(shí)現(xiàn)并且加速分片選擇的過程。

1）訂單ID索引表

【問題】：如何獲取主子訂單對應(yīng)的分片ID？

按主訂單ID分庫，首先產(chǎn)生的問題是子訂單ID如何計(jì)算分庫，需要查詢所有分庫么？我們是采用異構(gòu)索引表的方式，即創(chuàng)建一個(gè)訂單ID到主訂單ID的索引表，并且索引表是按訂單ID進(jìn)行分庫。每次查詢訂單ID查詢時(shí)，從索引表中獲取對應(yīng)的主訂單ID，計(jì)算出分庫，再進(jìn)行業(yè)務(wù)查詢，避免查詢所有分庫。

2）索引表多級緩存

【問題】：通過索引表查詢分片ID會(huì)增加了查詢的二次開銷，使查詢性能損失嚴(yán)重，如何減少數(shù)據(jù)庫二次查詢的開銷來提高查詢性能呢？

訂單ID的二次查詢，仍然會(huì)帶來數(shù)據(jù)庫的壓力明顯上升，實(shí)際上訂單ID是不會(huì)更新的，訂單ID和主訂單ID的映射關(guān)系也是不會(huì)發(fā)生變化的，完全可以把訂單ID索引表的信息緩存起來，每次查詢時(shí)從緩存中就可以獲取主訂單ID。

我們設(shè)計(jì)了多級緩存來實(shí)現(xiàn)查詢加速，所有的緩存和分庫邏輯都封裝在組件中，提供給各個(gè)客戶端使用。三級緩存結(jié)構(gòu)如下：

注：圖下方的數(shù)字代表在當(dāng)前緩存和它的所有上級緩存命中率的總和。例如Redis的99.5%代表1000個(gè)訂單有995個(gè)在本地緩存或者是Redis緩存中命中了。

客戶端本地緩存：將最熱門的訂單ID索引存放在應(yīng)用的本地內(nèi)存中，只需要一次內(nèi)存操作就能獲取主訂單號，不需要進(jìn)行額外的網(wǎng)絡(luò)IO

Redis分布式緩存：將大量的索引信息存放在Redis中，并且所有客戶端可以共用Redis緩存，命中率超過99%，并且由于訂單的映射關(guān)系是不會(huì)發(fā)生變化的，因此可以在生成訂單號的階段對緩存進(jìn)行預(yù)填充

服務(wù)端本地緩存：對DB索引表的讀取，都是在特定的應(yīng)用中實(shí)現(xiàn)，未命中緩存時(shí)客戶端是通過服務(wù)端獲取索引信息。服務(wù)端也有本地緩存，使用Guava實(shí)現(xiàn)用于減緩熱點(diǎn)key的流量尖刺避免緩存擊穿

3）本地緩存的內(nèi)存優(yōu)化

【問題】：使用本地緩存可以減少索引表查詢開銷，如果需要提高緩存命中率，就需要消耗更多的內(nèi)存使用，那么如何減少內(nèi)存占用的問題呢？

本地緩存的效率是最高的，存儲(chǔ)在本地的索引信息自然是越多越好。但本地內(nèi)存是寶貴而有限的，我們需要盡量減少單個(gè)索引占用的內(nèi)存。訂單ID都是Long類型，每個(gè)Long類型占用24個(gè)字節(jié)，通常情況下，單個(gè)索引中包含兩個(gè)Long類型， 還需要緩存內(nèi)部的多層Node節(jié)點(diǎn)，最終單個(gè)索引大約需要100個(gè)字節(jié)。

我們主要是結(jié)合業(yè)務(wù)場景來改進(jìn)內(nèi)存的使用。訂單ID是有序的，而且主子訂單ID的生成時(shí)間是非常接近的，大部分情況下，主訂單ID和子訂單ID的數(shù)值差異是很小的。對于連續(xù)的數(shù)字，數(shù)組的方式是非常節(jié)省空間的，100個(gè)Long類型占用2400個(gè)字節(jié)，而一個(gè)長度為100的long數(shù)組，則只占用824個(gè)字節(jié)。同時(shí)不直接存儲(chǔ)主訂單ID，而是只存儲(chǔ)主子訂單ID的差值，從long類型縮減為short類型，可以進(jìn)一步減少內(nèi)存占用。

最終的緩存結(jié)構(gòu)為：Map<Long, short[]>。從而使整體的內(nèi)存占用減少了大約93%的存儲(chǔ)空間。也就意味著我們可以適當(dāng)增加本地緩存的容量，同時(shí)減少內(nèi)存的消耗。

改造后：

• 【Key】表示訂單ID所在的桶，計(jì)算方式為訂單ID對 64（數(shù)組長度）取模
• 【下標(biāo)】表示訂單ID的具體位置，計(jì)算方式為訂單ID對 64（數(shù)組長度）取余數(shù)，即【KEY】和【下標(biāo)】合計(jì)起來表示訂單ID
• 【偏移量】表示主訂單ID的信息，計(jì)算方式是主訂單ID減去訂單ID

最優(yōu)情況下，存儲(chǔ)64個(gè)索引只需要一個(gè)Long類型、一個(gè)長度64的short數(shù)組和約50個(gè)字節(jié)的輔助空間，總計(jì)200個(gè)字節(jié)，平均每個(gè)索引3個(gè)字節(jié)，占用的內(nèi)存縮減到原來的100個(gè)字節(jié)的3%。

值得注意的是對于偏移量的設(shè)計(jì)仍然有一定的講究。我們需要分析主子訂單的差異區(qū)間范圍。Short的取值范圍是-32768 ～ 32767，首先將-32768定義為非法值。我們還發(fā)現(xiàn)大部分的訂單分布區(qū)間其實(shí)并沒有和這個(gè)取值范圍重疊，因此需要額外再給偏移量增加二次偏移量來優(yōu)化這個(gè)問題，實(shí)際的取值范圍是：-10000 ～ 55534，進(jìn)一步提高了short偏移量的覆蓋面。

4）主子訂單ID同余

【問題】我們對訂單ID索引做了各種改進(jìn)，使它運(yùn)行的越來越順暢，但三級緩存的引入，也使得我們的系統(tǒng)結(jié)構(gòu)變復(fù)雜，是否有辦法跳過索引表呢？

我們將未使用的訂單ID按余數(shù)分成多個(gè)桶，新增訂單在拆分訂單時(shí)，子訂單ID不再是隨機(jī)生成，而是按照主訂單ID的余數(shù)確定對應(yīng)的桶，然后只允許使用這個(gè)桶內(nèi)的訂單ID，即保證主訂單ID和子訂單ID的余數(shù)是相同的。在查詢時(shí)，子訂單ID直接取余數(shù)就能確定對應(yīng)的分庫，不需要讀取訂單索引。

再進(jìn)一步，生成主訂單ID時(shí)也不再是隨機(jī)選擇，而是基于用戶ID來分桶和選擇，做到一個(gè)UID下的訂單會(huì)盡量集中到單一分庫中。

用戶ID/主訂單ID/子訂單ID三者同余

2.3.2 跨分片查詢優(yōu)化

數(shù)據(jù)分庫后，當(dāng)查詢條件不是分片鍵時(shí)，例如使用用戶ID、更新時(shí)間等作為查詢條件，都需要對所有分片進(jìn)行查詢，在DB上的執(zhí)行次數(shù)會(huì)變?yōu)樵瓉淼?4倍，消耗的CPU資源也會(huì)急劇放大。這是所有分庫分表都會(huì)遇到的問題，也是一個(gè)分庫項(xiàng)目最具有技術(shù)挑戰(zhàn)的環(huán)節(jié)。我們針對各種場景，采取多種方式來進(jìn)行優(yōu)化。

1）UID索引表

【問題】UID是除了訂單號以外消耗資源最多的查詢之一，大約占用大約8%的數(shù)據(jù)庫使用資源。使用allShards查詢會(huì)消耗非常多的資源，嚴(yán)重降低查詢性能。那么我們?nèi)绾螌ID查詢進(jìn)行優(yōu)化，從而提升查詢效率呢？

索引表是一種常見的解決方案，需要滿足三個(gè)條件：

• 索引字段不允許更新訂單庫中用戶ID是不會(huì)被更新的
• 單個(gè)字段值關(guān)聯(lián)的數(shù)據(jù)要少，或者關(guān)聯(lián)的分庫數(shù)量少關(guān)聯(lián)的數(shù)據(jù)過多，最終還是到所有分庫中獲取數(shù)據(jù)，也就失去了索引表的意義。對于我們的業(yè)務(wù)場景來說，用戶購買機(jī)票是一種較為低頻的行為。因此，大部分用戶的訂單數(shù)量相對有限，平均每個(gè)用戶的訂單涉及的分庫數(shù)量遠(yuǎn)小于所有分庫數(shù)量。
• 查詢頻率要足夠高索引表本質(zhì)上是一個(gè)“空間換時(shí)間”的思路，只有足夠高的查詢頻率，有足夠的收益，才值的實(shí)現(xiàn)索引表。

以用戶ID作為條件的查詢，是業(yè)務(wù)中非常重要的一類查詢，也是排除訂單ID查詢后，最多的一類查詢?；跇I(yè)務(wù)和現(xiàn)有數(shù)據(jù)來分析，由于單個(gè)用戶購買機(jī)票的總數(shù)并不是很多，用戶ID分布在了有限的分庫上。我們增加一個(gè)用戶ID索引表，存儲(chǔ)用戶ID與訂單ID的映射信息，并按照用戶ID進(jìn)行分庫存儲(chǔ)。如下圖，每次用戶ID的查詢，會(huì)先查詢索引，獲取包含此用戶訂單的所有分庫列表，通過一次額外的查詢，能夠快速排除大量無關(guān)的分庫。再結(jié)合前面提及的用戶ID與訂單ID同余的策略，單個(gè)用戶ID的新增訂單會(huì)集中存儲(chǔ)在單一分庫中，隨著歷史數(shù)據(jù)的逐步歸檔，單個(gè)用戶查詢的分庫數(shù)量會(huì)越來越少。

UserIDIndex表結(jié)構(gòu)

2）鏡像庫

【問題】：并不是所有的查詢都可以像用戶ID一樣，通過建立一個(gè)二級索引表來優(yōu)化查詢問題，而且建立二級索引表的代價(jià)比較大，我們需要一個(gè)更通用的方案解決這些查詢問題。

AllShards查詢中的另一類查詢就是時(shí)間戳的查詢，尤其是大量的監(jiān)控查詢，大部分請求是可以接受一定的延遲，同時(shí)這些請求只是關(guān)注熱點(diǎn)數(shù)據(jù)，比如尚未被使用的訂單。

我們新建了一套MySQL數(shù)據(jù)庫，作為鏡像庫，將64個(gè)分庫中的熱點(diǎn)數(shù)據(jù)，集中存儲(chǔ)到單一數(shù)據(jù)庫中，相關(guān)的查詢直接在鏡像庫中執(zhí)行，避免分庫的問題。

鏡像庫的數(shù)據(jù)同步，則是通過Canal+QMQ的方式來實(shí)現(xiàn)，并定時(shí)對比數(shù)據(jù)，業(yè)務(wù)應(yīng)用上則是只讀不寫，嚴(yán)格保證雙邊數(shù)據(jù)一致性。

3）ES/MySQL對比

【問題】：鏡像庫存在多種實(shí)現(xiàn)方案，很多系統(tǒng)采用了ES作為查詢引擎，我們該如何選擇？

ES也是解決復(fù)雜查詢場景的一種常見方案，我們曾經(jīng)考慮采用ES來提升查詢性能，并且進(jìn)行了詳細(xì)的評估和測試，但最終放棄了ES方案，主要考慮到以下幾點(diǎn)原因：

• 項(xiàng)目前期對所有的查詢進(jìn)行了充分簡化和規(guī)整，目前所有的查詢使用MySQL都可以很好的運(yùn)行。
• 在已經(jīng)正確建立索引和優(yōu)化SQL語句的情況下，MySQL消耗的CPU可能遠(yuǎn)小于ES，尤其是訂單ID、時(shí)間戳等數(shù)字類型的查詢，MySQL消耗的CPU只是ES消耗的20%甚至更低。
• ES并不擅長數(shù)字查詢，而是更合適索引字段多變的場景。

因此具體采用ES還是MySQL，或者是其他數(shù)據(jù)庫來建立鏡像數(shù)據(jù)庫，最重要的一點(diǎn)還是要基于現(xiàn)有的業(yè)務(wù)場景和實(shí)際生產(chǎn)上的需求進(jìn)行綜合分析和驗(yàn)證后，找出一個(gè)最適合自己當(dāng)前情況的方案。

2.3.3 雙寫組件設(shè)計(jì)

因?yàn)榧夹g(shù)棧的問題，目前我們的ORM采用的是公司的DAL組件。這個(gè)組件本身對公司的環(huán)境支持較好，而且該組件對于Sharding數(shù)據(jù)庫也提供了良好的支持。因此我們在該項(xiàng)目上仍然使用DAL作為我們數(shù)據(jù)庫的訪問組件。

但是原生的DAL并不支持雙寫的功能，不支持讀寫的切換。針對項(xiàng)目的特性，我們需要盡可能的讓開發(fā)少感知或者不感知底層數(shù)據(jù)庫的雙寫和讀寫切換的操作。一切對于用戶來說變得更簡單、更透明。另一方面，我們打算優(yōu)化組件本身的使用接口，讓用戶使用起來更傻瓜化。

組件的升級改造需要符合以下原則：

• 對業(yè)務(wù)代碼侵入少
• 改造少，降低工作量
• 使用簡單
• 符合直覺

這些改造的意義是非常重大的，它是我們能夠高質(zhì)量上線的關(guān)鍵。于是我們對組件進(jìn)行了一些封裝和優(yōu)化。

1）業(yè)務(wù)層對象和數(shù)據(jù)庫層對象進(jìn)行隔離

為了統(tǒng)一維護(hù)方便我們將團(tuán)隊(duì)內(nèi)所有的數(shù)據(jù)庫對象（Pojo）都維護(hù)在了公共組件中。因此，在公共jar包中生成的對象通常是一個(gè)大而全的數(shù)據(jù)庫實(shí)體。這種大而全的實(shí)體信息存在以下幾個(gè)問題：

• 單表查詢時(shí)直接只用pojo返回了全量信息，影響查詢性能
• 直接在代碼中使用pojo帶來了大量無用的字段，不符合按需使用的原則
• 很難統(tǒng)計(jì)應(yīng)用對于數(shù)據(jù)庫字段的依賴的問題
• 數(shù)據(jù)庫字段和代碼直接耦合，在代碼編寫期間不能對字段的命名等問題進(jìn)行優(yōu)化

為了解決以上問題，我們中間新增了Model層，實(shí)現(xiàn)數(shù)據(jù)庫pojo和業(yè)務(wù)代碼的隔離。例如我們的航班信息表（Flight）有200多個(gè)字段，但是實(shí)際在代碼中僅需要使用航班號和起飛時(shí)間。我們可以在業(yè)務(wù)代碼中定義一個(gè)新的FlightModel，如下圖所示：

@Builder
public class Flight implements DalDto {
   /**
    * 訂單號
    */
   private Long orderId;


   /**
    * 航班號
    */
   [DalField=”flight”]
   private String flightNo;
}

擴(kuò)展組件將該對象映射到數(shù)據(jù)庫的Pojo上，并且可以改變字段的命名甚至類型從而優(yōu)化代碼的可讀性。在數(shù)據(jù)庫查詢時(shí)也進(jìn)行了優(yōu)化，僅僅查詢必要字段，減少了開銷。

2）雙寫功能

我們實(shí)現(xiàn)的雙寫方案是先寫SQLServer再寫MySQL，同時(shí)也實(shí)現(xiàn)了失敗處理相關(guān)的策略。

雙寫模式包括：

異步雙寫

這個(gè)主要是在雙寫功能實(shí)現(xiàn)的初期，我們會(huì)使用隊(duì)列+異步線程的方式將數(shù)據(jù)寫入到MySQL。采取這種方式的數(shù)據(jù)一致性是比較差的，之所以采用這種方式也是在初期我們對數(shù)據(jù)庫處于探索階段，避免MySQL數(shù)據(jù)庫故障對當(dāng)前系統(tǒng)產(chǎn)生影響。

同步雙寫

當(dāng)SQLServer寫入成功后，在相同的線程中對MySQL進(jìn)行寫入。這種模式相對來說數(shù)據(jù)一致性會(huì)比較好，但是在極端情況下仍然可能存在數(shù)據(jù)不一致的情況。

如下圖所示。當(dāng)任務(wù)1更新MySQL數(shù)據(jù)庫之前，如果有別的任務(wù)搶先更新了相同的數(shù)據(jù)字段就有可能產(chǎn)生臟寫的問題。

我們可以通過以下手段減少數(shù)據(jù)不一致的問題：

• 數(shù)據(jù)表的讀寫盡可能收口
• 訪問收口以后，通過對業(yè)務(wù)系統(tǒng)增加分布式鎖等手段緩解此類問題的產(chǎn)生?
• 可以增加數(shù)據(jù)比對的工具，主動(dòng)發(fā)現(xiàn)數(shù)據(jù)的不一致并進(jìn)行修復(fù)，通過一個(gè)異步的掃描時(shí)間戳的工具來主動(dòng)進(jìn)行數(shù)據(jù)對比注和修復(fù)
• 寫入失敗需要根據(jù)當(dāng)前的模式觸發(fā)自動(dòng)補(bǔ)償?shù)牟呗?，這個(gè)可以參考下文提到的數(shù)據(jù)雙寫異常的補(bǔ)償方案

注：數(shù)據(jù)對比和補(bǔ)償需要注意熱點(diǎn)數(shù)據(jù)頻繁更新和由于讀取時(shí)間差導(dǎo)致的不一致的問題

剛才提到我們抽象了Model層的數(shù)據(jù)，在此基礎(chǔ)上，我們的雙寫改造對用戶來說非常的容易。

@DalEntity(primaryTypeName = "com.ctrip.xxx.dal.sqlserver.entity.FlightPojo",
          secondaryTypeName = "com.ctrip.xxx.dal.mysql.entity.FlightPojo")
@Builder
public class Flight implements DalDto {

我們僅需在Model對象上增加DalEntity注解實(shí)現(xiàn)數(shù)據(jù)庫Pojo的雙邊映射。除此之外，開發(fā)人員不需要對業(yè)務(wù)代碼做其他調(diào)整，即可以通過配置實(shí)現(xiàn)雙寫、數(shù)據(jù)源切換等操作。

3）雙寫異常處理模式

雙寫時(shí)，我們需要盡可能保證數(shù)據(jù)的一致性，對于MySQL數(shù)據(jù)寫入異常時(shí)，我們提供了多種異常處理模式。

• AC

異步雙寫時(shí)，如果從庫發(fā)生異常進(jìn)行數(shù)據(jù)捕獲，不拋出異常，僅輸出告警信息

• SC

同步雙寫時(shí)，如果從庫發(fā)生異常進(jìn)行數(shù)據(jù)捕獲，不拋出異常，僅輸出告警信息

• ST

同步雙寫時(shí)，如果從庫發(fā)生異常，拋出異常，中斷處理流程

4）雙讀功能

雙寫功能相對比較好理解。在灰度切換過程中，假如存在灰度控制的訂單A以SQLServer為主，訂單B以MySQL為主。但是我們查詢到結(jié)果中同時(shí)包含了訂單A和訂單B的場景。這個(gè)時(shí)候我們希望的是，同時(shí)查詢SQLServer和MySQL的數(shù)據(jù)源，并且從不同數(shù)據(jù)源中獲取相應(yīng)的訂單數(shù)據(jù)，然后進(jìn)行組合、排序、拼接。這些篩選邏輯由我們的組件來自動(dòng)完成，從而實(shí)現(xiàn)了更加精細(xì)的灰度控制。

值得注意的是allShard查詢的結(jié)果在部分情況下（例如分頁查詢）和單庫查詢的結(jié)果存在較大的差異，也需要組件的支持。

5）數(shù)據(jù)寫入異常的補(bǔ)償方案

我們需要在不同階段設(shè)計(jì)不同的補(bǔ)償方案。初期MySQL的數(shù)據(jù)并不會(huì)對外提供服務(wù)，即使數(shù)據(jù)寫入失敗，也不能影響系統(tǒng)流程的正常運(yùn)行，同時(shí)也要保證數(shù)據(jù)寫入的準(zhǔn)確性。因此，我們采用了SC的異常處理模式，并且增加了主動(dòng)和被動(dòng)的數(shù)據(jù)補(bǔ)償。

但是我們的目標(biāo)是使用MySQL的數(shù)據(jù)。因此，當(dāng)主數(shù)據(jù)源需要SQLServer切換到MySQL后，雖然數(shù)據(jù)庫寫入的順序仍然保持先寫SQLServer再寫MySQL，但是數(shù)據(jù)寫入失敗的處理模式需要發(fā)生變化。

這里先插播一個(gè)問題，就是為什么不能先寫MySQL然后同步更新SQLServer。主要考慮到以下兩個(gè)因素：

1）數(shù)據(jù)庫主鍵生成的歷史遺留原因

由于MySQL是Sharding數(shù)據(jù)庫，如果先插入該數(shù)據(jù)庫，默認(rèn)情況下會(huì)通過雪花算法生成主鍵。寫入完成后，我們將該主鍵同步給SQLServer。

但是受到公司ORM框架和歷史遺留的技術(shù)限制，SQLServer不會(huì)使用該數(shù)據(jù)，仍然采用自增的方式生成主鍵。導(dǎo)致數(shù)據(jù)嚴(yán)重不一致。

2）數(shù)據(jù)雙向同步的復(fù)雜度問題

當(dāng)我們以SQLServer作為主數(shù)據(jù)庫時(shí)，如果數(shù)據(jù)不一致需要同步給MySQL（異步存在延時(shí)）；當(dāng)以MySQL作為主數(shù)據(jù)庫時(shí)，如果發(fā)生數(shù)據(jù)不一致，需要進(jìn)行反向同步。

一來，數(shù)據(jù)補(bǔ)償程序復(fù)雜度很高。二來，如果我們?nèi)绻贛ySQL和SQLServer數(shù)據(jù)庫誰作為主庫之間切換頻繁，數(shù)據(jù)同步程序就會(huì)變得非常迷茫，到底誰該同步給誰？

那么如何提高在以MySQL為主的情況下，雙邊數(shù)據(jù)庫的一致性呢？

首先，我們得關(guān)閉自動(dòng)補(bǔ)償功能，異常處理模式需要從SC切換到ST，遇到MySQL失敗直接拋出數(shù)據(jù)庫異常，然后基于系統(tǒng)的業(yè)務(wù)場景進(jìn)行如下操作：

1）依賴業(yè)務(wù)系統(tǒng)的自動(dòng)補(bǔ)償

對于訂單處理系統(tǒng)，大部分的流程其實(shí)具備了自動(dòng)補(bǔ)償?shù)哪芰?，因此哪怕SQLServer更新成功，MySQL未成功。下次補(bǔ)償程序仍然讀取MySQL，SQLServer會(huì)被二次更新，從而達(dá)到最終一致性。

這個(gè)時(shí)候，需要考慮的SQLServer的可重入性。

2）無法自動(dòng)補(bǔ)償?shù)膱鼍埃峁┦止?shù)據(jù)補(bǔ)償?shù)墓δ?/strong>

因?yàn)榇藭r(shí)MySQL已經(jīng)作為主要數(shù)據(jù)源，如果SQLServer存在不一致的場景可以提供手工的方式將數(shù)據(jù)補(bǔ)償回SQLServer。這邊沒有實(shí)現(xiàn)自動(dòng)補(bǔ)償，因?yàn)槔碚撋现挥性跀?shù)據(jù)不一致的場景，并且發(fā)生了回切才會(huì)產(chǎn)生影響。

3）數(shù)據(jù)的比對功能仍然正常開啟，及時(shí)發(fā)現(xiàn)數(shù)據(jù)的不一致

6) 組件設(shè)計(jì)的功能和策略分離

我們整體的功能都整合在名為Dal-Extension的系統(tǒng)組件里，主要分為功能實(shí)現(xiàn)和策略兩大部分。

功能就是前面提到的例如雙寫，讀切換，異常處理模式切換等。策略就是引擎，它實(shí)現(xiàn)了功能和功能間的聯(lián)動(dòng)。例如上文提到的，如果以SQLServer作為主數(shù)據(jù)源，那么系統(tǒng)自動(dòng)采用SC的異常處理模式，并且主動(dòng)調(diào)用數(shù)據(jù)補(bǔ)償功能。如果是以MySQL作為主數(shù)據(jù)源，那么系統(tǒng)自動(dòng)切換到ST的異常處理模式。

相較于基于應(yīng)用、表維度的切換策略。我們提供了維度更豐富的切換組合策略。

• 表
• 應(yīng)用/IP地址
• 讀/寫
• 訂單區(qū)間

通過對以上維度的配置進(jìn)行靈活調(diào)整，我們即可以實(shí)現(xiàn)單表，單機(jī)器的試驗(yàn)性切換控制，也可以進(jìn)行全鏈路的灰度切換，確保一個(gè)訂單在整個(gè)訂單處理生命周期使用相同的數(shù)據(jù)源，從而避免因?yàn)閿?shù)據(jù)雙寫或者同步導(dǎo)致的數(shù)據(jù)讀取結(jié)果不一致的問題。整體的數(shù)據(jù)切換操作由配置中心統(tǒng)一托管。

2.3.4 分片故障處理

原先的數(shù)據(jù)庫如果發(fā)生了故障，會(huì)導(dǎo)致整個(gè)系統(tǒng)不可用。但是新的數(shù)據(jù)庫擴(kuò)展成64個(gè)分片后，其實(shí)相對來說故障概率提高了64倍。因此，我們需要避免部分分片故障導(dǎo)致整個(gè)系統(tǒng)失效的情況。另外增加故障轉(zhuǎn)移和隔離功能，避免故障擴(kuò)散，減少損失也是我們重點(diǎn)關(guān)注的功能。

（當(dāng)然，如果發(fā)生分片故障，首選的故障恢復(fù)方案是數(shù)據(jù)庫的主從切換）。

1）返回僅包含查詢成功分片的部分?jǐn)?shù)據(jù)

【問題】針對跨分片查詢的場景，如果一個(gè)分片故障默認(rèn)情況下會(huì)導(dǎo)致整個(gè)查詢失敗，那么如何提高查詢成功率呢？

我們調(diào)研了數(shù)據(jù)使用端，發(fā)現(xiàn)有很多場景，例如人工訂單處理的環(huán)節(jié)，是可以接受部分?jǐn)?shù)據(jù)的返回。也就是說有查詢出盡可能多符合條件的訂單，放入人工待處理列表中。我們增加了continueOnError參數(shù)來表示當(dāng)前查詢可以接受部分分片失效的場景。并且，系統(tǒng)返回了查詢結(jié)果后，如果存在分片查詢失敗的場景，系統(tǒng)會(huì)提供了錯(cuò)誤分片的信息。這樣業(yè)務(wù)上不僅能夠確保了很多業(yè)務(wù)環(huán)節(jié)處理不中斷，同時(shí)針對它提供的錯(cuò)誤分片信息可以讓我們快速感知失效的分片，以便系統(tǒng)自動(dòng)或者人工對這些分片進(jìn)行干預(yù)。

2）故障分片隔離

【問題】當(dāng)故障分片出現(xiàn)大規(guī)模錯(cuò)誤后，如果是因?yàn)轫憫?yīng)時(shí)間長會(huì)導(dǎo)致大量線程block，從而拖累整個(gè)應(yīng)用服務(wù)器。那么如何解決此類問題呢？

當(dāng)分片發(fā)生故障時(shí)，有可能我們的數(shù)據(jù)庫請求被hang住。我們allShards查詢的底層實(shí)現(xiàn)是基于共享線程池。當(dāng)部分分片的響應(yīng)慢時(shí)，會(huì)拖累整個(gè)線程池。另外單表查詢時(shí)，也可能會(huì)因?yàn)閿?shù)據(jù)庫響應(yīng)時(shí)間的問題導(dǎo)致工作線程數(shù)量上漲的問題。

我們?yōu)榇嗽黾恿朔制帘蔚膮?shù)。當(dāng)我們啟用分片臨時(shí)屏蔽功能后，底層數(shù)據(jù)庫查詢時(shí)，發(fā)現(xiàn)該分片被屏蔽直接拋出異常，讓應(yīng)用程序能夠得到快速響應(yīng)。從而避免了網(wǎng)絡(luò)和數(shù)據(jù)庫訪問時(shí)間消耗，提高了異常執(zhí)行的效率，避免問題擴(kuò)散到正常的分片的數(shù)據(jù)處理。

3）故障訂單轉(zhuǎn)移

【問題】根據(jù)之前的介紹，用戶訂單號是根據(jù)UID的哈希值進(jìn)行分配的。也就是說同一個(gè)用戶分配的分片是固定的。如果該分片故障時(shí)，用戶就無法提交訂單。那么如何避免或者減少此類問題呢？ 

如上圖所示，用戶ID_1和用戶ID_2根據(jù)哈希算法，原先會(huì)在分片1上生成訂單。但是如果發(fā)生了分片1故障時(shí)，我們的UID分片計(jì)算組件會(huì)將分片1標(biāo)記為不可用，然后通過新的Hash算法計(jì)算出新的分片。

這里需要注意的是，新hash算法的選擇。

方法1：

使用同樣的哈希算法，但是生成結(jié)果后取模的值為63（64-1），但是這個(gè)存在的問題是用戶ID_1和用戶ID_2計(jì)算出來的分片結(jié)果是一致的。假如新的分片號為2的話，如果發(fā)生分片1、分片2同時(shí)失效的情況下。那么仍然有1/64的訂單出現(xiàn)問題。

方法2：

采用新的哈希算法，盡量使訂單分布在出了分片1以外的其他分片上。那么這種方法，即使分片1、分片2同時(shí)失效。那么僅僅會(huì)影響到1/64 * 1/63的訂單。受影響的訂單量大幅降低。

三、項(xiàng)目規(guī)劃

除了以上提到的技術(shù)問題以外，我們再談?wù)勴?xiàng)目的管理和規(guī)劃問題。首先，圈定合理的項(xiàng)目范圍，劃清項(xiàng)目邊界是項(xiàng)目順利實(shí)施的重要前提。這個(gè)項(xiàng)目的范圍包括兩個(gè)重要的屬性：數(shù)據(jù)和團(tuán)隊(duì)。

數(shù)據(jù)范圍

1）劃定數(shù)據(jù)表范圍，先進(jìn)行表結(jié)構(gòu)優(yōu)化的工作

我們需要在項(xiàng)目初期明確數(shù)據(jù)表的范圍，針對一些可以下線的表或者字段，先完成合并和下線的工作，來縮小項(xiàng)目范圍。避免表結(jié)構(gòu)的變化和該項(xiàng)目耦合在一起，造成不必要的困擾。

2）相關(guān)數(shù)據(jù)表中哪些數(shù)據(jù)需要被遷移

我們在處理這個(gè)問題上，有一些反復(fù)。

方案1：僅遷移熱數(shù)據(jù)

因?yàn)橛唵螖?shù)據(jù)分為冷熱數(shù)據(jù)，所以我們最開始考慮是不是只要遷移熱數(shù)據(jù)就好了，冷數(shù)據(jù)僅保留查詢功能。

但是，這個(gè)方案有兩個(gè)很大的問題：一是存在冷數(shù)據(jù)需要被還原到熱數(shù)據(jù)的場景，增加了系統(tǒng)實(shí)現(xiàn)的復(fù)雜度。二是冷數(shù)據(jù)保留時(shí)限的問題，無法在短時(shí)間內(nèi)下線這個(gè)數(shù)據(jù)庫。

方案2：部分?jǐn)?shù)據(jù)自然消亡的表和字段不進(jìn)行遷移

針對有一些表由于業(yè)務(wù)或者系統(tǒng)改造的原因，可能后續(xù)數(shù)據(jù)不會(huì)更新了，或者在新的訂單上這些字段已經(jīng)廢棄了。大家在設(shè)計(jì)新表的時(shí)候其實(shí)往往很不喜歡把這些已經(jīng)廢棄了的信息加到新設(shè)計(jì)的表中。但是，我們需要面臨的問題是，舊數(shù)據(jù)如何兼容是一個(gè)非常現(xiàn)實(shí)的問題。

因此，當(dāng)我們開發(fā)到中間的過程中，還是將部分表和字段重新加了回來。來確保舊數(shù)據(jù)庫盡快下線以及歷史邏輯保持兼容。

方案3：保留當(dāng)前所有的表結(jié)構(gòu)和信息

我們最后采用了這個(gè)方案，哪怕這個(gè)數(shù)據(jù)表或者字段未來不會(huì)做任何修改。

團(tuán)隊(duì)范圍

確定好數(shù)據(jù)范圍后，我們需要根據(jù)這些數(shù)據(jù)，確定我們需要做的工作以及找到完成這些工作的相關(guān)團(tuán)隊(duì)并提前安排好資源。整個(gè)項(xiàng)目的資源分為核心成員和相關(guān)配合改造的團(tuán)隊(duì)。

核心成員需要做到組織分工明確，并且需要經(jīng)常一起頭腦風(fēng)暴，提出問題，解決問題，消除隱患。核心成員的另一個(gè)職責(zé)是幫助配合改造的團(tuán)隊(duì)，協(xié)調(diào)并且解決技術(shù)問題、資源問題等等。特別是涉及到的改動(dòng)點(diǎn)較多、改造難度較大的團(tuán)隊(duì)，需要提前介入，在適當(dāng)?shù)臅r(shí)候提供更多的幫助。

3.1 規(guī)劃

確定了項(xiàng)目的目標(biāo)和范圍后，我們?yōu)轫?xiàng)目設(shè)計(jì)了6個(gè)里程碑，來幫助我們更好的完成這個(gè)項(xiàng)目。

階段1：通過API對讀取進(jìn)行收口

這個(gè)階段雖然難度并不大，但是周期很長，溝通成本較高。在這個(gè)階段重點(diǎn)在于任務(wù)的協(xié)調(diào)和跟進(jìn)。DBA幫助我們研發(fā)了生產(chǎn)Trace查詢的工具，能夠準(zhǔn)實(shí)時(shí)的知道數(shù)據(jù)表的訪問情況，幫我們快速驗(yàn)收并且圈定改造范圍。

我們建立了任務(wù)的看板，為每一個(gè)任務(wù)設(shè)定了負(fù)責(zé)人以及預(yù)期解決的時(shí)間，定期對任務(wù)進(jìn)行進(jìn)行跟蹤。項(xiàng)目的負(fù)責(zé)人也作為驗(yàn)收人，確認(rèn)每個(gè)任務(wù)的完成情況。

通過一段時(shí)間的努力，數(shù)據(jù)庫的訪問收口在極少數(shù)內(nèi)部應(yīng)用當(dāng)中。實(shí)現(xiàn)了數(shù)據(jù)訪問的收口。

階段2：開發(fā)雙讀/雙寫功能來實(shí)現(xiàn)平滑的數(shù)據(jù)切換

這個(gè)階段需要將整個(gè)項(xiàng)目的技術(shù)點(diǎn)、難點(diǎn)都逐一的找到，并且給出解決方案。如何提高效率和質(zhì)量也是這個(gè)階段重點(diǎn)關(guān)注的話題，我們盡量把這些雙寫、切換的功能進(jìn)行封裝，讓業(yè)務(wù)邏輯層盡可能少感知，或者不感知這些底層邏輯。降低代碼開發(fā)量，不僅能提高效率，還能提升質(zhì)量。

總的來說，這個(gè)階段需要提升開發(fā)效率，提高開發(fā)質(zhì)量并且降低項(xiàng)目風(fēng)險(xiǎn)。

階段3：驗(yàn)證數(shù)據(jù)一致性

這個(gè)是對階段2的驗(yàn)證工作，需要注意的是在驗(yàn)證中減少噪音，提高驗(yàn)證的自動(dòng)化率，能有效的提升項(xiàng)目的開發(fā)質(zhì)量。

階段4：通過壓測，故障模擬等手段驗(yàn)證系統(tǒng)性能。在數(shù)據(jù)庫故障時(shí)，提供可靠的系統(tǒng)的災(zāi)備和故障隔離能力。

階段5：數(shù)據(jù)讀取從SQLServer切換到MySQL

這個(gè)階段可能不需要有太多的資源投入，但是風(fēng)險(xiǎn)卻是最大的。這個(gè)階段是對前面所有階段成果的驗(yàn)收。做好數(shù)據(jù)監(jiān)控、制定良好的切換方案、出現(xiàn)問題時(shí)能夠回退是這個(gè)階段順利實(shí)施的重點(diǎn)。

階段6：停止SQLServer寫入并且下線相關(guān)數(shù)據(jù)表

相比起階段5，階段6沒有后悔藥。一旦停止了SQLServer的寫入，就非常難進(jìn)行回切的操作。所以得仔細(xì)做好白名單的驗(yàn)證，并且及時(shí)響應(yīng)和解決相關(guān)問題。

3.2 原則

整個(gè)項(xiàng)目周期較長，我們需要制定好每個(gè)階段的目標(biāo)，每個(gè)任務(wù)的目標(biāo)。由于數(shù)據(jù)庫承載了非常核心的業(yè)務(wù)，因此整個(gè)階段、所有任務(wù)以及技術(shù)方案其實(shí)圍繞著一個(gè)原則展開，就是降低風(fēng)險(xiǎn)。

所以我們在設(shè)計(jì)每個(gè)技術(shù)方案的時(shí)候，盡可能考慮這點(diǎn)。例如在數(shù)據(jù)源切換的開關(guān)雖然涉及較多的服務(wù)實(shí)例，但是我們通過一個(gè)集中控制的平臺(tái)，來實(shí)現(xiàn)全鏈路的切換和灰度控制。

四、經(jīng)驗(yàn)分享

該項(xiàng)目整體的周期較長，每個(gè)階段的挑戰(zhàn)不盡相同。為了確保項(xiàng)目的上線質(zhì)量，后續(xù)在讀切換、寫切換兩個(gè)流程的灰度時(shí)間比較久。項(xiàng)目大約在2021年下半年順利完成。

實(shí)現(xiàn)了以下主要目標(biāo)和功能：

系統(tǒng)的水平擴(kuò)展能力得到大幅提升

系統(tǒng)分片數(shù)量為64，部署在16臺(tái)物理機(jī)上。后續(xù)根據(jù)業(yè)務(wù)需要機(jī)器的部署方式和分片數(shù)量可以進(jìn)行靈活調(diào)整。

數(shù)據(jù)庫資源利用率大幅下降，可靠性提升

數(shù)據(jù)庫服務(wù)器的CPU利用率從高峰期40%下降到目前的3%-5%之間。

訂單處理能力提升和存儲(chǔ)能力提升

原先區(qū)分冷熱數(shù)據(jù)，熱數(shù)據(jù)大約僅能支持3個(gè)月的訂單，按照現(xiàn)在硬件資源推算，系統(tǒng)可以處理至少5年以上的訂單。

數(shù)據(jù)訪問收口

原先近200個(gè)應(yīng)用直接訪問數(shù)據(jù)庫，給我們的改造帶來很大的不便。目前僅有限的內(nèi)部應(yīng)用允許直接訪問訂單庫。

整體成本下降

原先主從服務(wù)器的CPU為128核，內(nèi)存256G；現(xiàn)在服務(wù)器縮減為40核心的標(biāo)準(zhǔn)配置。

在項(xiàng)目過程中也積累了不少的經(jīng)驗(yàn)，例如：

項(xiàng)目的規(guī)劃要清晰，任務(wù)要明確，跟蹤要及時(shí)

整個(gè)項(xiàng)目中大約建立了數(shù)百個(gè)子任務(wù)，每一個(gè)任務(wù)需要落實(shí)負(fù)責(zé)人以及上線時(shí)間，并對上線結(jié)果進(jìn)行驗(yàn)收。才能確保整個(gè)項(xiàng)目的周期不至于拉的非常長，減少后續(xù)的項(xiàng)目返工和風(fēng)險(xiǎn)。

減少例外情況的發(fā)生

當(dāng)一個(gè)大型的項(xiàng)目存在非常多的例外情況，這些特殊情況就得特殊處理，那么到最后總會(huì)有一些沒有處理干凈的尾巴。這些問題都是項(xiàng)目的潛在隱患。

減少項(xiàng)目的依賴

這個(gè)和我們?nèi)粘ｉ_發(fā)關(guān)系也非常密切，當(dāng)一項(xiàng)任務(wù)有多個(gè)依賴方的時(shí)候，往往項(xiàng)目的進(jìn)展會(huì)大幅超出我們的預(yù)期。因此減少一些前置依賴，在不是非常確定的情況下。我們得先做好最壞的打算。

一次干好一件事

很多時(shí)候我們往往會(huì)高估自己的能力，例如在這次的改造中，我們會(huì)順便優(yōu)化一些表的結(jié)構(gòu)。于是造成了MySQL和SQLServer的數(shù)據(jù)表差異過大的問題。那么這些差異其實(shí)為后面的開發(fā)造成了不小的困擾。所有的方案，包括數(shù)據(jù)補(bǔ)償、遷移、數(shù)據(jù)源的切換等等場景都得為這些特殊差異的表單獨(dú)考慮方案，單獨(dú)實(shí)現(xiàn)邏輯。一不留神或者沒有考慮的很周全的情況下，往往會(huì)漏掉這部分的差異。導(dǎo)致項(xiàng)目返工，甚至出現(xiàn)生產(chǎn)故障。

項(xiàng)目的成功上線離不開每一個(gè)成員的努力。在實(shí)施過程中，遇到的問題比這篇文章列舉的問題多得多，很多都是一些非?，嵥榈氖虑椤Ｌ貏e是項(xiàng)目初期，我們往往是解決了一個(gè)，冒出了更多的問題。但是每次遇到問題后，團(tuán)隊(duì)的成員都積極思考，集思廣益，攻破了一個(gè)又一個(gè)的技術(shù)問題和業(yè)務(wù)問題。通過一年多時(shí)間的鍛煉，團(tuán)隊(duì)成員的項(xiàng)目能力、技術(shù)能力進(jìn)步顯著；發(fā)現(xiàn)問題的角度更敏銳，思考的角度更全面；團(tuán)隊(duì)的凝聚力也得到了明顯提升。