OceanBase 事务引擎介绍

1 .OceanBase 事务引擎介绍 颜然/韩富晟 yanran.hfs@antfin.com 

2 .IBM解决方案 System 360 System 390 IBM z14 

3 .从小型机到数据中心演化 DEC PDP8 SUN Workstation PC Server Datacenter 

4 .OceanBase 事务 弹性扩展 不依赖高端硬件 OceanBase 高性能 金融级可靠性 OB 架构下事务 ACID 的实现方式： • Durability: 事务日志使用 Paxos 做多副本同步 • Atomicity: 使用两阶段提交保证跨机事务原子性 • Isolation: 使用多版本机制进行并发控制 • Consistency: 保证唯一性约束 

5 .目录 1 内存事务引擎 2 分布式事务二阶段提交 3 事务隔离 

6 .OceanBase 存储引擎 基线数据 增量修改 

7 .OceanBase 存储引擎 适应存储介质的数据组织方式 • 固态盘随机读效率高，随机写效率差 Query 增删改 • 硬盘存储基线数据以批量的方式写入 • 内存存储增量修改，存储到一定量后 Data 基线数据 修改增量 与基线数据合并。合并后形成新的基 （固态盘） （内存） 线数据，已合并的内存增量清空。 为短事务优化 • 实际系统中绝大部分事务都是短事务 • 事务状态不持久化 • 不需要 undo 

8 .内存事务引擎 name salary department phone Han 1,000,000 Research 17012341234 Sun 800,000 Sales 17013571357 Wei 1,200,000 Marketing 17014701470 Han ● 4: s: 2,000,000 ● 2: d: Investment ● 1: s: 1,500,000 ● Wei ● 3: s: 1,300,000 ● UPDATE staff SET salary = salary + 500000 WHERE name = ‘Han’ UPDATE staff SET department = ‘Investment’ WHERE name = ‘Han’ UPDATE staff SET salary = salary + 100000 WHERE name = ‘Wei’ UPDATE staff SET salary = salary + 500000 WHERE name = ‘Han’ 

9 .内存事务引擎 内存存储 • 修改产生的多版本以内存链表形式表达，效率高 

10 .OceanBase 数据组织与分布 数据组织与分布 RootService PartitionTabl • 数据以 Partition 进行组织 e （一个 Table 有一个或者多个 Partition） P0 P0 P0 • 全局的 PartitionTable 是 P1 P1 P1 Partition 的元信息，记录了 Partition 的位置 P2 P2 P2 • 每个 Partition 拥有独立的日 P3 P3 P3 志服务 • 涉及多个 Partition 的事务都 P4 P4 P4 是分布式事务 ObServer1 ObServer2 ObServer3 ObServer4 

11 .可靠性 vs 可用性 传统数据库的事务模型 ACID 没有描述可用性（Availability） 业务系统切实需要可用性来保证服务能力 传统数据库的解决方案：最大保护（Max Protection），最大可用 （Max Availability），最好性能（Max Performance） OceanBase 采用 Paxos 协议兼顾可靠性和可用性 Atomicity Availability ACID A2CID Consistency Isolation Durability 

12 .Paxos 日志同步 Commit日志 Commit日志 P01 9 10 11 12 13 14 15 P02 9 10 11 12 13 14 15 P03 9 10 11 12 13 14 15 

13 .分布式事务 难点： • 分布式事务依赖二阶段提交保证事务的原子性 • 二阶段提交：状态多、复杂、状态机容易卡住 OceanBase 二阶段提交协议的特点： • 所有参与者都是高可用的 • 协调者不写日志，无持久化状态 • commit 操作延迟低 • 全自动处理异常情况 

14 .分布式事务的执行模型 二阶段提交参与者 Clien Clien Clien t t t • 事务的所有 SQL 都通过 session 传送， 参与者列表维护在 session 所在机器。 Session • 参与者的实体是 Partition（Px, Py, Pz） • 业务不感知是否分布式事务，如果只有一 个参与者则使用一阶段提交，否则 ObServer1 ObServer2 ObServer3 ObServer4 自动使用二阶段提交 SQLy SQLz SQLx 

15 .二阶段提交流程 Commit 命令 • 指定第一个参与者 Px 作为协调者，发送 end_trans 消息给 Px 并告知其参与者列表 Px, Py, Pz 协调者 • Px 收到 end_trans 消息创建协调者 协调者 参与者 状态机 • 协调者进入 PREPARE 状态并向所有 参与者发送 prepare 消息 • 收到所有参与者 prepare ok 应答后 进入 COMMIT 状态并向所有参与者 发送 commit 消息 • 如果有一个参与者应答 abort 则进入 ABORT 状态并向所有参与者发送 abort 消息 

16 .二阶段提交流程 参与者 • 参与者状态机是在 DML 语句执行过程中创 建的 • 收到 prepare 消息后将事务的修改写日志 参与者 协调者 （redo） • 日志持久化成功后进入 PREPARED 状态并 回复协调者 prepare ok 消息 • 收到协调者的 commit 消息则写 commit 日志、进入 COMMITTED 状态并回复 commit ok 消息 • 收到 abort 消息则写 abort 日志、 进入 ABORTED 状态并回复 abort ok 消息 

17 .二阶段提交过程中参与者宕机 需要区分是否进入 PREPARED 状态两种情况考虑 已进入 PREPARED 状态 • 状态已经 Paxos 同步 • 系统会自动选择一个副本作为新的 Leader 并恢复出 PREPARED 状态，协调者继 续推进，协调者可能感知不到 还未进入 PREPARED 状态 • 参与者的所有事务状态丢失 • 参与者会应答协调者 prepare unknown 消息 • 事务最终会 abort 

18 .二阶段提交过程中协调者宕机 协调者与第一个参与者是同一个 Partition，参与者状态机恢复遵从参与 者自己的逻辑，协调者状态机的恢复由参与者回复协调者的消息触发 参与者未收到协调者消息时，认为上一条回复消息丢失，会定时重发发 送上一条消息 正常流程里 Px 收到 end_trans 消息会创建协调者状态机 异常流程里 Px 收到 prepare ok, commit ok, abort ok 消息会创建协 调者状态机，协调者会继续推动状态机继续运行 所有参与者都记录参与者列表 

19 .二阶段提交延迟分析 协调者 P0 P1 用户感知的 commit 延迟 • 标准：4次日志延迟 + 2次 RPC 延迟(同zone) commit prepare req • OB：1次日志延迟 + 2次 RPC 延迟(同zone) 协调者 P0 P1 commit OB 二阶段提交 prepare req prepare ok 标准二阶段提交 commit req pre-commit ok prepare ok commit ok commit ok commit req 持久化日志 commit ok commit ok 事务提交 

20 .OceanBase 事务隔离 写-写并发 • 所有修改的行加互斥锁 • 写操作需要等待行上已有的行锁解锁 读-写并发 • 读操作读取事务快照版本（Publish Version）对应的数据 • 读写互相不阻塞 Publish Version …… 134 157 201 221 230 232 249 …… 9 10 11 12 13 14 15 

21 .事务版本号 分布式事务多版本并发难点 • 系统中事务完成的版本号顺序无法严格递增 • 单纯基于快照版本无法做到读到正确的数据 • PREPARE 和 COMMIT 之间的事务已经产生了事务版本，但是事务状态还未确定， 需要阻塞更大快照版本的读取 Publish Version …… 134 157 201 221 230 232 249 …… 9 10 11 12 13 14 15 

22 .THANKS /感谢聆听 --------- Q&A Section -------- OceanBase 颜然/韩富晟