前言
攜程酒店訂單系統的存盤設計從1999年收錄第一單以來，已經完成了從單一SQLServer資料庫到多IDC容災、完成分庫分表等多個階段，在見證了大量業務奇跡的同時，也開始逐漸暴露出老驥伏櫪的心有余而力不足之態，基于更高穩定性與高效成本控制而設計的訂單存盤系統，已經是攜程在疫情后恢復業務的必然訴求，
目前攜程酒店訂單系統，在著在業務高增長的同時，也面臨著資訊讀寫管理能力受制于資料庫自身性能與穩定性的窘境，綜合分析，一則為攜程服役了十多年的SQLServer服務器集群的磁盤容量設計，已經跟不上時下新增訂單量的空間訴求；二則在系統能力提升上造成了各大業務系統巨大的底層瓶頸與風險，同時又相比業界主流已基于MySQL架構設計存盤系統而言，我們的訂單存盤系統仍基于SQLServer構建也整體推高了運營成本，
為了支撐未來每日千萬級訂單的業務增長目標，同時滿足高可用、高性能、高可擴展的高效成本控制期望，我們為酒店部門的訂單DB所有訪問開發并落地了一套穩定且可靠的統一中間件封裝方案，對現狀收斂并提供了全域統一的熱點快取系統，徹底解決了當下訂單上層應用與資料庫間直連的方案缺陷，
新系統由中間件服務統一實作了對上層應用提供資料鏈服務，并達成了為現有依賴訂單庫的應用以及其他直接或間接的資料應用無感的實作存盤底層由SQLServer向MySQL技術架構遷移的目標，
一、架構綜述
通過對現有系統瓶頸的分析，我們發現核心缺陷集中在訂單資料快取分散導致資料各端不一致，各訂單應用則與資料庫直連又造成可擴展性差，通過實踐我們撰寫中間件抽象并統一了資料訪問層，以及基于資料庫部署架構鏡像構建了訂單快取統一管理熱點資料，解決了各端差異，
圖1.1 存盤系統架構圖
二、應用場景
1、新單秒級各端同步
從訂單的提交到各端可見的速度為存盤服務的核心指標之一，我們對資料鏈的主要環節進行了優化，覆寫了新單同步、訊息實時推送、查詢索引構建以及資料平臺離線歸檔等主要環節，使大系統內資料到達速度在3秒以內，即用戶剛下完單即可跳轉我攜串列可見，
-
當新用戶創單時，同步服務作為資料鏈入口將用戶訂單資料通過中間件寫入訂單庫，此時中間件同時完成訂單快取的構建；
-
當訂單完成入庫行為和熱點資料構建后拋訂單訊息，實時輸出給各子系統；
-
當新單入庫完畢即刻構建訂單明細資訊的ES索引，為第三方提供檢索支持；
-
最后資料平臺T+1實施當日資料的歸檔供BI等各類離線業務使用，
圖2.1 資料鏈
2、自動發單與作業臺
對客、商、員工作業臺三端的支持是訂單存盤系統的基本角色，圖2.1資料鏈在新單提交后為自動發單與作業臺起到的銜接作用功不可沒，自動發單即在客人提交訂單后，以最快的回應速度向商戶發送訂單明細資訊進行核實貨位、確認訂單等流程，作業臺則協助員工介入流程及時獲取訂單處理人工事件，
圖2.2 基于存盤系統的發單與作業臺關系（縮略細節）
3、查詢與資料分析
基于訂單資料為核心的主要分為在線查詢和資料分析兩條業務線，以對詳情查詢為例，訪問QPS終年保持在高位，每逢假期高峰則容易造成查詢瓶頸，根因復盤后在本次架構升級中我們做了調整來優化相關場景的高可用性，
-
在線查詢以訂單快取為主，訂單提交即構建熱點快取紓解查詢壓力，并可按配置時間引數長時段有效，
-
非在線查詢場景，以實時訊息推送并結合Hive數倉T+1方式交付，凡需要長周期訂單資料的場合（例如實時報表）均接入訂單訊息實時計算，離線BI按年度等大批量資料分析時使用Hive表，并每日凌晨低峰時段以從庫低頻訪問的方式實施資料同步，
如此以上，我們將訂單主庫的訪問保護在訂單快取、實時訊息、Hive數倉三駕馬車之后，與業務盡最大可能的解耦，
三、系統升級實踐
在對攜程核心存盤系統進行更新換代的程序中，貫穿全程需要做到的是熱遷移，并達成所有操作對資料鏈路上的各應用透明無損的目標，我們的設計通盤分析了集團資料鏈路的特性，由訂單快取系統提供資料庫鏡像降低應用與資料庫的直連耦合，繼而再通過中間件對應用透明掉資料源于SQLServer / MySQL的物理關系，提供底層熱遷移的操作空間，
結合無損遷移的工藝設計，注重對每一筆資料庫流量的可見及可控，支持全庫、Shard級、表級、CRUD操作級的流量分配策略，提供了底層資料遷移足夠的實施手段，數倉銜接設計則側重于解決資料平臺百億級離線資料與雙庫在線期間的同步問題，以及解決全量接入MySQL期間產生的資料問題，
以下將分三個部分分享我們在這一程序中學到的經驗，
1、分布式訂單快取
隨著業務發展，用戶數和訪問量越來越大，訂單系統應用和服務器的壓力也與日俱增，在沒有引入訂單快取之前，每個應用獨立連接資料庫，造成查詢出來的資料無法在應用間共享，并且DB每秒查詢量和連接數都有上限，而酒店核心交易鏈路基于DB存盤，存在單點故障風險，
經過埋點資料分析，訂單系統是典型的讀多寫少，為了共享熱點查詢資料以及降低DB負載，一個有效的辦法就是引入快取，如圖3.1，用戶的請求過來時，優先查詢快取，如果存在快取資料，則直接回傳結果；快取沒有命中，則去查詢DB，根據配置策略校驗DB結果資料，校驗通過則將DB資料寫入快取留作后續查詢使用，否則不寫入快取，最后回傳DB查詢結果，
圖3.1 訂單快取基本設計
關于引入新的快取組件后的硬體開銷，可通過收斂原來各應用分散的硬體資源來降低總成本，但還會因為中心化管理帶來可用性挑戰以及資料一致性等問題，故需要充分對現有系統進行容量評估、流量估算和快取表價值分析，只快取訪問量高的熱點資料表，通過恰當的快取結構設計、資料壓縮和快取淘汰策略，最大程度提高快取命中率，在快取容量、硬體成本和可用性之間做好權衡，
傳統的快取設計，是一條資料庫表記錄對應一條快取資料，而在訂單系統中，一個訂單查詢多表的場景很常見，如果采用傳統設計，在一次用戶查詢中，Redis的訪問次數是隨著表數量增加的，這種設計網路IO較大并且耗時較長，在盤點表維度流量資料時，我們發現有些表經常一起查詢，不到30%的表其查詢流量超過90%，在業務上完全可以劃分為同一個抽象領域模型，然后基于hash結構進行存盤，如圖3.2，以訂單號作為key，領域名稱作為field，領域資料作為value，
這樣無論是單表還是多表查詢，每個訂單都只需要訪問一次Redis，即減少了key，又減少了多表查詢次數，提升了性能，同時value基于protostuff進行壓縮，還減少了Redis的存盤空間，以及隨之而來的網路流量開銷，
圖3.2 基于domain的存盤結構簡述
2、無損遷移工藝
如何做到無損熱遷移是整個專案最具挑戰性的地方，在工藝設計之前我們的前置作業首先完成了中間件的開發，通過中間件將資料庫與業務層應用一分為二，其次抽象Dao層實作領域化，并由資料領域層向應用提供資料服務，領域之下適配SQLServer和MySQL兩種資料庫并統一封裝，以此為基礎才能為以下述工藝設計實施無損熱遷移，
-
SQLServer和MySQL雙庫在線，實施雙寫，主寫SQLServer，同步副寫MySQL，如果SQLServer操作失敗則整體失敗，回滾雙寫事務，
-
SQLServer和MySQL之間增加一路同步Job，實時查詢SQLServer最近時間視窗變更的資料進行一致性校驗MySQL中的條目，差異點追齊，可以確保雙寫期間不可預期的兩邊不一致，特別是還殘有直連寫SQLServer應用的階段特別有用，
-
中間件設計有配置系統，支持任一主要查詢維度可按配置精準的將資料源定向到SQLServer或MySQL，并可控制是否讀取后加載到訂單快取，初期設定只加載SQLServer資料源，避免因雙庫間的資料不一致而造成快取資料跳躍，并在初期可設定灰度，將小批量非核心表直連MySQL驗證可靠性，后期資料一致性達成預期后，訂單快取也可自由按指定資料庫加載快取，
-
解決了查詢場景下的資料一致性問題后，流量策略支持圖3.3中任一可調控維度進行資料庫單寫，實際專案中以表維度實施單寫為主，當指定表被配置單寫MySQL后，所有涉及該表的CRUD行為全部定向MySQL，包括快取加載源，
-
最后通過中間件統一收口對外發送的訂單訊息，所有訊息基于中間件的CUD操作發送與物理資料庫無關，這樣實作訊息的資料源透明，且可聯動以上所有工藝操作，資料鏈保持一致，
圖3.3 操作工藝簡介
3、數倉銜接
為了方便理解生產資料到資料倉庫ODS層資料的遷移，做到對下游透明，這里簡單介紹一下常規資料倉庫的分層體系，通常資料倉庫主要分為五層：ODS(原始資料層)、DIM(維度)、EDW(企業數倉)、CDM(通用模型層)、ADM(應用模型層)，如下圖所示：
圖3.4 資料倉庫分層結構
從圖3.4上可以看出，資料倉庫各層都依賴ODS層的資料，為了不影響資料平臺所有應用，我們只需要將原來訂單庫ODS層資料源從SQLServer遷移到MySQL庫即可，
從圖上很直觀的看出，遷移只需換個資料源不是很麻煩，但是為了保證資料質量，我們做了很多的前置作業，比如：DBA預先將生產資料同步到生產MySQL庫、MySQL資料實時同步、生產兩側資料一致性校驗、MySQL側資料同步到ODS層、ODS層資料一致性校驗及原有ODS層同步Job資料源切換等，
其中，生產兩側資料一致性校驗和資料倉庫ODS層資料一致性校驗最為復雜，耗時也最長，要確保每張表、每個欄位都要一致時才能切換資料源，但是，從實際操作程序中，卻做不到完全一致，根據實際情況，適當處理時間型別、浮點值精度及小數位等，
下面介紹一下整體流程：
首先，對于線上資料一致校驗，我們開發了在線同步Job，將SQLServer的資料和MySQL資料進行比較，發現不一致時，就將MySQL的資料以SQLServer資料為基準更新掉，確保兩邊資料的一致性，
其次，對于離線資料一致性校驗，我們和資料倉庫同事合作把MySQL側資料同步到ODS層(以庫名區分是SQLServer還是MySQL的表)，并且將定時跑的任務和SQLServer側任務在時間上盡量一致，兩側資料都準備好后，我們開發了離線資料校驗腳本生成器，根據資料倉庫元資料，為每張表生成一個同步Job，將其部署到調度平臺，
同步任務會依賴兩側ODS層同步資料，T+1資料同步完成后，執行一致性校驗，將不一致的訂單號記錄到不一致明細表中，并統計不一致的資料量，將結果保存到統計表中，然后在自助報表平臺制作一個報表，將每天統計的不一致的表及不一致量發送到郵箱，我們每天對不一致的表進行排查找出問題，調整比較策略，更新比較Job，大致流程如下：
圖3.5 一致性校驗整體流程
最后，隨著線上和離線資料逐步趨于一致后，我們將原先SQLServer同步到ODS層Job的資料源切換到MySQL，這里可能有同學會有疑問：為什么不直接使用MySQL側ODS層的表呢？原因是，經過統計，依賴原先ODS層表的Job有上千個之多，如果讓依賴Job切換到MySQL側ODS表，修改作業量非常大，所以我們直接將原來的ODS層同步資料源直接切換成MySQL，
實際操作中，切資料源并不能一次全部切完，我們分三批進行，先找十幾個不那么重要的表作為第一批，切完后運行兩周，并收集下游資料問題的反饋，第一批表順利切完兩周后，我們沒收到下游報資料問題，說明資料質量沒問題，然后再將剩余的幾百張表按重要程度分兩批繼續切，直到切完，
至此，我們完成了訂單庫從SQLServer遷移到MySQL在資料倉庫層的遷移作業，
四、核心問題精編
實際上再周密的分析與設計，總是難免遇到執行程序中的各種挑戰，我們總結了一些經典問題，雖然通過技術手段最終解決了這些大大小小問題并達成了目標，但是相信各位看官必定還有更好的解決方案，我們樂見共同學習與進步，
1、SQLServer & MySQL 流量遷移如何細粒度監控
訂單系統涉及到的應用和表數量眾多，一個應用對應1到n張表，一張表又對應1到n個應用，是典型的多對多關系，如圖4.1，對于上層應用來說，從一個SQLServer資料庫，切換到另一個MySQL資料庫，其基本流程參照操作工藝章節至少分為以下幾步：
-
從單寫SQLServer變成雙寫SQLServer和MySQL
-
從單讀SQLServer變成單讀MySQL
-
從雙寫SQLServer和MySQL變成單寫MySQL
-
下線SQLServer
圖4.1 應用和資料庫以及表的關系圖
在生產環境更換資料庫系統，就像在高速公路上不停車換輪胎，需要維持原有的車速不變，且對用戶無感，否則后果不敢設想，
在切換工藝中雙寫、單讀和單寫流程，環環相扣，步步相依，作為配套設計監控手段必須確認上一個操作達到預期效果才能進行下一個，如果跳過或者沒有切換干凈就貿然進行下一步，比如還沒有雙寫完全一致，就開始讀MySQL資料，可能造成查無此資料或者查到臟資料！那么就需要對每一個CRUD操作的讀寫進行監控，在遷移程序中做到360度無死角可視化流量細分控制，所見即所得，具體的做法如下：
-
所有應用接入中間件，CRUD由中間件根據配置控制讀寫哪個DB的哪張表；
-
每一個讀寫操作的詳細資訊均寫入ES，在Kibana和Grafana上可視化展示，并且通過DBTrace，可以知道每條SQL是在哪個DB上執行；
-
按照應用級別逐步配置雙寫DB，通過同步Job實時比對、修復和記錄兩側DB差異，再通過離線T+1校驗雙寫中出現的最終不一致，如此往復直到雙寫一致；
-
雙寫一致之后，就開始逐步將讀SQLServer切換到讀MySQL，通過ES監控和DBTrace確認完全沒有SQLServer讀，則表明單讀MySQL完成，考慮到自增主鍵情況，我們采取按照表維度，按批次斷寫SQLServer，直至所有表都單寫MySQL，
綜上所述，基本方案為通過中間件為管道為所有接入的應用統一埋點，通過實時展示應用層的行為觀察流量分布，并結合公司資料庫側Trace的可視化工具核實應用的流量切換行為與資料庫實際QPS及負載浮動保持一致來監督遷移任務，
2、如何解決雙寫期間DB一致性問題
酒店的訂單庫有著二十年左右歷史，經年累積，跨部門和酒店內部多個團隊直接或間接依賴訂單庫SQLServer，要想切換到MySQL，就得先解決雙寫DB一致性問題，不一致主要體現在以下兩點：
-
雙寫時實際僅單寫了SQLServer，漏寫MySQL；
-
雙寫SQLServer和MySQL成功，并發、不可靠網路、GC等發生時MySQL資料有幾率和SQLServer不一致，
關于雙寫資料一致性的保證，我們基于同步Job將SQLServer資料為準線，根據最后更新時間，拉取兩側DB資料進行比對，如果不一致則修復MySQL的資料并將不一致資訊寫入ES，供后續排查根因，
但也因為引入了額外的Job操作MySQL資料，帶來了新的問題，那就是多表雙寫時，因為耗時翻倍，Job發現SQLServer有資料而MySQL沒有，就立即修復了MySQL資料，造成雙寫失敗，所以雙寫部分失敗又加上了Failover機制，通過拋送訊息，觸發新一輪的比對和修復作業，直到兩側DB資料完全一致，
同步Job和Failover訊息機制雖然可以讓資料最終一致，但畢竟有秒級的間隔，兩側資料是不一致的，并且對于眾多應用的各種場景，難免會有遺漏時單寫SQLServer，對于這些漏寫MySQL的地方，通過DBTrace是無法找到的，因為無法確定一個CUD操作只寫入SQLServer，而未寫入MySQL，那么有沒有辦法事前就能找出漏寫MySQL的場景呢，確實被我們找出來一點，那就是更換資料庫連接串，接入中間件的應用使用新連接串，然后找出所有使用舊連接串操作SQLServer的SQL，就能準確定位出漏寫MySQL的流量了，
最終，我們將雙寫DB不一致率從十萬分之二逐步降低到了幾乎為0，為什么是幾乎呢，因為DB的一些特性差異問題，會天然的導致資料無法完全一致，這個在后續內容會有詳細的論述，
3、引入訂單快取后導致的資料不同步問題處理
引入快取之后，就涉及到對快取進行寫入或者更新，業界常見的做法分為以下幾種：
-
先寫DB再寫快取
-
先寫快取再寫DB
-
先刪快取再寫DB
-
先寫DB再刪快取
在具體實施上還會進行雙刪快取或者延遲雙刪快取，此處不再比較各種做法的優劣，我們采用的是先寫DB再刪快取方案，對于資料敏感表，會進行延遲雙刪，后臺的同步Job定時比對、修復和記錄資料庫資料與Redis資料的差異，雖然設計上已經能保證最終一致性，但是在前期還是出現過大量的資料不一致，主要體現在以下幾個方面：
-
應用有場景未接入中間件，對DB進行CUD操作之后，漏洗掉快取；
-
寫DB后洗掉快取延遲導致讀取到快取臟資料，比如不可靠網路、GC等造成刪快取延遲；
-
寫DB后洗掉快取失敗導致讀取到快取臟資料，比如Redis主從切換期間，只能讀不可寫，
而為了解決快取一致性問題，如圖4.2，我們在原有的快取和DB基礎上，增加了樂觀鎖和CUD施工標記，來限制并發情況下同時存在加載資料到快取相互覆寫的行為，以及對當前被查資料正在進行CUD操作的感知，在此兩種場景未結束期間可以做到Query流量直連DB，通過基于樂觀鎖的最后寫入者獲勝機制解決競爭問題，最終我們的快取不一致率從百萬分之二控制到了千萬分之三，
圖4.2 快取一致性解決
圖4.2當查詢未命中快取，或當前存在該資料的樂觀鎖或施工標記時，當次查詢直連DB，直至相關事務完成后放開快取資料自動加載功能，
4、存量訂單資料如何一次性校準
專案啟動初期我們對MySQL進行了最近N年資料的一次性鋪底，這就產生了在雙寫階段無法校準的如下兩個場景的資料：
-
因生產上訂單庫預置保留近N年的資料，負責清理備份的Job在接入中間件前，MySQL已存在的N年外的這批資料無法被策略覆寫而清理掉，
-
所有應用接中間件花了很長時間，接中間件雙寫前資料有可能不一致的，需要全部應用接中間件和全部表雙寫后，對之前的資料進行一次性修復，
針對第一點，我們開發了MySQL資料專項清理Job，由于訂單資料庫是多Shard的，Job內部根據實際Shard數設定核心執行緒總量，每個執行緒分別負責對應Shard中的指定表進行清理，并行開多臺服務器分發任務進行清理，通過速度控制既保證了效率又不影響生產上資料庫的負載，
針對第二點，在所有應用接中間件和所有表實作雙寫后，通過調整線上同步Job掃描的開始時間戳，對存量訂單資料進行修復，修復時特別注意的是，掃描資料要按時間段分片處理，防止加載資料太多導致訂單庫服務器CPU太高，
5、一些資料庫特性差異問題
在如此龐大的系統下進行資料庫熱遷移，我們就必須了解不同資料庫之間的差異與不同，做到知己知彼，對癥下藥，MySQL與SQLServer雖同為時下流行的關系型資料庫，均支持標準化SQL查詢，但在細枝末節上還是有些許差異，下面我們通過遷移中所面臨的問題來具體分析一下，
1）自增鍵問題
為保證資料自增序號一致，不能讓兩個資料庫各自去進行自增，否則一旦不一致就要面臨修資料甚至更大風險，因此，在資料雙寫時，我們將SQLServer寫入后生成的自增id，回寫入MySQL自增列，在資料單寫MySQL時直接使用MySQL生成自增id值，
2）日期精度問題
雙寫后為了保證資料一致性，要對兩側資料進行一致性校驗，型別為Date、DateTime、Timestamp的欄位，由于保存精度不一致，在對比時就需要做特殊處理，截取到秒進行比較，
3）XML欄位問題
SQLServer中支持XML資料型別，而MySQL 5.7不支持XML型別，在使用varchar(4000)代替后，遇到MySQL資料寫入失敗，但同步Job將SQLServer資料回寫MySQL時又能正常寫入的案例，經過分析，程式在寫入時會將未壓縮的XML字串寫入，SQLServer XML型別會自動壓縮并存盤，但MySQL并不會，導致長度超過4000的寫入操作失敗，SQLServer壓縮后長度小于4000，又能夠正常回寫MySQL，為此我們提出應對措施，寫入前壓縮并校驗長度，非重要欄位截取后再存盤，重要欄位優化存盤結構或更換欄位型別，
下面列舉一些遷移程序中常見的注意點，
五、預警實踐
我們的預警實踐并不局限于專案推進期間的監控訴求，如何在百億級資料中周期掃描資料寫入的例外，完成專案期間雙寫資料一致率的復核，如何實時監控與預警訂單庫每個分片上訂單寫入量的正常趨勢，如何定期驗收/核驗整套系統的高可用性將在以下篇幅中描述，
1、百億級資料差異校驗預警
要滿足訂單資料SQLServer遷移到MySQL庫，資料質量是遷移的必要條件，資料一致性達不到要求就無法透明遷移，所以設計合理的校驗方案，關乎遷移的進度，針對資料校驗，我們分為線上和線下兩種：
-
線上資料校驗和預警
遷移期間我們通過同步Job，在計算出不一致資料后，將不一致的表及欄位寫入ElasticSearch，再用Kibana制作出不一致資料量及不一致表所占比例的監控看板，通過監控看板，我們就可以實時監控哪些表資料不一致量比較高，再根據表名稱通過DBA工具排查出哪些應用對表進行了CUD操作，進一步定位漏接中間件的應用和代碼，
在實際操作中，我們確實找出了大量未接中間的應用并對其改造，隨著接入中間件的應用越來越多，資料一致性逐漸提高，從監控看板上看到不一致的量也慢慢降低，但是一致性始終沒有降低到零，原因是應用和同步Job并發導致的，這個也是最令人頭疼的問題，
或許有同學會疑問，既然雙寫了為什么不停止掉同步Job呢？原因是雙寫以SQLServer為主寫，以受中間件覆寫的CUD范圍為基準，除了不能保證寫入MySQL的資料百分百成功外也不能保證兩庫的資料量相等，所以需要一致性Job兜底，由于并發的存在，雖然做不到資料百分百一致，但是可以進一步降低，
我們的做法是，一致性Job比較時設定一個5秒的穩定線（即距離當前時間5秒內的資料視為不穩定資料），訂單資料時間戳在穩定線內的不進行比較，穩定線外的比較時，會再一次計算訂單資料是否在穩定線內，如果確認全部資料在穩定線外，就進行比較操作，否則放棄本次比較，由下一次調度執行一致性校驗，
-
離線資料校驗和預警
訂單庫遷移涉及到幾百張表，離線資料比較多，一年的訂單相關資料就有上百億了，對于離線資料校驗比較有挑戰，我們撰寫了資料一致性腳本生成器，為每張表生成一個比較腳本并部署到調度平臺，比較腳本依賴上游SQLServer和MySQL兩側的同步Job，上游Job執行完畢后自動執行資料比較，將不一致資料的訂單號寫到明細表中，并根據明細表統計出不一致量，以日報的形式發出，每天對資料不一致比較高的表排查并解決，
通常一是能修復對比腳本的瑕疵，二是發現離線資料問題，就這樣反復摸排解決不一致問題，對于離線資料每張表每個欄位的校驗是非常復雜的，我們撰寫UDF函式進行比較，UDF函式功能也很簡單，就是將每張表的非主鍵欄位進行拼接生成一個新欄位，兩側表進行全外連接，主鍵或者邏輯主鍵相等的記錄，生成新欄位也應該一樣，只要不一樣就視為不一致資料，這里要注意日期欄位截取、資料精度及末尾為零的小數處理問題，
經過三個多月的努力，我們排查出所有未接中間件的應用，并將其CUD操作全部接入中間件，開啟雙寫后線上線下資料一致性逐步提高，達到了遷移資料的目標，
2、ALL Shard 實時訂單總量監控
每個公司對于訂單量的監控是不可或缺的，攜程有一個統一預警平臺Sitemon，它主要監控各類訂單告警，包括酒店，機票，無線，高鐵，度假，并能按照online/offline，國內/國際，或者支付方式單獨搜索和展現，并對各類訂單做了告警，
訂單資料從SQLServer遷移到MySQL期間，我們梳理出來依賴訂單庫的預警策略近兩百個，負責監控的相關同事對SQL Server資料源的預警策略原樣復制一份連接MySQL資料源，以MySQL為資料源監控告警都添加完成后，開啟報警策略，一旦訂單量例外報警，NOC會收到兩條通知，一條來源于SQLServer資料告警，一條來源于MySQL告警，如果兩邊一致，說明灰度驗證通過，否則，不通過，需排查MySQL 監控問題，
經過一段時間的灰度驗證，兩邊報警資料一致，隨著SQLServer資料表下線（即單寫MySQL資料），以SQLServer為資料源的預警策略也跟著及時下線，
3、“流浪地球”實操
為了做好系統安全保障作業，提高應對突發事件的能力，必要的演練壓測等是少不了的，為此，我們制定了完備的應急預案并定期組織開展應急演練——流浪地球，演練專案包括核心/非核心應用熔斷、DB熔斷、Redis熔斷、核心防火墻、交換機應急切換等，
以快取為例，為了保證快取服務的高可用，我們在演練時會下線部分節點或機器甚至切斷整個Redis服務，模擬快取雪崩、快取擊穿等場景，按照計劃，在熔斷前我們會先切斷應用的Redis訪問，一步步降低Redis負載，然后熔斷Redis，以此檢驗在無Redis的情況下各應用系統是否能夠正常運轉，
但在首次演練中，熔斷Redis后應用報錯量就急劇上升，果斷停止演練回退并查找原因，經過分析，部分應用Redis操作未統一收口，不受中間件統一控制，Redis熔斷后應用隨即出現例外，針對這一情況，我們分析后一方面將報錯應用的訂單快取訪問收口接入中間件，另一方面強化了中間件與Redis的弱依賴關系，支持一鍵斷開Redis操作，并完善了各項指標監控，最終在第二次演練中順利完成Redis熔斷，各業務系統在全流量打入MySQL的狀態下的正常運行，在最近一次的流浪地球演練中，機房網路阻斷、非核心應用阻斷等一輪輪故障注入后，我們的系統更是取得了很好的預期效果，
就這樣，在一次次的演練中，我們發現問題，總結經驗，優化系統，完善應急預案，一步步提升系統應對突發故障的能力，保證業務的連續性以及資料的完整性，做好底層資料支撐，為整個酒店訂單系統保駕護航，
六、未來規劃
1、訂單快取手工調控臺
雖然我們有完善的監控看板與預警系統，但對于像熔斷演練、自動化故障演練、硬體故障和維護以及不可提前預知的問題，若剛好核心開發人員未能及時在現場回應操作，系統尚不能完全自主降級可能導致部分性能有所下降，比如回應耗時增加等，在將來計劃增加手工調控看板，授權后可以讓NOC或者TS進行針對性操作，比如Redis全部或者部分集群宕機，可以一鍵切割故障Redis分片，或者根據Redis已計劃中的不可用時間段來提前設定切割時間，可以最大程度保證系統的可控性，
2、中間件自動降級
既然可以手工進行調控，那么我們也考慮后續可以通過一些核心指標的監控，比如Redis主從切換期間，正常情況是秒級，但是我們也出現過部分Redis 10秒以上不可寫的情況，此時可以監控快取與資料庫不一致的臟資料量，也可以在Redis發生故障時通過監控回應耗時例外的閥值來應用一些策略，讓中間件自動降級切割掉這些故障主機保證服務的基本穩定，然后在探測到集群指標穩定后再逐步嘗試恢復，
3、中間件接入Service Mesh
當前訂單團隊內部是以JAR的方式使用中間件，由中間件來屏蔽資料庫底層差異和操作Redis以實作更復雜的功能，天然具備接入Service Mesh能力，接入后底層升級更加快速和無感、呼叫更加輕量化、更好與框架進行網格化集成以及上云更加方便，能夠更好的支撐攜程的國際化戰略目標，
作者丨榮華、軍威、金永、俊強
本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/From-SQL-Server-to-MySQ_Ctrip_s-core-system-has-no-sense-of-migration.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/501410.html
標籤：MySQL
上一篇：MySQL中實作中文轉拼音
下一篇：Java學習路線之redis