专栏首页我要变牛你才不是只会理论的女同学-seata实践篇

你才不是只会理论的女同学-seata实践篇

本文主要内容为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/stevenniu9527/nerry

如果有时间还是建议自己敲一遍代码,看别人的东西都会觉得很简单,一看就会

但是当自己实操时就会发现各种奇奇怪怪的异常,一用就废

纸上得来终觉浅,绝知此事要躬行,

比如例子中子pom依赖为什么不需要配置版本、eureka两个怎么互为副本的、seata相关表中具体数据是什么、debug和延迟30s是否会对seata有影响

这些问题自己敲一遍会有更深的理解,更何况代码量是如此的少。

本文分享自微信公众号 - 你呀不牛(notNiu),作者:不牛

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-04-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 分布式事务,一次性说清

    的确,分布式事务的落地实践相对比较复杂,和数据库分库分表一样,很多公司采取的策略都是能不碰就不碰,因为在业务规模不庞大时,设计分布式事务要投入的精力,可能比采取...

    架构师之路
  • 分布式架构设计篇(十二)-分布式事务总结篇

    ​ 咱们前面分别对分布式事务的几个分支:XA、2PC、3PC、TCC、Saga、事务消息、最大努力事务进行的详细介绍。本篇作为分布式事务设计的收尾篇...

    林淮川
  • 分布式事务精华总结篇

    咱们前面分别对分布式事务的几个分支:XA、2PC、3PC、TCC、Saga、事务消息、最大努力事务进行的详细介绍。本篇作为分布式事务设计的收尾篇,讲对前面的内容...

    江帅帅
  • 我参与 Seata 开源项目的一些感悟

    我一直都有上 GitHub 搜索一些主流开源项目的习惯,我是从去年 5 月份从 GitHub 开始关注 Seata 项目的,经过入门上手之后,我就觉得它的设计理...

    张乘辉
  • 分布式事务精华总结篇,实打实的干货!

    咱们前面分别对分布式事务的几个分支:XA、2PC、3PC、TCC、Saga、事务消息、最大努力事务进行的详细介绍。本篇作为分布式事务设计的收尾篇,讲对前面的内容...

    孙玄@奈学教育
  • 看了 5 种分布式事务方案,我司最终选择了 Seata,真香!

    好长时间没发文了,最近着实是有点忙,当爹的第 43 天,身心疲惫。这又赶上年底,公司冲 KPI 强制技术部加班到十点,晚上孩子隔两三个小时一醒,基本没睡囫囵觉的...

    程序员内点事
  • 分布式架构设计篇(七)-刚性事务总结和柔性事务概述

    ​ 在《分布式架构之设计篇-刚性事务之2PC详解》和《分布式架构之设计篇-刚性事务之3PC详解》二文中分析了分布式事务的本质、XA、2PC、3PC等...

    林淮川
  • 对比 5 种分布式事务方案,还是宠幸了阿里的 Seata(原理 + 实战)

    好长时间没发文了,最近着实是有点忙,当爹的第 43 天,身心疲惫。这又赶上年底,公司冲 KPI 强制技术部加班到十点,晚上孩子隔两三个小时一醒,基本没睡囫囵觉的...

    程序员内点事
  • ​深入了解分布式事务组件 Seata (一)

    分布式事务的问题,在微服务架构中一直是难题。单体应用实现本地事务即可,到了分布式环境,情况就变得复杂。一个请求可能涉及多个服务,上下游存在依赖关系,其中的一环失...

    aoho求索
  • 从分布式事务解决到Seata使用,一梭子给你整明白了

    大家好,欢迎来到小菜同学的个人 solo 学堂,知识免费,不吝吸收!关注免费,不吝动手!

    蔡不菜丶
  • 对比 5 种分布式事务方案,还是宠幸了阿里的 Seata(原理 + 实战)

    我们先看看百度上对于分布式事务的定义:分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

    Bug开发工程师
  • 我还不懂什么是分布式事务

    事务是应用程序中一系列严密的操作,所有操作必须成功完成,否则在每个操作中所作的所有更改都会被撤消。

    你呀不牛
  • [图文] Seata AT 模式分布式事务源码分析

    AT 模式是 Seata 主推的分布式事务解决方案,最早来源于阿里中间件团队发布的 TXC服务,后来成功上云改名 GTS。相较于TCC而言,Seata的AT模式...

    田守枝
  • 我参与阿里巴巴 ASoC-Seata 的一些感悟

    我先来说说 Seata 这个项目的 idea 是怎么来的。一直就有参与开源项目的打算,一个事物的兴起必定或大或小引发一定的问题,微服务就是这样,分布式事务概念泛...

    用户5397975
  • 1.4 w字,25 张图让你彻底掌握分布式事务原理

    从 CPU 到内存、到磁盘、到操作系统、到网络,计算机系统处处存在不可靠因素。工程师和科学家努力使用各种软硬件方法对抗这种不可靠因素,保证数据和指令被正确地处理...

    kunge
  • Seata 分布式事务 XA 与 AT 全面解析

    Seata 是一款开源的分布式事务解决方案,star 高达 19200+,社区活跃度极高,致力于在微服务架构下提供高性能和简单易用的分布式事务服务。

    张乘辉
  • 逸仙电商Seata企业级落地实践

    就职于逸仙电商交易中心;Seata Committer,加入 Seata 社区已有一年半,见证了从 Fescar 到 Seata 的变更,GA 等。

    用户5397975
  • 如何能在实战中完成分布式事务

    在一年前我写过一篇关于分布式事务的文章: 再有人问你分布式事务,把这篇扔给他,在这篇文章中我详细介绍了分布式事务是什么,实现分布式事务有哪些常用的方案,但是其中...

    用户5397975
  • 什么是 “分布式事务” ?

    对于分布式事务,相信所有人都应该很了解,为什么会有分布式事务?无论是数据量导致的分库,还是现在微服务盛行的场景都是他出现的原因。

    小灰

扫码关注云+社区

领取腾讯云代金券