事务
分布式事务理论基础
CAP 理论
在cap 理论中,一个分布式系统 ,设计读写操作时只能满足 三点中的两个
- 一致性（Consistence）: 所有节点访问同一份最新的数据副本
- 可用性（Availability）: 非故障的节点在合理的时间内返回合理的数据
- 分区容错性（Partition tolerance）: 分布式系统出现网格分区时,仍然能对外提供服务
多个系统中网络出现中断,功能根据网络连接分割成区域
注意不是三选二
分布式系统不能没有P(分区容错),那实际上我们可以选的就只有PA,PC
如果没有发生网络分区，我们还是需要尽量保证c和a
BASE 理论
base理论是cap理论的一个延伸和发展，我们在网络分区情况下在牺牲一定强一致性，根据每个节点业务特点尽量保证每个节点的最终一致性
Base的理论三要素
- 基本可用 在发生不可控的网络问题时，保证一定程度上的系统可用性。
- 软状态 允许数据存在中间状态， 并认为该中间状态不会影响系统的整体可用性。
- 最终一致 系统中的数据 ，经过一定时间，最终能达到一个一致的状态
一致性级别：
- 弱一致性：不保证在某些时间之后数据的一致性。
- 强一致性： 写入什么 读取就是什么。
- 最终一致性：保证一定时间之后数据的一致性，弱一致性的升级版。
分布式理论方案：
根据对一致性的区分，可以简略地分为最终一致性与强一致性。
最终一致性：tcc 消息表 saga
强一致性： 2pc 3pc
强一致性：
2pc：
分为两个阶段准备阶段与提交阶段
准备阶段：会通知各个事务点，准备好事务，但不提交等待总事务控制器的指令。
提交阶段：总事务控制器等待全部准备好后 ，发送命令全部执行 ，
事务点收到执行命令后，返回执行结果
总是事务控制器根据各节点的结果来决定是否回滚。
mysql与oracle 天然支持，实现简单
seata的act模式也是2pc模式的加强
存在问题：
事务会存在阻塞性
消息一致：在二阶段时， 网络问题导致各节点不一定能收得到其执行事务或回滚的操作。
3pc模式
3PC模式是2PC模式的一个延展
主要不同点在于准备阶段会有一个问询操作，询问节点是否可以执行事务
事务控制器收到全部就绪之后，会发送消息执行所有事务
tcc模式
是后来互联网经过发展提出的一种模式
try： 事务总控制器会询问各节点是否可以执行事务，各节点会的锁定部分数据，保证收到消息之后的事务可执行。
事务总控制器收到所有的就绪后，会发送消息，让各节点执行事务。
catch阶段： 如果中间发生了意外问题，事务控制器会发送消息，让各节点解锁锁定数据与回滚
tcc模式是严重侵入式，就要开发人员在代码里做一定处理。
saga模式
相比于tcc模式，准备阶段不会让各节点锁定数据，而是发送消息直接执行。
相比于tcc模式，无法保证事务的隔离性。事务操作的数据会被其它操作修改导致事务失败
seata模式好像两种都支持，需要我补充后续
若有收获，就点个赞吧
0 人点赞
