更合适，因为 Dubbo 服务往 Zookeeper 注册的就是临时节点，需要定时发心跳到 Zookeeper来续约节点，并允许服务下线时，将 Zookeeper 上相应的节点摘除。Zookeeper 使用 ZAB 虽保证数据的强?致，但是它的机房容灾能力的缺乏，无法适应?些大型场景。
Nacos 因为要支持多种服务类型的注册，并能够具有机房容灾、集群扩展等必不可少的能力，1.0.0 正式支持 AP 和 CP 两种?致性协议并存。1.0.0 重构数据的读写和同步逻辑，将与业务相关的 CRUD 与底层的?致性同步逻辑进行了分层隔离。然后将业务的读写（主要是写，因为读会直接使用业务层的缓存）抽象为 Nacos 定义的数据类型，调用?致性服务进行数据同步。在决定使用 CP 还是 AP ?致性时，使用?个代理，通过可控制的规则进行转发。
目前的?致性协议实现，?个是基于简化的 Raft 的 CP ?致性，?个是基于自研协议 Distro 的AP ?致性。Raft 协议不必多言，基于 Leader 进行写入，其 CP 也并不是严格的，只是能保证?半所见?致，以及数据的丢失概率较小。Distro 协议则是参考了内部 ConfigServer 和开源 Eureka，在不借助第三方存储的情况下，实现基本大同小异。Distro 重点是做了?些逻辑的优化和性能的调优
图 5 Nacos ?致性协议：
本文由博客一文多发平台 OpenWrite 发布！