上一篇：单业务的一致性（CAP中的C【Consistency】）-02CAP介绍

1.使用Seata做强一致性分布式事务

还是我们开头提出的问题：如何保证1.1、1.2、1.3要么同时成功，要么同时失败，本小节，使用alibaba seata作为分布式事务的解决方案，达到这个目的。

2.Seata的AT模型介绍

seata中文官网：http://seata.io/zh-cn/docs/user/quickstart.html
可以直接官网查看，这里作为搬运工。

2.1Seata 是什么?

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

此处仅讨论其AT模式，AT模式本质上也是2PC模式。

2.2使用前提?

1.基于支持本地 ACID 事务的关系型数据库。
2.Java 应用，通过 JDBC 访问数据库。

2.3整体机制?

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

二阶段：
提交异步化，非常快速地完成。
回滚通过一阶段的回滚日志进行反向补偿。使用第一阶段的事务日志。undo.log

2.4写隔离

2.4.1正常提交

一阶段本地事务提交前，需要确保先拿到全局锁 。拿不到全局锁 ，不能提交本地事务。
拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。

下面的实例特别好：
两个全局事务 tx1 和 tx2，分别对 A 表的 m 字段进行更新操作，m 的初始值 1000。

• tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的全局锁 ，本地提交，释放本地锁。
• tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的全局锁 ，tx1全局提交前，该记录的全局锁被 tx1 持有，tx2 需要重试等待全局锁 。
  如下图：
  
• tx1 二阶段全局提交，释放全局锁 。tx2 拿到 全局锁 提交本地事务。

2.4.2回滚提交

• 如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。
• 此时，如果 tx2 仍在等待该数据的 全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 的 全局锁 等锁超时，放弃 全局锁 并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。
• 因为整个过程 全局锁 在 tx1 结束前一直是被 tx1 持有的，所以不会发生 脏写 的问题。

2.4写隔离?

在更新的同时进行查询的过程：

• 在数据库本地事务隔离级别 读已提交（Read Committed） 或以上的基础上，Seata（AT 模式）的默认全局隔离级别是 读未提交（Read Uncommitted） 。
• 如果应用在特定场景下，必需要求全局的 读已提交 ，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。
  
• SELECT FOR UPDATE 语句的执行会申请 全局锁 ，如果 全局锁 被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到 全局锁 拿到，即读取的相关数据是 已提交 的，才返回。
• 出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。

2.5工作机制实例说明AT模式

业务表：product

Field	Type	Key
id	bigint(20)	PRI
name	varchar(100)
since	varchar(100)

AT 分支事务的业务逻辑：

update product set name = 'GTS' where name = 'TXC';

2.5.1一阶段

过程：

1.解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = ‘TXC’）等相关的信息。
2.查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。

select id, name, since from product where name = 'TXC';

得到前镜像：

id	name	since
1	TXC	2014

3.执行业务 SQL：更新这条记录的 name 为 ‘GTS’。
4.查询后镜像：根据前镜像的结果，通过主键定位数据。

select id, name, since from product where id = 1;

5.插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中。

{
	"branchId": 641789253,
	"undoItems": [{
		"afterImage": {
			"rows": [{
				"fields": [{
					"name": "id",
					"type": 4,
					"value": 1
				}, {
					"name": "name",
					"type": 12,
					"value": "GTS"
				}, {
					"name": "since",
					"type": 12,
					"value": "2014"
				}]
			}],
			"tableName": "product"
		},
		"beforeImage": {
			"rows": [{
				"fields": [{
					"name": "id",
					"type": 4,
					"value": 1
				}, {
					"name": "name",
					"type": 12,
					"value": "TXC"
				}, {
					"name": "since",
					"type": 12,
					"value": "2014"
				}]
			}],
			"tableName": "product"
		},
		"sqlType": "UPDATE"
	}],
	"xid": "xid:xxx"
}

6.提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的 全局锁 。（注册时获得锁，锁后的后才会提交本地事务。）
7.本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。
8.将本地事务提交的结果上报给 TC。

2.5.2二阶段-回滚

1.收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作。
通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
2.数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理，详细的说明在另外的文档中介绍。（可以直接覆盖）
3.根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句：

update product set name = 'TXC' where id = 1;

4.提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC。

2.5.3二阶段-提交

1.收到 TC 的分支提交请求，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。
2.异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。

2.5.4回滚日志表

以 MySQL 为例：

Field	Field
Field	bigint
xid	varchar(100)
context	varchar(128)
rollback_info	longblob
log_status	tinyint
log_created	datetime
log_modified	datetime

sql:

-- 注意此处0.7.0+ 增加字段 context
CREATE TABLE `undo_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(100) NOT NULL,
  `context` varchar(128) NOT NULL,
  `rollback_info` longblob NOT NULL,
  `log_status` int(11) NOT NULL,
  `log_created` datetime NOT NULL,
  `log_modified` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

2.Seata的TCC 模式

回顾总览中的描述：一个分布式的全局事务，整体是 两阶段提交 的模型。全局事务是由若干分支事务组成的，分支事务要满足 两阶段提交 的模型要求，即需要每个分支事务都具备自己的：

• 一阶段 prepare 行为
• 二阶段 commit 或 rollback 行为
  
  根据两阶段行为模式的不同，我们将分支事务划分为 Automatic (Branch) Transaction Mode (自动事务模型)和 Manual (Branch) Transaction Mode（手动事务模型）.

AT 模式（参考链接 TBD）基于 支持本地 ACID 事务 的 关系型数据库：

• 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。

• 二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。

• 二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。
  相应的，TCC 模式，不依赖于底层数据资源的事务支持：

• 一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。

• 二阶段 commit 行为：调用 自定义 的 commit 逻辑。

• 二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。
  所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。
  总结一句话：和AT一模一样，只是自己实现。

3.Saga 模式

Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。

理论基础：Hector & Kenneth 发表论⽂ Sagas （1987）
适用场景：
业务流程长、业务流程多
参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口
优势：
一阶段提交本地事务，无锁，高性能
事件驱动架构，参与者可异步执行，高吞吐
补偿服务易于实现
缺点：
不保证隔离性

4.官方实例架构

用例
用户购买商品的业务逻辑。整个业务逻辑由3个微服务提供支持：

仓储服务：对给定的商品扣除仓储数量。
订单服务：根据采购需求创建订单。
帐户服务：从用户帐户中扣除余额。

5.官方实例架构SEATA 的分布式交易解决方案

我们只需要使用一个 @GlobalTransactional 注解在业务方法上:

@GlobalTransactional
    public void purchase(String userId, String commodityCode, int orderCount) {
        ......
    }

6.在订单业务的一致性中使用seata的AT保证分布式事务一致性

1.每个需要用到的微服务（此处三个）创建undo_log
这里涉及到三个微服务：订单服务、库存服务、积分服务，这三个数据库中分别创建undo_log表。
2.安装事务协调器TC，seata-server,即seata软件
3.整合项目

• 导入依赖

<!-- common pom.xml中添加，其他引用了common微服务的用到的就不需要再次添加了。
        Seata场景启动器 - 解决分布式事务 -->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
            <version>2.1.0.RELEASE</version>
        </dependency>

• 加压启动seata-server
  

• 所有想要用到分布式事务的服务使用seata DataSourceProxy代理自己的数据源

package com.atguigu.gulimall.order.config;

import com.zaxxer.hikari.HikariDataSource;
import io.seata.rm.datasource.DataSourceProxy;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.autoconfigure.jdbc.DataSourceProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.util.StringUtils;

import javax.sql.DataSource;

/**
 * @Description SeaTa分布式事务管理的配置bean类，主要是对数据源的配置。
 **/
@Configuration
public class MySeataConfig {

    @Autowired
    DataSourceProperties dataSourceProperties;


    /**
     * 这里抄的是源码中的配置数据源的方式。
     * 参考源码书写。主要是为了使用
     * @param dataSourceProperties
     * @return
     */
   @Bean
    public DataSource dataSource(DataSourceProperties dataSourceProperties) {

        HikariDataSource dataSource = dataSourceProperties.initializeDataSourceBuilder().type(HikariDataSource.class).build();
        if (StringUtils.hasText(dataSourceProperties.getName())) {
            dataSource.setPoolName(dataSourceProperties.getName());
        }

        return new DataSourceProxy(dataSource);
    }


}

特别注意，此处的数据源代理使用的是seata的代理，这样事务就交由seata管理了。：

import io.seata.rm.datasource.DataSourceProxy;

• 每个微服务均需要导入registry.conf和file.conf
  

• 在我们的业务方法上添加@GlobalTransactional可解决分布式事务问题。

	//点击提交订单按钮的时候，问题来了
	@GlobalTransactionall //seata事务 TM
  	@Transactional //本地事务 RM
    @Override
    public SubmitOrderRespVo submitOrder(OrderSubmitVo orderSubmitVo) {

        
            if (checkValidity() ) {//校验合法性，如果一切合法，则开始提交代码
	                // 1.1把订单保存在订单表中
	                saveOrder(order);
	                
	                // 1.2调用库存服务吧库存减去2
	                R r = wareFeignService.orderLocKStock(orderSubmitVo);
	
					// 1.3调用用积分服务给张三添加800万积分
	               	R r = pointsFeignService.upPoint(orderSubmitVo);
	               	return submitOrderRespVo;
	               	
               }
            } 
        }
    }

• 其他注意点：
  registry.conf和file.conf的配置有些注意点，再次不在赘述，可以使用数据库、或者文件作为存储使用；另外把自己配置进入nacos配置中心。
• 其他注意点 jpa整合https://github.com/seata/seata-samples/tree/master/springcloud-jpa-seata

1. file.conf 的 service.vgroup_mapping 配置必须和spring.application.name一致在 org.springframework.cloud:spring-cloud-starter-alibaba-seata的org.springframework.cloud.alibaba.seata.GlobalTransactionAutoConfiguration类中，默认会使用 ${spring.application.name}-fescar-service-group作为服务名注册到 Seata Server上，如果和file.conf中的配置不一致，会提示 no available server to connect错误
2. 也可以通过配置 spring.cloud.alibaba.seata.tx-service-group修改后缀，但是必须和file.conf中的配置保持一致
   

7总结

1.前面说了那么多其实就是一个注解的事。
2.seata的这种方案在一般场景中会使用到，例如金融it行业，但是在电商中不会使用，因为其中均需要获得锁local Lock 或者GlobleLock，性能低下，下篇介绍更为高效的解决方案：柔性事务-可靠消息+最终一致性。
下一篇地址：订单业务的一致性（CAP中的C【Consistency】）-04使用柔性事务-可靠消息+最终一致性方案

数据一致性解决方案

CAP理论

C：一致性、A：可用性、P：分区容错性
CAP只能满足两个
CA：两阶段提交的严格选举协议
CP弱A：RAFT协议等多数派选举协议
AP：GOSSIP等冲突解决协议

数据一致性

时间一致性：所有相关数据副本任意时刻数据一致
事务一致性：事务之行前后数据一致
应用一致性：分布式事务一致

BASE理论

基本可用：允许偶尔失败
软状态：数据状态要求任意时刻一致
最终一致性：弱一致性

数据一致性解决方案

多副本数据一致性：
一般用于容灾和高可用：副本之间通过同步复制或者异步复制的方式达到数据一致。
分布式事务数据一致性：
本地事务是指数据库的单机事务处理，有点是严格的ACID特性，高效、可靠、状态可以只在资源管理器中维护、应用编程模型简单。缺点：不具备分布式事务处理能力，隔离的最小单位受限于资源管理器。
分布式事务：事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点上。

强一致性解决方案：

一次请求对多个数据源的数据进行完整性以及一致性的操作，满足事务的特性，要么全部成功，要么全部失败，保证原子性以及可见性。
强一致性通过锁定资源的方式，但是会牺牲性能，使用之前需要谨慎评估。

XA分布式事务

XA协议：
是X/OPEN组织提出的分布式事务规范，该规范主要定义了全局事务管理器（TM）和本地资源管理器（RM）之间的接口，本地资源管理器往往由数据库实现。
主流的数据库产品都提供了XA接口，XA接口是一个双向的系统接口，在事务管理器以及多个资源管理器之间作为通信桥梁。
之所以需要XA，是因为在分布式系统中从理论上讲，两台机器是无法达到一致性状态的，因此引入了一个单节点进行协调。
有全局事务管理器管理的机器可以跨多个资源和进程，负责各个本地资源的提交和回滚，全局事务管理器一般使用XA二阶段提交协议与数据库进行交互。

二阶段提交（2PC）

准备阶段：
事务协调者向所有事务参与者发送事务内容，询问是否可以提交事务，并等待参与者回复。
提交阶段：
如果协调者收到了参与者的失败信息或者超时信息，直接给所有参与者发送回滚信息进行事务回滚；否则发送提交信息。
2PC方案实现起来比较简单，但是实际项目中使用比较少
缺陷：

• 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，容易造成性能问题；
• 可靠性问题：如果协调者存在单点故障问题，一旦协调者出现故障，参与者一直处于锁定状态；
• 数据一致性问题：第二阶段如果发生局部网络问题，一部分收到提交消息，一部分没有收到，会导致数据不一致。

三阶段提交（3PC）

三阶段提交是在二阶段提交的基础上的改进版本，主要是加入了超时机制，同时在协调者和参与者中都引用了超时机制。
三阶段是将二阶段里面的准备阶段拆分为两个阶段，插入了一个预提交阶段，这样原先二阶段准备之后，参与者发生崩溃或者错误所引起的问题。
第一阶段：
事务协调者向所有事务参与者发送事务内容，询问是否可以提交事务（canCommit），并等待参与者回复。参与者收到请求之后，检查是否可以提交，如果认为可以执行事务操作，返回Yes，并进入预备状态（参与者不执行事务操作），否则返回No。
第二阶段：
协调者根据第一阶段中参与者的相应情况来决定是否可以进行基于事务的预提交操作：
任何一个参与者反馈abord，即中断事务，协调者向所有参与者发送abord，abord或者超时都会中断事务。
第三阶段：
第二阶段中所有参与者均返回yes，会向所有参与者发送doCommit请求，参与者收到doCommit请求之后会正式执行事务提交，并释放整个事务期间的占用资源，各参与者向协调者返回完成的消息，协调者收到所有参与者的反馈的ack完成的消息后，完成事务的提交。
注意：
在进入第三阶段之后，无论是协调者出现问题，还是协调者与参与者的网络出现问题，都会导致参与者无法收到协调者的请求，此时参与者都会在等待超时之后继续执行事务提交（因为异常的情况毕竟是少数）

弱一致性解决方案

弱一致性：复制是异步的，最终一致性是弱一致性的特例，保证用户最终能够读取到某操作对系统特定的数据更新。
弱一致性为了提高系统的吞吐量，允许一定程度上的数据脏读。

最终一致性解决方案

强一致性的技术实现成本很高，运行性能低，很难满足真实业务场景下的高并发需求，在实际的生产环境中，通常采用最终一致性的解决方案。
最终一致性：不追求任意时刻系统都能满足数据完整且一致的要求，通过一段业务上可接受时间之后，系统能达到数据完整且一致的目标。

消息队列

建立两个消息topic，一个用来处理正常的业务提交，一个用来处理异常冲正消息。请求服务向正常的topic提交业务请求，如果全部正常，则数据一致；如果出现任何异常，向异常的topic提交业务请求，负责回滚。

事务消息方案

核心： 消息队列必须支持半事务消息（如RocketMQ），半事务消息提供类似于X/OPEN XA二阶段提交的分布式事务功能，这样能够确保请求服务执行本地事务和发送消息在一个全局事务中，只有本地事务成功执行之后，消息才会被投递。消息一旦被投递，默认设计业务执行必须成功（通过重试机制）。如果因为某些异常导致业务最终执行失败，系统无法自愈。只能通过告警的方式等待人工干预。

数据订阅方案

核心： 监听数据库的更新日志，并转换成消息流供消费端进行订阅处理。业务订阅是异步的，会存在一定的消息延迟。

TCC事务补偿

TCC是服务化的二阶段编程模型，尝试（try）、确认（confirm）、取消（cancel）均由业务编码实现。
try阶段： 尝试执行业务，完成所有业务的检查，实现一致性；预留必须的业务资源，实现准隔离型。
confirm阶段： 真正执行业务，不做任何检查，仅适用于try阶段预留的业务资源，同时要满足幂等性。
cancel阶段： 取消执行业务，释放try阶段预留的业务资源，操作要满足幂等性。

相比于二阶段提交：
TCC位于业务层服务，二阶段提交位于资源层
**性能提升： **业务来实现控制资源锁的粒度大小，不会锁定整个资源
数据最终一致性： 基于confirm和concel的幂等性，保证最终事务完成确认或者取消。
可靠性： 解决了XA协议的协调者单点故障的问题，由主业务方发起并控制整个业务活动，业务管理器也变成多点，引入集群。
缺点：
都要有具体业务实现，业务耦合度较高，提高开发成本。

saga事务模式

核心思想： 将长事务拆成多个本地短事务，由saga事务协调器进行协调，如果正常结束，则正常完成；如果某个步骤失败，根据相反顺序依次调用补偿操作，达到事务的最终一致性。
基本协议：

• saga事务由许多幂等的有序的小事务组成；
• 每个小事务都有对应的补偿，用于撤销执行后的结果；
  和TCC相比，没有预留动作，直接提交。
  有些场景不适合补偿，比如发送短信，发了之后如果撤销，就得再给用户发送说明撤销，体验较差。

一致性成本vs非一致性成本，原文链接：https://www.ffeeii.com/1882.html

质量成本：

质量成本（cost of quality）包括在产品生命周期中为预防不符合要求，为评估产品或服务是否符合要求，以及因未达到要求（返工），而发生的所有成本。

一致性成本：

一致性成本（cost of conformance），该成本是预防性的，在缺陷发生之前付出的，用于质量与要求或规范一致而付出的成本。

非一致性成本：

非一致性成本（cost of non-conformance），是由于质量与要求或者规范不一致而造成的成本。

一致性成本和非一致性成本对比：

一致性成本和非一致性成本对比

举例：

1、为了确保满足质量标准，项目经理聘请外部资源来检查可交付成果的质量。这种检查的成本可以分为哪些成本类别？

• A：预防成本
• B：评估成本
• C：外部成本
• D：失败成本

答案：B。检查属于评估成本

2、下面是非一致成本的例子，除了：

• A：返工
• B：培训
• C：报废
• D：保修

答案：B。解析：培训是为了提高团队成员的能力或统一对项目的质量的认识，是为了预防缺陷的产生，是一致性成本。