这是我参与更文挑战的第26天，活动详情查看： 更文挑战
前言
从 CPU 到内存、到磁盘、到操作系统、到网络，计算机系统处处存在不可靠因素。记得以前上司说过一句话，机器跟程序都是不可靠的，只要有可能发生的事情，那么我们就要把这件事当作百分百会发生，而我们的目的则是为了预防这些不可靠因素，来保证数据和指令被正确地处理
小故事
一天，小明去搭地铁，发现地铁卡没钱了，就去机器充值，刚扫付款码支付，小明的钱扣了，机器正在充值中，这时候机器突然故障了，那么小明卡里的钱没了，卡也没有充值上，由于手机和充值机器属于两个隔离的系统，手机不知道系统故障了，或者说充值机器故障的消息没法告诉手机，这个时候，就需要有个第三方服务，将手机付款，机器充值的事情记录起来，过一段时间后，小明虽然充值失败了，但支付的钱应该退回给他了
分布式事物处理过程
组成
- Transaction ID XID 全局唯一的事务ID
- 三组件概念
三组件概念
- TC (Transaction Coordinator)：事务协调者，维护全局和分支事务的状态，驱动全局事务提交或回滚。
- TM (Transaction Manager)：事务管理器，定义全局事务的范围：开始全局事务、提交或回滚全局事务。
- RM (Resource Manager)：资源管理器，管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
什么是Seata？
Seata：简单可扩展自治事务框架，提供全方位分布式事务解决方案
Seata有四种模式：
AT模式
一阶段
在一个数据库食物内完成，保证操作的原子性：
- 业务数据更新之前，Seata解析SQL并获取SQL要更新的数据保存为“before image”
- 业务数据更新之后，Seata解析SQL并获取SQL要更新的数据保存为“after image”
二阶段
- 二阶段提交，证明业务数据已经提交到数据库成功，那么Seata框架将一阶段保存的快照数据和行锁删除，完成数据清理
- 二阶段回滚，Seata需要回滚到一阶段的“before image数据”，回滚前先根据“after image”对比数据库的业务数据是否一致，不一致则证明有脏写，出现这种情况则需要人工处理
TCC
TCC分为三个阶段：
- Try：做业务检查和资源预留
- Confirm：确认提交
- Cancel：业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放
Sage
Sage 是长事务解决方案，事务驱动 saga提供了两种实现方式，一种是编排，另一种是控制。seata的实现方式是后者。seata的控制器使用状态机驱动事务执行。
- 在saga模式下，seata提供了RM、TM和TC三个角色。
- TC也是位于sever端，RM和TM位于客户端。
- TM用于开启全局事务，RM开启分支事务，TC监控事务运行。
XA 模式
在 Seata 定义的分布式事务框架内，利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种 事务模式。
执行阶段：
- 可回滚：业务 SQL 操作放在 XA 分支中进行，由资源对 XA 协议的支持来保证 可回滚
- 持久化：XA 分支完成后，执行 XA prepare，同样，由资源对 XA 协议的支持来保证 持久化（即，之后任何意外都不会造成无法回滚的情况）
完成阶段：
- 分支提交：执行 XA 分支的 commit
- 分支回滚：执行 XA 分支的 rollback
今日小结
Seata是一款开源的分布式事务解决方案，对于分布式事物，小编了解还不足，今天就先学一部分了，还待完善。
