一，容災的要求#
1、服務品質協議（SLA，Service Level Agreement）的要求#
SLA 的要求一般是規定一定期限內需要恢復服務。SLA 的要求不能滿足的情況下，往往需要對客戶有相應金額的賠償或說明，其風險相對可控。
2、事務正確性的要求#
我們知道事務有 ACID 四個特性，分別是原子性（ Atomicity ）、一致性（ Consistency ）、隔離性（ Isolation ）和持續性（ Durability）。金融系統中，原子性的要求最為嚴苛，即事務包含的所有操作要麼全部成功，要麼全部失敗回滾。事務正確性要求一旦不能滿足，系統就會出現大的混亂，其風險相對較高。比如，在 ATM 取款的時候，顯示扣款成功，但 ATM 機突然斷電，來不及吐出現金，此時就要恢復到沒取錢時候的狀態。
容災的要求就是針對以上兩種的要求，需要結合成本，在 SLA 級別、事務正確性級別做一平衡。比如說，容災的要求不能滿足事務正確性的要求，僅僅保證 SLA 的要求，但其成本卻比 SLA 所需的賠償預算還要大，那麼這樣的容災其實是沒有意義的。這種情況下，用日常的利潤的一部分來作為容災的賠付基金即可以滿足需求。再比如說，有些金融業務，業務量小，客戶少，（但可能金額高），其 SLA 的要求較低，可以是幾天，甚至是幾個月。這種情況下，容災的成本就不能很高。
二，容災監控#
實現容災的前提是要先有監控。金融機構，尤其是銀行，往往用跨機房的容災監控來實現。
1，監控數據本地異步備份#
監控數據本地異步備份，跨機房的監控系統彼此之間互相監控。
2，監控實時和延時#
推（push）：業務系統主動地將業務指標推送給監控系統，比如心跳線，從而實現實時監控。這種做法實時性較強，但對資源的要求也較高。
拉（pull）：監控系統定期地從業務系統中拉取監控指標，比如愛數的日誌運維工具 AnyRobot，可以通過標準協議（比如 Syslog、SNMP、SSH、JDBC 等）從業務系統中拉取監控指標。
3，監控本身也會出錯#
監控發現錯誤的時候就會啟動容災，但是監控本身也會出錯，此時容災的時候要考慮監控的偽報問題。
三、容災處理#
1，服務容災處理#
有狀態和無狀態服務是兩種不同的服務架構，其判斷依據 —— 兩個來自相同發
起者的請求在服務器端是否具備上下文關係。
無狀態的服務則可以將請求發送到任意一台 server 上，然後就可以通過負載均衡等手段，實現水平擴展。比如說通過 cookie 保存 token 的方式傳輸請求數據。
來源：CSDN 博主「༺鯨落༻」的原創文章
原文鏈接：https://blog.csdn.net/nsx\_truth/article/details/108917851
而事務的處理就需要有狀態的服務，比如說電商的購物流程，從購物車 — 訂單填寫 — 付款等一系列操作。這種情況下可以使用 Session 來維護登錄用戶的上下文信息。雖然 http 協議是無狀態的，但是借助 Session，可以使 http 無狀態服務轉換為有狀態服務。
來源：CSDN 博主「༺鯨落༻」的原創文章
原文鏈接：https://blog.csdn.net/nsx\_truth/article/details/108917851
無狀態服務的容災相對簡單，本身服務的調度算法會將服務調度到不同的節點。有狀態服務的容災則是把服務節點按照數據節點處理。
2、數據容災處理#
1）單節點容災
單節點的數據寫入操作的過程可以分為：應用緩存 —OS 緩存 — 硬件控制器緩存 — 硬盤存儲。在這個過程中，出現斷電，都會導致寫入的失敗。目前解決方法有兩種：一是使用帶電池的硬盤來延緩斷電的時間，保證最終硬盤存儲全部完成。二是使用集群 + 負載均衡來保障業務的高可用。（這裡要注意集群即可，而非分佈式。兩者區別可參考：《分佈式與集群的區別與好處》）
2）多節點容災
在銀行的系統中，我們經常聽到兩地兩中心或者兩地三中心或者三地五中心的說法。不管是哪一種，都是利用了共識（consensus）算法，其中最著名的就是 Raft 共識算法。Raft 分主從節點，至少需要 2 個節點，如果只有一個節點了，那就談不上分佈式。Raft 的部署一般有 3 個備份節點或 5 個備份節點兩個選項，至少要求一半的節點以上在線才能正常工作。
先看兩地兩中心（3 個備份）的情況，即一個數據中心有 1 個節點，另一個數據中心有 2 個節點的情況。此時如果單個節點出現故障，由於另外 2 個節點可以正常工作，那麼是可以正常工作的。但是如果擁有 2 個節點的數據中心出現故障，由於只剩一個節點，無法滿足一半的節點在線，則整個系統無法正常工作。這種設計可以滿足單節點的容災，但不能滿足數據中心級的容災。
接下來看兩地三中心（3 個備份）的情況，即三個數據中心都有 1 個節點，其中兩個數據中心在一個城市。這種情況下，上述兩地兩中心的數據中心級別的故障如果發生的話，並不會影響工作，但是如果城市級別發生故障，比如說地鐵施工挖斷了城市光纖，那麼又會出現只剩一個節點，則整個系統無法正常工作。** 這種設計可以滿足數據中心級的容災，但不能滿足城市級的容災。** 兩地三中心這種架構是目前很多銀行正在使用的一種架構，因為國家針對銀行的災備能力做過要求，資產超過多少多少的一定要做兩地三中心架構，以保證銀行系統的穩定。但兩地三中心和雙活還是有一些區別，前者區分數據中心和災備中心的角色，後者災備中心也可以是數據中心，對技術要求比較高。
最後我們看三地五中心，即三個不同城市，建立 5 個節點。這種架構差不多是目前金融系統最高級別的容災架構了，可以滿足城市級的容災。螞蟻金服曾經就以此秀過一次。但是這種方案目前採用得很少，銀行一般到兩地三中心就差不多了，券商很多也就是雙活，根本沒有資源去建立龐大的多節點容災系統。
四、容災與災備#
容災和災備並不能簡單地劃等號，後者的範疇更大，包括備份和容災。不過，備份的目的仍然是為了容災，如果備份是成功的，但當系統發生故障，需要恢復的時候，通過備份恢復需要幾天的時間，即 RTO 過長，這個情況下的備份其實是沒有意義的。或者說數據量太多，每天的備份時間不夠，比如很多銀行的數據庫系統在一個晚上是備不完的，這樣就談不上容災，更不能說災備了。
我在之前寫過一篇《備份技術概述》，介紹了 CDP 備份和 CDM 備份。這兩種備份技術都可以較好地為容災服務。前者的 RTO 近乎為 0，後者的 RTO 也很短，而且可以實現雙活，有效地利用了備份數據，都是不錯的選擇方案。國內災備龍頭企業愛數的分級保護技術就是把定時備份、CDP 備份、CDM 備份同時應用在銀行的兩地三中心的災備上。
來源：愛數學院
參考文獻：#
任傑，《如何實現正確的跨機房實時容災》