SQL Server無感系統遷移到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，它主要監控各類訂單告警，包括酒店，機票，無線，高鐵，度假。該系統具備根據線上/線下、國內/國際及支付方式進行獨立搜尋和展示，並對所有類型訂單進行警報的功能。

訂單資料從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能力，接入後底層升級更加快速和無感、調用更加輕量化、更好與框架進行網格化集成以及上雲更加方便，能夠更好的支撐攜程的國際化戰略目標。

以上是SQL Server無感系統遷移到MySQL怎麼實現的詳細內容。更多資訊請關注PHP中文網其他相關文章！