guoyu07 / sts

Soa Transaction Service

STS——SOA Transaction Service

0、简介:

STS是一款基于事务补偿的分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。STS 从架构上分为 sts-client、 sts-monitor量部分，前者是一个嵌入客户端应用的jar包，主要负责分布式事务控制；后者是一个独立的系统，主要负责异常监控、告警和恢复。

特性:

• 接入成本低：对系统原有代码无侵入，只需新增配置、回滚代码即可，原有业务不需感知分布式事务！
• 最终一致：事务处理过程中，会有短暂不一致的情况，但通过恢复系统，可以让事务的数据达到最终一致的目标。
• 服务幂等：STS支持服务幂等性保障
• 与 RPC 协议无关：在 SOA 架构下，一个或多个 DB 操作往往被包装成一个一个的 Service，Service 与 Service 之间通过 RPC 协议通信。STS 框架构建在 SOA 架构上，与底层协议无关。
• 与本地事务实现无关： STS 是一个抽象的基于 Service 层的概念，与底层本地事务实现无关，无论是关系型数据库 MySQL，Oracle，还是 KV 存储 MemCache，本地事务还是交给数据库。

1、核心概念:

• 发起方： client端，负责启动分布式事务，触发创建相应的主事务记录。是分布式事务的协调者，负责调用参与者的服务，并记录相应的事务日志，感知整个分布式事务状态来决定整个事务是 COMMIT 还是 ROLLBACK。
• 参与者：server端，参与者是分布式事务中的一个原子单位，为client端提供业务接口（API）和rollback接口，并保证其业务数据的幂等性，也是回滚逻辑的执行者。
• Transaction：这里并非本地事务，而是分布式事务，其最核心的数据结构是事务号和事务状态，它是在启动分布式事务的时候，由发起方持久化写入数据库的。
• Operation：分布式事务中的一个原子操作，client调用server的一个接口，就是一个原子操作，原子操作也有id和状态。

**Note：**以下分布式事务简称trans，原子操作简称op。

-	状态枚举值	保存位置
Trans	doing/done	client端
Op	try/success/rollback_success	Server端

2、现有的一些框架(协议)比较:

-	原理简述	事务控制	适用场景	改造成本
2PC	需要单独的事务管理器，一阶段prepare，二阶段commit或rollback	资源层	实际中使用较少	大
TCC	事务补偿，需要实现类似2PC的协议，一个接口需要拆分成三个阶段try/confirm/cancel，且本地事务要感知分布式事务	资源层	金融、电商	大
STS	事务补偿，业务阶段保存回滚信息，异常时自动回滚	服务层	通用	小

3、STS的设计:

3.1 设计目标

目标	方案
最终一致性，通用性强，与业务解耦，与底层RPC框架无关	1、不改变业务流程，服务层进行事务补偿，业务无感知。2、在异常情况下，由发起方，发起进行事务回滚，每个参与者回滚之前的操作，最后发起方回滚本地事务
服务幂等性	通过transId + 事务信息持久化来保障，业务操作可以重复调用，回滚操作可以重复调用
极端情况下，能够保存重要信息，便于事务恢复，并主动报警	事务信息持久化 + 事务状态；整个SOA事务状态——doing/done，每个原子操作状态——try/success/rollback_success
使用方便，开发简单	仅需要实现callback接口并增加注解，对原有代码无侵入

3.2 模块组件

3.3 工作流程

3.4 状态流转

3.5 级联事务

3.6 事务恢复

3、STS接入方法:

---