漫谈Google Percolator分布式事务
作者:littlemagic
来源:https://littlemagic.blog.csdn.net/article/details/110732647
前言
前段时间忙双11忙到废寝忘食,这期间又被各种奇奇怪怪的小病折腾了半个多月,整个人状态不是很好,博客也连续吃灰到现在,请看官勿怪。好在今天感觉还不错,可以继续写点东西了。
为了应对业务数据的爆炸性增长以及MySQL业务库分库分表现状的各种不便,笔者的团队近期用一周时间突击调研TiDB,并部署了由16个节点组成的TiDB集群,同时开始逐渐探索利用它替代MySQL的可能性。在调研过程中,我们了解到TiDB能够100%支持ACID事务。并且不同于传统的XA,TiDB采用的是Google提出的Percolator分布式事务协议。本文聊一聊Percolator的部分细节,之后的文章再说它在TiDB事务(包括乐观事务和悲观事务)中的具体应用。
从Bigtable跨行事务到Percolator
Bigtable是Google实现的分布式结构化大数据存储系统,我们耳熟能详的HBase就是Bigtable的开源版本实现。其数据模型可以视为多维的、支持MVCC的K-V Map,即:
(row:string, column:string, timestamp:int64) -> data:string
Bigtable原生支持单行事务,即能够保证一行内一个或多个列族上的多个操作的ACID特性。但是,很多情况下用户都需要在单个事务中更改多行数据,只有单行事务显然不够用。而基于Bigtable的分布式特性,跨行事务与单行事务相比更加复杂,需要注意的三个要点列举如下:
必须有精准的全局授时服务,消除服务器之间时钟无法严格同步的影响,从而保证事务的顺序不会错乱;
必须有高效的全局锁机制,保证两个并发的事务不能同时修改一行数据,并且避免事务出现死锁;
必须高效,在实现ACID语义的基础上不能影响原有系统的吞吐量与并发度。
在这三个要点的基础上,Google的大佬们又设计了Percolator分布式事务协议,借助Bigtable原生的单行事务实现了跨行事务。Percolator的设计理念集中体现在OSDI 2010的一篇论文《Large-scale Incremental Processing Using Distributed Transactions and Notifications》中。下图示出启用Percolator之后的Bigtable服务架构。
Bigtable依靠Chubby(等同于ZooKeeper)提供分布式协调服务。图中的每一个大矩形表示一台服务器,其上运行的服务包括Tablet Server(等同于HBase RegionServer)、Chunk Server(等同于HDFS DataNode),以及新加入的Percolator Worker。另外,还引入了Timestamp Oracle(简称TSO)作为全局授时服务。也就是说,Percolator的实现仅需要增加2个服务,以及在客户端提供与Percolator协议兼容的库。
Percolator事务流程
Percolator事务分为两个阶段:预写(Pre-write)和提交(Commit),本质上相当于一个加强的2PC。另外,所有启用了Percolator事务的表中,每一个列族都会预先增加两个列,分别是:
lock:
存储事务过程中的锁信息;
write:
存储当前行可见(最近一次提交)的版本号。
为了避免混淆,在这里不将其称为时间戳。
另外,为了简化场景,假设存储用户数据的列只有一个,名为data。
预写阶段
客户端启动事务,从TSO获取时间戳,记为start_ts,并向Percolator Worker发起Pre-write请求。
在该事务包含的所有写操作中选取一个作为主(primary)操作,其余的作为次(secondary)操作。
主操作将作为整个事务的互斥点,标记事务的状态。
先预写主操作,成功后再预写次操作。
在预写过程中,对每一个写操作都要执行检查:
检查写入的行对应的write列版本号是否晚于start_ts,如果是,说明有版本冲突,直接取消整个事务;
检查写入的行对应的lock列是否有锁,如果有,说明其他事务正在写,直接取消整个事务。
检查通过后,以start_ts作为版本号将数据写入data列,但不更新write列,亦即此时写入的数据仍然不可见。
对操作行加锁,即更新lock列的锁信息:
主操作行的lock直接标为primary,次操作行的lock则标为主操作行的行键和列名。
注意:处理每一行时,上述步骤3、4、5每次都会在同一个Bigtable单行事务中进行,保证原子性。
提交阶段
客户端从TSO获取时间戳,记为commit_ts,并向Percolator Worker发起Commit请求。
检查主操作行对应的lock列所在的primary标记是否存在,如果不存在(可能已经被清理,见后文所述)则失败,取消事务;
如果存在则继续。
以commit_ts作为版本号,将start_ts更新到write列中。
也就是说在本阶段完成后,预写阶段写入的数据将会可见。
对该行解锁,即删除lock列的锁信息。
若步骤1~4均成功,说明主操作行成功,代表整个事务实际上已经提交。
接下来只需异步地提交每个次操作即可,即重复步骤3、4的更新write列和清除lock列操作。
注意:上述步骤2、3、4会在同一个Bigtable单行事务中进行,保证原子性。另外,如果次操作的提交失败,则仍然要回滚事务。
示例:经典转账流程
下图来自原始论文,描述了Percolator协议下的一次转账流程(Bob向Joe转账$7)。注意每一列中冒号之前的是版本号,冒号之后的则是该列存储的数据。附带的说明清楚易懂,笔者就不多废话了。
要点简析
快照隔离级别
传统关系型数据库中定义的隔离级别有4种(RU、RC、RR、S),而Percolator提供的隔离级别是快照隔离(Snapshot Isolation, SI),它也是与MVCC相辅相成的。SI的优点是:
对于读操作,保证能够从时间戳/版本号指定的稳定快照获取,不会发生幻读;
对于写操作,保证在多个事务并发写同一条记录时,不会有多于一个事务提交成功。
SI下的事务都会带有两个时间戳,即上文讲解Percolator流程时提到的start_ts(下图中空心方块)与commit_ts(下图中实心圆点)。SI硬性要求一个事务提交时的commit_ts大于所有之前产生的start_ts和commit_ts,当然这已经由TSO来保证了。
看图说话:
因为start_ts[2] < commit_ts[1],所以事务1的结果对事务2不可见;
因为start_ts[3] > commit_ts[2] > commit_ts[1],所以事务1和2的结果都对事务3可见;
如果事务1和2写了同一条记录,那么1和2中至少有一个会失败。
SI存在的主要问题是写偏斜(Write-skew),看官可自行查找资料去了解,不再赘述。
分散的锁机制
由上文的描述可以看出,Percolator巧妙地反其道而行之,把事务相关的锁信息分散到了每一行中,并通过将主操作作为互斥点,免去了重新设计一套全局锁机制的麻烦。另外,预写阶段的步骤3中检查到任意锁冲突都会取消事务,简单粗暴地避免了死锁的发生。最后,Percolator构建在带冗余的分布式文件系统(论文的语境中是GFS)之上,所以不必担心锁信息会丢失。
快照读与锁清理
相对于写流程,读流程就简单很多了:从TSO获取当前start_ts,然后检查lock列,判断早于当前start_ts的区间内是否有锁。如果没有,则从write列中根据commit_ts获取到最新提交的start_ts,再根据获取到的start_ts从data列中获取数据。如果有锁,则意味着存在未提交的事务,需要等待持锁的事务提交,才能读取最新的数据。读流程也是在Bigtable单行事务中进行的。
这里会产生两个问题:
第一,为什么不能在有冲突时直接返回版本号小于当前start_ts的最新版本数据?
很显然,基于持锁事务结果的不确定性(可能提交也可能回滚),这样会打破SI对读操作的保证,亦即产生幻读。看官稍稍思考一下即可理解。
第二,如果客户端崩溃或者失联,导致它发起的事务的锁遗留下来,读操作一直不能成功,该怎么办?
答案是由读操作来自主完成,即不会无限等待下去,而是在一定时长的延迟之后直接将卡住的主操作锁信息清理掉,并读取最新版本的数据。
分两种情况讨论:其一,读操作直接读到了原事务中具有primary锁信息的行,说明原事务未提交成功,需要回滚(即清理锁);其二,读操作读到了原事务中具有secondary锁信息的行,此时仍然要去对应的primary行上查找锁是否存在,如果存在,说明原事务未提交成功,将其回滚;如果不存在,说明已提交成功,将其前滚(即清理锁的同时更新对应的write列)。
可见,主操作锁和从操作锁存在的紧密关联能够有效保证Percolator事务的安全性与活性,即:同一事务中的任意两个写操作结果肯定一致,且所有操作的结果要么是提交成功,要么是提交失败。
客户端的作用
如果套用2PC的概念,客户端(在TiDB内部是tikv-client)显然扮演了协调者(Coordinator)的角色。传统2PC的协调者存在单点问题,但是Percolator中的客户端并没有此问题——就算客户端失败,事务也只会有成功与失败两种状态,不会破坏一致性。
有缺点么?
当然有。
网络I/O和RPC的负载较大,事务预写成本较高;
依靠读操作清理锁,如果清理不及时,会增加其他正常事务写冲突的概率;
Percolator锁的本质为乐观锁,如果大量事务并发写热点数据,则根本无法阻塞,造成回滚风暴。
考虑另一个场景:
有一个大事务和很多小事务,且它们的热点overlap,那么大事务可能受小事务的影响进入饥饿状态(即很长时间内无法执行)。
为了克服该问题,TiDB提出了悲观事务模型,不过这就是后话了。
特别推荐一个分享架构+算法的优质内容,还没关注的小伙伴,可以长按关注一下:
http://www.taodudu.cc/news/show-147872.html
相关文章:
- 【Redis】缓存的三大问题及其解决方案
- 如何打造一个经常宕机的业务系统?
- 「系统架构」什么是堡垒机?为什么需要堡垒机?
- Redis为什么变慢了?常见延迟问题定位与分析
- 达摩院基于元学习的对话系统
- 你不好奇缓冲池里的秘密吗?
- 网曝某互联网大厂给员工电脑安装插件,基本等于全程监控!网友:就是监控你们划水!...
- 互联网大厂有哪些分库分表的思路和技巧?
- 微服务场景下的数据一致性解决方案
- 用太极拳讲分布式理论,真舒服!
- 微服务的简介和技术栈
- 如何制定一份永远完不成的年度计划?
- 内存分页不就够了?为什么还要分段?
- MySQL为Null会导致5个问题,个个致命!
- 基于Flink的在线机器学习系统架构探讨
- 前阿里程序员吐槽女友败家:开酒店必须400元起步,工资只有自己的1/3
- CTO点名要搞个灰度发布系统,不慌!
- 某程序员炫耀:因长得太帅被女领导追求,三年就提拔到总监!程序员搞技术没用,健身护肤才是王道!...
- 面试官:关于Spring就问这13个
- 程序员必备基础:如何安全传输存储用户密码?
- 阿里总监辞职回家创业,年利润千万让人羡慕
- 一致性协议算法-2PC、3PC、Paxos、Raft、ZAB、NWR超详细解析
- 全面解析微服务系统监控分层,啃透服务治理核心!
- 4.5万字手把手教你实现MySQL TB级数据存储!!
- 面试官:能说一说Mysql缓存池吗?
- 数据中台已成气候!大数据架构师如何站上风口?
- MyBatis千万级数据查询解决方案,避免OOM
- 我用Redis实现了一个轻量级的搜索引擎!
- 这篇实战攻略,带你轻松入门Elastic search
- 假期三天,我肝了万字的Java垃圾回收,看完你还敢说不会?
漫谈Google Percolator分布式事务相关推荐
- 分布式系统漫谈【拾】_分布式事务一致性:阿里方案
上篇文章:分布式系统漫谈[玖]_分布式事务一致性:协议支持 其实对于生产环境的分布式事务一致,各大互联网公司都是自己实现的解决方案,总结起来无非是异步.补偿.实时查询.定期校对几种模式,大部分场景都是 ...
- 深入理解分布式技术 - 漫谈分布式事务及解决方案
文章目录 什么是分布式事务 数据库事务 隔离级别 Read uncommitted 读未提交 Read committed 读已提交 Repeatable read 可重复读 Serializable ...
- 漫谈分布式事务的那些解决方案
点击上方 好好学java ,选择 星标 公众号 重磅资讯.干货,第一时间送达 今日推荐:牛人 20000 字的 Spring Cloud 总结,太硬核了~ 作者:平头哥的技术博文 链接:https:/ ...
- 分布式事务选型的取舍
来自:DBAplus社群 作者介绍 温卫斌,就职于中国民生银行信息科技部,目前负责分布式技术平台设计与研发,主要关注分布式数据相关领域. 微服务兴起的这几年涌现出不少分布式事务框架,比如ByteTCC ...
- 分布式事务选型的取舍 | 建议收藏
点击上方"朱小厮的博客",选择"设为星标" 回复"1024"获取独家整理的学习资料 微服务兴起的这几年涌现出不少分布式事务框架,比如Byte ...
- 分布式事务方案这么多,到底应该如何选型?
戳蓝字"CSDN云计算"关注我们哦! 作者 | 温卫斌 责编 | 刘晶晶 源自 | dbaplus社群 作者介绍 温卫斌,就职于中国民生银行信息科技部,目前负责分布式技术平台设计与 ...
- SSCC/Domino:分布式事务的突破性进展
Domino(Decrease cOnflict, assist comMIt, NO rollback)是构建在HBase上的分布式事务引擎,支持完整的ACID事务特性.在架构上,Domino与HB ...
- 关于分布式事务、两阶段提交协议、三阶提交协议
随着大型网站的各种高并发访问.海量数据处理等场景越来越多,如何实现网站的高可用.易伸缩.可扩展.安全等目标就显得越来越重要.为了解决这样一系列问题,大型网站的架构也在不断发展.提高大型网站的高可用架构 ...
- 刚柔并济的开源分布式事务解决方案
导读 相比于数据分片方案的逐渐成熟,集性能.透明化.自动化.强一致.并能适用于各种应用场景于一体的分布式事务解决方案则显得凤毛麟角.基于两(三)阶段提交的分布式事务的性能瓶颈以及柔性事务的业务改造问题 ...
最新文章
- cs6 数据库mysql_能mysql内容
- Android项目出现main.xml编译出错和 出现main.out.xml无法编译的解决办法
- String案例 获取一个字符串在另一个字符串中出现的次数(两种方法)
- 关于手机横屏打开相机或者相册闪退解决方案
- 2019计算机组成原理及答案,2019计算机组成原理复习题(一)
- 企业电力征信大数据价值挖掘与应用
- django+xadmin在线教育平台(十二)
- 最新log4j2 远程代码执行漏洞(紧急扩散)
- Delphi 程序开发范例宝典(第2版)高清PDF下载 附光盘
- ultraedit 运行的是试用模式_原来用Unittest框架写接口测试用例这么简单!
- simulink中积分环节、惯性环节、比例环节
- 【数理逻辑三】命题逻辑及形式系统【下】
- 可操作 转载 安装cpan软件包软件包
- 超详细!简单的物联网模块esp8266接入小爱爱同学控制电器(一)——控制开关灯
- dva处理_关于dva框架的二三事
- 瑞芯微RK3328_Demo(1)原理图参考
- 邦邦两拳‾͟͟͞(((ꎤˋ⁻̫ˊ)—̳͟͞͞o
- RS485通信的学习以及思考
- 比较好的Java 网站
- SQL WEEK()函数
热门文章
- Naive Operations (线段树 分析复杂度)
- jasp报错_jetty启动访问jsp页面报错
- luogu P2865 [USACO06NOV]Roadblocks G(次短路模板)
- android自定义tab下划线变大,Android开发之设置TabLayout下方下划线的宽度
- mysql font zhushi_关于在mysql front中使用注释符报错的问题
- 去除菜单项的加速键--‘’符号
- linux下安装python3
- linux下测试磁盘的读写IO速度-简易方法
- 将简历挂到云服务器网站上记
- 第十次课:前台首页设计及显示商品信息