MySQL集群通过共识协议（如Paxos）、GTID全局有序、分布式两阶段提交等机制实现多节点事务强一致；事务须多数节点确认才提交，否则回滚，且依赖GTID保障幂等与精准故障切换。
MySQL集群（如MySQL Group Replication、InnoDB Cluster 或 NDB Cluster）中，事务处理和一致性保障机制与单机MySQL有本质区别。核心原则是：事务必须在所有节点达成共识后才提交，否则回滚，以此保证数据强一致（或最终一致，取决于配置）。
事务提交需多数节点确认（Group Replication/InnoDB Cluster）
在基于Paxos协议的MySQL Group Replication中，事务不是本地提交就生效，而是广播给组内所有节点，只有获得法定多数（quorum）节点的接收并预提交响应后，发起节点才能正式提交。
- 若网络分区导致节点数低于多数（例如3节点集群挂掉2个），剩余节点自动禁止写入，避免脑裂和数据不一致
- 事务在本地写入binlog并进入“prepare”状态，等待组通信层（XCom）返回多数确认，才执行“commit”
- 未获多数确认的事务会被自动回滚，应用端收到
ER_GROUP_REPLICATION_COMMUNICATION_FAILURE等错误
全局事务ID（GTID）保障复制顺序与幂等性
集群启用GTID（gtid_mode=ON）后，每个事务被赋予唯一GTID（server_uuid:transaction_id），替代传统binlog文件+position定位方式。
- 从节点通过GTID_SET自动跳过已执行事务，避免重复执行，提升恢复和切换可靠性
- 主节点故障切换时，新主能精准识别各从节点同步位点，无需人工比对binlog位置
- GTID强制要求事务在集群内全局有序，同一逻辑操作在所有节点以相同顺序执行，是强一致基础
NDB Cluster事务模型差异（内存表+两阶段提交）
MySQL NDB Cluster底层使用NDB存储引擎，事务由NDB数据节点（ndbd/ndbmtd）而非MySQL Server完成，采用分布式两阶段提交（2PC）。
- 事务请求发往SQL节点，SQL节点协调多个数据节点参与：先发送prepare，全部成功再发commit；任一节点失败则全体rollback
- 所有数据节点内存中保存完整副本，写操作需同步到多数副本（默认2/3）才返回成功，保障高可用与低延迟一致性
- 不依赖binlog复制，因此不支持传统异步复制，但支持备份与跨中心仲裁节点（Arbitrator）防止单点脑裂
应用层需适配集群事务行为
开发者不能假设“执行完COMMIT就一定持久可见”，需正视集群特有的延迟、拒绝写入、连接重试等场景。
- 捕获明确的集群错误码（如1236、3092、3108），区分是网络抖动、节点离线还是事务冲突
- 避免长事务：集群中长时间未提交的事务会阻塞组视图变更与新成员加入
- 读操作建议使用
READ COMMITTED隔离级别，配合SELECT ... FOR UPDATE显式加锁，避免幻读与非确定性结果
MySQL集群通过共识协议、GTID、分布式提交等机制，在节点间协同保障事务ACID特性。关键不在“是否支持事务”，而在“如何让多节点共同遵守同一套事务语义”。配置合理、应用配合，就能在扩展性提升的同时守住一致性底线。
