某电商平台在促销期间因Nacos集群Leader节点宕机，导致部分服务注册失败，引发线上故障。
核心问题：

  1. Nacos作为注册中心，是AP还是CP架构？
  2. Leader节点宕机后，服务注册是否会被阻塞？

一、*CAP理论回顾：为什么注册中心需要AP？*

在分布式系统中，CAP理论指出三者不可兼得：

  • C（一致性）：所有节点数据实时一致
  • A（可用性）：请求总能获得响应
  • P（分区容忍性）：网络分区时系统仍能工作

图片

关于更多一致性理论，可以阅读我之前的文章：

分布式事务模型详解

注册中心的抉择：

  • Zookeeper（CP）：强一致性优先，Leader选举期间服务不可用
  • Eureka（AP）：高可用优先，容忍短暂数据不一致
  • Nacos（灵活切换）：支持AP/CP双模式，默认AP模式。AP 是通过 Nacos 自研的 Distro 协议来保证的，CP 是通过 Nacos 的 JRaft 协议来保证的。

**
**

问题：Nacos 中哪些地方用到了 AP 和 CP？

  • 针对临时服务实例，采用 AP 来保证注册中心的可用性，Distro 协议。
  • 针对持久化服务实例，采用 CP 来保证各个节点的强一致性，JRaft 协议。（JRaft 是 Nacos 对 Raft 的一种改造）
  • 针对配置中心，无 Database 作为存储的情况下，Nacos 节点之间的内存数据为了保持一致，采用 CP。Nacos 提供这种模式只是为了方便用户本机运行，降低对存储依赖，生产环境一般都是通过外置存储组件来保证数据一致性。
  • 针对配置中心，有 Database 作为存储的情况下，Nacos 通过持久化后通知其他节点到数据库拉取数据来保证数据一致性，另外采用读写分离架构来保证高可用，所以这里我认为这里采用的 AP，欢迎探讨。
  • 针对 异地多活，采用 AP 来保证高可用。

弦外音：

  • 临时服务实例就是我们默认使用的 Nacos 注册中心模式，客户端注册后，客户端需要定时上报心跳进行服务实例续约。
  • 持久化服务实例就是不需要上报心跳的，不会被自动摘除，除非手动移除实例，如果实例宕机了，Nacos 只会将这个客户端标记为不健康。

**
**

二、*Nacos的AP模式实现原理*

1. 去中心化架构

图片

  • 服务注册：客户端可连接任意节点，数据异步复制到集群
  • 最终一致性：允许短暂数据不一致，但最终所有节点数据一致

2. Distro协议（AP模式核心）

  • 数据分片：每个节点负责部分数据，通过心跳+健康检查维护状态
  • 故障恢复：节点宕机后，其负责的数据由其他节点接管
  • 源码片段：
1
// Distro协议数据同步核心逻辑  public class DistroProtocol {      public void syncData(String key, Data data) {          // 异步广播数据到所有节点          for (Member node : clusterNodes) {              if (!node.isSelf()) {                  asyncSendData(node, key, data);              }          }      }  }

** **

3. Leader节点的真实作用

在AP模式下：

  • Leader职责：仅负责元数据管理（如节点列表维护），不参与数据一致性决策
  • Leader宕机：集群自动选举新Leader（秒级完成），不影响服务注册与发现

**
**

三、*Nacos的CP模式实现原理*

1. Raft协议（CP模式核心）

  • 强一致性保证：所有写操作必须经过Leader节点，同步复制到多数派节点
  • Leader选举：宕机后需重新选举，期间服务注册不可用

** **

2. 适用场景

  • 特殊注册场景：金融交易等强一致性要求的业务

** **

**3. 服务端模式切换配置 **

Nacos 服务端支持通过 HTTP API 动态切换集群的工作模式：

1
# 切换为 CP 模式curl -X PUT 'http://<nacos-server-ip>:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'# 切换为 AP 模式curl -X PUT 'http://<nacos-server-ip>:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=AP'

****注意事项****：

  • 需确保集群内所有节点均切换为相同模式，否则可能导致数据不一致
  • 切换后需重启服务端以生效

四、*关键问题：Leader节点宕机后还能注册服务吗？*

** **

1. AP模式下的答案

可以注册！

  • 数据流向：服务注册请求发往任意节点 → 异步同步到集群
  • Leader宕机影响：仅元数据管理短暂不可用，数据操作不受影响

** **

2. CP模式下的答案

短暂不可用！

  • Leader选举期间：新的服务注册请求会被阻塞（通常持续3-10秒）
  • 客户端重试：Nacos SDK默认支持重试机制，选举完成后自动恢复

** **

3. 生产环境实测数据

模式 Leader宕机时间 服务注册成功率 恢复时间
AP 30秒 100% 0秒
CP 30秒 0%（期间阻塞） 5秒

**
**

五、*设计启示：如何选择AP与CP？*

1. 选型建议

  • 99%场景选择AP模式：注册中心的核心目标是高可用，容忍秒级数据不一致
  • CP模式慎用：仅适用于强一致性要求的特殊场景

** **

2. 高可用架构设计

图片

  • 多节点部署：至少3节点，跨机房容灾
  • 客户端容错：配置多个Nacos地址，自动切换可用节点