分佈式系統技術難題--異地多活

什麼是異地多活？

爲了保證系統可以對機房級別的故障進行容錯,不會使系統不可用,這就須要在機房級別對系統進行冗餘處理。而這就須要在架構上進行良好的設計。來面對多機房場景下的技術挑戰。事實上，異地多活最大的挑戰在於機房之間的物理距離更遠,數據傳輸的延遲已經不能忽略。在網絡廣泛延遲的狀況下,如何根據業務特性設計高可用的性能達標的分佈式系統,將是最大的挑戰。

異地多活常見的解決方案有哪些？

1. 請求如何路由,如何實現會話保持?

對於請求路由問題,其設計目標在於,讓特定用戶訪問特定的機房,而且能夠實現流量分發策略控制,根據IP會話保持。而在於特定業務中,能夠根據制定更加複雜的路由規則,利用前端傳遞來的標籤，作路由策略轉發。讓特定的一些用戶在同一個機房中,例如餓了嗎，基於附近地區的業務場景，用戶,騎手,商家都是在同一個地區。咱們經過區分哪些用戶在同一個地區,機房按地區進行業務劃分。這樣商家，用戶,騎手的整個核心業務流程會在一個機房中完成，避免了跨機房調用形成延遲,用戶下單幾分鐘,商家才接到訂單,騎手接單到派送時間被延長。因此實現一個機房外的路由組件是頗有必要的,在機房級別添加一個路由網關。常見的作法就是基於用戶ID進行HASH的方式將用戶固定在一個機房處理該用戶相關的全部業務邏輯。

2. 數據存儲服務如何同步?

對於數據存儲問題是網絡延遲形成最大影響的地方。在常見的解決方案中有多機房單集羣,和多機房多集羣部署兩種.數據的同步能夠分爲，數據庫,緩存,消息隊列,session等。在多機房單集羣中如何部署？ 及整個系統中存儲服務是惟一的一個集羣,只有一個master節點.作讀寫分離設計,全部機房上的服務只能向數據存儲集羣上的master節點提交寫請求,而在讀數據時向本身機房上的salve節點提交請求。數據的同步委託給基礎組件完成,能夠利用數據自己的數據同步方案，但一般沒法結合業務特性進行優化提升性能，redis 自己的數據同步在master同步salve時會致使salve不可用，mysql自身的同步方案性能和穩定性都比較差。這時須要團隊親自制定化數據同步組件。來保證多個機房上的數據全量同步。還能夠基於消息隊列來實現數據同步，但這會致使額外的帶寬佔用,更能夠搭建專用網絡線路解決。不管任何的同步方式,在業務端須要對訪問數據庫的客戶端進行重構使其可以支持讀寫分離。而且爲了防止網絡延遲，咱們能夠在客戶端作不少事情,第一,雙寫:多個機房下容許出現多個Master,那麼客戶端進行封裝在底層將寫請求發送給多個Master上。第二:雙讀或回源讀,當讀取本機房數據沒有讀到時,去主機房讀取或者根據用戶請求解析出數據源在哪一個機房而後去讀取。

3. 是否能夠跨機房服務調用？延遲提升,佔據更多的網絡帶寬怎麼辦？

內部RPC等禁止跨主機調用,這樣能夠防止數據被依賴。避免對專用網絡佔用更多的帶寬。而且當一個機房不可用後不會影響可用機房的業務運行。

4. 當某個機房不可用時,需將該機房的流量切入另外一個機房,那麼每一個機房要預留多少存儲與計算資源？

通常通過測試評估,每一個機房預留S級服務承載的流量資源。

5. 一些devops組件如何支持跨機房部署環境？

監控系統,部署系統等如何彙總全部機房的數據,仍是將其區分開？ 通常來講,devops組件須要對多機房部署進行升級,增長機房選項。在多機房部署中,日誌數據可彙總到統一的數據區處理，日誌記錄一般異步進行便可。

6. 對於強一致性業務如何保證？

對於強一致數據,應創建多機房單集羣的部署模式,使用雙讀策略。多機房多集羣模式,採用雙寫策略。

7. 如何拆分業務,保證最大限度的避免跨機房延遲

將業務按照，流量大的業務,核心業務,產生收入的業務進行拆分,優先保證核心業務的多機房部署。將這些業務的總體流程邏輯放在一個機房內處理。列如餓了嗎按照 地域信息進行流量切分,將用戶下單，賣家接單,騎手接單配送這個核心流程儘可能放在一臺服務器處理。阿里就按用戶ID路由,大型網遊可能按照服務區對用戶處理流程限定在某個特定機房中。