跳到主要内容

前言

目前我们的系统架构一般都是分布式微服务架构，而在这种架构中，我们都知道，一个服务会调用不同的服务，例如，一个下单操作会涉及到多个服务，比如订单服务(进行新建订单操作)，库存服务(减库存)，账户服务(扣钱)，如果我们的库存不足或者余额不足，是不是就要回滚之前的操作

image.png

image.png

我们在分布式环境下，难以保证ACID特性

事务的ACID特性

  • 原子性

一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个阶段。

  • 一致性

一个事务的操作只能把数据库从某个一致性状态到另一种一致性状态，不能破坏数据库的完整性

  • 隔离性

允许多个事务对数据库进行并发修改并且不会影响数据最终的结果

  • 持久性

一个事务一但提交，那么修改是永久性的，即使数据库宕机，也不会丢失

分布式事务

分布式事务就是为了保证在分布式环境下，事务的ACID特性，因为我们看到上面的操作，订单服务，已经完成下订单的操作了并且已经入库了，而库存服务中，扣减库存失败了，这个时候需要回滚订单服务的操作，但是订单服务已经落库了，已经没办法去修改了。

分布式定理引入

我们知道在分布式环境下，保证CAP原则，那么什么是CAP原则呢？

CAP原则

C代表一致性也就是Consistency，A代表可用性也就是Availability，P代表分区容错性也就是Partition tolerance

一致性​

一致性指的是，对于不同的节点，我们请求得到的数据应该是相同的。

image.png

对于这么一个系统，我们想要修改count的时候，肯定只发送一个请求，那么这个请求也只能打到一个服务器上，也就是node1或者node2

假如这个请求打到了node2上，那么此时node2中的count则变为2

image.png

我们发现count修改后两个node上的数据不一致了，如果想要保证一致性，那么就要进行数据同步！

image.png

可用性​

可用性指的是访问任意一个健康节点必须进行一个响应，只有访问不健康节点的时候，才会返回超时或者拒绝

分区容错性​

分区容错性指的是可能由于网络原因或者其他原因分布式系统部分节点与其他节点之间失去连接，形成了一个独立的分区，在这种分区的情况下，依然会对外进行服务

image.png

分布式系统中，我们不能保证所有的网络都是健康的，所以出现分区是很正常的情况，我们必须要保证分区容错性

BASE理论

BASE理论指的是Basically Available(基本可用)，Soft State(软状态),Eventually Consistent(最终一致性)

其实BASE理论是对CAP原则的一种解决方案

  • 基本可用

允许损失部分可用性，保证核心可用

  • 软状态

在一定时间内，允许出现中间态，例如临时数据不一致状态

  • 最终一致性

软状态结束之后，必须要保证最终一致性，也就是最终数据一致性

分布式事务最大的问题就是一个大事务中各个子事务一致性的问题，这样我们可以利用一个事务协调者

简单来说就是通过事务协调者作为一个全局事务来保证事务的ACID性，因为我们调用一个有一个服务其实就类似于一个又一个子事务，我们知道事务中，如果有一个失败那么全部都会回滚，利用全局事务来保证分布式事务的ACID性即可完成

image.png

我们如果想要在项目中使用分布式事务，就不得不提到Seata，Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务，Seata 提供了 AT、TCC、SAGA 和 XA 事务模式，这里就不在对于Seata去讲解，详情可以去官网了解