Appearance
最终一致性：定义可见性和恢复边界
修订于 2026-10-12：原文给出的“正常 100 毫秒到 2 秒”等传播时间没有测量依据，已删除。具体产品保证应查阅对应文档。
最终一致性的核心是：在没有新写入且故障最终恢复的条件下，副本或派生视图会趋于一致。它不保证刚写完马上能读到新值，也不自动承诺固定时长内完成传播。产品往往还提供会话一致、有界陈旧或强一致等不同选项，不能把全部读写行为笼统归为“强”或“最终”。
先写业务可见性要求
不同字段对延迟和不一致的容忍度不同。新闻阅读量可允许短暂延迟；支付状态、库存扣减和权限变更则需要更明确的保证。为每个接口写出：
- 写入成功的定义是什么，是否已经持久化？
- 读请求可以返回多旧的数据？
- 用户写后读是否必须看到自己的更新？
- 若下游投影未更新，界面显示“处理中”还是直接失败？
- 传播超时、事件丢失、重复事件如何检测与修复？
一致性与可靠交付是两件事
数据库和消息系统之间的双写失败会造成状态传播缺口。事务性 Outbox 可让业务写入和待发布事件在同一个本地事务中提交；发布器与消费者仍需处理重复、乱序与恢复。Saga 适合跨服务长流程，但补偿是新的业务操作，不等于数据库回滚。
验证最终会收敛
测试至少覆盖正常延迟、下游停机后恢复、事件重复、乱序、消息积压和人工修复。监控“最新已提交版本”与“各投影已处理版本”的差距，比只看队列长度更接近业务问题。还要给积压设置告警与操作手册，定义何时触发重放或人工对账。
DynamoDB 官方文档说明，最终一致读可能暂时看不到最近完成的写入，并对不同读操作提供不同选项。Azure Cosmos DB 文档列出了强一致、有界陈旧、会话、前缀一致和最终一致等级。它们是具体产品契约，不应抽象为所有数据库都能提供相同选项。