共计 4917 个字符，预计需要花费 13 分钟才能阅读完成。
文|宋国磊（GitHub ID：glmapper )
SOFAStack Committer、华米科技高级研发工程师
负责华米账号零碎、框架治理方向的开发
本文 3024 字 浏览 10 分钟
|前言|
本文次要围绕 SOFARegistry 的数据同步模块进行了源码的解析。其中，对于注册核心的概念以及 SOFARegistry 的基础架构将不再做具体的论述，有趣味的小伙伴在《海量数据下的注册核心 – SOFARegistry 架构介绍》[1] 一文中获取相干介绍。
本文次要的思路大抵分为以下 2 个局部：
– 第一局部，借助 SOFARegistry 中的角色分类来阐明哪些角色之间会进行数据同步；
– 第二局部，对数据同步的具体实现进行解析。
PART. 1——SOFARegistry 的角色分类
如上图所示，SOFARegistry 蕴含以下 4 个角色：
Client
提供利用接入服务注册核心的根本 API 能力，利用零碎通过依赖客户端 JAR 包，通过编程形式调用服务注册核心的服务订阅和服务公布能力。
SessionServer
会话服务器，负责承受 Client 的服务公布和服务订阅申请，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。
DataServer
数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，反对多正本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。\
MetaServer
元数据服务器，负责保护集群 SessionServer 和 DataServer 的统一列表，作为 SOFARegistry 集群外部的地址发现服务，在 SessionServer 或 DataServer 节点变更时能够告诉到整个集群。
在这 4 个角色中，MetaServer 作为元数据服务器自身不解决理论的业务数据，仅负责保护集群 SessionServer 和 DataServer 的统一列表，不波及数据同步问题。
Client 与 SessionServer 之间的外围动作是订阅和公布，从狭义上来说，属于用户侧客户端与 SOFARegistry 集群的数据同步，详情能够见：
https://github.com/sofastack/sofa-registry/issues/195，因而不在本文探讨领域之内。
SessionServer 作为会话服务，它次要解决海量客户端连贯问题，其次是缓存客户端公布的所有 pub 数据。Session 自身不长久化服务数据，而是将数据转写到 DataServer。DataServer 存储服务数据是依照 dataInfoId 进行一致性 Hash 分片存储的，反对多正本备份，保证数据高可用。
从 SessionServer 和 DataServer 的功能分析中能够得出：
SessionServer 缓存的服务数据须要与 DataServer 存储的服务数据保持一致 。
DataServer 反对多副原本保障高可用，因而 DataServer 多正本之间须要放弃服务数据统一。
SOFARegistry 中，针对上述两个对于数据的一致性保障就是通过数据同步机制来实现的。
PART. 2——数据同步的具体实现
理解了 SOFARegistry 的角色分类之后，咱们开始深刻数据同步具体的实现细节。我将次要围绕 SessionServer 和 DataServer 之间的数据同步，以及 DataServer 多正本之间的数据同步两块内容来开展。
「SessionServer 和 DataServer 之间的数据同步」
SessionServer 和 DataServer 之间的数据同步，是基于如下推拉联合的机制：
推： DataServer 在数据有变动时，会被动告诉 SessionServer，SessionServer 查看确认须要更新 （比照 version） 后被动向 DataServer 获取数据。
拉： 除了上述的 DataServer 被动推以外，SessionServer 每隔肯定的工夫距离，会被动向 DataServer 查问所有 dataInfoId 的 version 信息，而后再与 SessionServer 内存的 version 作比拟。若发现 version 有变动，则被动向 DataServer 获取数据。这个“拉”的逻辑，次要是对“推”的一个补充，若在“推”的过程中呈现错漏的状况能够在这个时候及时补救。
推和拉两种模式查看的 version 会有一些差别，这部分内容详见上面“推模式下的数据同步”和“拉模式下的数据同步”中的具体介绍。
「推模式下的数据同步流程」
推模式是通过 SyncingWatchDog 这个守护线程一直 loop 执行来实现数据变更检查和告诉发动的：
依据 slot 分组汇总数据版本。data 与每个 session 的连贯都对应一个 SyncSessionTask，SyncSessionTask 负责执行同步数据的工作，外围同步逻辑在：
com.alipay.sofa.registry.server.data.slot.SlotDiffSyncer#sync 办法中实现，大抵流程如下时序图所示：
上图圈红局部的逻辑第四步，依据 dataInfoId diff 更新 data 内存数据，能够看到这里仅解决了被移除的 dataInfoId，对于新增和更新的没有做工作解决，而是通过前面的第 5-7 步来实现。这么做的次要起因在于防止产生空推送而导致一些危险状况产生。
第 5 步中，比拟的是所有变更 dataInfoId 的 pub version，具体比拟逻辑能够参考前面 diffPublisher 大节中的介绍。
「数据变更的事件告诉解决」
数据变更事件会被收集在 DataChangeEventCenter 的 dataCenter2Changes 缓存中，而后由一个守护线程 ChangeMerger 负责从 dataCenter2Changes 缓存中一直的读取，这些被捞到的事件源会被组装成 ChangeNotifier 工作，提交给一个独自的线程池 (notifyExecutor) 解决，整个过程全副是异步的。
「拉模式下的数据同步流程」
拉模式下，由 SessionServer 负责发动，
com.alipay.sofa.registry.server.session.registry.SessionRegistry.VersionWatchDog
默认状况下每 5 秒扫描一次版本数据，如果版本有产生变更，则被动进行一次拉取，流程大抵如下：
须要留神的是，拉模式对推送流程的补充，这里的 version 是每个 sub 的 lastPushedVersion，而推模式的 version 是 pub 的数据的 version。对于 lastPushedVersion 的获取能够参考：
com.alipay.sofa.registry.server.session.store.SessionInterests#selectSubscribers
「DataServer 多正本之间的数据同步」
次要是 slot 对应的 data 的 follower 定期和 leader 进行数据同步，其同步逻辑与 SessionServer 和 DataServer 之间的数据同步逻辑差别不大；发动形式也是一样的；data 判断如果以后节点不是 leader，就会进行与 leader 之间的数据同步。
「增量同步 diff 计算逻辑剖析」
不论是 SessionServer 和 DataServer 之间的同步，还是 DataServer 多正本之间的同步，都是基于增量 diff 同步的，不会一次性同步全量数据。
本节对增量同步 diff 计算逻辑进行简略剖析，外围代码在：
com.alipay.sofa.registry.common.model.slot.DataSlotDiffUtils （倡议浏览这部分代码时间接联合代码中的测试用例来看）。
次要包含计算 digest 和 publishers 两个。
diffDigest
用 DataSlotDiffUtils#diffDigest 办法接管两个参数：
– targetDigestMap 能够了解为指标数据
– sourceDigestMap 能够了解为基线数据
外围计算逻辑如下代码剖析：
那么根据上述 diff 计算逻辑，这里有如下几种场景 （假如基线数据集数据中 dataInfoId 为 a 和 b）：
1. 指标数据集为空：返回 dataInfoId 为 a 和 b 两项作为新增项；
2. 指标数据集与基线数据集相等，新增项、待更新项与待移除项均为空；
3. 指标数据集中包含 a、b、c 三个 dataInfoId，则返回 c 作为待移除项；
4. 指标数据集中包含 a 和 c 两个 dataInfoId，则返回 c 作为待移除项，b 作为新增项
diffPublisher
diffPublisher 与 diffDigest 计算稍有不同，diffPublisher 接管三个参数，除了指标数据集和基线数据集之外，还有一个 publisherMaxNum （默认 400），用于限度每次解决的数据个数；这里同样给出外围代码解释：
这里同样对几种场景做一下剖析 （上面指的是更新 dataInfoId 对应的 publisher，registerId 与 publisher 一一对应）：
1. 指标数据集与基线数据集雷同，且数据没有超过 publisherMaxNum，返回的待更新和待移除均为空，且没有残余未解决数据；
2. 须要移除的状况：
基线中不包含指标数据集 dataInfoId 的 registerId （移除的是 registerId，不是 dataInfoId）
3. 须要更新的状况：
– 指标数据集中存在基线数据集不存在的 registerId
– 指标数据集和基线数据集存在的 registerId 的版本不同
PART. 3——总结
本文次要介绍了 SOFARegistry 中的数据同步模块。在整个过程中，咱们首先从 SOFARegistry 角色分类论述不同角色之间存在的数据同步问题，并针对其中 SessionServer 与 DataServer 之间的数据同步 和 DataServer 多正本之间的数据同步进行了开展。
在 SessionServer 与 DataServer 数据同步剖析中，着重剖析了推和拉两种场景下数据同步的整体流程。最初对 SOFARegistry 中数据减少的 diff 计算逻辑进行了介绍，并联合相干外围代码形容了具体的场景。
整体来看，SOFARegistry 在数据同步上的解决上有如下三点能够对咱们有所启发：
1. 在一致性方面，SOFARegistry 基于 ap，满足了最终一致性，并在理论的同步逻辑解决上，联合事件机制，根本都是异步化实现的，这样一来就无效弱化了数据同步对于外围流程的影响；
2. 在拉模式和数据变更告诉两个局部，外部采纳了相似“生产 - 生产模型”，一方面是对于生产和生产逻辑的解耦，从代码上更独立；另一方面通过缓存或者队列来打消生产和生产速度不同而导致的互相阻塞的问题；
3. 拉模式对推模式的补充；咱们晓得推模式是 server -> client，产生在数据变更时，如果呈现一些异样，导致某条 server -> client 链路推送失败，则会导致不同 client 持有的数据不统一的状况；拉模式的补充，让 client 能被动去实现对于数据一致性的查看。
【参考链接】
[1]《海量数据下的注册核心 – SOFARegistry 架构介绍》：https://www.sofastack.tech/blog/sofa-registry-introduction/
我的项目原文地址：https://www.sofastack.tech/projects/sofa-registry/code-analyze/code-analyze-data-synchronization/
理解更多
SOFARegistry Star 一下✨：\
https://github.com/sofastack/sofa-registry
本周举荐浏览
SOFARegistry 源码|数据分片之外围 - 路由表 SlotTable 分析
摸索 SOFARegistry（一）|基础架构篇
MOSN 构建 Subset 优化思路分享
Nydus —下一代容器镜像摸索实际
