播面 Nacos 使用了哪些一致性协议？
Nacos 为了满足不同场景下的需求（CAP 理论中的 AP 和 CP），主要使用了两种一致性协议：Distro 协议 和 Raft 协议。
Nacos 的独特之处在于它同时支持这两种协议，允许用户根据业务场景选择强一致性还是最终一致性。
以下是详细的解析：
1. Distro 协议 (AP 模式 - 最终一致性)
Distro 是阿里巴巴（Nacos 团队）自研的一种点对点（Peer-to-Peer）的一致性协议。
- 应用场景： 主要用于服务发现（Naming Service）中的非持久化（临时）实例。
- 在微服务架构中，绝大多数服务实例（如 K8s 中的 Pod）都是临时的，随时可能销毁和重建。对于服务发现来说，可用性（Availability）通常比强一致性更重要（宁可读到旧数据，也不能读不到数据）。
- 核心机制：
- 数据分片： Nacos Server 集群将数据分片，每个节点负责一部分数据的写入。
- 对等同步： 当一个节点收到注册请求后，它会处理该请求，并异步地将数据同步给集群中的其他节点。
- 最终一致性： 它是弱一致性的，不保证所有节点在同一时刻数据完全一致，但保证在一段时间后数据最终一致。
- 抗网络分区： 如果发生网络分区，各分区的节点依然可以对外提供服务。
- 新节点加入： 当新节点加入集群时，会轮询其他节点获取全量数据。
2. Raft 协议 (CP 模式 - 强一致性)
Raft 是目前业界最通用的分布式共识协议（Etcd、Consul 等都在用）。Nacos 采用了基于 Java 实现的 JRaft 库。
- 应用场景：
- 配置中心（Config Service）： 配置数据必须保证强一致性，不能出现不同节点读到不同配置的情况。
- 服务发现（Naming Service）中的持久化实例：例如传统的数据库节点，IP 基本不变，需要保证强一致性。
- 核心机制：
- Leader 选举： 集群中必须选举出一个 Leader，所有的写请求都必须由 Leader 处理。
- 日志复制： Leader 将变更以日志的形式复制给 Follower 节点。
- 过半提交： 只有当超过半数（N/2 + 1）的节点确认收到日志后，该变更才会被提交并生效。
- 特点： 保证了数据的强一致性，但在 Leader 选举期间或发生网络分区导致无法选主时，集群可能暂时不可用（牺牲可用性）。
总结与对比
Nacos 通过一个智能的架构将这两种协议结合在一起：
| 特性 | Distro 协议 | Raft 协议 |
|---|---|---|
| 一致性模型 | AP (可用性 + 分区容错性) | CP (一致性 + 分区容错性) |
| 一致性级别 | 最终一致性 | 强一致性 |
| 主要用途 | 服务发现（临时实例，默认模式） | 配置中心、服务发现（持久化实例） |
| 写操作 | 每个节点都可以处理写请求（分片机制） | 只有 Leader 节点处理写请求 |
| 性能 | 高（无须等待大多数节点确认） | 中（需等待过半节点确认） |
| 适用场景 | 高并发、高吞吐、对实时性要求不极端的服务注册 | 核心配置管理、对数据准确性要求极高的元数据 |
如何切换？
在 Nacos 的服务注册中，你可以通过请求参数 ephemeral 来控制：
ephemeral=true（默认）：使用 Distro 协议（AP）。ephemeral=false：使用 Raft 协议（CP）。
这种设计使得 Nacos 既能像 Eureka 一样提供高可用的服务发现（AP），又能像 ZooKeeper/Consul 一样提供强一致性的配置管理和服务治理（CP）。