文｜李乔（花名：南桥)、李宗杰（花名：白鹰)
李乔：蚂蚁集团高级开发工程师，担任蚂蚁境外银行付出结算系统开发
李宗杰：蚂蚁集团技能专家，担任蚂蚁分布式业务中心件研制
本文 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）
参加者账务部分二阶段处理流程如下图：
依据以上流程，在结合一阶段记账的进程，咱们得到以下的余额改变进程：
阐明一下：
第五行提交业务时，运用抓取一切业务中金额。因为未达金额优先被扣减，因而充值和第2次付款正好相抵，运用抓取到一条金额为零的未达金额，一条金额为 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 版别（github.com/seata/seata…）中，针对上面 4 个反常问题都现已供给了处理计划，而且运用十分方便，只需求在注解@TwoPhaseBusinessAction中设置属性useTCCFence=true即可。
PART. 5–压测
为了在线上供给安稳牢靠的服务，咱们经过压测对 Seata 的承载才能进行了解。
压测办法学习了 Seata 官方计划
(github.com/seata/seata…)。在类似的压测环境下，咱们把服务替换为自己的业务场景，并进行了如下改动：
●有 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时挂起的业务以及分支
selectregexp_extract(context,'(?<=[)(\S+)(?=])')asxid,regexp_extract(context,'(?<=[)(\d+)(?=])')asbranch_idwherecontextlike'Committingglobaltransaction[%'
--获取二阶段Commit时挂起业务的xid，而且去重
selectDISTINCTregexp_extract(context,'(?<=[)(\S+)(?=])')asxidwherecontextlike'Committingglobaltransaction[%'
--获取二阶段Commit时挂起的业务分支branch_id，并去重
selectDISTINCTregexp_extract(context,'(?<=[)(\d+)(?=])')asbranch_idwherecontextlike'Committingglobaltransaction[%'
--获取二阶段Commit时挂起的业务分支xid、branch_id
selectDISTINCTregexp_extract(context,'(?<=[)(\S+)(?=])')asxid,regexp_extract(context,'(?<=[)(\d+)(?=])')asbranch_idwherecontextlike'Committingglobaltransaction[%'
--获取二阶段Commit时挂起的业务分支条目数量
selectcount(DISTINCTregexp_extract(context,'(?<=[)(\S+)(?=])'))ascommit_error_timeswherecontextlike'Committingglobaltransaction[%'
●二阶段 Rollback 时的业务、分支业务
--获取二阶段Rollback时挂起的业务分支日志的条目数量
selectcount(*)wherecontextlike'Rollbackbranchtransactionfailandwillretry,xid=%'
--获取二阶段Rollback时挂起的业务分支日志
select*wherecontextlike'Rollbackbranchtransactionfailandwillretry,xid=%'
--获取二阶段Rollback时挂起的业务的xid和branch_id
selectregexp_extract(context,'(?<=xid\=\)(\S+)(?=\)')asxid,regexp_extract(context,'(?<=branchId\=\)(\S+)(?=)')asbranch_idwherecontextlike'Rollbackbranchtransactionfailandwillretry,xid=%'
--获取二阶段Rollback时挂起的业务的xid和branch_id，并去重
selectDISTINCTregexp_extract(context,'(?<=xid\=\)(\S+)(?=\)')asxid,regexp_extract(context,'(?<=branchId\=\)(\S+)(?=)')asbranch_idwherecontextlike'Rollbackbranchtransactionfailandwillretry,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 一下✨： seata.io/zh-cn/
本周引荐阅读
Seata 多语言系统建造
KusionStack｜Kusion 模型库和工具链的探索实践
Go 原生插件运用问题全解析
SOFARegistry 源码｜数据同步模块解析
