分布式事务的解决思路与方案 - 日理万妓 2022-08-28 08:53 136阅读 0赞 ### 导航 ### * 一、事务的种类与场景 * 二、分布式事务解决方案 * * 2.1 全局事务 * 2.2 可靠消息事务 * 2.3 最大努力通知 * 2.4 TCC 事务 # 一、事务的种类与场景 # 本地事务实际上就是指数据库的事务,参考《[MySQL —— 事务与隔离级别总结][MySQL _]》 分布式事务指的是在分布式环境下,由多个本地事务组成,多个系统之间如何保证事务之间的原子性、一致性等问题。例如多个系统访问同一个数据库,多个系统访问多个数据库,等等这些场景,都数据分布式事务的讨论范围。 # 二、分布式事务解决方案 # 介绍四个业界应用比较广泛的分布式解决方案:全局事务、可靠消息服务、最大努力通知、TCC事务(补偿型事务)。 ## 2.1 全局事务 ## 全局事务基于DTP 模型实现,这是由X/Open 组织提出的一种分布式事务模型,全称为“**分布式事务处理参考模型**”。 DTP规定要实现分布式事务,需要三种角色: > AP:Application 应用系统 > TM:Transaction Manager 事务管理器 > RM:Resource Manager 资源管理器 在 DTP 模型中,整个系统的事务分为两个阶段,即 2PC(2 Phrase Commit): > 1、准备阶段:也可以叫表决阶段或投票阶段。TM 向 各个 AP 发送准备命令,并告诉各本地事务即将提交事务。TM同步等待参与者的响应。此阶段各本地事务已经完成了事务逻辑,就差一步提交操作。 > 2、提交阶段:TM 根据响应结果,决定发送提交或回滚命令。若都准备成功,则提交事务;但只要有一个返回失败,就全部回滚。 ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_20_color_FFFFFF_t_70_g_se_x_16] 全局事务的优缺点: > **优点**:由于是同步阻塞协议,因此可以保证数据的强一致性。资源管理器本身就是数据库,实现不需要增加太多的代码逻辑,实现成本低。流程简单。 > **缺点**: > 1、单点故障问题:TM 是全局事务的协调者、管理者,绝不能出现单点故障问题。 > 2、同步阻塞:增加了资源阻塞时间,可能存在死锁的风险,需要增加超时机制。 > 3、一致性问题:二阶段提交可能存在失败的情况,导致数据不一致。 > > 总之,该模型是旨在保证强一致性的全局事务模型,但由于其模型仍然简单粗糙,在实际生产中,还需要进一步扩展和细化。 ## 2.2 可靠消息事务 ## 基于可靠消息服务的方案是通过消息中间件保证上、下游应用数据操作的一致性。基本可以理解为就是 RocketMQ提供的事务消息,参考《[Spring Cloud —— RocketMQ 的消息类型][Spring Cloud _ RocketMQ]》 假设有A和B两个系统,分别可以处理任务A和任务B。此时存在一个业务流程,需要将任务A和任务B在同一个事务中处理,就可以使用消息中间件来实现这种分布式事务。 ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_20_color_FFFFFF_t_70_g_se_x_16 1] ## 2.3 最大努力通知 ## 最大努力通知也被称为定期校对,其实是对可靠消息事务方案的进一步优化。它引入了本地消息表来记录错误消息,然后加入失败消息的定期校对功能,来进一步保证消息会被下游系统消费。 这种方案由于本身需要引入许多额外的补偿结构,如本地消息表、失败消息表、定期校对者等等,增加了业务耦合度,提高了实现复杂度,因此在业界并不是特别流行,但不得不说的确是增加了系统事务的安全性降低了事故风险。 ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_20_color_FFFFFF_t_70_g_se_x_16 2] 第一步:消息由A系统投递到中间件 > 1、处理业务的同一事务中,向本地消息表中写入一条记录 > 2、准备专门的消息发送者,轮询本地消息表,将需要发送的(未发送的或失败的)事务消息发送到中间件 第二步:消息由中间件投递到B系统 > 1、消息中间件收到消息后负责将该消息同步投递到下游系统,并触发下游系统的任务执行 > 2、当下游系统处理成功后,向消息中间件反馈确认应答,消息中间件便可以将该消息删除,表示该事务完成 > 3、如果投递失败,增加重试机制,对重试失败的,写入错误消息表 > 4、消息中间件需要提供失败消息的回查接口,下游系统会定期查询失败消息,自行消费。 优点:一种非常经典的分布式事务解决方案,最大限度保证最终一致性。 缺点:消息表会耦合到业务系统中,如果没有封装好的解决方案,会有很多杂活需要处理。 ## 2.4 TCC 事务 ## TCC 即为 Try Confirm Cancel,它属于补偿型分布式事务,业务层面的分布式事务。其中: > **Try**:指的是预留,即资源的预留和锁定。 > **Confirm**:确认,其实就是真正的执行提交。 > **Cancel**:撤销,就是回滚、撤销锁定动作。 同样,TCC模型也有一个全局的管理者或协调者角色,用来记录TCC全局事务状态,并提交或回滚事务。 TCC模型的难点在于业务上的定义,对每一个操作都需要定义三个动作分别对应 try-confirm-cancel例如,预留操作,需要明确预留或锁定的业务资源。因此TCC是业务耦合型分布式事务,需要根据特定的场景和业务逻辑来设计相应的操作。另外,确认或撤销操作可能需要重试,因此需要保证操作的幂等。 TCC相较于2PC、3PC,其优点在于可以**跨数据库**,**跨业务**来实现事务,但缺点也显而易见,就是开发量大,业务耦合度高。 TCC 两阶段提交与 XA 两阶段提交的区别: > XA 是资源层面的分布式事务,强一致性,在两阶段提交的整个过程中,会一直持有资源的锁。 > TCC 是业务层面的分布式事务,最终一致性,不会一直持有资源的锁。 [MySQL _]: https://blog.csdn.net/u014745069/article/details/103420050 [watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/a783885acce44f1eb3fdcf1e15134008.png [Spring Cloud _ RocketMQ]: https://blog.csdn.net/u014745069/article/details/120606895?spm=1001.2014.3001.5501 [watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/ea65f38fd9e74fc6925e2f59353e073b.png [watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/b52297c4e2504fc4b562e38f0f47ee16.png
还没有评论,来说两句吧...