MyCAT、DRDS、TIDB、TDSQL、TBase 在实现分布式事务时的区别及其各自的优势？

TBase 是基于 PostgreSQL 开发的企业级分布式 HTAP 数据库，这里介绍下 TBase 在分布式事务方面的一些经验：

**1.传统基于 MVCC+2PC+GTM 做的分布式事务，在高并发的情况下这种基于 GTM 全局快照的设计会在 GTM 上有比较大的性能压力。**一个是 GTM 加锁遍历生成全局快照中活动事务列表计算的开销以及锁冲突开销，另一个是高并发下活动事务列表过大导致快照大小膨胀带来的网络开销。这两点导致这种设计在高并发情况下性能受限。

**2.Google Spanner 基于原子时钟和 true time api 实现了一致性的分布式事务，但需要昂贵的设备支持。**Google Percolator 采用全局时钟提供一致性分布式事务，但 Percolator 在一阶段提交时需要遍历数据将锁信息写入到数据单位，二阶段时又需要遍历数据释放锁写入提交时间戳等信息。事务提交开销变大且与数据量相关。

**3.TBase 在参考 Spanner/Percolator 的基础上，为避免上述性能问题，创新性的结合 MVCC+2PC 提出了一种轻量级的基于全局时钟（GTS）的一致性分布式协议及算法。**主要思路是在两阶段提交中的 prepare 阶段作为全局同步点结合 GTS 的原子递增性保证多节点间的数据一致性和隔离性。基本消除 GTM 的网络开销问题，并将 GTM 单点压力分散到分布式多节点中。主要从以下几个方面进行优化：

MVCC 从基于全局快照事务 ID+事务状态的可见性判断，优化为基于 GTS+事务状态的可见性判断在当前节点 prepare 到收到 commit 通知之前会有事务锁保证全局一致

为了避免 Percolator 的提交开销变大的情况，TBase 在提交时只记录一次事务提交 GTS 到时间戳日志，避免提交开销。

后续进行可见性判断时，结合时间戳日志判断事务状态，且对时间戳日志进行缓存加速。随后在 tuple 的 header 记录中缓存事务状态及提交 GTS 信息，进一步加速后续扫描的可见性判断。

1.TBase 同时对 MVCC 空间回收进行改造，融入到基于 GTS 的一致性分布式事务中。

2.优化后 GTM 只负责分配全局时间戳，且设计了一种多核可扩展的全局原子递增时间戳算法进一步提高单点 GTS 分配性能。