分布式场景之刚性事务-2PC详解
分布式一致性
分布式场景下,多个服务同时对服务一个流程,比如电商下单场景,需要支付服务进行支付、库存服务扣减库存、订单服务进行订单生成、物流服务更新物流信息等。如果某一个服务执行失败,或者网络不通引起的请求丢失,那么整个系统可能出现数据不一致的原因。
上述场景就是分布式一致性问题,追根到底,分布式一致性的根本原因在于数据的分布式操作,引起的本地事务无法保障数据的原子性引起。
分布式一致性问题的解决思路有两种,一种是分布式事务,一种是尽量通过业务流程避免分布式事务。分布式事务是直接解决问题,而业务规避其实通过解决出问题的地方(解决提问题的人)。其实在真实业务场景中,如果业务规避不是很麻烦的前提,最优雅的解决方案就是业务规避。
事务分类
分布式事务实现方案从类型上去分刚性事务、柔型事务。刚性事务:通常无业务改造,强一致性,原生支持回滚/隔离性,低并发,适合短事务。柔性事务:有业务改造,最终一致性,实现补偿接口,实现资源锁定接口,高并发,适合长事务。
刚性事务:XA 协议(2PC、JTA、JTS)、3PC
柔型事务:TCC/FMT、Saga(状态机模式、Aop模式)、本地事务消息、消息事务(半消息)
2PC定义
2PC全称Two-phaseCommit,中文名是二阶段提交,是XA规范的实现思路,XA规范是 X/Open DTP 定义的交易中间件与数据库之间的接口规范(即接口函数),交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。XA 接口函数由数据库厂商提供。
X/Open DTP是X/Open 组织(即现在的 Open Group )1994定义的分布式事务处理模型。XA规模型包括应用程序( AP )、事务管理器( TM )、资源管理器( RM )、通信资源管理器( CRM )四部分。一般,常见的事务管理器( TM )是交易中间件,常见的资源管理器( RM )是数据库,常见的通信资源管理器( CRM )是消息中间件。
2PC 通常使用到XA中的三个角色TM、AP
AP:事务发起方,通常为微服务自身;定义事务边界(事务开始、结束),并访问事务边界内的资源
TM:事务协调方,事务操作总控;管理事务全局事务,分配事务唯一标识,监控事务的执行进度,负责事务的提交、回滚、失败恢复。
RM:本地事务资源,根据协调方命令进行操作;管理本地共享资源(既数据库)。
2PC流程
2PC 分成2个阶段,第一阶段:请求阶段(commit-request phase,或称表决阶段,voting phase)和第二阶段:提交阶段(commit phase)。
表决阶段:事务协调者(TM)串行给每个参与者(RM)发送Prepare消息,每个参与者要么直接返回失败,要么在本地SQL执行、记录事务日志(Undo、Redo),但不提交,到达一种“万事俱备,只欠东风”的状态。
可以进一步将准备阶段分为以下三个步骤:
1)TM串行向每个参与者节点询问是否可以执行提交操作,并等待各参与者节点的响应。
2)参与者节点执行询问的所有SQL语句,并将Undo和Redo写入日志。
3)各参与者节点响应TM发起的询问。如果参与者节点的事务操作实际执行成功,则返回一个”success”消息;如果参与者节点的事务操作实际执行失败,则返回一个”abort”消息。
提交阶段:如果TM收到了参与者的失败消息或者超时,直接给每个参与者发送回滚(Rollback)消息;否则,发送提交(Commit)消息;参与者根据TM的指令执行提交或者回滚操作,释放所有事务处理过程中使用的锁资源。(注意:必须在最后阶段释放锁资源)
分支一--当TM从所有参与者节点获得的相应消息都为”success”时:
1)TM向所有参与者节点发出”正式提交(commit)”的请求。
2)参与者节点正式完成操作,并释放在整个事务期间内占用的资源。
3)参与者节点向TM发送”完成”消息。
4)TM受到所有参与者节点反馈的”完成”消息后,完成事务。
分支二--如果任一参与者节点在第一阶段返回的响应消息为”abort”,或者 TM在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时:
1)TM向所有参与者节点发出”回滚操作(rollback)”的请求。
2)参与者节点利用之前写入的Undo信息执行回滚,并释放在整个事务期间内占用的资源。
3)参与者节点向TM发送”回滚完成”消息。
4)TM受到所有参与者节点反馈的”回滚完成”消息后,取消事务。
不管最后结果如何,第二阶段都会结束当前事务。
总结
2PC虽然将XA规范方案细化成思路,也形成了流程图,大部情况下确实能提供原子性操作,但是仍存在一定问题,所以又出现了3PC。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
SOFAMosn v0.13.0 发布,云原生网络代理平台
MOSN v0.13.0 发布报告如下: 新功能 支持 Strict DNS Cluster@dengqian 支持 GZip 处理的 Stream Filter@wangfakang Dubbo 服务发现完成 Beta 版本@cch123 支持单机故障隔离的 Stream Filter@NeGnail 集成 Sentinel 限流能力@ansiz 优化 优化 EDF LB 的实现,使用 EDF 重新实现 WRR LB@CodingSinger 配置获取 ADMIN API 优化,新增 Features 和环境变量相关 ADMIN API@nejisama 更新 Host 时触发健康检查的更新从异步模式修改为同步模式@nejisama 更新了 Dubbo 库,优化了 Dubbo Decode 的性能@zonghaishang 优化 Metrics 在 Prometheus 中的输出,使用正则过滤非法的 Key@nejisama 优化 MOSN 的返回状态码@wangfakang Bug 修复 修复健康检查注册回调函数时的并发冲突问题@nejisama 修复配置持久化函数没有正确处理空配...
- 下一篇
Apache架构师总结的30条设计原则
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 【编者的话】本文作者叫Srinath,是一位科学家,软件架构师,也是一名在分布式系统上工作的程序员。他是Apache Axis2项目的联合创始人,也是Apache Software基金会的成员。他是WSO2流处理器(wso2.com/analytics)的联席架构师。Srinath撰写了两本关于MapReduce和许多技术文章的书。他获得了博士学位。来自美国印第安纳大学。 Srinath通过不懈的努力最终总结出了30条架构原则,他主张架构师的角色应该由开发团队本身去扮演,而不是专门有个架构师团队或部门。Srinath认为架构师应该扮演的角色是一个引导者,讨论发起者,花草修建者,而不是定义者和构建者。Srinath为了解决团队内部的架构纷争和抉择,制定了以下30条原则,这些原则被成员们广泛认可,也成为了新手架构师的学习途径。 基本原则 原则1:KISS(Keep it simple, sutpid)保持每件事情都尽可能的简单。用最简单的解决方案来解决问题。 原则2:YAGNI(You ar...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS8安装Docker,最新的服务器搭配容器使用
- 设置Eclipse缩进为4个空格,增强代码规范
- Red5直播服务器,属于Java语言的直播服务器
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS7,8上快速安装Gitea,搭建Git服务器