在異地多活的實現上，數據能夠在三個及以上中心間進行雙向同步，才是解決真正異地多活的核心技術所在。本文基于三中心且跨海外的場景，分享一種多中心容災架構及實現方式，介紹幾種分布式ID生成算法，以及在數據同步上最終一致性的實現過程。

一、背景

為什么稱之為真正的異地多活？異地多活已經不是什么新鮮詞，但似乎一直都沒有實現真正意義上的異地多活。一般有兩種形式：一種是應用部署在同城兩地或多地，數據庫一寫多讀（主要是為了保證數據一致性），當主寫庫掛掉，再切換到備庫上；另一種是單元化服務，各個單元的數據并不是全量數據，一個單元掛掉，并不能切換到其他單元。目前還能看到雙中心的形式，兩個中心都是全量數據，但雙跟多還是有很大差距的，這里其實主要受限于數據同步能力，數據能夠在3個及以上中心間進行雙向同步，才是解決真正異地多活的核心技術所在。

提到數據同步，這里不得不提一下DTS(Data Transmission Service)，最初阿里的DTS并沒有雙向同步的能力，后來有了云上版本后，也只限于兩個數據庫之間的雙向同步，做不到A-B-C這種形式，所以我們自研了數據同步組件，雖然不想重復造輪子，但也是沒辦法，后面會介紹一些實現細節。

再談談為什么要做多中心容災，以我所在的CDN&視頻云團隊為例，首先是海外業務的需要，為了能夠讓海外用戶就近訪問我們的服務，我們需要提供一個海外中心。但大多數業務還都是以國內為主的，所以國內要建雙中心，防止核心庫掛掉整個管控就都掛掉了。同時海外的環境比較復雜，一旦海外中心掛掉了，還可以用國內中心頂上。國內的雙中心還有個非常大的好處是可以通過一些路由策略，分散單中心系統的壓力。這種三個中心且跨海外的場景，應該是目前異地多活最難實現的了。

二、系統CAP

面對這種全球性跨地域的分布式系統，我們不得不談到CAP理論，為了能夠多中心全量數據提供服務，Partition tolerance（分區容錯性）是必須要解決的，但是根據CAP的理論，Consistency（一致性）和Availability（可用性）就只能滿足一個。對于線上應用，可用性自不用說了，那面對這樣一個問題，最終一致性是最好的選擇。