pengtao-tech

最终一致性与下发设计

8分钟阅读

中心到边缘节点的下发与最终一致（版本号、ACK、补偿）

一句话速记

中心节点下发配置/数据到大量边缘节点（如 CDN 节点、IoT 设备、App 端），核心挑战是：如何保证所有边缘节点最终都拿到最新数据。方案：版本号（什么是最新）+ Push/Pull 混合（如何传达）+ ACK（是否到达）+ 补偿扫描（没到达时重发）= 最终一致性。

关键细节

1）典型场景

配置中心下发：
  中心 Nacos/Apollo → 各服务实例（100-10000 个）

内容分发：
  平台内容 → CDN 全球边缘节点（预热/刷新）

规则引擎下发：
  风控规则、定价规则 → 所有机器实时生效

IoT 指令下发：
  云端 → 边缘设备（可能离线）

App 远程配置：
  服务端 → 亿级用户的 App（Feature Flag、AB 测试）

2）版本号设计

中心维护全局版本号（单调递增）：
  每次配置变更 → version++
  或用时间戳：updated_at（有时钟漂移风险，建议单调 ID）

边缘节点维护本地版本号：
  node_version：当前已应用的版本
  拉取时携带：GET /config?since_version=N
  中心返回：所有 version > N 的变更（增量）

全量 vs 增量：
  node_version=0（首次/重置）→ 全量拉取
  node_version=N → 增量（变更 list，从 N 到最新）
  
版本的幂等性：
  同一版本数据重复接收 → 幂等（version 相同不重复应用）
  应用版本：IF version > local_version THEN apply AND SET local_version=version

3）Push / Pull 混合策略

Push（服务器推送，低延迟）：

中心配置变更 → 主动推送到所有节点

实现方式：
  长轮询（Long Polling）：
    节点发起请求，服务端 hold（挂起）直到有变更或超时（30s）
    有变更 → 立即返回 → 节点应用 → 立即发起下一次 hold
    → Nacos、Apollo 的实现方式
    → 优点：实时性好（秒级）；缺点：服务端连接数大
    
  WebSocket / SSE（Server-Sent Events）：
    持久连接，服务端主动 push
    → 适合低延迟、双向场景
    
  MQ（Kafka/RocketMQ）：
    配置变更发消息 → 节点消费
    → 解耦，异步，但多一层中间件

Pull（客户端拉取，兜底）：

节点定时拉取：
  每 60s 主动查询最新配置（即使 Push 失败也能拉到）
  
  作为 Push 的补充：
    Push 因网络问题未到达 → Pull 定时兜底
    
轮询时携带 version：
  GET /config/check?version=5
  服务端：version 5 已是最新 → 返回 304 Not Modified（空响应，省带宽）
  服务端：version 6 已发布 → 返回全量 v6 配置

4）ACK 机制与补偿

ACK 追踪：

数据库设计：
  config_dispatch_log 表：
    id, config_version, node_id, status(PENDING/ACKED/FAILED), dispatched_at, acked_at

Push 后：
  INSERT INTO config_dispatch_log (version, node_id, status='PENDING')
  
节点收到并应用后：
  POST /config/ack { version: N, nodeId: "node-001" }
  → UPDATE config_dispatch_log SET status='ACKED', acked_at=NOW()
  
补偿（Reconciliation）定时任务：
  每 5 分钟扫描：
  SELECT * FROM config_dispatch_log WHERE status='PENDING' AND dispatched_at < NOW()-5min
  → 对这些节点重新 Push（或标记 FAILED，等待节点 Pull 时自然获取）

对账视图（监控）：

SELECT 
    config_version,
    COUNT(CASE WHEN status='ACKED' THEN 1 END) as acked_count,
    COUNT(CASE WHEN status='PENDING' THEN 1 END) as pending_count,
    COUNT(*) as total_count,
    ROUND(acked_count / total_count * 100, 1) as ack_rate
FROM config_dispatch_log
GROUP BY config_version;

-- 告警：ack_rate < 95% 且距下发 > 5 分钟 → 告警（可能有节点挂了）

5）离线节点的处理

节点下线期间（重启、网络中断）→ Push 失败
节点上线后：
  1. 节点注册到中心（上线心跳）
  2. 带本地 version 发起 Pull
  3. 中心返回增量变更
  4. 节点应用 → ACK
  
节点长期离线（IoT 设备）：
  设备重连后全量拉取（version=0）
  或：中心维护每个设备的状态，重连时按需推送差异

6）实际案例：Nacos 配置中心

Nacos 的实现：
  1. 客户端长轮询（30s 超时）：
     GET /listener?dataId=xxx&group=DEFAULT&tenant=&md5=当前配置的MD5
     
  2. 服务端：
     配置未变 → 挂起（hold）29.5s 后返回 304
     配置变更 → 立即通知（返回变更的 dataId 列表）
     
  3. 客户端收到通知 → 立即拉取完整配置（GET /config?dataId=xxx）
  
  4. MD5 作为版本标识（内容 Hash，不是顺序版本号）
     问题：同一 MD5 不能区分先后（两次不同变更恰好内容相同）
     实际：配合 lastModified 时间戳
     
  5. 本地容灾文件：
     配置拉取后写本地磁盘（~/.nacos/config/xxx）
     服务重启时先读本地文件，再异步同步（防止 Nacos 挂了服务无法启动）

延伸追问

  • Q：如果下发顺序不保证（节点先收到 v3，后收到 v2），怎么处理？ → 版本号单调递增 + 节点侧”只应用比当前版本更大的版本”：if (incoming_version > local_version) apply() 。版本号较小的数据被丢弃。中心保证版本单调递增（用数据库自增 ID 或分布式 ID）。
  • Q：边缘节点非常多（10 万+），Push 扩展性怎么保证？ → 分层推送：中心 → 区域节点（几十个）→ 边缘节点（每个区域节点负责几千个边缘）。或用消息总线（Kafka）：中心发一条消息，所有节点订阅，水平扩展无瓶颈。大规模场景（App 端 1 亿用户），用 Pull 为主（服务端无法维护亿级长连接），Push 只用于 VIP 用户/在线用户。
  • Q：版本号和 MD5/Hash 方式的对比？ → 版本号（单调递增）：可以判断新旧顺序，支持增量更新，但需要中心维护序号；MD5/Hash（内容摘要）：无需中心维护序号，但无法判断先后（两个不同版本 MD5 可能相同），只能用于”内容是否变化”的检测，不能用于”哪个更新”的判断。两者结合最好（MD5 快速判断是否变化，version 判断新旧）。

我的记法

  • 版本号：单调递增，节点只应用 version > local_version 的数据
  • 下发：Push（长轮询/WebSocket/MQ）+ Pull（定时兜底，带 version 节省带宽）
  • ACK：dispatch_log 表记录 PENDING/ACKED，定时补偿扫描未 ACK 的节点
  • 离线节点：上线后带 local_version 拉取增量，或 version=0 全量拉取
  • 一句话：「Push 保实时，Pull 做兜底，ACK+补偿保最终一致」

状态

  • 已背速记
  • 能画 Push+Pull 混合的数据流
  • 能解释 ACK 补偿扫描的设计

关系图谱