在分布式系统中,各个节点(或者事务参与方)之间在物理上相互独立,各节点之间无法确切地知道其它节点中的事务执行情况,所以多节点之间很难保证ACID,尤其是原子性。如果是单节点的事务,由于存在事务机制,可以保证其数据操作的ACID特性。如果要实现分布式系统事务的原子性,必须保证所有节点的数据写操作,要不全部都执行,要么所有节点全部都不执行。但是,一个节点在执行本地事务的时候无法知道其它节点的本地事务的执行结果,所以它就不知道本次事务到底应该commit还是 rollback。这就需要引入一个“协调者”的组件来统一调度所有分布式节点的执行。

两阶段提交原理

二阶段提交的算法思路可以概括为:协调者询问参与者是否准备好了提交,并根据所有参与者的反馈情况决定向所有参与者发送commit或者rollback指令。

所谓的两个阶段是指:

  • 准备阶段 又称投票阶段。在这一阶段,协调者询问所有参与者是否准备好提交,参与者如果已经准备好提交则回复Prepared,否则回复Non-Prepared。
  • 提交阶段 又称执行阶段。协调者如果在上一阶段收到所有参与者回复的Prepared,则在此阶段向所有参与者发送commit指令,所有参与者立即执行commit操作;否则协调者向所有参与者发送rollback指令,参与者立即执行rollback操作。

KingbaseES两阶段提交

  • prepare transaction transaction_id:prepare transaction 为当前事务的两阶段提交做准备。 在命令之后,事务就不再和当前会话关联了,它的状态完全保存在磁盘上, 它提交成功有非常高的可能性,即使是在请求提交之前数据库发生了崩溃也如此。这条命令必须在一个用BEGIN显式开始的事务块里面使用。
  • commit prepared transaction_id:提交已进入准备阶段的ID为transaction_id的事务
  • rollback prepared transaction_id:回滚已进入准备阶段的ID为transaction_id的事务

使用例子

设置数据库参数,确保 max_prepared_transactions 大于 0

test=# alter system set max_prepared_transactions=100;
ALTER SYSTEM

会话A:在prepare 后,全局事务ID 会保存到本地表中,即使数据库异常宕机也能恢复事务。

test=# begin;
BEGIN
test=# create table tt1(id integer);
CREATE TABLE
test=# PREPARE TRANSACTION 'the first prepared transaction';
PREPARE TRANSACTION
test=# \q

会话B:

test=# SELECT * FROM pg_prepared_xacts;
transaction | gid | prepared | owner | database
-------------+--------------------------------+-------------------------------+--------+----------
41207 | the first prepared transaction | 2022-04-27 17:33:12.411756+08 | system | test
(1 row) test=# ROLLBACK PREPARED 'the first prepared transaction';
ROLLBACK PREPARED

test=# SELECT * FROM pg_prepared_xacts;
transaction | gid | prepared | owner | database
-------------+-----+----------+-------+----------
(0 rows)

注意:在运行 prepare transaction时,本地的事务就已经结束,后续的commit or rollback 不必在事务块里执行。

test=# begin;
BEGIN
test=# create table tt1(id integer);
CREATE TABLE
test=# PREPARE TRANSACTION 'the first prepared transaction';
PREPARE TRANSACTION
test=# rollback;
WARNING: there is no transaction in progress
ROLLBACK

两阶段提交注意事项

  • PREPARE TRANSACTION transaction_id 命令后,事务状态完全保存在磁盘上。
  • PREPARE TRANSACTION transaction_id 命令后,事务就不再和当前会话关联,因此当前session可继续执行其它事务。
  • COMMIT PREPARED 和 ROLLBACK PREPARED 可在任何会话中执行,而并不要求在提交 prepare transaction 的会话中执行。
  • 不允许对那些执行了涉及临时表或者是创建了带WITH HOLD游标的事务进行PREPARE。 这些特性和当前会话绑定得实在是太紧密了,因此在一个准备好的事务里没什么可用的。
  • 如果事务用SET修改了运行时参数,这些效果在PREPARE TRANSACTION之后保留,并且不会被任何以后的COMMIT PREPARED或ROLLBACK PREPARED所影响,因为SET的生效范围是当前session。
  • 从性能的角度来看,把一个事务长时间停在准备好的状态是不明智的,因为它会影响VACUUM回收存储的能力。
  • 已准备好的事务会继续持有它们获得的锁,直到该事务被commit或者rollback。所以如果已进入准备阶段的事务一直不被处理,其它事务可能会因为获取不到锁而被block或者失败。

KingbaseES XA 分布式事务的更多相关文章

  1. MySQL binlog 组提交与 XA(分布式事务、两阶段提交)【转】

    概念: XA(分布式事务)规范主要定义了(全局)事务管理器(TM: Transaction Manager)和(局部)资源管理器(RM: Resource Manager)之间的接口.XA为了实现分布 ...

  2. MySQL数据库分布式事务XA优缺点与改进方案

    1 MySQL 外部XA分析 1.1 作用分析 MySQL数据库外部XA可以用在分布式数据库代理层,实现对MySQL数据库的分布式事务支持,例如开源的代理工具:ameoba[4],网易的DDB,淘宝的 ...

  3. 分布式事务、XA、两阶段提交、一阶段提交

    本文原文连接:http://blog.csdn.net/bluishglc/article/details/7612811 ,转载请注明出处! 1.XA XA是由X/Open组织提出的分布式事务的规范 ...

  4. 关于分布式事务,XA协议的学习笔记

    XA分布式事务协议,包含二阶段提交(2PC),三阶段提交(3PC)两种实现. 1.二阶段提交方案:强一致性 事务的发起者称协调者,事务的执行者称参与者. 处理流程: 1.准备阶段 事务协调者,向所有事 ...

  5. DTP模型之一:(XA协议之三)MySQL数据库分布式事务XA优缺点与改进方案

    1 MySQL 外部XA分析 1.1 作用分析 MySQL数据库外部XA可以用在分布式数据库代理层,实现对MySQL数据库的分布式事务支持,例如开源的代理工具:ameoba[4],网易的DDB,淘宝的 ...

  6. 关于分布式事务、两阶段提交、一阶段提交、Best Efforts 1PC模式和事务补偿机制的研究 转载

    1.XA XA是由X/Open组织提出的分布式事务的规范.XA规范主要定义了(全局)事务管理器(Transaction Manager)和(局部)资源管理器(Resource Manager)之间的接 ...

  7. Mycat 分布式事务的实现

    引言:Mycat已经成为了一个强大的开源分布式数据库中间件产品.面对企业应用的海量数据事务处理,是目前最好的开源解决方案.但是如果想让多台机器中的数据保存一致,比较常规的解决方法是引入"协调 ...

  8. 分布式事务之深入理解什么是2PC、3PC及TCC协议?

    导读 在上一篇文章<[分布式事务]基于RocketMQ搭建生产级消息集群?>中给大家介绍了基于RocketMQ如何搭建生产级消息集群.因为本系列文章最终的目的是介绍基于RocketMQ的事 ...

  9. 基于两阶段提交的分布式事务实现(UP-2PC)

    引言:分布式事务是分布式数据库的基础性功能,在2017年上海MySQL嘉年华(IMG)和中国数据库大会(DTCC2018)中作者都对银联UPSQL Proxy的分布式事务做了简要介绍,受限于交流形式难 ...

随机推荐

  1. jenkins部署docker

    1. 先在jenkins上配置拉取代码部分,需要在git上找到项目位置,直接复制url即可 http://192.168.0.161:3000/IT-Insurance/Back.Test-Walle ...

  2. linux web漏洞扫描arachni

    1. 下载arachni https://www.arachni-scanner.com/download/下载Linux x86 64bit 2. 上次解压直接使用 tar xzf arachni- ...

  3. Linux文件查找实现

    文件查找 locate:非实时查找(依赖数据库的方式) find(实时查找) locate:-- 模糊搜索(不适合经常改变的文件) locate 查询系统上预建的文件索引数据库 /var/lib/ml ...

  4. Linux YUM 配置源

    Linux Yum 简介 YUM是交互式的以rpm为基础的软件包管理工具.YUM可以根据仓库的元数据信息,去自动的实现系统更新,包括依赖性分析,过期软件包处理.我们也可以利用yum来进行软件安装,删除 ...

  5. 【.NET+MQTT】.NET6 环境下实现MQTT通信,以及服务端、客户端的双边消息订阅与发布的代码演示

    前言: MQTT广泛应用于工业物联网.智能家居.各类智能制造或各类自动化场景等.MQTT是一个基于客户端-服务器的消息发布/订阅传输协议,在很多受限的环境下,比如说机器与机器通信.机器与物联网通信等. ...

  6. 感知器网络(MP模型)和自适应线性元件

  7. Lambda表达式的无参数无返回值的练习和Lambda表达式有参数有返回值的练习

    使用Lambda(无参无返回) 说明:给定一个厨师(Cook)接口,内含唯一的抽象方法makeFood,且无参数.无返回值.如下: public interface Cook{ public abst ...

  8. 编译kubeadm使生成证书有效期为100年

    目录 问题 编译 检查结果 问题 当我使用kubeadm部署成功k8s集群时在想默认生成的证书有效期是多久,如下所示 /etc/kubernetes/pki/apiserver.crt #1年有效期 ...

  9. 5-9 Leaf 分布式ID

    Leaf 什么Leaf leaf是叶子的意思 我们使用的Leaf是美团公司开源的一个分布式序列号(id)生成系统 我们可以在Github网站上下载项目直接使用 为什么需要Leaf 上面的图片中 是一个 ...

  10. flv.js的追帧、断流重连及实时更新的直播优化方案

    目录 1. 前言 2. 前端直播 2.1 常见直播协议 2.2 flv.js 的原理 2.3 flv.js 的简单使用 3. flv.js 的优化方案 3.1 追帧-解决延迟累积问题 3.2 断流重连 ...