想要深入理解分布式事务，看这篇就足矣

导读概述

随着业务的快速发展，业务复杂度越来越高，大部分互联网公司几乎都会从单体走向分布式，特别是转向微服务架构，随之而来就必然遇到分布事务这个难题。

本文主要介绍一下Seata是如何保证数据一致性的,将从以下几个方面介绍一下分布式实现方案

1、介绍一下分布式理论(此部分如果已经掌握了可以跳过，看下面部分分享)

2、什么是Seata

3、Seata AT模式下如何解决分布式事务，应用场景

4、Seata TCC模式下如何解决分布式事务、应用场景、变种场景使用

5、Seata 下的Saga模式

本文以下单占库存案例为主线分享Seata分布式解决方案。

分布式理论

什么是事务？

指的就是一个操作单元，在这个操作单元中的所有操作最终要保持一致的行为，要么所有操作都成功，要么所有的操作都被撤销。

使用事务目的是什么

说明白了就是保证数据的一致性。

什么是本地事务呢

我们常常指的是关系型数据库的事务，关系型数据库事务四大特性:

• Atomicity（原子性) ：要么都成功，要么都失败。

• Consistency(一致性): 在事务开始之前和事务结束以后，数据库的完整性没有被破坏，完整性包括外键约束、应用定义的等约束不会被破坏。

• Isolation（隔离性):数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。

• Durability(持久性):事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
  

优点：可以保证单机数据库层面的数据一致性。

为什么要使用分布式事务

分布式事务在分布式环境下，为满足可用性、性能与降级服务的需要，降低一致性与隔离性的要求，一方面遵循 BASE 理论

• 基本业务可用性（Basic Availability）

• 柔性状态（Soft state）

• 最终一致性（Eventual consistency）

同样的，分布式事务也部分遵循 ACID 规范：

• 原子性：严格遵循

• 一致性：事务完成后的一致性严格遵循；事务中的一致性可适当放宽

• 隔离性：并行事务间不可影响；事务中间结果可见性允许安全放宽

• 持久性：严格遵循

需求是这样的：

随着业务发展在微服务架构下,【订单服务】和【库存服务】在两个业务系统里，同时分别调用对应的订单DB和库存DB，要求保证：要么库存和订单下单一起成功，如果库存占用和订单下单有一方失败要么就要回滚，保证数据的一致性。

此时场景数据库级别的事务就有些捉襟见肘了，此时分布式事务就派上用场了。

分布式事务常见解决手段有哪些呢？

两阶段提交2PC、三阶段提交3PC、TCC、SAGA、本地消息表、基于可靠消息保证最终一致、最大努力通知等方案。

由于分布式事务方案，无法做到完全的ACID的保证，没有一种完美的方案，能够解决掉所有业务问题。因此在实际应用中，会根据业务的不同特性，选择最适合的分布式事务方案。

什么是分布式事务呢？

1、分布式事务：

• 首先应用于分布式系统场景，分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
• 例如在电商系统中，下单接口通常会扣减库存、添加优惠券、生成订单 id, 而订单服务与库存、添加优惠券、下单接口的成功与否，不仅取决于本地的 db 操作，而且依赖第三方系统的结果，这时候分布式事务就保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

2、常见使用场景：

如用户注册送积分事务、创建订单减库存事务，银行转账事务等都可以应用分布式事务，分布式事务就是为了保证在分布式场景下，数据操作的正确执行。

提到分布式场景就绕不开CAP理论，三者只能满足两点，来解决分布式场景的问题，那么接下来先了解一下什么是CAP。

CAP原则

CAP 原则又称 CA