支持10倍訂單增長，攜程資料庫架構升級實踐

隨著機票訂單業務的不斷增長，當前訂單處理系統的架構已經不能滿足日益增長的業務需求，系統性能捉襟見肘，主要體現在以下方面：

因此我們迫切需要調整和優化機票訂單資料庫的架構，從而提升訂單系統的處理性能。通過建立良好的水平擴展能力，來滿足日益增長的業務需求，為後續系統優化和支撐10x訂單量的增長打下良好基礎。

我們選擇一個新的系統架構，應該基於當下麵臨的問題，綜合成本、風險、收益等多方面因素，選擇出的最合適的方案。機票訂單庫的架構演進也不例外。

我們最開始接觸機票訂單資料庫時，它是一個非常龐大的數據集合，所有的訂單業務全部都集中一個資料庫上，因此整體BR非常高。同時，我們的SQL語句也非常複雜，混雜著很多歷史遺留下來的存儲過程。可想而之，整個資料庫當時的壓力巨大，維護成本居高不下。DBA每天的工作也非常忙碌，想方設法降高頻，解決慢SQL等線上問題。生產偶爾也會因為某些沒有review的SQL導致資料庫短暫的停止服務。

初期，我們採用了最常見的幾種手段進行優化，包括：

雖然手段比較常規，通過一段時間的治理，訂單庫的穩定性也得到了一定的增強。總體實施成本較低，效果也是立竿見影的。

隨著時間的推移和數據的積累，新的性能瓶頸逐漸顯露。我們再次對系統進行了升級，對資料庫架構做了改進。主要包括以下幾個方面：

1）垂直拆分

訂單庫根據業務屬性拆分成了多個資料庫

基於業務對資料庫進行垂直拆分在很大程度上提高了系統的可靠性和可維護性。一個上百人的團隊，同時對一套資料庫進行維護，對於發佈變更來說是一種煎熬，同時也存在很大的風險。當一個非核心鏈路上的發佈出現了問題，例如某些操作導致了鎖表或者占用過多的系統資源，其他關鍵鏈路的資料庫訪問都會因此受到影響。

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

2）水平拆分（冷熱數據分離）

通常來說，當航班過了起飛時間並且用戶已經使用了當前機票，那麼我們認為該訂單服務已經完成，後續訂單數據發生改變的可能性很小，於是會將該數據遷移到一個具有相同結構的冷資料庫中。該資料庫僅提供查詢功能，不提供修改功能。但是我們發現少數場景仍然需要對這些數據進行修改。於是我們開發了一套數據還原功能，將處於冷資料庫中的數據，還原到熱資料庫中，然後再進行操作。

這次升級同樣解決了不少問題，使資料庫的穩定性得到了很大的增強。

雖然基於冷熱數據的分庫方案，在目前來看遇到了瓶頸。但是我認為它是一個非常值得借鑒的方案。我們現在仍然有大量的業務系統資料庫採用這種方案對數據進行拆分。它不僅實施簡單，同時運維成本也相對較低。

1）優勢

2）局限性

根據我們的系統規劃，在當下或者可預見的未來滿足以上提到原因中的多個，那麼就得謹慎選擇採用此方案。或者在改方案的基礎上進行優化。

正是由於我們目前的業務場景恰好命中了上面列舉的所有問題，我們才需要對這個架構進行進一步調整，選擇一個更好的水平擴展的方式，解決當前系統面臨的問題。

從2019年開始，我們就開始著手研究和規劃訂單資料庫sharding項目。當時主要面臨如下問題：

1）訂單的存儲要求

受制於當前訂單資料庫架構的限制以及機票業務的特殊性（通常不超過2年的處理生命周期），改造前的訂單資料庫僅能夠支持2年的訂單存儲。超過2年，我們會將數據進行歸檔。用戶和員工都無法通過線上查詢的方式獲取訂單信息。

但是基於以下幾個方面原因，原本2年的存儲和處理周期已經不能滿足客戶和業務的需要：

原先機票使用完成（出行）一段時間後就可以視為服務結束，大部分訂單3個月後就不會發生變化，但是由於新業務的推出，熱點數據查詢和處理周期明顯變長。

2）系統架構瓶頸

① 熱數據膨脹

熱數據原本僅千萬級別，由於業務的變化熱數據數量不斷膨脹。

② 冷數據量龐大

由於訂單存儲周期拉長和訂單量的增長，冷數據的數量也不斷攀升。冷資料庫查詢性能不斷下降；索引調整也變得非常困難，經常出現修改失敗的場景。

③ 資料庫高峰期BR達到了10w+

④ 系統存儲了20TB的數據，磁碟使用率達到80%以上，經常觸發使用容量告警

⑤ 主庫的CPU使用率高峰期接近50%

⑥ 由於採用了讀寫分離的架構，當主庫的伺服器的性能受到影響的時候，AG延遲變得非常高，偶爾達到分鐘級，有的時候甚至更長。

主從同步的延遲，導致了數據新鮮度的降低。我們之前的ORM層封裝了一個新鮮容忍度的參數。當不能滿足新鮮度要求的時候，讀取會切換到主庫，從而進一步加重了主庫的負擔。

因此，訂單庫的整體性能壓力非常大，如果想快速解決性能問題，只能對機器進行擴容。但是由於資料庫本身就是消耗資源大戶，CPU和記憶體消耗非常高，只能通過進一步提高資料庫的硬體配置來解決問題，因此整體升級的成本居高不下。另外硬體升級完成後，SQLServer的授權成本可能也會進一步提升。

為了徹底解決以上問題，我們計劃通過優化架構來提升系統的水平擴展能力，從而進一步提升我們系統的性能和服務水平。

基於上文提到的這些問題，為了確保系統能夠長久持續的穩定運行並且提升訂單系統的處理能力，我們計劃對資料庫的架構進行升級，總體實現以下目標：

我們希望通過1-2年的時間，實現對資料庫架構升級改造以及完成SQLServer遷移到MySQL的目標。

1）新舊架構的對比

① 舊系統架構

架構說明：

為熱數據的主庫，提供讀寫功能

為熱數據的從庫，在保障新鮮度的前提下提供只讀功能，採用SQLServer的AlwaysOn技術

為冷資料庫（沒有主從之分），僅提供只讀功能

備份機制，根據業務的需要，為了緩解主資料庫的壓力，對於符合條件的訂單（通常時起飛後+已出行）定時遷移到冷資料庫的操作

還原機制。在一些特殊情況下，需要對已經備份的數據進行修改，我們需要將數據從冷資料庫中恢復到熱資料庫然後才能進行操作。這個操作叫做還原。

當前存在的問題：

② 新系統架構

架構說明：

新資料庫基於訂單號將數據水平拆分成64個分片，目前部署在16台物理機上

針對熱點數據，通過Binglog和有序消息隊列同步到訂單聚合資料庫，方便數據監控，並且用於提高數據聚合查詢的性能

2）新舊架構的差異

新舊系統的主要差別包括：

在項目執行過程中有非常多的技術細節問題需要分析和解決。我們列舉一些在項目過程中可能會遇到的問題：

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

1）分片鍵選擇

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

分片鍵的選擇，是需要根據具體的業務場景來確定。對於訂單數據的拆分，常見的選擇是訂單ID和用戶ID兩個維度，這也是業內最常用的兩個分片鍵。我們最終採用的是主訂單ID，主要是基於四個因素：

我們決定採用主訂單號作為分片鍵後，進行了下列改造，用於實現並且加速分片選擇的過程。

① 訂單ID索引表

按主訂單ID分庫，首先產生的問題是子訂單ID如何計算分庫，需要查詢所有分庫麽？我們是採用異構索引表的方式，即創建一個訂單ID到主訂單ID的索引表，並且索引表是按訂單ID進行分庫。每次查詢訂單ID查詢時，從索引表中獲取對應的主訂單ID，計算出分庫，再進行業務查詢，避免查詢所有分庫。

② 索引表多級緩存

訂單ID的二次查詢，仍然會帶來資料庫的壓力明顯上升，實際上訂單ID是不會更新的，訂單ID和主訂單ID的映射關係也是不會發生變化的，完全可以把訂單ID索引表的信息緩存起來，每次查詢時從緩存中就可以獲取主訂單ID。

我們設計了多級緩存來實現查詢加速，所有的緩存和分庫邏輯都封裝在組件中，提供給各個客戶端使用。三級緩存結構如下：

③ 本地緩存的記憶體優化

本地緩存的效率是最高的，存儲在本地的索引信息自然是越多越好。但本地記憶體是寶貴而有限的，我們需要儘量減少單個索引占用的記憶體。訂單ID都是Long類型，每個Long類型占用24個位元組，通常情況下，單個索引中包含兩個Long類型， 還需要緩存內部的多層Node節點，最終單個索引大約需要100個位元組。

我們主要是結合業務場景來改進記憶體的使用。訂單ID是有序的，而且主子訂單ID的生成時間是非常接近的，大部分情況下，主訂單ID和子訂單ID的數值差異是很小的。對於連續的數字，數組的方式是非常節省空間的，100個Long類型占用2400個位元組，而一個長度為100的long數組，則只占用824個位元組。同時不直接存儲主訂單ID，而是只存儲主子訂單ID的差值，從long類型縮減為short類型，可以進一步減少記憶體占用。

最終的緩存結構為：Map<Long, short[]>。從而使整體的記憶體占用減少了大約93%的存儲空間。也就意味著我們可以適當增加本地緩存的容量，同時減少記憶體的消耗。

改造後：

最優情況下，存儲64個索引只需要一個Long類型、一個長度64的short數組和約50個位元組的輔助空間，總計200個位元組，平均每個索引3個位元組，占用的記憶體縮減到原來的100個位元組的3%。

值得註意的是對於偏移量的設計仍然有一定的講究。我們需要分析主子訂單的差異區間範圍。Short的取值範圍是-32768 ～ 32767，首先將-32768定義為非法值。我們還發現大部分的訂單分佈區間其實並沒有和這個取值範圍重疊，因此需要額外再給偏移量增加二次偏移量來優化這個問題，實際的取值範圍是：-10000 ～ 55534，進一步提高了short偏移量的覆蓋面。

④ 主子訂單ID同餘

我們將未使用的訂單ID按餘數分成多個桶，新增訂單在拆分訂單時，子訂單ID不再是隨機生成，而是按照主訂單ID的餘數確定對應的桶，然後只允許使用這個桶內的訂單ID，即保證主訂單ID和子訂單ID的餘數是相同的。在查詢時，子訂單ID直接取餘數就能確定對應的分庫，不需要讀取訂單索引。

再進一步，生成主訂單ID時也不再是隨機選擇，而是基於用戶ID來分桶和選擇，做到一個UID下的訂單會儘量集中到單一分庫中。

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

2）跨分片查詢優化

數據分庫後，當查詢條件不是分片鍵時，例如使用用戶ID、更新時間等作為查詢條件，都需要對所有分片進行查詢，在DB上的執行次數會變為原來的64倍，消耗的CPU資源也會急劇放大。這是所有分庫分表都會遇到的問題，也是一個分庫項目最具有技術挑戰的環節。我們針對各種場景，採取多種方式來進行優化。

① UID索引表

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

關聯的數據過多，最終還是到所有分庫中獲取數據，也就失去了索引表的意義。對於我們的業務場景來說，用戶購買機票是一種較為低頻的行為。因此，大部分用戶的訂單數量相對有限，平均每個用戶的訂單涉及的分庫數量遠小於所有分庫數量。

索引表本質上是一個“空間換時間”的思路，只有足夠高的查詢頻率，有足夠的收益，才值的實現索引表。

以用戶ID作為條件的查詢，是業務中非常重要的一類查詢，也是排除訂單ID查詢後，最多的一類查詢。基於業務和現有數據來分析，由於單個用戶購買機票的總數並不是很多，用戶ID分佈在了有限的分庫上。我們增加一個用戶ID索引表，存儲用戶ID與訂單ID的映射信息，並按照用戶ID進行分庫存儲。如下圖，每次用戶ID的查詢，會先查詢索引，獲取包含此用戶訂單的所有分庫列表，通過一次額外的查詢，能夠快速排除大量無關的分庫。再結合前面提及的用戶ID與訂單ID同餘的策略，單個用戶ID的新增訂單會集中存儲在單一分庫中，隨著歷史數據的逐步歸檔，單個用戶查詢的分庫數量會越來越少。

UserIDIndex表結構

② 鏡像庫

並不是所有的查詢都可以像用戶ID一樣，通過建立一個二級索引表來優化查詢問題，而且建立二級索引表的代價比較大，我們需要一個更通用的方案解決這些查詢問題。

AllShards查詢中的另一類查詢就是時間戳的查詢，尤其是大量的監控查詢，大部分請求是可以接受一定的延遲，同時這些請求只是關註熱點數據，比如尚未被使用的訂單。

我們新建了一套MySQL資料庫，作為鏡像庫，將64個分庫中的熱點數據，集中存儲到單一資料庫中，相關的查詢直接在鏡像庫中執行，避免分庫的問題。

鏡像庫的數據同步，則是通過Canal+QMQ的方式來實現，並定時對比數據，業務應用上則是只讀不寫，嚴格保證雙邊數據一致性。

③ ES/MySQL對比

鏡像庫存在多種實現方案，很多系統採用了ES作為查詢引擎，我們該如何選擇？

ES也是解決複雜查詢場景的一種常見方案，我們曾經考慮採用ES來提升查詢性能，並且進行了詳細的評估和測試，但最終放棄了ES方案，主要考慮到以下幾點原因：

因此具體採用ES還是MySQL，或者是其他資料庫來建立鏡像資料庫，最重要的一點還是要基於現有的業務場景和實際生產上的需求進行綜合分析和驗證後，找出一個最適合自己當前情況的方案。

3）雙寫組件設計

因為技術棧的問題，目前我們的ORM採用的是公司的DAL組件。這個組件本身對公司的環境支持較好，而且該組件對於Sharding資料庫也提供了良好的支持。因此我們在該項目上仍然使用DAL作為我們資料庫的訪問組件。

但是原生的DAL並不支持雙寫的功能，不支持讀寫的切換。針對項目的特性，我們需要儘可能的讓開發少感知或者不感知底層資料庫的雙寫和讀寫切換的操作。一切對於用戶來說變得更簡單、更透明。另一方面，我們打算優化組件本身的使用介面，讓用戶使用起來更傻瓜化。

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

這些改造的意義是非常重大的，它是我們能夠高質量上線的關鍵。於是我們對組件進行了一些封裝和優化。

① 業務層對象和資料庫層對象進行隔離

為了統一維護方便我們將團隊內所有的資料庫對象（Pojo）都維護在了公共組件中。因此，在公共jar包中生成的對象通常是一個大而全的資料庫實體。這種大而全的實體信息存在以下幾個問題：

為瞭解決以上問題，我們中間新增了Model層，實現資料庫pojo和業務代碼的隔離。例如我們的航班信息表（Flight）有200多個欄位，但是實際在代碼中僅需要使用航班號和起飛時間。我們可以在業務代碼中定義一個新的FlightModel，如下圖所示：

@Builder
public class Flight implements DalDto {
   /**
    * 訂單號
    */
   private Long orderId;
  
   /**
    * 航班號
    */
   [DalField=”flight”]
   private String flightNo;
}

擴展組件將該對象映射到資料庫的Pojo上，並且可以改變欄位的命名甚至類型從而優化代碼的可讀性。在資料庫查詢時也進行了優化，僅僅查詢必要欄位，減少了開銷。

② 雙寫功能

我們實現的雙寫方案是先寫SQLServer再寫MySQL，同時也實現了失敗處理相關的策略。

雙寫模式包括：

這個主要是在雙寫功能實現的初期，我們會使用隊列+非同步線程的方式將數據寫入到MySQL。採取這種方式的數據一致性是比較差的，之所以採用這種方式也是在初期我們對資料庫處於探索階段，避免MySQL資料庫故障對當前系統產生影響。

當SQLServer寫入成功後，在相同的線程中對MySQL進行寫入。這種模式相對來說數據一致性會比較好，但是在極端情況下仍然可能存在數據不一致的情況。

如下圖所示。當任務1更新MySQL資料庫之前，如果有別的任務搶先更新了相同的數據欄位就有可能產生臟寫的問題。

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

剛纔提到我們抽象了Model層的數據，在此基礎上，我們的雙寫改造對用戶來說非常的容易。

@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註解實現資料庫Pojo的雙邊映射。除此之外，開發人員不需要對業務代碼做其他調整，即可以通過配置實現雙寫、數據源切換等操作。

③ 雙寫異常處理模式

雙寫時，我們需要儘可能保證數據的一致性，對於MySQL數據寫入異常時，我們提供了多種異常處理模式。

非同步雙寫時，如果從庫發生異常進行數據捕獲，不拋出異常，僅輸出告警信息

同步雙寫時，如果從庫發生異常進行數據捕獲，不拋出異常，僅輸出告警信息

同步雙寫時，如果從庫發生異常，拋出異常，中斷處理流程

④ 雙讀功能

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

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

⑤ 數據寫入異常的補償方案

我們需要在不同階段設計不同的補償方案。初期MySQL的數據並不會對外提供服務，即使數據寫入失敗，也不能影響系統流程的正常運行，同時也要保證數據寫入的準確性。因此，我們採用了SC的異常處理模式，並且增加了主動和被動的數據補償。

但是我們的目標是使用MySQL的數據。因此，當主數據源需要SQLServer切換到MySQL後，雖然資料庫寫入的順序仍然保持先寫SQLServer再寫MySQL，但是數據寫入失敗的處理模式需要發生變化。

這裡先插播一個問題，就是為什麼不能先寫MySQL然後同步更新SQLServer。主要考慮到以下兩個因素：

由於MySQL是Sharding資料庫，如果先插入該資料庫，預設情況下會通過雪花演算法生成主鍵。寫入完成後，我們將該主鍵同步給SQLServer。

但是受到公司ORM框架和歷史遺留的技術限制，SQLServer不會使用該數據，仍然採用自增的方式生成主鍵。導致數據嚴重不一致。

當我們以SQLServer作為主資料庫時，如果數據不一致需要同步給MySQL（非同步存在延時）；當以MySQL作為主資料庫時，如果發生數據不一致，需要進行反向同步。

一來，數據補償程式複雜度很高。二來，如果我們如果在MySQL和SQLServer資料庫誰作為主庫之間切換頻繁，數據同步程式就會變得非常迷茫，到底誰該同步給誰？

那麼如何提高在以MySQL為主的情況下，雙邊資料庫的一致性呢？

首先，我們得關閉自動補償功能，異常處理模式需要從SC切換到ST，遇到MySQL失敗直接拋出資料庫異常，然後基於系統的業務場景進行如下操作：

對於訂單處理系統，大部分的流程其實具備了自動補償的能力，因此哪怕SQLServer更新成功，MySQL未成功。下次補償程式仍然讀取MySQL，SQLServer會被二次更新，從而達到最終一致性。

這個時候，需要考慮的SQLServer的可重入性。

因為此時MySQL已經作為主要數據源，如果SQLServer存在不一致的場景可以提供手工的方式將數據補償回SQLServer。這邊沒有實現自動補償，因為理論上只有在數據不一致的場景，並且發生了回切才會產生影響。

⑥ 組件設計的功能和策略分離

我們整體的功能都整合在名為Dal-Extension的系統組件里，主要分為功能實現和策略兩大部分。

功能就是前面提到的例如雙寫，讀切換，異常處理模式切換等。策略就是引擎，它實現了功能和功能間的聯動。例如上文提到的，如果以SQLServer作為主數據源，那麼系統自動採用SC的異常處理模式，並且主動調用數據補償功能。如果是以MySQL作為主數據源，那麼系統自動切換到ST的異常處理模式。

相較於基於應用、表維度的切換策略。我們提供了維度更豐富的切換組合策略。

通過對以上維度的配置進行靈活調整，我們即可以實現單表，單機器的試驗性切換控制，也可以進行全鏈路的灰度切換，確保一個訂單在整個訂單處理生命周期使用相同的數據源，從而避免因為數據雙寫或者同步導致的數據讀取結果不一致的問題。整體的數據切換操作由配置中心統一托管。

4）分片故障處理

原先的資料庫如果發生了故障，會導致整個系統不可用。但是新的資料庫擴展成64個分片後，其實相對來說故障概率提高了64倍。因此，我們需要避免部分分片故障導致整個系統失效的情況。另外增加故障轉移和隔離功能，避免故障擴散，減少損失也是我們重點關註的功能。

當然，如果發生分片故障，首選的故障恢復方案是資料庫的主從切換。

① 返回僅包含查詢成功分片的部分數據

我們調研了數據使用端，發現有很多場景，例如人工訂單處理的環節，是可以接受部分數據的返回。也就是說有查詢出儘可能多符合條件的訂單，放入人工待處理列表中。我們增加了continueOnError參數來表示當前查詢可以接受部分分片失效的場景。並且，系統返回了查詢結果後，如果存在分片查詢失敗的場景，系統會提供了錯誤分片的信息。這樣業務上不僅能夠確保了很多業務環節處理不中斷，同時針對它提供的錯誤分片信息可以讓我們快速感知失效的分片，以便系統自動或者人工對這些分片進行干預。

② 故障分片隔離

當分片發生故障時，有可能我們的資料庫請求被hang住。我們allShards查詢的底層實現是基於共用線程池。當部分分片的響應慢時，會拖累整個線程池。另外單表查詢時，也可能會因為資料庫響應時間的問題導致工作線程數量上漲的問題。

我們為此增加了分片屏蔽的參數。當我們啟用分片臨時屏蔽功能後，底層資料庫查詢時，發現該分片被屏蔽直接拋出異常，讓應用程式能夠得到快速響應。從而避免了網路和資料庫訪問時間消耗，提高了異常執行的效率，避免問題擴散到正常的分片的數據處理。

③ 故障訂單轉移

如上圖所示，用戶ID_1和用戶ID_2根據哈希演算法，原先會在分片1上生成訂單。但是如果發生了分片1故障時，我們的UID分片計算組件會將分片1標記為不可用，然後通過新的Hash演算法計算出新的分片。

這裡需要註意的是，新hash演算法的選擇。

使用同樣的哈希演算法，但是生成結果後取模的值為63（64-1），但是這個存在的問題是用戶ID_1和用戶ID_2計算出來的分片結果是一致的。假如新的分片號為2的話，如果發生分片1、分片2同時失效的情況下。那麼仍然有1/64的訂單出現問題。

採用新的哈希演算法，儘量使訂單分佈在出了分片1以外的其他分片上。那麼這種方法，即使分片1、分片2同時失效。那麼僅僅會影響到1/64 * 1/63的訂單。受影響的訂單量大幅降低。

除了以上提到的技術問題以外，我們再談談項目的管理和規劃問題。首先，圈定合理的項目範圍，劃清項目邊界是項目順利實施的重要前提。這個項目的範圍包括兩個重要的屬性：數據和團隊。

1）數據範圍

① 劃定數據表範圍，先進行表結構優化的工作

我們需要在項目初期明確數據表的範圍，針對一些可以下線的表或者欄位，先完成合併和下線的工作，來縮小項目範圍。避免表結構的變化和該項目耦合在一起，造成不必要的困擾。

② 相關數據表中哪些數據需要被遷移

我們在處理這個問題上，有一些反覆。

因為訂單數據分為冷熱數據，所以我們最開始考慮是不是只要遷移熱數據就好了，冷數據僅保留查詢功能。

但是，這個方案有兩個很大的問題：一是存在冷數據需要被還原到熱數據的場景，增加了系統實現的複雜度。二是冷數據保留時限的問題，無法在短時間內下線這個資料庫。

針對有一些表由於業務或者系統改造的原因，可能後續數據不會更新了，或者在新的訂單上這些欄位已經廢棄了。大家在設計新表的時候其實往往很不喜歡把這些已經廢棄了的信息加到新設計的表中。但是，我們需要面臨的問題是，舊數據如何相容是一個非常現實的問題。

因此，當我們開發到中間的過程中，還是將部分表和欄位重新加了回來。來確保舊資料庫儘快下線以及歷史邏輯保持相容。

我們最後採用了這個方案，哪怕這個數據表或者欄位未來不會做任何修改。

2）團隊範圍

確定好數據範圍後，我們需要根據這些數據，確定我們需要做的工作以及找到完成這些工作的相關團隊並提前安排好資源。整個項目的資源分為核心成員和相關配合改造的團隊。

核心成員需要做到組織分工明確，並且需要經常一起頭腦風暴，提出問題，解決問題，消除隱患。核心成員的另一個職責是幫助配合改造的團隊，協調並且解決技術問題、資源問題等等。特別是涉及到的改動點較多、改造難度較大的團隊，需要提前介入，在適當的時候提供更多的幫助。

確定了項目的目標和範圍後，我們為項目設計了6個裡程碑，來幫助我們更好的完成這個項目。

階段1：通過API對讀取進行收口

這個階段雖然難度並不大，但是周期很長，溝通成本較高。在這個階段重點在於任務的協調和跟進。DBA幫助我們研發了生產Trace查詢的工具，能夠準實時的知道數據表的訪問情況，幫我們快速驗收並且圈定改造範圍。

我們建立了任務的看板，為每一個任務設定了負責人以及預期解決的時間，定期對任務進行進行跟蹤。項目的負責人也作為驗收人，確認每個任務的完成情況。

通過一段時間的努力，資料庫的訪問收口在極少數內部應用當中。實現了數據訪問的收口。

階段2：開發雙讀/雙寫功能來實現平滑的數據切換

這個階段需要將整個項目的技術點、難點都逐一的找到，並且給出解決方案。如何提高效率和質量也是這個階段重點關註的話題，我們儘量把這些雙寫、切換的功能進行封裝，讓業務邏輯層儘可能少感知，或者不感知這些底層邏輯。降低代碼開發量，不僅能提高效率，還能提升質量。

總的來說，這個階段需要提升開發效率，提高開發質量並且降低項目風險。

階段3：驗證數據一致性

這個是對階段2的驗證工作，需要註意的是在驗證中減少噪音，提高驗證的自動化率，能有效的提升項目的開發質量。

階段4：通過壓測，故障模擬等手段驗證系統性能。在資料庫故障時，提供可靠的系統的災備和故障隔離能力。

階段5：數據讀取從SQLServer切換到MySQL

這個階段可能不需要有太多的資源投入，但是風險卻是最大的。這個階段是對前面所有階段成果的驗收。做好數據監控、制定良好的切換方案、出現問題時能夠回退是這個階段順利實施的重點。

階段6：停止SQLServer寫入並且下線相關數據表

相比起階段5，階段6沒有後悔藥。一旦停止了SQLServer的寫入，就非常難進行回切的操作。所以得仔細做好白名單的驗證，並且及時響應和解決相關問題。

整個項目周期較長，我們需要制定好每個階段的目標，每個任務的目標。由於資料庫承載了非常核心的業務，因此整個階段、所有任務以及技術方案其實圍繞著一個原則展開，就是降低風險。

所以我們在設計每個技術方案的時候，儘可能考慮這點。例如在數據源切換的開關雖然涉及較多的服務實例，但是我們通過一個集中控制的平臺，來實現全鏈路的切換和灰度控制。

該項目整體的周期較長，每個階段的挑戰不盡相同。為了確保項目的上線質量，後續在讀切換、寫切換兩個流程的灰度時間比較久。項目大約在2021年下半年順利完成。

實現了以下主要目標和功能：

系統分片數量為64，部署在16台物理機上。後續根據業務需要機器的部署方式和分片數量可以進行靈活調整。

資料庫伺服器的CPU利用率從高峰期40%下降到目前的3%-5%之間。

原先區分冷熱數據，熱數據大約僅能支持3個月的訂單，按照現在硬體資源推算，系統可以處理至少5年以上的訂單。

原先近200個應用直接訪問資料庫，給我們的改造帶來很大的不便。目前僅有限的內部應用允許直接訪問訂單庫。

原先主從伺服器的CPU為128核，記憶體256G；現在伺服器縮減為40核心的標準配置。

在項目過程中也積累了不少的經驗，例如：

整個項目中大約建立了數百個子任務，每一個任務需要落實負責人以及上線時間，並對上線結果進行驗收。才能確保整個項目的周期不至於拉的非常長，減少後續的項目返工和風險。

當一個大型的項目存在非常多的例外情況，這些特殊情況就得特殊處理，那麼到最後總會有一些沒有處理乾凈的尾巴。這些問題都是項目的潛在隱患。

這個和我們日常開發關係也非常密切，當一項任務有多個依賴方的時候，往往項目的進展會大幅超出我們的預期。因此減少一些前置依賴，在不是非常確定的情況下。我們得先做好最壞的打算。

很多時候我們往往會高估自己的能力，例如在這次的改造中，我們會順便優化一些表的結構。於是造成了MySQL和SQLServer的數據表差異過大的問題。那麼這些差異其實為後面的開發造成了不小的困擾。所有的方案，包括數據補償、遷移、數據源的切換等等場景都得為這些特殊差異的表單獨考慮方案，單獨實現邏輯。一不留神或者沒有考慮的很周全的情況下，往往會漏掉這部分的差異。導致項目返工，甚至出現生產故障。