大道至簡

圖片

左圖展示了一個強調一致性（C）和分區(qū)容忍性（P）的系統(tǒng)。在這種系統(tǒng)中，當網(wǎng)絡分區(qū)（Partition）發(fā)生錯誤時，系統(tǒng)可能會拒絕操作以保持數(shù)據(jù)的一致性，犧牲了一部分可用性。例如，如果節(jié)點N1和N2無法通信（分區(qū)容忍性問題），系統(tǒng)可能會選擇停止操作，確保任何讀取都是一致的，即使這意味著某些操作不能完成。

右圖展示的是一個強調可用性（A）和分區(qū)容忍性（P）的系統(tǒng)。在這種系統(tǒng)中，即使發(fā)生了分區(qū)錯誤，每個節(jié)點（N1和N2）仍會盡力響應用戶的請求，保證服務的可用性。這可能導致數(shù)據(jù)的不一致，因為兩個分區(qū)可能會獨立響應并導致數(shù)據(jù)狀態(tài)不同步。

異地多活架構設計的本質是平衡CAP定理中的“可用性（A）”和“分區(qū)容忍性（P）”，而通常在必要的情況下對“一致性（C）”做出一定程度的妥協(xié)。

大道至深 - CAP

粒度：

CAP 關注的粒度是數(shù)據(jù)，而不是系統(tǒng)，需要根據(jù)不同業(yè)務的數(shù)據(jù)特點來設計

異地多活。

延遲：

CAP 是忽略網(wǎng)絡延遲的 ，但工程落地不可能做到零延遲。

分區(qū)容忍：

C和A只能取1個是在發(fā)生分區(qū)的時候，正常運行情況下，可以同時滿足 CA。

補救：

放棄 != 無為，需要為分區(qū)恢復后做準備，包括人工修復數(shù)據(jù)。

原則1 - 只保證核心業(yè)務

圖片

不同業(yè)務的數(shù)據(jù)特性不同，無法全部做到異地多活。

原則2 - 只能做到最終一致性

圖片

復制肯定有時間窗，拋棄實時一致性的幻想

原則3 - 只能保證絕大部分用戶

圖片

異地多活設計步驟

1.業(yè)務分級：

將業(yè)務按照某個維度進行優(yōu)先級排序，優(yōu)先保證TOP3 業(yè)務異地多活。

2.數(shù)據(jù)分類：

分析 TOP3 中的每個業(yè)務的關鍵數(shù)據(jù)特點，將數(shù)據(jù)分類。

3.數(shù)據(jù)同步

針對不同的數(shù)據(jù)分類設計不同的數(shù)據(jù)同步方式。

4.異常處理

針對極端異常的情況，考慮如何處理，可以是技術手段或非技術手段。

步驟1 – 業(yè)務分級

訪問量：

登錄 > 注冊 > 修改密碼

核心場景：

聊天 > 朋友圈 > 搖一搖

收入來源：

訂單 > 搜索 > 編輯

步驟2 – 數(shù)據(jù)分類

數(shù)據(jù)的修改量：

數(shù)據(jù)被修改的數(shù)量和頻率，包括新增、刪除、修改。

一致性：

數(shù)據(jù)的一致性要求，例如：強一致性（余額、庫存）、最終一致性（動態(tài)、興趣）。

唯一性：

數(shù)據(jù)的唯一性要求，例如：全局唯一（用戶 ID）、可重復（昵稱）

可丟失性：

數(shù)據(jù)是否可丟失，例如：不可丟失（賬戶余額）、可丟失（微博、密碼）。

可恢復性：

數(shù)據(jù)是否可恢復，例如：用戶恢復（微博）、系統(tǒng)提供恢復（密碼找回）、內部恢復（例如編輯和運營重發(fā)）。

步驟3 – 數(shù)據(jù)同步

圖片

多管齊下，“不擇手段”，不要局限于存儲系統(tǒng)同步！

步驟3 – 數(shù)據(jù)同步技巧

步驟4 –異常處理

業(yè)務兼容：

體驗不好 優(yōu)于 無法體驗。

1. 數(shù)據(jù)短時間不一致：業(yè)務有損，例如微博、朋友圈；

2. 數(shù)據(jù)無法獲取：轉賬申請，支付核對中。

事后補償：

少量用戶損失，用錢解決。

1. 禮包、紅包；

2. 禮物、物品（暴雪爐石回檔補償）；

3. 保險賠償。

人工修正：

盡力而為，減少損失。

1. 人工訂正數(shù)據(jù)，達到最終一致性；

2. 重要事情說三遍：日志、日志、日志。

5大技巧1 - 消息隊列同步

適合全局唯一的數(shù)據(jù)，因為可以覆蓋；不適合余額之類的數(shù)據(jù)，因為數(shù)據(jù)修改無法做到冪等性。

5大技巧2 - 庫存拆分

余額這么拆分可以嗎？

通常會有一個中央權威的賬戶管理系統(tǒng)來處理余額，而不是在各個數(shù)據(jù)中心分別處理。這樣可以簡化一致性和同步的復雜性，盡管這可能犧牲一些響應時間和可用性

5大技巧3 - 事務合并

圖片

例如：游戲玩家異地充值100，消費60，即使 IDC-B 的業(yè)務服務器不知道玩家的實際余額（在 IDC-A 的數(shù)據(jù)庫中），業(yè)務也是可以繼續(xù)處理的，具體實現(xiàn)邏輯如下：

1. 正常情況下通過數(shù)據(jù)庫同步來同步余額，對應上圖的 IDC-A 到 IDC-B 的“余額同步”；

2. 異常情況下，IDC-A 機房掛掉，余額同步中斷，可能會導致 IDC-A 和 IDC-B 的數(shù)據(jù)不同步，例如圖中兩個余額表的余額，IDC-A 是 30，IDC-B 是65；

3. 玩家到 IDC-B 想消費60塊，無論 IDC-B 的余額表中是大于還是小于60，都不能直接消費，因為無法判斷這個余額數(shù)據(jù)是否一致；

4. 玩家到 IDC-B 先充值100塊，再消費60塊，無論 IDC-B 的余額表中是大于還是小于60，都是允許的，此時 IDC-B 在臨時事務表中記錄兩個事務；

5. IDC-A 恢復后，IDC-B 將臨時事務表中的事務發(fā)給 IDC-A，IDC-A 進行合并，合并后的真實余額是70元，然后再通過“余額同步”這個通道將70元余額同步給 IDC-B 的余額表。

5大技巧4 - 實時改異步

圖片

5大技巧5 - 適當容忍

圖片

業(yè)務上稍微放開一些約束，例如：電話會議系統(tǒng)允許欠費也能發(fā)起會議。

總結：

圖片