Nacos 支持 CP（强一致性） 和 AP（最终一致性/高可用） 两种数据模型（一致性模型）。

这是 Nacos 相比于 Eureka（仅 AP）和 Zookeeper（仅 CP）的一个主要优势，它允许用户根据具体的业务场景在 CAP 理论中的 C（一致性）和 A（可用性）之间进行选择。

以下是这两种模型的详细对比：

1. CP 模型 (Consistency & Partition Tolerance)

• 核心特点：强一致性。
• 底层协议：使用 Raft 协议（一种分布式一致性算法）。
• 工作机制：
  • 当向 Nacos 集群写入数据时，必须等待大多数节点（Quorum）确认写入成功后，才向客户端返回成功。
  • 如果集群出现网络分区或 Leader 节点宕机，集群在重新选举出 Leader 之前无法处理写请求，从而保证数据的一致性，但牺牲了短暂的可用性。
• 适用场景：
  • 配置管理 (Config Service)：配置数据通常要求强一致性（例如数据库连接串、业务开关），不能出现不同节点读到不同配置的情况。
  • 持久化服务 (Persistent Services)：注册为“持久化”的服务实例（如数据库节点、Redis 集群节点），即使心跳丢失，Nacos 也不会直接剔除，而是标记为不健康。

2. AP 模型 (Availability & Partition Tolerance)

• 核心特点：高可用性 / 最终一致性。
• 底层协议：使用 Distro 协议（Nacos 自研的点对点同步协议）。
• 工作机制：
  • 数据写入任何一个节点后，该节点会立即返回成功，然后异步地将数据同步给其他节点。
  • 当集群出现网络分区时，各个节点依然可以对外提供服务，保证服务的高可用，但不同节点上的数据在短时间内可能不一致（最终会一致）。
• 适用场景：
  • 非持久化/临时服务 (Ephemeral Services)：这是 Spring Cloud 微服务架构中最常见的场景。微服务实例通常是随时可能启停的（如 K8s 中的 Pod），如果某个实例宕机，服务发现组件应该尽快感知，但即使短时间内读到了旧列表（包含已宕机的节点），通常也有客户端重试机制容错。相比之下，保证服务发现接口随时可用更为重要。

如何切换/决定使用哪种模型？

Nacos 根据服务注册时实例的属性来决定使用哪种模型：

• 临时实例 (Ephemeral = true) -> AP 模型
  • 默认模式（Spring Cloud Alibaba 默认即为临时实例）。
  • 实例通过心跳维持存活，心跳消失则直接剔除。
• 持久实例 (Ephemeral = false) -> CP 模型
  • 实例注册后永久存在，心跳消失仅标记为不健康。

切换方式（客户端代码示例）：

# 设置为非临时实例（开启 CP 模式）
spring.cloud.nacos.discovery.ephemeral=false