微服务的数据一致性

Posted 2020-11-02 开拖拉机的蜡笔小新

在微服务架构下，每个服务对应一个数据库，这就出现了原来单体中对同一个库的操作变成了跨服务数据库的操作。

遇到有事务约束的场景，比如转账汇款、订单状态和库存扣减，就从本地事务过渡到分布式事务来了。 

 

可以用利用最终一致性解决这个问题

最终一致性：不同服务节点再一段时间后，节点间的数据会最终达到一致的状态

有两种方法可以完成最终一致性 ：

1.可靠性事件模式

前序事件发生，后序事件一定发生。可靠性事件的缺点是不能回滚。一般借助消息队列和内部表来完成。

支付宝余额转账到余额宝余额为例： 

当发起一个请求到支付宝服务的时候，支付宝会执行扣款事件，并将这个事件记录下来，并且发送消息到余额宝服务，之后余额宝执行加款事件并将该消息投递到支付宝服务，支付宝服务得到该条消息后删除事件记录。如果余额宝服务出现故障，支付宝服务一直没有接受到回送的消息，定时任务会检测该事件一直存在数据库当中，并一直发送消息给余额宝直到余额宝服务恢复加款后回送消息支付宝给删除记录。

消息方案从本质上讲是将分布式事务转换为两个本地事务，然后依靠下游业务的重试机制达到最终一致性。基于消息的最终一致性方案对应用侵入性也很高，应用需要进行大量业务改造，成本较高。

 

2.补偿事务-sagsas模型

sag是一系列有序本地事务，每个本地事务通过更新数据库或者发送消息来触发下一个本地事务。

每一个本地事务都会发送消息并确认消息，如果本地事务失败，sag会有序的执行补偿事务来回滚刚才的操作。它的特点就是支持回滚。

 

每一个事务都有发送消息和接收确认消息的操作

该方案比较复杂，目前还没有开源框架来支持。

 

3.GTS-阿里分布式事务解决方案

GTS是一款分布式事务中间件，由阿里巴巴中间件部门研发，可以为微服务架构中的分布式事务提供一站式解决方案。

性能超强

GTS通过大量创新，解决了事务ACID特性与高性能、高可用、低侵入不可兼得的问题。单事务分支的平均响应时间在2ms左右，3台服务器组成的集群可以支撑3万TPS以上的分布式事务请求。

应用侵入性极低

GTS对业务低侵入，业务代码最少只需要添加一行注解（@TxcTransaction）声明事务即可。业务与事务分离，将微服务从事务中解放出来，微服务关注于业务本身，不再需要考虑反向接口、幂等、回滚策略等复杂问题，极大降低了微服务开发的难度与工作量。

完整解决方案

GTS支持多种主流的服务框架，包括EDAS，Dubbo，Spring Cloud等。 有些情况下，应用需要调用第三方系统的接口，而第三方系统没有接入GTS。此时需要用到GTS的MT模式。GTS的MT模式可以等价于TCC模式，用户可以根据自身业务需求自定义每个事务阶段的具体行为。MT模式提供了更多的灵活性，可能性，以达到特殊场景下的自定义优化及特殊功能的实现。

 

GTS与微服务的集成

GTS包括客户端（GTS Client）、资源管理器（GTS RM）和事务协调器（GTS Server）三个部分。GTS Client主要用来界定事务边界，完成事务的发起与结束。GTS RM完成事务分支的创建、提交、回滚等操作。GTS Server主要负责分布式事务的整体推进，事务生命周期的管理。GTS和微服务集成的结构图如下所示，GTS Client需要和业务应用集成部署，RM与微服务集成部署。

参考资料：GTS来了！阿里微服务架构下的分布式事务解决方案