本文作者： 張顯華、竇智浩、盧進文
與集中式架構相比，分佈式架構的系統複雜性呈指數級增長，混沌工程在信創轉型、分佈式架構轉型、小機下移等過程中有效保障了生產的穩定性。本文分享了 TiDB 分佈式數據庫在銀行核心業務系統落地中進行混沌測試的場景設計和實踐。
混沌工程概述
混沌工程是一種全面的測試方法，它覆蓋了從應用層前端到底層硬件環境的所有環節，確保整個系統在面對各種異常和故障時的穩定性和彈性。本文將聚焦於與 TiDB 分佈式數據庫相關的混沌工程場景。
混沌工程和普通測試在軟件系統工程中都扮演着重要的角色，但它們關注的質量屬性和測試實施的方式存在明顯差異。混沌工程更側重於系統的健壯性和在面對異常情況時的響應能力，而普通測試則側重於驗證系統的功能正確性和性能指標。兩者的差異詳見下表：
在着手進行混沌測試的場景設計和實施之前，有幾個關鍵問題需要我們深思熟慮：
首先，需要明確混沌測試的目標，希望通過測試掌需要關注的能力邊界、容錯能力、穩定性等。其次，選擇合適的混沌測試工具，這些工具能夠幫助我們在分佈式環境中模擬各種故障和異常情況。接下來，精心設計測試用例，確保它們能夠覆蓋到可能影響系統穩定性的關鍵環節。最後，梳理總結混沌測試可能帶來的收益，包括提高系統可靠性、優化故障恢復流程、增強團隊對系統行爲的理解等。通過這些環節的綜合考量，我們可以更有效地實施混沌測試演練，爲 TiDB 分佈式數據庫的穩定性提供堅實的保障。
混沌測試目的
TiDB 作爲一款原生分佈式數據庫，其架構設計與銀行系統中的傳統集中式數據庫相比具有顯著的差異。銀行核心系統對性能、穩定性、跨地域的高可用性都有着嚴苛的要求。爲了滿足這些要求，我們計劃通過混沌測試來摸底性能邊界、評估系統高可用性和容災能力、驗證系統的彈性、檢驗應急預案有效性、優化監控和告警機制、並準確評估外圍作業的影響。
2.1 摸底性能邊界
摸底數據庫的能力邊界，對上線後的運維工作具有重要的參考意義。一個新的業務系統在設計之初，不僅要滿足當前的業務需求，還要考慮滿足未來的業務發展需求，尤其是在極致穩定性要求下，銀行核心系統的設計需要考慮未來 5 年至 10 年以上的業務發展需求。通過混沌測試，在總體設計的配置下，測試數據庫的能力邊界，將結果作爲上線後運維的重要參考指標，並檢驗系統是否滿足總設要求下未來業務的承載體量。
此外，通過混沌測試還可以發現整個業務鏈路可能存在的一些瓶頸點。
2.2 評估系統高可用和容災能力
TiDB 的存算分離架構由核心組件和外圍組件組成。核心組件包括 TiDB、TiKV、PD 和 TiFlash，用於處理計算和存儲任務。外圍組件包括 BR 和 TiCDC 等，用於滿足備份、數據共享等業務場景的需求。這些組件可以單獨部署或混合部署，以滿足隔離性和資源利用率的平衡。
在銀行核心系統中，常見的部署模式是兩地三中心。通過混沌測試，可以在實際的部署架構下模擬各種故障場景，評估系統的高可用能力和災備接管能力。測試結果可以提供每個場景或多場景組合下的 RTO 和 RPO 指標，並幫助識別應用連接恢復的健壯性和透明性問題，以及發現可能存在的訪問鏈路瓶頸。
2.3 驗證系統的彈性
業務發展具有動態性，在突發的高流量高負載業務活動中，可能需要進行系統擴容以兼顧效率和穩定性。此外，X86 服務器相比小型機穩定性差、故障率高、生命週期短，需要通過擴縮容動作完成對硬件的升級和更換。基於這些因素，我們從兩個維度對擴展性進行評估：
- TiDB 的線性擴展能力：評估 TiDB 在擴容後能否保持性能的線性增長，滿足業務增長帶來的性能需求。
- 擴縮容調整的便捷性、透明性和對業務的影響：評估擴縮容操作是否簡單易行，對應用是否透明，對業務是否有影響以及影響程度。
2.4 檢驗應急預案有效性
利用混沌測試中涉及的破壞性測試場景，對應急預案進行全面的檢驗和優化，爲上線後的運行維護做好充分準備。
2.5 優化監控和告警機制
利用混沌測試，可以有效檢驗告警系統的有效性和準確性，並對告警進行全面的查漏補缺和優化。通過測試驗證和持續優化，確保告警及時、準確、等級合理、避免過度冗餘。
2.6 準確評估外圍作業的影響
生產業務系統涉及數據庫備份、統計信息收集、TiCDC 數據同步等外圍作業，以及版本/補丁升級、重啓、擴縮容、硬件替換、容災切換等運維作業。混沌測試應關注此類作業對系統負載、業務指標、網絡流量等方面的影響，並優化相關的作業窗口和併發度，確保業務平穩運行。
混沌測試工具
我們以某商業銀行核心場景爲例，使用 Chaosd 工具來進行混沌測試的場景設計和演練。Chaosd 組件 ( https://chaos-mesh.org/zh/docs/chaosd-overview/ ) 是 Chaos Mesh ( https://chaos-mesh.org/zh/ ) 提供的一款混沌工程測試工具（需要單獨下載和部署 ( https://chaos-mesh.org/zh/docs/chaosd-overview/#下載和部署 )），用於在物理機環境上注入故障，並提供故障恢復功能。
Chaos Mesh 是 PingCAP 自主研發的開源雲原生混沌工程平臺，提供豐富的故障模擬類型，具有強大的故障場景編排能力，方便用戶在開發測試中以及生產環境中模擬現實世界中可能出現的各類異常，幫助用戶發現系統潛在問題。
Chaosd 具有以下核心優勢：
- 易用性強：輸入簡單的 Chaosd 命令即可創建混沌實驗，並對實驗進行管理。
- 故障類型豐富：在物理機的不同層次、不同類型上都提供了故障注入的功能，包括進程、網絡、壓力、磁盤、主機等，且更多的功能在不斷擴展中。
- 支持多種模式：Chaosd 既可作爲命令行工具使用，也可以作爲服務使用，滿足不同場景的使用需求。
Chaosd 提供完善的可視化操作，旨在降低用戶進行混沌工程的門檻。用戶可以方便地在 Web UI 界面上設計自己的混沌場景，以及監控混沌實驗的運行狀態。你可以使用 Chaosd 模擬以下故障類型：
- 進程：對進程進行故障注入，支持進程的 kill、stop 等操作。
- 網絡：對物理機的網絡進行故障注入，支持增加網絡延遲、丟包、損壞包等操作。
- 壓力：對物理機的 CPU 或內存注入壓力。
- 磁盤：對物理機的磁盤進行故障注入，支持增加讀寫磁盤負載、填充磁盤等操作。
- 主機：對物理機本身進行故障注入，支持關機等操作。
對於每種故障類型的詳細介紹和使用方式，請參考對應的說明文檔 Chaosd 組件簡介 | Chaos Mesh ( https://chaos-mesh.org/zh/docs/chaosd-overview/ )。
混沌測試場景設計
混沌測試場景設計的原則是儘可能的模擬真實的生產情況。爲了最大程度地模擬真實環境，測試的目標環境推薦使用準生產環境或按照生產環境設計要求搭建 1:1 仿真測試環境，並確保環境配置、部署架構、數據容量和業務負載等方面與預估上線後或系統設計要求一致。
測試從業務壓力、故障注入、外圍作業和運維操作等多個維度進行全方位測試，包括但不限於：
- 模擬真實的用戶訪問量和業務負載，以評估系統在高併發情況下的性能和穩定性。
- 注入各種硬件故障、軟件故障和網絡故障，以評估系統的故障處理能力和快速恢復能力。
- 模擬數據同步、備份作業等相關外圍作業對資源使用的影響和 SQL 時延的影響。
- 模擬運維人員的日常操作，以評估系統的易用性和可維護性。
4.1 業務壓力
交易型業務壓力
混沌測試建議採用真實業務模型，通過等比例的業務流量進行壓測，或者有條件的採用流量回放（ 生產環境流量需嚴格遵循安全管控流程，僅適用於生產域，且需進行脫敏處理 ）的形式進行。對於項目前期無法基於真實業務模型進行壓力模擬的情況，可以選擇部分較爲核心（或簡化）的業務模型進行壓力模擬。
如果上述條件均不具備，也可採用 sysbench 進行壓力注入。由於 sysbench 與真實業務模型存在較大差異，對性能邊界的評估意義有限，但基本不影響對高可用、容災能力、擴展性、檢驗和優化監控告警等其他方面的驗證結果。
對於注入壓力的大小，建議按梯隊逐層加壓展開：
- 生產（預估）TPS 指標
- 總設要求的 TPS 指標
- 總設要求的 TPS 指標 * N 倍 （1.5、2、3 ....，截止滿足業務時延下的最高壓力）
- 滿足業務時延下的最高壓力
- 基礎環境負載打滿的壓力
以上幾個梯隊可以按需進行，兼顧測試成本，不建議過度細分壓力場景 。
對每個壓力場景，記錄各項基礎環境和數據庫實例級別的資源使用率、數據庫 QPS/TPS、數據庫 SQL 時延、端到端的業務時延、業務 TPS 等關鍵信息，建議將當時的壓測場景結合關鍵的監控信息進行存檔。以下登記表供參考（爲方便展現，部分信息項簡化合並)：
批量業務壓力
銀行核心業務中的日終、日切、日結、報表等批量類業務，併發量大，負載高，需按照真實的用戶量和總設要求的承載用戶量分別進行壓力測試。除了根據用戶量維度施加壓力外，還需關注此類業務的併發度、作業編排等方面，以探索最佳的業務實踐。
長穩壓測
長穩壓測建議以交易型業務壓力爲主（總設要求的 TPS 指標壓力），結合實際情況週期性注入批量業務壓力，開展 7*24 小時長穩壓測，全面驗證系統整體的可靠性和穩定性。此外，長穩壓測還可以有效發現一些容易被忽略的潛在問題，例如基礎硬件的質量問題、配置是否合理、全鏈路中的脆弱點和性能瓶頸等。
其他場景
按需根據實際的業務特點擴展測試場景，針對性地進行驗證。例如測試表數據量增長對 SQL 響應時延的影響：
- 根據實際表結構進行數據量增長壓測，模擬從百萬級到十億級數據量（甚至更多，兼顧測試成本按需進行即可，無需過度放大）的變化。
- 在同等業務壓力下，使用實際的業務 SQL 測試響應時延、QPS、TPS 指標的變化。
4.2 故障注入
針對 TiDB 的故障注入測試可以從實際部署架構和故障面積兩個維度進行設計，本文以同城雙機房雙活的 DR Auto-Sync 架構 ( https://docs.pingcap.com/zh/tidb/stable/two-data-centers-in-one-city-deployment#單區域雙-az-部署-tidb ) （即 Data Replication Auto Synchronous，簡稱 DR Auto-Sync）進行介紹，其他部署架構的故障注入測試用例設計思路與此類似。故障注入和恢復後，需要關注的事項有：
- 對於業務量、QPS、TPS 的影響比例和持續時間
- 業務端到端的時延變化和持續時間
- SQL 的時延變化和持續時間
- 存活節點的資源使用變化
- 集羣自身的負載均衡能力（如 leader 重新選舉）
- 應用連接池重連能力（注意關注並優化連接池配置、負載探活配置）
以下故障注入跟蹤表供參考（爲方便展現，部分信息項簡化合並)：
建議採用分級故障注入策略，實例級故障注入時需要根據不同的實例角色進行，服務器級故障注入時需要結合部署架構（尤其是存在混合部署情況下）進行。
4.3 外圍作業
外圍作業注入應關注相關作業對資源使用和 SQL 延遲的影響，並結合生產實際業務週期性變化的情況，優化作業窗口和併發度等配置。主要的外圍作業包括全量物理備份、全量邏輯備份、BR log 備份（常駐作業）、統計信息收集和 TiCDC 數據同步（常駐作業）等。
4.4 運維操作
運維操作注入是模擬真實運維操作對 TiDB 系統的影響，需要關注的事項與故障注入一致，部分運維操作場景和故障注入場景可能存在重疊，主要包括的場景有：滾動重啓、 擴容（關注線性擴展比、對應用的透明度） 、縮容、補丁/版本升級、在線 DDL（增、刪、修改字段、創建索引）和容災切換等。其中，容災切換需要模擬各類場景進行重點測試，如測試系統在計劃內切換（主備機房不停機）和計劃外切換（主備機房完全失聯）場景下的表現。
4.5 DR Auto-Sync 專項場景
DR Auto-Sync 架構 ( https://docs.pingcap.com/zh/tidb/stable/two-data-centers-in-one-city-deployment#單區域雙-az-部署-tidb ) 適用於同城雙機房 RPO=0 的高可用容災架構 （本系列後續文章將進行詳細介紹，敬請關注）
該方案在同一區域部署兩個 AZ (**Availability Zone, AZ)，以滿足高可用和容災要求，且成本更低** 。下圖爲集羣部署架構圖：
- 集羣採用推薦的 6 副本模式，其中 AZ1 中放 3 個 Voter，AZ2 中放 2 個 Follower 副本和 1 個 Learner 副本。TiKV 按機房的實際情況打上合適的 Label。
- 副本間通過 Raft 協議保證數據的一致性和高可用，對用戶完全透明。
該部署方案定義了三種狀態來控制和標示集羣的同步狀態，該狀態約束了 TiKV 的同步方式。集羣的複製模式可以自動在三種狀態之間自適應切換。
- sync：同步複製模式，此時從 AZ (DR) 至少有一個副本與主 AZ (PRIMARY) 進行同步，Raft 算法保證每條日誌按 Label 同步複製到 DR。
- async：異步複製模式，此時不保證 DR 與 PRIMARY 完全同步，Raft 算法使用經典的 majority 方式複製日誌。
- sync-recover：恢復同步，此時不保證 DR 與 PRIMARY 完全同步，Raft 逐步切換成 Label 複製，切換成功後彙報給 PD。
針對應用雙機房部署的情況，通過混沌測試的場景設計，來驗證 TiKV 和 PD leader 的最佳放置位置以及流量分發的最優鏈路，以期實現最佳的性能。如圖所示，根據業務流量訪問和數據 Leader 分佈分別在單、雙中心的四種場景組合進行測試，從而找到最佳方案。
混沌測試的收益和實戰舉例
5.1 掌握能力邊界
混沌測試能夠幫助我們全面瞭解系統的能力邊界，爲業務上線及後續的運維提供重要的參考依據， 具體包括：獲得當前配置和部 署下數據庫最高可承載的業務量，爲容量規劃提供指導；評估數據庫的擴展能力，爲未來的擴容提供指導；模擬各類故障對數據庫服務能力的影響，進而驗證和優化應急預案設計；模擬各類運維操作對數據庫服務能力的影響，從而指導變更流程設計；模擬單表數據快速增長，評估對數據庫性能的影響，並採取相應的優化措施。
實測結 果舉例：
- 系統彈性能力評估：
- 在線擴容、操作簡單，對應用、對錶物理模型完全透明。
- 容量、性能線性擴展比超過 90%。
- 單表數據量增長對 SQL 時延影響場景：
銀行核心業務中，部分業務表（如交易流水錶）數據量會隨着業務辦理而急劇增長，並需在生產集羣中保留一定時間（超過一定週期轉移到近線庫，超過在線查詢週期轉移到帶庫存儲）。這類表通常體積較大，銀行客戶基於對集中式數據庫的使用經驗，會擔心單表數據量增長對性能產生影響。
爲此，我們通過測試進行了驗證。測試結果表明，單表數據（實測多張相關聯業務表等比例增長）從百萬級到 10 億 急速增長的情況下，相關業務的 SQL 時延幾乎不受影響，打消了客戶的疑慮。如下圖所示，短時間內少量業務流水錶數據量急劇增長，相關業務 SQL 時延非常穩定，無明顯變化。
5.2 獲得最佳實踐
混沌測試可以幫助我們發現系統全鏈路中的瓶頸點，從而進行鍼對性的優化，實現最佳實踐。通過混沌測試，我們可以識別數據庫部署架構和配置、負載均衡和探活配置、應用連接池和探活配置、雙活架構下的數據庫配置和流量分發、各類外圍作業的時間窗口和併發度配置等方面存在的潛在問題，並進行相應的優化，例如調整數據庫參數、調整流量分發規則、優化導入導出作業的併發度等。
實測結果舉例:
- Label 標籤和服務器物理位置結合可以增強高可用能力：
- 以 5 副本架構爲例，最多可以同時容忍兩個 Label 標籤下的服務器掉線
- 結合服務器物理位置規劃，即可以同時容忍兩組機櫃下的服務器掉線
- 在“DR Auto-Sync 架構 + 應用雙活部署”專項場景中我們得出的最佳實踐：
- TiKV Leader 、PD Leader 指定在主機房
- 主、備機房負載均衡分別訪問本機房 TiDB-Server
- 主、備機房流量按照 9:1 分發分發到本機房負載
5.3 提升高可用能力和優化應急預案
混沌測試能夠幫助我們全面瞭解數據庫在不同故障情況下服務能力的變化，從而檢驗應急預案的有效性，並針對性地進行優化。
實測結果舉例:
- 單點的離線類（實例和服務器級的異常 Crash ）故障對 TiDB 數據庫服務整體影響面小或者時間短，且可以自愈，基本不需要應急預案。
- 單點離線類故障針對不同組件的影響程度從大到小排序：PD-Server (Leader) > TiDB-Server > TiKV-Server (主機房) ；其他，不影響在線服務，無感知。
- 部署架構和 Label 配置結合物理位置設計情況下，機櫃級故障約等同於單點故障 （因涉及實例多，影響面積略大，持續時間略久），可自愈，且基本不需要應急預案。
- 單點的能力惡化類故障（服務器夯 / 實例夯 / IO 時延 / 網絡時延等）對 TiDB 數據庫服務影響較大，不可自愈，自愈方式可採用強制隔離下線或重啓方式，這也符合分佈式數據庫 Fast-Fail 的應急思路。
- 跨機房網絡能力下降（非中斷），對 TiDB 數據庫的 DR Auto-Sync 架構的服務影響較大，不可自愈，需要應急預案（如將 Sync 模式降級爲 Majority 模式 ）。
- 機房級中斷類故障分爲兩種情況：
- 同城 (從) 機房離線（同城網絡中斷、批量宕機失聯等）會導致 TiDB 服務中斷，RPO=0，RTO 時間受服務降級參數影響 (通常設置 10s-30s)，可自愈，不需要應急預案。
- 主機房離線（主機房網絡中斷，批量宕機失聯等）會導致 TiDB 服務中斷，可以保證 RPO=0，需要計劃外容災切換的應急預案。
這裏的 “應急預案”僅指故障場景中滿足 SLA 情況下的應急，不包括集羣整體健壯性或健康度的修復。
若兼顧健壯性或健康度的修復，還需要關注的事項：
- 存活節點的資源使用率和負載均衡情況；
- 基礎環境或硬件故障不可恢復情況，事後需要通過擴容、配置調整等手段補齊高可用能力。
常見的故障場景對於 TiDB 數據庫服務的影響（下表中的 MTTR、業務影響比例受集羣部署架構、故障實例個數、集羣規模、業務負載特徵、負載均衡探活策略等因素影響）：
5.4 優化監控告警機制
混沌測試可以幫助我們檢驗和優化監控告警，確保監控告警能夠及時、有效地發現和識別系統故障。以下是一些對監控告警設置的建議：
- 確保告警覆蓋所有的關鍵指標和組件，設置合理的探測頻率。
- 設置適度的冗餘，保證根因可以通過告警直接發現，提升告警的可靠性。
- 區別於集中式數據庫，TiDB 作爲原生分佈式數據庫具有原生高可用、高併發等特點，設置告警規則時需要考慮這些特點，避免簡單的套用集中式數據庫的告警思維。
- 建議以分類法進行告警梳理，確保告警覆蓋面，可參考的分類維度有：運行狀態類、黃金指標類、資源使用類、閾值類（結合配置參數）、日誌和報錯類、開發規範管控類（如慢 SQL / 全表掃描 SQL / 非規範語法）等。
過去一年，PingCAP 在金融行業場景累計完成數千個混沌演練測試，發現近百個問題。展望未來，PingCAP 將持續深耕金融行業，積極探索混沌工程在分佈式數據庫領域的應用，通過不斷豐富的故障場景，結合故障診斷、根因分析等技術手段，做好故障沉澱積累，穩步提升 TiDB 處理異常事故及極端場景的應變能力，爲金融業務穩健運行提供有力保障。