竹翁，OceanBase 内核研发总监
杨志丰，花名竹翁，毕业于北京大学，长期从事分布式系统和数据库的研发工作，现于阿里巴巴/蚂蚁金服自主研发的分布式关系数据库 OceanBase 团队负责研发工作，致力于把设计先进的 HTAP 数据库系统打造成技术业内标杆的核心基础设施。在 OceanBase 系统中，他先后负责研究 OceanBase 的 SQL 引擎、分布式主控模块、多模数据库方向以及 OceanBase 的数据库平台产品研发，并于近期开始负责内核创新研发工作。竹翁对 C++、分布式系统原理、SQL 查询处理、事务处理、编译技术、工程效率等方面具有深入的理解。

源码是 OceanBase 的“方向盘”，本系列主要围绕“源码解读”，通过文章阐述，帮助大家理清数据库的内在本质。本文为 OceanBase 数据库源码解读系列文章的第四篇，将主要为大家介绍事务的外部接口相关知识。

事务的外部接口

1.1. 协议层对事务层的封装

协议层对事务层提供的原始接口进行了封装，源码位置：sql/ob_sql_trans_control.h，截图如下。这层封装维护了  TransState 状态，且便于 SQL 层调用，语句执行结束时在统一的位置根据  TransState 调用正确的事务接口，保证在任何异常状态下事务资源不泄露。

2.2. 原始的事务接口

原始的事务接口位于源码文件 storage/transaction/ob_trans_service.h，主要接口为：

• start_trans &  end_trans （参见截图）
• start_stmt &  end_stmt
• start_participant &  end_participant

它们分别对应事务、语句、语句内参与者（分区）的访问生命周期。 start trans 开启事务后，返回一个  ObTransDesc 对象。该对象作为事务唯一标识，会被保存到  session 对象中，其他事务接口和后续语句执行都需要它，也常用于问题诊断。

3.3. 分布式事务

开始执行前，根据语句涉及分区信息从  location cache 中获取主副本（leader）位置，选择对应类别的执行计划。一般的，一个 SQL 查询或 DML 会产生三类执行计划（ ObPhyPlanType）：

• local 计划表示所有该语句执行需访问分区的 leader 都在本节点
• remote 计划表示所有分区 leader 都在远程一个节点上
• distributed 计划表示分区 leader 在多节点上的情况。

location cache 是一个整体架构上的重要组件，用于高效查找分区副本信息，它对外提供统一接口，屏蔽了很多分布式细节。它的主体实现位于 share/partition_table目录（参见截图），而源文件 sql/ob_sql_partition_location_cache.h 对它进行了封装，同时统一了虚拟表的处理。

事务控制调用往往要综合考虑多种因素：

• 语句类型（是否只读）
• 事务类型（是否自动提交，是否弱一致性读）
• 当前事务状态和执行计划类型等
  

例如，本地计划自动提交，在本节点顺序执行  start_trans ➡︎  start_stmt➡︎  start_participant➡︎ end_participant➡︎ end_stmt➡︎ end trans；远程计划自动提交，上述接口都在远程节点执行。而对于分布式执行计划， start/end_stmt 在本节点执行， start/end_participant 在每个分区 leader 所在节点上执行。这组接口设计目的是在简化事务接口与分场景优化事务性能间取得一定的平衡。

以上就是 OceanBase 事务的一生，在后续的源码解读第五篇我们将会为大家解析 OceanBase 数据库多租户架构的相关内容，敬请期待。

如果大家有任何疑问，可以通过以下方式与我们进行交流：

微信群：扫码添加小助手，将拉你进群哟～

钉钉群：33254054

eanbase

博客问答： oceanbase.com/community /answer

gitee： https:// gitee.com/oceanbase