事务-分布式事务

1、事务的4个特性

原子性：整个事务为一个整体，要么全部成功，要么全部失败；
一致性：事务更新前后保持数据一致性，例如转账业务2个账户前后之和相等；（由程序业务管控）
隔离性：事务和事务之间的隔离级别，读未提交，读已提交，可重复读，串行化；事务的传播机制
持久性：事务更新后不会数据不会由于数据库宕机或其他因素改变

2、事务特性实现机制

事务的一致性需要靠程序业务实现
隔离性：通过配置隔离级别实现
事务的原子性和持久性，由undo,redo日志实现

数据在更新前会把原始数据写入undo日志，数据更新后会写入redo日志，事务提交写入磁盘

例如
A=1，B=2 更新为A=2，B=4
A=1 写入undo日志
A=2（内存中）
A=2 写入redo日志
B=2写入undo日志
B=4
B=4写入redo日志
undo日志写入磁盘
redo日志写入磁盘
数据写入磁盘（数据写入磁盘可异步）

3、分布式事务

例如下单付款业务
用户下单，在order-service 服务中生成订单，在account-service服务中扣钱，在storage-service服务中减库存
由于一个业务涉及到不同的服务或数据库，造成分布式事务

3.1 CAP理论

C:一致性：访问A数据源或B数据源结果保持一致
A:可用性，只要接收到用户请求，应用就必须返回响应；
P:分区容错性
CA之间比较矛盾，要保证一致性，就必须等待多个数据库之间数据同步，在同步期间，如果保持可用性，就一定会有数据不一致问题出现；
CA ：除非单点架构可实现
CP：zookeeper
AP: Eureka

3.2 Base理论

基本可用：CP
最终一致性：AP

3.3如何解决分布式事务

XA，TCC，可靠信息最终一致，AT

3.3.1 XA（两阶段提交协议2PC）

引入事务协调者概念
第一阶段：投票阶段：协调者问每个事务是否可执行，每个事务参与者执行事务，写入undo，redo日志，反馈结果
第二阶段：提交阶段：若每个事务参与者均可执行事务，则提交事务
缺陷：单点故障
协调者所动，事务执行过程中加锁等待

3.3.2 TCC

Try,confirm,cancel
try:资产检测和预留
confirm:
cancel:
缺陷:每个阶段都需要程序员编写对应代码，业务复杂化，安全问题考虑多

3.3.3 可靠消息服务（mq）

rocketmq本身有可靠消息服务
服务A 执行本地事务，发送消息到MQ
服务B 接收MQ消息，执行本地业务
保证最终一致性
若服务B执行失败，则服务A不可回滚，需手动解决
需保证消息传递可靠性

3.3.4 AT模式

Seata框架
类似于TCC原理，一阶段提交，二阶段补偿
补偿阶段由Seata框架自动执行
Seata在一个阶段拦截并解析，用select查询出来并保存镜像before images 类似于undo
二阶段，若成功，清空镜像，若失败回滚，查出before images
TC:事务协调者
TM：事务管理者
RM：资源管理器
TM开启事务，事务参与者执行把结果汇报给TC

实际应用：
搭建TC服务
在事务参与者的微服务中添加jar包
修改配置文件
添加全局事务注解