集中式事务与分布式事

集中式事务ACID：

事务是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元，狭义上的事务特指数据库事务。

事务的四个特征：原子性（Atomicity），一致性（Consistency），隔离性（Isolation）和持久性（Durability），简称为事务的ACID特性。

原子性

事务的原子性是指事务必须是一个原子的操作序列单元。事务中包含的各项操作在一次执行过程中，只允许出现两个情况：全部执行成功，全部不执行。

任何一个操作失败都会导致整个事务失败，同时已经执行成功的操作会被撤销并回滚，只有所有的操作成功事务才算成功。

一致性

事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行之前和执行之后，数据库都必须处于一致性状态。也就是说，事务执行的

结果必须使数据库从一个一致性状态变到另一个一致性状态，因此当数据库只包含成功事务提交的结果时，就能说数据库处于一致性状态。

隔离性

事务的隔离性是指在并发环境中，并发的事务是相互隔离的，一个事务的执行不能被其他事务干扰。也就是说，不同的事务并发操作相同的数据时，每个事务都

有各自的数据空间，即一个事务内部的操作以及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能相互干扰。

标准SQL规范中，定义了4种事务的隔离级别，不同的隔离级别对事务的处理不同（未授权读取，授权读取，可重复读取和串行化）级别由低到高

关于事务的隔离级别更多细节，这里不作记录了

持久性

事务的持久性也被称为永久性，是指一个事务一旦提交，它对数据库中的对应数据的状态变更就应该是永久性的。一旦某个事务成功结束，那么它对数据库所

做的更新就必须被永久保存下来。

分布式事务：

事务的参与者，支持事务的服务器，资源服务器以及事务管理器分别位于分布式系统的不同节点之上。通常一个分布式事务中会涉及对多个数据库或业务系统

的操作。分布式事务也可以定义为一种嵌套型的事务。

CAP定理，分布式系统不可能同时满足一致性（Consistency），可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两个。

一致性

在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致性的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保

证系统的数据仍然处于一致的状态。

可用性

可用性是指系统提供的服务必须一致处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。

分区容错性

分区容错性约束了一个分布式系统需要具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，

除非整个网络环境都发生了故障

对于一个分布式系统，分区容错性是必然需要的，一般只能根据业务特点在可用性和一致性方面做平衡。

BASE理论是 Basically Available（基本可用），soft state（软状态）和Eventually consistent（最终一致性）

基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性

弱状态

弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的

数据副本之前进行数据同步的过程存在延时。

最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间得同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能

够达到一致，而不需要实时保证系统数据的强一致性。

分布式一致性的的协议与算法

二阶段协议，三阶段协议，PAXOS算法协议

2PC

2PC，即二阶段提交，分为两个阶段来提交事务，简单来说就是分为投票与执行两个阶段

阶段一：提交事务请求

1.事务询问。

协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

2.执行事务。

各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中。

3.各参与者向协调者反馈事务询问的响应。

如果参与者成功执行了事务操作，那么就反馈给协调者Yes响应，表示事务可以执行；如果参与者没有成功执行事务，那么久反馈给协调者No响应，

表示事务不可以执行。

阶段二：执行事务提交

在阶段二中，协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作，正常情况下，包含以下两种可能。

执行事务提交：

如果协调者从所有参与者获得的反馈都是Yes响应，那么就会执行事务提交。

1.发送提交请求。

协调者向所有参与者节点发出Commit请求。

2.事务提交。

参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。

3.反馈事务提交结果。

参与者在完成事务提交之后，向协调者发送Ack消息。

4.完成事务。

协调者接收到所有参与者反馈的Ack消息后，完成事务。

中断事务：

如果任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

1.发送回滚请求。

协调者向所有参与者节点发出Rollback请求。

2.事务回滚。

参与者接收到Rollback请求后，会利用其在阶段一中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。

3.反馈事务回滚结果。

参与者在完成事务回滚之后，向协调者发送Ack消息。

4.中断事务。

协调者接收到所有参与者反馈的Ack消息后，完成事务中断。

二阶段提交协议的优点：原理简单，实现方便。

二阶段提交协议的缺点：同步阻塞，单点问题，数据不一致，太过保守

3PC

三阶段提交，是对二阶段提交的改进，将二阶段的执行阶段分为了两个步骤，形成了CanCommit（询问是否能提交），PreCommit（预提交）和

doCommit（执行提交）三个阶段组成的事务处理协议。

阶段一：CanCommit

1.事务询问。

协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

2.各参与者向协调者反馈事务询问的响应。

参与者在接收到来自协调者的canCommit请求后，正常情况下，如果其自身任务可以顺利执行事务，那么会反馈Yes响应，并进入预备状

态，否则反馈No响应。

阶段二：PreCommit

在阶段二中，协调者会根据各参与者的反馈情况来决定是否可以进行事务的PreCommit操作，正常情况下，有两种可能。

执行事务预提交

假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务预提交。

1.发送预提交请求。

协调者向所有参与者节点发出preCommit的请求，并进入Prepared阶段。

2.事务预提交。

参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。

3.各参与者向协调者反馈事务执行的响应。

如果参与者成功执行了事务操作，那么就会反馈给协调者Ack响应，同时等待最终的指令：提交（commit）或中止（abort）。

中断事务

和二阶段一样，如有任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

1.发送中断请求。

协调者向所有参与者节点发出abort请求。

2.中断事务。

无论是收到来自协调者的abort请求，或者是在等待协调者请求过程中出现超时，参与者都会中断事务。

阶段三：doCommit

该阶段将进行真正的事务提交,会存在两个情况。

执行提交

1.发送提交请求

假设协调者处于正常工作状态，并且接收到了来自所有参与者的Ack响应，那么将预提交状态转换到提交状态，并向所有参与者发送doCommit

请求。

2.事务提交。

参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。

3.反馈事务提交结果。

参与者在完成事务提交之后，向协调者发送Ack消息。

4.完成事务。

协调者接收到所有参与者反馈的Ack消息后，完成事务。

中断事务

假设协调者处于正常工作状态，并且有任意一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，

那么就会中断事务。

1.发送中断请求。

协调者向所有的参与者节点发送abort请求。

2.事务回滚。

参与者接收到abort请求后，进行事务的回滚，完成回滚后释放整个事务执行期间占用的资源。

3.反馈事务回滚结果。

参与者在完成事务回滚之后，向协调者发送Ack消息。

4.中断事务。

协调者接收到所有参与者反馈的Ack消息后，中断事务。

进入三阶段以后，无论协调者还是参与者出现故障，参与者都会在等待超时之后，继续进行事务提交。

Ack确认接收到消息无误,UNDO主要记录如何撤销事务和保证读一致性；REDO则是负责数据库前滚（重做），保护数据不丢失。