跨机房SQL读写分离需分场景权衡一致性：写操作强一致优先，读操作按业务容忍度分级——强一致读主库或会话一致性，最终一致性读从库，分布式事务仅用于关键跨库更新。
跨机房部署下，SQL读写分离与数据一致性不是非此即彼的选择，而是需要分场景、分数据重要性做精细权衡。核心思路是：写操作强一致优先，读操作按业务容忍度分级处理。
读写分离 + 异步复制的常见陷阱
多数数据库（如MySQL主从、PostgreSQL流复制）默认采用异步复制，主库写入后不等从库同步就返回成功。这导致从库存在“复制延迟”，跨机房网络抖动时延迟可能达秒级甚至分钟级。用户刚提交订单就刷新订单页看到“未找到”，就是典型问题。
- 不能把所有读请求都打到从库——尤其是用户刚写完立刻要读的场景（如“发表评论后立即看自己评论”）
- 监控复制延迟（如MySQL的Seconds_Behind_Master）必须接入告警，延迟超阈值时自动将该从库摘除或降级为只读不可用
- 避免在应用层硬编码“读从库”，应通过统一数据访问层（DAL）控制路由逻辑，便于动态调整
强一致读：读主库 or 会话一致性（Session Consistency）
对“写后即读”类请求，最直接方案是强制走主库。但高并发下主库压力大。更优解是引入会话级一致性保障：
- 用户首次写入后，在一定时间窗口（如30秒）内对该用户的后续读请求，全部路由到同一主库或已同步完成的从库
- 可通过中间件（如ShardingSphere、Vitess）或应用层透传一个“一致性标记”（如last_write_ts）实现
- 适合电商下单、社交发帖等场景，用户体验好，且不牺牲主库扩展性
最终一致性读：适用可容忍延迟的查询
报表统计、历史订单归档、后台管理页面等对实时性无要求的读操作，可安全走从库。关键是要明确标注“非实时数据”，避免业务误判。
- 在SQL注释或接口文档中标明“本接口返回最终一致性结果，延迟≤5秒”
- 对聚合类查询（如SUM、COUNT），可考虑物化视图或定时同步宽表，规避跨机房JOIN和实时计算开销
- 避免在从库执行写操作（如临时表INSERT）或依赖自增ID的业务逻辑，防止主从状态错乱
分布式事务：慎用，但关键场景必须兜底
跨机房更新多个数据库（如支付扣款+库存扣减+日志记录）时，单靠数据库复制无法保证原子性。此时需引入分布式事务机制：
- 优先选“本地消息表 + 补偿任务”模式：写主库同时写本地消息表，异步投递MQ，下游服务消费并重试，失败进人工干预队列
- 强一致要求极高且能接受性能损耗时，可用Seata AT模式或XA协议，但务必压测跨机房RT和吞吐，避免雪崩
- 所有跨机房写操作必须有幂等设计（如唯一业务单号+状态机），防止补偿重复执行
基本上就这些。没有银弹，只有根据延迟敏感度、错误容忍度、运维成本做的务实取舍。
