背景
Distro 协议是 Nacos 社区自研的一种 AP 分布式协议,是面向临时实例设计的一种分布式协议,其保证了在某些 Nacos 节点宕机后,整个临时实例处理系统依旧可以正常工作。
作为一种有状态的中间件应用的内嵌协议,Distro 保证了各个 Nacos 节点对于海量注册请求的统一协调和存储。
设计思想
Distro 协议的主要设计思想如下:
-
Nacos 每个节点是平等的都可以处理写请求,同时把新数据同步到其他节点。
-
每个节点只负责部分数据,定时发送自己负责数据的校验值到其他节点来保持数据一致性。
-
每个节点独立处理读请求,及时从本地发出响应。
下面几节将分为几个场景进行 Distro 协议工作原理的介绍。
数据初始化
新加入的 Distro 节点会进行全量数据拉取。
具体操作是轮询所有的 Distro 节点,通过向其他的机器发送请求拉取全量数据。
数据校验
在 Distro 集群启动之后,各台机器之间会定期的发送心跳。
心跳信息主要为各个机器上的所有数据的元信息(之所以使用元信息,是因为需要保证网络中数据传输的量级维持在一个较低水平)。
这种数据校验会以心跳的形式进行,即每台机器在固定时间间隔会向其他机器发起一次数据校验请求。
一旦在数据校验过程中,某台机器发现其他机器上的数据与本地数据不一致,则会发起一次全量拉取请求,将数据补齐。
写操作
对于一个已经启动完成的 Distro 集群,在一次客户端发起写操作的流程中,当注册非持久化的实例的写请求打到某台 Nacos 服务器时,Distro 集群处理的流程图如下。
整个步骤包括几个部分(图中从上到下顺序):
-
前置的 Filter 拦截请求,并根据请求中包含的 IP 和 port 信息计算其所属的 Distro 责任节点,并将该请求转发到所属的 Distro 责任节点上。
-
责任节点上的 Controller 将写请求进行解析。
-
Distro 协议定期执行 Sync 任务,将本机所负责的所有的实例信息同步到其他节点上。
读操作
由于每台机器上都存放了全量数据,因此在每一次读操作中,Distro 机器会直接从本地拉取数据。快速响应。
这种机制保证了 Distro 协议可以作为一种 AP 协议,对于读操作都进行及时的响应。
在网络分区的情况下,对于所有的读操作也能够正常返回;当网络恢复时,各个 Distro 节点会把各数据分片的数据进行合并恢复。
小结
Distro 协议是 Nacos 对于临时实例数据开发的一致性协议。其数据存储在缓存中,并且会在启动时进行全量数据同步,并定期进行数据校验。
在 Distro 协议的设计思想下,每个 Distro 节点都可以接收到读写请求。所有的 Distro 协议的请求场景主要分为三种情况:
1、当该节点接收到属于该节点负责的实例的写请求时,直接写入。
2、当该节点接收到不属于该节点负责的实例的写请求时,将在集群内部路由,转发给对应的节点,从而完成读写。
3、当该节点接收到任何读请求时,都直接在本机查询并返回(因为所有实例都被同步到了每台机器上)。
Distro 协议作为 Nacos 的内嵌临时实例一致性协议,保证了在分布式环境下每个节点上面的服务信息的状态都能够及时地通知其他节点,可以维持数十万量级服务实例的存储和一致性。
chat
介绍一下 distro
Nacos 的 Distro 协议 是一种为分布式场景设计的轻量级一致性协议,主要用于服务注册与配置中心中的数据同步和一致性保障。
与 Paxos 或 Raft 不同,Distro 是一种最终一致性协议,重点关注系统的高可用性和性能,适合对一致性要求较弱的场景。
以下是对 Nacos 自研 Distro 协议的详细介绍:
一、背景
Nacos 是阿里巴巴开源的服务发现与配置管理工具,广泛应用于微服务架构中。
Nacos 面临以下需求:
- 高性能:服务注册中心需要快速响应大量的读写操作。
- 高可用性:系统需要具备一定的容错能力,尤其是在部分节点失效或网络分区时。
- 最终一致性:允许数据在短时间内不一致,但需保证最终达到一致状态。
为满足这些需求,Nacos 设计了 Distro 协议,用来同步服务实例和元数据。
二、Distro 协议的核心思想
Distro 协议的设计遵循以下核心思想:
- 分布式数据分片:
- Distro 按照数据的哈希值对其进行分片,并分发到不同的 Nacos 节点。
- 每个节点只负责处理和维护自己负责的数据分片。
- 节点间通过异步复制和心跳机制实现数据同步。
- 最终一致性:
- Distro 并不追求强一致性,允许短时间内的数据不一致性,但通过定期的同步和冲突解决,最终达到一致性。
- 去中心化设计:
- Distro 没有专门的 Leader 节点,每个节点平等且独立,可以自行处理其分片内的数据。
- 异步通信:
- 数据同步采用异步通信方式,降低延迟和系统负载。
三、Distro 协议的工作机制
Distro 协议通过以下几个关键步骤实现数据同步和一致性:
1. 数据分片
- 数据分片的规则基于一致性哈希算法。
- 每个节点根据哈希值分配部分数据,并称为这些数据的“责任节点”。
- 数据的分片信息可以根据节点变化动态调整。
2. 数据同步
- 增量同步:
- 当某节点的数据发生变化时(如新增或修改服务实例),它会将变化的数据异步发送到其他节点。
- 全量同步:
- 当节点新加入集群或从故障中恢复时,它会向其他节点请求全量数据同步。
- 双向同步:
- 每个节点既可以是数据的发送方,也可以是接收方,确保系统中所有数据最终一致。
3. 数据存储
- 每个节点存储两类数据:
- 本地负责的数据分片。
- 从其他节点同步的数据。
4. 数据失效检测
- 使用心跳机制检测节点状态。
- 当一个节点失效时,其负责的数据分片会被重新分配给其他节点。
四、Distro 协议的容错机制
- 节点失效处理:
- Nacos 会通过心跳检测到节点失效,并将该节点的数据重新分配给其他存活节点。
- 数据重新分配采用哈希重新平衡机制,避免数据丢失。
- 网络分区处理:
- 在网络分区情况下,各分区内的节点继续对数据进行操作。
- 网络恢复后,分区内的数据会通过冲突解决机制同步到全网,最终达到一致。
- 数据冲突解决:
- Distro 使用时间戳或版本号作为数据冲突的解决依据。
- 当两个节点的数据冲突时,以最新版本的数据为准。
五、Distro 协议的优势和局限性
优势
- 高性能:
- 异步通信和去中心化设计,使其能够快速响应大量的读写请求。
- 高可用性:
- 节点失效或网络分区时,系统仍可提供部分服务,具备容错能力。
- 实现简单:
- 不需要复杂的选主机制和投票过程,降低了实现成本。
局限性
- 一致性弱:
- 短时间内可能出现数据不一致的情况,不适合需要强一致性的场景。
- 网络复杂性:
- 在大规模集群中,异步数据同步可能增加网络开销。
- 冲突解决成本:
- 数据冲突的处理需要额外的逻辑,可能会增加延迟。
六、Distro 协议的典型应用场景
Distro 协议主要应用于对一致性要求较低,但性能和可用性要求较高的场景,例如:
- 服务注册与发现:
- 微服务实例的注册、注销和元数据同步。
- 允许服务发现在短时间内返回稍旧的数据。
- 分布式配置管理:
- 配置的分发与同步,适合不要求强实时同步的配置更新场景。
七、与其他协议的对比
特性 | Paxos/Raft | Distro |
---|---|---|
一致性 | 强一致性 | 最终一致性 |
可用性 | 中等(需等待多数确认) | 高(异步同步不阻塞操作) |
容错性 | 高 | 较高 |
性能 | 较低(同步通信开销较大) | 高 |
适用场景 | 分布式数据库、高一致性场景 | 服务发现、配置管理 |
八、总结
Nacos 的 Distro 协议是针对服务注册和配置同步优化的轻量级一致性协议。
它通过数据分片、异步同步和去中心化设计实现高性能和高可用性,同时在保证最终一致性的基础上降低了系统复杂性。
虽然它不适合强一致性需求的场景,但对于微服务场景中的服务注册与发现、配置管理等场景具有很高的实用价值。
参考资料
https://nacos.io/docs/ebook/ktwggk/