Saga分布式事务模式

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

特点

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

缺点

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

传统ACID事务在分布式CAP定理束缚下,走向了最终一致性的柔性事务中,也就常说的BASE

Saga中每个事务的参与者在收到正向操作请求时,立即提交事务。

如果发生异常,由事务协调者发出回滚请求,处理者执行回滚操作。

Saga操作模式更像发电子邮件,发出的电子邮件是正确的,接收者按正常方式解读。

如果,邮件发错了,就再发一封告诉接收者,请忽略上一封邮件。

实际实现时都是将错就错,因为,有可能第二封邮件到达时,事情已经变得不可逆了。

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

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

如何实现ACID

原子性

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

一致性

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

持久性

由数据库保证。

隔离性

Saga模式决定不能保隔离性,通过引入事件溯源实现隔离,不一定适用所有场景。

整个事务没有结束时,操作以事件方式记录下来,当查询数据时,回放事件,对数据执行动态计算。

两种实现模式

Orchestration

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

此模式下的协调者通常是一个状态机。

状态机在很长一段时间内都是编程的核心概念,适合以快速可预测的性能协调许多小型组件。

此状态机引擎应基于事件驱动架构,过程都是异步的,两个过程间通过事件队列流转。

这种流程引擎不一定要自行开发,可选择如AWS Step Functions这类产品。

Orchestration特点,避免服务间的循环依赖。

Choreography

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

此模式使用事件概念,订单服务处理完订单,发出一个支付事件,支付服务接受事件,以事件方式告知是否通过。

事件是解耦利器同时增加了开发难度,对遵循DDD领域事件的应用相对容易很多。

Choreography特点,事务参与者只需发出事件。

操作应具备的特性

幂等( idempotent)

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

可交换(commutative)

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

Saga保证

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