分布式理论（一）

1 关于分布式事务

1.1 本地事务

1.1.1 事务的概念

事务指逻辑上的一组操作，组成这组操作的各个单元，要么全部成功，要么全部不成功。从而确保了数据的准确与安全。

 

1.1.2 事务的四大特性

 

1 ）原子性（ Atomicity ）

原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。

2 ）一致性（ Consistency ）

事务必须使数据库从一个一致性状态变换到另外一个一致性状态。

例如转账前 A 有 1000 ， B 有 1000 。转账后 A+B 也得是 2000 。

3 ）隔离性（ Isolation ）

事务的隔离性是多个用户并发访问数据库时，数据库为每一个用户开启的事务，每个事务不能被其他事务的操作数据所干扰，多个并发事务之间要相互隔离。

 

4 ）持久性（ Durability ）

 

持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对 其有任何影响。

1.1.3 事务的隔离级别

1 ）不考虑隔离级别，会出现以下情况：（以下情况全是错误的）

脏读：一个线程中的事务读到了另外一个线程中未提交的数据。

不可重复读：一个线程中的事务读到了另外一个线程中已经提交的 update 的数据（前后内容不一样）

虚读（幻读）：一个线程中的事务读到了另外一个线程中已经提交的 insert 的数据（前后条数不一样）

2 ）数据库共定义了四种隔离级别：

Serializable ：可避免脏读、不可重复读、虚读情况的发生。（串行化） 最高

Repeatable read ：可避免脏读、不可重复读情况的发生。 ( 有可能发生幻读 ) 第二

Read committed ：可避免脏读情况发生。 第三

Read uncommitted ：最低级别，以上情况均无法保证。 ( 读未提交 ) 最低

注意：级别依次升高，效率依次降低

MySQL 的默认隔离级别是： REPEATABLE READ 。（ Oracle 的默认是： READ COMMITTED ）

 

1.1.4 随着系统架构的变化本地事务的问题

 

在 dubbo 官方网址 上提供了一个系统架构的演变图，它里面展示了从单体架构到 SOA 架构的演变：

当我们的项目架构不再是 All in One 时，那么我们的数据库也可能面临着单一数据库不够用的情况。当我们部署了多台数据库之后，新的问题就产生了，由于每台数据库都有独立的本地事务，且事务的隔离性确定了事务之间不能相互打扰。所以，在多数据库下，事务该如何控制呢？

1.2 分布式事务

 

1.2.1 分布式事务的概念

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同 节点之上。简单来说就是组成事务的各个单元处于不同数据库服务器上。

相信大家都接触过这种场景，手机支付，付款方和收款方的银行账号不是同一家一行，不在同一地域的情况。那 么，我们就要保证付款方减去的金额，和收款方增加的金额保持一致。

在我们的实际开发中，分布式事务无处不在，比如，电商系统中的生成订单，账户扣款，减少库存，增加会员积分 等等，他们就是组成事务的各个单元，它们要么全部发生，要么全部不发生，从而保证最终一致，数据准确。

1.2.2 分布式事务的应用架构

1 ）单一服务不同数据库架构

2 ）单一服务分库分表架构

 

3 ）多服务不同数据库库架构

 

1.2.3 分布式事务的解决方案分类

1 ）刚性事务

刚性事务指的就是遵循本地事务四大特性（ ACID) 的强一致性事务。它的特点就是强一致性，要求组成事务的各个 单元马上提交或者马上回滚，没有时间弹性，要求以同步的方式执行。通常在单体架构项目中应用较多，一般都是 企业级应用（或者局域网应用）。例如：生成合同时记录日志，付款成功后生成凭据等等。但是，在时下流行的互 联网项目中，这种刚性事务来解决分布式事务就会有很多的弊端。其中最明显的或者说最致命的就是性能问题。如 下图所示：

因为某个参与者不能自己提交事务，必须等待所有参与者执行 OK 了之后，一起提交事务，那么事务锁住的时间就 变得非常长，从而导致性能非常低下。基于此我们也就得出了一个结论，阶段越多，性能越差。

2 ）柔性事务

柔性事务是针对刚性事务而说的，我们刚才分析了刚性事务，它有两个特点，第一个强一致性，第二个近实时性 （NRT ）。而柔性事务的特点是不需要立刻马上执行（同步性），且不需要强一致性。它只要满足基本可用和最终 一致就可以了。要想真正的明白，需要从BASE 理论和 CAP 理论说起。

1.2.4 CAP理论和BASE理论

1 ） CAP 理论

CAP 理论，又叫做 CAP 原则，网上对他的概念描述非常的清晰，且一致。换句话说，我们在网上搜到的 CAP 理论的

描述，基本都是一样的。它的描述是这样的：

CAP 指的是在一个分布式系统中，一致性（ Consistency ）、可用性（ Availability ）、分区容错性（ Partition tolerance）。其中， C,A,P 的说明如下：

一致性（ C ）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的 数据副本）

可用性（ A ）：在集群中一部分节点故障后，集群整体是否还能响应客户端 ] 的读写请求（对数据更新具备高可用 性）

分区容错性（ P ）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C 和 A 之间做出选择。

CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出 取舍。而对于分布式数据系统，分区容错性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一 致性和可用性之间取一个平衡。对于大多数web 应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性， 是目前多数分布式数据库产品的方向。

 

2 ） BASE 理论

BASE 理论是指， Basically Available （基本可用）、 Soft-state （ 软状态 / 柔性事务）、 Eventual Consistency （最 终一致性）。

1 、基本可用 BA ：（ Basically Available ）：

指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。但不等价于不可用。比如：搜索引擎 0.5 秒返回查询结果，但由于故障，2 秒响应查询结果；网页访问过大时，部分用户提供降级服务等。简单来说就是基 本可用。

2 、软状态 S ：（ Soft State ）：

软状态是指允许系统存在中间状态，并且该中间状态不会影响系统整体可用性。即允许系统在不同节点间副本同步 的时候存在延时。简单来说就是状态可以在一段时间内不同步。

3 、最终一致性 E ：（ Eventually Consistent ）：

系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，不需要实时保证系统数据的强一致性。最终一 致性是弱一致性的一种特殊情况。BASE 理论面向的是大型高可用可扩展的分布式系统，通过牺牲强一致性来获得 可用性。ACID 是传统数据库常用的概念设计，追求强一致性模型。简单来说就是在一定的时间窗口内， 最终数据 达成一致即可。

BASE 理论是基于 CAP 原则演化而来，是对 CAP 中一致性和可用性权衡的结果。

核心思想： 即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一致性。

3 ）再谈刚性事务和柔性事务的比较