分布式事务

分布式事务

事务的特性：A原子性、C一致性、I隔离性、D持久性

事务的隔离级别：读未提交、读已提交、可重复读、串行化

刚性事务的ACID是作用在同一个数据库上，多个数据库上无效

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上,且属于不同的应用，分布式事务需要保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

CAP

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

一致性——Consistency

一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意结点读取到的数据都是最新的状态。

例如：

1、商品服务写入主数据库成功，则向从数据库查询新数据也成功。

2、商品服务写入主数据库失败，则向从数据库查询新数据也失败。

如何实现一致性？

1、写入主数据库后要将数据同步到从数据库。

2、写入主数据库后，在向从数据库同步期间要将从数据库锁定，待同步完成后再释放锁，以免在新数据写入成功后，向从数据库查询到旧的数据。

分布式系统一致性的特点：

1、由于存在数据同步的过程，写操作的响应会有一定的延迟。

2、为了保证数据一致性会对资源暂时锁定，待数据同步完成释放锁定资源。

3、如果请求数据同步失败的结点则会返回错误信息，一定不会返回旧数据。

可用性——Availability

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

1、从数据库接收到数据查询的请求则立即能够响应数据查询结果。

2、从数据库不允许出现响应超时或响应错误。

如何实现可用性？

1、写入主数据库后要将数据同步到从数据库。

2、由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定。

3、即时数据还没有同步过来，从数据库也要返回要查询的数据，哪怕是旧数据，如果连旧数据也没有则可以按照约定返回一个默认信息，但不能返回错误或响应超时。

分布式系统可用性的特点：

所有请求都有响应，且不会出现响应超时或响应错误。

分区容忍性——Partition tolerance ：

通常分布式系统的各个结点部署在不同的子网，这就是网络分区，不可避免的会出现由于网络问题而导致结点之间通信失败，此时仍可对外提供服务，这叫分区容忍性。

1、主数据库向从数据库同步数据失败不影响读写操作。

2、其一个结点挂掉不影响另一个结点对外提供服务。

如何实现分区容忍性？

1、尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据库，这样结点之间能有效的实现松耦合。

2、添加从数据库结点，其中一个从结点挂掉，其它从结点提供服务。

分布式分区容忍性的特点：

分区容忍性分是布式系统具备的基本能力。

CAP组合方式

由于一致性和可用性相互矛盾，但只要确保最终一致性即可，所以分为以下几种方式：

AP

放弃一致性，追求分区容忍性和可用性。这是很多分布式系统设计时的选择。

例如商品管理，完全可以实现AP。订单退款，今日退款成功，明日账户到账。前提是只要用户可以接受所查询的到数据在一定时间内不是最新的。

CP

放弃可用性，追求一致性和分区容错性。比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。

CA

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

分布式事务的解决办法

二阶段提交——2PC

保证强一致性

数据库层面的分布式事务场景

2PC 引入一个事务协调者的角色来协调管理各参与者（也可称之为各本地资源）的提交和回滚。

二阶段分别指的是准备（投票）和提交两个阶段。

• 准备阶段：协调者会给各参与者发送准备命令，此阶段除了提交事务之外啥事都做完了。
• 提交阶段：同步等待所有资源的相应之后进入第二阶段（回滚事务或者提交事务）
  • 假如在第一阶段所有参与者都返回准备成功，那么协调者则向所有参与者发送提交事务命令，然后等待所有事务都提交成功之后，返回事务执行成功。
  • 假如在第一阶段有一个参与者返回失败，那么协调者就会向所有参与者发送回滚事务的请求，即分布式事务执行失败。
  • 首先 2PC 是一个同步阻塞协议，像第一阶段协调者会等待所有参与者响应才会进行下一步操作，当然第一阶段的协调者有超时机制，假设因为网络原因没有收到某参与者的响应或某参与者挂了，那么超时后就会判断事务失败，向所有参与者发送回滚命令。
  • 在第二阶段协调者的没法超时，因为只能不断重试。

如果协调者故障，则选择新的协调者：事务管理器序列化之后，传给下一个协调者，由下一个协调者继续执行。

三阶段提交——3PC

兼顾可用性，引入了资源的提交阶段

3PC 包含了三个阶段，分别是准备阶段、预提交阶段和提交阶段，对应的英文就是：CanCommit、PreCommit 和 DoCommit。将 2PC 的提交阶段变成了预提交阶段和提交阶段

3PC 的阶段变更影响：

首先准备阶段的变更成不会直接执行事务，而是会先去询问此时的参与者是否有条件接这个事务，因此不会一来就干活直接锁资源，使得在某些资源不可用的情况下所有参与者都阻塞着。

而预提交阶段的引入起到了一个统一状态的作用，它像一道栅栏，表明在预提交阶段前所有参与者其实还未都回应，在预处理阶段表明所有参与者都已经回应了。

假如你是一位参与者，你知道自己进入了预提交状态那你就可以推断出来其他参与者也都进入了预提交状态。

但是多引入一个阶段也多一个交互，因此性能会差一些，而且绝大部分的情况下资源应该都是可用的，这样等于每次明知可用执行还得询问一次。

我们再来看下参与者超时能带来什么样的影响。

我们知道 2PC 是同步阻塞的，上面我们已经分析了协调者挂在了提交请求还未发出去的时候是最伤的，所有参与者都已经锁定资源并且阻塞等待着。

那么引入了超时机制，参与者就不会傻等了，如果是等待提交命令超时，那么参与者就会提交事务了，因为都到了这一阶段了大概率是提交的，如果是等待预提交命令超时，那该干啥就干啥了，反正本来啥也没干。

然而超时机制也会带来数据不一致的问题，比如在等待提交命令时候超时了，参与者默认执行的是提交事务操作，但是有可能执行的是回滚操作，这样一来数据就不一致了。

TCC

2PC 和 3PC 都是数据库层面的，而 TCC 是业务层面的分布式事务，就像我前面说的分布式事务不仅仅包括数据库的操作，还包括发送短信等，这时候 TCC 就派上用场了！

TCC 指的是Try - Confirm - Cancel。

• Try 指的是预留，即资源的预留和锁定，注意是预留。
• Confirm 指的是确认操作，这一步其实就是真正的执行了。
• Cancel 指的是撤销操作，可以理解为把预留阶段的动作撤销了。

将非事务异常纳入到回滚条件中，比如用户点击取消

对业务侵入性比较大

操作幂等性：多次执行得到的结果是一致的。例如，付款时卡住了，一直点击支付，需要保证点击多次还是支付一次。

撤销和确认的操作，要保证重试

本文转载博文

https://blog.youkuaiyun.com/weixin_44062339/article/details/99710968?ops_request_misc=&request_id=&biz_id=102&utm_term=CAP%20%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1&utm_medium=distribute.pc_search_result.none-task-blog-2_allsobaiduweb~default-2-99710968.nonecase&spm=1018.2226.3001.4187

https://zhuanlan.zhihu.com/p/183753774