分布式事务

https://juejin.im/post/5b5a0bf9f265da0f6523913b

事务有ACID，是通过InnoDB日志和锁来保证。事务的隔离型是通过数据库锁机制实现的、持久性通过redo log重做日志来实现。原子性和一致性通过UndoLog来实现。UndoLog的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方，（这个存储数据的地方成为UndoLog）。然后进行数据的修改，如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用UndoLog中的备份将数据恢复到事务开始之前的状态。和UndoLog相反，RedoLog是新数据的备份，在事务提交钱，只要讲RedoLog持久化即可，不需要将数据持久化。当系统出现崩溃时，虽然数据没有持久化，但是redolog已经持久化，系统可以根据RedoLog的内容，将所有数据恢复到最新的状态。

CAP定理，又叫做布鲁尔定理。

C(一致性)：对某个指定客户端而言，读操作能返回最新的写操作。对数据分布在不同节点的数据来说，如果某个节点更新了数据，其他节点都能读取到这个最新的数据，那就是强一致，如果有节点没有去取到，就是分布式不一致。

A（可用性）：非故障节点在合理时间内返回合理的相应（不是错误和超时的响应）。可用性的关键是合理的时间和合理的响应。合理的时间是指请求不能无限被阻塞，应该在合理时间内给出返回。合理的响应是指系统应该明确返回结果并且结果正确。

P（分区容错性）：当网络出现分区后，系统仍然能够继续工作。

三者不能共有。

BASE是basically available（基本可用），Soft state（软状态）和Eventually consistent（最终一致的缩写）。是对AP的一个扩展。

基本可用：分布式系统出现故障时，允许损失部分可用功能，保证核心功能可用。

软状态：允许系统中存在中间状态，这个状态不影响系统可用性，（指的是CAP中的不一致）

最终一致：经过一段时间后，所有节点数据都将会达到一致。

2PC：

XA协议中分为两阶段：

（1）事务管理器要求每个涉及到事务的数据库预提交此操作，并反映是否可以提交

（2）事务协调器要求每个数据库提交数据或者回滚数据。

优点：

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

缺点：

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

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

数据不一致：存在数据不一致的可能性。比如在第二阶段中，假如协调者发出了事务commit的通知，但是因为网络问题该通知仅仅被一部分参与者收到并执行了，其余的参与者因为没有收到通知一直阻塞，这时候就是数据不一致。

不能支持高并发

TCC：

Try-Confirm-Cancel，解决协调者单点，引入超时，超时后进行补偿

Try阶段：尝试执行，完成所有业务检查，预留必须业务资源

Confirm：确认真正执行业务，不做检查，只使用Try阶段预留的业务资源，Confirm操作满足幂等性，要求具备幂等设计。

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

TCC适合于强隔离性、严格要求一致，执行时间较短的业务