分布式实战-分布式事务（三）

事务的概念

1、锁的问题   ----- 多对一的问题 ------ 是多个线程同时访问同一个资源，造成资源状态不一致

2、事务的问题 ----- 一对多的问题 ----- 是一个线程进数据库，操作多条sql，其中，某条sql的失败，致使整个业务失去意义;

3、数据库中事务的实现方式：

------------------ service执行一个操作，要执行N条sql（ 一条sql 是一个原子性操作）

--------- 数据库内部，如何实现事务？

--------- 所有的sql执行完毕之前，结果都以副本形式存在，如下图

------- commit操作 ------ 业务线程向数据库发指令 ----- 把副本转正

------ roback操作 ------- 把副本丢掉

jdbc规范里- 事务管理器

//事务管理器
    @Bean
    DataSourceTransactionManager transactionManager(DataSource dataSource) {//事务管理
        return new DataSourceTransactionManager(dataSource);
    }

事务管理器定义三个标准接口，即：

1、启动事务（启动副本），

2、副本转正

3、副本丢弃

分布式事务

1、分布式事务，是指多台数据库的执行sql，也想要达到一致性的标准，即：多台一起commit或rollback

2、参照单机事务的模型，分布式事务的思路延袭，也想通过三个标准接口的模式来完成（启副本/commit/rollback）

3、按这个思路， X/Open组织提出了分布式事务的规范 ----- XA

4、XA的核心，便是全局事务，通过XA二阶段提交协议，与各分布式数据交互，分准备与提交两个阶段，如下图：

预置一个事务问题场景：去哪网上订购机票

国航：北京 ---- 香港

南航：香港 ----- 泰国

 

只有同时能在国航/南航买到机票，才算有意义，否则做退票处理！

一、XA规范下的2pc事务

2pc步骤：

1、引入包

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jta-atomikos</artifactId>
            <version>${spring.boot.version}</version>
</dependency>

2配置xadatasource --- 2pc方式需要支持XA协议的数据源

@Bean(name = "ghDataSource")
  @Primary
  @Autowired
  public DataSource ghDataSource(Environment env) {
    AtomikosDataSourceBean ds = new AtomikosDataSourceBean();
    Properties prop = build(env, "spring.datasource.druid.ghDB.");
    ds.setXaDataSourceClassName("com.alibaba.druid.pool.xa.DruidXADataSource");
    ds.setUniqueResourceName("ghDB");
    ds.setPoolSize(5);
    ds.setXaProperties(prop);
    return ds;

  }

3、代码示例 ------- 默认只有runtime（包括其子类）异常回滚 --------普通异常Exception是不回滚的

@Transactional
    public String doOrder(String busId,String idcard) {
        System.out.println("begin.....");

        String sql = "UPDATE tcc_fly_order SET bus_id=?,STATUS = 1,idcard=?,remark=? WHERE STATUS = 0 LIMIT 1";

        //锁定订单
        int ret = ghJdbcTemplate.update(sql,busId,idcard,"国航");
        if (ret != 1){
            throw new RuntimeException("国航下单失败，无票可订");
        }

        //锁定订单
        ret = nhJdbcTemplate.update(sql,busId,idcard,"南航");
        if (ret != 1){
            throw new RuntimeException("南航下单失败，无票可订");
        }
        System.out.println("end.....");
        return "success";
    }

只要doOrder方法里抛出了RuntimeException，则两个数据库里的sql结果，都会被回滚掉

2pc在现实使用中的问题/限制：

1、必须要使用支持XA协议的datasource数据源

2、因为要同时锁定两个数据库的数据，事务锁定时间大大延长 ------ 现实中数据库性能欠佳

base理论/柔性事务

为了可用性，牺牲一致性

BA:Basic Availability 基本业务可用性

S：Soft state 柔性状态（中间态不一致）

E :  Eventual consistency 最终一致性

1、base理论的本质，是不再遵守ACID标准，不做强一致性

2、base理论的S，即指事务执行的中间状态（commit之前的状态），可以不隔离锁定，允许对外界表现出不一致

-----------一个事务执行需要时间 ------- a步骤---》b步骤 -------- 20毫秒 ---- 中间状态

3、base理论的E，即指保证最终所有的步骤都得到执行，达到最终数据是一致的

4、整个base理论的过程，如下：

事务开始前 ----- 数据是一致的

事务进行中 ------ 数据是不一致的 ---- 中间态不一致 ---- 放宽标准

事务结束后 ------ 数据又一致

5、对比ACID事务，base事务就是砍掉其中的数据锁定状态

----------------为了可用性 --- 数据锁定的状态--- 不可用状态

6、业界对事务分类标准：

ACID标准，强一致性要求的事务标准 ----- 刚性事务

牺牲一致，放弃ACID里的强一致要求-------柔性事务：

tcc两阶段、补偿性事务

1、业务接口改造：

一个普通业务接口-----切成三个接口：try--confirm--cancel

try    ------- 原业务接口------- 接口执行完毕，数据库数据就提交 ----如： insert一条数据1

confirm ------ 确认数据 --------- 将try阶段的数据查询出来确认，如： select 1确认数据是否已ok

cancel -------- 抵消数据 --------- 将try阶段的数据做逆向取消，如： delete from删除数据/ insert  -1再加一条数据抵消  ------- 逆向业务方法，又称之谓补偿动作

2、try -confirm-cancel的三个步骤联动过程

如果try不出正常结束，则框架自动去调用confirm方法

如果try出了异常，框架去调用cancel补偿方法

3、tcc方案，对原业务的侵入性太强。为了更好控制，通常做变种使用

try    ------- 将原业务接口，涉及到的资源锁定/或者做预备 ------ 通过一个冻结状态，做排它处理

confirm ------ 正式调用原业务接口方法，如：insert一条数据1 ----- 因try阶段已经为此语句准备好了执行条件，不会再出现业务的冲突情况（业务一定是可行的）

cancel -------- 恢复资源状态，取消资源的冻结状态

4、tcc-transation框架方案实战

（1）、引入pom

<dependency>
            <groupId>org.mengyun</groupId>
            <artifactId>tcc-transaction-dubbo</artifactId>
            <version>${tcc.version}</version>
        </dependency>

        <dependency>
            <groupId>org.mengyun</groupId>
            <artifactId>tcc-transaction-spring</artifactId>
            <version>${tcc.version}</version>
        </dependency>

（2）、配置tcc数据源

（3）、tcc事务的日志表，TCC_TRANSACTION_ENJOY这张，是由_ENJOY

（4）代码逻辑如下：其中confirm指定确认方法，cancelMethod指定补偿方法

public class GHServiceImpl implements GHService{
    @Autowired
    private JdbcTemplate jdbcTemplate;
    @Autowired
    private NHService nhService;

    @Compensable(confirmMethod = "confirmOrder", cancelMethod = "cancelOrder")
    @Transactional
    public int doOrder(String busId,String idcard) {//try方法

        System.out.println("frozen order："+busId);

        //幂等性要求，如果已经执行过，则直接返回
        Integer count = jdbcTemplate.queryForObject("SELECT COUNT(1) FROM tcc_fly_order t WHERE t.bus_id = ?",Integer.class,busId);
        if (count > 0){
            return 1;
        }

        //锁定订单
        int ret = jdbcTemplate.update(
                "UPDATE tcc_fly_order SET frozen = 1,bus_id=? WHERE STATUS = 0 AND frozen=0 LIMIT 1",busId);
        if (ret != 1){
            throw new RuntimeException("下单失败，国航无票可订");
        }
        nhService.doOrder(busId,idcard);
        return ret;
    }

    public int confirmOrder(String busId,String idcard) {
        System.out.println("confirm order："+busId);

        //本语句是幂等性的
        int ret = jdbcTemplate.update("UPDATE tcc_fly_order SET frozen = 0,STATUS = 1,idcard=? WHERE bus_id=? and STATUS = 0 ",idcard,busId);
        return ret;
    }

    public int cancelOrder(String busId,String idcard) {//补偿性
        System.out.println("cancel order："+busId);

        //本语句是幂等性的
        int ret = jdbcTemplate.update("UPDATE tcc_fly_order SET frozen = 0,STATUS = 0 WHERE bus_id=?",busId);
        return ret;
    }
}

（5）tcc框架对业务方法的要求：

try-confirm-cancel三个方法，都必须要满足幂等性/可查询性