騰訊雲免認證賬號:騰訊雲同城雙活與異地多活(MySQL Redis)架構搭建指南
在互聯網高並發、大流量的背景下,系統的穩定性就是企業的生命線。 很多技術團隊在項目初期,服務器和數據庫都堆在騰訊雲的同一個可用區(機房)。 平時風平浪靜,可一旦遇到機房斷電、光纜被挖斷或者大面積網絡故障,整個業務就會瞬間陷入癱瘓。
為了實現「高可用」,架構師們通常會祭出兩級大招:
同城雙活(Multi-AZ)
和
異地多活(Multi-Region)
。
很多人一聽到「多活」就覺得高不可攀,認為那是大廠才能玩的底層黑科技。 其實,利用騰訊雲成熟的雲產品(如 TDSQL、CDB、tcaplusDB 以及 DTS 數據傳輸服務),中小團隊也能在幾天內搭建起一套高可用的多活架構。
今天這篇教程直接切入核心,不扯空洞的理論,帶你用大白話拆解
同城雙活
與
異地多活
的架構邏輯,並手把手教你如何配置
MySQL + Redis
的雙活落地。
核心複習:同城雙活 vs 異地多活,有何不同?
在動手之前,必須搞清楚這兩套方案的邊界,否則選錯了型,不僅燒錢,還解決不了問題。
1. 同城雙活(同城多可用區)
怎麼建: 把應用和數據庫分別部署在同一個城市(比如上海)的兩個不同機房(比如上海可用區二、上海可用區三)。
網絡延遲: 極低(通常 < 2ms),因為兩個機房之間拉的是專線纖。
數據同步: 強一致性。 MySQL 和 Redis 可以做到幾乎零延遲的同步。
防範風險: 完美防禦單機房斷電、單機房火災等物理故障。
2. 異地多活(跨地域多活)
怎麼建: 在兩個相隔很遠的城市(比如北京和廣州)分別建一套完整的系統。
網絡延遲: 較高(北京到廣州光速傳輸也有約 30ms 的物理延遲)。
數據同步: 最終一致性。 因為延遲的存在,絕對做不到實時強同步,只能異步複製。
防範風險: 防禦城市級災難(如地震、主幹網斷裂)。
大白話建議: 95% 的企業,做到同城雙活就已經足夠應對絕大多數宕機災難了。 只有當你的DAU過千萬,或者對合規性有極端要求時,才需要考慮異地多活。
第一階段:同城雙活(MySQL+Redis)實戰搭建
同城雙活的核心思想是:
應用層雙活(流量隨便切),數據層一主一備(自動秒級切換)
。
1. 基礎設施:劃定 Vpc 與子網
你在騰訊雲買服務器時,必須把它們安頓在不同的可用區。
在上海地域創建一個 VPC。
創建兩個子網:子網 A 屬於 上海可用區二,子網 B 屬於 上海可用區三。
2. 應用層(CLB CVM)配置
買兩台輕量服務器或 CVM,一台扔在子網 A,一台扔在子網 B。
購買一個騰訊雲 負載均衡(CLB),並在後端伺服器列表里,同時把這兩台服務器掛載上去,權重設為 50:50。
這樣,無論哪個機房掛了,CLB 都能在一秒內把流量全部導向另一個機房存活的應用。
3. 數據層:MySQL(CDB 高可用版)配置
不要自己去服務器上裝集群,直接買騰訊雲的
雲數據庫 CDB(高可用版)
。
購買選型: 在購買頁面,選擇 跨可用區部署。
節點分配: 主節點選 上海可用區二,備節點選 上海可用區三。
底層原理: 騰訊雲底層會利用強同步機制(Semi-Sync),確保主備數據絕對一致。 一旦可用區二停電,CDB 會在 30 秒內自動把可用區三的備節點升級為主節點,應用的數據庫連接地址(VIP)保持不變,無需人工修改代碼。
4. 緩存層:Redis(本地雙活)
Redis 通常用來做高速緩存。 在同城雙活下,建議使用騰訊雲的
Redis 尊享版(跨可用區高可用)
,其主備架構與 MySQL 類似:可用區二讀寫,可用區三異步同步。 因為同城延遲極低,緩存穿透的概率微乎其微。
第二階段:異地多活(MySQL Redis)實戰搭建
異地多活的難度呈指數級上升。 因為北京和廣州之間的延遲有 30ms,如果北京的應用跨地域去讀廣州的數據庫,網絡開銷會讓你的系統卡得像 PPT。
異地多活的鐵律:
單元化部署,各讀各的,數據異步混算。
1. 核心大招:流量染色與單元化(GSLB)
假設你按用戶 ID 劃分:ID 為奇數的去北京機房,ID 為偶數的去廣州機房。
利用騰訊雲的 全局負載均衡(GSLB) 或者控制 DNS 解析,當北京用戶請求時,直接解析到北京機房的 CLB。
絕對禁止跨地域調用: 北京的應用只能讀寫北京本地的 MySQL 和 Redis,廣州的應用只能讀寫廣州本地。
2. 數據層:MySQL 異地雙活(利用 DTS 雙向同步)
北京有一套 MySQL,廣州有一套 MySQL,兩邊都在同時寫入數據,如何保持同步?
進入騰訊雲控制台,搜索 數據傳輸服務 DTS。
新建一個 雙向數據同步 任務。
源數據庫選北京的 CDB,
目標數據庫選廣州的 CDB。
配置衝突解決策略:重點! 必須選擇「錯開主鍵」或者「時間戳優先」。 比如北京生成的 ID 都是奇數,廣州生成的 ID 都是偶數,防止兩邊同時往數據庫插數據時發生主鍵衝突。
🚨異地多活的「隱形大坑」--數據回環:如果北京的數據同步給廣州,廣州誤以為是本地新產生的,又同步回北京,系統就會死循環。 騰訊雲的 DTS 後台自帶「防回環」機制,它會給同步的數據打上特殊標籤,確保數據只複製一次。
3. 緩存層:Redis 異地多活
Redis 里的數據通常有過期時間,且變化極快。 在異地多活場景下,普通的 Redis 複製根本無法承受。
官方神器: 騰訊雲提供了 Redis 全球多活(Global Replication) 產品。
配置方法: 你可以在北京和廣州各買一個 Redis 實例,在控制台將它們綁定為一個「全球多活組」。
業務邏輯: 兩邊的 Redis 都可以本地讀取。 對於需要共享的緩存(如用戶登錄的 Token 狀態),北京寫入後,騰訊雲底層會通過專線,在幾十毫秒內異步推送到廣州。 雖然有短暫的時間差,但完全能滿足業務需求。
第三階段:容災演練與切流(關鍵時刻不抓瞎)
架構搭好了,怎麼驗證它真的能救命? 你需要進行定期演練。
場景一:同城雙活單機房掛掉(如可用區二故障)
自動部分: 騰訊雲 CLB 會自動剔除可用區二的異常 CVM。 MySQL 會自動觸發主備切換,可用區三的備庫接管讀寫。
人工確認: 運維登錄控制台,檢查業務日誌,確認無髒數據,演練結束。
場景二:異地多活城市級掛掉(如北京機房整體失聯)
這時候需要人工介入路由切流:
登錄騰訊雲 DNS 解析/流量調度控制台。
把原本分流到北京的 50% 奇數用戶流量,一鍵硬切換改指向廣州機房的 CLB。
廣州的應用此時開始同時承載 100% 的用戶請求。 由於 DTS 一直在後台同步,廣州的 MySQL 里已經擁有了北京機房死掉前 99.9% 的數據。
代價接受: 切換過程中,可能會有極少數在最後幾毫秒內註冊的北京用戶提示「登錄失敗」或「數據滯後」,這在異地多活的「最終一致性」理論中是完全被允許的。
總結與高可用四句口訣
高可用架構不是一勞永逸的銀彈,而是一場向物理定律(光速與網絡延遲)妥協的藝術。 總結起來就四句話:
同城雙活最划算: 跨可用區買服務,代
碼一行不用改,防災搞定九成半。
異地多活先分區: 業務必須單元化,北京人看北京庫,跨城讀寫是災難。
主鍵衝突要避開: 異地雙寫用 DTS,奇偶主鍵錯開排,防止數據成亂麻。
定期演練才心安: 別等真正出了事,才翻文檔看切流,平時多練兵,戰時顯神威。
