Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。这句话是官方描述，有两个知识点：分布式，事物。
在了解seata之前我们先说下分布式和事物。
分布式：
分布式是从原来单一服务演变过来的。
单一服务臃肿，耦合，扩展性差等缺点，当某个功能点挂了全盘皆挂。当然优点是结构简单，易于开发维护。
当上述单一服务不满足于业务发展则出现了伪分布式的架构，通过Nginx进行反向代理，对于客户来说访问的地址是一样的，但是对于系统来说是分开处理的。优点是扩展性比单一服务强很多，但是同样所有功能都耦合到一个服务，臃肿，代码可读性差等缺点依然存在。
接下来真正的分布式服务架构出现了，同时提出来一个微服务的概念，对原有臃肿的服务进行拆分，根据业务或者模块功能划分为多个服务，这种服务我们统称它为微服务。每个微服务之间可以互相依赖调用(rpc)同时也为上层服务提供支撑，当前市面比较流行的rpc框架有dubbo,spring cloud。分布式服务架构优点：可扩展性增强，系统高可用，代码划分清晰，耦合大大降低。当然随之而来的问题就出现了：部署复杂，运维难度提高，架构的学习曲线大，代码实现需要考虑更多东西等，当然本节讲的分布式事物也在其中。
本章分布式架构不会再细讲，接下来我们铺垫下事物
事物：
数据库事务( transaction)是访问并可能操作各种数据项的一个数据库操作序列，这些操作要么全部执行,要么全部不执行，是一个不可分割的工作单位。事务由事务开始与事务结束之间执行的全部数据库操作组成。
上述文本是百科描述，总结为简单的一句话：不可分割的工作单位，具有原子性，一致性，持久性，隔离性。此章节不会去详细讲解事物的组成与原理。
使用seata的业务场景
1.分布式数据库事物(一个服务操作多个数据库)。
当一个数据库支撑不起我们的业务，我们会想办法优化数据库。通过业务将数据划分多个模块分别存放到不同的数据库中；或者对一张大表进行的横向切割。这样我们普通的事物失效了，夸库了。
2.分布式服务事物(一次请求多个服务处理)
在分布式服务中，一次业务处理需要多个服务参与完成。当夸服务普通的事物也会失效。举个很简单的场景：
小伙伴们可以自己想一下。
3.分布式数据库+分布式服务事物
虽然可以在每个服务中加上事物，但也只能保障自身数据正确，我们现在需要的是数据的最终一致性，这三个服务中的数据要摸一起成功要摸一起失败，保障原子性。
分布式事物理论基础
CAP和BASE大家想要深入了解看下网上资料，看着很高大上，其实就是一句话：最终一致性。
为了实现最终一致性，我们引入2PC：两阶段提交协议。
事物管理器协调资源管理器，第一阶段是各个资源管理器的准备阶段，都准备成功后进入到第二阶段提交，如果有一个准备失败则回滚。一阶段准备，二阶段提交/回滚。
seata术语
TC - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
seata分为客户端和服务端，seata-server需要单独启动角色就是上述的TC。客户端分为TM和RM。
seata模式
模式具体描述以及原理放到后面文章讲解这里只是说明适用场景
AT模式
基于支持本地 ACID 事务的关系型数据库。通过jdbc访问数据库，AT是通过拦截jdbc执行过程实现数据的提交回滚。当前支持的DB:mysql,oracle,PostgreSQL等。代码0入侵但数据源需要替换为seata指定的数据源。适用于执行逻辑不包含调用三方接口逻辑，这里举个返例：A逻辑中包含向A库插入数据且调用三方接口通知，回滚只能回滚数据库数据不能回滚三方接口业务。
TCC模式
同样基于两阶段提交，不过是调用自身实现的接口逻辑。自身需要实现三个接口：prepare,commit,rollback。prepare数据准备阶段，commit数据提交，rollback数据回滚。自身处理逻辑写在Prepare中，commit和rollback负责提交和回滚业务。代码入侵大，但适用性强。还是拿上述场景：A逻辑中包含向A库插入数据且调用三方接口通知，当某个步骤执行失败可以通过rollback对数据库数据回滚且调用三方接口进行回滚通知。适用大多数业务场景，但是改动成本以及维护成本比较高。
SAGA模式
saga适用于业务流程场且业务流程多，很多项目无法维护无法入侵试的编写代码。saga可以理解为一个外挂的状态机，对流程中每一个步骤都进行补偿。
好了小伙伴们，seata的简介到此结束了，有什么不足的地方大家踊跃提出来，下一章咱们讲解seata的安装启动，以及常见问题解决。
