本文次要内容为 seata 的实际篇，理论知识不懂的请参考前文：
我还不懂什么是分布式事务
次要介绍两种最罕用的 TCC 和 AT 模式。
环境信息：
mysql：5.7.32
seata-server：1.4.1
SpringCloud：Hoxton.SR10
SpringBoot：2.3.8.RELEASE
注册核心：Eureka
波及服务：
Seata-server
1、在 file.conf 中批改
mode = “db”
而后配置 DB 信息：
## database store property
db {
datasource = "druid"
## mysql/oracle/postgresql/h2/oceanbase etc.
dbType = "mysql"
driverClassName = "com.mysql.jdbc.Driver"
url = "jdbc:mysql://127.0.0.1:3306/seata"
user = "root"
password = "123456"
minConn = 5
maxConn = 100
globalTable = "global_table"
branchTable = "branch_table"
lockTable = "lock_table"
queryLimit = 100
maxWait = 5000
}2、在 register.conf
registry {
# file、nacos、eureka、redis、zk、consul、etcd3、sofa
type = "eureka"
loadBalance = "RandomLoadBalance"
loadBalanceVirtualNodes = 10
eureka {
serviceUrl = "http://eureka-chengdu:8761/eureka,http://eureka-hangzhou:8762/eureka"
application = "seata-server"
weight = "1"
}3、客户端批改
这里所指的客户端蕴含所有的资源管理器，蕴含所有须要 seata-server 治理的服务
在服务启动 yml 中减少：
seata:
enabled: true
# 事务群组（能够每个利用独立取名，也能够应用雷同的名字）tx-service-group: my_tx_group
client:
rm-report-success-enable: true
# 异步提交缓存队列长度（默认 10000）rm-async-commit-buffer-limit: 1000
# 一阶段全局提交后果上报 TC 重试次数（默认 1 次，倡议大于 1）tm-commit-retry-count: 3
# 一阶段全局回滚后果上报 TC 重试次数（默认 1 次，倡议大于 1）tm-rollback-retry-count: 3
support:
# 数据源主动代理开关（默认 false 敞开）spring-datasource-autoproxy: false
service:
vgroup-mapping:
# TC 集群（必须与 seata-server 保持一致）my_tx_group: seata-server
grouplist:
default: seata-server:8091
registry:
type: eureka
eureka:
serviceUrl: http://eureka-chengdu:8761/eureka/,http://eureka-hangzhou:8762/eureka/TCC 模式
TCC 模式实际须要四个服务，除了 seata-server 外，其余服务调用关系如下：
business 服务是全局事务的发起者，须要减少 @GlobalTransactional 注解
@Override
@GlobalTransactional
public String processTcc(Map<String, String> params) {String xid = RootContext.getXID();
System.out.println(("---》》》》xid：" + xid));
uploadFeign.upload(params);
downloadFeign.download(params);
return xid;
}business 服务会通过 feign 近程调用 upload 和 download 服务，这两个服务都要申明 TCC 的三个接口，并通过 TwoPhaseBusinessAction 注解申明。
upload 服务：
@LocalTCC
public interface TccService {@TwoPhaseBusinessAction(name = "upload", commitMethod = "commitTcc", rollbackMethod = "cancel")
String upload(@BusinessActionContextParameter(paramName = "params") Map<String, String> params);
boolean commitTcc(BusinessActionContext context);
boolean cancel(BusinessActionContext context);
}具体实现，这里模仿了 TCC 后果并放到 Result 中，通过 restful 接口能够查看，理论业务须要思考 防悬挂 和空回滚 问题，例子只是简略形容如何应用 TCC 模式：
@Slf4j
@Service
public class TccServiceImpl implements TccService {@Value("${spring.application.name}")
private String appName;
@PostConstruct
private void initAppName() {Result.getResult().setAppName(appName);
}
@Override
public String upload(Map<String, String> params) {String xid = RootContext.getXID();
System.out.println(("---》》》》xid：" + xid));
return "success";
}
@Override
public boolean commitTcc(BusinessActionContext context) {String xbid = context.getXid();
System.out.println(("---》》》》xid：" + xbid + "提交胜利"));
Result.getResult().setActionResult(context.getXid(), +context.getBranchId(), "Commit", context.getActionContext("params"));
return true;
}
@Override
public boolean cancel(BusinessActionContext context) {System.out.println(("---》》》》xid：" + context.getXid() + "回滚胜利"));
Result.getResult().setActionResult(context.getXid(), context.getBranchId(), "Rollback", context.getActionContext("params"));
return true;
}
}
download 服务
download 服务也同样须要申明一个 TCC 接口，实现上在 Try 阶段模仿每三次调用,，提早 30s 失败一次场景
@Override
public String download(Map<String, String> params) {String xid = RootContext.getXID();
System.out.println(("---》》》》xid：" + xid));
if (count.incrementAndGet() % 3 == 0) {
try {TimeUnit.SECONDS.sleep(30);
} catch (InterruptedException e) {log.warn("InterruptedException", e);
}
throw new RuntimeException("服务异样");
}
return "success";
}测试
1、通过 restful 接口调用两次，返回全局事务 ID
2、查看 download 和 upload 服务后果，能够看到后果都是胜利。
upload 后果：
3、通过日志查看
seata-server：
business 服务日志：
第三次调用
第三次模仿的是 download 服务失败场景，所以能看到 download 后果是失败回滚
然而 upload 服务并没有异样，来看下是否可能和 download 保障事务的一致性，后果都是回滚呢？
从后果看到两个服务后果是雷同的，从而也看出保障了事务一致性。
从 seata-server 日志也能看到回滚胜利的信息：
AT 模式
AT 模式实际须要四个服务，除了 seata-server 外，其余服务调用关系如下：
模仿电商场景，下订单、减库存，解决胜利后，第三次调用时延时 30s 抛出异样
业务触发测，也就是全局事务发动服务 business 服务：
@Override
@GlobalTransactional(rollbackFor = Exception.class)
public String processAt(String userId, int orderMoney, String commodityCode, int count) throws InterruptedException {String xid = RootContext.getXID();
System.out.println("---》》》》xid：" + xid);
System.out.println(("-------> 创立订单开始"));
orderFeign.create(userId, commodityCode, count, orderMoney);
System.out.println(("-------> 创立订单完结"));
System.out.println(("-------> 扣减库存开始"));
storageFeign.deduct(commodityCode, count);
System.out.println(("-------> 扣减库存完结"));
if (visitCount.incrementAndGet() % 3 == 0) {TimeUnit.SECONDS.sleep(30);
throw new RuntimeException("process failed");
}
return xid;
}order 服务、storage 服务
除了配置中减少 seata 外，与一般的入库服务是一样的
@Service
public class OrderDao {
@Autowired
private JdbcTemplate jdbcTemplate;
public boolean createOrder(Order order) {String sql = "INSERT INTO product_order (user_id,product_id,count,money,status) VALUES('" + order.getUserId() + "'," + order.getProductId() + "," + order.getCount() + "," + order.getMoney() + ",0);";
return jdbcTemplate.update(sql) > 0;
}
}调用之前：数据：
order 数据库为空，
storage 数据库中库存字段为 100：
调用两次后：
数据库后果：
第三次调用是模仿延时 30s 后失败场景，也就是书库更新后，解决数据失败，应该从数据库看到数据回滚过程，提早 30s 也是为了更好的察看后果，也能够用 debug 形式察看后果
也能够看到
rollback_info 中：
30s 后从新查问书库能够看到 storage 库存变回 98，order 记录缩小为 2 条，同时 undo_log 和 seata 相干表中数据被清空。
从 seata-server 日志也能看到回滚信息。
华为
同时看下华为的分布式事务解决方案，相比于 seata 直观的就是多了交互命令行，从下面例子也能够看出 seata 目前还只能通过数据库查看后果
其余和 seata 相似提供了 TCC 和非侵入两种计划
seata-golang
参考容器时代：seata-golang 接入指南
总结
例子中波及的代码已上传到 github
https://github.com/stevenniu9…
如果有工夫还是倡议本人敲一遍代码，看他人的货色都会感觉很简略，一看就会
然而当本人实操时就会发现各种奇奇怪怪的异样，一用就废。
纸上得来终觉浅，绝知此事要躬行，
比方例子中子 pom 依赖为什么不须要配置版本、eureka 两个怎么互为正本的、seata 相干表中具体数据是什么、debug 和提早 30s 是否会对 seata 有影响
这些问题本人敲一遍会有更深的了解，更何况代码量是如此的少。
最初感觉写的还行，求关注，求点赞，求转发