SQL双写一致性需业务层保障，核心是接受短暂不一致并内置可靠补偿机制：写操作幂等、状态可追溯、失败可感知、补偿可调度。
SQL双写一致性无法靠数据库自身完全保障，必须依赖业务层设计。核心思路是：接受短暂不一致，通过可靠补偿机制最终达成一致。
为什么双写天然存在一致性风险
两个独立数据库（如MySQL + Redis、MySQL + Elasticsearch）之间没有跨库事务支持。即使使用本地事务先写主库再发MQ，中间仍可能失败——比如写完MySQL后服务宕机、网络中断或下游写入超时，导致状态分裂。
推荐的补偿机制设计原则
补偿不是“出问题后再补”，而是从一开始就把补偿能力作为系统能力内置：
- 写操作必须可重试：所有下游写入接口需幂等（如用唯一业务ID+版本号/时间戳控制）
- 状态必须可追溯：主库中记录“双写状态字段”（如red">sync_status），初始为pending，成功后更新为done
- 失败必须可感知：同步逻辑需有明确的成功/失败回调，失败时立即落库标记+触发告警
- 补偿必须可调度：提供定时扫描任务（如每分钟查sync_status = 'pending'且updated_time 的记录）并重试
典型补偿流程示例（MySQL → Redis）
用户下单后需同步订单数据到Redis缓存：
- 事务内写MySQL订单表，并插入一条sync_task记录：biz_id=123, target='redis', status='pending', retry_count=0
- 异步线程读取sync_task，调用Redis SET命令；成功则更新status='done'，失败则retry_count+1并延迟重试（如指数退避）
- 独立补偿服务每2分钟扫描retry_count 的任务，重新发起同步
- 若重试3次仍失败，转人工介入或写入死信队列供排查
进阶建议：避免强依赖双写
真正高可靠的方案往往不是把双写做更稳，而是减少对双写的实时性依赖：
- 读场景优先走主库，缓存仅作性能优化（Cache-Aside模式），接受缓存击穿而非强一致
- 搜索类同步走MQ+消费确认机制，配合消费位点管理和重复消息过滤
- 关键业务（如支付）改用最终一致性模型：主库单写，下游通过binlog订阅（如Canal）解析变更，降低应用层同步复杂度
不复杂但容易忽略。
