跨國資料同步系統設計與實作

最近完成一個俄羅斯與中國同時線上使用的集生産物流銷售出庫于一體的（供應鍊）系統。從這個系統的設計之初到完成，經曆了有半年有餘。本篇記錄一下這個系統實作的核心架構思路。

現狀

1. 2019年一共做了兩個俄羅斯的項目。因為第一個項目的原因，對于俄羅斯營運商提供的伺服器的跨國網絡品質實在是無法恭維。有從各個管道了解到阿裡雲是莫斯科是有節點的，但是并不對外開放銷售。是以，想通過阿裡雲架設專線的這個想法基本就可以不考慮了。
2. 需求方要求，中國這邊操作，俄羅斯那邊也能快速擷取到變更後的資料。
3. 需求方還要求，資料要安全，保密，防止丢失。
4. 需求方甚至還要求，到哪都要快速打開。

問題考慮

1. 減少延遲

   中國大陸到俄羅斯的延遲大概在5000ms之間，網絡波動巨大，帶寬非常小。在俄羅斯購買的無帶寬限制的伺服器在國内拉取資源，隻能達到20kb/s。測試了阿裡雲香港節點到俄羅斯nic.ru的莫斯科節點的延遲，大概是在200ms左右，帶寬能達到100M左右。而香港阿裡雲到杭州阿裡雲公網的延遲基本上就在30ms以内。是以需要實作一個雙向鍊路莫斯科->香港->杭州，杭州->香港->莫斯科來減小延時

2. 資料同步：Binlog同步：在資料同步方面，首先想到的是Binlog同步，但是一番調研和實踐之後，發現在兩個節點之間互相同步資料，是需要實作一個cluster的，而跨區域的資料節點延遲過于高。别說是在兩個國家之間了，就算是同城，延遲幾ms的叢集都會造成極大的性能損耗。這個資料同步，最起碼在做到在操作的國家節點上不能出現髒讀和幻讀的情況。TiDB現成的優化方案：單節點寫入，多節點讀取。這個方案，在我們的項目中，可以保證使用者寫入的資料不會有操作同一件物料。但是考慮到跨國的資料寫入以及寫入後，無法保證使用者在何時可以看到資料被寫入了。一旦網絡波動過大，導緻目前節點無法擷取到此次資料寫入，使用者勢必會發起第二次請求，重新添加。是以暫時不在考慮中。TiDB的相關連結：流量和延遲減半！挑戰 TiDB 跨資料中心難題基于SQL的同步：基于SQL的同步可以讓每一個資料節點獨立運作。資料節點内的所有插入與更新的SQL的執行，都會産生一條push推送，給資料同步節點。資料同步節點産生目标節點的可執行參數，push到目标節點上。延遲時間大概為200ms+200 μs +30ms。

選中方案介紹

基于客戶高可用和操作速度快的需求，最終選中的方案是SQL同步。而該系統SQL同步的完美實作得益于兩點：

1. 分布式ID：自研的分布式id，單機每秒可以産生2萬有序不重複id
2. 資料校驗：在一個節點校驗到資料超賣的情況下，會上報同步中心，同步中心對曆史SQL進行審計，進行首次超賣資料修正。再分發到各個機器。

分布式ID

此次選用的分布式id生成規則為%d%02d%02d%02d%04d%08d。

段位	%d	%02d	%02d	%02d	%04d	%08d
備注	年份後2位	月份	日期	目前秒	機器id	8位秒級自增id，最高可支援8個9的正整數數。

在這裡，同步中心還負責作為注冊中心使用，當一個業務節點啟用，業務節點就會向服務中心注冊，注冊中心會傳回目前機器的臨時編号。并且業務節點需要與注冊中心保持長連接配接，以便實時擷取到最新的業務節點數量。注冊中心會與業務機保持心跳，避免資料沒有被業務機同步，資料就過期。

資料校驗

同步資料變更記錄異步寫入到mq後，由消費者發送到同步中心。

1. 當資料到達同步中心後，同步中心會基于SQL的更新時間進行重新排序，然後生成每個注冊同步節點的對應的SQL。在時間顆粒内，保證資料基于時間有序。
2. 當資料同步到其他節點時，會先進行資料校驗，保證庫存不會出現超賣。出現超賣，上報同步中心，同步最近N個時間顆粒的資料，進行SQL重放。

效果

第一次開發的系統（A）

本次開發完畢的系統（B）

接口響應對比

• A系統通路者在國内，開啟HK的科學上網，接口響應時間在1s以上，丢包率50%以上，國内基本無法正常使用。
• B系統，業務部署在莫斯科與杭州兩個資料中心。根據所在的地區，選用對應的系統，接口響應時間均在200ms以内，杭州節點一般在50ms左右。

資料同步時間對比

• A系統無資料同步系統支援，中國通路的延遲基本無法接受。
• B系統的資料同步時間基本在500ms以内。基本上實作了跨國資料同步。

資料安全性

• A系統單節點存在，資料可靠性依賴于伺服器提供商
• B系統的資料在莫斯科存在一份，香港存在一份日志記錄（可通過資料回放恢複資料），杭州存在一份。一旦出現資料節點毀滅性丢失資料，可以從其他兩個節點進行資料恢複，資料丢失量可以控制在一到二個時間同步顆粒。

系統獨立性

• A系統單節點存在，不存在資料同步依賴
• B系統雖然需要進行資料同步，但是因為執行SQL同步方案，系統的獨立運作性能不會限制于資料庫同步。

注意點

1. 所有的機器都需要基于0時區進行時間校驗，保證SQL的ID基于時間有序。
2. 在設計分布式ID生成時，需要注意機器碼的編号大小不能影響到資料的大小排序，隻作為一個識别編号。
3. 資料校驗的嚴格程度取決于同步中心對于同步頻率的控制，是一個動态的值。盡量不要用一個固定值去處理，固定值需要取較大，影響同步校準性能。
4. 分布式id采用的是數字類型，資料庫的自增id需要及時清除。

作者:Strcpy

出處:https://jinfeijie.cn/post-830