nacos作为注册中心时，支持AP(可用性 | 分区容错性) 和 CP(一致性 | 分区容错性)两种 默认是AP;作为配置中心时，由于配置是存储在mysql中的，所以不存在CP还是AP.
如果注册Nacos的client节点注册为临时节点时(ephemeral=true)，那么Nacos集群对这个client节点的效果就是AP，采用distro协议实现；而注册Nacos的client节点注册为永久节点时(ephemeral=false)，那么Nacos集群对这个节点的效果就是CP的，采用raft协议实现。根据client注册时的属性，AP，CP同时混合存在，只是对不同的client节点效果不同。Nacos可以很好的解决不同场景的业务需求。
最终一致性指的是，在一定时间段内，所有数据的副本最终都会变成一致的。在这一过程中，对某个数据的写入操作可能只被应用在部分数据副本上，而剩余的数据副本可能还没来得及进行同步。但是，随着时间的推移，所有的副本最终会同步，数据变得一致。
强制一致性则要求所有数据的副本在数据写入后必须立即达到一致状态，即事务的 ACID 特性。这种模型下，需要付出更多的代价来保证数据一致性。
Nacos 采用的是最终一致性模型，这样使得 Nacos 具有更高的可用性和性能，而且在实际开发中通常也足够满足需求。但是，需要注意的是，最终一致性带来的代价是，如果服务或数据副本异常，可能会产生短暂的不一致。因此，在选择使用 Nacos 或其他最终一致性模型的分布式系统时，需要根据应用场景权衡其优缺点。
nacos集群检测其他节点的实现原理
在 Nacos 集群中，节点之间会通过心跳机制检测对方的存活状态。具体来说，每个节点会定时向其他节点发送心跳请求，其他节点接收到请求后会返回一个心跳响应，告诉发送节点它仍然存活。如果一个节点连续若干次没有收到另外一个节点的心跳响应，就会认为这个节点已经宕机，然后将它从集群中移除。
在 Nacos 中，这个心跳机制是由两个组件来实现的：心跳管理器和心跳监听器。心跳管理器会负责定时向其他节点发送心跳请求，而心跳监听器则会监听其他节点返回的心跳响应。如果在一定时间内没有收到心跳响应，心跳监听器会认为这个节点已经宕机，然后将它从集群中移除。通过这种方式，Nacos 实现了高可用性和容错性的集群机制。
选举Leader的过程
Nacos使用Raft算法进行Leader选举，其选举的流程可以简单描述如下：
- 初始状态下，所有节点均为Follower状态。
- 有任一节点超过选举超时时间（election timeout）没有收到Leader节点的心跳，即进入下面的步骤3。
- 进入选举状态，该节点成为Candidate节点，并向其他节点发送选票请求请求选票。
- 如果其他节点还没投票，它们会持有选票，在收到选票请求后，会递增自己的term并投票给候选节点。
- 如果候选节点收到了大多数节点的选票（即半数以上），那么它会成为Leader节点，并开始向其他节点发送心跳包。
- 如果候选节点在等待投票过程中，接收到了其他节点发送的心跳信息，并发现了新的Leader节点，那么它会转成Follower状态，然后开始接受新Leader的心跳包。
- 如果候选节点在等待投票过程中，没有收到足够的选票，那么它会增加选举超时时间并再次进入选举状态，重复上述步骤。
需要说明的是，如果有多个节点同时成为候选节点，它们都会向其他节点发送选票请求。在这种情况下，只有一个节点最终能够成功地成为Leader节点，而其他节点将不再继续发送心跳包和提供服务。该算法能够保证在集群中只有一个Leader节点，可以有效地防止数据不一致的情况发生。
Nacos 在进行 Leader 选举的过程中，一般情况下会影响外部服务的可用性。如果集群注册的为永久节点，nacos采用的是CP，集群中的节点需要进行通信、协调以及状态变更等操作，因此可能会在一定时间内影响正常的服务调用。若nacos注册的是临时节点，nacos默认为AP，可以向外提供服务。
在 Nacos 1.3.0 及以上版本中，为了减少 Leader 选举对外部服务的影响，Nacos 引入了快速选举机制。在节点加入集群时，Nacos 集群会为每个节点计算一个快速选举的权重，该权重会考虑节点的处理能力等因素，然后只有权重最高的节点才会参与 Leader 选举。这样可以大大缩短 Leader 选举的时间，减少对外部服务的影响。
但是需要注意的是，即使使用了快速选举机制，Nacos 集群在进行 Leader 选举时仍然可能会影响外部服务的可用性，特别是在节点异常较多或者 Leader 节点失效时。因此，在设计应用架构时，应当做好服务的容错和降级处理，以应对 Nacos 集群中可能出现的故障情况。
