分布式事务：基础理论

分布式事务：基础理论

一、本地事务

事务可以看作是一次大的活动，它由不同的小活动组成，这些活动要么全部成功，要么全部失败。

而在计算机系统种，更多的是通过关系型数据库来控制事务，这是利用数据库本身的事务特性来实现的，这种基于关系型数据库的事务被称为本地事务。

为什么需要本地事务呢？

事务问题一般都会拿转账来举例子。假如 A 账户 转账 100元给 B 账户。站在用户角度来看，这是一个单一的逻辑，而在关系型数据库中，至少要分成两个步骤来完成：

• 将 A 账户的存款减少 100元

• 将 B 账户的存款增加 100 元

而本地事务即数据库事务的目的就是保证这两个步骤要么同时全部成功，要么全部失败。

当数据库操作失败或者系统出现崩溃的时候，系统能够以事务来进行恢复，保证数据库状态的一致性。

回顾数据库事务的四大特性 ACID ：

• 原子性(Atomicity): 事务中的所有操作作为一个整体像原子一样不可分割，要么全部成功,要么全部失败。

• 一致性(Consistency): 事务的执行结果必须使数据库从一个一致性状态到另一个一致性状态。

  • 一致性状态是指:

    • 1.系统的状态满足数据的完整性约束(主码,参照完整性,check约束等)

    • 2.系统的状态反应数据库本应描述的现实世界的真实状态,比如转账前后两个账户的金额总和应该保持不变。

• 隔离性(Isolation) : 并发执行的事务不会相互影响,其对数据库的影响和它们串行执行时一样。比如多个用户同时往一个账户转账,最后账户的结果应该和他们按先后次序转账的结果一样。

• 持久性(Durability) : 事务一旦提交,其对数据库的更新就是持久的。任何事务或系统故障都不会导致数据丢失。

  

• 事务的并发读问题：

  • 脏读：读取到另一个事务未提交数据；

  • 不可重复读：两次读取不一致；

  • 幻读（虚读）：读到另一事务已提交数据。

  四大隔离级别：在相同的数据环境下，使用相同的输入，执行相同的工作根据不同的隔离级别，可以导致不同的结果。

  • SERIALIZABLE（序列化）

    不会出现任何并发问题，因为它是对同一数据的访问是串行的，非并发访问的；

    性能最差；最高级别

  • REPEATABLE READ（可重复读）（MySQL）

    防止脏读和不可重复读，不能处理幻读问题；

    性能比SERIALIZABLE好

  • READ COMMITTED（读已提交数据）（Oracle）

    防止脏读，没有处理不可重复读，也没有处理幻读；

    性能比REPEATABLE READ好

  • READ UNCOMMITTED（读未提交数据）

    可能出现任何事务并发问题 性能最好，级别最低

  二、分布式事务

  2.1 为什么要用分布式事务

  随着互联网的快速发展，软件系统由原来的单体应用转变为分布式应用。

  分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成的事务称为分布式事务。

  例如创建订单和扣减库存，这就是分布式事务。

  在分布式服务中，订单服务和库存服务不再同一个服务，在创建订单之后，再调用扣减库存服务。但是因为网络问题的存在，扣减库存成功了，但是如果远程调用超时了，那么创建订单也会回滚，因为它长时间接收不到返回的消息，但扣减库存确扣掉了，这就是本地事务回滚做不到的地方，因此，需要采用分布式事务。

  2.2 应用场景

  1、分布式事务典型的场景就是微服务架构。（跨 JVM）

  微服务之间通过远程调用完成事务操作，这种产生的原因就是跨JVM 进程产生的分布式事务，

  2、单体系统访问多个数据库实例。（跨数据库实例产生分布式事务）

  当单体系统访问多个数据库实例就会产生分布式事务。

  比如：用户信息和订单信息分别在两个 MYSQL 实例存储，用户管理系统删除用户信息及用户的订单信息，由于数据分布在不同的数据实例，需要通过不同的数据库链接去操作数据，此时产生分布式事务。

  3、多个服务访问单个数据库实例。（跨 JVM）

  会因为网络传输问题会造成数据的不一致性。

  三、分布式事务基础理论

  分布式事务之所以叫分布式事务，它是为了解决分布式系统中因为提供服务的节点分布在不同机器上，相互之间通过网络交互产生的事务问题，不能因为一点网络问题就导致整改系统无法提供服务，网络因素成为了分布式事务的考量标准之一。因此，分布式事务需要了解一些理论知识，从而帮助我们理解每个解决方案。

  3.1 CAP 理论

  CAP 理论是分布式存储的理论基石，三个字母是三个单词的缩写

  • C : Consistent ，一致性

  • A ： Availablity，可用性

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

  • P ： Partition tolerance，分区容忍性。

    • 分区容错的意思是，区间通信可能失败。比如，一台服务器放在上海，另一台服务器放在北京，这就是两个区，它们之间可能因网络问题无法通信。容忍的意思是虽然两个分区的通信失败了，但仍然能对外提供服务。

  分布式系统的节点往往都是分布在不同的机器进行网络隔离的，意味着随时都具备网络断开的风险，一旦断开就被称为 网络分区。

  在网络分区时，两个分布式节点无法进行通信，对其中的一个节点进行的修改操作将无法同步到另外一个节点上，所以数据的一致性将无法满足。

  除非牺牲可用性，在网络断开的时候不再提供修改数据的服务，直到网络恢复才恢复。

  组合方式思考：

  • 怎样才能同时满足CA？ 除非是单点架构

  • 何时要满足CP？ 对一致性要求高的场景。例如我们的Zookeeper就是这样的，在服务节点间数据同步时，服务对外不可用。

  • 何时满足AP？ 对可用性要求较高的场景。例如Eureka，必须保证注册中心随时可用，不然拉取不到服务就可能出问题。这是很多分布式系统设计的选择，通常实现 AP 都会保证最终一致性。

  总结：

  • CAP 理论就是当网络分区的时候，一致性和可用性不可兼得。

  • 一般组合方式选用 AP，舍弃 C 强一致性，保证最终一致性。

  3.2 BASE 理论

  3.2.1 理解强一致性和最终一致性

  CAP 理论告诉我们一个分布式系统最多只能满足 CAP 的某两项。其中 AP 在实际应用中较多，AP 舍弃一致性，保证可用性和分区容忍性，但是在实际生成中也有很多场景都要实现一致性，比如 主数据库向从数据库同步数据，即时不需要一致性，但是也要保证数据同步成功来保证数据最终一致性。即最终一致性它允许可以在一段时间内每个结点的数据不一致，但是经过一段时间每个结点的数据必须一致，即最终一致性。

  3.2.2 Base 理论介绍

  BASE 是 Basically Available（基本可用）、Soft state （软状态）和 Eventually consistent（最终一致性）三个短语的缩写。

  BASE 理论是对 CAP 中 AP 的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到抑制状态。满足 BASE 理论的事务，我们称为 “柔性事务”。

  • 基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如掘金平台发布文章出现问题，但是文章依旧可用正常浏览。

  • 软状态：由于不要求强一致性，所以 BASE 允许系统中存在中间状态（软状态），这个状态不影响系统可用性。例如导出 excel 的正在导出功能。待全部导出后将最终一致性的状态改为成功状态。

  • 最终一致：最终一致是指经过一段时间后，所有节点数据都将达到一致。如订单的“支付中”状态。

  小结

  分布式事务是指事务的参与者，支持事务的服务器，资源服务器分别位于分布式系统的不同节点之上，通常一个分布式事物中会涉及到对多个数据源或业务系统的操作。在后面我将

[转自：分布式事务: 基础理论]