。早期MySQL保证数据一致性的方案核心是基于二进制日志binlog的主从复制并围绕它构建了读写分离和双机热备等架构。在保障数据一致性方面存在明显的缺陷做运维的人都深有体会。这是当时最基础的架构所有高级方案都建立在此之上。基本原理主库Master将所有数据变更写入binlog从库Slave的I/O线程拉取这些日志并写入本地relay log随后SQL线程重放日志中的SQL语句从而实现数据同步。整个过程默认是异步的。读写分离基于此架构将写操作指向主库读操作分散到多个从库以此提升系统整体的吞吐能力早期增强一致性的辅助手段为了改善数据一致性当时也有一些辅助实践半同步复制Semi-Synchronous ReplicationMySQL 5.5引入。主库需等待至少一个从库确认收到binlog后才向客户端返回成功。这降低了数据丢失风险但可能增加写入延迟且仍有退化回异步复制的可能。行级复制Row-Based Replication, RBRMySQL 5.1引入。binlog记录的是数据行的实际变更如某行某字段从A变为B解决了基于语句复制SBR在使用NOW()等非确定性函数时的数据不一致问题。第三方工具如MHAMaster High Availability可在主库故障时自动将数据最接近的从库提升为新主库并尝试补录差异数据尽量减少数据丢失。方案的局限性受限于当时技术这些方案普遍存在以下痛点数据丢失风险异步复制下主库崩溃时尚未同步到从库的事务可能永久丢失。主从延迟从库同步必然存在延迟在读写分离场景下会导致用户读到旧数据。切换复杂且有风险早期缺乏自动化高可用工具故障转移常需人工介入过程复杂且易出错。复制中断与不一致网络问题或从库执行出错可能导致复制中断而基于语句的复制SBR本身就存在导致主从数据不一致的隐患。总的来说这些早期方案是MySQL在高可用和数据一致性探索上的重要阶段为后续更成熟的GTID、增强半同步和MGRMySQL Group Replication等技术的诞生奠定了基础特性GTID增强半同步MGR (组复制)核心思想为事务提供全局唯一ID主库等待从库确认接收binlog基于共识协议的集群决策主要解决的问题简化主从切换和复制管理防止主库故障时的数据丢失提供数据强一致性和自动高可用数据一致性高(基于事务)较高(无损复制)最高(基于Paxos的强一致)性能影响低中等(取决于网络和从库性能)较高(多数节点确认带来延迟)复杂度低中等高适用场景需要自动化运维和简化故障切换的场景对数据安全有较高要求的大多数核心业务金融、支付等对数据一致性要求极高的核心系统当今最主流的方案归纳为四大范式根据业务对“一致性”和“可用性”来权衡。范式一经典自治架构业界绝对主流核心组合GTID 增强半同步复制AFTER_SYNC Orchestrator或MHA定位大多数互联网业务的“黄金标准”在性能、一致性和运维成本间取得最佳平衡。怎么玩采用一主多从所有事务必须等待至少一个从库确认Binlog落盘后才提交保证无损。搭配Orchestrator这类工具它能实时探测拓扑在主库宕机时自动计算各从库的Binlog差异选出数据最完整的从库一键提升为新主。杀手锏相比老旧的MHAOrchestrator支持拓扑可视化和故障后自动恢复且能优雅处理网络分区避免错误切换。隐患仍是“单点写”且极端情况下所有从库都来不及同步时仍有极小概率丢数据但已满足99.9%的场景。范式二官方原生集群架构未来演进方向核心组合MySQL InnoDB ClusterMGR组复制 MySQL Router定位MySQL官方钦定的“下一代”高可用方案解决脑裂和手工切换的痛点。怎么玩底层基于MGR组复制的Paxos共识协议事务需集群多数派节点N/2投票通过才提交天然保证数据强一致。上层配套MySQL Shell提供一键部署脚本MySQL Router作为轻量级中间件自动感知集群主节点变化并将写流量路由到正确节点。杀手锏内置自动化防脑裂机制成员自动驱逐且支持单主/多主模式切换虽官方建议生产用单主。代价对网络延迟极其敏感建议10ms内网且性能损耗高于异步复制适合金融级核心交易系统。范式三同步多写架构严苛一致性场景核心组合Galera Cluster for MySQL或Percona XtraDB Cluster (PXC)定位“几乎零延迟”的同步复制适合需要任意节点读写且不允许丢数据的极端场景。怎么玩基于Certification-Based Replication基于认证的复制事务在本地执行后需广播给所有节点进行全局冲突认证所有节点同时提交或同时回滚。它提供真正的“多主写入”且节点加入集群时通过State Snapshot TransferSST自动同步数据。杀手锏读性能极佳本地读且故障节点恢复后能自动增量同步IST。致命伤写入性能受限于集群中最慢的节点且在大事务或网络抖动时极易引发整个集群的“流控”Flow Control导致TPS骤降。范式四云原生解耦架构未来的形态核心组合AWS Aurora / 阿里云PolarDB的共享存储Shared-Storage架构定位重新定义“主从”将计算与存储分离从底层物理日志层面解决复制延迟。怎么玩主从节点不再通过传输Binlog重放SQL来同步而是将Redo Log写入共享的分布式存储卷如云盘。从库称为“Replica”直接读取存储卷上最新的数据页省去了SQL回放过程从物理层面实现极低延迟毫秒级。杀手锏支持“快照回滚”和“秒级添加只读节点”且由于日志是持久化到共享存储的主库宕机时无需“补录Binlog”新的主库瞬间就能在存储层拿到完整数据数据零丢失RPO0。门槛深度绑定特定云厂商存在技术锁定且成本较高。终极选型速查如果非要给一个当下的“标准答案”初创或常规业务直接采用云厂商的RDS托管服务本质是范式一的封装让平台替你做自动备份和HA切换。自建机房且不想太折腾采用范式一GTID 增强半同步 Orchestrator这是目前社区生态最成熟、踩坑最少的路子。交易、支付等高要求的核心链路优先考虑范式二InnoDB Cluster因为它有官方的标准化支持且能彻底解决困扰DBA多年的“主从切换后数据错乱”问题。对多机房容灾有要求可以结合半同步 跨机房专线或直接使用云原生的跨AZ部署方案范式四。下期将详细介绍每种范式的实操过程