Nacos 同时支持 AP 和 CP 模式，它是怎么做到的？背后的 Raft 和 Distro 协议各自解决什么问题？

一、注册中心的 CAP 困境

  • 1.1 为什么注册中心需要 CAP 选择
  • 1.2 Eureka 的 AP 选择——优先可用性
  • 1.3 ZooKeeper 的 CP 选择——优先一致性
  • 1.4 Nacos 的混合选择——可切换

二、Nacos 的 AP 模式——Distro 协议

  • 2.1 Distro 的设计目标——最终一致性 + 高可用
  • 2.2 数据同步机制——每个节点都能写入
  • 2.3 健康检查——临时实例的心跳检测
  • 2.4 Distro 的一致性保证——异步复制 + 对账

三、Nacos 的 CP 模式——Raft 协议

  • 3.1 Raft 的基本概念——Leader / Follower / Candidate
  • 3.2 Leader 选举过程——Term + Vote
  • 3.3 日志复制——过半写入确认
  • 3.4 Nacos 中的 Raft 实现——JRaft

四、临时实例 vs 持久化实例

  • 4.1 临时实例——AP 模式，心跳保活
  • 4.2 持久化实例——CP 模式，主动健康检查
  • 4.3 什么场景用哪个——微服务用临时，DNS/核心服务用持久化

五、健康检查机制

  • 5.1 客户端心跳——临时实例的 5 秒心跳
  • 5.2 服务端主动探测——TCP/HTTP/MYSQL 探针
  • 5.3 保护阈值——防止网络抖动导致全部下线

六、源码核心流程

  • 6.1 服务注册——InstanceController.register()
  • 6.2 服务发现——InstanceController.list()
  • 6.3 Distro 同步——DistroConsistencyServiceImpl.put()
  • 6.4 客户端订阅——UDP 推送 + 定时轮询

七、总结

  • Nacos 的设计哲学——稳定压倒一切
  • 生产环境配置建议