在
JavaEE
企业级开发的应用领域,为了保证数据的完整性和一致性,必须引入数据库事务的概念,所以事务管理是企业级应用程序开发中必不可少的技术。所谓本地事务,是指在单个数据源上进行数据的访问和更新,它仅在当前工程内有效。
数据库事务的四大特性:原子性(Atomicity
)、一致性( Consistency
)、隔离性或独立性( Isolation
) 和持久性(Durabilily
),简称就是 ACID
。
原子性:一系列的操作整体不可拆分,要么同时成功,要么同时失败。
一致性:数据在事务的前后,业务整体一致。
隔离性:事务之间互相隔离。
持久性:一旦事务成功,数据一定会落盘在数据库。
在以往的单体应用中,我们多个业务操作使用同一条连接操作不同的数据表,一旦有异常,我们可以很容易地整体回滚。就比如买东西业务,扣库存,下订单,账户扣款,是一个整体,必须同时成功或者失败。一个事务开始,代表以下的所有操作都在同一个连接里面。
READ UNCOMMITTED
(脏读):该隔离级别的事务会读到其它未提交事务的数据。READ COMMITTED
(不可重复读):一个事务可以读取另一个已提交的事务,多次读取会造成不一样的结果。Oracle
和 SQL Server
的默认隔离级别。REPEATABLE READ
(虚读/幻读):该隔离级别是 MySQL
默认的隔离级别,一个事务可以读取另一个事务已提交的数据,读取的数据前后相比多了点或者少了点。MySQL
的 InnoDB
引擎可以通过next-key locks
机制来避免幻读。SERIALIZABLE
(序列化):这是数据库最高的隔离级别,在该隔离级别下事务都是串行顺序执行的,MySQL
数据库的 InnoDB
引擎会给读操作隐式加一把读共享锁,从而避免了脏读、不可重读复读和幻读问题,但是执行效率差,性能开销也最大,所以基本没人会用。PROPAGATION_REQUIRED: :如果当前没有事务,就创建一个新事务,如果当前存在事务,就加入该事务,该设置是最常用的设置。
PROPAGATION_SUPPORTS: :支持当前事务,如果当前存在事务,就加入该事务,如果当前不存在事务,就以非事务执行。
PROPAGATION_MANDATORY: :支持当前事务,如果当前存在事务,就加入该事务,如果当前不存在事务,就抛出异常。
PROPAGATION_REQUIRES_NEW::创建新事务,无论当前存不存在事务,都创建新事务。
PROPAGATION_NOT_SUPPORTED::以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。
PROPAGATION_NEVER: :以非事务方式执行,如果当前存在事务,则抛出异常。
PROPAGATION_NESTED: :如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则执行与 PROPAGATION_REQUIRED 类似的操作。
七种事务传播机制最常用的就两种:
1.4.1 问题一:远程服务假失败
远程服务其实成功了,由于网络故障没有返回,导致订单回滚,库存却扣减。
假失败就是我们在订单服务调库存服务时, 库存锁定成功,然后由于服务器慢、卡顿、等故障原因,本地事务提交了之后,一直没返回到订单服务。此时再看订单服务,因为调用库存服务时间太长了,库存服务迟迟没有返回结果,可能就会触发 feign
的超时机制,在调用远程服务这里抛异常:read time out
读取超时,但是这个异常并不是我们手动抛的锁库存异常,而是 feign
的异常并且订单服务,设计的回滚机制,是只要一出现异常就会全部回滚,导致最终数据不一致。
示意图:
1.4.2 问题二:调用新服务出现异常之后,已经执行的服务不会回滚
假设库存锁定成功,将结果返回到了订单服务,我们根据结果又调用了积分服务,让它扣减积分,结果积分服务内部出现异常,积分数据回滚此时再看订单服务,订单服务感知到我们手动抛的积分异常,订单数据回滚,但是库存服务,却不会有任何感知。其结果就是积分、订单数据全部回滚,库存给锁定了,也是数据不一致。
示意图:
1.4.3 总结:
本地事务,在分布式系统,只能控制住自己的回滚,控制不了其它服务的回滚。
产生分布式事务问题的最大原因,就是网络问题 + 分布式机器。
假设我们有一个下单的事务场景,它会涉及调用库存、订单、会员功能。
在单体应用下,我们将三个功能的代码写到一个系统,而且都是连接同一数据库,这样的话很容易就能控制事务,若其中一个失败,则整个事务都会回滚。
而在分布式系统下,我们拆分了很多的微服务,它们都是独立部署且每个服务都有自己操作的数据库,那这样我们想要完成整个下单逻辑,我们就要远程调用这三个机器的各个方法。
但是,由于分布式系统会经常出现机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的 TCP、存储数据丢失…等异常情况。所以,分布式事务是企业集成中的一个技术难点,也是每一个分布式系统架构中都会涉及到的一个东西,特别是在微服务架构中,几乎可以说是无法避免。
CAP
指的是一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。
CAP
原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。
满足一致性:假设我们有三个节点,当客户端有一个请求进来,我们所有的节点完成数据备份,此时满足了我们的一致性C
的需求。
可用性与一致性冲突:再次假设,当节点1向节点2、3要求同步备份数据时,此时节点3发生了网络故障,也就是分区容错性。接下来我们就会考虑,能否满足可用性?若让其满足的话(允许客户端请求负载到节点3读取数据),但是由于上次发生故障导致节点3的数据没有更新,则此时读到的数据就出现了不一致。所以当你想要满足一致性,就必须让节点3不能被访问,既然不能被访问相当于又不可用。C
和A
无法同时做到。
在分布式系统里,因为我们这个网络肯定会出现问题,所以我们永远都要满足分区容错。则就需要在一致性与可用性做出选择。
选择可用性+分区容错性(AP
)的情况下,我们不去在意读到的数据是否一致,这种场景实现相对简单。
若选择一致性+分区容错性(CP
)的情况下,是如何保证它们之间一致的?我们在分布式系统里边一般会有一些一致性算法,典型的代表,比如说Google的Chubby分布式锁服务,采用了Paxos
算法;etcd分布式键值数据库,采用了Raft
算法;ZooKeeper分布式应用协调服务,Chubby的开源实现,采用ZAB
算法。
由于 Paxos
算法过于晦涩难懂且难以实现,后提出了一种更易于理解和实现并能等价于 Paxos
算法的共识算法 - Raft
算法。
Raft
算法有两个核心概念:
领导选举(关注角色、心跳时间、自旋时间)-> Leader的选举过程-演示动画:https://acehi.github.io/thesecretlivesofdata-cn/raft/#election
日志复制 -> 日志复制过程-演示动画:https://acehi.github.io/thesecretlivesofdata-cn/raft/#replication
通过它们来保证我们整个集群的一致性,即使有分区错误,我们也能保持一致性。
是对
CAP
理论的延伸,思想是即使无法做到强一致性(CAP
的一致性就是强一致性),但可以采用适当的采取弱一致性,即最终一致性。
强一致与弱一致是对立概念。强一致性也叫做线性一致性,除此以外,所有其它的一致性都是弱一致性的特殊情况。所谓强一致性,即数据备份是同步的,弱一致性,即数据备份是异步的。
基本可用(Basically Available):指分布式系统在出现故障的时候,允许损失部分可用性(例如响应时间、功能上的可用性)。需要注意的是,基本可用绝不等价于系统不可用。就比如:
软状态( Soft State) :指允许系统存在中间状态,而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本,允许不同副本同步的延时就是软状态的体现。MySQL Replication
的异步复制也是一种体现。
最终一致性( Eventual Consistency):指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。
2PC
就是我们说的二阶段提交,又叫做XA Transactions
。MySQL
从 5.5 版本开始支持,SQL Server
2005 开始支持,Oracle
7 开始支持。
假设我们这有一个本地资源管理器(相当于每个服务的事务管理器),一个事务管理器(相当于总的事务管理器)。
协调事务处理共为两个阶段:
PreCommit
)此操作,并反映是否可以提交。优点:
XA 协议
比较简单,而且一旦商业数据库实现了 XA 协议
,使用分布式事务的成本也比较低。缺点:
mysql
的 XA
实现,没有记录 prepare 阶段日志,主备切换回导致主库与备库数据不一致。nosql
也没有支持 XA
,这让 XA
的应用场景变得非常狭隘。总结:了解即可,使用场景非常少。
三阶段提交(
3PC
)是二阶段提交(2PC
)的一个改良版本,引入了两个新的特性。
2PC
的同步阻塞问题,避免事务资源被永久锁定。CanCommit
、PreCommit
、DoCommit
三个阶段组成事务处理协议。3PC
相比较于 2PC
最大的优点就是降低了参与者的阻塞范围,并且能够在协调者出现单点故障后继续达成一致。3PC
依然存在数据不一致的问题。当参与者接收到 PreCommit
消息后,如果网络出现分区,此时协调者与参与者无法进行正常通信,这种情况下,参与者依然会进行事务的提交。2PC
和 3PC
之后,我们可以知道这两种方案都无法彻底解决分布式下的数据一致性。补偿事务
TCC
,全称Try-Confirm-Cancel
。
什么是柔性事务?
ACID
原则,强一致性。BASE
理论,最终一致性。与刚性事务不同,柔性事务允许一定时间内,不同节点的数据不一致,但要求最终一致。TCC核心思想:针对每个操作都要注册一个与其对应的确认(Try
)和补偿(Cancel
)。
Confirm
一起才能构成一个完成的业务逻辑。Try
阶段所有分支事务执行成功后开始执行 Confirm
。示意图:
2PC
通常是在跨库DB
里,而 TCC
是在应用层面。TCC
每个业务逻辑代码都要实现Try
、Confirm
、Cacnel
接口,开发难度大,所以所对应用的倾入性非常强。方案主要用在与第三方系统通讯时,比如:调用微信或支付宝支付后的支付结果通知。这种 方案也是结合
MQ
进行实现,例如:通过MQ
发送http
请求,设置最大通知次数,达到通知次数后即不再通知。
MQ
。接下来由订阅了消息队列的订单及库存服务接收消息,当它们都收到消息后,库存服务就会解锁库存,订单服务就会解锁订单,完成事务的回滚。既然是最大努力通知,期间就会不断发送业务处理失败的消息,直至对应业务返回处理成功的消息,就不再进行通知了。实现:业务处理服务在业务事务提交之前,向实时消息服务请求发送消息,实时消息服务只记录消息数据,而不是真正的发送。业务处理服务在业务事务提交之后,向实时消息服务确认发送。只有在得到确认发送指令后,实时消息服务才会真正发送。
关键点(防止消息丢失):
Publisher
,Consumer
手动 ack
。消息记录表:
CREATE TABLE `mq_message` (
`message_id` CHAR ( 32 ) NOT NULL,
`content` text,
`to_exchane` VARCHAR ( 255 ) DEFAULT NULL,
`routing_key` VARCHAR ( 255 ) DEFAULT NULL,
`class_type` VARCHAR ( 255 ) DEFAULT NULL,
`message_status` INT ( 1 ) DEFAULT '0' COMMENT '0-新建 1-已发送 2-错误抵达 3-已抵达',
`create_time` datetime DEFAULT NULL,
`update_time` datetime DEFAULT NULL,
PRIMARY KEY ( `message_id` )
) ENGINE = INNODB DEFAULT CHARSET = utf8mb4
Seata
是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。Seata
将为用户提供了AT
、TCC
、SAGA
和XA
事务模式,为用户打造一站式的分布式解决方案。
TC - 事务协调者:维护全局和分支事务的状态,驱动全局事务提交或回滚。
TM - 事务管理器:定义全局事务的范围(开始全局事务、提交或回滚全局事务)。
RM - 资源管理器:管理分支事务处理的资源,与 TC 交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。
工作原理:
TM
(事务管理器)先会告诉 TC
(事务协调者)它要准备跨服开启一个全局事务。TC
(事务协调者)注册一下,我们称为分支事务。相当于它的 RM
(资源管理器)会告诉 TC
(事务协调者),它有一个分支事务,并且它要实时汇报它的事务状态,它这个分支是提交成功还是失败回滚, TC
(事务协调者)都能实时的知道。TC
(事务协调者)都知道这个小事务成了还是败了。TC
(事务协调者)知道我们的大事务,已经调成功两个了,并且前两个事务都已经提交了,但是第三个事务给回滚了,TC
(事务协调者)就会命令前两个事务也回滚。5.2.1 相关概念:
AT
模式(自动事务Auto Transaction)是Seata
最主推的分布式事务解决方案,它是基于XA
演进而来。AT
模式是一种无侵入的分布式事务解决方案,也就是说我们不需要再编写多余的代码来实现这个模式,只需要在方法中添加上指定的注解即可。SQL
”,用户的 “业务 SQL
” 作为一阶段,Seata
框架会自动生成事务的二阶段提交和回滚操作。MySQL
、Oracle
、PostgreSQL
和 TiDB
。5.2.2 模式概述:
UNDO_LOG
表(即回滚日志表)。TC
(事务协调者) 只要调分支事务,成功之后就会提交事务,但是如果有一个分支事务失败了,失败的这个可以自己进行回滚。RM
(资源管理器)部分完成的,会在每一个数据库单元处理时均会生成一条log
数据。UNDO_LOG
里面记录了一下这条记录没改变之前的值。如果它失败回滚了,那它就回过头把我们数据库里边的这个十再改回去,改成八。所以,它相当于在我们事务执行之前,它先读取一下这个状态是几,最后再改回来。5.3.1 组件版本关系:
每个
Spring Cloud Alibaba
版本及其自身所适配的各组件对应版本如下表所示(避免版本不兼容带来未知问题)。
5.3.2 Docker下安装 Seata:
# 1.下载镜像(注意:此处版本号请参考组件版本关系图!)。
$ docker pull seataio/seata-server:1.2.0
# 2.启动容器。
$ docker run -d --name seata-server -p 8091:8091 seataio/seata-server:1.2.0
# 3.创建存放配置的文件夹。
mkdir -p /home/seata/config
# 4.拷贝配置文件。
$ docker cp seata-server:/seata-server/resources /home/seata/config
# 5.编辑配置文件(参考下面截图)。
$ cd /home/seata/config/resources
$ vim registry.conf
# 提示:
# 可以在registry.conf指定seata配置的位置(config {type = "nacos"})。
# 可以在file.conf中指定事务日志存储类型(store {mode = "db"}),若使用mysql-8版本则需要额外修改以下两项配置,否则报错。
# driverClassName = "com.mysql.cj.jdbc.Driver"
# url = "jdbc:mysql://127.0.0.1:3306/seata?serverTimezone=UTC"
# 6.停止容器。
$ docker stop seata-server
# 7.移除旧容器。
$ docker rm seata-server
# 8.启动新容器并挂载配置。
$ docker run -d \
--name seata-server \
-p 8091:8091 \
-e SEATA_IP=yourIp(公网IP) \
-v /home/seata/config/resources:/seata-server/resources \
seataio/seata-server:1.2.0
# 设置开机自启。
$ docker update seata-server --restart=always
5.3.3 验证Seata服务启动成功:
$ docker logs seata-server
http://yourIp:8848/nacos
5.4.1 数据库添加 UNDO_LOG 表:
每一个要使用分布式事务的数据库都需要一个
UNDO_LOG
表。
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,
`ext` VARCHAR ( 100 ) DEFAULT NULL,
PRIMARY KEY ( `id` ),
UNIQUE KEY `ux_undo_log` ( `xid`, `branch_id` )
) ENGINE = INNODB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8;
branch_id
:分支事务ID。xid
:全局事务ID(Seata
服务端地址+ ID)。context
:回滚信息序列化和压缩格式。rollback_info
:回滚信息。log_status
:日志状态(0
表示正常,1
表示全局已完成)。log_created
:创建时间。log_modified
:修改时间。5.4.2 依赖引入:
<dependency>
<groupId>com.alibaba.cloudgroupId>
<artifactId>spring-cloud-starter-alibaba-seataartifactId>
dependency>
5.4.3 配置代理数据源:
配置代理数据源实现分支事务,如果没有注入,事务无法成功回滚。
@Configuration
public class MySeataConfig {
@Autowired
DataSourceProperties dataSourceProperties;
/**
* 需要将 DataSourceProxy 设置为主数据源,否则事务无法回滚。
*
* @param dataSourceProperties 数据源属性配置。
* @return {@link DataSource}
*/
@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);
}
}
5.4.4 微服务中添加配置文件:
方式一(此处使用):每个要使用分布式事务的微服务服务中(
src/main/resources/
),都要添加这两个文件(registry.conf
、file.conf
)。方式二:也可以将
Nacos
作为统一配置中心,去配置Seata
的file.conf
各项参数,实现集群的配置共享,并结合application.properties/yml
+registry.conf
完成微服务整合。
registry.conf
# ---注册中心配置---
registry {
# file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
# 指定类型为nacos注册中心(根据项目所使用的注册中心进行选择),默认是"file"。
type = "nacos"
nacos {
serverAddr = "localhost:8848"
namespace = "public"
cluster = "default"
}
eureka {
serviceUrl = "http://localhost:1001/eureka"
application = "default"
weight = "1"
}
redis {
serverAddr = "localhost:6379"
db = "0"
}
zk {
cluster = "default"
serverAddr = "127.0.0.1:2181"
session.timeout = 6000
connect.timeout = 2000
}
consul {
cluster = "default"
serverAddr = "127.0.0.1:8500"
}
etcd3 {
cluster = "default"
serverAddr = "http://localhost:2379"
}
sofa {
serverAddr = "127.0.0.1:9603"
application = "default"
region = "DEFAULT_ZONE"
datacenter = "DefaultDataCenter"
cluster = "default"
group = "SEATA_GROUP"
addressWaitTime = "3000"
}
file {
name = "file.conf"
}
}
# ---配置中心---
config {
# file、nacos 、apollo、zk、consul、etcd3
# 指定seata配置的位置,默认"file"。
type = "file"
nacos {
serverAddr = "localhost"
namespace = "public"
cluster = "default"
}
consul {
serverAddr = "127.0.0.1:8500"
}
apollo {
app.id = "seata-server"
apollo.meta = "http://192.168.1.204:8801"
}
zk {
serverAddr = "127.0.0.1:2181"
session.timeout = 6000
connect.timeout = 2000
}
etcd3 {
serverAddr = "http://localhost:2379"
}
file {
# 关联 `file.conf` 文件中配置的seata参数。
name = "file.conf"
}
}
file.conf
# ---网络传输配置---
transport {
# tcp udt unix-domain-socket
type = "TCP"
#NIO NATIVE
server = "NIO"
#enable heartbeat
heartbeat = true
#thread factory for netty
thread-factory {
boss-thread-prefix = "NettyBoss"
worker-thread-prefix = "NettyServerNIOWorker"
server-executor-thread-prefix = "NettyServerBizHandler"
share-boss-worker = false
client-selector-thread-prefix = "NettyClientSelector"
client-selector-thread-size = 1
client-worker-thread-prefix = "NettyClientWorkerThread"
# netty boss thread size,will not be used for UDT
boss-thread-size = 1
#auto default pin or 8
worker-thread-size = 8
}
shutdown {
# when destroy server, wait seconds
wait = 3
}
serialization = "seata"
compressor = "none"
}
# ---当前微服务在seata服务器中注册的信息配置---
service {
# 事务分组,默认:${spring.applicaiton.name}-fescar-service-group。
vgroup_mapping.applicaiton-name-fescar-service-group = "default"
# 仅支持单节点,不要配置多地址,这里的default要和事务分组的值一致。
default.grouplist = "127.0.0.1:8091"
# 降级,当前不支持。
enableDegrade = false
# 禁用全局事务。
disable = false
#unit ms,s,m,h,d represents milliseconds, seconds, minutes, hours, days, default permanent
max.commit.retry.timeout = "-1"
max.rollback.retry.timeout = "-1"
}
# ---客户端相关工作的机制---
client {
async.commit.buffer.limit = 10000
lock {
retry.internal = 10
retry.times = 30
}
report.retry.count = 5
}
# ---事务日志存储配置---
# 注意:该部分配置仅在seata-server中使用,如果选择db请配合seata.sql使用。
## transaction log store
store {
## store mode: file、db
mode = "file"
## file store
file {
dir = "sessionStore"
# branch session size , if exceeded first try compress lockkey, still exceeded throws exceptions
max-branch-session-size = 16384
# globe session size , if exceeded throws exceptions
max-global-session-size = 512
# file buffer size , if exceeded allocate new buffer
file-write-buffer-cache-size = 16384
# when recover batch read size
session.reload.read_size = 100
# async, sync
flush-disk-mode = async
}
## database store
db {
## the implement of javax.sql.DataSource, such as DruidDataSource(druid)/BasicDataSource(dbcp) etc.
datasource = "dbcp"
## mysql/oracle/h2/oceanbase etc.
db-type = "mysql"
url = "jdbc:mysql://127.0.0.1:3306/seata"
user = "mysql"
password = "mysql"
min-conn = 1
max-conn = 3
global.table = "global_table"
branch.table = "branch_table"
lock-table = "lock_table"
query-limit = 100
}
}
lock {
## the lock store mode: local、remote
mode = "remote"
local {
## store locks in user's database
}
remote {
## store locks in the seata's server
}
}
recovery {
committing-retry-delay = 30
asyn-committing-retry-delay = 30
rollbacking-retry-delay = 30
timeout-retry-delay = 30
}
transaction {
undo.data.validation = true
undo.log.serialization = "jackson"
}
## metrics settings
metrics {
enabled = false
registry-type = "compact"
# multi exporters use comma divided
exporter-list = "prometheus"
exporter-prometheus-port = 9898
}
5.4.5 添加全局事务注解:
主业务方法添加全局事务注解:@GlobalTransactional
分支业务方法添加本地事务注解:@Transactional
@GlobalTransactional
public void purchase(String userId, String commodityCode, int orderCount) {
......
}
# 整合 nacos
https://github.com/seata/seata-samples/tree/master/springcloud-nacos-seata
# 整合 jpa
https://github.com/seata/seata-samples/tree/master/springcloud-jpa-seata
# 整合 dubbo
https://github.com/seata/seata-samples/tree/master/springboot-dubbo-seata
# 整合 ShardingSphere
https://github.com/seata/seata-samples/tree/master/springboot-shardingsphere-seata
“-------怕什么真理无穷,进一寸有一寸的欢喜。”
微信公众号搜索:饺子泡牛奶。