drds mysql兼容_DRDS 技术内幕 — 分布式强一致事务的支持

原标题：DRDS 技术内幕 — 分布式强一致事务的支持

前言

DRDS 在最新的第三代分布式 SQL 引擎中新增了对 TCC(Try-Commit-Cancel)柔性事务的支持。实际中我们发现，许多用户前来咨询是否支持强一致事务。在最新发布的版本中，DRDS 新增了 XA 强一致分布式事务、以及兼容 MySQL 5.6 的 2PC 事务模式的支持。

分布式事务 XA 协议

XA 协议是 X/Open 组织提出的通用的两阶段提交(2-Phase Commit)事务协议，用于协调分布式系统的各个组件、执行分布式事务。如下图所示，XA 协议中包含两个主要角色：事务管理器和资源管理器。

资源管理器(Resource Manager, RM)是指参与分布式事务的资源方，例如用户数据库；

事务管理器(Transaction Manager, TM)保存了事务的状态信息(提交或回滚)。

当分布式事务提交途中发生故障，例如 RM 或用户应用程序宕机，RM 需要向 TM 询问分布式事务的状态，决定应当提交还是回滚，从而保证分布式事务的原子性。由此可见，TM 的事务状态至关重要，且需要具备高可用性。

XA 强一致分布式事务

DRDS 对上述 XA 事务的提交过程针对分布式数据库场景做了优化，TM 的事务状态同样保存在后端数据库(即 RM)上，由 DRDS 节点进行协调，无需额外部署组件。

具体而言，在参与分布式事务的各个分库中选出一个主库(Primary DB)，主库上除了用户数据之外，还会向事务日志表中写入提交状态；主库之外的其他分库则需要用 XA 协议进行两阶段提交。

如下图所示，分布式事务提交时，主库上写事务状态和用户 SQL 在同一个本地事务完成。而其他分库在主库提交前完成 PREPARE，主库提交成功后进行 COMMIT。

当某一分库进行故障恢复时，通过查询主库上的事务状态，即可确定应当向前提交(roll forward)或是向后回滚(roll back)。

需要特别注意的是，MySQL 的可重复读(REPEATABLE-READ)隔离级别采用快照读，由于 XA 协议的缺陷，无法保证读到全局一致的快照。其他隔离级别(读未提交、读已提交、可串行化)没有这个问题，分布式事务下隔离级别与单机事务保持一致。

2PC 分布式事务

旧版本的 MySQL XA 协议实现存在一个致命的 bug，直到 5.7.7 版本才被修复。我们的客户中有很多仍在使用 MySQL 5.6，为了让这部分用户也能使用分布式事务，DRDS 还提供了 2PC 事务策略。

顾名思义，2PC 事务同样使用两阶段提交方案。与 XA 事务不同之处是：DRDS 在分库上使用一张内部表 REDO_LOG记录事务过程，而不是依赖 XA PREPARE 内部实现，如下图所示。

当某一分库进行故障恢复时，若发现 REDO_LOG 中还有未完成的事务、且主库事务状态为已提交，DRDS 会立即执行该事务；否则，丢弃掉这部分日志。

上述过程中，在极少数情况下(例如 MySQL 宕机恢复)可能出现用户 SQL 先于 REDO_LOG 执行，可能导致脏写发生。

DRDS 事务体系总结

目前，最新版本的 DRDS 支持以下四种事务策略，用户可以根据实际业务场景，选择最合适的事务策略。

策略

描述

特性

适用场景

FREE

允许多写

不保证原子性，无性能损耗

数据批量导入、表初始化等场景

2PC

两阶段提交事务

保证原子性，不保证可见性

推荐 MySQL 5.6 用户使用

XA

XA 强一致事务

保证原子性，保证可见性

推荐 MySQL 5.7 及更高版本用户使用

FLEXIBLE

TCC 补偿型事务

适用于性能要求较高、高并发的业务场景

更多关于 DRDS 分布式事务的介绍，请关注后续的文章。返回搜狐，查看更多

责任编辑：