在分布式数据库的世界里， 事务的原子性和 系统的可用性之间始终存在着一对天然的矛盾——要保证跨节点事务的 ACID，就离不开两阶段提交（2PC）；而 2PC 中协调器一旦宕机，就可能造成事务悬挂甚至集群阻塞。南大通用GBase 8c数据库（gbase database）是如何化解这个矛盾的？本文将从分布式架构出发，深入剖析其 2PC 事务状态保持机制，看看它是如何在保障强一致性的同时，实现协调器故障下的无感切换。
一、GBase 8c 的分布式骨架：CN、DN 与 GTM
理解事务机制之前，先要看清 GBase 8c 的分布式架构。
南大通用GBase 8c（gbase database）采用 Shared-Nothing 的分布式架构，计算节点和存储节点分离，节点间通过高速网络通信。集群包含三类核心角色：
- CN（协调器） ：负责接收客户端连接、解析 SQL、生成分布式执行计划，并将任务下发给相应的 DN 节点。多个 CN 节点完全对等部署，任一 CN 均可对外提供完整的数据库视图。
- DN（数据节点） ：实际存储数据的节点，保存表和索引等数据库对象。每个 DN 采用主备高可用架构，主备之间可配置同步或异步复制。
- GTM（全局事务管理器） ：负责生成和维护全局事务 ID 与快照信息，确保分布式场景下的全局一致性。
二、分布式事务的挑战：2PC 的两难困境
当事务只涉及单个 DN 时，CN 可以直接向该 DN 发起本地事务，无需 2PC，性能非常高。但当事务需要跨多个 DN 操作时，就必须依靠 两阶段提交协议来保证原子性。
2PC 的执行流程分为两个阶段：
- 准备阶段：CN 向所有参与的 DN 发送 Prepare 请求，各 DN 执行事务操作并持久化准备状态，然后返回 Prepare OK。
- 提交阶段：CN 收到所有 DN 的 Prepare OK 后，发送 Commit 指令；各 DN 完成提交并返回 Commit OK。
这套机制在正常情况下运转良好，但存在一个致命的脆弱点—— 协调器（CN）是单点。如果在第二阶段，CN 在发送 Commit 后、收到所有 Commit OK 之前宕机，就会出现一个可怕的情况：
部分 DN 已经提交了事务，部分 DN 还在等待最终的提交指令。事务处于“悬空”状态，已申请的锁无法释放，其他事务可能因此被阻塞。严重时，整个集群可能陷入卡死。
这就是经典 2PC 的 阻塞问题——协调器故障会导致事务状态无法最终确定。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69979120/viewspace-3185263/ ，如需转载，请注明出处，否则将追究法律责任。
