對於金融企業來說，尤其是銀行、證券、保險這些行業，在一個 IT 系統運行支撐業務的過程當中，考慮到硬件的故障、網絡的故障，等一切可能會對業務產生影響的突發故障。那麼，在過去漫長的 IT 發展的過程當中，大量的技術被應用在關於如何解決組件級的高可用，整個服務的容災和災備，包括如何保證整體業務的連續性。

在金融行業來說，數據庫作爲最核心的基礎組件之一，要求它能夠安全運行和保障數據安全，這是一個剛需。另外，數據庫服務本身的高可用，是我們實現整個對外數據服務連續性的最重要的基石。在這些基礎上，光有高可用還是不夠的，我們需要考慮到機房級的、數據中心級的、站點級的災難導致的對業務的影響。配套的容災技術，以及對應事件的方案，應運而生。在過去的二、三十年裏面，關於容災和技術的技術手段、軟件工具，包括各種各樣的方案、管理方法，在不斷的展現。

傳統數據庫支撐關鍵計算的高可用/容災方案短板

回到傳統的數據庫領域，在過去至少三四十年的時間裏，我們都是在使用集中式的數據庫，比如大家非常熟悉的 Oracle、DB2 包括曾經很輝煌的 Sybase、Informix 等等。這些數據庫都是以大家所熟知的“ IOE”的架構來實現數據服務的。

在這些技術體系下，在長期的技術發展過程當中，也有產生對應的高可用和容災的方案，比如說大家非常熟悉的 Oracle RAC，比如說我們在 DB2 上，經常會用到的 HACMP，還有曾經大名鼎鼎的 Veritas VCS，MC/SG，以及紅帽的 RHCS , Pacemaker/Corosync 等實現單機數據庫高可用的。

這些技術都是通過數據庫，建主從的實例，然後共享數據庫的數據文件，放在高端的數據的存儲上。這種集中架構的話，它總體是比較穩定的，但是隨着 IT 應用場景的不斷發展，到今天爲止，我們在考慮數據庫的時候，除了要考慮它的可靠性之外，還需要考慮它如何應對海量的數據處理，海量的併發請求。 那麼我們需要必須尋求擴展，而集中式的結構，它沒有辦法做橫向擴散。此外的話，這種傳統的數據庫的高可用方式，非常依賴於外部的組件，就是前面說的這些獨立的廠商提供的相關的高可用和容災組件。

進入到開源數據庫的階段，大家所熟知的 MySQL 和  PostgreSQL，它們也會有對應的高可用的解決方案，比如 MySQL 它最常見的就是通過它的 Binlog 複製建立起來主從隊，然後在數據庫之外，我們採取類似像 MHA 這樣的一個 SwitchManager 的工具，包括 PG 的話，它有 PAF、RepMgr、Ptroni 這樣的技術。

在這樣的技術場景中，其實在可用性和容災方面，還是有很多的問題， 比如說複製的時候的採用的異步複製，增強的半同步複製以及國內好多互聯網公司定製的 MySQL，PG 的同步方案，在多節點，跨地域容災災備場景中的一致性的問題，始終是一個很大的挑戰。特別是在容災的場景當中，超過 1000 公里以上的站點距離間隔，用上述複製的方式，用獨立的 SwitchManager 的故障切換機制，是不是能夠保證在千公里以上的容災的可靠性是很大一個疑問。

此外，主從複製的模式資源利用率比較低。 到現在爲止，我們還有在主從複製基礎上，再往前走一步，提高高可用性的一些保障機制，比如說大家都熟知的組同步，像 Codership 之前做的 Galera，像包括 MariaDB Galera Cluster 和 Percona XtraDB Cluster，都把 Galera 組件放在產品當中。包括現在 MySQL 新版本中的複製技術實現了組同步 MGR。但是這些方向又有它的問題，比如說它的性能損耗非常顯著，然後在多寫場景的衝突的處理複雜性，以及整個集羣的擴展規模，受到這樣的限制。

分佈式數據庫備份容災的挑戰

所以，從單機數據庫進入到分佈式數據庫的領域，問題的挑戰就更加大了。集中來看的話，就是比如說我們最常見的兩個傳統的分佈式的數據庫的架構：MySQL、PG 加上主從複製核心組件，再加一個高可用的外部組件實現 Failover/Switchover，然後再加分庫分表中間件。那麼這樣的方案，在傳統的分佈式架構當中，它的核心的可用性的技術限制和天花板沒有變化。它還是如前文所說的：主從複製加上一個數據庫外部組件實現 Failover/Switchover 。

然後，在分佈式數據庫架構裏，我們需要非常認真的去考慮，分佈式數據庫的伸縮能力和它怎麼樣去跟高可用及容災的要求達到平衡。甚至還要想怎麼樣再去做進一步的優化，這是比較困難和有挑戰的。

另外，在互聯網應用場景中， 訪問量和數據量非常的大，業務邏輯相對簡單。 但是在銀行、保險、證券等這樣的傳統關鍵金融場景當中，業務的邏輯是非常複雜的。針對於這樣的傳統高可用及災備容災方案，它與應用進行適配，往往要做一些面向應用的反向適配，應用還需要爲此進行調整與妥協。 比如說兩地三中心的場景當中，應用適配的難度更加大，所以改造過程當中的適配過程和反向適配的風險，也是一個經常讓金融行業的 IT 從業人員非常頭痛的一件事情。

最嚴峻的一個事情，當在這樣的傳統災備容災方案爲基底的一套系統在運行的過程當中，真的發生了非預期的重大故障和災難突發的時候，怎麼樣保證數據的嚴格安全，以及如何保證在故障發生以後，對於部分組件，對於機房級的災難，對於中心級的災難，在災難發生的時候，要保證對業務的最小影響，也就是我們經常聽到的，RPO 和 RTO 這樣的要求。那麼在這個過程當中，怎麼樣最大程度減少人工的干預？因爲， 在災難發生的時候，人的干預是必須的，但是人的反應也是比較遲鈍的。所以，怎麼樣通過一個技術手段，在整個方案的能力上，能夠去高效執行災難恢復的處理工作？

TiDB 的金融級備份及容災之道

TiDB 經常這麼多年的積累和逐漸完善，在整個分佈式數據庫的容災和災備的領域，我們達到了金融生產級的要求。那麼在整個 TiDB 的備份與災備、容災的體系裏，我們主要是由以下幾個方面來組成的。

第一個是我們默認的，也是我們推薦的，多中心的容災方案，同城的兩中心，異地的一中心，或者擴展到三地五中心模式。 這個方案也是 TiDB 最早原生的核心方案。通過多級標籤的感知，能夠實現服務器級、機架級、機房級、站點級的故障轉移。能達到 RPO 等於 0，以及我們的故障影響時間小於 30 秒，也就是 RTO 小於 30 秒的一個剛性指標。

這一套方案，目前我們在國內和國外，已經有了不少用戶，尤其是金融行業的用戶，在關鍵場景投產使用了。這其中也是經受過了很多的考驗，比如說，同城光纖的抖動，同城到異地之間的通訊線路出現問題，以及機房裏面多個節點同時出現了故障，隨着在生產環境上持續運行時間的變長，這些問題都暴露出來了。通過 TiDB 的多中心的容災方案，非常可靠地避免了這些故障對業務的影響，保障了業務連續性及數據安全。

除此之外，在國內的話，從北到南，我們的運營商的線路也是非常的複雜。對於有些用戶來說，從投資成本、業務的重要性、客戶網絡的物理條件來說，沒有辦法去構成同城多中心加異地的的容災架構，他可能只能選擇兩中心的方案，那麼在這個過程當中的話，TiDB 經過這幾年對這個方面的積累，我們現在已經有了 兩中心的容災方案 ，並且，在這個方案裏面，我們有多種配置來適應不同的網絡條件。即便是在兩中心方案當中，我們也能達到 RPO 等於 0 的保護模式。當然也有一些用戶的場景，他的網絡線路可能延遲非常高，且用戶要求有一個託底的容災方案，同時對於數據的一致性可以有略微的放鬆和讓步，在這個過程當中， 我們也會通過配置來爲其提供異步同步的模式，來幫助其實現託底的容災方案，最大程度保障服務的連續性和數據安全。

以上是我們交付給用戶的多種金融生產級的災備容災的方案，它背後的支撐是由核心的 TiDB 的 Multi Raft 的高可用機制 ，以及一系列針對跨中心的調度、數據的調度管理、故障的自動轉移判斷等這一整套後臺的保障技術機制來實現的。

另外，對於數據業務來說，除了在線的熱的故障轉移、切換等。我們對於數據庫的數據本身，也提供了完善的數據備份方案，除了全量的備份、增量、恢復時間點 (PITR ) 之外， 我們在數據的備份模式上面，也提供了包括基於日誌的傳統邏輯備份。並且，在去年我們也推出了 TiDB BR 工具和備份方案，直接從數據庫的 TiDB 存儲引擎 TiKV 層上，直接實現備份和恢復，備份與恢復非常高的效率。

但光有上述方案是不不夠的，PingCAP 對於自身產品的要求是非常嚴格的，既然是要達到金融生產級的要求，除了要有對應的技術方案、對應的技術實現之外，必須爲產品本身提供專業的分佈式測試的體系和手段。每一個 TiDB 的版本，在我們的內部，都會通過極其嚴格及複雜的分佈式數據庫測試。爲此，我們也專門根據混沌工程，設計開發了自己的一套測試平臺，並且在最近把它開源了，這套工具叫做 Chaos Mesh:registered: ，可以幫助用戶更好的檢測分佈式系統的可用性和魯棒性。

在 TiDB 內部測試的整條鏈路上，我們有非常完善的對於可靠性和一致性和安全方面的測試保障。包括自動化故障注入，包括我們引入的 Jepsen 的一致性驗證，包括我們對於一些最核心的算法，引入了 TLA+ 的驗證。還有我們每天在數據中心，在我們測試環境，不停跑的自動化模擬的業務負載以及各種各樣的集成測試。我們相信只要是人寫出來的軟件，一定是會有問題的，一定會有 Bug，不可能做到完全沒有問題。 所以，在這個過程當中，需要的保障手段，除了高可用和軟件架構本身設計的機制之外，先進的、完善的、強大的產品測試體系和可靠性 驗證能力，也是最重要的保障手段之一。

TiDB 災備與容災的核心機制

TiDB 容災的核心機制是我們的 Raft ，相信各位關注 TiDB 的朋友也通過我們的公衆號、官網，包括社區裏面，聽到過小夥伴們提供的分享。Raft 是基於日誌與狀態機的一種一致性的算法。我們基於它，在 TiDB 裏實現了 Multi Raft 的機制。它能夠非常可靠的管理我們的數據與數據的副本，在 TiDB 裏面，整個數據對我們的業務來說是自動的透明打散的，然後它會以一個一個 Region 的數據組織方式，在不同的存儲節點上面進行自動存儲和建立 Raft 副本。

通過 Multi Raft 這樣的一個機制，我們可以在不同的主機，不同的機房，不同的園區，一套數據庫不同的節點上，產生它的第二、第三副本，甚至更多的副本。這個副本是動態可調的，並且我們可以保證，TiDB 上執行的所有的聯機交易事務，在數據變更發生時都可以達到多數的一致， 也就是說在一個實施規劃和部署正確的 TiDB 集羣裏面，在一個多中心的災備容災 TiDB 集羣中，任何的主機，所在的機架、機房，乃至數據中心的失效，包括數據中心間的網絡故障，通過 Multi Raft 機制以及 TiDB 的高可用調度機制，都可以完善的去保障，對我們的業務影響最小，同時，非常嚴格的保證了數據的絕對安全。

在 Raft 這個機制上，TiDB 的研發團隊也做了大量的優化工作。比如說跨數據中心，包括跨區域的運維方式。另外，我們在 Raft 機制上面，也提供了很多的比如說新的一些增強化，像 Lazy Peer、像 Learner、像 Joint consensus 等機制的研發。

TiDB 高性能分佈式備份機制

剛剛我還提到一個叫 TiDB BR 的工具，它是一個在存儲層實現高性能分佈式數據備份恢復的工具。所以，大家由下圖可以看到，我們的測試中的備份速度、恢復速度，都是非常驚人的。而且隨着節點數量的增加，在數據量一定的前提下，備份/恢復的性能都會有接近線性的增長：

最強的多中心：TiDB 多中心多活容災方案

在多中心裏面，前面提到，我們通過 Multi Raft 的機制，以及相關的工程優化，實現了跨中心的容災方案。比如說，對於長距離的異地中心，我們在同城設了兩個中心，通過光纖連接，異地的話，通常租用比如運營商的 MSTP 類型的線路，構成一個三中心的結構，通過 TiDB 內置的容災和災備的相關的一系列的機制與手段，可以構建出非常強健的容災的架構。 任何中心級失效，都會由另外兩個中心來立刻進行故障的轉移，以及對外繼續提供正常的數據庫服務。

安全的兩中心：TiDB 兩中心容災方案

前面也提到，有些用戶的網絡，比如說一箇中心在上海，一個在北京，延遲是非常大。因爲高等級、低延遲線路的租用使用成本非常高。綜合考慮成本及所需要保護的業務的關鍵性等級，不少用戶會做一個權衡。部分用戶最終希望核心數據庫，只需要完成一個主從站點的容災和災備就可以了。

通過 TiDB Binlog 模式能夠去適配和滿足對多中心網絡通信成本敏感且對服務/數據防護能力略低的容災需求的用戶，我們會用兩中心的 TiDB  Binlog based 方案 ，它是異步同步模式，能夠適配兩個中心長距離間隔其網絡延遲較大，比如延遲大於 30~40 毫秒的。採納這樣方案的用戶對於 RPO 的要求就比較寬鬆了，該模式是一個異步同步，當災難發生的時候，我們已經在 TiDB 的工程優化上儘可能通過多種機制來減少數據丟失的可能，但是從根本上來說，還是會存在一定數據丟失的情況。 該方案提供給用戶低成本的保障能力，同時還提供了比較靈活的可選拓撲，比如雙向的環形複製等。

也有用戶希望在兩中心的方案裏，需要有一個強一致保障的方案。所以我們研發了兩中心的 Raft based 容災方案 ，它可以在同城或者接近同城距離的兩中心環境中，且中心間網絡條件比較好的情況下，實現嚴格的強一致同步。 這個方案可以達到 RPO 等於 0 的保障要求，也就是數據不丟失前提下的一個高等級的容災要求。

結語

最後，我們一直持續在花非常多的精力和投入，研究如何讓 TiDB 變得更強，更安全，更可靠。能夠達到更好的金融級的數據服務的支撐能力水平，依託於我們整個工程研發團隊、 QA 測試團隊，以及我們所打造和擁有的強大的測試體系、TiDB 產品的容災災備一系列高可用及災備容災機制，我們能夠爲銀行、保險、證券等金融客戶提供完善的、可靠的、放心的、金融級的分佈式數據庫服務。