一、分布式系统核心协议概览
┌─────────────────────────────────────────────────────────┐
│ 分布式系统协议体系 │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 一致性协议 │ │ 共识协议 │ │
│ │ (Consistency) │ │ (Consensus) │ │
│ │ │ │ │ │
│ │ • Paxos │ │ • Raft │ │
│ │ • Raft │ │ • ZAB (ZooKeeper)│ │
│ │ • ZAB │ │ • Gossip │ │
│ │ • Gossip │ │ • Distro (Nacos)│ │
│ │ • Distro │ │ • Eureka Peer │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 数据同步协议 │ │ 服务发现协议 │ │
│ │ │ │ │ │
│ │ • Pull │ │ • DNS │ │
│ │ • Push │ │ • HTTP REST │ │
│ │ • Long Polling │ │ • gRPC │ │
│ │ • Watch/Notify │ │ • mDNS │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘二、核心分布式协议详解
1. Paxos 协议（拜占庭将军问题解决方案）
┌─────────────────────────────────────────┐
│ Paxos 两阶段提交 │
│ │
│ Phase 1 (Prepare) │
│ Proposer ──Prepare(n)──→ Acceptor │
│ ←─Promise──── │
│ (承诺不接受小于n的提案) │
│ │
│ Phase 2 (Accept) │
│ Proposer ──Accept(n,v)─→ Acceptor │
│ ←─Accepted─── │
│ (确认接受提案) │
│ │
│ 角色：Proposer（提案者） │
│ Acceptor（接受者） │
│ Learner（学习者） │
└─────────────────────────────────────────┘特点：
-
理论最完善的一致性算法
-
实现复杂，难以理解（Lamport 论文晦涩）
-
性能较低（多轮网络通信）
应用：Chubby（Google 分布式锁）、少量系统底层
2. Raft 协议（Paxos 的简化实现）
┌─────────────────────────────────────────┐
│ Raft 领导者选举 │
│ │
│ 角色：Leader（领导者） │
│ Follower（跟随者） │
│ Candidate（候选人） │
│ │
│ 选举过程： │
│ Follower ──超时未收到心跳──→ Candidate │
│ │ │ │
│ │ ▼ │
│ │ 发起投票请求 │
│ │ RequestVote │
│ │ │ │
│ └──────────←───────────────┘ │
│ 获得多数票成为 Leader │
│ │
│ 日志复制： │
│ Leader ──AppendEntries──→ Follower │
│ ←─────ACK──────── │
└─────────────────────────────────────────┘特点：
-
强一致性（CP）
-
实现简单，易于理解（比 Paxos 清晰）
-
领导者瓶颈（所有写操作经过 Leader）
应用：etcd、Consul、TiKV、Nacos（JRaft 选主）
3. ZAB 协议（ZooKeeper Atomic Broadcast）
┌─────────────────────────────────────────┐
│ ZAB 崩溃恢复 + 消息广播 │
│ │
│ 阶段一：崩溃恢复（选主） │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Server1 │ │ Server2 │ │ Server3 │ │
│ │ zxid=9 │ │ zxid=10 │ │ zxid=9 │ │
│ │ │ │ Leader │ │ │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ ↑ │ ↑ │
│ └────────────┴────────────┘ │
│ 同步数据保证一致 │
│ │
│ 阶段二：消息广播（正常运行） │
│ Leader ──Proposal──→ Follower │
│ │ ←────ACK──── │
│ │ │
│ └──Commit──→ 所有节点执行 │
│ │
│ zxid = 64 位：高 32 位 epoch（周期） │
│ 低 32 位 计数器 │
└─────────────────────────────────────────┘特点：
-
强一致性（CP），顺序一致性
-
快速选举（200ms 内完成选主）
-
高吞吐（内存数据，适合读多写少）
应用：ZooKeeper、Kafka（早期）、Dubbo
4. Gossip 协议（最终一致性，流行病传播）
┌─────────────────────────────────────────┐
│ Gossip 协议传播过程 │
│ │
│ 初始：Node A 知道新数据 │
│ │
│ Round 1: │
│ A ──► 随机选择 B、C 发送数据 │
│ B ──► 随机选择 D、E │
│ C ──► 随机选择 F │
│ │
│ Round 2: │
│ D ──► G, H E ──► I F ──► J │
│ │
│ 特点： │
│ • 去中心化，无单点 │
│ • 最终一致性（Eventually Consistent） │
│ • 容错性强，网络分区自愈 │
│ • 收敛时间 O(logN) │
└─────────────────────────────────────────┘特点：
-
最终一致性（AP）
-
无中心节点，扩展性极强
-
带宽消耗较大（多次随机通信）
应用：Consul（Serf 库）、Cassandra、Redis Cluster
5. Distro 协议（Nacos 自研）
┌─────────────────────────────────────────┐
│ Distro 协议（Nacos） │
│ │
│ 设计目标：AP 架构，高可用，高性能 │
│ │
│ 数据分片： │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Node 1 │ │ Node 2 │ │ Node 3 │ │
│ │ 负责 A-C │ │ 负责 D-F │ │ 负责 G-I │ │
│ │ 副本 B,E │ │ 副本 A,D │ │ 副本 C,F │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ ↑ ↑ ↑ │
│ └────────────┼────────────┘ │
│ │ │
│ 每个节点负责部分数据 │
│ 同时持有其他节点副本 │
│ │
│ 同步机制： │
│ • 启动时全量同步 │
│ • 运行时增量同步（异步） │
│ • 定时校验 checksum │
└─────────────────────────────────────────┘特点：
-
最终一致性（AP）
-
水平扩展能力强（无单点瓶颈）
-
适合服务注册（临时数据，可容忍短暂不一致）
6. Eureka Peer 复制协议
┌─────────────────────────────────────────┐
│ Eureka 去中心化复制机制 │
│ │
│ ┌─────────┐ ◄──────► ┌─────────┐ │
│ │ Peer 1 │ 双向复制 │ Peer 2 │ │
│ │ (Zone1) │◄─────────►│ (Zone2) │ │
│ └────┬────┘ └────┬────┘ │
│ │ │ │
│ └──────────┬───────────┘ │
│ ▼ │
│ ┌─────────┐ │
│ │ Peer 3 │ │
│ │ (Zone3) │ │
│ └─────────┘ │
│ │
│ 复制方式： │
│ • 异步复制（不保证实时一致） │
│ • 客户端缓存（注册中心宕机仍可调用） │
│ • 自我保护（网络分区时不剔除服务） │
└─────────────────────────────────────────┘特点：
-
最终一致性（AP）
-
自我保护机制（防止雪崩）
-
无 master，所有节点对等
三、五大注册中心深度对比
架构对比图
┌─────────────────────────────────────────────────────────┐
│ 注册中心架构对比 │
├─────────────────────────────────────────────────────────┤
│ │
│ Eureka Nacos Consul │
│ ─────── ─────── ─────── │
│ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │Peer1│◄──►│Peer2│ │Node1│◄──►│Node2│ │Server│◄──►│Server│ │
│ │(Zone1)│ │(Zone2)│ │(Distro)│ │(Distro)│ │(LAN) │ │(WAN) │
│ └──┬──┘ └──┬──┘ └──┬──┘ │
│ │ │ │ │
│ 去中心化复制 Distro协议+Raft Raft+Gossip │
│ 纯AP架构 CP/AP可切换 默认CP │
│ │
│ ZooKeeper etcd │
│ ───────── ───── │
│ ┌─────┐ ┌─────┐ │
│ │Leader│◄────┐ │Leader│◄────┐ │
│ └──┬──┘ │ └──┬──┘ │ │
│ │ │ │ │ │
│ ┌──┴──┐ ┌─┴─┐ ┌──┴──┐ ┌─┴─┐ │
│ │Follower│◄►│Follower│ │Follower│◄►│Follower│ │
│ └─────┘ └───┘ └─────┘ └───┘ │
│ │
│ ZAB协议 Raft协议 │
│ 强一致性(CP) 强一致性(CP) │
│ │
└─────────────────────────────────────────────────────────┘详细对比表
表格
| 维度 | Eureka | Nacos | Consul | ZooKeeper | etcd |
|---|---|---|---|---|---|
| 底层协议 | Peer 异步复制 | Distro + Raft | Raft + Gossip | ZAB | Raft |
| CAP 理论 | AP | AP/CP 可切换 | CP（可调成 AP） | CP | CP |
| 一致性级别 | 最终一致 | 最终一致/强一致 | 强一致 | 顺序一致 | 线性一致 |
| 选举算法 | 无（去中心化） | Raft（JRaft） | Raft | ZAB | Raft |
| 数据模型 | 注册表 | 注册表 + 配置 | KV + 服务 + 健康 | 树形 ZNode | KV |
| 健康检查 | 客户端心跳 | 客户端心跳/服务端探活 | 多种方式（HTTP/TCP/脚本） | 客户端心跳 | 租约机制 |
| 多数据中心 | 支持（Zone） | 支持 | 原生支持（WAN Gossip） | 需配置 Observer | 需配合工具 |
| 性能（QPS） | ~1k | ~10k+ | ~1k | ~10k+（读） | ~10k+ |
| 扩展性 | 一般 | 强 | 强 | 一般（写瓶颈） | 强 |
| 易用性 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| Spring Cloud | 原生支持 | 原生支持（Alibaba） | 支持 | 需配置 | 需配置 |
各注册中心优缺点详解
1. Eureka
优点：
✓ 与 Spring Cloud 集成最丝滑，开箱即用
✓ 自我保护机制，防止网络分区时误杀服务
✓ 客户端缓存，注册中心宕机不影响调用
✓ 配置简单，学习成本低
缺点：
✗ 已停止维护（Netflix 进入维护模式）
✗ 仅支持服务注册，无配置中心功能
✗ 一致性较弱（异步复制延迟）
✗ 无原生健康检查（依赖客户端心跳）
适用：传统 Spring Cloud 项目，快速上手2. Nacos
优点：
✓ 注册中心 + 配置中心一体化，减少组件
✓ 支持 AP/CP 切换，灵活应对不同场景
✓ 控制台功能强大，支持灰度发布、权重调整
✓ 性能高（Distro 协议水平扩展）
✓ 国产项目，中文文档完善，社区活跃
缺点：
✗ 相对年轻（2018 年开源），稳定性待验证
✗ 功能多导致复杂度上升
✗ 非 Java 生态支持较弱
适用：阿里云环境、大规模微服务、需要配置中心3. Consul
优点：
✓ 多数据中心原生支持，适合全球化部署
✓ 健康检查机制丰富（HTTP/TCP/脚本/GRPC）
✓ 支持 Service Mesh（集成 Envoy）
✓ 一致性高（Raft 协议）
✓ 跨语言支持好（HTTP API + SDK）
缺点：
✗ 性能相对较低（CP 架构）
✗ 资源消耗较大（需要 Agent 常驻）
✗ 国内社区相对较小
✗ 无配置中心功能（需配合 Consul KV）
适用：多语言混合、多数据中心、需要强健康检查4. ZooKeeper
优点：
✓ 成熟稳定（Apache 顶级项目，10+年历史）
✓ 强一致性，顺序保证（ZAB 协议）
✓ 生态丰富（Dubbo、Kafka、HBase 依赖）
✓ Watch 机制实时推送变更
✓ 支持分布式锁、队列等高级功能
缺点：
✗ 写性能瓶颈（单 Leader 处理写请求）
✗ 会话管理复杂（Session 超时难调优）
✗ 无服务健康检查（需自己实现）
✗ 不适合大规模服务注册（临时节点过多）
✗ Java 客户端较重（Curator 依赖多）
适用：已有 Dubbo/Kafka 生态、需要分布式协调5. etcd
优点：
✓ Kubernetes 默认存储，云原生标准
✓ 性能极高（Raft + gRPC + BoltDB）
✓ 安全性好（支持 TLS 双向认证）
✓ 版本控制（可查看历史变更）
✓ 轻量级（单二进制文件）
缺点：
✗ 功能单一（纯 KV，无服务发现高层抽象）
✗ 无内置健康检查机制
✗ 需配合其他工具实现服务发现
✗ 学习曲线较陡（Raft 原理需理解）
适用：K8s 环境、需要高性能 KV、基础设施层四、协议与注册中心对应关系
┌─────────────────────────────────────────────────────────┐
│ 协议 → 注册中心 映射关系 │
├─────────────────────────────────────────────────────────┤
│ │
│ 一致性协议 注册中心实现 │
│ ─────────── ─────────── │
│ Paxos Chubby（Google，闭源） │
│ 极少开源实现 │
│ │
│ Raft ├─ etcd（CoreOS） │
│ ├─ Consul（HashiCorp） │
│ ├─ Nacos（选主用 JRaft） │
│ └- TiKV、RethinkDB 等 │
│ │
│ ZAB ZooKeeper（Apache） │
│ │
│ Gossip ├- Consul（Serf 库，多数据中心） │
│ ├- Cassandra（数据库） │
│ └- Redis Cluster │
│ │
│ Distro Nacos（阿里自研，服务注册） │
│ │
│ Peer 复制 Eureka（Netflix，去中心化） │
│ │
└─────────────────────────────────────────────────────────┘五、选择决策树
┌─────────────────┐
│ 需要什么功能？ │
└────────┬────────┘
│
┌───────────────────┼───────────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│纯服务注册 │ │注册+配置 │ │ 多语言 │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ 规模小？ │ │ 阿里云？ │ │ 多数据中心？│
└────┬────┘ └────┬────┘ └────┬────┘
是│否 是│否 是│否
▼ ▼ ▼ ▼ ▼ ▼
Eureka Nacos Nacos Consul Consul etcd
(简单) (大规模) (推荐) (自建) (推荐) +工具六、核心记忆点
表格
| 协议/注册中心 | 关键词 | 记忆口诀 |
|---|---|---|
| Paxos | 复杂、理论完善 | "Paxos 难，学界赞" |
| Raft | 简单、Leader 选举 | "Raft 简，好实现" |
| ZAB | 快选主、顺序性 | "ZAB 快，ZK 爱" |
| Gossip | 传播、最终一致 | "Gossip 传，像流感" |
| Eureka | AP、自我保护 | "Eureka 保，不抛锚" |
| Nacos | 全能、国产 | "Nacos 全，阿里造" |
| Consul | 多 DC、健康检查 | "Consul 远，跨数据中心" |
| ZooKeeper | 老稳、分布式协调 | "ZK 老，协调好" |
| etcd | K8s、高性能 | "etcd 快，K8s 带" |
一句话总结：选注册中心就是选 CAP，要可用性选 AP（Eureka/Nacos），要一致性选 CP（Consul/ZK/etcd），要全能选 Nacos！