注册中心应该选 CP 还是 AP？Nacos、Eureka、ZooKeeper 有什么区别？

简化版

CAP 理论下，分布式系统在**一致性（C）和可用性（A）**之间只能优先保一个（P 分区容错必须有）。注册中心通常更应该选 AP——因为「拿到稍旧的服务列表（可能含个别失效实例）」比「注册中心因追求强一致而暂时不可用（连不上、发现不了服务）」危害小得多。典型：Eureka 是 AP（保可用，牺牲强一致）；ZooKeeper 是 CP（保一致，选举期间不可用）；Nacos 两者都支持（默认 AP，可切 CP），是目前主流选择。Consul 是 CP。

详细版

主流注册中心的 CAP 取向：

注册中心	CAP	一致性协议	特点
Eureka	AP	无强一致（节点对等，异步复制）	保可用，Netflix 出品，已停更
ZooKeeper	CP	ZAB	保一致，Leader 选举期间不可用
Nacos	AP / CP 可切	Distro(AP) / Raft(CP)	阿里，二合一，主流
Consul	CP	Raft	HashiCorp，功能全
etcd	CP	Raft	K8s 的存储，强一致

为什么注册中心倾向 AP：

服务发现要高可用——注册中心一旦不可用，所有服务都发现不了对方、整个系统瘫痪。
服务列表短暂不一致可容忍——消费者拿到旧列表，即使包含个别已下线实例，调用失败还能重试其他实例；配合客户端容错，影响小。

完整版教学

一、先理解 CAP 在注册中心的含义

CAP 理论：分布式系统无法同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance） 三者，最多同时满足两个。而分区（网络故障导致节点间通信中断）在分布式系统中不可避免，所以 P 必须保，实际是在C 和 A 之间二选一：

CP（选一致性）：发生网络分区时，为了保证数据一致，宁可拒绝服务（部分节点不可用），也不返回可能不一致的数据。
AP（选可用性）：发生网络分区时，为了保证服务可用，每个节点都继续响应，但可能返回旧数据（不一致）。

具体到注册中心：

C（一致性）：所有节点看到的服务注册信息完全一致。
A（可用性）：注册中心任何时候都能响应「注册」和「查询」请求。

二、为什么注册中心通常应该选 AP

这是本题的核心判断。注册中心的首要职责是「让服务能互相发现」，所以「可用」比「强一致」更重要。 分析两种极端情况：

如果选 CP（如 ZooKeeper）：当发生网络分区、或 Leader 宕机重新选举时，ZooKeeper 为了保证一致性，会暂停对外服务（选举期间整个集群不可写、甚至不可用）。这段时间里，所有服务既不能注册、也不能发现别的服务——新服务上不了线、消费者拉不到列表，整个微服务体系可能瘫痪。为了「服务列表绝对准确」而让整个系统不可用，得不偿失。

如果选 AP（如 Eureka）：网络分区时，每个注册中心节点继续对外服务，只是各节点的数据可能短暂不一致（比如某个刚下线的实例还在列表里）。消费者拿到的列表可能有个别失效实例，但这没那么可怕——调用那个失效实例失败后，客户端重试其他实例即可（配合客户端负载均衡和容错）。服务发现整体始终可用。

结论：服务发现场景下，「短暂拿到旧数据」的代价，远小于「注册中心不可用导致全体服务发现瘫痪」的代价，所以注册中心倾向 AP。

三、Eureka：经典的 AP 实现

Eureka（Netflix 出品，Spring Cloud 早期标配）是典型的 AP 注册中心：

节点对等（Peer to Peer）：Eureka 集群各节点地位平等，没有 Leader，之间异步复制注册信息。
保可用：即使节点间复制不同步、或部分节点挂了，每个节点仍能独立提供注册和查询服务。
自我保护机制：当 Eureka 检测到大量实例心跳丢失（可能是网络问题而非实例真挂了）时，不会贸然剔除这些实例（宁可保留可能失效的，也不错删健康的），进一步偏向可用性（详见「Eureka 自我保护」专题）。
缺点：数据一致性弱（不同节点可能短暂看到不同列表）；且 Eureka 1.x 已停止更新。

四、ZooKeeper：CP 的代表

ZooKeeper 是典型的 CP 系统，基于 ZAB 协议保证强一致：

有 Leader：写请求都经过 Leader，同步到多数 Follower 才算成功，保证各节点数据强一致。
Leader 选举期间不可用：当 Leader 宕机，ZooKeeper 要重新选举（通常几十秒），选举期间整个集群不可写、不对外提供服务——这就是它牺牲可用性保一致性的体现。
用它做注册中心时，选举期间服务无法注册/发现，是个风险。所以虽然 ZooKeeper 常被用作注册中心（如早期 Dubbo 默认），但从 CAP 角度看它不是最适合服务发现的选择（更适合需要强一致的场景，如分布式锁、选主）。

五、Nacos：AP/CP 可切换的主流选择

Nacos（阿里开源）是目前最主流的注册中心，它的优势是同时支持 AP 和 CP，可按需切换：

默认 AP 模式：用阿里自研的 Distro 协议，适合注册临时实例（靠心跳保活），偏可用——这是服务发现的推荐模式。
CP 模式：用 Raft 协议，适合注册持久化实例（需要强一致的场景）。
通过实例的 ephemeral（是否临时）属性选择：临时实例走 AP，持久实例走 CP。

此外 Nacos 注册中心和配置中心二合一（既能服务发现又能管配置），生态好、文档全、社区活跃，是新项目的首选。

六、常见误区与追问

这道题面试时最容易丢分的地方，是把「注册中心 CP 与 AP 取舍」答成一段泛泛的组件介绍。更稳的答法是先给结论，再沿着服务注册与发现链路拆清楚流程，最后补上异常场景、数字边界和选型取舍。

回答层次	要讲清的内容	容易漏掉的边界
核心定义	CP 优先保证注册数据一致，AP 优先保证服务发现可用；注册中心场景通常更看重发现链路不断供	不要停在名词解释
流程机制	判断服务地址是否属于强一致业务数据 -> 评估网络分区时更怕错误地址还是无地址 -> 结合客户端缓存和健康检查兜底 -> 选择 Nacos AP/CP、Eureka AP 或 ZooKeeper CP 等方案	说明谁触发、谁存储、谁通知、谁兜底
工程取舍	例如 3 节点注册中心故障 1 节点时，AP 模式应尽量继续返回可用列表，CP 模式可能拒绝写入或等待多数派	注册信息不是业务数据，短暂不一致通常靠客户端缓存、重试和健康检查兜底

注册中心 CP 与 AP 取舍 面试拆解：
1. 判断服务地址是否属于强一致业务数据
2. 评估网络分区时更怕错误地址还是无地址
3. 结合客户端缓存和健康检查兜底
4. 选择 Nacos AP/CP、Eureka AP 或 ZooKeeper CP 等方案

记忆钩子：先区分注册、发现、心跳、剔除和本地缓存，再说明一致性与可用性的取舍；回答时一定要落到题目中的「注册中心 CP 与 AP 取舍」，不要把相邻中间件的能力混着讲。

误区：CP 一定比 AP 更高级。 注册中心不是库存扣减，很多场景宁愿短暂读到旧实例，也不能让所有调用方拿不到地址。
误区：AP 就等于数据乱了。 AP 是优先可用，仍会通过心跳、推送和最终一致机制收敛，不是放弃一致性。
误区：注册中心必须强一致。 如果客户端有本地缓存、负载均衡和失败重试，短暂注册表延迟通常可接受。
追问：Nacos 为什么既支持 CP 又支持 AP？ 因为临时实例更适合 AP 心跳模型，持久实例或强一致元数据更适合 CP 模型。
追问：ZooKeeper 做注册中心有什么典型取舍？ 它基于 Zab 保证强一致和顺序性，但写入与会话抖动成本更高，不适合极大规模频繁上下线。
追问：面试中怎么回答选型？ 先说业务容忍度，再说组件机制，最后补客户端缓存、健康检查和降级策略。

七、加强记忆

CAP 下分区容错（P）必须保，实际在一致性（C）和可用性（A）间二选一。注册中心通常应选 AP——因为「拿到稍旧的服务列表（含个别失效实例，客户端重试即可）」远好于「注册中心为强一致而不可用，导致全体服务发现瘫痪」。主流对比：Eureka=AP（节点对等异步复制、保可用、有自我保护、已停更）；ZooKeeper=CP（ZAB 协议强一致，但Leader 选举期间不可用，更适合分布式锁/选主）；Nacos=AP/CP 可切（默认 AP-Distro 临时实例、CP-Raft 持久实例，注册配置二合一，主流首选）；Consul/etcd=CP。判断口诀：服务发现要高可用，短暂不一致可容忍，所以注册中心优先 AP。

简化版

详细版