千家信息网

怎么理解web开发中的分布式事务

发表于:2024-11-12 作者:千家信息网编辑
千家信息网最后更新 2024年11月12日,这篇文章主要讲解了"怎么理解web开发中的分布式事务",文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习"怎么理解web开发中的分布式事务"吧!capC:一致
千家信息网最后更新 2024年11月12日怎么理解web开发中的分布式事务

这篇文章主要讲解了"怎么理解web开发中的分布式事务",文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习"怎么理解web开发中的分布式事务"吧!

cap

C:一致性被称为原子对象,任何的读写都应该看起来是"原子",或串行的。写后面的读一定能读到前面写的内容,所有的读写请求都好像被全局排序。

A:对任何非失败节点都应该在有限时间内给出请求的回应。(请求的可终止性)

P:允许节点之间丢失任意多的消息,当网络分区发生时,节点之间的消息可能会完全丢失

个人理解:

  1. 对于C,就是保证在一个时间点各个节点的状态是一致的,而A是在用户的视角看来各个节点都是正常的,P就是在节点看开各个节点都是正常连接

  2. 但在分布式环境中,多实例部署是基本条件,因为网络的不可靠性,造成了P成了硬性条件,所以分布式系统基本都是cp和ap的

base

  1. 基本可用(Basically Available)

  2. 软状态(Soft State)

  3. 最终一致性(Eventually Consistent)

个人理解:

  1. base理论落地基本都是ap的系统,分布式事务和业务有着强耦合的关系,因为基本上业务层面要维持一个中间状态好让事务可以有回滚余地而不破坏数据

  2. 其次因为有中间状态所以在事务的过程中基本都是最终一致

xa

如图基本分以下三种角色

  1. AP 应用程序

  2. RM 资源管理器

  3. TM 事务管理器

个人理解:

  1. 基本各个资源管理器要实现各自的资源管理接口

  2. 应用程序向资源管理器申请资源,然后对资源的修改不是直接通知资源管理器,而是预先准备好,然后由三方的事务管理器统一进行修改

  3. 使用该协议的系统基本都是cp类型的系统

2pc/3pc

2pc:

个人理解:

  1. 在prepare阶段对事务执行完毕剩下事务提交,只要一处执行出问题就触发事务回滚

  2. 在提交阶段由于网络问题可能会有不一致的问题

  3. 各个事务之间相互依赖成功,锁定资源的时间过长(阻塞时间过长)

  4. 对于事务协调器有超时重新选举,但是各个服务没有超时机制

3pc:

个人理解:

在2pc之上增加了一层,个人理解这一层是为了辅助超时阶段,因为在preCommit阶段事务已经就剩下提交其他服务也都确认成功,最后每个服务都会启动一个超时计划,到时直接提交而不是等待协调器来docommit, 而docommit就是提交命令,但是各个服务可能因为网络无法接收所以有个超时机制,也就是为了弥补2pc中的阻塞过长和服务端没有超时机制

tcc

个人理解:

  1. tcc本质就是base中的业务提供一种中间态,通过准备提交和回滚来完成整体事务

  2. 整体增加了事务管理器来自动化的进行管理事务的进程,比如宕机后事务管理器会定时的去执行日志记录中事务的进程保证最终一致性

  3. 一般分布式事务都会传递全局事务id来标识事务和解决幂等性

sega

个人理解sega很像2pc但是sega的事务都是自己提交自己的,对于集中式出问题由主业务进行回滚或者重试,对于分布式而是递归的形式进行回滚

上述的几个问题

  1. 整体上我这样理解,sega是最终一致性的,但是又不会有base的中间状态,所以会有隔离性的问题,容易出现幻读重复度,读更改等各种问题,对于解决方案一般都是sega对应的框架自行提供全局读写锁来进行提供隔离性

  2. 对于sagas框架来看,他实现了事务协调器来简化事务的回滚和重试,实现了一套自行生成回滚sql的机制来进行

  3. 对于sagas还有很多设计,目前个人没有时间研究后续研究透了会重写相关sagas的问题(对于sagas历史好像最开始是阿里收费项目gks,当时看人反汇编代码说实现可能是自动生成回滚代码的tcc,现在看来是saga的模式加全局锁)

sega2种回滚方案

  1. backward recovery,向后恢复,补偿所有已完成的事务,如果任一子事务失败。即上面提到的第二种执行顺序,其中j是发生错误的sub-transaction,这种做法的效果是撤销掉之前所有成功的sub-transation,使得整个Saga的执行结果撤销。

  2. forward recovery,向前恢复,重试失败的事务,假设每个子事务最终都会成功。适用于必须要成功的场景,执行顺序是类似于这样的:T1, T2, ..., Tj(失败), Tj(重试),..., Tn,其中j是发生错误的sub-transaction。该情况下不需要Ci

集中式

分布式


消息事务/本地消息事务


感谢各位的阅读,以上就是"怎么理解web开发中的分布式事务"的内容了,经过本文的学习后,相信大家对怎么理解web开发中的分布式事务这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是,小编将为大家推送更多相关知识点的文章,欢迎关注!

0