分布式事务

CAP理论

CAP理论说的是：在一个分布式系统中，最多只能满足C、A、P中的两个需求。

CAP的含义：

• C：Consistency 一致性 同一数据的多个副本是否实时相同。
• A：Availability 可用性 可用性：一定时间内 & 系统返回一个明确的结果 则称为该系统可用。
• P：Partition tolerance 分区容错性 将同一服务分布在多个系统中，从而保证某一个系统宕机，仍然有其他系统提供相同的服务。

BASE理论

CAP理论告诉我们一个悲惨但不得不接受的事实——我们只能在C、A、P中选择两个条件。而对于业务系统而言，我们往往选择牺牲一致性来换取系统的可用性和分区容错性。不过这里要指出的是，所谓的“牺牲一致性”并不是完全放弃数据一致性，而是牺牲强一致性换取弱一致性。下面来介绍下BASE理论。

• BA：Basic Available 基本可用
  • 整个系统在某些不可抗力的情况下，仍然能够保证“可用性”，即一定时间内仍然能够返回一个明确的结果。只不过“基本可用”和“高可用”的区别是：
    • “一定时间”可以适当延长 当举行大促时，响应时间可以适当延长
    • 给部分用户返回一个降级页面 给部分用户直接返回一个降级页面，从而缓解服务器压力。但要注意，返回降级页面仍然是返回明确结果。
• S：Soft State：柔性状态 同一数据的不同副本的状态，可以不需要实时一致。
• E：Eventual Consisstency：最终一致性 同一数据的不同副本的状态，可以不需要实时一致，但一定要保证经过一定时间后仍然是一致的。

TCC（两阶段型、补偿型）

TCC即为Try Confirm Cancel，它属于补偿型分布式事务。顾名思义，TCC实现分布式事务一共有三个步骤：

• Try：尝试待执行的业务
  • 这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源
• Confirm：执行业务
  • 这个过程真正开始执行业务，由于Try阶段已经完成了一致性检查，因此本过程直接执行，而不做任何检查。并且在执行的过程中，会使用到Try阶段预留的业务资源。
• Cancel：取消执行的业务
  • 若业务执行失败，则进入Cancel阶段，它会释放所有占用的业务资源，并回滚Confirm阶段执行的操作。

一、事务的过程

1. 建立连接

• 1、拿到事务的控制权；2、事务组管理者

1. 开启事务
2. 执行方法  
3. 提交/回滚

二、事务管理者

1. 保存本地事务状态（回滚、提交）
2. 统计结果：整个分布式事务的结果（回滚、提交）
3. 通知：告诉每个本地事务