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适合于强隔离性、严格要求一致,执行时间较短的业务