蚂蚁金服服务注册中心数据一致性方案分析 | SOFARegistry 解析

SOFAStack （Scalable Open Financial Architecture Stack）是蚂蚁金服自主研发的金融级云原生架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。

SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。

本文为《剖析 | SOFARegistry 框架》第七篇，本篇作者明不二。《剖析 | SOFARegistry 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：SOFA:RegistryLab/，文末包含往期系列文章。

GitHub 地址：https://gitee.com/sofastack/sofa-registry

概述

在前面的文章已经做过介绍，与其他注册中心相比，SOFARegistry 主要特点在于支持海量数据、支持海量客户端、秒级的服务上下线通知以及高可用特性。本文将从如下几个方面来讲述 SOFARegistry 的一致性方案：

MetaServer 数据一致性

为支持高可用特性，对于 MetaServer 来说，存储了 SOFARegistry 的元数据，为了保障 MetaServer 集群的一致性，其采用了 Raft 协议来进行选举和复制。

SessionServer 数据一致性

为支持海量客户端的连接，SOFARegistry 在客户端与 DataServer 之间添加了一个 SessionServer 层，客户端与 SessionServer 连接，避免了客户端与 DataServer 之间存在大量连接所导致的连接数过多不可控的问题。客户端通过 SessionServer 与 DataServer 连接的时候，Publisher 数据同时会缓存在 SessionServer 中，此时就需要解决 DataServer 与 SessionServer 之间数据一致性的问题。

DataServer 数据一致性

为支持海量数据，SOFARegistry 采用了一致性 Hash 来分片存储 Publisher 数据，避免了单个服务器存储全量数据时产生的容量瓶颈问题。而在这个模型中，每个数据分片拥有多个副本，当存储注册数的 DataServer 进行扩容、缩容时，MetaServer 会把这个变更通知到 DataServer 和 SessionServer，数据分片会在集群内部进行数据迁移与同步，此时就出现了 DataServer 内部数据的一致性问题。

MetaServer 数据一致性

MetaServer 在 SOFARegistry 中，承担着集群元数据管理的角色，用来维护集群成员列表，可以认为是 SOFARegistry 注册中心的注册中心。当 SessionServer 和 DataServer 需要知道集群列表，并且需要扩缩容时，MetaServer 将会提供相应的数据。

图1 MetaServer 内部结构图源自《蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析》

因为 SOFARegistry 集群节点列表数据并不是很多，因此不需要使用数据分片的方式在 MetaServer 中存储。如图 1 所示，集群节点列表存储在 Repository 中，上面通过 Raft 强一致性协议对外提供节点注册、续约、列表查询等 Bolt 请求，从而保障集群获得的数据是强一致性的。

Raft 协议

关于 Raft 协议算法，具体可以参考 The Raft Consensus Algorithm 中的解释。在 SOFA 体系中，对于 Raft 协议有 SOFAJRaft 实现。下面对 Raft 协议算法的原理进行简要介绍。

Raft 协议由三个部分组成，领导人选举（Leader Election）、日志复制（Log Replication）、安全性（Safety）。

领导人选举

通过一定的算法选举出领导人，用于接受客户端请求，并且把指令追加到日志中。

图2 Raft 状态机状态转换图图源自Understanding the Raft consensus algorithm: an academic article summary

日志复制

领导人接受到客户端请求之后，把操作追加到日志中，同时与其他追随者同步消息，最终 Commit 日志，并且把结果返回给客户端。

图3 复制状态机图源自 Raft一致性算法笔记

安全性

安全性保证了数据的一致性。

基于 Raft 协议的数据一致性保障

图4 SOFARegistry 中的 Raft 存储过程图源自《蚂蚁金服服务注册中心 MetaServer 功能介绍和实现剖析 | SOFARegistry 解析》

如图 4 所示，SOFARegistry 中的 Raft 协议数据存储经历了如上的一些流程。客户端发起 Raft 协议调用，进行数据注册、续约、查询等操作时，会通过动态代理实现 ProxyHandler 类进行代理，通过 RaftClient 把数据发送给 RaftServer ，并且通过内部的状态机 Statemachine ，最终实现数据的操作，从而保证了 MetaServer 内部的数据一致性。

SessionServer 数据一致性

SessionServer 在 SOFARegistry 中，承担着会话管理及连接的功能。同时，Subscriber 需要通过 SessionServer 来订阅 DataServer 的服务数据，Publisher 需要通过 SessionServer 来把服务数据发布到 DataServer 中。

在这个场景下，SessionServer 作为中间代理层，缓存从 DataServer 中获取的数据成了必然。DataServer 的数据需要通过 SessionServer 推送到 Subscriber 中，触发 SessionServer 推送的场景有两个：一个是 Publisher 到 DataServer 的数据发生变化；另外一个是 Subscriber 有了新增。

而在实际的场景中，Subscriber 新增的情况更多，在这种场景下，直接把 SessionServer 缓存的数据推送到 Subscriber 中即可，能够大大减轻 SessionServer 从 DataServer 获取数据对 DataServer 的压力。因此，这也进一步确认了在 SessionServer 缓存数据的必要性。

图5 两种场景的数据推送对比图

SessionServer 与 DataServer 数据对比机制

当服务 Publisher 上下线或者断连时，相应的数据会通过 SessionServer 注册到 DataServer 中。此时，DataServer 的数据与 SessionServer 会出现短暂的不一致性。为了保障这个数据的一致性，DataServer 与 SessionServer 之间通过 推 和 拉 两种方式实现了数据的同步。

数据推送模式

DataServer 在服务数据有变化时会主动通知到 SessionServer 中，此时 SessionServer 会比对两者数据的版本号 version ，对比之后若需要更新数据，则会主动向 DataServer 获取相应的数据。

数据拉取模式

SessionServer 会每隔一定的时间（默认 30s）主动向 DataServer 查询所有 dataInfoId 的 version 信息，若发现有版本号有变化，则会进行相应的同步操作。

SessionServer 从 DataServer 同步数据：常规情况下，一般是 DataServer 的数据要比 SessionServer 更新，此时，当 SessionServer 发现数据版本号有变化时，会主动拉取 DataServer 的数据进行同步。注意，此时缓存的数据只与当前 SessionServer 管理的客户端所订阅的服务信息有关，并不会缓存全量的数据，而且容量也不允许。
DataServer 从 SessionServer 同步数据：特殊情况下，DataServer 数据出现缺失，并且副本数据也出现问题之后，当 SessionServer 与 DataServer 数据进行版本号比对时，会触发数据恢复操作，能够把 SessionServer 内存中所存储的全量数据恢复到 DataServer 中，实现了数据的反向同步与补偿机制。
数据的缓存方式

SOFARegistry 中采用了 LoadingCache<Key, Value> 的数据结构来在 SessionServer 中缓存从 DataServer 中同步来的数据。每个 cache 中的 entry 都有过期时间，在拉取数据的时候可以设置过期时间（默认是 30s），使得 cache 定期去 DataServer 查询当前 session 所有 sub 的 dataInfoId，对比如果 session 记录的最近推送version（见com.alipay.sofa.registry.server.session.store.SessionInterests#interestVersions ）比 DataServer 小，说明需要推送，然后 SessionServer 主动从 DataServer 获取该 dataInfoId 的数据(此时会缓存到 cache 里)，推送给 client。

同时，当 DataServer 中有数据更新时，也会主动向 SessionServer 发请求使对应 entry 失效，从而促使 SessionServer 去更新失效 entry。

SessionServer 与 Subscriber 之间的数据一致性同步

当 SessionServer 的数据发生变更时，会与 Subscriber 之间进行数据同步，把变化的 dataInfoId 数据推送到 Subscriber 中，保证客户端本地所缓存的数据与 SessionServer 中的一致。

DataServer 数据一致性

DataServer 在 SOFARegistry 中，承担着核心的数据存储功能。数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。

如果 DataServer 宕机，MetaServer 能感知，并通知所有 DataServer 和 SessionServer，数据分片可 failover 到其他副本，同时 DataServer 集群内部会进行分片数据的迁移。

DataServer 请求接收过程

在讲解一致性之前，先讲一下 DataServer 的启动之后关于数据同步方面做了哪些事情。DataServer 启动之时，会启动一个数据同步 Bolt 服务 openDataSyncServer ，进行相应的 DataServer 数据同步处理。

启动 DataSyncServer 时，注册了如下几个 handler 用于处理 bolt 请求：

图5 DayaSyncServer 注册的 Handler

getDataHandler

该 Handler 主要用于数据的获取，当一个请求过来时，会通过请求中的 DataCenter 和 DataInfoId 获取当前 DataServer 节点存储的相应数据。

publishDataProcessor \ unPublishDataHandler

当有数据发布者 publisher 上下线时，会分别触发 publishDataProcessor 或 unPublishDataHandler ，Handler 会往 dataChangeEventCenter 中添加一个数据变更事件，用于异步地通知事件变更中心数据的变更。事件变更中心收到该事件之后，会往队列中加入事件。此时 dataChangeEventCenter 会根据不同的事件类型异步地对上下线数据进行相应的处理。

与此同时，DataChangeHandler 会把这个事件变更信息通过 ChangeNotifier 对外发布，通知其他节点进行数据同步。

notifyFetchDatumHandler

这是一个数据拉取请求，当该 Handler 被触发时，通知当前 DataServer 节点进行版本号对比，若请求中数据的版本号高于当前节点缓存中的版本号，则会进行数据同步操作，保证数据是最新的。

notifyOnlineHandler

这是一个 DataServer 上线通知请求 Handler，当其他节点上线时，会触发该 Handler，从而当前节点在缓存中存储新增的节点信息。用于管理节点状态，究竟是 INITIAL 还是 WORKING 。

syncDataHandler

节点间数据同步 Handler，该 Handler 被触发时，会通过版本号进行比对，若当前 DataServer 所存储数据版本号含有当前请求版本号，则会返回所有大于当前请求数据版本号的所有数据，便于节点间进行数据同步。

dataSyncServerConnectionHandler

连接管理 Handler，当其他 DataServer 节点与当前 DataServer 节点连接时，会触发 connect 方法，从而在本地缓存中注册连接信息，而当其他 DataServer 节点与当前节点断连时，则会触发 disconnect 方法，从而删除缓存信息，进而保证当前 DataServer 节点存储有所有与之连接的 DataServer 节点。

最终一致性

SOFARegistry 在数据存储层面采用了类似 Eureka 的最终一致性的过程，但是存储内容上和 Eureka 在每个节点存储相同内容特性不同，采用每个节点上的内容按照一致性 Hash 数据分片来达到数据容量无限水平扩展能力。

SOFARegistry 是一个 AP 分布式系统，表明了在已有条件 P 的前提下，选择了 A 可用性。当数据进行同步时，获取到的数据与实际数据不一致。但因为存储的信息为服务的注册节点，尽管会有短暂的不一致产生，但对于客户端来说，大概率还是能从这部分数据中找到可用的节点，不会因为数据暂时的不一致对业务系统带来致命性的伤害。

集群内部数据迁移过程

SOFARegistry 的 DataServer 选择了“一致性 Hash分片”来存储数据。在“一致性 Hash分片”的基础上，为了避免“分片数据不固定”这个问题，SOFARegistry 选择了在 DataServer 内存里以 dataInfoId 的粒度记录操作日志，并且在 DataServer 之间也是以 dataInfoId 的粒度去做数据同步。

图6 DataServer 之间进行异步数据同步

数据和副本分别分布在不同的节点上，进行一致性 Hash 分片，当时对主副本进行写操作之后，主副本会把数据异步地更新到其他副本中，实现了集群内部不同副本之间的数据迁移工作。

总结

在分布式系统的设计中，可用性、分区容错性、一致性是我们必须进行权衡的选项，CAP 理论告诉我们，这三者中只能同时满足两个的要求。在设计分布式系统时，如何进行权衡选择，是摆在每个系统设计者面前的一个难题。

SOFARegistry 系统分为三个集群，分别是元数据集群 MetaServer、会话集群 SessionServer、数据集群 DataServer。复杂的系统有多个地方需要考虑到一致性问题，SOFARegistry 针对不同模块的一致性需求也采取了不同的方案。对于 MetaServer 模块来说，采用了强一致性的 Raft 协议来保证集群信息的一致性。对于数据模块来说，SOFARegistry 选择了 AP 保证可用性，同时保证了最终一致性。

SOFARegistry 的设计给了我们启示，在设计一个多模块的分布式系统时，可以根据不同模块的需求选择不同的一致性方案，同时 CAP 三者的权衡也需要结合系统不同模块的目标作出合理的权衡，不必拘泥。

SOFARegistryLab 系列阅读

来源：oschina

链接：https://my.oschina.net/sofastack/blog/3187743

标签

SOFARegistry