Nacos 的AP和CP底层是怎么实现的？

Nacos 作为一款动态服务发现、配置管理和服务管理平台，支持 AP（可用性和分区容错性） 和 CP（一致性和分区容错性） 两种模式，分别适用于不同的业务场景。以下是新版本（如 2.x）中 AP 和 CP 模式的底层实现原理：

---

1. AP 模式（Distro 协议）

AP 模式是 Nacos 的默认模式，适用于临时实例（如微服务），强调高可用性，采用 Distro 协议（阿里巴巴自研的 AP 协议）实现最终一致性。

核心实现机制

1. 数据分片与责任机制

   • 每个 Nacos 节点负责一部分数据（基于服务名或实例 IP 的哈希计算）。
   • 写请求会被路由到负责该数据的节点（称为 责任节点），处理完成后异步同步给其他节点。

2. 异步数据同步

   • 责任节点处理写请求后，通过 增量同步 方式广播给其他节点。
   • 若同步失败，会进行重试，但不阻塞主流程，保证高可用性。

3. 临时实例管理

   • 临时实例数据仅存储在内存，不会持久化到磁盘。
   • 客户端通过 心跳机制（HTTP/gRPC）保活，超时（默认 15s 不健康，30s 剔除）后自动清理。

4. 健康检查

   • 客户端主动上报心跳（HTTP 或 gRPC 长连接）。
   • 服务端定时检查心跳，超时则标记为不健康或剔除。

适用场景

• 微服务注册与发现（如 Spring Cloud 应用）。
• 对高可用性要求高，允许短暂数据不一致。

---

2. CP 模式（Raft 协议）

CP 模式适用于永久实例（如数据库、Redis 等），强调强一致性，采用 Raft 算法 保证数据一致性。

核心实现机制

1. Leader 选举

   • 集群通过 Raft 协议选举 Leader，只有 Leader 能处理写请求。
   • Follower 节点转发写请求到 Leader。

2. 日志复制

   • Leader 将写操作记录到日志，并同步给 Follower。
   • 需 半数以上节点 ACK 才算成功，确保数据强一致性。

3. 持久化存储

   • 数据会持久化到磁盘，即使节点重启也能恢复。
   • 适用于永久实例（如 MySQL 注册信息）。

4. 健康检查

   • 服务端主动探测（TCP/HTTP/MySQL 检查）。
   • 不依赖客户端心跳，适合无法主动上报的服务。

适用场景

• 需要强一致性的场景（如配置中心）。
• 注册基础设施服务（如数据库、中间件）。

---

3. AP 与 CP 模式对比

特性	AP 模式（Distro）	CP 模式（Raft）
一致性	最终一致性	强一致性
可用性	高（容忍节点故障）	低（选举期间不可用）
数据存储	内存（临时实例）	磁盘（永久实例）
同步方式	异步批量同步	同步日志复制
适用实例	临时实例（微服务）	永久实例（数据库、Redis）

---

4. 模式切换

Nacos 允许通过配置切换 AP/CP 模式：

• 临时实例（AP）：spring.cloud.nacos.discovery.ephemeral=true（默认）。
• 永久实例（CP）：spring.cloud.nacos.discovery.ephemeral=false。

---

5. 版本差异（1.x vs 2.x）

• 1.x：HTTP 通信，临时/永久实例可混用。
• 2.x：默认 gRPC 长连接，提升性能；临时/永久实例由 服务级别 决定（同一服务只能选一种模式）。

---

总结

• AP 模式（Distro）适合微服务，高可用但最终一致。
• CP 模式（Raft）适合关键基础设施，强一致但牺牲部分可用性。
• Nacos 2.x 优化了通信协议（gRPC）和集群同步机制，性能更高。

如果需要更深入的实现细节，可参考 Nacos 源码中的 DistroConsistencyServiceImpl（AP）和 RaftConsistencyServiceImpl（CP）。