1. CAP 理论概述：

C（Consistency，一致性）：所有节点的数据是一致的，即对某个数据的所有操作，最终会传播到集群中的每一个节点，保证所有节点的数据一致。
A（Availability，可用性）：每个请求都会收到一个响应，成功或者失败，但不至于长时间挂起。
P（Partition tolerance，分区容忍性）：系统能够在某些节点或网络发生故障时，继续提供服务，不会因为网络分区而宕机。

在 CAP 理论 中，系统最多只能保证 两个 特性（Consistency、Availability、Partition tolerance）中的 任意两个，不能同时保证三个特性。在分布式系统中，由于 分区容忍性 是不可避免的（例如网络故障），所以大多数分布式系统会在 一致性 和 可用性 之间做选择。

RPC 服务注册/发现过程简述如下：

服务提供者启动时，会将其服务名称，IP 地址注册到配置中心。

服务消费者在第一次调用服务时，会通过注册中心找到相应的服务的 IP 地址列表，并缓存到本地，以供后续使用。

当消费者调用服务时，不会再去请求注册中心，而是直接通过负载均衡算法从 IP 列表中取一个服务提供者的服务器调用服务。

当服务提供者的某台服务器宕机或下线时，相应的 IP 会从服务提供者 IP 列表中移除。同时，注册中心会将新的服务 IP 地址列表发送给服务消费者机器，缓存在消费者本机。

当某个服务的所有服务器都下线了，那么这个服务也就下线了。

同样，当服务提供者的某台服务器上线时，注册中心会将新的服务 IP 地址列表发送给服务消费者机器，缓存在消费者本机。

服务提供方可以根据服务消费者的数量来作为服务下线的依据。

Nacos 集群

Leader 和 Follower 节点：

Nacos 集群采用了类似 Raft 协议的机制，集群中的一个节点被选举为 Leader，其负责处理写请求（如数据的更新、注册服务等），其他节点为 Follower，主要负责响应读请求（如查询服务列表等）。
Leader 节点通过心跳与 Follower 节点保持同步，确保数据一致性。Follower 节点如果与 Leader 节点失去连接，可能会被选举为新的 Leader。

数据同步：

集群中的节点之间会通过 数据同步 保持数据的一致性。所有的写操作（如服务注册、配置更新等）都会先写入 Leader 节点，并通过 Raft 协议同步到其他 ##Follower 节点。
一旦数据同步完成，集群中所有节点的数据保持一致。
服务发现和配置管理：

Nacos 集群中的所有节点都可以提供 服务发现 和 配置管理 功能，任何一个节点的客户端都可以向集群中的任意节点发起请求，集群节点会通过负载均衡将请求路由到合适的节点。
但是，写操作（如服务注册、配置更新）会通过 Leader 节点进行，而读取操作（如获取配置、查询服务）可以从任何节点读取。

心跳与故障恢复：

集群节点之间通过定期的 心跳机制 维持健康状态。一旦某个节点不可用，其他节点会尝试进行 Leader 选举，保证集群的高可用性。
集群规模与扩展：

在 Nacos 集群中，节点可以横向扩展，增加新的节点以提升集群的处理能力和容错性。每个新加入的节点都会通过心跳机制与其他节点同步状态。

总结来说，Nacos 集群中的节点通过 Leader 和 Follower 的角色划分、数据同步机制、心跳检测等方式共同保障集群的高可用性、数据一致性和负载均衡能力。

ZooKeeper

ZooKeeper Atomic Broadcast（ZAB，ZooKeeper 原子消息广播协议）是 ZooKeeper 实现分布式数据一致性的核心算法。
Zookeeper客户端会随机的链接到Zookeeper集群中的一个节点，如果是读请求，就直接从当前节点中读取数据；如果是写请求，那么节点就会向Leader提交事务，Leader接收到事务提交，会广播该事务，只要超过半数节点写入成功，该事务就会被提交。

Zookeeper 作为注册中心的一些弊端

作为一个分布式协同服务，ZooKeeper 非常好，但是对于 Service 发现服务来说就不合适了，因为对于 Service 发现服务来说就算是返回了包含不实的信息的结果也比什么都不返回要好。

所以当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接 down 掉不可用。

但是 zk 会出现这样一种情况，当 master 节点因为网络故障与其他节点失去联系时，剩余节点会重新进行 leader 选举。

问题在于，选举 leader 的时间太长，30 ~ 120s, 且选举期间整个 zk 集群都是不可用的，这就导致在选举期间注册服务瘫痪。

在云部署的环境下，因网络问题使得 zk 集群失去 master 节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

所以说，作为注册中心，可用性的要求要高于一致性！

在 CAP 模型中，Zookeeper 整体遵循一致性（CP）原则，即在任何时候对 Zookeeper 的访问请求能得到一致的数据结果，但是当机器下线或者宕机时，不能保证服务可用性。

那为什么 Zookeeper 不使用最终一致性（AP）模型呢？因为这个依赖 Zookeeper 的核心算法是 ZAB，所有设计都是为了强一致性。

这个对于分布式协调系统，完全没没有毛病，但是你如果将 Zookeeper 为分布式协调服务所做的一致性保障，用在注册中心，或者说服务发现场景，这个其实就不合适。

nacos 与zk的选举差异

Nacos 的行为：

选举过程中的服务可用性：在 Nacos 集群中，如果 Leader 节点不可用，系统会触发 Leader 选举。在选举过程中，从节点（Follower）仍然可以继续提供服务，例如：读取服务和配置数据。

这是因为 Raft 协议允许从节点继续提供 读取操作，即使发生了网络分区或 Leader 节点故障。在 Leader 选举过程中，虽然写操作（如服务注册、配置更新等）会被暂时暂停，从节点依然能提供读取操作，保证了系统的高可用性。

例如，在 Leader 失效时，集群会重新选举新的 Leader，但从节点依然可以处理 读请求，如查询配置或服务列表等。这就是 AP 原则，允许系统继续响应请求，即使某些数据可能稍微滞后或不一致。

ZooKeeper 的行为：

选举过程中的服务不可用性：在 ZooKeeper 中，Leader 节点不可用时，所有的写操作会暂停，而且 从节点（Follower）无法提供服务。ZooKeeper 的设计目的是保证 一致性（C），因此它严格控制 数据一致性。

如果发生了 Leader 节点故障，ZooKeeper 集群会启动 Leader 选举，直到选举出新的 Leader 节点后，系统才能恢复写操作。

在选举期间，从节点不能提供服务，即使是 读取操作。这就意味着，如果发生网络分区或 Leader 故障，ZooKeeper 集群会进入一个短暂的 不可用状态，直到选举过程完成并确保一致性。

这种设计是 CP 原则 的体现，因为系统保证一致性（即所有操作在选举前都不能执行，直到一致性得到保障）而牺牲了可用性。

总结：

Nacos 在 Leader 选举过程中，允许从节点继续提供服务（主要是读操作），即使在网络分区或 Leader 故障时，保证了 系统可用性，这是 AP 原则
。
ZooKeeper 在 Leader 选举过程中，不允许从节点提供服务，直到新 Leader 被选举出来并且系统一致性得到保障，系统会在此期间进入 不可用状态，这是 CP 原则。

因此，Nacos 更加注重系统的 高可用性，即使在发生故障和网络分区时也能保持服务的可用性；而 ZooKeeper 更加注重 一致性，即使会暂时不可用，但始终保证数据的一致性和正确性。