共计 11806 个字符，预计需要花费 30 分钟才能阅读完成。
文|李乔（花名：南桥)、李宗杰（花名：白鹰)
李乔：蚂蚁团体高级开发工程师，负责蚂蚁境外银行领取结算零碎开发
李宗杰：蚂蚁团体技术专家，负责蚂蚁分布式事务中间件研发
本文 11580 字 浏览 25 分钟
PART. 1– 背景
蚂蚁国内境外银行业务正在局部迁徙至阿里云，原外部应用的 SOFA 技术栈无奈在阿里云上失去反对。为了满足银行业务疾速倒退、简化银行零碎技术栈的指标，咱们采纳了 Spring+Dubbo 等一套开源的技术计划从新构建起了新的技术栈。蚂蚁团体作为金融机构，外部利用采纳了微服务架构，数据间的一致性极其重要，但蚂蚁外部原有的分布式事务框架，在阿里云上也无奈提供技术支持。
Seata 是分布式事务解决方案，囊括了阿里团体的 TXC （阿里云版本称为 GTS） 和蚂蚁团体的 TCC/SAGA 等多种模式，是一款通过多年双十一大规模流量验证的金融级分布式事务框架。因而在综合比拟各个现有的分布式事务框架之后，咱们抉择了 Seata。
本文介绍了蚂蚁团体境外银行技术部在国内站点建设过程中，应用开源的 Seata 1.4.2 版本进行分布式事务管理的具体计划。同时本文也介绍如何在客户端实现对事务悬挂、幂等、空提交以及空回滚等情景的解决办法。
PART. 2– 调研
Seata 通过四年建设后，曾经造成了一个十分宏大的技术体系。但不论其如何演进，Seata 整体放弃了架构的稳定性与应用接口的向后兼容性。
2.1–Seata 架构
Seata 官网给出了其如下架构图：
总体由如下角色形成：
●TC: Transaction Coordinator
事务协调器：保护全局事务和分支事务的状态，驱动全局事务提交或者回滚。
●TM: Transaction Manager
事务管理器：定义全局事务的范畴，提交或者回滚全局事务。
●RM：Resource Manager
资源管理器：和分支事务在同一个利用，进行分支事务的注册，报告分支事务的状态，驱动分支事务的提交或者回滚。
TC 与 TM 以及各个 RM 之间应用 netty 框架进行长链接通信，通信协议是在四层 TCP 协定之上自定义的一套二进制双向通信协定，所以 Seata 总体的通信效率十分高。
2.2– 事务模式
在这套架构之上，Seata 提供了 TCC、AT、SAGA 和 XA 四种事务模式：
TCC 模式
参与者须要实现 Prepare/Commit/Rollback 接口，在一阶段实现数据资源的预处理，在二阶段实现提交和回滚逻辑实现两阶段的提交。长处是通过业务逻辑实现数据可见性和隔离性，疾速开释本地事务，进步对同一个资源的并发度，毛病是引入了两头数据的预处理过程，减少了业务复杂度。因而 TCC 模式具备很好的性能与隔离性，尤其适宜在银行金融场景下同一个账户的并发交易解决。
AT 模式
在一阶段时通过解析 SQL，生成二阶段回滚日志：二阶段提交时，删除回滚日志；二阶段回滚时，通过回滚日志来复原记录到一阶段之前的状态。相似于 TCC 的两阶段，不过二阶段的 Commit/Rollback 由框架主动生成，主动实现了二阶段操作，易用性好于 TCC。但 AT 模式通过全局锁来实现数据的隔离性，因而对于同一个资源的事务处理只能串行操作，所以性能逊于 TCC。当然如果不存在并发应用同一个资源的场景，则 AT 模式能够很好的兼顾性能和隔离性，以及更好的开发效率。
SAGA 模式
是一种长事务解决方案，其一阶段正向服务和二阶段弥补服务都由业务开发实现，它在微服务编排畛域有大量利用。但其数据隔离性不好，业务数据有被脏写的危险。
XA 模式
其应用接口与 AT 模式统一，提供了最严格的隔离性，能够保障了用户不会呈现脏读。XA 模式的毛病是其事务范畴较长，其性能较低。
2.3– 小结
Seata 四种模式都是二阶段事务的技术实现。联合 Seata 本身的技术架构，其事务模型总体有如下特点：
PART. 3– 实际
进行总体技术调研后，咱们认为 Seata 的总体技术栈能够满足咱们所有金融业务场景的需要。在施行过程中，在不同的业务场景下依据不同的技术需要进行了取舍，咱们在发起者本地的交易流水局部应用了 AT 模式，在上游账户相干的服务中应用了 TCC 模式。本章接下来咱们将以业务中最经典的账务余额模型为例详述本次实际，包含为了适配相应的事务模型所做的工作。
3.1– 交易流水应用 AT 模式
为了记录每次的交易流水状态，在发动每笔交易前，咱们都要将本次交易流水做记录，交易状态流水简化模型如下：
在接管到申请时，首先记录初始化状态的交易流水，而后发动分布式事务。本次交易的分布式事务执行胜利后，预期该笔交易流水须要是执行胜利状态。为了对失败的交易发动重试，咱们启动了一个定时工作，定时扫描交易流水状态，扫描到肯定工夫后未实现的记录须要从新发动重试。
从下面的场景能够看出，在发起者的交易流水记录的状态变更中，也须要参加到整个分布式事务中。分布式事务胜利，则流水状态须要更新为胜利，如果分布式事务失败，则须要更新为失败。同时交易流水记录之间是独立的，不存在并发操作的可能，只有异步工作的扫描才会和交易中的事务做抢锁解决。
针对这个场景，就非常适合应用 AT 模式，无需通过业务代码记录事务执行状态，而是间接在发起者中通过 AT 模式提供的代理数据源执行批改流水状态为“执行胜利”状态，由框架主动实现 AT 模式下的一二阶段的提交和回滚，保障交易流水状态和整体分布式事务的状态统一，同时能够放弃简洁的代码和更高的开发效率。
3.2– 账户应用 TCC 模式
从业务原理上来剖析，账户的余额是不能凭空减少或者缩小的，每个余额变动必须有明细对应。所以账户余额模型应该具备以下几个要害因素：账户 （明确到底是谁的账户）、 余额 （承载的客户资产具体数值）、 账务明细 （记录账户余额变动的数值、工夫和起因）。这三个其实形成了最奢侈的账户余额模型。
依据从业务原理的剖析，咱们就产生了一个最简略的账户余额根底数据模型：
账户（ip_account）
账户模型确定了根本的账户信息：
●账号：该账号与会员的信息映射在一起，作为会员的余额资产；
●账户类型：对公 （商户账号），对私 （集体账号），平台户、营销户、商户待结算账户等类型；
●余额：记录以后客户资产具体数据的余额；
●交易状态：管制四种交易方式：流入、流出、充值、提现，这是在账务层做的一个资金平安兜底保障。每一种类型用 T/F 来示意是否能够进行此类交易，T 是能够，F 是不能够；
●核算主体：用于示意以后账号在那个核算主体上面进行核算。
账户明细（ip_account_log,ip_trans_log）
ip_trans_log 是指账户的交易明细，用于解释为什么这个账户是要产生这笔记账申请。能够了解为业务原始凭证，用于和业务零碎数据关联校验。以你用支付宝在便利店买了一瓶矿泉水为例，就是记录的这花 2 元买水的原始信息。
ip_account_log 是指账务明细，用于解释这个账户到底扣减了多少钱，记账的对方账户是谁。依然以你用支付宝在便利店买了一瓶 2 块钱的水为例。这里就记录两条记账明细，一条是从你的支付宝账号扣除 2 元，一条是便利店的商户待结算账号上减少 2 元。
蚂蚁国内境外银行的这类对账户操作的业务具备较高的金融属性，对系统的高可用、高性能方面均提出肯定的要求，同时要对账户、交易数据之间做一致性解决，而且对并发申请的隔离性要求极高。
因而，在这四种模式下咱们首先排除掉了隔离性较差的 SAGA 模式，这种账务操作的业务场景下，应用 AT 模式会对整个账户进行加锁，XA 模式同样因为长事务起因会有性能问题。而应用 TCC 模式只需解冻变动的金额就行，所以 TCC 模式因其性能、隔离性方面的突出长处被咱们选用，上面介绍一下咱们在应用 Seata 做分布式事务实际中的业务模型转换。
在 TCC 模式中蕴含着两个角色：事务协调者和事务参与者。它们之间的交互流程如下：
3.2.1– 第一阶段解析
第一阶段又称为筹备 (Prepare) 阶段，其具体流程如下：
1. 首先事务协调者（发起者）所在的节点会向所有的参与者节点发送 Prepare 申请;
2. 每个参与者节点收到 Prepare 申请后各自执行与本地事务无关的数据更新，包含主事务 ID 和分支事物 ID 的落库，及交易快照信息记录等；
3. 如果参与者本地事务执行胜利，向事务协调节点返回“胜利”音讯，否则返回“失败”音讯；
4. 事务协调者接到了所有参与者的返回音讯后，整个分布式事务进入第二阶段。
实质上来说，TCC Prepare 阶段是要预留资源。而咱们的账户模型的降级也正是为了反对一阶段的余额预留。
3.2.2– 第二阶段解析
分布式事务的第二阶段又称为执行 （Execute） 阶段，其具体流程如下：
1. 如果所有事务参与者都向事务协调节点返回“胜利”音讯，则它会向所有的参与者节点发送 Commit 申请，否则发送 Rollback 申请；
2. 每个参与者接到 Commit/Rollback 申请之后，各自执行本地的事务提交，并开释锁资源，向事务协调者返回“执行实现”音讯；
3. 事务协调者接管到所有事务参与者的“执行实现”反馈，批改事务状态，完结流程。
在咱们的模型中，二阶段实际上是对一阶段中曾经预留资源的一个确认和勾销操作。比方转账过程中，在一阶段先确认是否余额足够，如果余额足够，则对须要转账的金额进行解冻的预留操作，在二阶段时提交时，即实现转账时，须要对一阶段解冻的金额做实在的删除确认操作。
3.2.3– 适配 TCC 的余额模型
通过下面的分布式事务解说，针对分布式事物的执行过程，在技术层面咱们对账户余额模型会产生另一角度的意识，在整个分布式事物波及的金额进行“锁定并标识”能够临时统称为“事务金额”。
在业务实质上来讲，对于一个账户只存在“支出”和“收入”两种动作，为了达到一阶段和二阶段之间一个两头数据预留和确认的目标，咱们将在事务过程中账户收入记账金额称之为零碎金额，将事务中账户支出金额称之为事务未达金额。
模型如下：
零碎金额：
在事务外也是可见的，并且在账户模型 ip_account 有体现。这样设计也是合乎业务逻辑的，如果一个账号同时有多笔交易，存在多个事务过程中，每个事务理当感知以后被占用的零碎金额 –“事务中收入金额”，不然有透支危险；
事务未达金额：
只在同一事务中可见，因为事务未达金额在整个事务未实现前，都不确定是否可能胜利实现整个事务，如果在事务外可见，有可能会被其余事务应用，一旦产生回滚，就会造成资损，产生资金危险。
3.2.4– 可用余额计算
依据下面的模型和剖析能够得悉：
可用余额 = 账户余额 - 解冻金额 - 零碎金额 + 本事务未达余额
3.2.5– 零碎金额计算
示例表格如下 （红圈的数字为旁注）：
解释阐明 （对照表格中的红圈旁注）：
1. 零碎金额记录将付未付的额度，能够看成是一种非凡的解冻。
2. 未达金额是一个事务中将收未收的额度，只能在同一个事务中被应用。
3. 事务中可用余额和事务外可用余额是指主事务号是否雷同的交易，本表格举的例子是在同一个事务中的屡次交易。
4. 付款预处理账户余额并不缩小，而是减少零碎金额。
5. 减少零碎金额，依据可用余额计算公式，就相当于可用余额缩小。
6. 收款预处理账户余额并不减少，而是减少未达金额。
7. 未达金额只有在同一个事务中能够应用，事务外不可见。
8. 同一个事务中优先应用 （缩小） 未达金额。
9. 未达金额不够领取时，应用 （减少） 零碎金额。
10. 提交时依据计算公式更新账户余额。
综上，在一个 Seata 分布式事务中，能够既存在 TCC 模式的参与者，也存在 AT 模式的参与者，TM 不会感知到参与者应用了何种模式。所以咱们依据不同场景别离应用了 TCC 和 AT 模式，在发起者处应用 AT 模式管制交易流水记录的一致性，在账务参与者中应用 TCC 模式，在保障隔离性的同时又能获取较高的性能。
上面是咱们的整体构造阐明：
3.3– 交易流程实例详解
咱们先假如一个业务场景：这次你来到超市买了 100 元的水果，结账的时候关上支付宝付款，支付宝余额只有 20 元了，剩下的 80 元须要从银行卡扣除，假如这次的领取流程是先领取 20 元，而后从银行卡充值 80 元到支付宝，最初再领取 80 元。
3.3.1– 发起者一阶段过程 （AT）
交易事务启动前，资产替换作为发起者，首先插入交易流水记录表，记录初始状态为未执行，而后启动分布式事务，在发起者本地一阶段通过 AT 模式执行状态流水的串行更新操作。
交易流水记录表自身不存在并发读写问题，因而由 AT 模式在一阶段就更新状态为转账胜利，如果转账失败，该状态会被回滚到未执行状态；如果转账胜利，分布式事务二阶段提交会开释该锁。事务执行期间，定时轮询工作会定时检测该记录，所以为了进步隔离性，对流水的读取操作应用 select for update，设置 AT 模式隔离界别为串行化隔离级别，这样定时工作因为拿不到读锁会始终重试轮询，直到事务超时开释锁后，读取到状态为未执行后，再次发动重试。
3.3.2– 参与者一阶段过程及账务余额模型变动 （TCC）
接下来先阐明账务一阶段的解决流程，如下图：
分布式事务记账金额的解决：
阐明一下：
第二行：付款 20，将资源预留，解冻余额中的 20，零碎金额 20(0+20)，事务中可用余额为 0，事务外可用余额 0(20-0-20+0)。
第三行：充值 80，预处理时未达金额减少，等于 80(0+80)，事务中可用余额 80(20-0-20+80)，事务外可用余额 0(20-0-20+0)，未达金额在事务外不可见，等于 0。
第四行：付款 80，资源预留先冻住，优先应用未达金额，所以零碎金额 20(20+80-80)，未达金额 0(80-80)，事务中事务外可用余额 0(20-0-20+0)。
3.3.3– 发起者二阶段过程 （AT）
发起者二阶段是通过 AT 框架主动提交完的，不须要业务关怀，二阶段提交后，交易流水记录会开释行锁。
3.3.4– 参与者二阶段过程及账务余额模型变动 （TCC）
参与者账务局部二阶段解决流程如下图：
依据以上流程，在联合一阶段记账的过程，咱们失去以下的余额变动过程：
阐明一下：
第五行 提交事务时，利用捞取所有事务中金额。因为未达金额优先被扣减，因而充值和第二次付款正好相抵，利用捞取到一条金额为零的未达金额，一条金额为 20 的零碎金额明细，并将零碎金额还原 20 为 0。接着利用遍历分支事务，对账户实现余额 20-20+80-80=0 的计算后长久化到账户模型中，并落地记账明细。
3.4–AT+TCC 编程实际
Seata 的客户端辨别为事务发起者与事务参与者。发起者开启 Seata 的 AT 模式时，须要通过配置，开启数据源的主动代理，也能够在代码中手动指定代理源。参与者的 Prepare/Commit/Rollback 该当在本地事务中进行，其 Commit/Rollback 接口只需关注以后利用的提交或者回滚即可，无需调用上层参与者的 Commit 或 Rollback 接口。
3.4.1– 发起者接入 AT 模式
AT 模式是面向数据库由框架主动托管的两阶段协定模式，在发起者中要应用 AT 模式，只须要将利用的数据源通过框架做代理即可。
须要留神的是，在 AT 模式下，一个表只能有一个字段做主键，不能够应用复合主键。
3.4.2– 参与者接入 TCC 模式
接入 TCC 模式，须要业务上将原先的一个阶段设计为两阶段。因而须要提供三个接口，别离是一阶段的 Prepare，和二阶段的 Commit 和 Rollback 接口，同时须要将一阶段接口上打上 Seata 的 TCC 两阶段注解 @TwoPhaseBusinessAction，如下：
在应用 Seata 时，有如下注意事项：
1. 如果参与者超时或 TM 始终没提交事务，能够在发起者端设置事务超时时长，默认 60 s，如果超过设置时长后，TM 还没发动提交，则 TC 会主动发动事务回滚；
2. 无论是 TCC 还是 AT，都是弥补型事务，在提交本地事务时，分布式事务并没有实现，不能保障用户全局视角的数据一致性，须要避免脏读脏写的场景。为进步发起者一阶段的隔离性，select 语句都须要加上 for update，进行加锁串行解决：
a. 脏写场景须要加上 @GlobalTransaction；
b. 脏读场景须要加上 @GlobalLock + @Transactional 或者 @GlobalTransaction；
3. TwoPhaseBusinessAction 注解中的 name 作为 RM 的 resourceId，而 resourceId 和 applicationName 惟一确定一个 RM，因而在同一个利用中不能存在雷同的 name。如果一个零碎实现了屡次有雷同 name 的 SPI，Seata 将无奈辨别开这两个接口。
PART. 4– 异样
分布式系统中，网络中会常常产生丢包、申请超时、申请重试、程序假死或解体以及运行环境解体等异常情况，Seata 当然也会面临这些问题。
第一阶段，如果某个事务参与者反馈失败音讯，阐明该节点的本地事务执行不胜利，必须回滚。第二阶段，事务协调节点向所有的事务参与者发送回滚申请，接管到回滚申请之后，各个事务参与者节点须要在本地进行事务的回滚操作。其余的还会因为网络超时抖动引起的异样失败，重试申请等场景，这些异样也是须要在分布式事务开发过程中必须要解决的。
4.1– 四种异样
就分布式事务场景而言，有以下常见问题：
1. 幂等解决
2. 空回滚
3. 空提交
4. 资源悬挂
这些异常情况须要框架和运维独特兜底，保障服务质量。
4.2– 解决办法
2021 年咱们应用 Seata v1.4.2 版本时，其没有提供防悬挂能力。对四种异样别离采取了如下应答措施：
幂等管制：
在事务一阶段采纳了 xid+branchId 作为惟一键进行幂等管制，如发现幂等抵触，则间接抛出异样将事务回滚。如需重试，则由业务零碎被动发动。
容许空回滚：
一阶段申请因为网络起因没有收到，或者先收到了二阶段的 Rollback 申请。空回滚属于失常状况，零碎须要可能失常接管解决空回滚申请。
回绝空提交：
零碎只有胜利解决了一阶段申请，才会收到二阶段的 Commit 申请。如果在没有收到一阶段申请的状况下，收到了二阶段申请，那么零碎必定呈现了异样，该当间接回绝掉。
防悬挂：
在网络抖动等状况下，零碎在收到二阶段 Rollback 申请后，又收到了一阶段申请而且进行了解决，那么零碎将永远无奈收到二阶段 Commit 或者 Rollback，事务将无奈达到终态，也就是处于悬挂状态。零碎须要在解决空提交时，记录下该回滚记录，在之后收到一阶段申请时，间接回绝。
CREATE TABLE IF NOT EXISTS `tcc_fence_log`
(`xid` VARCHAR(128) NOT NULL COMMENT 'global id',
`branch_id` BIGINT NOT NULL COMMENT 'branch id',
`action_name` VARCHAR(64) NOT NULL COMMENT 'action name',
`status` TINYINT NOT NULL COMMENT 'status(tried:1;committed:2;rollbacked:3;suspended:4)',
`gmt_create` DATETIME(3) NOT NULL COMMENT 'create time',
`gmt_modified` DATETIME(3) NOT NULL COMMENT 'update time',
PRIMARY KEY (`xid`, `branch_id`),
KEY `idx_gmt_modified` (`gmt_modified`),
KEY `idx_status` (`status`)
) ENGINE = InnoDB
DEFAULT CHARSET = utf8mb4;解决这几类异样解决次要是依赖每个参与者本地的 防悬挂记录表，外围逻辑是在一阶段向该表中插入一条事务记录。
在二阶段查看记录是否存在，如果存在阐明一阶段曾经失常执行过，如果不存在阐明是空回滚，此时须要立刻插入一条记录示意产生过空回滚，这样如果再次接管到一阶段时会因为主键抵触报错拒绝执行，从而能够避免二阶段回滚先于一阶段先执行导致的悬挂问题。这个办法也被成为双插计划。
4.3– 最新计划
在 2022 年 6 月份公布的 Seata v1.5.1 版本（https://github.com/seata/seata/releases/tag/v1.5.1）中，针对下面 4 个异样问题都曾经提供了解决方案，而且应用十分不便，只须要在注解 @TwoPhaseBusinessAction 中设置属性 useTCCFence=true 即可。
PART. 5– 压测
为了在线上提供稳固牢靠的服务，咱们通过压测对 Seata 的承载能力进行摸底。
压测办法借鉴了 Seata 官网计划
(https://github.com/seata/seata/pull/2611)。在相似的压测环境下，咱们把服务替换为本人的业务场景，并进行了如下改变：
●有 2 个发起者，3 个上游参与者
●申请 TPS 设定为失常业务顶峰的 4 倍：50*4 = 200 tps
●按 100 并发步长开始阶梯压测，每个阶梯压测 4 次
后果如下：
注：申请耗时工夫为残缺的 2B 业务申请耗时，失常整体链路耗时 400 ms 左右；
整个压测的过程中，内存和磁盘毫无压力，压测到 500 并发时，CPU 压力开始回升，呈现超时景象。根据上述压测后果，咱们制订了线上服务保障计划：当服务端接管到的申请超过 400 或者有服务 RT 耗时超过 400 ms 时，主动对服务进行扩容。
PART. 6– 监控
分布式系统的可观测性伎俩无外乎 Logging、Metrics 和 Tracing，Seata 本身反对接入 Prometheus 收集其 Metrics，接入 Skywalking 收集其 Tracing。因为咱们的零碎是在阿里云部署的，所以咱们基于阿里云的 APM 技术体系打造了 Seata 的整体监控告警体系。
●Logging 切分日志后接入阿里云 SLS
●Metrics 阿里云 Prometheus
●Monitor 阿里云 ARMS 以及 SLS 仪表盘
●Alert SLS 关键字告警、SLS 仪表盘告警以及 Prometheus Metrics 告警
至于 Tracing 能力，咱们对 Seata 相干能力进行了加强，通过在客户端和服务端进行 TraceId 买通，买通整个 Tracing 链路。
整体监控零碎架构如下：
同时咱们本人打造了一个事务管理端，通过监控如下内容，对超过阈值的异样进行告警：
●在线节点宕机数
●注册到 TC 的 TM/RM 异样事务状态
●超时申请个数
●一段时间内谬误日志的数
select count(*) as error_log_num where level = 'ERROR'●断开或者重建的事务连贯
-- 过来 X 时间段内重建连贯数量
select count(*) where context like '% to server channel inactive.'
-- 过来 X 时间段内断开连接数量
select count(*) where context like 'remove unused channel:%' ●超时心跳
SELECT cost_time,method,logtime WHERE method = 'heartBeat' and cost_time >= 60●一段时间内的谬误数量
select count(*) as error_log_num where level = 'ERROR'●二阶段异样挂起时的事务、分支事务
-- 获取二阶段 Commit 时挂起的事务以及分支
select regexp_extract(context, '(?<=[)(\S+)(?=])') as xid, regexp_extract(context, '(?<=[)(\d+)(?=])') as branch_id where context like 'Committing global transaction[%'
-- 获取二阶段 Commit 时挂起事务的 xid，并且去重
select DISTINCT regexp_extract(context, '(?<=[)(\S+)(?=])') as xid where context like 'Committing global transaction[%'
-- 获取二阶段 Commit 时挂起的事务分支 branch_id，并去重
select DISTINCT regexp_extract(context, '(?<=[)(\d+)(?=])') as branch_id where context like 'Committing global transaction[%'
-- 获取二阶段 Commit 时挂起的事务分支 xid、branch_id
select DISTINCT regexp_extract(context, '(?<=[)(\S+)(?=])') as xid, regexp_extract(context, '(?<=[)(\d+)(?=])') as branch_id where context like 'Committing global transaction[%'
-- 获取二阶段 Commit 时挂起的事务分支条目数量
select count(DISTINCT regexp_extract(context, '(?<=[)(\S+)(?=])') ) as commit_error_times where context like 'Committing global transaction[%'●二阶段 Rollback 时的事务、分支事务
-- 获取二阶段 Rollback 时挂起的事务分支日志的条目数量
select count(*) where context like 'Rollback branch transaction fail and will retry, xid =%'
-- 获取二阶段 Rollback 时挂起的事务分支日志
select * where context like 'Rollback branch transaction fail and will retry, xid =%'
-- 获取二阶段 Rollback 时挂起的事务的 xid 和 branch_id
select regexp_extract(context, '(?<=xid\ =\)(\S+)(?=\)') as xid, regexp_extract(context, '(?<=branchId\ =\)(\S+)(?=)') as branch_id where context like 'Rollback branch transaction fail and will retry, xid =%'
-- 获取二阶段 Rollback 时挂起的事务的 xid 和 branch_id，并去重
select DISTINCT regexp_extract(context, '(?<=xid\ =\)(\S+)(?=\)') as xid, regexp_extract(context, '(?<=branchId\ =\)(\S+)(?=)') as branch_id where context like 'Rollback branch transaction fail and will retry, xid =%'
-- 获取二阶段 Rollback 时挂起的事务的数量
select count(DISTINCT regexp_extract(context, '(?<=xid\ =\)(\S+)(?=\)') ) where context like 'Rollback branch transaction fail and will retry, xid =%'注：
1. 监控对象是 Seata v1.4.2 的日志，不同 Seata 版本或有异同；
2. 收集日志的 SQL 是 SLS SQL。
PART. 7– 瞻望
本文具体介绍了蚂蚁团体国内站点接入 Seata v1.4.2 过程的一些要害的技术步骤与应用细节，并对其中存在的一些问题给出了一套综合解决方案。近期 Seata 曾经公布了 v1.5.2，蕴含了控制台等让咱们十分 excited 的新 feature，咱们打算在下半年及时降级到新版本并进行相干的稳定性建设，充分利用开源版本的最新技术红利。
作为开源技术的动摇拥护者，蚂蚁团体既是 Seata 的大规模使用者，也是 Seata 开源的共建方，先后为 Seata 提交了 TCC 和 SAGA 模式实现。在踊跃推动 Seata 2.0 的建设过程中，咱们将陆续奉献 SAGA 注解化模式、二阶段执行异步化、二阶段并行提交以及基于 RocketMQ 的分布式音讯事务等技术。
开源技术，普惠公众。咱们将放弃开源和外部工作联动，共用一个 Seata 开源内核，放弃我的项目和社区的衰弱可继续倒退。
理解更多…
Seata Star 一下✨：
https://seata.io/zh-cn/
本周举荐浏览
Seata 多语言体系建设
KusionStack|Kusion 模型库和工具链的摸索实际
Go 原生插件应用问题全解析
SOFARegistry 源码|数据同步模块解析
欢送扫码关注：