分布式事务

最新推荐文章于 2024-06-05 12:38:42 发布

VJJ

最新推荐文章于 2024-06-05 12:38:42 发布

阅读量220

点赞数

文章标签：分布式事务

数据库本地事务

A：原子性(Atomicity)
一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。
C：一致性(Consistency)
事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。
I：隔离性(Isolation)
指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。
D：持久性(Durability)
指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。

而事务的ACID是通过InnoDB日志和锁来保证。事务的隔离性是通过数据库锁的机制实现的，持久性通过redo log（重做日志）来实现，原子性和一致性通过Undo log来实现。
UndoLog的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为UndoLog）。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。
和Undo Log相反，RedoLog记录的是新数据的备份。在事务提交前，只要将RedoLog持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是RedoLog已经持久化。系统可以根据RedoLog的内容，将所有数据恢复到最新的状态。对具体实现过程有兴趣的同学可以去自行搜索扩展。

分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。
CAP

C (一致性)：对某个指定的客户端来说，读操作能返回最新的写操作。对于数据分布在不同节点上的数据上来说，如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致，如果有某个节点没有读取到，那就是分布式不一致。
A (可用性)：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)。可用性的两个关键一个是合理的时间，一个是合理的响应。合理的时间指的是请求不能无限被阻塞，应该在合理的时间给出返回。合理的响应指的是系统应该明确返回结果并且结果是正确的，这里的正确指的是比如应该返回50，而不是返回40。
P (分区容错性)：当出现网络分区后，系统能够继续工作。打个比方，这里个集群有多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。

熟悉CAP的人都知道，三者不能共有，如果感兴趣可以搜索CAP的证明，在分布式系统中，网络无法100%可靠，分区其实是一个必然现象，如果我们选择了CA而放弃了P，那么当发生分区现象时，为了保证一致性，这个时候必须拒绝请求，但是A又不允许，所以分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。
对于CP来说，放弃可用性，追求一致性和分区容错性，我们的zookeeper其实就是追求的强一致。
对于AP来说，放弃一致性(这里说的一致性是强一致性)，追求分区容错性和可用性，这是很多分布式系统设计时的选择，后面的BASE也是根据AP来扩展。

BASE
BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。是对CAP中AP的一个扩展

基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
软状态：允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。
最终一致：最终一致是指经过一段时间后，所有节点数据都将会达到一致。
BASE解决了CAP中理论没有网络延迟，在BASE中用软状态和最终一致，保证了延迟后的一致性。BASE和 ACID 是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

两段式提交和三段式提交
https://www.cnblogs.com/congsg2016/p/5400958.html
ACP定理
CAP理论告诉我们，一个分布式系统不可能同时满足一致性（C，Consistency），可用性（A，Availability）和分区容错性（P，Partition tolerance）三个基本要求，最多只能同时满足其中两个。
一致性：分布式系统中，能够做到针对一个数据的更新成功后，其他所有的用户都可以读取到［最新的值］，那么这样子的系统就是强一致性的。
可用性：［有限时间内］［返回结果］
分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证固堤外提供满足一致性和可用性的服务。
其实CAP定理是理论，现实系统场景中的CAP也不一定会真的会放弃其中一个不做，而是我们可以着重性的保证其他两个，而剩下的一个尽量保证。

［二段式提交协议］是将事务的提交过程分成了两个阶段来进行处理，其执行过程如下：
阶段一：提交事务请求：
1、事务询问。协调者向所有参与者发送事务内容，询问是否可以进行事务提交操作，然后就开始等待参与者的响应。
2、执行事务。各参与者节点执行事务，并将Undo和Redo信息记入事务日志中。
3、各参与者向协调者反馈事务询问的响应。
阶段二：执行事务提交：
假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务提交。
1、发送提交请求。
2、事务提交。
3、反馈事务提交结果。参与者在完成事务提交之后，会向协调者发送Ack消息。
4、完成事务。
中断事务：
1、发送回滚请求。协调者向参与者发出rollback请求。
2、事务回滚。参与者接收到Roolback请求利用阶段一种记录的Undo信息来执行事务回滚动作。
3、反馈事务回滚结果。
4、中断事务。

二段式提交协议的优缺点：
优点：原理简单，实现方便；
缺点：同步阻塞、单点问题、脑裂（比如协调者的消息在网络异常情况下只给一部分参与者发送了）、太过保守。

［三段式提交协议］其实是在二段式基础上面针对二段式的缺点进行了改进。
阶段一：CanCommit
1、事务询问。
2、各参与者向协调这反馈事务询问的响应。
阶段二：PreCommit
假设协调者从所有的参与者获得的都是Yes响应，那么将执行事务预提交。
1、发送预提交请求。协调者向所有参与者节点发出preCommit请求，进入prepared阶段。
2、事务预提交。参与者接收到preCommt请求，执行事务，将Undo和Redo信息记录到事务日志中。
3、各参与者向协调者反馈事务提交的响应。
假设任何一个参与者向协调者反馈了No反应，活着在等待超时之后，协调者无法获得所有参与者的响应，那么将执行事务的中断。
1、发送终端请求。协调者向所有参与者发出abort请求。
2、中断事务。无论接到abort请求还是等待协调者请求过程出现超时情况，参与者都会中断事务。
阶段三：doCommit
该阶段将进行真正的事务提交：
执行提交
1、发送提交请求。进入这一阶段，假设协调者从正常的工作状态，并且接收到所有的参与者的ack响应，它将从预提交状态转换到提交状态，向所有参与者发送doCommit请求。
2、事务提交。参与者接收到doCommit请求后，正式执行事务提交操作。并在提交后释放在整个事务执行期间占用的事务资源。
3、反馈事务提交结果。参与者完成事务提交之后，向协调者发送Ack消息。
4、完成事务。协调者接收到所有参与者的Ack消息，完成事务。
中断事务
中断事务的4步操作与提交事务完全一致，只不过从提交事务变成了事务回滚。
三段式提交协议的优缺点：
最大优点就是降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。

缺点就是在去除阻塞的情况下引入了新的问题，那就是参与者接收到了PreCommit消息，然后网络出现问题，参与者和协调者无法通信，这种情况下，参与者依然会执行事务的提交。数据可能存在不一致性。

分布式事务中2PC与3PC的区别

https://blog.csdn.net/yyd19921214/article/details/68953629
在分布式系统中，每一个机器节点虽然都能明确的知道自己执行的事务是成功还是失败，但是却无法知道其他分布式节点的事务执行情况。因此，当一个事务要跨越多个分布式节点的时候（比如，淘宝下单流程，下单系统和库存系统可能就是分别部署在不同的分布式节点中），为了保证该事务可以满足ACID，就要引入一个协调者（Cooradinator）。其他的节点被称为参与者（Participant）。协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务进行提交。

2PC的第一阶段准备阶段不仅仅是回答YES or NO，还是要执行事务操作的，只是执行完事务操作，并没有进行commit还是roolback。相当于先干了再汇报结果，然后协调者根据结果统一提交或回滚。

3PC最关键要解决的就是协调者和参与者同时挂掉的问题，所以3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。在第一阶段，只是询问所有参与者是否可可以执行事务操作，并不在本阶段执行事务操作。当协调者收到所有的参与者都返回YES时，在第二阶段才执行事务操作，然后在第三阶段在执行commit或者rollback。

在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。

跟我学分布式事务之2PC和3PC

https://blog.csdn.net/huaweitman/article/details/50758907

分布式事务是指会涉及到操作多个数据库的事务。其实就是将对同一库事务的概念扩大到了对多个库的事务。目的是为了保证分布式系统中的数据一致性。分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）
在分布式系统中，各个节点之间在物理上相互独立，通过网络进行沟通和协调。由于存在事务机制，可以保证每个独立节点上的数据操作可以满足ACID。但是，相互独立的节点之间无法准确的知道其他节点中的事务执行情况。所以从理论上讲，两台机器理论上无法达到一致的状态。所以，常规的解决办法就是引入一个“协调者”的组件来统一调度所有分布式节点的执行。
2PC的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
第一阶段准备阶段：事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。
第二阶段提交阶段：如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)

3PC除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。