DRDS 柔性事务漫谈

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云数据库 RDS SQL Server,独享型 2核4GB
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介: 在阿里巴巴,“柔性事务” 已经是重构分布式事务的标准方法,覆盖了商品、交易、支付各个大规模应用场景,并且经受了双十一的考验。

DRDS 是阿里云提供的一款分布式数据库产品,它的原型是在阿里内部使用了 10 年的数据库中间件 TDDL。DRDS 在 TDDL 提供的数据切分和 SQL 路由能力上,强化了分布式查询,事务和水平扩容能力。

什么是柔性事务?

在分布式数据库中,数据存储在多个节点将引入两个问题:

  • 分布式事务 - 业务需要更新多个节点的数据。
  • 全局二级索引 - 查询无法准确的定位数据位于哪个节点。

由于全局二级索引的同步依赖于事务,因此 分布式事务 是所有分布式数据库产品都需要解决的核心问题。这一问题的关键是 —— 数据存储在多个节点,原本在单机数据库上不难实现的 ACID 特性在分布式环境下变得困难:

  1. 因为网络通信的不可靠,事务的原子性需要用多次日志和网络通信来保证。
  2. 存储节点的增加,放大了单个存储节点在事务过程中出现故障的风险。
  3. 用锁实现的事务隔离性,在故障或网络抖动时严重影响性能。

因此,在高可用与高性能的应用场景,分布式事务的最佳实践是放弃 ACID,遵循 BASE 的原则重构业务流程:

1526715684758-6f375480-89d4-43fd-a2c9-3f

区别于 ACID 特性的数据库事务,这种放弃强一致性,采取最终一致方式执行的分布式事务称为 “柔性事务” (Flexible Transactions)。

在阿里巴巴,“柔性事务” 已经是重构分布式事务的标准方法,覆盖了商品、交易、支付各个大规模应用场景,并且经受了双十一的考验。阿里内部最常用的柔性事务方案有 “消息事务” 与 “TCC 事务” (Try / Confirm / Cancel),它们的基本原理是一致的:

  1. 将业务中的分布式事务分解成一个个在独立分库上执行的子事务。
  2. 用异步重试的方式执行这些子事务,由框架或应用保证重试的 “幂等”(相同的业务逻辑不会被重复执行)。
  3. 如果需要回滚,以同样方式执行另一组子事务组成的补偿操作,恢复事务前的业务状态。

柔性事务放弃了隔离性,减小了事务中锁的粒度,使得应用能够更好的利用数据库的并发性能,实现吞吐量的线性扩展。异步执行方式可以更好的适应分布式环境,在网络抖动、节点故障的情况下能够尽量保障服务的可用性 (Availability)。因此在高可用、高性能的应用场景,柔性事务是最佳的选择。

但是,现有的柔性事务方案都存在一个共同问题:它们是以框架或者中间件的形式存在,应用需要付出较大的改造成本:

  1. 框架和中间件的接口带来了学习成本。
  2. 用户需要理解一些概念(例如 “可靠消息” “幂等”)才能正确的使用。
  3. 需要业务流程去适配工具,应用不但在架构上要大幅调整,而且还影响业务流程的直观性。

有没有更好的方案?

有。 DRDS / TDDL 在新发布的 5.3 版本开始提供两种类型的分布式事务:柔性事务 (FLEXIBLE) 和两阶段提交事务 (XA)。前者将柔性事务与传统数据库的使用方式相结合,提供了简单易用、低成本、高性能的 DRDS 分布式事务功能。

使用 DRDS 柔性事务

开启 DRDS 柔性事务只需要一行代码:

SET drds_transaction_policy = 'flexible';

SHOW VARIABLES LIKE 'drds_transaction_policy'; 
+-------------------------+----------+
| VARIABLE_NAME           | VALUE    |
+-------------------------+----------+
| drds_transaction_policy | FLEXIBLE |
+-------------------------+----------+
1 row in set (0.07 sec)

除了一行代码,DRDS 柔性事务的使用方法和普通事务完全相同:应用首先用 SET autocommit = 0SET drds_transaction_policy = 'flexible' 开启柔性事务;然后在同一个会话中执行事务的 SQL 语句 —— 最后当应用发起 commitrollback 后,DRDS 将保证这些 SQL 语句执行的原子性:全部成功,或者全部失败。

相比 TCC 或消息事务, DRDS 不需要业务编写补偿操作的回滚语句。DRDS 会根据事务中 SQL 语句的语义,自动生成相应的补偿操作。

例如,如果业务执行的是一条典型的资金扣减操作:

UPDATE account SET balance = balance - 100 WHERE id = 123 AND balance >= 100

DRDS 会自动生成对应的反向退款操作:

UPDATE account SET balance = balance + 100 WHERE id = 123

由于柔性事务的弱隔离性,应用通常会担心:提交失败后,异步回滚操作是否会覆盖并发的更新,造成 "Lost update" 或者 “回滚覆盖” 问题。在传统 TCC 或消息事务中,回滚覆盖问题需要由应用引入状态、版本号、或乐观锁机制来规避。

DRDS 柔性事务则使用了一些创新的方式来解决这个问题:

1. 增量回滚

前面的例子已经展示了增量回滚是如何工作的:如果 DRDS 识别应用的 UPDATE 语句中包含 “增量操作”,例如:balance = balance - 100,则会在回滚语句中使用 balance = balance + 100 进行补偿。由于增量操作的结果与顺序无关,即使事务异步回滚,也不会覆盖任何一笔业务的更新结果。

增量操作的定义是 UPDATE 语句符合以下格式:

UPDATE {表名} SET {列名} = {列名} [+/-] {常量表达式}, ... WHERE {条件表达式}

增量回滚对账户、积分、库存这样的字段非常有用,而这些字段又通常是需要用分布式事务严格保证一致性的关键数据。建议在应用中尽量对这一类字段采用 “增量操作” 的方式更新,既节省了一次数据库操作(SELECT),又避免了柔性事务 “回滚覆盖” 的风险。

2. 关键事务

另一个防止回滚覆盖的方法是 “关键事务”。

在 DRDS 柔性事务中,应用第一次在事务内执行的 DML(INSERT/UPDATE/DELETE) 操作被放入 “关键事务” 内执行。在柔性事务的执行流程中,“关键事务” 总是第一个开始,最后一个提交。

1525448533171-650e00b4-d216-461d-bdd7-06

DRDS “关键事务” 的执行机制与单机事务相同,不需要记录补偿操作,也不需要异步回滚。因此,把具有回滚覆盖风险的 UPDATE 操作放入 “关键事务” 内执行,是一个防止异步回滚的好方法。

“关键事务” 的设计,可以让一个 DRDS 单机事务自然切换到分布式事务。在传统的柔性事务方案中,应用需要识别业务场景是不是存在分布式事务,然后再根据场景采用不同的事务方式。而 DRDS 的特殊设计,可以做到开启柔性事务,执行单机事务也不产生任何额外代价。

3. 后置执行

第三个方法是使用 “后置执行” 优化事务流程,防止产生回滚。

DRDS 提供了一个全新的 SQL 执行方式:“后置执行”。用来优化分布式事务中不影响业务最终执行结果的跨库操作。在分布式事务理论中,这一类优化被称为 “Best Efforts 1PC”:

1525448540525-8d215a32-e5bc-4f3d-8826-5b

使用 “后置执行” 非常简单,只需要在 SQL 语句的头部加入 /*TDDL:DEFER*/:

/*TDDL:DEFER*/ UPDATE account SET balance = balance + 100 WHERE id = 123

DRDS 保证后置执行的 SQL 仅仅执行一次,不需要应用关心出错重试或者幂等的问题。

“后置执行” 将事务中同步执行的操作转移至异步执行,减少了分布式事务中持有锁的时间,提高了事务执行的并行度,因此可以很好的提升分布式事务的性能。同时,由于 “后置执行” 用异步重试替代了回滚,它也是解决回滚覆盖问题的另一个方法。

使用 DRDS XA 事务

新版本 DRDS 也支持 XA 事务,在柔性事务的基础上提供了强一致能力。

SET drds_transaction_policy = 'XA';

SHOW VARIABLES LIKE 'drds_transaction_policy'; 
+-------------------------+-------+
| VARIABLE_NAME           | VALUE |
+-------------------------+-------+
| drds_transaction_policy | XA    |
+-------------------------+-------+
1 row in set (0.07 sec)

DRDS XA 事务使用两阶段提交协议 (XA Protocol) 保护子事务的提交与回滚,消除了柔性事务的异步回滚问题。由于 XA Protocol 在提交与回滚阶段始终加锁,避免了事务结束前的脏读和覆盖,但是对性能有较大影响。

“后置执行” 功能在 DRDS XA 事务中同样可用,能够减少 XA 协议中的锁,提供了进一步的性能优化空间。

由于 MySQL XA 实现机制的限制,我们建议只有在 DRDS 后端是 MySQL 5.7 版本以上才启用 XA 事务功能。

低成本、高性能

从稳定性和成本出发,DRDS 柔性事务不引入额外的服务和存储节点,而是利用后端的 RDS/MySQL 存储事务日志和回滚信息。在实现上,DRDS 尽可能的减少了事务过程中的数据传输和日志开销,以提升分布式事务的性能。

使用 sysbench 压测工具表明,在标准的 8core 16G 规格 DRDS 实例上,开启柔性事务可以达到 9000 QPS 的优异性能。相比不开启事务的 sysbench 压测结果,性能差异不到 10%.

事务性能对比.png

小结

从分布式事务的原理出发,最终一致的 “柔性事务” 与提供 ACID 保证的 “强一致事务” 是两个独立的发展方向。前者实现了更高的水平扩展能力与性能,代价是应用需要付出额外的开发成本;后者提供了强一致的数据访问和更好的开发体验,但存在性能上的限制。

作为行业领先的云原生分布式数据库,DRDS 同时在两个方向拓展产品的边界:

  • 降低应用使用 “柔性事务” 的开发成本。
  • 持续创新,提升 “强一致事务” 的性能和扩展性。

DRDS 新版本提供的分布式事务功能(柔性事务以及 XA 事务)正是第一阶段的成果。

未来的 DRDS 产品将为企业用户提供更多、更好的选择:作为基础的 “强一致事务”、标准的全局事务隔离级别、基于分布式 MVCC 的一致性读、以及为高性能应用提供的 “柔性事务” 。在默认配置下,DRDS 将提供标准的事务 ACID 保证,以及高于业界水准的性能;而应用只需要付出较少的代价,就可以适配 DRDS 的特性,获得更高的水平扩展能力和性能保证。

相关实践学习
Polardb-x 弹性伸缩实验
本实验主要介绍如何对PolarDB-X进行手动收缩扩容,了解PolarDB-X 中各个节点的含义,以及如何对不同配置的PolarDB-x 进行压测。
目录
相关文章
|
2月前
|
SQL 存储 关系型数据库
PolarDB-X Operator 基于两次心跳事务的指定时间点恢复方案介绍
数据库恢复方式有备份集恢复和任意时间点恢复(PITR, point-in-time recovery)。备份集恢复顾名思义是直接使用保存的数据备份集进行恢复,只能恢复到固定某一时刻的数据库状态;任意时间点恢复,利用数据库的数据备份和日志备份,先利用数据备份将数据恢复到某一个时刻的数据库状态,数据备份集中会有一个日志位点,下载从该日志位点到指定时间时候那个日志位点之间的日志进行回放,便能恢复到指定时刻的数据库状态。
|
9月前
|
SQL 前端开发 关系型数据库
开源分布式数据库PolarDB-X源码解读——PolarDB-X源码解读(十一):事务的一生
开源分布式数据库PolarDB-X源码解读——PolarDB-X源码解读(十一):事务的一生
197 0
|
SQL 前端开发 关系型数据库
PolarDB-X 源码解读:事务的一生
本文将主要解读 PolarDB-X 中事务部分的相关代码,着重解读事务的一生在计算节点(CN)中的关键代码:从开始、执行、到最后提交这一整个生命周期。
868 2
|
关系型数据库 数据库 RDS
PolarDB-X 1.0-常见问题-事务问题-在PolarDB-X上执行事务操作的时候提示不支持跨库事务,该如何解决?
在PolarDB-X上,可以将事务简单分类为如下两种: 单机事务:所有的事务操作都落在同一个RDS数据库。
248 0
|
SQL 关系型数据库 分布式数据库
分布式关系型数据库服务 DRDS 支持并行DDL、SHOW STATUS 支持事务统计等多项能力发布
信息摘要: 分布式关系型数据库服务 DRDS 支持并行DDL、SHOW STATUS 支持事务统计等多项能力发布适用客户: 数据库使用者 / 分布式数据库使用者 / 开发者 / 互联网企业 / 金融保险行业 / 新零售行业 版本/规格功能: 新功能 1、支持并行DDL 2、重构的系统变量支持,如:SELECT @session.
1960 0
|
SQL 关系型数据库 分布式数据库
分布式关系型数据库服务 DRDS 支持跨 Schema 联机查询及 DML 事务写入等多项能力发布
信息摘要: 分布式关系型数据库服务 DRDS 支持跨 Schema 联机查询及 DML 事务写入等多项能力发布适用客户: 数据库使用者 / 分布式数据库使用者 / 开发者 / 互联网企业 / 金融保险行业 / 新零售行业版本/规格功能: 一、新功能 1.
1379 0
|
关系型数据库 分布式数据库
GTS全局事务测试-单DRDS跨库事务
全局事务服务GTS是一款高性能、高可靠、接入简单的分布式事务中间件,用于解决分布式环境下的数据一致性问题。DRDS特定SQL使用方式; 不同数据库全局事务一致性测试是使用注解的方式。
6021 0
|
5月前
|
SQL Oracle 关系型数据库
Polar DB-O (兼容 Oracle 语法版本)和Polar DB PostgreSQL 版本概述(二)
Polar DB-O (兼容 Oracle 语法版本)和Polar DB PostgreSQL 版本概述(二)
560 0
|
存储 Cloud Native 关系型数据库
PolarDB-X迎来开源后首个重大版本升级,2.1版本新增5大特色功能
2022 年 5 月25日,阿里云开源 PolarDB-X 升级发布新版本!PolarDB-X 从 2009 年开始服务于阿里巴巴电商核心系统, 2015 年开始对外提供商业化服务,并于 2021 年10月正式开源。本次发布是开源后首个重大版本升级,重磅推出在稳定性、生态融合以及易用性上有了长足进步的 2.1 版本,该版本在内核能力上首次对齐商业版,新增 X-Paxos、自动分区、OSS 冷热数据分离等诸多重要特性,并在 MySQL 生态融合、K8S 生态融合方向持续迭代。
PolarDB-X迎来开源后首个重大版本升级,2.1版本新增5大特色功能
|
存储 SQL Kubernetes
PolarDB-X 发布 2.1.0 版本,Paxos 重磅开源
2022年4月1号,PolarDB-X 正式开源X-Paxos,基于原生MySQL存储节点,提供Paxos三副本共识协议,可以做到金融级数据库的高可用和容灾能力,做到RPO=0的生产级别可用性,可以满足同城三机房、两地三中心等容灾架构。
PolarDB-X 发布 2.1.0 版本,Paxos 重磅开源