Doris数据库BE——Stream load流程中事务状态

这篇具有很好参考价值的文章主要介绍了Doris数据库BE——Stream load流程中事务状态。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

Doris数据库BE——Stream load流程中事务状态,Doris,数据库
Stream Load的事务管理由FE负责,Doris的事务状态包括:PREPARE、COMMITTED、VISIBLE和ABORTED。
Doris数据库BE——Stream load流程中事务状态,Doris,数据库
数据导入开始之前,Coordinator BE节点会向FE发送Begin Transaction请求,FE会为当前label开启一个新的事务,并为事务分配Transaction Id,同时将事务状态设置为PREPARE,然后将Transaction Id以及Begin Transaction成功的信息返回给Coordinator BE。

当数据在所有Executor BE节点完成写入之后,Coordinator BE节点会向FE发送Commit Transaction请求,FE会判断每一个Tablet成功写入数据的副本数量是否超过了Tablet副本总数的一半,如果每一个Tablet成功写入数据的副本数量都超过Tablet副本总数的一半(多数成功),则Commit Transaction成功,并将事务状态设置为COMMITTED;否则,向Coordinator BE返回Commit Transaction失败的信息。COMMITTED状态表示数据已经成功写入,但是数据还不可见,需要继续执行Publish Version任务,此后,事务不可被回滚。

当从FE获取导入计划失败、执行数据导入失败或Commit Transaction失败时,Coordinator BE节点会向FE发送Rollback Transaction请求,执行事务回滚。FE收到事务回滚的请求之后,会将事务的状态设置为ABORTED,并通过Thrift RPC向Executor BE发送Clear Transaction的请求,Clear Transaction任务在BE节点异步执行,将数据导入生成的Rowset标记为不可用,这些Rowset在之后会从BE上被删除。状态为COMMITTED的事务(Commit Transaction成功但Publish Version超时的事务)不能被回滚。

FE会有一个单独的线程对Commit成功的Transaction执行Publish Version,FE执行Publish Version时会通过Thrift RPC向Transaction相关的所有Executor BE节点下发Publish Version请求,Publish Version任务在各个Executor BE节点异步执行,将数据导入生成的Rowset变为可见的数据版本。当Executor BE上所有的Publish Version任务执行成功,FE会将事务状态设置为VISIBLE,并向Coordinator BE返回Commit Transaction以及Publish Version成功的信息。如果存在某些Publish Version任务失败,FE会向Executor BE节点重复下发Publish Version请求直到之前失败的Publish Version任务成功。如果在一定超时时间之后,事务状态还没有被设置为VISIBLE,FE就会向Coordinator BE返回Commit Transaction成功但Publish Version超时的信息(注意,此时数据依然是写入成功的,只是还处于不可见状态,用户需要使用额外的命令查看并等待事务状态最终变为VISIBLE。)

TCC 指的是Try - Confirm - Cancel。Try 指的是预留,即资源的预留和锁定。Confirm 指的是确认操作,这一步其实就是真正的执行了。Cancel 指的是撤销操作,可以理解为把预留阶段的动作撤销了。一个分布式的全局事务,整体是两阶段提交的模型。TCC也是一样的,单相对应2PC和3PC来说,把事务管理从数据库层面,提取到了业务层面。
TCC第一阶段:try行为,试探性操作
TCC第二阶段:confirm或cancel操作,第一阶段成功就会调用confirm,失败就会cancel操作
TCC还需要一个全局事务管理者的角色,用来记录TCC全局事务状态并提交或回滚事务
Doris数据库BE——Stream load流程中事务状态,Doris,数据库
由于TCC每一步操作都需要业务上的定义,对于一个操作都要写三个方法对应try、confirm、cancel。因此TCC对业务的侵入性比较大和业务是紧耦合的关系。但是因为TCC是业务上的实现,所以他的适用范围更广,可以跨数据库、跨不同的业务系统来实现事务。

事务控制代码都需要开发去写,所以需要做好异常控制:

空回滚允许-现象是try没有被执行,就调用了cancel。

出现原因:Try超时(丢包)、分布式事务回滚触发cancel、未收到try收到cancel

解决办法:让cancel能够识别出这是一个空回滚,可以记录事务执行状态,cancel中判断try是否执行了。

幂等控制

事务协调着会重复调用,try、confirm、cancel三个方法都需要实现幂等控制

解决办法:记录事务执行状态,如果执行过了,就不再执行。

防悬挂控制-Cancel比Try先执行

出现原因:Try超时(拥堵)、分布式事务回滚触发cancel、拥堵try到达

解决办法:记录事务执行状态,try执行时判断cancel是否执行了。

并发控制

Doris的事务模型中的Coordinator BE就是TCC中的使用者,FE就是TCC中的事务管理者,Executor BE就是TCC中的服务A。

  1. 调用者向事务管理者发起事务相当于Coordinator BE节点向FE发送Begin Transaction请求(当然还有向FE获取导入计划的交互流程未体现);

  2. 调用者向服务调用try,相当于Coordinator BE向Executor BE分发数据;

  3. 服务向调用者返回结果相当于Executor BE向Coordinator BE返回数据写入成功与否;

  4. 调用者向事务管理者发送提交命令即是Coordinator BE节点向FE发送Commit Transaction请求;

  5. 事务管理者向服务调用confirm相当于FE对commit成功的Transaction执行Publish Version,也就是通过Thrift RPC向Executor BE节点下发Publish Version请求。 (当然还有当Executor BE上所有的Publish Version任务执行成功,FE会向Coordinator BE返回Commit Transaction以及Publish Version成功的信息。如果存在某些Publish Version任务失败,FE会向Executor BE节点重复下发Publish Version请求直到之前失败的Publish Version任务成功)

当然对于第四步,调用者向事务管理者发送回滚命令相当于当从FE获取导入计划失败、执行数据导入失败或Commit Transaction失败时,Coordinator BE节点会向FE发送Rollback Transaction请求,执行事务回滚。事务管理者在收到回滚命令后会向服务发送Cancel请求相当于FE收到事务回滚的请求之后,会通过Thrift RPC向Executor BE发送Clear Transaction的请求。文章来源地址https://www.toymoban.com/news/detail-685226.html

到了这里,关于Doris数据库BE——Stream load流程中事务状态的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • datagrip或navicat连接doris数据库

    首先一般在公司连的话会有一个vpn证书 公司一般内部都会提供vpn的工具 你导入这个vpn证书的配置文件到工具即可连接公司的数据库 首先看datagrip连接doris 新建一个datasource 选择mysql 然后填入对应的ip地址和端口9030 先测试连接 test 成功的话就点击apply 再点击ok  navicat更加简单

    2024年02月11日
    浏览(46)
  • Apache Doris 数据库有哪些应用场景?

    首先声明,本人无意叛变,依然是ClickHouse的忠实信徒。 对于Doris,一直听圈内的人在说,吹得神乎其神,但到底有多强,从来没有真正的去尝试一把。 直到这次,被人狠狠上了一课。 在一次全文检索的模糊查询的场景PK中,ClickHouse一败涂地,让本人很是没面子,咳咳,大哥

    2024年01月22日
    浏览(48)
  • 聊聊分布式 SQL 数据库Doris(五)

    阅读 Doris SQL 原理解析,总结下Doris中SQL解析流程: 词法识别:解析原始SQL文本,拆分token 语法识别:将token转换成AST 单机逻辑查询计划:将AST经过一系列的优化(比如,谓词下推等)成查询计划,提高执行性能与效率。 分布式逻辑查询计划:根据分布式环境(数据分布信息

    2024年02月05日
    浏览(52)
  • 聊聊分布式 SQL 数据库Doris(四)

    FE层的架构都能在网上找到说明. 但BE层的架构模式、一致性保障、与FE层之间的请求逻辑,数据传输逻辑等,我个人暂时没有找到相应的博客说明这些的。当然这些是我个人在学习与使用Doris过程中,对内部交互逻辑与实现感兴趣才有这些疑问. 还好现在有GPT这类大模型,有了

    2024年02月05日
    浏览(57)
  • 分布式数据库Apache Doris简易体验

    📢📢📢📣📣📣 哈喽!大家好,我是【IT邦德】,江湖人称jeames007,10余年DBA及大数据工作经验 一位上进心十足的【大数据领域博主】!😜😜😜 中国DBA联盟(ACDU)成员,目前服务于工业互联网 擅长主流Oracle、MySQL、PG、高斯及Greenplum运维开发,备份恢复,安装迁移,性能优

    2024年02月06日
    浏览(58)
  • 聊聊分布式 SQL 数据库Doris(七)

    Doris的存储结构是类似LSM-Tree设计的,因此很多方面都是通用的,先阅读了解LSM相关的知识,再看Doris的底层存储与读取流程会清晰透彻很多,LSM基本知识如下: 原理:把各种数据先用log等形式组织在内存中(该数据结构称为MemTable,且有序);到达一定数据量后再批量merge写入磁

    2024年02月05日
    浏览(47)
  • 聊聊分布式 SQL 数据库Doris(九)

    优化器的作用是优化查询语句的执行效率,它通过评估不同的执行计划并选择最优的执行计划来实现这一目标。 CBO: 一种基于成本的优化器,它通过评估不同查询执行计划的成本来选择最优的执行计划。CBO会根据数据库系统定义的统计信息以及其他因素,对不同的执行计划进

    2024年02月05日
    浏览(47)
  • 聊聊分布式 SQL 数据库Doris(六)

    此处的负载均衡指的是FE层的负载均衡. 当部署多个 FE 节点时,用户可以在多个 FE 之上部署负载均衡层来实现 Doris 的高可用。官方文档描述: 负载均衡 。 实现方式 实现方式有多种,如下列举。 开发者在应用层自己进行重试与负载均衡。 JDBC Connector 发现一个连接挂掉,就自

    2024年02月05日
    浏览(52)
  • 聊聊分布式 SQL 数据库Doris(一)

    MPP:Massively Parallel Processing, 即大规模并行处理. 一般用来指多个SQL数据库节点搭建的数据仓库系统. 执行查询的时候, 查询可以分散到多个SQL数据库节点上执行, 然后汇总返回给用户. Doris 作为一款开源的 MPP 架构 OLAP 高性能、实时的分析型数据库,能够运行在绝大多数主流的商

    2024年02月05日
    浏览(44)
  • 聊聊分布式 SQL 数据库Doris(二)

    Doris中,Leader节点与非Leader节点和Observer节点之间的元数据高可用和一致性,是通过bdbje(全称:Oracle Berkeley DB Java Edition)的一致性和高可用实现的。 元数据与同步流程 元数据主要存储四类数据: 用户数据信息. 包括数据库, 表的schema, 分片信息等 各类作业信息. 如导入作业, clo

    2024年02月05日
    浏览(66)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包