配置中心、动态刷新、灰度回滚与故障恢复面试题
本页只放标准回答、追问和原理跳转。
1. 配置中心为什么是控制面
标准回答： 配置中心负责保存、审批、发布和通知，业务数据面读取进程内最后成功快照，不应每次请求同步查配置中心。否则控制面故障会直接拖垮全部业务请求。
原理：控制面与数据面
2. Push、Long Polling 和 Watch 有什么区别
标准回答： Push由服务端主动通知；Long Polling由客户端携带版本发起可挂起请求，变化或超时后立即重连；Watch从某Revision订阅事件，历史压缩或离线过久需重新拉快照。三者最终都应以带版本的当前配置事实为准。
原理：通知模型
3. 为什么不能收到配置后逐字段修改Bean
标准回答： 并发请求可能看到新旧字段混合的半更新，跨字段约束被破坏。应拉取完整版本，解析到临时不可变对象，完成校验和资源构建后用AtomicReference或作用域代理原子发布，失败继续使用旧快照。
原理：版本化快照
4. 怎样防止迟到通知把配置回退
标准回答： 每份配置携带服务端Revision/发布版本，只应用严格更新版本；通知只是失效信号，客户端重新读取当前事实。不能用本地接收时间判断新旧，因为网络会乱序和重试。
原理：版本化快照
5. 配置发布怎样做灰度
标准回答： 先校验，再按实例、租户、可用区或单元发布小范围，汇总实例应用版本并观察错误率、P99、资源池和业务成功率；达标后分批扩大，异常则停止并发布兼容回滚版本。灰度必须有足够真实样本。
6. 数据源、线程池配置能否动态刷新
标准回答： 不能只改字段。资源型配置通常要用新配置创建候选资源、预连接验证、原子切新流量、排空旧任务再关闭；某些不可安全调整的结构应要求重启。构建失败要继续使用旧资源。
原理：资源型配置
6.1 为什么配置改了，有些代码还是旧值
标准回答： 配置刷新要分三层：新值是否进入Environment，Bean是否重新绑定或重建，业务是否仍缓存旧对象引用。@RefreshScope通常是刷新后清理旧目标对象，新访问通过代理创建新目标；已拿到旧引用的异步任务、长任务、静态字段、final常量、构造器里计算出的派生对象不会自动变新。资源型配置还要安全重建和切流。
7. 配置与滚动发布怎样兼容
标准回答： 新旧代码并存时，新字段要有默认值，枚举要支持UNKNOWN，删除或重命名采用Expand–Migrate–Contract：代码先兼容两种配置，发布新配置，确认全部实例迁移后再删除旧字段。
原理：配置兼容窗口
8. 为什么配置回滚不是把值改回去
标准回答： 新配置可能已经启动消费组、提交Offset、发起批任务或切换密钥，改回值只影响未来行为，不能撤销副作用。回滚也是一个新版本发布，需要校验、灰度、资源排空和必要的数据补偿。
原理：回滚边界
9. 配置中心运行时不可用怎么办
标准回答： 已运行实例通常继续使用最后成功快照并监控版本年龄；新实例对数据库地址等核心配置应Fail Fast，非核心配置可用受控默认值。本地快照要校验环境、版本、Checksum和最大年龄，恢复后拉完整事实原子替换。
原理：控制面故障
10. 什么是配置风暴
标准回答： 全局配置变更让大量实例同时拉取、刷新缓存、重建连接池和访问下游，形成控制面和数据面尖峰。应合并通知、随机抖动、分批发布、限速、控制资源预热并发，并把必须逐条执行的命令放到MQ而不是配置中心。
原理：配置风暴
11. 部分实例配置未生效怎样排查
标准回答： 先核对配置身份、版本、Checksum和灰度范围；按实例查看通知、拉取、校验、应用状态；再查长轮询/Watch、权限、本地快照、PropertySource优先级、Bean刷新范围和业务旧值缓存，资源型配置还要检查新旧资源和在途任务。
原理：配置生产Runbook
12. Apollo配置中心的核心原理是什么
标准回答： Apollo用AppId + Env + Cluster + Namespace定位配置。管理员在Portal发布配置，Admin Service写入配置和发布记录；客户端通过Meta Server找到Config Service，启动时拉取配置并合并到本地缓存和Spring Environment。运行时客户端通过长轮询携带本地版本等待通知，收到变化通知后再拉取完整配置事实。业务请求读取本地快照，不应该每次请求访问Apollo。
13. Apollo发布成功是否代表所有实例都生效
标准回答： 不代表。发布成功只说明配置中心保存了新Release；客户端长轮询通知、重新拉取、本地缓存更新、Environment更新、Bean刷新和资源切换都有传播窗口。生产要按实例观察releaseKey、checksum、当前配置版本、刷新结果、错误率、P99和核心业务指标。资源型配置构建失败时应继续使用旧资源并告警。