springcloud入门——Seata

目录

1.初识seata

2.Seata环境准备

3.@GlobalTransactional的使用

4.Seata之原理

---

1.初识seata

使用分布式微服务前单机单库没这个问题；使用分布式微服务后从1:1 -> 1:N -> N:N：

单体应用被拆分成微服务应用，原来的三个模块被拆分成三个独立的应用,分别使用三个独立的数据源，业务操作需要调用三三 个服务来完成。此时每个服务内部的数据一致性由本地事务来保证， 但是全局的数据一致性问题没法保证。

一次业务操作需要跨多个数据源或需要跨多个系统进行远程调用，就会产生分布式事务问题。

Seata是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。

分布式事务处理过程的一ID+三组件模型：

一ID：Transaction ID XID ，全局唯一的事务ID。

三组件：

• TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚。
• TM (Transaction Manager) - 事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务。
•  RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

处理过程：

1.     TM向TC申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID；
2.     XID在微服务调用链路的上下文中传播；
3.     RM向TC注册分支事务，将其纳入XID对应全局事务的管辖；
4.     TM向TC发起针对XID的全局提交或回滚决议；
5.     TC调度XID下管辖的全部分支事务完成提交或回滚请求。

seata安装后需要修改配置文件file.conf:

以及修改registry.conf文件：

2.Seata环境准备

首先我们会创建三个服务，一个订单服务，一个库存服务，一个账户服务，对应三个微服务及三个数据库数据。

当用户下单时,会在订单服务中创建一个订单, 然后通过远程调用库存服务来扣减下单商品的库存，再通过远程调用账户服务来扣减用户账户里面的余额，最后在订单服务中修改订单状态为已完成。

该操作跨越三个数据库，有两次远程调用，很明显会有分布式事务问题。

一言蔽之，下订单—>扣库存—>减账户(余额)—>改状态。

创建业务数据库

    seata_ order：存储订单的数据库;
    seata_ storage：存储库存的数据库;
    seata_ account：存储账户信息的数据库。

seata_order库下建t_order表：

seata_storage库下建t_storage表：

seata_account库下建t_account表：

按照上述3库分别建对应的回滚日志表

• 订单-库存-账户3个库下都需要建各自的回滚日志表
• \seata-server-0.9.0\seata\conf目录下的db_ undo_ log.sql

 对应三个数据库，我们创建三个module，都需要导入依赖（注意Seata版本对应）：

seata-order-service2001：

注意！如果测试时出现Hystrix调用超时异常，可以修改为以下内容（加入以下Hystrix的单独配置,即设置默认超时时间）：

 因为OpenFeign底层使用的是ribbon，ribbon连接客户端的时间是1s。

拷贝file.conf和registry.conf至resource文件夹中，注意修改部分内容：

新建domain类（实体类）：

业务类：

dao-mapper：

service（因order模块需调用另外两个微服务模块的方法，所以此处有3个service及一个实现类）：

控制类：

config配置，设置为自己的数据源：

主启动类：

seata-storage-service2002：

主要内容相似，主要完成order微服务中调用的decrease方法的编写：

seata-account-service2003：

主要内容相似，主要完成order微服务中调用的decrease方法的编写：

 

测试：

正常下单 - http://localhost:2001/order/create?userId=1&productId=1&count=10&money=100

数据库查得数据已修改：

3.@GlobalTransactional的使用

 模拟AccountServiceImpl添加超时异常：

故障情况

• 当库存和账户金额扣减后，订单状态并没有设置为已经完成，没有从零改为1

• 而且由于feign的重试机制，账户余额还有可能被多次扣减

用@GlobalTransactional标注OrderServiceImpl的create()方法：

再次访问，显示error页面，但数据库未进行插入操作，记录都添加不进来，达到出异常，数据库回滚的效果。

4.Seata之原理

简单来说，TC（全局协调管理者）可以理解为seata的服务器，负责所有seata业务的注册及管理，管理所有分布式业务；TM（即标记注解@GlobalTransactional的方法）可以理解为事物的发起方，由他向TC申请XID。RM即每一个数据库，对应每一个微服务，他需要向TC注册。

seata目前有四种模式，我们使用的是AT无侵入自动补偿的事务模式。

整体机制：

两阶段提交协议的演变：

• 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
• 二阶段：

1. 提交异步化，非常快速地完成。
2. 回滚通过一阶段的回滚日志进行反向补偿。

在一阶段，Seata会拦截“业务SQL”

1. 解析SQL语义，找到“业务SQL" 要更新的业务数据，在业务数据被更新前，将其保存成"before image”（前置sql）。

2. 执行“业务SQL" 更新业务数据。

3. 在业务数据更新之后,将其保存成"after image”（后置sql），最后生成行锁。

以上操作全部在一个数据库事务内完成, 这样保证了一阶段操作的原子性。 

二阶段提交

• 二阶段如果顺利提交的话，因为"业务SQL"在一阶段已经提交至数据库，所以Seata框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

二阶段回滚

• 二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的 “业务SQL"，还原业务数据。
• 回滚方式便是用"before image"还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和"after image"。
• 如果两份数据完全一致就说明没有脏写（没有人动过）， 可以还原业务数据，如果不一致就说明有脏写, 出现脏写就需要转人工处理。