MySQL主从复制需依业务选异步、半同步或增强半同步模式；跨节点事务用最终一致性+补偿机制；须监控复制延迟与数据校验，应用层须读写分离规范与强一致路由。
主从复制机制是基础保障
MySQL集群中，主从复制是最常用的一致性保障手段。主库写入后，通过二进制日志（binlog）将变更同步到从库，实现数据冗余与读写分离。但默认的异步复制存在主库宕机、未同步事务丢失的风险，因此需根据业务容忍度选择合适模式：
- 半同步复制：至少一个从库确认收到并写入relay log后，主库才返回成功，兼顾性能与一致性；
- 增强半同步（如MGR插件）：基于Paxos协议，自动选主、冲突检测、强一致性写入，适合高可用要求严苛的场景；
- 避免纯异步复制用于核心交易系统，尤其在主库崩溃且未刷盘时易丢数据。
事务隔离与分布式事务协调
单实例内靠InnoDB的MVCC和锁机制保障ACID，但在多节点集群中，跨库/跨分片操作天然打破事务边界。此时需分层处理：
- 尽量设计为单分片事务，例如按用户ID哈希分片，使同一用户的所有操作落在同一节点；
- 必须跨节点时，采用最终一致性+补偿事务（如TCC、Saga），而非强一致XA（性能差、阻塞高、MySQL原生XA在集群中运维复杂）；
- 合理设置事务隔离级别（推荐READ-COMMITTED），避免长事务导致主从延迟加剧或锁争用。
监控与主动干预机制不可少
再好的设计也需可观测性支撑。一致性不是“设好就完事”，而是持续验证的过程：
- 实时监控Seconds_Behind_Master、复制IO/SQL线程状态、GTID执行位置差值；
- 定期用pt-table-checksum校验主从数据逻辑一致性，发现隐性不一致（如跳过错误、非幂等语句）；
- 配置自动告警（如延迟>30秒、checksum差异>0），并预置回切/修复预案（如临时切读流量、重放binlog、重建从库）。
应用层配合降低一致性风险
数据库只是工具，真正决定一致性的往往是使用方式：
- 写操作务必走主库，禁止应用直连从库写入（哪怕测试环境）；
- 读操作若要求强一致（如支付结果页），应强制路由到主库，或利用read-after-write策略加短时缓存/版本号控制；
- 避免存储过程、触发器、自增字段混用等易引发主从不一致的操作；DDL变更需在低峰期执行，并确认所有节点已同步完成。
