nacos Distro 协议 vs Raft 协议

Posted on Views:

1.Nacos 两种一致性模型总览

Nacos 同时实现两套分布式协议：

协议 类型 一致性模型 使用场景
Distro AP 最终一致性 临时实例（ephemeral）
Raft CP 强一致性 持久实例（persistent）

2.Distro 协议（AP 模型）

2.1 核心特性

  • 去中心化（无 Leader）
  • 每个节点都可以写
  • 数据异步同步
  • 容忍网络分区

2.2 数据流（注册流程）

graph TD
A[客户端注册实例] --> B[任意Nacos节点]
B --> C[本地写入]
C --> D[异步同步到其他节点]

2.3 关键机制

数据分片（责任节点）

1
每个实例有一个“负责节点”（owner）
  • 通过 hash(ip+port) 决定
  • 只有 owner 负责同步

2.4 使用场景

1
ephemeral: true

典型：

  • 微服务实例注册
  • Kubernetes Pod
  • 临时节点

3.Raft 协议（CP 模型）

3.1 核心特性

  • 强一致性（线性一致）
  • 有 Leader
  • 写必须 quorum

3.2 数据流（写入流程）

graph TD
A[客户端写请求] --> B[Follower]
B --> C[重定向到Leader]
C --> D[写入日志]
D --> E[复制到Follower]
E --> F[多数节点确认]
F --> G[提交成功]

3.3 关键机制

Leader 选举

  • 多数投票选主
  • term 递增

日志复制

  • WAL（Write Ahead Log）
  • 顺序一致

3.4 优缺点

优点

  • 强一致性（无脏读）
  • 数据安全性高

缺点

  • 性能较低
  • 写入延迟高
  • 对网络敏感

3.5 使用场景

1
ephemeral: false

典型：

  • 配置中心
  • 持久服务注册
  • 关键元数据

4.核心对比（SRE视角）

维度 Distro Raft
CAP AP CP
一致性 最终一致 强一致
写入方式 任意节点 Leader
同步方式 异步 同步
性能 高 中
容错 高 中（依赖 quorum）
数据类型 临时实例 持久实例

5.为什么 Nacos 要双协议

设计动机

graph TD
A[服务发现需求] --> B[高性能]
A --> C[强一致]
B --> D[Distro]
C --> E[Raft]

解释

  • 服务注册（如 Pod）：

    • 更关心 可用性
    • 使用 Distro

  • 配置 / 持久实例：

    • 更关心 一致性
    • 使用 Raft