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

什麼是異地多活？

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

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

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路由,大型網遊可能按照服務區對使用者處理流程限定在某個特定機房中。

---------------------------------------------------------

老錢點評：雙機房就好比人的左右腦，機房之間的網路就是胼胝體。現在胼胝體壞了，還必須保證這個人能正常的生活，吃喝拉撒睡都還能幹，這確實是一件非常不容易的事。