服务实例上下线时，注册中心是如何通知消费者的？（推 vs 拉）

简化版

注册中心通知消费者服务变更有两种模式：拉模式（Pull）——消费者定期主动去注册中心拉取最新的服务列表，实现简单，但有延迟（两次拉取之间的变化感知不到）且频繁拉取有压力；推模式（Push）——消费者订阅服务后，注册中心在实例变化时主动推送通知给消费者，实时性好，但要维护连接、实现较复杂。实际的注册中心大多推拉结合：以推送为主保证实时，以定时拉取为兜底（防推送丢失），再加本地缓存保证可用性。Eureka 偏拉、ZooKeeper/Nacos 有推。

详细版

拉模式（Pull）：

消费者定时轮询注册中心，主动获取服务列表。
优点：实现简单、注册中心无状态压力小。
缺点：有延迟（轮询间隔内的变化感知不到）；轮询太频繁则压力大、太稀疏则延迟大。
代表：Eureka（默认 30 秒拉取一次）。

推模式（Push）：

消费者订阅服务，注册中心维护订阅关系，实例变化时主动推送变更。
优点：实时性好，变化立即通知。
缺点：注册中心要维护订阅关系/长连接，实现复杂；连接多时有压力。
代表：ZooKeeper（Watcher 通知）、Nacos（UDP 推送 / 长连接）。

推拉结合（主流）：

推送为主（实时感知变化）+ 定时拉取兜底（防推送丢失）+ 本地缓存（保可用）。

完整版教学

一、问题背景：变化如何传达给消费者

服务实例是动态变化的——会扩容（新实例上线）、缩容/宕机（实例下线）。消费者缓存着服务列表，这个列表必须及时更新，否则会用旧地址（漏掉新实例、调用死实例）。核心问题是：当注册中心的服务列表变化了，怎么让消费者知道？ 有两种思路——消费者主动来问（拉），或注册中心主动去说（推）。

二、拉模式（Pull）：消费者定期来问

拉模式：消费者定时主动去注册中心拉取最新的服务列表。就像你每隔一段时间刷新一下网页看有没有新消息。

流程：消费者启动一个定时任务，每隔固定时间（如 30 秒）调用注册中心接口，获取服务的最新实例列表，更新本地缓存。
优点：实现简单——注册中心只要提供一个「查询服务列表」的接口即可，不需要维护「谁订阅了什么」的状态，注册中心相对无状态、压力小。
缺点：
- 有延迟：两次拉取之间发生的变化，消费者感知不到，最长要等一个轮询周期。比如实例刚下线，但消费者下次拉取是 30 秒后，这 30 秒内它还可能调用这个死实例。
- 拉取频率两难：拉太频繁（如每秒）能减小延迟但增大注册中心压力（大量消费者高频轮询）；拉太稀疏省压力但延迟大。
代表：Eureka，Consumer 默认每 30 秒拉取一次注册表。

三、推模式（Push）：注册中心主动通知

推模式：消费者订阅自己关心的服务，注册中心记住这个订阅关系；一旦服务实例列表变化，注册中心主动把变更推送给订阅的消费者。就像你关注了一个公众号，有更新它主动推给你，不用你反复刷新。

流程：消费者订阅服务 → 注册中心维护订阅关系（谁订阅了哪个服务）→ 实例变化时，注册中心找到订阅了该服务的消费者，主动推送通知 → 消费者收到后更新本地缓存。
优点：实时性好——变化几乎立即通知到消费者，延迟极低。
缺点：
- 实现复杂：注册中心要维护大量订阅关系、维护到消费者的连接（长连接或回调），有状态。
- 连接/推送压力：消费者多时，维护海量连接、推送海量通知有压力；还可能有「羊群效应」（大量消费者同时被通知、同时来拉取详情）。
代表：ZooKeeper（Watcher 机制，节点变化触发通知，但 Watcher 是一次性的）、Nacos（早期 UDP 推送，新版长连接推送）。

四、推拉结合：主流方案

纯拉有延迟、纯推有复杂度和可靠性问题（推送可能丢失），所以成熟的注册中心大多「推拉结合」：

以推送为主：保证变化能实时通知到消费者。
以定时拉取为兜底：万一某次推送丢失了（网络问题、消费者临时断连），定时拉取能最终把消费者的列表拉到最新，保证最终一致。
加本地缓存：消费者缓存服务列表，即使注册中心暂时不可用也能用缓存调用（见「注册中心宕机」专题）。

比如 Nacos：消费者订阅后，服务端在实例变化时推送；消费者同时也定时（如每 10 秒）拉取兜底；并缓存到本地。这样兼顾了实时性（推）、可靠性（拉兜底）、可用性（缓存）。

五、推 vs 拉对比总结

维度	拉模式（Pull）	推模式（Push）
触发方	消费者定时主动拉	注册中心主动推
实时性	有延迟（轮询周期）	实时
实现复杂度	简单（注册中心近无状态）	复杂（维护订阅/连接）
注册中心压力	高频轮询有压力	维护连接/推送有压力
代表	Eureka	ZooKeeper Watcher、Nacos

没有绝对好坏，实践中推拉结合 + 本地缓存是兼顾各方的最优解。

六、常见误区与追问

这道题面试时最容易丢分的地方，是把「服务发现推拉模式」答成一段泛泛的组件介绍。更稳的答法是先给结论，再沿着服务注册与发现链路拆清楚流程，最后补上异常场景、数字边界和选型取舍。

回答层次	要讲清的内容	容易漏掉的边界
核心定义	拉取简单可靠但有延迟，推送实时性好但需要维护连接；生产常用首次拉取、本地缓存、变更推送的组合	不要停在名词解释
流程机制	客户端启动先拉全量列表 -> 本地缓存服务实例 -> 注册中心监听实例变化 -> 变化时推送增量或通知 -> 客户端兜底定期拉取校准	说明谁触发、谁存储、谁通知、谁兜底
工程取舍	若客户端每 30 秒拉一次，实例下线最长可能延迟接近 30 秒；推送可把延迟降到秒级但连接和通知成本更高	注册信息不是业务数据，短暂不一致通常靠客户端缓存、重试和健康检查兜底

服务发现推拉模式 面试拆解：
1. 客户端启动先拉全量列表
2. 本地缓存服务实例
3. 注册中心监听实例变化
4. 变化时推送增量或通知
5. 客户端兜底定期拉取校准

记忆钩子：先区分注册、发现、心跳、剔除和本地缓存，再说明一致性与可用性的取舍；回答时一定要落到题目中的「服务发现推拉模式」，不要把相邻中间件的能力混着讲。

误区：推送一定比拉取好。 推送实时性更强，但需要连接管理、重试和消息可靠性；规模大时复杂度更高。
误区：拉取模式一定不可靠。 拉取配合短周期、本地缓存和失败重试，也能满足很多服务发现需求。
误区：客户端不需要缓存注册表。 没有本地缓存时注册中心抖动会直接影响调用链路，缓存是服务发现高可用的关键。
追问：为什么常见方案会推拉结合？ 首次拉取保证有基线数据，推送降低变更延迟，定时拉取用于纠偏。
追问：推送丢了怎么办？ 客户端要有版本号、长轮询重试或定期全量拉取，保证最终一致。
追问：如何评价服务下线感知速度？ 看心跳周期、剔除阈值、通知延迟和客户端负载均衡失败重试。

七、加强记忆

服务变更通知两种模式：拉（Pull）——消费者定时主动拉取最新列表（Eureka 默认 30 秒），简单但有延迟、频率两难；推（Push）——消费者订阅后注册中心在变化时主动推送（ZooKeeper Watcher、Nacos 推送），实时但实现复杂、连接有压力。主流是推拉结合：推送为主（实时）+ 定时拉取兜底（防推送丢失、保最终一致）+ 本地缓存（保可用），如 Nacos。口诀：拉是「我定期来问」（简单有延迟）、推是「你有变就说」（实时但复杂）、实战推拉结合加缓存。

简化版

详细版