事务笔记

事务的作用
数据库事务的原理
分布式事务
CAP原理
XA协议的原理
二阶段提交的原理
TCC（Try/Confirm/Cancel）
消息最终一致性

1. 事务的作用

保证单个逻辑单元的一系列操作，要么全部成功执行，要么都不执行。

事务具有ACID特性，原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）

原子性：事务中的所有元素作为一个整体提交或回滚.

一致性：事务完成时，数据必须是一致的.

隔离性：对数据急性修改的多个事物是彼此隔离的。

持久性：事物完成之后，对系统的影响是永久的。

2. 数据库事务的原理

事务存在的几个问题

更新丢失：两个事务都同时更新一行数据，一个事务对数据的更新把另一个事务对数据的更新覆盖了。

脏读：一个事务读取到了另一个事务未提交的数据操作结果。

不可重复读：一个事务对同一行数据重复读取两次，但是却得到了不同的结果，包含虚读和幻读。

虚读：事务T1读取某一数据后，事务T2对其做了修改，当事务T1再次读取数据时得到与前一次不同的值。

幻读：事务在操作过程中进行两次查询，第二次查询的结果包含了第一次查询中未出现的数据活着缺少了第一次查询中出现的数据。这是因为在两次查询中有另外一个事务插入数据造成的。

为了解决上面的几个问题，数据库提供了四种隔离级别，不同的隔离级别对事务的处理不同。

数据库默认是采用REPEATABLE-READ

读未提交(Read Uncommitted)：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个事务则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。

读提交(Read Committed)：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。

可重复读取(Repeatable Read)：禁止不可重复读取和脏读取，但是有时可能出现幻读数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。

序列化(Serializable)：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，不能并发执行。仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

3. 分布式事务

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

例如在微服务架构中，一个借口中，可能包同时调用多个服务，如何保证所有服务的正确提交和失败回滚呢？这就是分布式事务要做的事情。

4. CAP原理

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

CAP原则是 NOSQL数据库的基石。

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

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

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

5. XA协议

X/Open Distributed Transaction Processing (DTP) Model

XA协议由 Tuxedo首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。目前， Oracle、 Informix、 DB2和 Sybase等各大数据库厂家都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。XA接口提供资源管理器与事务管理器之间进行通信的标准接口。

6. 二阶段提交的原理

参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。

第一阶段：准备阶段（投票阶段）

第二阶段：提交阶段（执行阶段）

流程

1. 协调者询问参与者进行准备确认，并等待参与者响应

2. 参与者响应通过，返回“同意”，反之返回“中止”

3. 协调者收到所有参与者反馈的“同意”时，向参与者发起提交请求

4. 若参与者都处理成功，向协调者发送“完成”消息，协调者完成事务

若参与者其中一个处理失败，向协调者发送“中止”消息，协调者回滚所有参与者的事务。

缺点：同步阻塞问题，单点故障，数据不一致

7. TCC（Try/Confirm/Cancel）

基于事务补偿机制的分布式事务管理器。

Try：主要对业务系统做检测及资源预留

Confirm：主要对业务系统做确认提交

Cancel：主要是在业务执行错误时，回滚业务。

对业务的侵入性比较大

8. 消息最终一致性

目前比较成熟的产品是阿里的RocketMQ，但未开源，同时阿里云也提供了一款中间件产品全局事务服务(Global Transaction Service, GTS)。

用消息确认机制来保证：只要消息发送，就能确保被消费者消费来做到了消息最终一致性

流程

1. APP发送待确认消息 -> 可靠消息系统

2. 可靠消息系统保存待确认状态消息 -> 服务

3. APP确认并发送消息 -> 可靠消息系统

4. 可靠消息系统修改消息状态为发送，并发送消息 -> MQ中间件

5. 服务监听MQ中间件，执行本地业务，ACK确认 -> MQ中间件, 确认消息被消费 -> 可靠消息

6. 可靠消息修改状态为已完成

参考资料

猜你喜欢