注：本文章引自终于把分布式事务讲明白了！
在前面的文章中，我们了解了单机库中的事务一致性实现以及分布式事务中的两阶段提交协议。大多数分布式系统都是采用了两阶段提交塄来保证事务的原子性，Greenplum也是采用了两阶段提交，Greenplum的两阶段提交是基于PostgreSQL的基础上实现的。
PostgreSQL的两阶段提交
虽然PostgreSQL是集中式数据库，但是它实现了对两阶段提交协议的支持。PG主要通过PREPARE TRANSACTION、COMMIT TRANSACTION、ROLLBACK PREPARED命令实现对两阶段提交协议的支持。
PREPARE TRANSACTION对应两阶段中的第一阶段，COMMIT/ROLLBACK PREPARED对应两阶段中的第二阶段。
注：参与者prepare时，会将日志落盘，释放一些资源，但不会释放申请的锁。在PG中，执行完PREPARE后如果把数据库停掉再启动，会发现pg_locks中会残留prepared的事务，这是因为在执行prepare的时候，PG会把事务的lock信息作为prepare日志记录的一部分记录在日志文件（xlog）中，当数据库启动后会读这个日志文件把锁还原到pg_lock表里面。在Greenplum中如果QE在prepare后发生崩溃，QD会在函数doNotifyingCommitPrepared里面重试，QE恢复prepare事务的逻辑与上述PG的步骤类似。
Greenplum在PG的事务基础上实现的分布式事务，具体实现的功能如下图。
然后我们看一下Greenplum中分布式事务的信息是怎样在QE和QD之间同步。
当创建一个新的事务时，需要在TMGXACT分布式事务结构体中包含以下信息：
- 分布式事务ID
- 分布式事务管理器启动的时间戳
- 活跃分布式事务中最小的事务ID
- session ID
这些分布式事务信息，包括分布式快照信息，再通过这种序列化的方式，序列化到一个查询计划里面，然后用dispatch的方式发送到segment上。Segment作为参与者，把信息进行反序列化，读到自己的内存里面，从而完成一个QD到QE之间的信息共享。以下是PG中两阶段协议的一些主要函数及大概逻辑。
很多数据库会在标准的两阶段提交协议上做了大量的优化，比如在某些情况下使用一阶段提交。Greenplum也做了相应的优化，比如在QD执行提交前，检查事务是否满足一阶段提交的条件：
- 有写操作，参与者只有一个
- 只读事务
如果满足以上其中一个，QD就会调用函数doNotifyingOnePhaseCommit向参与者发送DTX_PROTOCOL_COMMAND_COMMIT_ONEPHASE命令，QE完成提交。
