050、事务设计之Percolator事务模型

Percolator 背景

050、事务设计之Percolator事务模型_第1张图片

  • Bigtable: 大表打散每行到各个节点,每一行作为一个kv。
  • 解决的问题
    一个事务涉及的行在多个节点,如何用单行对一个事务进行控制,实现原子性。

快照隔离级别(snapshot )

050、事务设计之Percolator事务模型_第2张图片
白色点:代表事务开始时间
黑色点:代表事务结束时间

事务2是不能看到事务1的修改(事务2的开始时间是早于事务1的提交时间)
事务3的开始时间是晚于事务1和事务2的提交时间,所以都能看到。

快照隔离级别类似可重复读,事务能读到的数据都是事务开始那一刻能看到的数据。

分布式时钟

分布式时钟: 给事务分配时间标识
050、事务设计之Percolator事务模型_第3张图片

Percolator 事务执行流程

050、事务设计之Percolator事务模型_第4张图片
050、事务设计之Percolator事务模型_第5张图片
050、事务设计之Percolator事务模型_第6张图片
primary key: 选择任一一行作为主行,这里不是说主键
050、事务设计之Percolator事务模型_第7张图片
prewrite
其它行也加锁(但这个锁的内容是指向主行),所以真正的锁只有一把在主行上。
如果此时其它行 无法加这个锁,则表示其他行正在被其它事务写入,则此时当前这个事务会报错,把指向的主行上面的锁也清掉。 (相当于整个分布式事务直接回滚)
050、事务设计之Percolator事务模型_第8张图片

Percolator 案例

  • 修改数据
    050、事务设计之Percolator事务模型_第9张图片
  • prewrite
    050、事务设计之Percolator事务模型_第10张图片
  • 提交主行

050、事务设计之Percolator事务模型_第11张图片

  • 主行提交完毕,提交其它行
    050、事务设计之Percolator事务模型_第12张图片
    如果主行提交完成,其它行提交异常(数据库down了),其实是不影响事务的一致性。因为重新发起事务后,发现上面有个锁(记录主锁信息)发现主锁已经清理,则此时会将lock当中的信息清掉,保持其他行已提交。

优缺点

  • 优点
    • 实现简单
    • 基于单行的事务基础上,实现了跨行事务
    • 去中心化的锁管理
  • 缺点
    • 需要管理中心化的版本号
    • 网络交互较多

你可能感兴趣的:(TiDB从入门到精通,tidb)