云溪数据库事务模型简介
一. 架构介绍
从宏观上看,云溪数据库由两部分组成:上层的SQL引擎和下层的作为一个整体的分布式KV数据库。任何针对于数据库的SQL操作,经过SQL引擎的解析之后,都会把它们分解成一组组的kv操作,比如“select * from t”会被分解成scan操作,”update t set a = 1”会被分解成scan和put(conditionalPut)操作......事务主要是在下层的KV数据库对kv操作进行调度,以完成对更底层的存储引擎的并发读写。
二. Percolar事务模型介绍
云溪数据库的事务模型是从Percolator发展而来。Percolator是构建在BigTable之上的,通过提供一个TSO中央授时服务和一个client lib来封装BigTable的接口,最终将BigTable改造成了一个带有ACID快照隔离语义的支持跨行、跨表事务的分布式多维map。
Percolator的特点是没有集中式的事务处理措施,比如中心事务管理器、全局死锁探测器......事务产生的锁也是和数据关联在一起分布式存储的。就事务的角度而言,全局的唯一单点就是TSO。因此Percolator模型具有良好的水平扩展能力。但是也正式这种无中心的实现方式,导致各种冲突处理都需要通过必要的网络交互来实现,所以事务的延迟相对较高。如果照搬这种实现方式,是无法满足OLTP数据库对于高性能的事务处理的要求的。
三. 云溪数据库事务模型介绍
云溪数据库事务模型是从Percolator发展而来的。一方面,它进一步实现了去中心化,通过使用HLC代替TSO,消除了最后一个单点,是系统的水平扩展能力进一步提高;另一方面,它也做了许多努力来减小Percolator模型事务延迟较高的弊端,比如具体的优化有异步释放锁 、 并行提交 、事务流水线、一阶段提交......
1. 标准时间戳排序协议
云溪数据库通过MVCC+实现戳排序协议实现了SSI的事务隔离级别,下面简单介绍一下时间戳排序协议。
在标准时间戳排序协议中,每个事务都有一个唯一固定的时间戳,在事务开始时获取,读、写、提交都在该时间戳上进行。每个数据项保持两个时间戳,W-timestam表示成功执Write(Q)的所有事务的最大时间戳;R-timestamp表示成功执Read(Q)的所有事务的最大时间戳。
1:假设事务Ti发出read(Q)。
- 若TS(Ti)< W-timestamp(Q),则Ti需要读入的Q值已经被覆盖。因此read操作被拒绝,Ti回滚。
- 若TS(Ti)>= W-timestamp(Q),则执行read操作,R-timestamp(Q)被设置为R-timestamp(Q)于TS(Ti)两者的最大值。
2:假设事务Ti发出write(Q)
- 若TS(Ti)< R-timestamp(Q),则Ti产生的Q值是先前面所需要的值,且系统已经假定该值不会再产生因此,write操作被拒绝,Ti回滚。
- 若TS(Ti)< W-timestamp(Q),则Ti试图写入的Q值已经过时。因此,write操作被拒绝,Ti回滚。
- 其他情况,系统执行write操作,将W-timestamp(Q)设置为TS(Ti)。
2. 标准时间戳排序协议的缺陷
标准时间戳排序协议是一个无锁(free lock)的并发控制协议,读写操作都不需要加锁,这虽然能获得高性能,单却存在级联回滚问题和不可恢复调度。
不可恢复调度问题:当txn1回滚时,txn2本来也应该回滚,因为它读的A是txn1写入的。但是由于txn2已经提交,所以没有办回滚,导致数据的一致性被破坏。
级联回滚问题:txn2依赖txn1,txn3依赖txn2,可能会有txn4依赖txn3……当txn1回滚时,会造成大面积的事务回滚。
为了避免上面这两个问题,云溪数据库会对写入的未提交数据加排他锁,这样在类似上面的场景中,txn2和txn3在读A时会被阻塞,直到txn1提交才回放行。这样就不会产生级联问题和不可恢复调度问题。
3. 云溪数据库对标准时间戳排序协议的优化
时间戳排序协议是一个比较乐观的协议,它假设冲突很少发生,因此在事务开启的时候就确定事务也可以在这个时间戳提交,时间戳排序的冲突处理规则就是建立在这个前提之上的,任何出现违反了这个规则的情况都会导致事务回滚。因此在高并发高冲突的场景中,时间戳排序协议的事务回滚率和回滚代价都是比较高的。为了降低回滚率,云溪数据库引入了时间戳forward(push)机制,规则如下:一个事务维护两个时间戳,readTS和writeTS。事务在readTS上执行所有读取操作,以获取一直性快照;所有的写操作在writeTS发生,当遇到RW冲突时,W事务的writeTS forward到冲突时间戳的ts.next,然后继续执行,在必要时刻或者最终提交时进行检查尝试将readTS refresh到writeTS,如果成功,则事务提交,否则事务回滚。
在这个机制之下,当遇到上图的场景时,由于txn1在commit时能把它的readTS refresh到writeTS,所以txn1还是可以提交。但是在标准的时间戳排序协议中,由于txn1 write(B)时发现B的R-Timestamp大于自己的ts,所以事务txn1需要回滚。
4. 云溪数据库事务模型总结
- 没有单点和集中式处理,扩展性好
- 由于同步点机制,任何冲突都需要访问同步点来确认冲突的最终结果,网络交互多
- 锁和数据一起存储,每个写操作都会给存储引擎产生两三倍的写入压力,冲突处理流程曲折
- HLC的时钟偏移太大,在某些场景下对同一数据的W、R容易导致重试
- 时间戳排序并发控制协议比较乐观、导致事务容易重试和回滚,且代价较大
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
云端技能包 | 百亿级日志之云原生实时流实战(2)
上一期内容中,我们简单为大家介绍了fluentd、docker和日志采集器的架构。现在,我们开始实操。 【 SpotMax 解决方案充分利用了云原生特性,基于微服务架构,可在保障用户服务稳定的同时充分利用Spot实例,实现云端降本增效。戳链接了解SpotMax】 首先来看一下dockerfile,我们可以去fluentd的官网上(docs.fluentd.org)获取基础镜像: 然后我们可以通过run加上一些命令,对容器做初始化: 有了docker file,我们就可以通过docker build,来创建一个镜像。-t后面是镜像名称,冒号:后面是一个版本: 创建完镜像之后,我们可以通过docker image,获取镜像列表: 我们也可以把镜像推到远程docker hub里。Docker hub是官网的远程管理功能,可以免费注册: 我们通过docker login登录之后,再通过docker push就可以把镜像推送到远程了: 现在已经有了一个镜像,我们来run一个container。 首先,跑一个临时的容器。--rm代表运行临时容器,--network host代表用一个host的网络...
- 下一篇
【更新公告】跨平台自动化测试方案 Airtest 更新至 1.2.4
本次更新为 Airtest 更新,版本提升至 1.2.4 版本。 PS:AirtestIDE 暂未更新 ,1.2.12版本的 IDE 自带的 Airtest 版本仍是 1.2.3 版本,不是最新的 1.2.4 版本。 更新详情 1)新增对Android12的支持 新增Android 12的minicap截图支持。 如果在1.2.12版本的IDE中,连接不上Android12的设备,可以在本地python环境把Airtest更到1.2.4版本后,连接Android12的设备跑一个脚本之后,再用1.2.12版本的IDE来连接该设备。(当然,后续更新了AirtestIDE的版本之后,就可以直接连接,无需进行这些操作) 2)修复了1个启动录屏失败的问题 安卓在录屏强制中止的情况下,下一次启动录屏时优先清理之前的录屏再开始新录屏,有效避免了启动录屏失败的问题。 旧版本在录屏强制终止的情况下,重新开始录屏可能会出现如下的报错(需要手动结束录屏或者单独运行结束录屏的脚本之后才能正常重新开启录屏): 3)优化了部分手机的输入问题 部分手机如oppo/vivo等,在没有安装/启用yosemite输入法时...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7,8上快速安装Gitea,搭建Git服务器
- 设置Eclipse缩进为4个空格,增强代码规范
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Mario游戏-低调大师作品
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- MySQL8.0.19开启GTID主从同步CentOS8