在单体应用程序中,事务通常是在单个数据库或单个操作系统中管理的,而在微服务架构中,事务需要跨越多个服务和数据库,这就使得事务管理变得更加复杂和困难。
目录
一句话导读
一、微服务事务管理的定义和意义
二、微服务事务管理的策略
1.使用Saga模式:
2.两阶段提交(2PC):
3.异步消息
4.分布式事务协调器
5.补偿机制
三、分布式事务CAP原则
1.一致性(Consistency)
2.可用性(Availability)
3.分区容忍性(Partition Tolerance)
四、微服务事务管理的挑战
1.原子性
2.一致性
3.隔离性
4.持久性
图(1)
上图是一个经典的微服务事务管理示意图,当客户下单时,订单服务聚合层接收到下单请求,将操作拆分成不同请求分发到不同服务中,如在订单服务中创建订单,在支付服务中创建支付订单,在库存服务中扣减库存,这些操作要么都成功要么都失败,这就是微服务的事务管理的基本特性。
目前,关于微服务事务管理的研究已经取得了许多成果。例如,二阶段提交协议(2PC)、补偿事务(Compensating Transactions)、Saga模式等都是解决分布式事务问题的常用方法。
Saga是一种将大型事务拆分为一系列较小事务的模式。每个微服务都有自己的Saga,处理自己的事务,如果某个步骤失败,可以触发回滚或者补偿操作。
Saga 模式的核心思想是,将长时间跨多个服务的大型事务拆分为多个小的本地事务,这些本地事务可以在系统中不同的节点上并行执行。每个本地事务都有一个对应的补偿操作,用于撤销该事务的影响。这种设计使得如果某个事务失败,系统可以通过执行补偿操作来回滚之前的操作,以保持数据的一致性。
图(2)
相对应图(1),图(2)多了一个失败回滚接口
2PC是一种协调多个事务参与者以确保所有参与者都同意提交或回滚的协议。尽管2PC具有一定的复杂性和性能开销,但在某些情况下仍然是一个有效的解决方案。"2" 表示协议有两个阶段,而 "PC" 表示这两个阶段的操作
图(3)
使用消息队列来实现异步通信,将事务操作转化为消息,由接收方处理。这种方式可以减少分布式事务的复杂性。
一些分布式事务协调器,如TCC(Try-Confirm-Cancel)和XA协议,可以用来处理分布式事务的协调和管理。
在某些情况下,事务失败后可以通过执行逆向操作来进行补偿,确保数据的一致性
CAP定理指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)和分区容忍性(Partition Tolerance)这三个属性无法同时完全满足,最多只能同时满足其中的两个。
图(4)
所有节点在同一时间具有相同的数据副本,即每个读操作都能够读到最近一次的写操作。
每个非故障节点在合理的时间内都能够响应请求,即系统随时可用并能够处理请求。
即使网络分区(节点之间的通信故障)发生,系统仍然能够继续运行,保持一致性和可用性。
我们知道,在单体应用中事务的管理是基于关系型数据库的事务机制实现的,因为单体应用只使用了一个数据库,每个操作都是在该数据库中进行。但是微服务却不一样,每个服务有自己的数据库,跨服务、跨数据库的事务管理就非常复杂了。单体应用的事务特性ACID对于微服务来说就是很大的挑战
事务被视为一个不可分割的最小单位,多个操作组合形成一个事务,这些操作要么全部执行,要么全部不执行。
在分布式环境中,要确保多个微服务的操作要么全部成功,要么全部回滚,以维护数据的一致性。实现原子性和一致性需要精心的设计和实现。
分布式事务需要处理并发操作,确保不同事务之间的操作不会相互干扰。保持隔离性是必要的,但也可能影响性能。
在微服务架构中,不同微服务的数据可能存储在不同的数据库中。确保分布式事务在各种故障情况下仍能保持持久性是一个挑战。
除了以上ACID挑战外还有如下: