写一致性 (Write Consistency) 关注的是：当数据发生变更时，如何保证所有存储介质（数据库、缓存、多个副本）都能正确、原子地记录这次更新，不产生脏数据。
在缓存架构中，写一致性最核心的问题就是如何安全地完成“双写”逻辑。
写一致性级别
按保障强度从强到弱排序，具体实现细节请参考子文档：
- 强一致性 (Strong Consistency)：写操作完成后，所有后续读写都能立即看到最新值。
- 顺序一致性 (Sequential Consistency)：保证所有节点看到的写操作顺序一致。
- 因果一致性 (Causal Consistency)：保证有逻辑因果关系的写操作按顺序生效。
- 最终一致性 (Eventual Consistency)：保证数据最终会达到一致状态。
场景与对策
写一致性的破坏通常源于分布式系统的不可靠性以及并发控制的缺失：
| 场景分类 | 典型问题 | 核心对策 |
|---|---|---|
| 原子性破坏 | DB 成功但 Cache 失败、宕机导致补偿中断 | Transactional Outbox、MQ 重试补偿、Binlog 订阅 |
| 竞态条件 | 写-写冲突（旧覆盖新）、写-读-写冲突 | 分布式锁、乐观锁 (CAS/版本号)、旁路缓存 (Cache Aside) |
| 顺序错乱 | 消息乱序消费、主从切换窗口数据滞后 | 写幂等设计、延迟双删、顺序消息队列 |
| 长事务复杂性 | 跨服务批量更新部分失败 | Saga / TCC 模式、定期对账治理 |
总结
在设计写一致性方案时，Cache Aside 配合 合理的 TTL 是大多数互联网场景的首选。对于金融等严苛场景，则需要引入 分布式事务 或 强一致性协议。