分布式事务

2024-08-06 15:14:14 浏览数 (2)

分布式事务

前言：

  • 本篇学习借鉴了以下文章： 感谢大佬 https://blog.csdn.net/bjweimengshu/article/details/79607522 https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html https://www.cnblogs.com/monkeyblog/p/10449363.html 当然这里绝对不是打广告！ 而且，我看的可不止这么多，这个是我看的比较好的… 为了方便我后面自己忘记了可以回顾的。
  • 本篇，存在一些大佬的文章搬运，主要是写的太好了，copy来了… 如果大佬不允许会及时删除！

什么是事务

举个生活中的例子：

  • 你去小卖铺买东西，“一手交钱，一手交货”就是一个事务的例子
  • 交钱和交货 必须全部成功，事务才算成功任一个活动失败，事务将撤销所有已成功的活动。
  • 事务可以看做是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败。
数据库事务的四大特性 ACID：

A（Atomic）：原子性

  • 构成事务的所有操作，要么都执行完成，要么全部不执行，不可能出现部分成功部分失败的情况。

C（Consistency）：一致性

  • 在事务执行前后，数据库的一致性约束没有被破坏。
  • 比如 张三100元 ，李四100元，一共200。 李四给张三50 李四50元， 张三150元，一共还是200元！

I（Isolation）：隔离性

  • 数据库中的事务一般都是并发的，
  • 隔离性是指并发的两个事务的执行互不干扰，一个事务不能看到其他事务运行过程的中间状态。
  • 通过配置事务隔离级别可以避脏读、重复读等问题

D（Durability）：持久性

  • 事务完成之后，该事务对数据的更改会被持久化到数据库，且不会被回滚

本地事务 Local Transaction

  • 起初，事务仅限于对单一数据库资源的访问控制 架构服务化以后，事务的概念延伸到了服务中。
  • 倘若将一个单一的服务操作作为一个事务，那么整个服务操作只能涉及一个单一的数据库资源。
  • 这类基于单个服务单一数据库资源访问的事务，被称为**本地事务**

分布式事务 | 产生的场景

  • 随着互联网的快速发展，软件系统由原来的 单体应用 转变 为**分布式应用**
  • 分布式系统会把一个应用系统拆分为可独立部署的多个服务，不同的服务还会有不同的库 因此需要服务与服务之间远程协作才能完成事务操作
  • 这种分布式系统环境下**由不同的服务之间通过网络远程协作，在不同的数据库之间，完成事务**称之为分布式事务
单一服务分布式事务
  • 最早的分布式事务应用架构很简单
  • 不涉及服务间的访问调用，仅仅是服务内操作涉及到对多个数据库资源的访问。
多服务分布式事务
  • 一个服务操作访问不同的数据库资源 对于上面介绍的分布式事务应用架构，尽管一个服务操作会访问多个数据库资源，但是毕竟整个事务还是控制在单一服务的内部。
  • 一个服务操作需要调用另外一个服务，**这时的事务就需要跨越多个服务了**
多服务多数据源分布式事务
  • 在多个服务之间，且不同服务存在不同的数据库，的环境下的分布式事务 好牛啊！

事务的作用：

保证每个事务的数据一致性。

分布式事务基础理论

CAP理论

理解CAP
  • CAP是 Consistency、Availability、Partition tolerance三个词语的缩写分别表示：一致性、可用性、分区容忍性

C (一致性)

  • 一致性是指: 写操作后的 读操作可以**读取到最新的数据状态** 实时更新！
  • 对于数据分布在不同节点上的数据来说 如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为 强一致 如果有某个节点没有读取到，那就是 分布式不一致

A (可用性)

  • 可用性，就是提高程序的高可用… 提高安全… 类似于搭建 集群，一个服务挂了，其它服务继续工作不影响使用！，但这必然影响了C一致性的性能速度！
  • 但注意，可用行 会导致 一致性的效率，但也要保证 最终一致性 这是事务必须的！ 非故障的节点在合理的时间内返回合理的响应 　(不是错误和超时的响应)
  • 所以分布式系统理论上不可能选择 CA 架构, 只能选择 CP 或者 AP 架构。

P (分区容错性)

  • 分布式系统的各各结点部署在不同的子网，这就是**网络分区 不可避免的会出现由于网络问题而导致结点之间通信失败，此时仍可对外提供服务，这叫**分区容忍性
  • 如何实现分区容忍性？ 尽量使用异步取代同步操作 　例如使用异步方式将数据从主数据库同步到从数据，这样结点之间能有效的实现 松耦合。 添加从数据库结点，其中一个从结点挂掉其它从结点提供服务。
  • 分布式分区容忍性的特点： 分区容忍性分是布式系统具备的基本能力。

CAP有哪些组合方式呢？

AP：

  • 放弃一致性，追求分区容忍性和可用性。
  • 例如： 商品管理，完全可以实现AP，前提是只要用户可以接受所查询的到数据在一定时间内不是最新的即可。 一些业务场景比如： 订单退款，今日退款成功，明日账户到账，只要用户可以接受在一定时间内到账即可。

CP:

  • 放弃可用性，追求一致性和分区容错性，我们的zookeeper其实就是追求的强一致
  • 一些业务场景比如： 抢购商品 秒杀！

CA：

  • 放弃分区容忍性，即不进行分区，不考虑由于网络不通或结点挂掉的问题，则可以实现一致性和可用性。
  • 那么系统将不是一个标准的分布式系统，我们最常用的 关系型数据就满足了CA
面试题：ZooKeeper 和 eureka 的区别
  • ZooKeeper 是 cp eureka 是ap 的架构….

总结

  • CAP理论告诉我们一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍 性（Partition tolerance）这三项中的两项.
  • 在实际生产中很多场景都要实现一致性 比如我们举的例子：主数据库向从数据库同步数据，即使不要一致性，但是最终也要将数据同步成功来保证数据一致
  • 其中AP在实际应用中较多，AP即舍弃一致性，保证可用性和分区容忍性

BASE理论

  • BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。
  • BASE理论是对CAP中AP的一个扩展，通过牺牲强一致性来获得可用性 当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。
  • 满足BASE理论的事务，我们称之为 “柔性事务”
基本可用:
  • 分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
  • 如，电商网站交易付款出现问题了，商品依然可以正常浏览。
软状态:
  • 由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态）
  • 这个状态不影响系统可用性，如订单的"支付中"、“数据同步中”等状态，待数据最终一致后状态改为“成功”状态。
最终一致:
  • 最终一致是指经过一段时间后，所有节点数据都将会达到一致。 如订单的"支付中"状态，最终会变为“支付成功”或者"支付失败"， 使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。

分布式事务解决方案

XA分布式事务协议

  • 分布式事务常见的解决方案有：**2pc传统方案** 2PC的传统方案是在数据库层面实现的，如Oracle、MySQL都支持2PC协议
  • 为了统一标准减少行业内不必要的对接成本，需要制定标准化的处理模型及接口标准
  • 国际开放标准组织**Open Group 定义了 分布式事务处理模型 DTP** Distributed Transaction Processing Reference Model

DTP模型

DTP模型定义如下角色：

  • AP(Application Program)：即应用程序，可以理解为使用DTP分布式事务的程序。
  • RM(Resource Manager)：即资源管理器 可以理解为事务的参与者，一般情况下是指一个数据库实例， 通过资源管理器对该数据库进行控制，资源管理器控制着分支事务。
  • TM(Transaction Manager)：事务管理器 负责协调和管理事务，事务管理器控制着全局事务，管理事务生命周期，并协调各个RM。 全局事务 是指分布式事务处理环境中，需要操作多个数据库共同完成一个工作，这个工作即是一个全局事务。

基于XA协议的两阶段提交(2PC)

两阶段提交协议 Two Phase Commitment Protocol 涉及到两种角色

  • 一个**事务协调者（coordinator）** TM事务管理器 负责协调多个参与者进行事务投票及提交(回滚)
  • 多个**事务参与者（participants）** RM资源管理器 即本地事务执行者

总共处理步骤有两个

  • 投票阶段**（voting phase） 参与者操作 协调者将通知，事务参与者 准备提交或取消事务，然后进入表决过程投票阶段参与者将告知协调者自己的决策** true： 事务参与者，本地事务执行成功,但未提交 flase： 本地事务执行故障
  • 提交阶段**（commit phase） 协调者操作 收到参与者的通知后，协调者再向参与者发出通知，根据反馈**投票**情况决定，各参与者是否要提交还是回滚 多个参与者，只要有一个false , 就表示事务执行失败，通知所有的参与者未提交的事务进行回滚！**
2PC总结：
  • 整个2PC的事务流程涉及到三个角色AP、RM、TM。
  • AP指的是使用2PC分布式事务的应用程序；
  • RM指的是资源管理器，它控制着分支事务；
  • TM指的是事务管理器，它控制着整个全局事务。

缺点：

  • 在 投票阶段**，RM执行实际的业务操作，但不提交事务，**资源锁定
  • 协调者单点故障问题 3PC阶段解此问题！ 事务协调者是整个XA模型的核心， 一旦事务协调者节点挂掉，参与者收不到提交或是回滚通知。参与者会一直处于中间状态无法完成事务。
  • 丢失消息导致的不一致问题。 在XA协议的第二个阶段，如果发生局部网络问题，一部分事务参与者收到了提交消息 另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致…!!

Seata 实现2PC

Seata方案
  • Seata是由阿里中间件团队发起的开源项目 Fescar， 后更名为Seata Simple Extensible Autonomous Transaction Architecture 一套一站式分布式事务解决方案。

解决分布式事务问题，有两个设计初衷

  • 对业务无侵入 即减少技术架构上的微服务化所带来的分布式事务问题对业务的侵入，实际开发中只要一个注解就搞定了！**@Configuration**
  • 高性能 减少分布式事务解决方案所带来的性能消耗，添加 undo_log 表，**本地放心提交事务，可以依靠undo_log进行回滚处理..**

seata中有两种分布式事务实现方案：**AT** 及**TCC**