SQL数据库一致性设计需依业务在强一致与最终一致间取舍：强一致靠ACID与锁保障，适用于银行转账等场景；最终一致通过异步+补偿实现，用于微服务跨库场景；混合策略则写主库强一致、读从库接受延迟。
SQL数据库的数据一致性设计，核心在于根据业务场景在强一致和最终一致之间做合理取舍。强一致保障事务执行后所有读操作立即看到最新结果，但可能牺牲性能与可用性；最终一致允许短暂不一致，换取更高吞吐与弹性，需额外机制保障收敛。
强一致性：靠ACID与锁机制保障
传统关系型数据库（如PostgreSQL、MySQL InnoDB）默认提供强一致性，依赖ACID特性实现：
- 原子性：通过undo log保证事务全部成功或全部回滚
- 一致性：由约束（主键、外键、CHECK）、触发器和应用逻辑共同维护
- 隔离性：利用行级锁 + MVCC（多版本并发控制），避免脏读、不可重复读；可设SERIALIZABLE级别彻底规避幻读
- 持久性：redo log写入磁盘确保崩溃后数据不丢失
典型适用场景：银行转账、库存扣减、订单支付——任何中间态的不一致都不可接受。此时应避免跨库事务、慎用长事务，并通过索引优化减少锁等待。
最终一致性：异步解耦+补偿机制
当系统拆分为微服务或需跨数据库/外部系统协同时，强一致难以维持，转而采用最终一致方案：
- 用本地消息表或事务性消息队列（如RocketMQ事务消息）记录操作意图，再异步投递
- 关键路径上引入幂等接口与状态机（如订单状态流转：created → paid → shipped），防止重复处理
- 对账服务定时扫描不一致数据，触发补偿任务（如补发通知、回滚异常订单）
- 读服务可结合缓存（Redis）+ 数据库双写策略，但需用延迟双删或binlog监听保证缓存与DB最终同步
注意：最终一致不是“放任不一致”，而是明确不一致窗口期（如秒级）、定义收敛条件，并监控延迟与失败率。
混合策略：读写分离下的权衡
高并发读多写少场景常混合使用两种模型：
- 写操作走主库，强制强一致；读操作路由至从库，接受短暂延迟（半同步复制下通常
- 对一致性敏感的读（如用户刚提交的评论立即查看），可强制打标走主库（“读己之写”）
- 报表类查询走只读副本+物化视图，容忍分钟级延迟，减轻主库压力
这种架构需清晰标注各接口的一致性级别（SLA），并在API文档或OpenAPI中显式说明。
设计关键：从业务语义出发，而非技术偏好
判断该用强一致还是最终一致，本质是回答三个问题：
- 用户能否感知并容忍几秒内的数据偏差？（例如点赞数晚显示2秒无妨，但余额错误1分钱即客诉）
- 系统故障时，优先保可用性（AP）还是保一致性（CP）？金融核心系统通常选CP，内容推荐系统倾向AP
- 不一致带来的修复成本是否高于预防成本？若对账补偿逻辑复杂且易出错，不如初期就用分布式事务框架（如Seata AT模式）保强一致
没有银弹，只有适配业务节奏的一致性契约。
