分布式事务的目的是保证分布式系统中的多个参与方的数据能够保证一致性。即所有参与者,在一次写操作过程中要么都成功,要么都失败。
至于这个一致性到底是怎样的一致性,是强一致性、还是最终一致性,不同的分布式事务方案其实达到的效果并不相同。
如果想要实现强一致性,那么就一定要引入一个协调者,通过协调者来协调所有参与者来进行提交或者回滚。所以,这类方案包含基于XA规范的二阶段及三阶段提交、以及支持2阶段提交。
如果想要实现最终一致性,那么方案上就比较简单,常见的基于可靠消息的最终一致性(本地消息表、事务消息)、最大努力通知等。
可靠消息实现最终一致性的方案其实就是借助支持事务消息的中间件,通过发送事务消息的方式来保证最终一致性,过程及原理可以参考——RocketMQ的事务消息是如何实现的?
另外,还有我们比较熟知的TC,他也是最终一致性的一种实现方案。只不过他比基于消息的最终一致性要稍微更加靠近强一致性一些。或者说他的不一致性的时长会更短。
另外,还有一些分布式事务的组件,如Seata,他其实是一个开源的分布式事务解决方案,旨在为微服务架构提供高效目透明的事务管理。在讨论 Seata 的一致性特性时,需要明确其支持的不同事务模式,因为每种模式对一致性的保证不同。
AT 模式:尽管设计为提供强一致性,但在分布式系统中完全实现强一致性是具有挑战性的,尤其是在面对网络分区或节点故障时。因此,尽管AT模式致力于达到强一致性,它在某些故障场景中可能只能保证最终一致性
TCC 和 Saga 模式:这两种模式都设计为支持最终一致性。它们允许更大的灵活性和可伸缩性,因为它们通过明确的补偿机制来处理事务的不同阶段,从而逐步达到全局的一致性。