text: 常用的分布式事务解决方案有哪些
  数据库本地事务四大特性 :原子性、一致性、隔离性、持久性
  本质上来说，分布式事务解决的问题就是为了保证不同数据库的数据一致性。
  分布式事务场景 :
  •业务拆分:大系统由各子系统构成
  •微服务
  C:Consistency 一致性 :同一数据的多个副本是否实时相同
  A:Availability 可用性:一定时间内 &系统返回一个明确的结果 则称为该系统可用
  只不过“基本可用”和“高可用”的区别是:
  S:Soft State:柔性状态 同一数据的不同副本的状态，可以不需要实时一致。
  E:Eventual Consisstency:最终一致性 同一数据的不同副本的状态，可以不需要实时一致，但一定要保证经过一定时间后仍然是一致的。
  三、分布式事务常见解决方案 2PC协议:
  第一阶段:协调者要求每个涉及到事务的数据库预提交(precommit)操作，并反映是否可以提交.
  分布式事务多种主流形态 :基于消息实现的分布式事务;基于补偿实现的分布式事务;基于TCC实现的分布式事务;基于SAGA实现的分布式事务;基于2PC实现的分布式事务
  分布式事务方案常见的有 :全局事务(DTP);TCC(两阶段 补偿);基于可靠消息队列的分布式事务;最大努力通知;saga长事务
  3.1 全局事务模型DTP AP(Application Program):也就是应用程序，可以理解为使用 DTP 的程序;RM(Resource Manager):资源管理器(这里可以是一个 DBMS，或者消息服务器管理系统)应用程序通过资源管理器对资源进行控制，资源必须实现 XA 定义的接口;
  资源管理器负责控制和管理实际资源。
  全局事务 两阶段提交
  两阶段提交需要一个 协调者 (TM)来掌控所有参与者节点(RM)的操作结果并且指引这些节点是否需要最终提交。
  全局事务的优点 :严格的ACID，强一致性。
  全局事务的缺点 :
  Ø 高并发下存在性能隐患(吞吐量)。
  Ø 系统复杂性也成倍增加。
  3.2 TCC方案(两阶段+补偿型) TCC的全程分为三个阶段，分别是 Try、Confirm、Cancel:
  Cancel阶段 :如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿，就是执行已经执行成功的业务逻辑的回滚操作
  •一个完整的业务活动由一个主业务服务与若干从业务服务组成
  •主业务服务负责发起并完成整个业务活动
  •从业务服务提供TCC型业务操作
  •业务活动管理器控制业务活动的一致性，它登记业务活动中的操作， 并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作
  •原本服务一个接口，需要同时改造为三个接口，即try-confirm-cancel
  •如自己实现tcc框架，成本高，系统复杂性高
  •如引入开源事务框架，涉及服务都需要引入开源框架
  •事务活动日志存储
  适用场景: 强一致性要求的业务;执行时间较短的业务;资金交易类业务;业务接口同步调用
  应用案例: •支付宝XTS;•阿里TXC •Seata_TCC
  业务处理服务在业务事务提交后，向实时消息服务确认发送。
  只有在得到确认发送指令后，实时消息服务才真正发送
  •业务处理服务在业务事务回滚后，向实时消息服务取消发送。
  消息状态确认系统定期找到未确认发送或回滚发送的消息，向业务处理服务询问消息状态，业务处理服务根据消息ID或消息内容确定该消息是否有效
  成本: 可靠消息系统建设; 业务系统需要提供消息状态反查接口 ; 下游处理方式需要保证幂等
  适用场景与优点:
  •事务协调处理由消息中间件完成，系统间解耦
  •基于可靠消息可以实现最终一致性
  •适用于实时性要求不高场景，能容忍一定延迟
  •适用于异步业务处理场景
  应用案例: RocketMQ消息队列框架支持事务消息，一个业务任务会包括几个子任务，每个子任务都可以当成一个子事务，事务以异步方式执行 【大事务 = 小事务 + 异步】，图是基于RocketMQ是一个转账案例
  如上游发送消息失败会不断进行重试，如果持续失败意味着消息中间件出现故障，需人工干预;
  MQ通知消费端也可能失败，同样会重试，持续失败会记录到失败消息表，下游系统会定期查询失败消息，并将其消费;
  最大努力型主要通过重试机制+定期校对实现分布式事务
  消费方都需要支持幂等
  适用场景: 适用于实时性要求低的业务场景; 对业务最终一致性时间敏感度低; 消息中间件如不支持事务可以采用本方式
  TM - 事务管理器 定义全局事务的范围:开始全局事务、提交或回滚全局事务。
  RM - 资源管理器 管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚
  一个典型的分布式事务过程:
  XID 在微服务调用链路的上下文中传播。
  RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖。
  TM 向 TC 发起针对 XID 的全局提交或回滚决议。
  TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。
  Seata 分布式事务框架 -TCCTCC 将事务提交分为 Try - Confirm - Cancel 3个操作。
  AT 模式基于支持本地 ACID 事务 的关系型数据库:而TCC模式则是由用户自定义
  TCC 三个方法描述，由用户自定义:
  总得来说就是分为如下几步:
  业务方调用各个微服务的try()方法，执行资源检查及预留操作
  当所有try()方法均执行成功时，对全局事物进行提交，即由事物管理器调用每个微服务的confirm()方法
  当任意一个方法try()失败(预留资源不足，抑或网络异常，代码异常等任何异常)，由事物管理器调用每个微服务的cancle()方法对全局事务进行回滚
  总结一下全局事务提交的大致流程: 业务方调用微服务无异常，通过TM发起事务提交请求TC接收到事务提交请求后，通过Xid找到全局事务，再取出所有的分支事务遍历分支事务，发出分支事务提交请求TCC资源管理器RM接收到提交请求后，调用commit方法.
  Seata分布式事务框架-saga模式
  目前SEATA提供的Saga模式是基于状态机引擎来实现的，机制是:
  通过 状态图 来定义服务调用的流程并生成 json 状态语言定义文件状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点
  状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚.
  总体上seata框架中
  AT模式业务侵入最少，但是涉及本地锁和全局锁，高并发性能隐患;业务提交和回滚都是基于数据库层侵入实现;
  不过业务回滚操作也是由业务方自己实现;saga模式是接入成本最低的一种模式
  整体上接入开源框架，都需要维护部署seata TC server端，各系统需融入seata客户端，Tcserver端会存在单点隐患.
  对于大多数的业务来说，其实我们并不需要做分布式事务，直接做日志，做监控就好了。
  然后出现问题，手工去处理，一个月也不会有那么多的问题的。
  对于资金类的场景，那么基本上会采用分布式事务方案来保证，像其他的服务，会员，积分，商品信息呀这些，可能就不需要这么去搞了。