我們一起聊聊業務定制型異地多活架構設計
大道至簡
圖片
左圖展示了一個強調一致性（C）和分區容忍性（P）的系統。在這種系統中，當網絡分區（Partition）發生錯誤時，系統可能會拒絕操作以保持數據的一致性，犧牲了一部分可用性。例如，如果節點N1和N2無法通信（分區容忍性問題），系統可能會選擇停止操作，確保任何讀取都是一致的，即使這意味著某些操作不能完成。
右圖展示的是一個強調可用性（A）和分區容忍性（P）的系統。在這種系統中，即使發生了分區錯誤，每個節點（N1和N2）仍會盡力響應用戶的請求，保證服務的可用性。這可能導致數據的不一致，因為兩個分區可能會獨立響應并導致數據狀態不同步。
異地多活架構設計的本質是平衡CAP定理中的“可用性（A）”和“分區容忍性（P）”，而通常在必要的情況下對“一致性（C）”做出一定程度的妥協。
大道至深 - CAP
粒度：
CAP 關注的粒度是數據，而不是系統，需要根據不同業務的數據特點來設計
異地多活。
延遲：
CAP 是忽略網絡延遲的 ，但工程落地不可能做到零延遲。
分區容忍：
C和A只能取1個是在發生分區的時候，正常運行情況下，可以同時滿足 CA。
補救：
放棄 != 無為，需要為分區恢復后做準備，包括人工修復數據。
原則1 - 只保證核心業務
圖片
不同業務的數據特性不同，無法全部做到異地多活。
原則2 - 只能做到最終一致性
圖片
復制肯定有時間窗，拋棄實時一致性的幻想
原則3 - 只能保證絕大部分用戶
圖片
異地多活設計步驟
1.業務分級：
將業務按照某個維度進行優先級排序，優先保證TOP3 業務異地多活。
2.數據分類：
分析 TOP3 中的每個業務的關鍵數據特點，將數據分類。
3.數據同步
針對不同的數據分類設計不同的數據同步方式。
4.異常處理
針對極端異常的情況，考慮如何處理，可以是技術手段或非技術手段。
步驟1 – 業務分級
訪問量：
登錄 > 注冊 > 修改密碼
核心場景：
聊天 > 朋友圈 > 搖一搖
收入來源：
訂單 > 搜索 > 編輯
步驟2 – 數據分類
數據的修改量：
數據被修改的數量和頻率，包括新增、刪除、修改。
一致性：
數據的一致性要求，例如：強一致性（余額、庫存）、最終一致性（動態、興趣）。
唯一性：
數據的唯一性要求，例如：全局唯一（用戶 ID）、可重復（昵稱）
可丟失性：
數據是否可丟失，例如：不可丟失（賬戶余額）、可丟失（微博、密碼）。
可恢復性：
數據是否可恢復，例如：用戶恢復（微博）、系統提供恢復（密碼找回）、內部恢復（例如編輯和運營重發）。
步驟3 – 數據同步
圖片
多管齊下，“不擇手段”，不要局限于存儲系統同步！
步驟3 – 數據同步技巧
步驟4 –異常處理
業務兼容：
體驗不好 優于 無法體驗。
1. 數據短時間不一致：業務有損，例如微博、朋友圈；
2. 數據無法獲取：轉賬申請，支付核對中。
事后補償：
少量用戶損失，用錢解決。
1. 禮包、紅包；
2. 禮物、物品（暴雪爐石回檔補償）；
3. 保險賠償。
人工修正：
盡力而為，減少損失。
1. 人工訂正數據，達到最終一致性；
2. 重要事情說三遍：日志、日志、日志。
5大技巧1 - 消息隊列同步
適合全局唯一的數據，因為可以覆蓋；不適合余額之類的數據，因為數據修改無法做到冪等性。
5大技巧2 - 庫存拆分
余額這么拆分可以嗎？
通常會有一個中央權威的賬戶管理系統來處理余額，而不是在各個數據中心分別處理。這樣可以簡化一致性和同步的復雜性，盡管這可能犧牲一些響應時間和可用性
5大技巧3 - 事務合并
圖片
例如：游戲玩家異地充值100，消費60，即使 IDC-B 的業務服務器不知道玩家的實際余額（在 IDC-A 的數據庫中），業務也是可以繼續處理的，具體實現邏輯如下：
1. 正常情況下通過數據庫同步來同步余額，對應上圖的 IDC-A 到 IDC-B 的“余額同步”；
2. 異常情況下，IDC-A 機房掛掉，余額同步中斷，可能會導致 IDC-A 和 IDC-B 的數據不同步，例如圖中兩個余額表的余額，IDC-A 是 30，IDC-B 是65；
3. 玩家到 IDC-B 想消費60塊，無論 IDC-B 的余額表中是大于還是小于60，都不能直接消費，因為無法判斷這個余額數據是否一致；
4. 玩家到 IDC-B 先充值100塊，再消費60塊，無論 IDC-B 的余額表中是大于還是小于60，都是允許的，此時 IDC-B 在臨時事務表中記錄兩個事務；
5. IDC-A 恢復后，IDC-B 將臨時事務表中的事務發給 IDC-A，IDC-A 進行合并，合并后的真實余額是70元，然后再通過“余額同步”這個通道將70元余額同步給 IDC-B 的余額表。
5大技巧4 - 實時改異步
圖片
5大技巧5 - 適當容忍
圖片
業務上稍微放開一些約束，例如：電話會議系統允許欠費也能發起會議。
總結：
圖片
