【无标题】

CAP强一致性（2PC、3PC、XA）

1、2PC（two phase commit）两阶段提交

• 两阶段提交就是将事务的提交拆分成两个阶段处理。事务发起的节点为协调者，参与的节点为参与者，协调者统一参与者执行。
  • 阶段1：prepare（准备阶段）
    • 协调者向所有参与者发送事务内容，询问参与者是否可以提交事务，并等待所有参与者答复。
    • 各参与者执行事务但不提交，将undo和redo信息写入事务日志中。
    • 如果参与者执行成功则反馈给协调者yse，执行失败反馈给协调者no
  • 阶段2：commit（提交阶段）:
    • 如果收到参与者的反馈为no或超时，则给每个参与者发送rollback消息。
    • 如果所有参与者的反馈都为yes，则给每个参与者发送commit消息。
• 2PC方案实现起来简单，但实际项目中很少会使用，主要因为一下原因：
  • 性能问题：所有参与者在提交阶段处于同步阻塞状态，占用资源，容易导致性能瓶颈。
  • 可靠性问题：如果协调者存在单点故障，一旦协调者出现故障，参与者将一直处于锁定状态。
  • 数据一致性问题：在提交阶段中，如果发生网络问题，会导致一部分参与者收到提交消息，另一部分参与者没有收到提交消息，那么就会导致节点之间数据不一致。

2、3PC 三阶段提交：第一阶段为can commit，第二阶段pre commit ，第三阶段do commit。

• 3PC是2PC的改进版本，与二阶段不同的是，在协调者与参与者中都引入了超时机制。3PC将2PC的准备阶段拆分成了两个，插入了一个pre commit阶段，解决了在2PC中参与者在准备阶段后，由于协调者或协调者发生崩溃或错误，而导致参与者无法知晓而处于长时间等待的问题。引入超时机制后，协调者在指定时间内没有收到参与者的消息后则默认失败。
  • 阶段1：can commit
    • 协调者向参与者发出提交请求，如果参与者可以提交就返回yes，不能提交就返回no。
  • 阶段2：pre commit
    • 协调者根据canCommit中参与者返回的情况执行预提交事务或中断事务操作。
    • 参与者均反馈yes：协调者向所有参与者发出preCommit请求，参与者收到preCommit后，执行事务操作，但不提交，将undo和redo信息写入事务日志中；各参与者向协调者反馈ack或no相应，并等待最终指令。
    • 任何一个参与者反馈no或超时：协调者向所有参与者发送abort请求，参与者收到abort请求，或在等待协调者发送请求过程中超时，都会执行中断事务操作。
  • 阶段3：do commit
    • do commit进行真正的事务提交，根据preCommit反馈的结果执行完成事务的提交或中断操作。
• 相比2PC模式，3PC模式降低了阻塞范围，在等待超时后参与者或协调者会中断事务。避免了协调者的单点问题。

3、XA

• XA是由X/Open组织提出的分布式事务规范，基于两阶段提交协议。XA规范主要定义了全局事务管理器（TM）和局部资源管理器（RM）之前的接口，目前主流关系型数据库都实现了XA接口。
• 在XA中可以把TM理解为协调者，把RM理解为参与者
• 在阶段1中TM会询问所有RM是否可以提交，RM收到请求后会实现自身事务提交前的准备工作并返回结果。
• 在阶段1中如果所有RM的返回接口都为yes则执行commit操作，如果有任一参与者返回no则执行rollback操作。
• 

 

BASE最终一致性（TCC、基于mq、saga）

1、TCC（Try-Confirm-Cancel），TCC是服务化的两阶段编程模型，其中Try、Confirm、Cancel3个方法均由业务编码实现，下面举例积分兑换商品

• try操作为一阶段，负责资源的检查和预留；
  • 业务代码分别实现积分的检查/预留和商品的检查/预留。
• confirm操作为二阶段提交操作，执行真正的业务；务代码中进行商品库存扣减并且扣除相应的积分，提交事务，清空预留信息。
• cancel是预留资源的取消；
  • 如果在confirm中出现异常，则取消操作，并清除预留的资源信息。
• TCC相比于XA，解决了如下几个缺点：
  • 解决了协调者单点，由业务方发起并完成这个业务活动。业务活动管理器可以变成多点，引入集群。
  • 同步阻塞：可以引入超时机制，超时后进行补偿，并且不会锁定整个资源，将资源转换为业务逻辑形式，粒度变小。
  • 数据一致性：有了补偿机制后，由业务活动管理器控制一致性。

2、基于mq实现最终一致性

3、saga

• saga事务是由多个短时事务组成的长时事务。在分布式事务场景下，我们把一个saga分布式事务看做是一个由多个本地事务组成的事务，每个本地事务都有一个与之对应的补偿事务。在saga事务的执行过程中，如果某一步执行出现异常，saga事务会被终止，同时会调用对应的补偿事务完成相关的恢复操作，这样保证saga相关的本地事务要么都执行成功，要么通过补偿恢复成为事务执行之前的状态。（自动反向补偿机制）。
• saga事务基本协议如下：
  • 每个saga事务是由一系列幂等的有序子事务（sub-transaction）Ti组成。
  • 每个Ti都有对应的幂等补偿操作Ci，补偿操作用于撤销Ti造成的接口。
• saga是一种补偿模式，它定义了两种补偿策略：
  • 向前恢复：如果子事务发生异常，则进行重试，适用于必须要成功的场景。
  • 向后恢复：如果子事务发生异常，则回滚之前所有成功的子事务，使得整个saga的执行结果撤销。

   

   

seata框架

seata 是一套一站式分布式事务解决方案，是阿里和蚂蚁金服联合打造的分布式事务框架。seata目前的事务模式有AT、TCC、Saga三种模式，默认是AT模式，AT模式本质上是2PC协议的一种实现。

seata AT事务模型包含TM（事务管理器），RM（资源管理器），TC（事务协调器）。其中TC是一个独立的服务需要单独部署，RM和TM以jar包的方式同业务应用部署在一起，他们同TC建立长链接，在整个事务生命周期内，保持RPC通信。

• 全局事务的发起方为TM，全局事务的参与者为RM
• TM负责全局事务的begin和commit/rollback
• RM负责分支事务的执行结果上报，并通过TC的协调进行commit/rollback。
• 执行流程：
  • TM请求TC，开启一个全新的事务，TC会为这个事务生成一个XID
  • XID通过TM的调用链把它传递到其他RM中
  • RM把本地事务作为XID的分支事务注册到TC，并把自己的分支事务执行结果上报TC
  • 全部的RM执行完成后，TC会知道所有RM的执行结果并同步到TM
  • 如果所有RM的执行结果均为成功，则TM请求TC对这个XID进行事务提交，否则进行回滚。
  • TC收到TM的请求后，向XID下的所有RM发送相应的请求commit/rollback。

   

分布式一致性事物 2pc 3pc tcc Seata

2pc/3pc 2PC、3PC、TCC&XA&saga&AT基础理论__雪辉_的博客-CSDN博客

tcc 什么是TCC？_知识记录者-vincent的博客-CSDN博客_tcc

seata Seata分布式事务XA与AT全面解析_FUNKYE的博客-CSDN博客_xa at

Seate名词解释

TM - 事务管理器，定义全局事务的范围：开始全局事务、提交或回滚全局事务。

TC - 事务协调者，维护全局和分支事务的状态，驱动全局事务提交或回滚。

RM - 资源管理器，管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

XID：一个全局事务的唯一标识，由ip:port:sequence组成

Transaction Coordinator (TC)： 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。

Transaction Manager (TM)： 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。

Resource Manager (RM)： 控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。

如何保证接口的幂等性

在实际项目中针对幂等性问题常用的解决方案有两种

1. 使用redis判断拦截，具体使用方法
   1. 使用业务唯一ID作为redis key进行存储，如：SYSTEM_A_SHOPPING_1000021，并且设置过期时间。
   2. 在业务方法的入口查询redis，判断当前业务Id是否存储在redis中，如果不在则表示是第一次请求，可以正常进行业务处理，并且把业务Id存储到redis中。
   3. 此时如果有重复请求进来，查询redis，发现业务Id在redis中，则进行拦截操作，提示前端“重复操作”等信息。
2. 使用mysql唯一索引拦截
   1. 由于mysql唯一索引可以保证数据的唯一性，所以可以利用这一点来实现接口的幂等性。