分布式事务（一）--分布式事务理论基础

• 一、参考内容：
• 二、微服务、分布式、集群的区别：
• 三、背景：
• 四、分布式环境下，如何保证数据一致性？
  • 1、背景：
  • 2、核心业务链路：
• 五、方案：
• 六、使用：
• 七、总结：
• 八、分布式事务选型调研：
• 九、生产环境如何使用分布式事务的？

一、参考内容：

分布式事务入门

二、微服务、分布式、集群的区别：

假如现在有个电商系统，会有很多业务模块，用户系统、营销系统、商品系统、购物车系统等。

微服务：我们采用SOA（面向服务的架构）模型，把这些功能模块拆分出来，做成一个个服务，user-center，promotion-center等，这个就是微服务。

分布式：这些微服务之间通过良好的接口和协议联系起来。此时就要考虑如何部署这些微服务了，可以部署到一个或多个服务器上。分布式指的是这些服务部署在不同的机器上。

微服务和分布式的区别：多个微服务可以选择部署在单台机器，也可以在多台机器上，而分布式必须部署在多台机器。

集群：商城系统可以是一个单体应用/多个业务模块。可以把单体应用或者用户模块的微服务部署到多个服务器上，这样多个服务器提供了相同的服务，这就是所谓的集群。

三、背景：

在单体项目中，不需要使用分布式事务，一个系统对应一个数据库，事务在本地数据库的事务就可以了。

但是微服务环境下，服务之间的调用，数据库是分开的，无法通过本地数据库事务保证了。

四、分布式环境下，如何保证数据一致性？

1、背景：

一个微服务系统，每个服务都有自己的DataBase。

2、核心业务链路：

订单服务 --> 库存服务 --> wms服务 --> 积分服务

假如前面的流程都成功了，最后积分服务出现了异常，前面如何进行回滚。

五、方案：

XA、TCC、可靠消息最终一致性方案、最大努力通知方案、Sega、Atomikos等。。。

六、使用：

类似上面涉及到支付的链路，要使用TCC来保证强事务。例如将订单服务、积分服务、库存服务绑定到一个TCC事务中，这三个服务要保证强一致性。
PS：这里只是举例，实际业务场景，积分可能是通过MQ异步处理的。

wms服务可以使用可靠消息最终一致性方案保证事务。就是通过消息中间件，保证一定会把消息交给下游的仓储服务，仓位服务消费消息然后通知发货。如果失败了，中间件一定要不停重试投递消息，保证一定要成功。

七、总结：

强一致方案：主要用于核心模块，例如交易/订单等等。

最终一致性方案：一般用于边缘模块例如库存，通过mq去通知，保证最终一致性，也可以业务解耦。

八、分布式事务选型调研：

ByteTCC，Himly，TCC-Transaction：
类似TCC事务的开源框架，由个人开发，star在3-6k，会有一些中小型公司生产环境用了类似的分布式事务框架，知名度和普及型不高。

seata(fescar)：
阿里开源的分布式事务框架，支持TCC、Saga等事务模式，这个框架是经历过阿里生产环境大量的考验的一个框架。支持dubbo、spring cloud两种服务框架，比较推荐seata。

基于RabbitMQ、Kafka实现可靠消息最终一致性方案。

RocketMQ：作为MQ中间件，提供了分布式事务支持，但是如果使用，性能影响较大。

九、生产环境如何使用分布式事务的？

如果在事务里，有些操作特别的耗时，可以做成异步化。
同时还要将这个异步化的操作包裹到一个事务中去，此时就可以使用可靠消息最终一致性的方案。

在事务里，有些操作无关紧要，是否成功都行，而且还比较耗时，例如发送短信，发送邮件，发送一个通知等。
即使失败了是无关紧要的，可以使用最大努力通知方案。

TCC方案适合于多个服务的操作都比较快，例如：资金转账、创建订单、抽奖机会、积分、流量券相关的服务调用的逻辑。
包裹在一个分布式事务内，用TCC来控制这个分布式事务，因为这里的一些操作基本都是在流量充值中心内部的一些服务，都比较快。