文章目录先说结论Eureka的架构数据同步的四个阶段阶段一服务注册阶段二Peer to Peer复制阶段三心跳续约阶段四注册表拉取为什么Eureka选择AP而不是CPEureka的自我保护机制回答技巧与点评加分回答面试官点评个人网站虽然 Eureka 已停更但它的数据同步机制是AP 型注册中心的经典设计面试中仍然高频出现。面试官问这题不是让你背 Eureka 源码而是考察你对分布式数据同步的理解多个 Eureka 节点之间怎么保持数据一致为什么不选强一致先说结论维度说明模型AP高可用 最终一致同步方式Peer to Peer对等复制核心机制注册 → 复制 → 续约 → 剔除一致性最终一致不保证实时一致与 ZooKeeper 对比Eureka 是 APZooKeeper 是 CP一句话记住Eureka 的同步像微信群——每个人发消息其他人都能看到但可能有延迟不像电话会议必须所有人同时在线Eureka的架构Service A ──注册──→ Eureka Server 1 ←──复制──→ Eureka Server 2 ↑ ↑ Service B ──注册──→ Eureka Server 1 ←──复制──→ Eureka Server 2 Service C ──拉取──→ Eureka Server 1获取所有服务列表所有 Eureka Server 节点地位平等没有主从之分服务注册到任意一个节点数据会复制到其他节点客户端从任意一个节点拉取注册表数据同步的四个阶段阶段一服务注册服务启动时向 Eureka Server 发送注册请求// 服务端处理注册publicvoidregister(InstanceInfoinfo,booleanisReplication){registry.register(info,leaseDuration,isReplication);// isReplication 标记是否是复制来的请求if(!isReplication){replicateToPeers(register,info);// 不是复制来的才向其他节点复制}}关键点isReplication 标记——如果是其他节点复制过来的注册信息不再继续向其他节点复制避免无限循环。阶段二Peer to Peer复制Eureka Server 之间是对等复制privatevoidreplicateToPeers(Stringaction,InstanceInfoinfo){for(PeerEurekaNodepeer:peerEurekaNodes){// 向每个对等节点复制peer.replicate(action,info);}}复制是异步的——注册请求先本地成功再异步复制到其他节点。这意味着注册成功后其他节点可能还看不到新服务但最终所有节点的数据会一致最终一致性阶段三心跳续约服务每 30 秒向 Eureka Server 发送心跳// 客户端定时发送心跳Scheduled(fixedRate30000)publicvoidheartbeat(){eurekaClient.sendHeartBeat(instanceInfo);}Eureka Server 如果 90 秒没收到心跳就认为服务不可用将其从注册表中剔除。心跳也有复制——Server A 收到心跳后异步复制到 Server B。阶段四注册表拉取客户端每 30 秒从 Eureka Server 拉取完整注册表首次或增量注册表后续// 增量拉取ApplicationsdeltaeurekaClient.getDelta();// 只获取最近 3 分钟内变化的实例增量拉取只返回最近变化的部分减少网络开销。但增量数据可能丢失所以 Eureka 会定期每 6 次全量拉取一次对齐。为什么Eureka选择AP而不是CP场景CPZooKeeperAPEureka网络分区选主期间不可用继续提供服务节点故障重新选主期间不可用其他节点照常工作数据一致性强一致最终一致适用场景强依赖一致性的场景服务发现场景服务发现场景为什么选 AP假设网络分区发生ZooKeeper 会选主选主期间注册中心不可用——你连注册中心都连不上更别提发现服务了。Eureka 的选择即使数据暂时不一致某些节点看到的注册表不同也要保证可用——你能发现服务虽然可能发现的是过期的服务。这在微服务场景中更可接受因为调用方本身就有重试和超时机制。Eureka的自我保护机制当 Eureka Server 在短时间内丢失大量心跳超过 85%它认为可能是网络问题而非服务真的挂了进入自我保护模式不再剔除过期服务继续对外提供服务注册和发现网络恢复后自动退出这避免了网络抖动导致大量服务被误剔除的问题。Eureka 数据同步全景 架构模型 ├── Peer to Peer对等复制 ├── AP 模型高可用 最终一致 └── 无主架构所有节点平等 同步流程 ├── 注册 → 本地保存 → 异步复制到 Peer ├── 心跳 → 本地续约 → 异步复制到 Peer ├── 剔除 → 90秒无心跳 → 本地剔除 └── 拉取 → 增量 定期全量对齐 核心设计 ├── isReplication 防循环复制 ├── 异步复制最终一致 ├── 自我保护防误剔除 └── 增量拉取 全量对齐 口诀Peer to Peer对等网注册复制异步走 心跳续约三十秒九十不跳就剔除 自我保护防误判增量拉取省带宽 AP模型保可用最终一致是代价回答技巧与点评标准回答Eureka Server 采用 Peer to Peer 对等复制模型服务注册到任意节点后异步复制到其他对等节点。核心机制包括注册isReplication 防循环复制、心跳续约30秒一次90秒超时剔除、增量拉取客户端每30秒拉取变化数据。Eureka 选择 AP 模型保证高可用牺牲强一致性网络分区时仍可提供服务发现。自我保护机制在心跳丢失过多时暂停剔除防止误判。加分回答isReplication 的精妙注册请求携带 isReplication 标记只在首次注册时向其他节点复制避免 A→B→A 的无限循环。这是分布式系统中防止消息风暴的经典做法Read-Write CacheEureka Server 使用两级缓存ReadWriteCacheMap ReadOnlyCacheMap读操作走 ReadOnly 缓存每30秒同步一次写操作更新 ReadWrite 缓存。这是典型的读写分离优化Nacos 的改进Nacos 支持 AP/CP 模式切换——临时实例用 AP类似 Eureka持久化实例用 CPRaft 协议。比 Eureka 更灵活面试官点评这道题考的是你对分布式一致性模型的理解。能说出 Peer to Peer 复制和 AP 模型算及格高分的关键在于解释为什么服务发现选 AP 而不是 CP以及isReplication 防循环复制的机制。如果你能把 Eureka 的两级缓存也讲出来说明你看过源码。原文阅读内容有帮助点赞、收藏、关注三连评论区等你