異地多活設計4步走
阿新 • • 發佈：2022-01-16
極客時間：《從 0 開始學架構》:異地多活設計4步走
第 1 步：業務分級
按照一定的標準將業務進行分級，挑選出核心的業務，只為核心業務設計異地多活，降低方案整體複雜度和實現成本。
常見的分級標準有下面幾種：
- 訪問量大的業務
- 核心業務
- 產生大量收入的業務
第 2 步：資料分類
挑選出核心業務後，需要對核心業務相關的資料進一步分析，目的在於識別所有的資料及資料特徵，這些資料特徵會影響後面的方案設計。
常見的資料特徵分析維度有：
- 資料量
資料量包括總的資料量和新增、修改、刪除的量 - 唯一性
唯一性指資料是否要求多個異地機房產生的同類資料必須保證唯一 - 實時性
實時性指如果在 A 機房修改了資料，要求多長時間必須同步到 B 機房，實時性要求越高，對同步的要求越高，方案越複雜。 - 可丟失性
可丟失性指的是資料是否可以丟失。 - 可恢復性
可恢復性指資料丟失後，是否可以通過某種手段進行恢復，如果資料可以恢復，至少說明對業務的影響不會那麼大，這樣可以相應地降低異地多活架構設計的複雜度。
第 3 步：資料同步.
確定資料的特點後，我們可以根據不同的資料設計不同的同步方案。常見的資料同步方案有：
- 儲存系統同步
- 訊息佇列同步
採用獨立訊息佇列進行資料同步，常見的訊息佇列有 Kafka、ActiveMQ、RocketMQ 等。
訊息佇列同步適合無事務性或者無時序性要求的資料。 - 重複生成
資料不同步到異地機房，每個機房都可以生成資料，這個方案適合於可以重複生成的資料。例如，登入產生的 cookie、session 資料、快取資料等
第 4 步：異常處理
異常（如同步延遲、資料丟失、資料不一致等）處理就是假設在出現這些問題時，系統將採取什麼措施來應對。
異常處理主要有以下幾個目的：
- 問題發生時，避免少量資料異常導致整體業務不可用
- 問題恢復後，將異常的資料進行修正
- 對使用者進行安撫，彌補使用者損失。
常見的異常處理措施有這幾類：
- 多通道同步
多通道同步的含義是採取多種方式來進行資料同步，其中某條通道故障的情況下，系統可以通過其他方式來進行同步，這種方式可以應對同步通道處故障的情況。
多通道同步設計的方案關鍵點有：
- 一般情況下，採取兩通道即可，採取更多通道理論上能夠降低風險，但付出的成本也會增加很多。
- 資料庫同步通道和訊息佇列同步通道不能採用相同的網路連線，否則一旦網路故障，兩個通道都同時故障；可以一個走公網連線，一個走內網連線。
- 需要資料是可以重複覆蓋的，即無論哪個通道先到哪個通道後到，最終結果是一樣的。例如，新建賬號資料就符合這個標準，而密碼資料則不符合這個標準。
- 同步和訪問結合
訪問指異地機房通過系統的介面來進行資料訪問。
同步和訪問結合方案的設計關鍵點有：
- 介面訪問通道和資料庫同步通道不能採用相同的網路連線，不能讓資料庫同步和介面訪問都走同一條網路通道，可以採用介面訪問走公網連線，資料庫同步走內網連線這種方式。
- 資料有路由規則，可以根據資料來推斷應該訪問哪個機房的介面來讀取資料。例如，有 3 個機房 A、B、C，B 機房拿到一個不屬於 B 機房的資料後，需要根據路由規則判斷是訪問 A 機房介面，還是訪問 C 機房介面。
- 由於有同步通道，優先讀取本地資料，本地資料無法讀取到再通過介面去訪問，這樣可以大大降低跨機房的異地介面訪問數量，適合於實時性要求非常高的資料。
- 日誌記錄
日誌記錄主要用於使用者故障恢復後對資料進行恢復，其主要方式是每個關鍵操作前後都記錄相關一條日誌，然後將日誌儲存在一個獨立的地方，當故障恢復後，拿出日誌跟資料進行對比，對資料進行修復。
常見的日誌儲存方式有：
- 伺服器上儲存日誌，資料庫中儲存資料，這種方式可以應對單臺數據庫伺服器故障或者宕機的情況。
- 本地獨立系統儲存日誌，這種方式可以應對某業務伺服器和資料庫同時宕機的情況。
- 日誌異地儲存，這種方式可以應對機房宕機的情況。
- 使用者補償
無論採用什麼樣的異常處理措施，都只能最大限度地降低受到影響的範圍和程度，無法完全做到沒有任何影響。
PS：業務分級討論的時候，產品說 A 也很重要，因為影響使用者使用；B 也很重要，因為影響公司收入；C 也很重要，因為會導致客戶投訴……這種情況下我們該如何處理業務分級？
答：
業務分級我覺得得從如下方面來分析：
1.部門或者公司當期的發力點，如果著重新使用者的增長 我覺得順序應該是ACB，如果著重現有客戶滿意度，我覺得順序應該是CBA，如果看重看重收益，那B的優先順序最高
2.可通過預期貨幣價值分析，進行業務分級；大致維度如下：風險發生概率 風險損耗成本 技術改造陳本 技術改造時長（月） 改造後成本節省（月）