作者
孔令圳，斗魚首席架構師，全面負責斗魚全站技術架構體系規划和建設，10 余年中大型互聯網產品架構經驗，擅長高並發、高可用場景下的架構與方案設計。
於競，斗魚技術保障運維專家，負責斗魚高可用基礎架構建設，擅長注冊中心、監控體系等技術領域，同時也是斗魚多活基礎保障負責人。
唐聰，騰訊雲資深工程師，極客時間專欄《etcd 實戰課》作者，etcd 活躍貢獻者，主要負責騰訊雲大規模 k8s/etcd 平台、有狀態服務容器化、在離線混部等產品研發設計工作。
陳鵬，騰訊雲容器服務產品架構師，多年專注雲原生領域，幫助了大量用戶雲原生容器化改造和生產落地，擁有豐富的一線實踐經驗，也發表了海量的雲原生技術文章。
業務背景和痛點
斗魚直播作為業界領先的游戲直播平台，每天為數以億計的互聯網用戶提供優質的游戲直播觀看、互動和娛樂等服務。
隨着近年直播市場的火熱，斗魚直播平台作為業內口碑和體驗俱佳的互聯網公司，用戶量也出現井噴式增長。海量用戶給平台帶來的穩定性技術挑戰也越發強烈，斗魚的老架構如下圖所示，無論是業務支撐還是架構設計，均存在一定的風險和隱患。
斗魚老架構
圖一 斗魚老架構
為了給用戶帶來更好的可用性體驗，斗魚急需解決單一數據中心的問題，將老架構從單數據中心升級到多數據中心。
多數據中心挑戰
在實現單活升級為多活的過程中，為了確保無故障的遷移升級，我們面臨一系列挑戰，比如：
有狀態服務 etcd、zookeeper 等如何多數據中心同步？
應用彼此之間存在 1 個復雜的樹狀或網狀依賴關系，應該從哪里開始遷移？
按什么維度來划分目標的邊界，怎么避免業務焊死在一起，造成無從下手的局面？
如果遷移后出現問題，如何快速恢復，並且不牽連已遷移成功的業務？
因單活升級到多活的過程中，涉及系統眾多，本文將是斗魚直播多活改造系列的第一篇，只聚焦於注冊中心模塊，因此我們先和你介紹下注冊中心背后的 etcd 和 zookeeper。
zk/etcd 承擔的角色
dubbo 通過注冊中心來解決大規模集群下的服務注冊與發現問題，以下是注冊中心架構圖：
dubbo 默認支持 zookeeper 注冊中心，雖然新版也有 etcd 實現，但該實現尚缺乏大規模投產的先例，Java 技術棧采用 etcd 作為注冊中心的案例也比較罕見。
當采用 zookeeper 作為 dubbo 注冊中心時，其注冊關系為樹形結構，詳細結構如下圖所示：
因為 zookeeper 是基於類似文件系統的樹形結構來存儲數據，但 etcd 卻是采用鍵值對存儲，二者之間的差異會給注冊關系同步帶來較大困難。
此外，如果從 zookeeper 遷移到 etcd，則在整個遷移過程中：已有的線上服務不能受損，更不能停服；如果遷移失敗，還要能回退到到 zookeeper。
同城雙活與多活新架構
為了實現多活，我們通過跨數據中心的同步服務、服務依賴梳理與邊界划分、可控變更等技術手段和運維理念，成功解決了以上挑戰，設計了如下一套新的架構來實現多活，如下圖所示：
圖二 斗魚多活新架構
在新的架構下，可以按域名甚至是 URL 來細粒度的調度流量，RPC 層面也具備了自動就近調用的能力，其中注冊中心的局部架構圖如下：
圖三 斗魚注冊中心老架構
注冊中心多活方案選型與目標
在注冊中心多活改造過程中，我們面臨多個方案，如下表所示：
由於歷史原因，我們有 zookeeper（以下簡稱 zk）和 etcd 這 2 套注冊中心，加上我們有 Java、Go、C++、PHP 這 4 個技術棧，因此在注冊中心領域仍然一些不足，希望能統一到 etcd 來解決痛點問題，並達到以下目標：
降低維護成本：此前需要運維 zk+etcd 兩套注冊中心，更困難的是做多活解決方案時也需要適配 zk+etcd，這導致注冊中心多活研發成本翻倍。由於 etcd 是 k8s 的一部分，運維 etcd 又不可避免，這是選擇 etcd 的第 1 個原因。
擁抱更繁榮的生態：etcd 有雲原生托管解決方案，有廠商通過 etcd 管理 10K node 級別的 k8s 集群，etcd 還自帶 proxy、cache、mirror 等各種周邊工具，java 側 dubbo 也支持以 etcd 作為注冊中心，etcd 相對於 zk 來說發展前景更好，這是選擇 etcd 的第 2 個原因。
增強跨語言能力：etcd 可基於 http 或 grpc 協議通訊，並且支持長輪詢，具有較強的跨語言能力。而 zk 需要引入專用客戶端，除 java 客戶端之外，其它語言客戶端尚不成熟。而我們有 JAVA、Go、C++、PHP 等 4 種研發語言，這是選擇 etcd 的第 3 個原因。
基於以上原因，我們選擇了方案四，方案四大新架構如下圖所示:
圖四 斗魚注冊中心新架構
注冊中心多活難點與挑戰
為了實現新注冊中心，達到我們期望的設計目標，注冊中心在改造過程中，面臨以下難點與挑戰:
如何解決 zk 的多數據中心同步問題？尤其是 zookeeper watch 機制是不可靠的，可能出現丟失 watch 事件的問題？（正確性）
如何解決 etcd 的多數據中心同步問題？從下面方案選型中，我們可以看到社區目前並無任何成熟、生產環境可用的解決方案。（正確性）
如何解決跨數據中心讀的性能問題？（性能）
如何解決跨數據中心的服務穩定性問題？網絡鏈路上，比如內網專線若中斷了怎么辦？同步服務設計上，是否會導致 etcd/zk 同步服務進入性能極慢的全同步邏輯，同步服務本身是否具備高可用等等？容災測試上，我們又該如何設計測試用例驗證？運維上，我們又該如何快速發現隱患、消除潛在的故障，建設可視化、靈活的多活運維系統？（穩定性、可運維性）
注冊中心多活難點分析
遷移過程中如何保證新舊服務互通？
開發 zk2etcd
我們很多 java 開發的業務使用 dubbo 框架做服務治理，注冊中心是 zookeeper，我們希望 java 和 go 開發的業務全部都統一使用 etcd 作為注冊中心，也為跨語言調用的可能性做好鋪墊。
由於業務眾多，改造和遷移的周期會很長，預計持續 1~2 年，在此過程中我們需要將 zookeeper 中的注冊數據同步到 etcd 中，實時同步，而且要保證數據一致性以及高可用，當前市面上沒有找到滿足我們需求的工具，於是我們和騰訊雲 TKE 團隊合作開發了一個 zk2etcd 來同步實現 zookeeper 數據到 etcd，並且已將其開源，整體方案落地篇我們將詳細介紹。
如何實現 etcd 異地容災?
通過 zk2etcd 同步服務，我們成功解決了 zookeeper 數據遷移問題，使得新老業務的注冊中心數據都使用 etcd 來存儲。
因此，etcd 的重要性不言而喻，它的可用性決定着我們的整體可用性，而斗魚直播目前的部署架構又嚴重依賴某核心機房，一旦核心機房出現故障，將導致整體不可用。因此斗魚直播下一個痛點就是提升 etcd 的可用性，期望實現 etcd 跨城容災、異地容災能力。
斗魚直播理想中的 etcd 跨城同步服務應該具備如下特性:
etcd 跨城容災部署后，讀寫性能不顯著下降，能滿足業務場景基本訴求。
同步組件達到生產環境可用級別，具備完備的一致性檢測、日志、metrics 監控等。
對數據一致性要求不強的業務可就近訪問同地區的 etcd 集群服務、強一致訴求業務可訪問主 etcd 集群。
主集群故障后，業務運維能根據一致性監控等，快速將備集群提升為主集群。
那么有哪些方案呢？各個方案又有哪些優缺點呢？最終評估了如下幾種方案:
單集群多地部署方案
etcd 社區 make-mirror 方案
etcd 社區 learner 方案
騰訊雲 etcd-syncer 方案
單集群多地部署方案
單集群多地部署方案圖如下：
在此方案中，etcd Leader 節點通過 Raft 協議將數據復制到各個地域的 Follower 節點。
此方案它的優點如下：
各地域網絡互通后，部署簡單，無需運維額外組件
數據跨城強一致同步，3 節點部署場景中，可容忍任一城市故障，並且不丟失任何數據
介紹完它的優點后，我們再看看它的缺點，如下所示：
在 3 節點部署的場景下，任意寫請求至少需要兩個節點應答確認，而不同節點部署在各地，ping 延時會從幾毫秒上升到 30ms 左右（深圳 - 上海)，因此會導致寫性能急劇下降。
etcd 默認的讀請求是線性讀，當 Follower 節點收到 Client 發起的讀請求后，它也需要向 Leader 節點獲取相關信息，確認本地數據追趕上 Leader 后才能返回數據給 client，避免讀取到舊數據等，在這過程中也會導致 etcd 讀延時上升、吞吐量下降。
跨城部署網絡之間質量也較容易波動，導致服務質量抖動等。
client 訪問 etcd 集群的配置，為了防止單點故障，必須配置多個 etcd 節點，而這又可能導致 client 訪問到異地的 etcd 節點，導致服務請求延時增大等。
etcd 社區 make-mirror 方案
介紹完單集群多地部署方案后，我們再看看 etcd 社區提供的 make-mirror 方案，它的原理圖如下：
在此方案中，我們分別在不同城市部署了一套獨立的 etcd 集群，通過 etcd 社區提供的 make-mirror 工具實現跨城數據復制。
make-mirror 工具原理如下：
指定數據同步的前綴后，通過 etcd Range 讀接口從主集群遍歷此前綴下的所有數據，寫入到目的 etcd。（全量同步）
隨后通過 etcd Watch 接口指定讀請求返回的“版本號”，監聽從此版本號后的所有變更事件。
make-mirror 收到主 etcd 集群推送的 key-value 變化事件后，通過 txn 事務接口將數據寫入到熱備集群。（增量同步）
此方案它的優點如下：
主 etcd 集群讀寫性能高，整體上不受跨地域網絡延時、網絡質量波動影響
若業務可容忍短暫不一致，可就近訪問距離最近的 etcd 集群
若業務要求強一致，可通過內網專線訪問主 etcd 集群
不依賴高版本 etcd
介紹完它的優點后，我們再看看它的缺點，如下所示：
當寫請求較大的時候，備集群可能存在一定的數據落后，可能讀到臟數據。
社區自帶的 make-mirror 同步鏈路中斷后，退出重啟會再次進入全量同步模式，性能較差，無法滿足生產環境訴求。
社區自帶的 make-mirror 工具缺少 leader 選舉、數據一致性檢測、日志、metrics 等一系列特性，不具備生產環境可用性。
不支持同步非 key-value 數據，如 auth 鑒權相關數據、lease 數據等。
etcd 社區 learner 方案
介紹完 etcd 社區的 make-mirror 方案后，我們再看看 etcd 社區提供的 learner 方案，它的原理圖如下：
它的核心原理如下：
etcd raft 算法庫在 2017 年的時候就已經支持了 learner 節點，詳情可參考 pr 8751。
etcd 社區在 2019.8 月推出的 3.4 版本中，正式支持 Learner 節點，它作為非投票 (Non-Voting) 的成員節點加入集群，不參與集群選舉等投票，只進行數據復制。
Leader 收到寫請求后，將日志同步給 Follower 和 Learner 節點，並在內存中使用一個名為 Progress 的數據結構，維護 Follower 和 Learner 節點的日志同步進展信息。
當 Learner 節點的數據與 Leader 數據差距較小的時候，它就可以被提升為可投票的成員節點加入集群。
此方案它的優點如下：
各地域網絡互通后，部署簡單，只需往 etcd 集群中添加一個 Learner 節點，無需運維額外組件
Learner 節點可同步任意類型數據，如 key-value、auth 鑒權數據、lease 數據
介紹完它的優點后，我們再看看它的缺點，如下所示：
Learner 節點只允許串行讀，也就是業務如果就近讀，會讀到舊數據。
依賴高版本 etcd，etcd 3.4 及以上版本才支持 Learner 特性，並且只允許一個 Learner 節點 .
主集群全面故障后，無法快速將 Learner 節點提升為可寫的獨立 etcd 集群。
介紹完已有的幾種方案后，我們發現它們都無法滿足業務生產環境訴求，於是我們自研完成了生產環境可用的 etcd 同步服務落地，在整體方案落地章節將詳細介紹。
如何確保 etcd 和 zk 同步服務的穩定性、可運維性?
為了確保 etcd、zk 同步服務的穩定性，模擬 5 類常見的故障，檢驗服務在這些典型故障場景下的自愈能力，詳細測試方案如下。
故障場景
redis 閃斷（zk2etcd 服務依賴），例如：redis 版本升級、非平滑擴容。
zk2etcd 離線，例如：OOM、容器驅逐、宿主機故障。
etcd2etcd 離線 ，例如：OOM、容器驅逐、宿主機故障
網絡閃斷，例如：OOM、容器驅逐、宿主機故障。
弱網環境，例如：專線斷掉后臨時用公網頂替。
上述 5 種場景的實際觸發原因有多種多樣，只需要模擬出一種情況。
演練方案
redis 閃斷：通過改 host 模擬 redis 不可達，此時自動訂正停止；模擬 redis 恢復后，自動訂正亦自動恢復。
zk2etcd 離線：通過殺容器節點模擬 zk2etcd 掛掉，15 秒內 k8s 自動拉起，拉起完成后同步正常、數據一致。
etcd2etcd 離線 ：通過殺容器節點模擬 zk2etcd 掛掉，15 秒內 k8s 自動拉起，拉起完成后同步正常、數據一致。
網絡閃斷： 通過改 host 模擬 zk、etcd 不可達，此時同步中斷，后去掉 host 模擬網絡恢復，恢復后同步正常、數據一致。
弱網環境： 通過切公網模擬弱網環境，切公網后同步效率降低在 4 倍以內，1 次全量同步仍然可在 1 分鍾內完成。
另外針對可運維性問題，無論是 etcd 還是 zk 同步服務，都提供了詳細的 metrics、日志，我們針對各個核心場景、異常場景都配置了可視化的觀測視圖，並配置了告警策略。
整體方案落地
整體架構
etcd 集群多活架構圖如下所示:
說明
黑實線：正常情況下的專線訪問
黑虛線：切公網方式訪問
紅實線：etcd 集群發生主備切換后的專線訪問
紅虛線：etcd 集群發生主備切換后的公網訪問
etcd2etcd/zk2etcd 數據同步服務圖如下所示:
zk同步服務工程化實踐
zookeeper 與 etcd 存儲結構不一致，加大了同步的實現難度。zookeeper 存儲是樹狀結構，而 etcd v3 是扁平結構。zookeeper 無法像 etcd 一樣按照 prefix 來 list 所有 key；etcd 無法像 zookeeper 一樣通過 list chilren 來查詢某個目錄下的子節點，也加大了實現同步的難度。
如何感知 zookeeper 中的數據變化？zookeeper 的 watch 不像 etcd 一樣可以簡單的感知到任意 key 的新增，需要遞歸的 watch 所有的節點，收到 ChildrenChanged 事件后拿到該事件對應節點下的所有子節點，再與 etcd 中的數據進行比對，就可以得到新增的數據，並將其同步 put 到 etcd 中。類似的，可以用遞歸的方法 watch 所有節點的刪除事件，並同步刪除 etcd 中的數據。
另外 zookeeper 的 watch 有着先天性的缺陷，watch 是一次性的，所以每次收到事件后又必須重新 watch，兩次 watch 之間理論上是可能丟事件的，主要是在同一個 key 連續多次變更的時候可能會發生。如果丟事件發生就會破壞了數據一致性，我們引入了自動 diff 和訂正的能力，即計算 zookeeper 和 etcd 中數據存在的差異，每次都會經過兩輪 diff 計算，因為在頻繁變更數據的情況下，一輪 diff 計算往往存在一些因不是強一致性同步導致的"偽差異"，當 diff 計算出了結果就會自動 fix 掉這些差異。
如何解決與 etcd2etcd 共存？當同一個路徑下，即有 etcd2etcd 同步寫入的數據，又有 zk2etcd 寫入的數據，在 zk2etcd 的自動訂正邏輯里面，會計算出差異並訂正差異，但我們不希望因此而誤刪 etcd2etcd 寫入的數據。我們通過為 zk2etcd 引入了 redis 來存儲狀態解決了這個問題，在 zk2etcd 往 etcd 中同步寫入或刪除數據時，也同步在 redis 中記錄和刪除:
然后 zk2etcd 在自動訂正計算差異的時候，只考慮本工具寫入過的數據，避免誤刪其它同步工具寫入的數據。
etcd2etcd 工程化實踐
為了解決 etcd 同步難題，我們調研了如下兩種方案，接下來我們就詳細介紹下它的原理：
etcd-syncer 之 mirror-plus 版
首先我們介紹下 etcd-syncer 的 mirror-plus 方案，顧名思義，它是 etcd 社區 make-mirror 的加強版。為了解決 make-mirror 的各種缺陷，它實現了以下特性、優點:
支持多種同步模式，全量同步、斷點續傳，不再擔憂專線、公網網絡質量抖動
高可用，負責同一數據路徑復制的實例支持多副本部署, 一副本故障后，其他副本將在 5 秒后獲得鎖，在之前實例同步的進度基礎上，進行快速恢復
支持一致性檢查（全量數據檢查、快照檢查)
支持多實例並發復制提升性能（不同實例負責不同的路徑），建議生產環境配置多實例，每個實例負責不同路徑
良好的運維能力，基於 k8s deployment 一鍵部署，豐富的 metrics、日志，完備的 e2e 測試用例覆蓋核心場景（http/https 場景，服務異常中斷、網絡異常等 ）
那么它的缺點是什么呢？因為它核心原理依然是依賴 etcd 的 mvcc+watch 特性，因此數據無法保證強一致性和只同步 key-value 數據。
斷點續傳依賴 mvcc 歷史版本保留時間，最好業務能保存至少 1 個小時的歷史數據。
當寫請求較大的時候，備集群可能存在一定的數據落后，可能讀到臟數據。
不支持同步非 key-value 數據，如 auth 鑒權相關數據、lease 數據等。
etcd-syncer 之 Raft 版
為了解決所有類型的數據同步問題以及消除對 etcd mvcc 歷史數據的依賴，騰訊雲還可提供基於 Raft 日志的同步方案 etcd-syncer 之 raft 版本。
它的部署圖如下所示,etcd-syncer 同步服務作為一個類似 learner 節點的身份，加入主 etcd 集群。
主 etcd 集群 Leader 將 Raft 日志數據通過 MsgApp/Snapshot 等消息同步給 etcd-syncer, etcd-syncer 解析 Raft 日志，將 Raft 日志條目對應的 Txn/Delete/Auth 等請求應用到目的 etcd 集群。
它具備如下優點：
具備 etcd-syncer 之 mirror-plus 版本的所有特性和優點，同時不依賴 etcd mvcc 歷史數據。
基於 etcd 底層的 Raft 日志同步數據，可以同步 key-value、auth、lease 等各種類型的數據。
不依賴高版本的 etcd。
完備的容災測試
grpc-proxy
此方案引入了 grpc-proxy 代理服務，也是頭一次使用。為了了解此代理服務的性能情況，我們使用 etcd 自帶的 benchmark 進行了讀和寫的測試，另外手寫了一個小工具做了一下 watch 測試。以下為部分測試內容。
寫入測試
直接訪問 etcd 服務的負載均衡入口
走 grpc-proxy 代理訪問 etcd 服務的情況
grpc-proxy 代理在 endpoints 配置走專線或公網情況下，都能正常寫入
寫入 key 總數一定的情況下，連接數和客戶端數越大，總耗時越低
寫入 key 總數越大，單次寫入的平均耗時（Average）會有所增加，但仍為毫秒級
當一次寫入 key 總數為 10 萬時，直連 etcdserver 會出現 too many requests 的報錯，但 grpc-proxy 沒有
公網情況比專線性能有所下降
走 grpc-proxy 代理的平均耗時相比直連有所增加，但滿足需求
讀取測試
直接訪問 etcd 服務的負載均衡入口
走 grpc-proxy 代理訪問 etcd 服務的情況
grpc-proxy 代理在 endpoints 配置走專線或公網情況下，都能正常讀取
走 grpc-proxy 代理的平均耗時相比直連有所增加，但在可接受范圍
watch 測試
根據我們自己寫的一個 etcdwatcher 服務對 grpc-proxy 進行 watch 測試：可以設置總 watcher 數量，更新頻率，以及測試時間，結束時打印出簡報
./etcdwatch -num=100 -span=500 -duration=10 -endpoint=http://grpc-proxy-addr:23791
test done
total 100 task
0 task failed
current revision is 631490
least revision is 631490
0 task is not synced
參數說明：
num 任務數量
span 更新間隔，單位毫秒
duration 總測試時間，單位秒
current revision：代表寫入的 revision
least revision：表示 num 個任務中同步最慢的 revision
failed 為 0 說明正常；如果過出現 task not sync 說明 watch 和 put 不同步
以上測試結果來看：failed 數為 0，watch 測試正常
zk2etcd
我們使用的是 1.2.5 版本，通過 k8s 的 deployment 方式部署
模擬 zk server 失聯
場景
通過將 hosts 中注入錯誤解析地址
現象
期間沒有發現 zk 失聯的報錯日志
監控指標沒有發現異常
此后執行重啟，fixed 操作數沒有出現凸增情況（在 1.2.4 版本中，存在 full sync 雖然在定時執行，但是並沒有感知到需要 fix 的 key 的 bug。導致重啟 zk2etcd 服務實例后，可能觀察到 fixed 操作凸增的現象）
模擬 redis 失聯
模擬操作
09:56:49 將 hosts 中注入 redis 錯誤解析地址
10:07:34 恢復 redis
10:16:00 重啟同步服務 pod（操作重啟是為了觀察 full sync 是否正常）
現象
期間 fixed operation 數量沒有增長，其他監控指標未發現明顯異常
實例重啟后沒有出現 fixed 數凸增的情況
模擬etcd失聯
模擬操作
16:15:10 etcd server 失聯
16:30 恢復
16:45 重啟 pod
現象
期間 fixed operation 數量沒有增長，其他監控指標未發現明顯異常
此后重啟，fixed operation 數量有所增漲（不能確定是 full sync 未生效，還是重啟后剛好有更新修復導致）
總結
只要 full sync 機制工作正常，各異常場景發生后，都能在下一個 full sync 觸發后被恢復
恢復的最小時間間隔取決於設置的 full sync 定時執行間隔時間（默認為 5m），業務對此間隔時間容忍情況自行調整參數
此外，為了避免異常發生后，full sync 機制定時運行但也沒能感知到情況發生，保險起見事后可以第一時間重啟一下 zk2etcd 服務
對於追加的 etcd 公網測試，full sync completed 和 zk、etcd 操作耗時，相比內網情況有一定（秒級）增長
etcd2etcd
etcd2etcd 的同步服務，我采用 deployment 雙副本部署
多副本 backup 能力
期望
⼯作節點故障后備⽤節點會在 5s 后接管同步任務
測試方案
etcd syncer 雙實例部署
殺掉正在運行的工作節點進行觀察
結論
不論是增量同步還是全量同步過程中，主備切換都能正常工作（需要注意的是，當全量同步中發生主備切換后會變為增量同步，從而可能導致比對較慢）
斷點續傳能力
期望
故障恢復后能從斷點繼續開始同步
其實在第 1 部分，備節點切換為主后接管同步工作，fast_path 變為 1 也證明了斷點續傳能力，我們還額外補充幾個驗證場景：
(a) 短時間故障
故障場景
中心 etcd 集群到熱備集群的同步過程中，因作為源的中心 etcd 集群中也存在 -etcd-syncer-meta- 的 key，觸發了同步服務報錯（同 txn 中不能包含相同的 key），出現了數據差異
現象
將同步服務運行參數添加對 -etcd-syncer-meta- 的過濾，然后觀察進過一段時間追趕數據后，最終 miss 數降去達到一致
(b) 長時間故障
故障場景
停止同步服務的部署 deployment
等待兩邊 etcd 集群產生數據差異，並發生一次 compact 后再啟動同步服務
現象
等產生數據差異，並發生 compact 后，重新啟動同步服務，其日志如下：因 compacted 發生，觸發全量同步
同步服務監控指標：(a) dst miss key 很快降下去；(b) src miss key 有所增加，並持續不降
分析
同步服務停止以后，源 etcd 的 key 數量發生不少變化，監控圖看出期間有下降，說明發生過 key 的刪除
這里也暴露出一個小問題，當出現 src miss key 的時候，目前不能自動修復，需要人工接入清理多余的 key
- reset 觸發全量同步
當同步發生重大差異（如，發生 dst miss）進行緊急修復的時候，通過配置 --reset-last-synced-rev 參數刪除斷點續傳信息，來觸發全量同步修復差異
現象
因某種異常，同步出現 dst miss（圖中黃線實例）的情況。為了進行修復，新實例添加 --reset-last-synced-rev 參數后運行
分析
slow_path 為 1，說明觸發全量同步（圖中綠線實例）
綠線實例的 dst miss 值沒有增長起來，說明已經達到一致
- 網絡故障
兩 etcd 集群之間專線中斷
增量同步中
全量同步中
測試方案
當專線中斷切換公網時，需要修改運行參數中的 etcd 集群訪問地址，即：必會發生重啟（重啟場景測試前面已經涵蓋，這里不再重復）
總結
etcd-syncer 同步服務有較好的主備機制，能夠及時有效的進行切換
短時間故障后的斷點續傳表現符合預期；對於長時間故障，同時發生 compact 的復雜情況時，恢復同步后出現 src miss 的情況，可能需要人工接入
通過配置 --reset-last-synced-rev 參數對 src miss 的異常修復有較好的效果
關於我們
更多關於雲原生的案例和知識，可關注同名【騰訊雲原生】公眾號~
福利：公眾號后台回復【手冊】，可獲得《騰訊雲原生路線圖手冊》&《騰訊雲原生最佳實踐》~
【騰訊雲原生】雲說新品、雲研新術、雲游新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
