配置推送的一致性和实时性如何权衡？
简化版
配置中心通常保证服务端发布版本有明确顺序、客户端最终收敛，不承诺所有实例在同一瞬间切换。 实时性靠通知加速，一致性靠版本化存储、主动拉取和周期校准兜底。 对必须协同切换的配置，应使用兼容窗口、分阶段协议或流量闸门，不能把普通推送误当分布式原子提交。
详细版
先区分控制面提交一致性、通知延迟和客户端生效一致性。 发布成功后，网络抖动、离线实例和回调耗时会造成短暂版本分叉。 客户端收到通知后拉取当前完整版本，校验并原子替换；漏通知由长轮询或周期校准修复。
业务按风险定义 SLO，例如 99% 在线实例 5 秒内应用、100% 可达实例 60 秒内收敛。 灰度发布要求版本收敛和业务指标都通过才扩量。 若旧新协议不兼容，先部署双读/双写能力，再切配置，最后移除兼容逻辑。
完整版教学
一、三个“一致”不能混为一谈
服务端一致指读取当前发布版本不会因节点不同长期分叉。 通知一致指客户端能获知有变化，但通知通常只是一种提示。 生效一致指业务线程实际使用同一版本，它还受下载、解析和资源切换影响。
通知负责快，拉取与校准负责对；业务兼容负责承受收敛窗口。
二、常见发布链路
commit immutable version
-> update current pointer
-> notify clients
-> clients fetch current version
-> validate and atomic apply
-> report applied version通知可重复、乱序或丢失，因此只携带“请检查”也能工作。 客户端最终以当前指针为准，而不是回放每一条通知。
三、实时性与成本
短轮询简单但请求量高；长轮询、流式连接或推送能降低发现延迟。 10 万客户端每 5 秒轮询一次约 2 万 QPS，每 30 秒约 3333 QPS。 推送也需要连接维持、限流、批量和重连抖动。
| 机制 | 主要作用 | 失败兜底 |
|---|---|---|
| 推送/长轮询 | 快速发现变化 | 周期校准 |
| 版本化拉取 | 获取完整真值 | 重试与镜像节点 |
| 客户端上报 | 证明实际应用 | 心跳补报 |
四、客户端如何避免乱序
客户端收到事件后读取服务端当前期望版本。 新配置完整校验成功后构造不可变快照并原子交换。 较旧请求迟到时要核对当前期望令牌，不能覆盖已应用的新版本。 回滚创建新的发布序列，因此简单用“内容版本更大”表达回滚并不准确。
五、不能原子切换时怎么办
跨数百个实例不存在零时差切换。 若字段语义不兼容，采用 expand-contract：先让程序同时理解旧新格式，再发布新格式，最后清理旧逻辑。 路由切换可先让新旧集群都就绪，再通过统一入口逐步改权重。 极端场景用业务暂停或栅栏令牌控制写入，但代价是可用性和复杂度。
六、怎样定义收敛 SLO
SLO 要写清目标实例集合、比例、分位时间和不可达实例策略。 例如“发布后 5 秒 99% 在线目标应用，60 秒所有可达目标应用；失败实例自动摘流”。 100 个目标中 98 个成功、1 个失败、1 个未知时，不能只展示成功实例中的 100%。 业务错误率、P99 和关键交易指标也要进入发布门禁。
七、故障与降级
服务端提交成功但通知系统故障时，周期校准仍应最终拉到新版本。 配置中心整体不可用时，客户端继续使用最后正确版本，并按配置风险限制陈旧时间。 安全撤销类配置对时效要求更高，可以缩短校准周期并在超时后失败关闭。 监控发布到通知、通知到拉取、拉取到应用的分段延迟，才能准确定位瓶颈。
八、常见误区与追问
- 误区：推送成功就实现强一致。 客户端可能尚未下载或应用。
- 误区：只要轮询足够快就没有不一致。 实例应用仍存在非零时间窗口。
- 误区：通知必须可靠保存每一条事件。 客户端拉当前状态时，通知可只是失效提示。
- 误区：追求实时可以取消校准。 推送链路仍可能漏消息，必须有反熵机制。
- 追问：强一致配置如何切换？ 用兼容协议、栅栏或暂停业务，而非普通广播。
- 追问：如何量化实时性？ 分段统计发布、发现、下载和应用延迟。
- 追问：离线实例怎么办？ 恢复后主动拉当前版本，未追平前可禁止接流量。
九、加强记忆
- 服务端排序，客户端最终收敛。
- 通知加速，拉取取真值，校准补漏。
- 应用新配置必须校验并原子替换。
- 跨实例原子切换靠业务兼容或栅栏。
- 用分段延迟、收敛率和业务指标共同定义结果。