Successfully reported this slideshow.
Your SlideShare is downloading. ×

分布式事务概述和对应代码框架介绍.pdf

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 32 Ad
Advertisement

More Related Content

Recently uploaded (20)

Advertisement

分布式事务概述和对应代码框架介绍.pdf

  1. 1. 分布式事务概述和对应代码框架介绍 谭新宇 清华大学软件学院 Github @OneSizeFitsQuorum 2022.4.21
  2. 2. 目录
  3. 3. 分布式事务概述 01
  4. 4. 事务基础:ACID
  5. 5. 事务基础:Disk-Oriented DBMS
  6. 6. 事务基础:BufferPool Policies Steal/No-Steal:是否允许未 commit 的数据落盘 Force/No-Force:是否要求 commit 之后将所有数据更新落盘
  7. 7. 事务基础:ARIES 用 WAL 保证事务原子性和持久性  undo log 保证原子性  redo log 保证持久性 C. Mohan
  8. 8. 事务基础:Isolation Level ANSI SQL 92 A Critique of ANSI SQL Isolation Levels — 1995
  9. 9. 事务基础:Isolation Level Adya No commonly used standard
  10. 10. 原子提交:2PC  问题:如何保证多节点对某件事的原子性(all or nothing)  难点:节点可能宕机;网络可能分区;请求可能超时  方案:Two-Phase Commit  缺点:  同步阻塞:协调者宕机事务可能会 block  延时高:需要持久化 decision log
  11. 11. 原子提交:3PC  动机:解决 2PC 的同步阻塞问题  方案:额外引入一个阶段,参与者超时后可自行提交  缺点:  无法保证 safety:为了 liveness 牺牲 safety  延时更高:2 RTT -> 3 RTT
  12. 12. 原子提交:Spanner  动机:解决 2PC 的同步阻塞问题  方案:结合 Consensus 和 2PC 算法,使得 coordinator 高可用,coordinator 宕机后由新选举出来 的coordinator 决定事务状态  缺点:  延时高:decision log 不仅需要持久化,还需要达成共识
  13. 13. 原子提交:Percolator  动机:解决 2PC 的同步阻塞问题  方案:结合 Consensus 和 2PC 算法,将 decision log 高可用,coordinator 宕机后由其他事务来 确定性的决定事务状态  缺点:  延时高:decision log 不仅需要持久化,还需要达成共识
  14. 14. 并发控制:2PL  核心思想:先取锁再访问的保守策略  优点:类似于 mutex,事务写冲突较多时性能更好  工作原理:两个阶段;两种锁类型  2PL:存在级联回滚和死锁问题  SS2PL:存在性能和死锁问题  死锁预防:Wait for Graph
  15. 15. 并发控制:OCC  核心思想:先访问再解决冲突的乐观策略  优点:类似于 CAS,事务写冲突较少时性能更好  工作原理:三个阶段;为每行数据维护版本  Read Phase:读数据和版本号并开始在本地缓存计算  Validation Phase:锁住写集合,根据版本号检查读集合是否依然匹配  Write Phase:进行提交,递增版本并释放锁
  16. 16. 并发控制:MVCC  核心思想:一个数据存储多个版本,空间换取时间  优点:写不阻塞读,读不阻塞写;读事务可以无锁快照读  缺点:存储开销  特点:可与悲观策略(Google Spanner)或乐观策略(Hekaton)结合
  17. 17. 事件排序 如何为发生在不同节点上的所有事件排序?  使用物理时钟:  不同节点的物理时钟存在误差  物理时钟不能百分百准确  使用逻辑时钟:  存在具有因果一致性的事件被排序错误  排序的意义:  满足各种一致性级别对于读写请求序列的要求  Replicate State Machine 的启蒙思想
  18. 18. 事件排序:Partial Ordering  Happened Before 关系:  同一进程内的先后事件:r1 -> r2  同一消息的发送和接收事件:r2 -> q7  满足传递定律:r1 -> q7  并不是所有事件具备 Happened Before 关系: 比如 q6 和 r2  本质:存在因果的关系才具有 Happened Before 关系  逻辑时钟:为事件标记逻辑时间戳,反映 Happened Before 关系即可  问题:如何为所有事件排出一个全序?
  19. 19. 事件排序:Total Ordering  最简单的方案:比较逻辑时间戳  本质:在系统内部,比较没有因果性的事件没有意义  缺点:物理世界的因果关系无法被系统捕捉到  举例:小明从网络上查询到了球赛的结果为 3:1,打电话告诉了小李,但小李在网络上查询 到的球赛结果依然还是 2:1
  20. 20. 事件排序:Total Ordering  物理世界:根据相对论,我们所在的物理世界是偏序时空  O 和 P 存在偏序关系,他们在物理世界中存在因果关系  O 和 Q 不存在偏序关系,比较他们的顺序没有意义  最理想的方案:误差足够小的物理时钟  本质:保证物理世界存在因果性的事件所被标记的逻辑时 间戳具备 Happened Before 关系
  21. 21. 事件排序:Rethinking  我们所在世界的 Happened Before 关系是由光速自然维护的  我们所在世界的物理时钟可能在更高维空间看来是逻辑时钟
  22. 22. 时钟:True Time  特点:足够精确的物理时钟,误差在 7ms 以内  核心思想:利用 TrueTime API 和 Commit Wait Rule 来保证外部一致性  不确定窗口处理方案:写时等待  缺点:需要特殊的硬件支持,不具备普适性  典型系统:Spanner
  23. 23. 时钟:HLC  特点:与物理时钟半同步的逻辑时钟,使用 NTP 同步,误差一般在 250ms 以内  核心思想:在不依赖特殊硬件时,为保证低延迟只能弱化一致性级别  不确定窗口处理方案:读时重试  缺点:对于新增 key 无法保证线性化  典型系统:CockRoachDB  异象:T3 有可能只能查到 T2,查不到 T1
  24. 24. 时钟:TSO  特点:实现递增时间戳的最简单方案  核心思想:抽象出 PD 角色来提供递增时间戳,经过批量异步等优化后能达到百万 TPS 每秒  缺点:跨数据中心事务延时较高  典型系统:TiDB
  25. 25. Distributed-Txn 代码框架介绍 02
  26. 26. Overview TinyKV:有状态的参与者 TinySQL:无状态的协调者
  27. 27. 存储引擎:Engine  基本接口: Get/Put/Delete/Batch  特点:  KV 分离的 LSM 架构,对宽表友好  支持迭代器和前缀扫描  支持垃圾回收  支持事务
  28. 28. 存储引擎:Storage  基本接口: Write/Reader  特点:  支持 Standalone 版本  支持 Raft 版本 -> TinyKV / 6.824
  29. 29. 事务引擎:TinySQL
  30. 30. 事务引擎:TinyKV
  31. 31. 总结
  32. 32. Q & A Thanks!

×