ui做的好的网站,建设网络平台的技术服务合同交印花税吗,聊城做网站信息,公众号修改wordpress目录
前言
1.sharding的分布式事务
2.分布式事务的产生原因
3.分布式事务的解决方案
3.1.DTP模型
3.2.分阶段提交
3.3.TCC模式
3.4.可靠消息服务
3.5.AT模式
3.6.Seata 前言
本文是前面一篇文章聊了基于sharding的分库分表后拓展出来的关于分布式事务的讨论#xf…目录
前言
1.sharding的分布式事务
2.分布式事务的产生原因
3.分布式事务的解决方案
3.1.DTP模型
3.2.分阶段提交
3.3.TCC模式
3.4.可靠消息服务
3.5.AT模式
3.6.Seata 前言
本文是前面一篇文章聊了基于sharding的分库分表后拓展出来的关于分布式事务的讨论本文中将详细讲一下sharding中的分布式事务以及市面上常见的分布式事务解决方案。
1.sharding的分布式事务 Sharding JDBC Sharding JDBC 提供了对分布式事务的支持。它通过两阶段提交2PC协议来实现跨多个数据源的分布式事务。Sharding JDBC 会将事务中的操作发送到各个数据源执行并在提交阶段协调所有数据源的提交操作以保证事务的一致性。 Sharding Proxy Sharding Proxy 本身并不直接支持分布式事务。它主要是一个中间件负责路由和转发客户端的 SQL 请求到后端的多个数据源。在 Sharding Proxy 中跨多个数据源的事务操作会被拆分成多个独立的本地事务每个数据源独立处理。这就意味着在 Sharding Proxy 中跨多个数据源的事务并不会保证全局的一致性需要应用程序自行处理分布式事务的逻辑。
sharing jdbc后在spring boot中如何使用分布式事务代码示例 Service
public class MyService {
Autowiredprivate JdbcTemplate jdbcTemplate;
Transactionalpublic void performDistributedTransaction() {// 在事务范围内执行数据库操作jdbcTemplate.update(INSERT INTO table1 (column1) VALUES (?), value1);jdbcTemplate.update(INSERT INTO table2 (column1) VALUES (?), value2);// 手动抛出异常模拟事务中的异常情况throw new RuntimeException(Simulated exception);}
} 是的你没看错不用任何额外的配置就是用spring的事务即可。因为sharding jdbc作为一个分库分表的技术栈天生就有分布式事务问题所以其默认就是开启分布式事务的它的事务都是两阶段提交的。
说到分布式事务我们来回顾一下之前聊过的分布式事务的内容。
2.分布式事务的产生原因 分布式事务是指在在分布式架构下一个事务中的不同子操作是在不同机器上执行的子操作之间状态无法相互感知其中有子操作出错后其他机器上的子操作无法正确回滚。
分布式事务产生的根本原因各个服务之间无感知
举一个例子
一个下单事务包含创建订单库存服务需要顺序调用订单服务、库存服务。如果库存服务挂掉后订单服务也是无法回滚的因为订单服务感知不到库存服务是否成功即无法感知到库存服务的状态。 3.分布式事务的解决方案 3.1.DTP模型 1994年X/Open组织即现在的Open Group定义了分布式事务处理的DTP模型该模型包括几个角色
应用程序AP服务事务管理器TM全局事务管理者资源管理器RM一般是数据库通信资源管理器CRMTM和RM之间的通信中间件
DTP模型中一个分布式事务全局事务可以被拆分成多个本地事务运行在不同的AP和和RM上。每个本地事务的ACID由自身保证全局事务必须保证每个本地事务必须同时成功若有一个失败其他事务必须回滚。由于本地事务之间相互是无法感知状态的因此要通过CRM来通知各个本地事务同步事务执行的状态。
由于各个本地事务之间需要通信通信就需要标准因此配套提出了XA通信标准。XA规定了DTP中CRM和TM之间的通信的接口规范定义了用于通知事务开始、提交、终止、回滚等接口各个数据库厂商之间必须实现该接口。
3.2.分阶段提交 分阶段提交也叫两阶段提交two-phase commit。DTP模型落地实现的一种思想。
两阶段提交中将事务分成两个阶段来执行
阶段一准备阶段各个本地事务执行自己事务内的逻辑完成提交前的准备工作。阶段二执行阶段各个事务根据上一阶段的执行结果进行提交或者回滚。
两阶段提交中有两个角色协调者coordinator、参与者voter。
正常情况 异常情况
准备阶段协调者会询问每个参与者是否可以执行事务每个事务参与者执行事务写入redo、undo日志然后反馈事务的执行结果只要有一个参与者返回的是disagree则说明失败协调者会像各个参与者发出abort指令各个事务收到指令后各自回滚事务。 两阶段提交的优点
方案成熟很稳能保证强一致性
两阶段提交的缺点
单点故障当协调者挂了之后后续的步骤就没办法进行了被锁住的数据没办法解锁会造成阻塞。数据锁定分阶段提交由于过程被拆成两段会造成本地事务的执行过程变长数据会长时间处于锁定状态。
3.3.TCC模式 TCC模式是专门用来解决分阶段提交的缺陷的减少数据锁定避免阻塞问题。
TCC相当于是强化了两阶段提交在分阶段提交中埋入了以下几个点位
try资源的检测和预留。confirm执行的业务操作提交要求try成功的话confrim一定要能成功。cancel预留资源释放
经过TCC的强化埋点后两阶段提交变成了
准备阶段。try资源预留通知每个参与者去try一下数据资源判断一下数据资源是否足以支撑之后的事务运行。每个参与者均try成功再执行下一步否则直接cancel。执行阶段confrim让协调者通知各个参与者执行并提交事务因为资源已经准备好了执行和提交可以一气呵成各个参与者confrim成功则成功但凡有一个失败则通知协调者组织全局回滚、释放资源、退出。 TCC的优点
TCC其实每个阶段都是单独的事务try其实是个事务只是去摸一下看下阶段要的数据资源是否能用confrim则是原来的包含业务逻辑的事务。这样的话就避免了两阶段提交中agree过程中对于数据的锁定尽量避免了影响其他事务的执行。
TCC的缺点
编码成本存在代码侵入需要开发人员手动编写TCC三步开发的成本会比较高。弱一致性TCC保证的是最终一致性因为单个本地事务的执行和提交都包含在confirm一个步骤中如果出现问题回滚前其实是没有保证一致性的在这中间有其他读操作进来是能读到已经变动的数据的。
3.4.可靠消息服务 可靠消息服务起源自eBay是将各个服务的本地事务串成一个链依托MQ来保障分布式事务比如服务A执行完服务后向MQ中存放自己执行成功的信息MQ再向服务B推送消息叫它执行本地事务服务B执行完本地事务后又告诉MQMQ继续向后续要执行本地事务的服务推送消息。 缺点
由于是MQ主动向后续服务推送消息后续服务要是失败了前置服务感知不到前置服务无法进行感知回滚。。所以可靠消息服务适用的场景有限。
3.5.AT模式 AT模式是Alibaba的seata组件开源出来的一种分布式事务解决方案是对TCC的一种优化解决了TCC模式中的的代码侵入、编码复杂等问题。
AT模式中用户只需关注自己的业务SQLseata框架会自动生成书屋的二阶段提交和回滚操作。
AT模式整个流程和TCC大致相同不同点是在于AT模式将执行放在了一阶段
一阶段开发者实现正常编写业务逻辑然后执行SQL执行本地事务并返回执行结果。二阶段框架托管根据一阶段的结果判断二阶段的做法提交或者回滚。 AT模式的底层原理 在阶段一的时候拦截下所有SQL框架会去解析这条SQL然后去数据库中查询出要操作的数据存一份镜像叫before image接下来执行SQL执行完SQL后再查询一次存一份叫after image。
到了阶段二的时候比对before镜像和after镜像从而判断操作是否成功如果一阶段的所有本地事务操作都是成功的就会清空before镜像和after镜像如果有一个是失败的各个本地事务就会根据属于自己的before镜像进行回滚。
after镜像是为了在回滚的时候进行比对要是回滚时发现数据库中此时的数据和after镜像中记录的数据不相同则说明数据又被动过了产生了脏数据此时就需要人工介入了。由于行锁的存在产生脏数据的概率很低很低after镜像只是留了一手。
AT模式中的角色 AT模式中一共有三个角色
TC服务协调者是一个单独的服务。TM通信中间件。RM资源管理器管理分支的事务处理与TC进行通信注册分支事务和报告事务状态驱动分支事务提交或者回滚。
TM、RM和服务是耦合在一起的但是不侵入代码以jar包的方式体现。
3.6.Seata Seata是目前为止常用、流行切稳定的分布式事务解决方案其在使用上对代码没有侵入直接是基于配置的使用方法见官方手册即可。在遇到分布式事务场景时可以优先考虑使用seata来解决。
