分布式事务

CAP

在分布式的服务架构中,一致性(Consistency),可用性(Availability),分区容忍性(Partition Tolerance),在现实中不能都满足,最多只能满足其中两个.

BASE

2PC

分为两阶段:

第一阶段：事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.

第二阶段：事务协调器要求每个数据库提交数据，或者回滚数据。

优点： 尽量保证了数据的强一致，实现成本较低。

缺点:

单点问题:
事务管理器在整个流程中扮演的角色很关键，如果其宕机，比如在第一阶段已经完成，在第二阶段正准备提交的时候事务管理器宕机，资源管理器就会一直阻塞，导致数据库无法使用。

同步阻塞:
在准备就绪之后，资源管理器中的资源一直处于阻塞，直到提交完成，释放资源。

数据不一致:
两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能，比如在第二阶段中，假设协调者发出了事务commit的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了commit操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。

TCC

TCC（Try-Confirm-Cancel）.
TCC事务机制相比于2PC，解决了其几个缺点:

1.解决了协调者单点，由主业务方发起并完成这个业务活动。业务活动管理器也变成多点，引入集群。

2.同步阻塞:引入超时，超时后进行补偿，并且不会锁定整个资源，将资源转换为业务逻辑形式，粒度变小。

3.数据一致性，有了补偿机制之后，由业务活动管理器控制一致性.

TCC的流程:

Try阶段：尝试执行,完成所有业务检查（一致性）,预留必须业务资源（准隔离性）.

Confirm阶段：确认执行真正执行业务，不作任何业务检查，只使用Try阶段预留的业务资源，Confirm操作满足幂等性。要求具备幂等设计，Confirm失败后需要进行重试。

Cancel阶段：取消执行，释放Try阶段预留的业务资源.Cancel操作满足幂等性,Cancel阶段的异常和Confirm阶段异常处理方案基本上一致。

ByteTCC

ByteTCC

本地消息表

将需要分布式处理的任务通过消息日志的方式来异步执行。

消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。

人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。

对于本地消息队列来说核心是把大事务转变为小事务。

MQ事务

消息事务+最终一致性

将本地事务和发消息放在了一个事务里,保证要么两者都成功,要么两者都失败.
基于消息中间件的两阶段提交往往用在高并发场景下,将一个分布式事务拆成一个消息事务(A系统的本地操作+发消息)+B系统的本地操作,只要消息事务成功,那么A操作一定成功,消息也一定发出来了.
而对于B系统的操作,则依赖B系统的重试机制.