作者
孔令圳，斗鱼首席架构师，全面担任斗鱼全站技能架构体系规划和建造，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 的反常修正有较好的效果
关于咱们
更多关于云原生的事例和知识，可重视同名【腾讯云原生】大众号~
福利：大众号后台回复【手册】，可取得《腾讯云原生路线图手册》&《腾讯云原生最佳实践》~
