微服务架构之分布式事务

本文深入探讨了微服务架构风格及其独立部署的特点,详细解释了分布式事务的处理方式,包括本地事务、跨库事务及微服务事务。对比分析了XA/JTA规范的两阶段提交协议与TCC在资源锁持有上的差异,以及柔性事务在CAP理论和BASE理论下的应用,为读者提供了丰富的分布式系统设计思路。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、微服务

  • 微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。
  • 系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。
  • 每个微服务内聚不同的业务模块。

二、分布式事务

  • 本地事务  
  • 分布式事务-跨库事务   
  • 分布式事务-微服务

三、XA/JTA规范

  • 两阶段提交协议(2PC)

 

 

TCC与XA/JTA对比:

XA是资源层面的分布式事务,强一致性,在两阶段提交的整个过程中,一直会持有资源的锁。

TCC是业务层面的分布式事务,最终一致性,不会一直持有资源的锁。

 

四、柔性事务

  • CAP理论     

       开发大规模的分布式系统时会遇到三个特性:一致性(Consistency)、可用性(Availability)、分区容错(Partition-tolerance),而一个分布式系统最多只能满足其中的两项。     

     分区容错性是分布式系统必然需要面对和解决的问题,因此系统架构师往往需要把精力花在如何根据业务特点在C(一致性)和A(可用性)之间寻求平衡。而前面我们提到的JTA 两阶段提交协议的分布式事务方案,强调的就是一致性;由于可用性较低,实际应用的并不多。

  • BASE理论

基本可用(Basically Available):指分布式系统在出现不可预知故障的时候,允许损失部分可用性

软状态( Soft State):指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

最终一致( Eventual Consistency): 强调的是所有的数据更新操作,在经过一段时间的同步之后,最终都能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值