【分布式事务】最终一致性解决方案

对于分布式事务一般采用的都是最终一致性方案，而不是强一致性。而在使用最终一致性的方案时，一定要提到的一个概念是状态机。

什么是状态机？是一种特殊的组织代码的方式，用这种方式能够确保你的对象随时都知道自己所处的状态以及所能做的操作。它也是一种用来进行对象行为建模的工具，用于描述对象在它的生命周期内所经 历的状态序列，以及如何响应来自外界的各种事件。

状态机这个概念大家都不陌生，比如TCP协议的状态机。同时我们在编写相关业务逻辑的时候经常也会需要处理各种事件和状态的切换，比如switch、if/else。所以我们其实一直在跟状态机打交道，只是可能没有意识到而已。在处理一些业务逻辑比较复杂的需求时，可以先看看是否适合用一个有限状态机来描述，如果可以把业务模型抽象成一个有限状态机，那么代码就会逻辑特别清晰，结构特别规整。

比如我们来简单描述一个订单，以支付为例，一笔订单可能会有等待支付、支付中、已支付等状态，那么我们就可以先去把可能出现的状态以及状态的流程画出来。

状态机的作用:

1. 实现幂等
2. 通过状态驱动数据的变化
3. 业务流程以及逻辑更加清晰，特别是应对复杂的业务场景

幂等

简单来说：重复调用多次产生的业务结果与调用一次产生的业务结果相同；

例如：存款100元，ATM重发了5次，核心系统一共处理了6次，余额增加了600元。会发生重复调用的情况：

• 在分布式架构中，我们调用一个远程服务去完成一个操作，除了成功和失败以外，还有未知状态，那么针对这个未知状态，我们会采取一些重试的行为；
• 或者在消息中间件的使用场景中，消费者可能会重复收到消息。

对于这两种情况，消费端或者服务端需要采取一定的手段，也就是考虑到重发的情况下保证数据的安全性。一般我们常用的手段有：

1. 状态机实现幂等：即关注点是状态是否发生变化，若已经是更新后的状态，那么再收到调用请求也不做更新
2. 数据库唯一约束实现幂等
3. 通过tokenid的方式去识别每次请求判断是否重复

1.最大努力通知方案

2.TCC两阶段补偿方案

TCC是Try-Confirm-Cancel， 比如在支付场景中，先冻结一笔资金，再去发起支付。如果支付成功，则将冻结资金进行实际扣除；如果支付失败，则取消资金冻结

• Try阶段：完成所有业务检查（一致性），预留业务资源（准隔离性）
• Confirm阶段：确认执行业务操作，不做任何业务检查，只使用Try阶段 预留的业务资源。
• Cancel阶段：取消Try阶段预留的业务资源。Try阶段出现异常时，取消所有业务资源预留请求

3.基于可靠性分布式消息队列

就像RocketMQ提供了事务消息机制

4.开源的分布式事务解决方案

GTS / Seata /TX-LCN

最后

以上就是狂野煎饼为你收集整理的【分布式事务】最终一致性解决方案的全部内容，希望文章能够帮你解决【分布式事务】最终一致性解决方案所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。