Saga分布式事务模式

Saga是一种分布式事务模式,以一种补偿的方式保证数据的一致性,每一个事务的参与者,拥有一个正向的提交操作方法,和一个逆向的回滚方法。

Saga的特点

Saga由事件驱动、无锁、高性能、高吞吐,易于理解,易于实现,事务参与者之间异步执行,是一种针对长业务流程长事务的解决方案。

缺点

Saga无法保证ACID模式下的隔离性。

传统ACID事务在分布式CAP定理的束缚下,逐渐走向了最终一致性的柔性事务中,也就常说的BASE。Saga中每个事务的参与者在收到正向操作请求时,会立即提交事务。如果发生异常,由事务协调者发出回滚请求,处理者执行回滚操作。

Saga操作模式更像发电子邮件,发出的电子邮件是正确的,接收者按正常方式解读。如果,邮件发错了,就再发一封告诉接收者,请忽略上一封邮件。在实际的实现中很多时候都是将错就错,因为,有可能第二封邮件到达时,事情已经变得不可逆了。

比如,付完款后,后续流程的事务不能执行成功,通知付支付流程回滚事物,回滚操作检查数据时,发现数据已被其他事务做了修改,无法执行回滚,只能让支付的后续流程不断的重试,以期望流程顺序走完,最坏的结果是从业务角度入手,先“长款”后续引入退款操作。

Saga不像传统2PC/ACID事务,任何一个事务参与者失败,立即同步执行回滚操作,Saga所有操作都是异步执行。

Saga如何实现ACID

原子性

在Saga中事务任何一个步骤失败,都调用回滚接口实现撤销。

一致性/完整性

服务内部的本地事务由数据库保证,跨服务的数据完整性由应用完成。

持久性

由数据库保证

隔离性

Saga模式决定不能保隔离性,可通过引入事件溯源实现隔离性,但并不一定适用所有场景,在Saga整个事务没有结束期间,操作都以事件的方式记录下来,当需要查询数据时,通过回放事件,对数据进行动态计算。

Saga两种实现模式

Orchestration:事务统一由中心点协调者发出,服务只需按要求执行正向提交或逆向回滚。

Choreography:正向提交由上一个服务发起,逆向回滚由后一个事务发出。

Orchestration模式下的协调者通常是一个状态机,状态机在很长一段时间内都是编程的核心概念,非常适合以快速,可预测的性能协调许多小型组件。此状态机引擎应基于事件驱动架构,过程都是异步的,两个过程之间通过事件队列流转。这种流程引擎不一定要自行开发,可以选择如AWS Step Functions这类产品。

Choreography模式使用事件概念,订单服务处理完订单,发起一个支付事件,支付服务接受事件并以事件的方式告知是否通过。事件是解耦利器但同时增加了开发难度,对于遵循DDD领域事件的应用相对容易很多。

Orchestration特点

避免服务之间的循环依赖。

Choreography特点

事务参与者只需要发出事件。

Saga中操作应具备的特性

幂等的( idempotent)

请求和补偿请求都必须是幂等的。

可交换的(commutative)

补偿请求必须是可交换的,因为,消息可能不按顺序到达。在分布式Saga的上下文中,回滚请求可能在正向操作请求之前到达。

Saga保证

Saga要么所有请求都成功完成,要么所有回滚操作都能成功执行。