最终一致性（Eventual Consistency）是分布式系统中的一致性模型：系统允许不同副本、服务或设备在一段时间内看到不同状态，但如果没有新的更新，并且同步、重试和冲突处理机制持续工作，相关状态最终会收敛到一致结果。
在 设备影子 中，desired 和 reported 不要求实时相等；设备离线时它们可以不同，设备上线执行并上报后才逐步收敛。这就是一种最终一致性的工程形态。
核心问题
分布式系统很难同时满足强实时一致、低延迟、高可用和弱网容忍。尤其在 IoT、跨地域服务、缓存、消息队列和数据库副本中：
- 节点可能离线或网络分区。
- 消息可能延迟、重复或乱序。
- 写入可能先到一个副本，再异步传播到其他副本。
- 强制所有参与方同步确认会增加延迟并降低可用性。
最终一致性选择接受短暂不一致，用异步传播和补偿机制换取可用性、延迟和扩展性。
核心对象
| 对象 | 含义 | 工程关注点 |
|---|---|---|
| replica | 状态副本 | 数据库副本、缓存、设备本地状态、云端影子 |
| update | 状态更新 | 写入顺序、版本、幂等键 |
| propagation | 更新传播 | 消息队列、同步任务、心跳、拉取 |
| convergence | 收敛 | 所有相关副本最终得到兼容状态 |
| conflict | 冲突 | 并发写、乱序写、旧版本覆盖新版本 |
| version / timestamp | 版本信息 | 冲突检测、条件更新、调试证据 |
| reconciliation | 对账和修复 | 重试、补偿、合并、人工处理 |
核心机制
最终一致性的抽象条件可以写成：
if no new writes occur and synchronization keeps running:
replicas converge to the same logical stateno new writes occur表示系统进入一个静止窗口，否则状态可能一直变化。synchronization keeps running表示消息投递、重试、拉取、补偿任务或副本复制没有永久失败。same logical state不一定要求字节完全一样，但业务语义必须一致。
一个典型异步同步流程如下：
- 客户端向副本 A 写入新状态。
- A 立即返回成功，提高可用性和低延迟。
- A 把更新通过消息、日志或复制协议传播给副本 B、C。
- B、C 可能稍后才应用更新。
- 如果出现并发更新，系统按版本、时间戳、合并规则或业务规则解决冲突。
- 所有副本最终达到一致的业务结果。
在设备影子里，可以对应为：
desired(version=18) -> device applies -> reported(version=18-compatible)这里 reported 不一定保存同一个 version 字段，但它必须表达“设备已经达到或拒绝了该 desired 目标”的业务结果。
工程用途
- 弱网或离线设备状态同步。
- 多副本数据库、缓存刷新和搜索索引更新。
- 事件驱动系统中的跨服务状态传播。
- OTA、设备配置、告警确认和后台任务状态回写。
- 跨地域业务系统中降低同步写延迟。
工程上常配套使用版本号、幂等键、重试、死信队列、对账任务、超时告警和人工补偿流程。
边界与常见坑
- 最终一致性不是没有一致性：必须能说明何时、通过什么机制、在什么条件下收敛。
- 最终不等于很快：收敛时间可能受网络、队列积压、设备休眠和重试策略影响。
- 没有冲突规则就没有可靠收敛：并发写入必须定义 last-write-wins、合并、拒绝旧版本或业务仲裁。
- 不能用于所有业务：扣款、库存强扣减、强实时安全控制等场景可能需要更强一致性或事务边界。
- 读到旧值是设计结果，不是一定是 bug：但系统要能暴露版本和更新时间，让调用方知道数据新鲜度。
- 重试必须幂等：否则消息重复会造成重复执行、重复扣费或重复控制。