基于阿里微服务架构分布式事务解决方案-FESCAR
分布式事务Fescar中间件使用的总结以及对中间件的认识
分布式系统将不同的web模块部署在不同的服务器上,通过各种中间件将这些分散的web模块集于在一起,方便分布式系统数据的一致性。
FESCAR介绍
FESCAR(Fast & Easy Commit And Rollback) 是一个用于微服务架构的分布式事务解决方案,它的特点是高性能且易于使用,旨在实现简单并快速的事务提交与回滚。
#
微服务架构中的分布式事务问题
从传统的单体应用说起,假设一个单体应用的业务由3个模块组成,三者使用本地数据源。
这样的话本地事务很自然就可以保证每个服务中的数据一致性,但是在微服务架构中就不这么简单了,这3个模块被设计成3个不同的数据源之上的3个服务,每个服务对应一个数据库,本地事务当然也可以保证每个服务中的数据的一致性,但是扩展到整个应用,整个业务逻辑范围来看。
Fescar机制
Fescar就是用于解决上诉微服务架构的事务问题的解决方案。
如下图所示,分布式事务是一个全局事务(Global Transaction),由一批分支事务(Branch Transation)组成,通常分支事务只是本地事务。
Fescar中有三大组件
Coordinator(TC):维护全局和分支事务的状态,驱动全局事务提交与回滚。
Transaction Manager(TM):定义全局事务的范围:开始,提交或回滚全局事务。
Resource Manager(RM):管理分支事务处理的资源,与TC通信以注册分支事务并报告分支事务的状态,并驱动分支事务提交或回滚。
Fescar管理分布式事务的典型的生命周期:
1.TM 要求 TC 开始新的全局事务,TC 生成表示全局事务的 XID。
2.XID 通过微服务的调用链传播。
3.RM 在 TC 中将本地事务注册为 XID 的相应全局事务的分支。
4.TM 要求 TC 提交或回滚 XID 的相应全局事务。
5.TC 驱动 XID 的相应全局事务下的所有分支事务,完成分支提交或回滚。
结论:
这种方式还是有稳定性的问题的,比如TC驱动RM开始提交事务后,RM与TC的连接断开了,都不能保证一致性。另外,由于引入了fescar-server,需要额外保证fescar-server的稳定性。
RM其实充当一个全局的事务管理器,在业务代码完成,提交本地事务的时候,由全局事务管理器统一提交。
还没有评论,来说两句吧...