SequoiaDB 分布式事务实现原理是什么

本文将详细解释SequoiaDB分布式事务的实现原理。这篇文章的内容质量很高，所以边肖会分享给大家参考。希望你看完这篇文章后有所了解。

1

分布式事务背景

随着分布式数据库技术的发展越来越成熟，行业对分布式数据库的需求已经从过去只解决海量数据存储和读取的边缘业务转变为核心事务业务。如果分布式数据库要满足核心会计事务的需求，就需要改进分布式事务，跟上传统的关系数据库。即分布式事务的实现也需要满足事务的标准要求和定义，即ACID特性，就像传统关系数据库的事务一样。

分布式数据库的数据由多台机器和多个节点分布和存储。这种存储架构给分布式事务的实现带来了很大的困难。数据操作时，事务操作会根据数据分布在不同的存储位置执行，这个存储位置位于网络中不同机器的不同磁盘上。

2

事务基本概念

2.1 事务使用场景

银行申请是一个经典案例，可以说明交易申请的必要性。假设银行数据库中有两个表，支票账户表(check)和存款账户表(save)。现在，要将200元从李雷的支票账户转到她的存款账户，你至少需要完成三个步骤：

1.检查支票存款账户余额是否大于200元；

2.支票存款账户余额减去200元；

3.增加存款账户余额200元；

所有操作都打包并在一个事务中执行。如果某个步骤失败，所有完成的步骤都将回滚。操作通常使用START TRANSACTION语句启动事务，使用COMMIT语句提交整个事务，永久修改数据，或者使用ROLLBACK语句回滚整个事务以取消已经进行的修改。示例SQL操作如下：

STARTTRANSACTIONselect balanceFromCheckwhere customer _ id=10233276；UPDATEcheckSETbalance=balance-200.00 where CUstomer _ id=10233276；UPDATEsaveSETbalance=balance 200.00 where CUstomer _ id=10233276；COMMIT这是银行转账交易必须使用的交易操作场景，但在实际生产环境中，交易操作的复杂程度要比这复杂得多。

2.2 事务概念和特性

事务是用于访问和操作数据库中各种数据项的操作序列的集合，例如用于添加、删除和检查的各种SQL操作组合。它通常由开始事务和结束事务语句定义。

数据库系统的事务需要包括以下特征：

原子性：数据库中事务的所有操作要么全部成功，要么全部失败。

一致性：交易操作前后，数据的完整性必须一致。

隔离：当多个用户并发访问数据库时，数据库为每个用户打开一个事务，不受其他事务操作数据的干扰。也就是说，每个事务不能感觉到系统中的其他事务正在并发执行。

持久性：事务成功完成后，其对数据库的更改必须是永久的，即使出现系统故障，也不会影响事务。

事务隔离级别

对于事务隔离，SQL标准定义了四种类型的隔离级别，包括一些特定的规则来限制事务内外的哪些更改是可见的，哪些是不可见的。以下描述了四个隔离级别：

读取未提交(读取未提交的内容)

在READ UNCOMMITTED隔离级别，所有事务都可以“看到”未提交事务的执行结果。读取未提交的数据也称为“脏读”。

读取提交(读取提交的内容)

大多数数据库系统的默认隔离级别是读提交。它符合前面隔离的定义：事务只能“看到”提交的事务在开始时所做的更改，事务从开始到提交所做的任何数据更改都是不可见的，除非已经提交。该隔离级别不支持“可重复”操作。这意味着用户运行同一个语句两次，会看到不同的结果。

list-paddingleft-2">

REPEATABLE READ隔离级解决了READ UNCOMMITTED隔离级导致的问题。它确保同一事务的多个实例在并发读取数据时，会“看到同样的”数据行。不过理论上，这会导致另一个棘手问题：幻读（Phantom Read）。简单来说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影”行。数据库存储引擎可以通过多版本并发控制 (Multiversion Concurrency Control)机制解决了幻读问题，如MySQL的InnoDB和Falcon。

• SERIALIZABLE (可串行化)

SERIALIZABLE是最高级别的隔离级，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，SERIALIZABLE是在每个读的数据行上加锁。在这个级别，可能导致大量的超时现象和锁竞争现象。数据库应用中很少看到有用户选择这种隔离级。但如果用户的应用为了数据的稳定性，需要强制减少并发的话，也可以选择这种隔离级。

3

分布式事务

分布式事务的实现需要保证事务的原子性、一致性、隔离性和持久性，而实现此ACID属性的基本技术思路有：

• 通过“两阶段提交（Two-phase Commit，2PC）”协议实现事务的原子性、一致性和持久性等属性；

• 隔离性级别的实现通常使用多版本并发控制机制来保证。实现多版本并发控制常用的方式是“快照隔离（Snapshot Isolation）”技术；

下面先分别介绍一下这两个概念。

3.1 两阶段提交

两阶段提交（Two-phase Commit，2PC）是为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种协议。

两阶段提交算法的成立基于以下假设：

• 该分布式系统中，存在一个节点作为事务协调器，其他节点作为事务管理器，且节点之间可以进行网络通信。

• 所有节点都采用预写式日志（Write Ahead Log），且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。

• 所有节点不会永久性损坏，即使损坏后仍然可以恢复。

以下对二阶段提交算法分阶段进行说明。

第一阶段(提交请求阶段)

事务协调器节点向所有事务管理器节点询问是否可以执行提交操作，并开始等待各事务管理器节点的响应。事务管理器节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。

各事务管理器节点响应事务协调器节点发起的询问。如果事务管理器节点的事务操作实际执行成功，则它返回一个“同意”消息；如果事务管理器节点的事务操作实际执行失败，则它返回一个“中止”消息。有时候，第一阶段也被称作投票阶段，即各事务管理器投票是否要继续接下来的提交操作。

第二阶段(提交执行阶段)

巨杉数据库在实现多版本并发控制技术时，除了采用事务锁和内存老版本机制外，还采用了磁盘回滚段对并发控制策略进行了完善与补充。众所周知，内存是高速存储设备，但是其存在存储空间比较小以及断电数据丢失的问题。针对此问题，磁盘回滚段机制通过将内存中的“老版本数据”持久化到磁盘上，保证数据库在掉电等异常情况下不会影响事务的正常操作。

回滚段使用系统集合空间，名为”SYSRBS”。另外，其内部会使用1个集合，命名格式为”SYSRBSXXXX”，其中XXXX为循环编号，范围为0~4096。同时，回滚段使用第一个集合（即：SYSRBS0000）存储RBS的元数据，包括当前RBS集合和最后空闲RBS集合。巨杉数据库会在启动时检查是否支持MVCC，如果支持，则会检查”SYSRBS”集合空间是否存在，不存在的话则会创建此集合空间，同时创建 SYSRBSCL0000 和 SYSRBSCL0001 集合。如果回滚段的集合空间和集合均存在，则会从 SYSRBSCL0000 中读取元数据信息，根据当前RBS集合和最后空闲RBS集合信息创建下一下 SYSRBSCLXXXX。

为了更进一步提高读取速度，巨杉数据库将磁盘回滚段与内存老版本相结合，最新的老版本还是挂在记录锁的 oldversionContainer 上，其它更老的版本放磁盘上。这样满足大多数据短事务只用读内存的老版本，无需再读磁盘，从而提供了读取速度。考虑到主节点异常的情况，多版本控制需要将记录老版本数据的回滚段也同步至备节点，当备节点升为主节点后，可以通过回滚段重建老版本。

当事务ID小于全局最小事务ID(lowTranID)时，数据库后台的异步线程负责回收老版本记录和索引节点内存。内存老版本清理时要将其保存的老版本写入RBS。而磁盘老版本的清理则是从最后空闲集合(lastFreeCL)开始，逐个对比表的最大事务ID（MaxGTID），如果小于全局最小事务ID，则可以删除这个表（即SYSRBSCLXXXX）。

巨杉数据库通过采用事务锁、内存老版本以及磁盘回滚段重建老版本的设计来实现了多版本并发控制技术。此设计通过对内存结构的合理利用，存储数据和索引的老版本信息，从而实现多版本数据的快速的并发访问。

关于SequoiaDB 分布式事务实现原理是什么就分享到这里了，希望