Nacos 是 AP 还是 CP？一文讲透！

在分布式系统中，CAP 定理告诉我们：一致性（C）、可用性（A）和分区容忍性（P）三者不可兼得。而 Nacos 作为一个兼具 服务注册中心 和 配置管理中心 的产品级组件，它同时支持 AP 和 CP 模式。

一、为什么 Nacos 能同时支持 AP 和 CP？

Nacos 的设计哲学：一个系统，两种能力，完美适配注册中心 & 配置中心
Nacos 并不是一个“非此即彼”的系统。它巧妙地在一个集群中同时支持 AP 模式（高可用） 和 CP 模式（强一致），背后的设计理念非常清晰

核心原因：兼顾两个核心场景的不同需求

对于注册中心（服务发现）—— AP 更合适 ✅

当网络分区或节点故障时，即使数据短暂不一致，也应尽量保证服务可以继续注册和发现～

• 实例可能已下线但未及时清理 → 导致调用失败；
• 但可以通过客户端重试机制缓解，比如负载均衡 + 健康检查；

一句话总结：“宁可暂时不一致，也不能不让服务注册和发现！”

对于配置中心（统一配置管理）—— CP 更合适 ✅

配置信息如数据库连接串、功能开关、权限策略等，必须确保所有节点获取到相同的值；
如果某些节点拿到的是旧配置，可能会导致业务异常甚至严重事故；
所以需要牺牲一点可用性来换取强一致性；

一句话总结：“配置不能错，哪怕服务暂时不可用！”

二、Nacos 默认是 AP 模式？

默认情况下，Nacos 使用的是 Distro 协议，属于 AP 系统：

• ✅ 高可用
• ⚠️ 若一致性
• 支持网络分区

如何切换为 CP 模式？
可以通过以下方式动态切换：

方式一：修改配置文件 application.properties

nacos.protocol=raft

方式二：调用管理接口动态切换

POST /v1/ns/operator/mode?endpoint=raft

实现原理：Distro vs Raft

协议	类型	特点
Distro	自研 AP 协议	分布式哈希表，每个节点负责一部分数据，适合临时实例（ephemeral）
Raft	标准 CP 协议	基于 JRaft 实现，保证数据强一致性

Distro 协议设计思想：

• 所有节点平等，都可以处理写请求；
• 新数据同步到其他节点；
• 每个节点只负责部分数据；
• 定期校验数据一致性；
• 每个节点独立响应读请求；
• 适用于服务注册与发现等对可用性要求高于一致性的场景。

Raft 协议实现方式：

• 基于百度开源的 braft，使用 Java 实现为 JRaft；
• 提供一致性状态机；
• 解决复制、修复、节点管理问题；
• 让开发者专注于业务逻辑，无需关注底层一致性细节；
• 适用于配置中心等需要强一致性的场景。

三、总结一句话

Nacos 是一个“双面派”：

• 对于服务注册 → 用 AP（Distro），高可用优先；
• 对于配置管理 → 用 CP（Raft），一致性优先；

并且支持运行时动态切换，灵活应对不同业务需求

场景	是否推荐使用 CP 模式	说明
配置中心	✅ 强烈推荐	配置如数据库连接串、权限开关必须保持一致性，否则可能导致严重后果。
注册中心	❌ 不推荐	更看重服务可用性，短暂不一致可通过重试机制缓解。