事务是我们在处理业务时很常用的处理方法，通过事务可以保证多个任务的同步执行。
事务特性：原子性、一致性、持久性、隔离性
在 springBoot 中，我们通常会使用 @transition 注解进行事务处理，但是这是在单个 connection 中起到作用，而微服务中添加事务，是用于保证多个服务同步执行，没办法保证是单个 connection ，也就是说使用 @transition 注解并不能起到事务的作用。
单个 connection 是什么呢？
首先 jdbc 我们应该很熟悉，jdbc 的几个步骤就有注册驱动、获取连接对象...没错，这个获取连接对象就是上
面说的 connection。
@transition 底层是在 connection 中进行事务处理，connection 是 jdbc 中封装的一个连接对象，微服务
中每个服务都是不同的连接对象，这就是不能起到事务作用的原因了。
通过上面的内容，我们可以使用 springCloudalibaba 的 Seata 分布式事务锁进行事务处理，那 Seata 的原理以及和 @transition 有什么区别呢？
Seata 是在参与者（添加事务的服务）之间，增加了中间协调者事务管理器，首先添加的事务并不会直接影响参与者，而是发送到中间协调者，由中间协调者统一发送到参与者，每个参与者进行事务处理并且返回（这里有三种情况，第一：参与者执行事务能成功，记录并返回给中间协调者，第二：参与者执行事务失败，记录并返回给组件协调者，第三：宕机等情况无记录无返回），中间协调者通过参与者返回的记录，确定事务是否能执行成功，如果都可以则再向参与者发送提交事务信息，最后无论事务是否执行成功，都必须释放资源（参与者执行事务），中间协调者再返回事务操作结果。
这样看起来可能会比较绕，下面这个例子可以帮助你快速理解：
王五（控制台）觉得张三（参与者）和小七（参与者）很有夫妻相（事务），想撮合他们两，但是考虑到自己
姓氏的原因，没办法参与其中，于是王五想了一个损招，给张三和小七找了个媒婆（中间协调者），让媒婆想办法
让他们结婚，这个媒婆一听知道活来了，于是立刻接下这个任务，并且马上向张三和小七征求他们的意见（中间协
调者向每个参与者发送事务请求）。张三和小七听到后，考虑了一下自己和对方家庭的条件（每个服务是否满足事
务中对应的任务），一家人怀着激动不安坐在一起通宵讨论（是否能执行成功，是否返回），最终他们决定在一起
（分布式事务能成功执行的情况下），于是第二天就去找媒婆传递自己的意见（返回ask记录给中间协调者），媒
婆一听，高兴极了，于是立刻带他们走向婚姻的殿堂（执行事务），结婚后发现两口子过的很滋润，双方也就打消
了原有的顾虑（释放资源），最终媒婆就向王五反馈了此次任务的结果（返回）。
其实细分开来，我们以前的事务就像 事务a：sql1、sql2、sql3，而Seata 则是将多个事务a组合成一个事务b 由中间协调者管理，有种套娃的感觉。
上面就是 Seata 中间件的一个原理，如果有什么错误的地方请指出来。
