事务

参考文章

什么是事务

事务是有一组操作构成，要么全部正确执行，要么全部不执行

四大特性 ACID

• 原子性 Atomicity
  • 事务所有操作组成一个原子包，要么全部成功，要么全部失败。
• 一致性 Consistency
  • 事务开始和结束后，数据库的完整性约束没有被破坏。
• 隔离性 Isolation
  • 事务的执行是相互独立的，互不干扰，一个事务不会看到另一个正在运行过程中事务的数据
• 持久性 Durability
  • 一个事务执行结果必须是持久化保存的。

隔离级别

分布式事务

现在一个大型业务系统由多个子系统构成，子系统又各自拥有自己的数据库。因此，我们需要再数据库之上通过某种手段，实现跨数据库的事务支持。就是分布式事务。

CAP理论

在一个分布式系统中，最多只能满足C、A、P中的两个需求。

CAP:

• C:consistency 一致性
  • 同一数据的多个副本是否实时相同
• A:Availability 可用性
  • 一定时间内，系统返回一个明确的结果，则称该系统可用。
• P: partition tolerance 分区容错性
  • 将统一服务分布在多个系统中，从而保证某一个系统宕机，仍然有其他系统提供相同的服务。

对于一个系统来说，可用性和分区容错性是必须满足的两个条件。所以只能通过牺牲一致性来换取系统的可用性和分区容错性。这就是BASE理论

BASE

所谓牺牲一致性，不是放弃数据一致性，而是牺牲强一致性，换取弱一致性。

• BA basic available 基本可用
  • 基本可用和高可用的区别：
    • 响应时间可以适当延长
    • 给部分用户一个降级页面，降级页面仍然是返回明确的结果
• S soft state
  • 同一数据的不同副本的状态，可以不需要实时一致
• E eventual Consisstency 最终一致性
  • 同一数据的不同副本的状态，可以不需要实时一致，但一定要保证最后仍是一致的。

协议

• 2PC 两阶段提交协议
• 3PC 三阶段提交协议

2PC

算法思路：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情况决定各参与者是否要提交操作还是中止操作。

• 第一阶段 投票阶段
• 第二阶段 提交执行阶段

问题：

• 同步阻塞
• 单点故障
• 数据不一致
  • 只有一部门参与者收到commit请求

所以有了3PC

3PC

有两个改动

• 引入超时机制
  • 同时在协调者和参与者中引入超时机制
• 在第一和第二阶段中插入一个准备阶段
  • 保证了在最后提交阶段之前各个参与节点的状态是一致的。

3pc把2pc的准备阶段一分为二，三阶段就是 CanCommit PreCommit DoCommit三个阶段

但是都不能解决一致性的问题 所以有了Paxos算法。

解决方案

• 全局消息
• 基于可靠消息服务的分布式事务
• TCC
• 最大努力通知

消息服务的分布式事务

假设A和B 两个系统，分别处理任务A和任务B 现在要求AB需要在同一个事务中处理

[图片上传失败...(image-380cf3-1534841679092)]

• 任务A处理完成之后，向消息中间件发送Commit请求。该请求发送完成后，对系统A而言,该事务的处理过程就介绍了，此时它可以处理别的任务了。
  • 这个时候 可能会出现投递消息时，消息丢失，从而系统会出现不一致。消息中间件有事务的回查机制。

如果A处理失败，需要进行回滚操作

[图片上传失败...(image-87b8db-1534841679092)]

此时系统又处于一致性状态，因为A和B都没有执行

但是在实际系统中，Commit和Rollback指令都有可能在传输途中丢失。如何保证数据一致性能?----那就是超时询问机制
[图片上传失败...(image-b24769-1534841679092)]

• 超时询问机制
  • 系统A出了实现正常的业务流程外，还需要提供一个事务询问接口，供消息中间件调用。
  • 当消息中间件收到消息后开始计时，如果超过时间也没收到A发来的Commit或者Rollback指令，会主动调用系统A提供的事务询问接口询问该系统目前的状态，接口会返回三种结果：
    • 提交 把该消息投递给系统B
    • 回滚 直接丢弃该消息
    • 处理中 继续等待

1 防止上游系统指令丢失而导致的不一致情况 2 可以大大降低上游系统的阻塞时间，提升系统并发度。

消息可靠性保证

• 当上游系统向消息中间件提交了Commit指令后，便可以处理其他任务了。
• 接下来消息中间件 一定会保证消息被下游系统成功消费掉！！

流程

1. 消息中间件向下游系统投递消息之后，进入阻塞等待状态
2. 下游系统处理完成，返回应答
3. 消息中间件收到确认应答后认为事务处理完毕

重试机制

• 如果消息在投递或者应答途中丢失，会进行重试，重试一定次数之后会放入异常队列。

这里为什么不回滚？
如果回滚，就需要系统A提供回滚接口，增加了开发成本，业务复杂度也提高了。

为什么上游系统和下游系统的设计不一样？

• 上游是提交指令之后，就处理别的事情。
• 下游确实阻塞等待

因为上游系统知己诶和用户打交道。异步可以大大降低用户等待时间。提高并发。

最大努力通知（定期校对）

[图片上传失败...(image-8fd94a-1534841679092)]

在上面能方法，会有重试机制，重试上限之后仍失败，会记录在失败消息表中。消息中间件需要提供失败消息的查询接口，下游系统会定期查询失败信息，并将其消费。就是所谓的定期校对。

如果重复投递和定期校对都不能解决问题，那就需要人工干预了。

所以尽量选择支持事务型的消息中间件来实现分布式事务，如RocketMQ

TCC

Try Confirm Cancel 属于补偿性分布式事务

• Try 尝试待执行的业务
  • 完成业务的一致性检查，预留好执行任务所需的资源
• Confirm 执行业务
• Cancel 取消执行的业务

TCC全局事务必须基于RM本地事务来实现全局事务

RM Resource Manager资源管理器

TCC事务框架应该提供Confirm/Cancel服务的幂等性保障

幂等性：针对统一服务的多次请求和单次请求，二者具有相同的副作用。

在TCC事务模型中，Confirm、Cancel会被反复调用。

TCC和2pc协议比较

• 位于业务层 而非资源层
• 没有单独的准备阶段，Try操作兼具资源操作与准备的能力
• Try操作可以灵活选择业务资源的锁定粒度
• 较高的开发成本（）

TCC和XA对比分析

XA 模型另外一个意义在于其普适性，抛开性能问题的情况下，几乎可以适用于所有业务模式，这对于一些基础性的技术产品来说是非常有用的，比如分布式数据库、云服务的分布式事务框架等。

TCC 模型除了跨服务的分布式事务这一层作用之外，还具有两阶段划分的功能，通过业务资源锁定，允许第二阶段的异步执行，而异步化思想正是解决热点数据并发性能问题的利器之一。