業務高可用的保障 異地多活架構

2021-09-29 06:16:49 字數 1686 閱讀 2282

一、什麼是異地多活?

異地多活:異地指不同地理位置,多活指不同地理位置的系統都是活躍的,都能夠提供業務服務。

異地多活是為了解決極端場景下所有伺服器都出現故障時業務不受影響,或者業務在幾分鐘內就能夠快速恢復而設計的。

異地多活的優點:功能強大、提供更好的體驗、可以減少業務中斷帶來的損失

異地多活的缺點:代價高昂、設計複雜

二、應用場景

無法承受異地多活帶來的複雜度和成本時可以只做異地備份,不做異地多活

業務中斷後對使用者影響很大的系統需要做異地多活

業務規模很大,中斷後影響收入的系統需要做異地多活

三、架構模式

根據地理位置上的距離分為同城異區、跨城異地、跨國異地3種架構模式

1、同城異區

定義:將業務部署在同乙個城市不同區的多個機房

優缺點:設計複雜度非常低、成本相對較低、極端災難無法應對

應用場景:應對機房級別故障的最優架構

2、跨城異地

定義:業務部署在不同城市的多個機房,而且距離最好要遠一些

優缺點:可以有效應對範圍較大的極端災難、架構複雜度很高

應用場景:對資料一致性要求不那麼高,或者資料不怎麼改變,或者即使資料丟失影響也不大的業務

3、跨國異地

定義:業務部署在不同國家的多個機房

優缺點:不是真正意義的多活、適合特殊型別業務

應用場景:為不同地區的使用者提供服務、唯讀類的業務

四、跨城異地架構的設計技巧

異地多活的本質:通過異地的資料冗餘,來保證在極端異常的情況下業務也能夠正常提供給使用者,異地多活架構設計的核心是資料同步

設計核心思想:採用多種手段,保證絕大部分使用者的核心業務異地多活

1、技巧一:保證核心業務的異地多活

不要陷入『保證所有業務都能「異地多活」』的思維誤區

識別核心業務,優先實現核心業務的異地多活架構

2、技巧二:保證核心資料最終一致性

不要陷入『所有資料都實時同步』的思維誤區

物理距離導致無法實現資料快速同步的問題是無解的,只能儘量減少影響

儘量減少機房距離、儘量減少資料同步、只保證最終一致性

3、技巧三:採用多種手段同步資料

不要陷入『只使用儲存系統的同步功能』的思維誤區

多種手段配合儲存系統的同步來使用,或者不採用儲存系統的同步方案

4、技巧四:只保證絕大部分使用者的異地多活

不要陷入『我要保證業務 100% 可用』的思維誤區

異地多活也無法保證 100% 的業務可用

可以採取一些措施進行安撫或者補償受影響的使用者

五、跨城異地多活架構的設計流程

1、第一步:業務分級

按照一定的標準將業務進行分級,挑選出核心的業務

分級標準:訪問量大的、核心業務、產生大量收入的

2、第二步:資料分類

對核心業務相關的資料進一步分析,識別所有的資料及資料特徵

常見資料特徵分析緯度:資料量、資料唯一性、實時性、可丟失性、可恢復性

3、第三步:資料同步

根據不同的資料設計不同的同步方案

常見資料同步方案:儲存系統同步、訊息佇列同步、重複生成

4、第四步:異常處理

假設在出同步延遲、資料丟失、資料不一致等問題時,系統將採取什麼措施來應對

目的是避免整體業務不可用、在問題恢復後修正異常資料、安撫使用者彌補損失

常見異常處理措施:多通道同步、同步和訪問結合、日誌記錄、使用者補償

業務高可用的保障 異地多活架構

1 引言 高可用計算架構還是高可用儲存架構,其目的都是為了解決部分伺服器故障的場景下,如何保證系統能夠繼續提供服務。但也存在一些極端的情況,導致所有或大部分伺服器出現故障,如斷電 自然災害等,業務也就會受到不同層次的影響,因此,需要設計異地多活架構。2 應用場景 異地多活架構的關鍵點就是異地 多活,...

mysql異地多活方案 對於異地多活的實踐與思考

對於異地多活的實踐與思考 瀏覽次數 707 一 引 異地多活是近幾年比較熱門的乙個話題,那麼在實際業務中什麼時候需要去做這件事?如何去做?做的時候需要考慮什麼?1 何時去做?個人感覺取決於以下幾個方面 業務發展 基礎設施狀況 技術積澱 2 如何做?目前在網上搜尋到的異地多活方案來看,基本都是阿里 餓...

mysql異地多活方案 最易懂的資料庫異地多活方案

前言 今天我們將嘗試 資料庫的異地多活高可用。注意,我們討論的都是超大資料量 50tb 級別 的資料庫。第一種直接上分布式資料庫,目前市面上常見的有 3 種,tidb,阿里雲 polardb,亞馬遜 aurora。雖然 tidb 可以將資料 sharding 到各個城市,但由於各個城市的物理距離導致...