分布式事务一

一、事务

• 一个大的事务，包含多个小的活动，要么都成功，要么都失败

1. 本地事务

• 通过关系型数据库来控制事务
• 事务四大特性： ACID

A(Atomic): 原子性，构成事务的所有操作，要么都执行完成，要么都不执行

C(Consistency)： 一致性，事务执行前后，数据库的一致约束没有遭到破坏

I(Isolation)： 隔离性。数据库的事务一般都是并发的，并发的两个事务的执行
              互不干扰，一个事务不能看到其他事务运行过程的中间状态
              可以通过事务级别来控制

D(Duration)： 持久性，事务完成之后，该事务对数据的更改会被持久化到数据库

2. 分布式事务

• 应用拆分后，不同服务间通过远程协作，完成事务称为分布式事务

# 服务调用超时引发的问题
# 1. 跨jvm调用
工商银行张三给建设银行李四转钱
1.工商银行扣款100，同时调用建设银行李四加100
2. 如果调用失败，则工商银行回滚
3. 如果调用超时了，但是实际上李四已经加款成功了
4. 工商银行依然会滚了，导致张三没扣钱，但是李四加钱了

# 2.单体系统，调用多个数据库产生

# 3. 多系统，调用同一个数据产生

二、CAP

1. C-Consistency

• 写操作后的读操作可以读取到最新的状态
• 当数据库分布在多个节点上时，从任意节点读取到的数据都是最新状态

# 1.场景
- 服务向主数据写入成功，则向从数据库查询数据也成功

# 2. 实现
- 写入主数据库后，将数据同步到从数据库
- 在从主数据库向从数据库同步的时候，将从数据库锁定，待同步完成后再释放锁
- 避免在新数据写入成功后，在从数据库查到旧的数据

# 3. 分布式系统一致性的特点
- 存在数据同步的过程，写操作的响应会有一定的延迟
- 为了保证数据一致性会对资源暂时锁定，待数据同步完成后释放锁资源
- 如果请求数据同步的操作失败，从节点一定要返回错误信息，而不是旧数据

2. A-Avaliablity

• 任何事务操作，都可以得到响应结果，且不会出现响应超时或响应错误

# 1. 场景
- 从数据库接受到数据查询的请求后，立即响应数据查询结果
- 从数据库不允许出现响应超时或响应错误

# 2. 实现
- 写入主数据库后要将数据同步到从数据库
- 保证从数据库的可用性，不可将从数据库的资源进行锁定
- 即使数据还没同步过来，从数据库也要返回要查询的数据，哪怕是旧数据，
  如果旧数据都没有，则可以按照约定返回一个默认信息，但不能返回错误或响应超时

# 3. 分布式系统可用性
- 所有请求都有响应，且不会出现响应超时或响应错误

3. P - Partition tolerance

• 分布式系统各节点部署在不同子网，这就是网络分区
• 因为网络问题导致节点间通信失败，但此时仍然要对外提供服务，这叫分区容忍性

# 1. 场景
- 主数据库向从数据库同步数据失败，不影响读写操作
- 其中一个结点挂掉，不影响其他节点对外提供服务

# 2. 实现
- 尽量使用异步取代同步操作，节点间实现松耦合
- 添加从数据节点，其中一个从节点挂掉，其它从节点提供服务

# 3. 分布式分区容忍性特点
- 分区容忍性事分布式系统具备的基本能力

4. 组合方式

• 所有分布式事务场景中，不会同时具备CAP三个特性
• 因为在具备了P的条件下C和A是不能共存的

4.1 AP

• 放弃一致性，追求分区容忍性和可用性，这是很多分布式系统选择的
• 比如商品管理，允许用户查询到旧的数据(用户也明白存在时间差)

4.2 CP

• 放弃可用性，追求一致性和分区容忍性能
• 比如跨行转账

4.3 CA

• 放弃分区容忍性，即不进行分区，可以用单纯的关系型数据库解决
• 这就是放弃了分布式

三、Base理论

1. 强一致性和最终一致性

• 强一致性：CAP理论中的C
• 最终一致性：在保证A的时候，过一段时间，保证数据的C即可
• 有些场景可以不需要强一致性，但是可以使用最终一致性即可

2. Base理论

• Basically Avaliable：基本可用
• Soft state：软状态
• Eventually consistent: 最终一致性
• 是AP的一个扩展

通过牺牲强一致性来获得可用性，允许数据在一段时间内是不一致的
最终达到一致状态。满足Base理论的事务叫     柔性事务

基本可用：分布式系统故障时，允许损失部分可用功能，保证核心功能可见

软状态：不要求强一致性，所以允许出现中间状态(软状态)
       比如订单的‘支付中’，‘数据同步中’，数据一致后‘成功’

最终一致性： 经过一段时间后，所有节点数据都将达到一致
      比如‘支付成功’， ‘支付失败’，但需要一定时间延迟

四、两阶段提交

1. 理论

• 基于数据库的两阶段协议来进行支持的

1.1 准备阶段

• 事物管理器给每个参与者发送prepare消息，每个数据库参与者在本地执行事务，并写本地的undo/redo日志，此时事务没有提交

1.2 提交阶段

• 如果事务管理器收到了参与者的执行失败或者超时消息，直接给每个参与者发送回滚消息
• 否则，发送提交消息
• 参与者根据事务管理器的指令执行提交或者回滚操作，并释放事物处理过程中使用的锁资源
• 必须在最后阶段释放锁资源

2. XA方案

• 2pc的传统方案是在数据库层面实现的，如oracle，mysql都支持2pc协议
• 缺点：必须基于数据库的2px协议，两阶段模式需要加锁

DTP: Distributed Transancation Processing Reference Model
     - 分布式事务处理模型，包含3个角色

AP: Application Program，应用程序
   使用DTP分布式事务的程序

RM: Resource Manager， 资源管理器
    事务的参与者，如一个数据库实例，控制分支事务

TM: Transaction Manager， 事务管理器
    负责协调和管理事务，控制全局事务，协调各个RM 

1. XA： DTP模型定义TM和RM之间通过的接口规范。数据库提供的，基于2pc的借口协议
  1.1 TM向AP提供程序编程接口，AP通过TM提交及回滚事务
  1.2 TM交易中间件通过XA接口来通知RM数据库事务的开始，提交，结束，回滚等