分布式事务概述和对应代码框架介绍
谭新宇
清华大学软件学院
Github @OneSizeFitsQuorum
2022.4.21

目录

分布式事务概述
01

事务基础：ACID

事务基础：Disk-Oriented DBMS

事务基础：BufferPool Policies
Steal/No-Steal：是否允许未 commit 的数据落盘
Force/No-Force：是否要求 commit 之后将所有数据更新落盘

事务基础：ARIES
用 WAL 保证事务原子性和持久性
 undo log 保证原子性
 redo log 保证持久性
C. Mohan

事务基础：Isolation Level
ANSI SQL 92
A Critique of ANSI SQL Isolation Levels — 1995

事务基础：Isolation Level
Adya
No commonly used standard

原子提交：2PC
 问题：如何保证多节点对某件事的原子性（all or nothing）
 难点：节点可能宕机；网络可能分区；请求可能超时
 方案：Two-Phase Commit
 缺点：
 同步阻塞：协调者宕机事务可能会 block
 延时高：需要持久化 decision log

原子提交：3PC
 动机：解决 2PC 的同步阻塞问题
 方案：额外引入一个阶段，参与者超时后可自行提交
 缺点：
 无法保证 safety：为了 liveness 牺牲 safety
 延时更高：2 RTT -> 3 RTT

原子提交：Spanner
 动机：解决 2PC 的同步阻塞问题
 方案：结合 Consensus 和 2PC 算法，使得 coordinator 高可用，coordinator 宕机后由新选举出来
的coordinator 决定事务状态
 缺点：
 延时高：decision log 不仅需要持久化，还需要达成共识

原子提交：Percolator
 动机：解决 2PC 的同步阻塞问题
 方案：结合 Consensus 和 2PC 算法，将 decision log 高可用，coordinator 宕机后由其他事务来
确定性的决定事务状态
 缺点：
 延时高：decision log 不仅需要持久化，还需要达成共识

并发控制：2PL
 核心思想：先取锁再访问的保守策略
 优点：类似于 mutex，事务写冲突较多时性能更好
 工作原理：两个阶段；两种锁类型
 2PL：存在级联回滚和死锁问题
 SS2PL：存在性能和死锁问题
 死锁预防：Wait for Graph

并发控制：OCC
 核心思想：先访问再解决冲突的乐观策略
 优点：类似于 CAS，事务写冲突较少时性能更好
 工作原理：三个阶段；为每行数据维护版本
 Read Phase：读数据和版本号并开始在本地缓存计算
 Validation Phase：锁住写集合，根据版本号检查读集合是否依然匹配
 Write Phase：进行提交，递增版本并释放锁

并发控制：MVCC
 核心思想：一个数据存储多个版本，空间换取时间
 优点：写不阻塞读，读不阻塞写；读事务可以无锁快照读
 缺点：存储开销
 特点：可与悲观策略（Google Spanner）或乐观策略（Hekaton）结合

事件排序
如何为发生在不同节点上的所有事件排序？
 使用物理时钟：
 不同节点的物理时钟存在误差
 物理时钟不能百分百准确
 使用逻辑时钟：
 存在具有因果一致性的事件被排序错误
 排序的意义：
 满足各种一致性级别对于读写请求序列的要求
 Replicate State Machine 的启蒙思想

事件排序：Partial Ordering
 Happened Before 关系：
 同一进程内的先后事件：r1 -> r2
 同一消息的发送和接收事件：r2 -> q7
 满足传递定律：r1 -> q7
 并不是所有事件具备 Happened Before 关系： 比如 q6
和 r2
 本质：存在因果的关系才具有 Happened Before 关系
 逻辑时钟：为事件标记逻辑时间戳，反映 Happened
Before 关系即可
 问题：如何为所有事件排出一个全序？

事件排序：Total Ordering
 最简单的方案：比较逻辑时间戳
 本质：在系统内部，比较没有因果性的事件没有意义
 缺点：物理世界的因果关系无法被系统捕捉到
 举例：小明从网络上查询到了球赛的结果为
3:1，打电话告诉了小李，但小李在网络上查询
到的球赛结果依然还是 2:1

事件排序：Total Ordering
 物理世界：根据相对论，我们所在的物理世界是偏序时空
 O 和 P 存在偏序关系，他们在物理世界中存在因果关系
 O 和 Q 不存在偏序关系，比较他们的顺序没有意义
 最理想的方案：误差足够小的物理时钟
 本质：保证物理世界存在因果性的事件所被标记的逻辑时
间戳具备 Happened Before 关系

事件排序：Rethinking
 我们所在世界的 Happened Before 关系是由光速自然维护的
 我们所在世界的物理时钟可能在更高维空间看来是逻辑时钟

时钟：True Time
 特点：足够精确的物理时钟，误差在 7ms 以内
 核心思想：利用 TrueTime API 和 Commit Wait Rule 来保证外部一致性
 不确定窗口处理方案：写时等待
 缺点：需要特殊的硬件支持，不具备普适性
 典型系统：Spanner

时钟：HLC
 特点：与物理时钟半同步的逻辑时钟，使用 NTP 同步，误差一般在 250ms 以内
 核心思想：在不依赖特殊硬件时，为保证低延迟只能弱化一致性级别
 不确定窗口处理方案：读时重试
 缺点：对于新增 key 无法保证线性化
 典型系统：CockRoachDB
 异象：T3 有可能只能查到 T2，查不到 T1

时钟：TSO
 特点：实现递增时间戳的最简单方案
 核心思想：抽象出 PD 角色来提供递增时间戳，经过批量异步等优化后能达到百万 TPS 每秒
 缺点：跨数据中心事务延时较高
 典型系统：TiDB

Distributed-Txn 代码框架介绍
02

Overview
TinyKV：有状态的参与者
TinySQL：无状态的协调者

存储引擎：Engine
 基本接口： Get/Put/Delete/Batch
 特点：
 KV 分离的 LSM 架构，对宽表友好
 支持迭代器和前缀扫描
 支持垃圾回收
 支持事务

存储引擎：Storage
 基本接口： Write/Reader
 特点：
 支持 Standalone 版本
 支持 Raft 版本 -> TinyKV / 6.824

事务引擎：TinySQL

事务引擎：TinyKV

总结

Q & A
Thanks！