事务

事务具有 4 个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID 特性。

  - Atomicity（原子性）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复到事务开始前的状态，就像这个事务从来没有执行过一样。
  - Consistency（一致性）：在事务开始前、进行中、结束后，数据库的完整性没有被破坏。完整性包括外键约束、应用定义的等约束不会被破坏。
  - Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
  - Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

分布式事务会部分遵循 ACID 规范：

-     原子性：严格遵循
-     一致性：事务完成后的一致性严格遵循；事务中的一致性可适当放宽
-     隔离性：并行事务间不可影响；事务中间结果可见性允许安全放宽
-     持久性：严格遵循

因为事务过程中，不是一致的，但事务会最终完成，最终达到一致，所以我们把分布式事务称为“最终一致”

2PC

- 两阶段提交，将事务的提交过程分为资源准备和资源提交两个阶段，并且由事务协调者来协调所有事务参与者，如果准备阶段所有事务参与者都预留资源成功，则进行第二阶段的资源提交，否则事务协调者回滚资源。
- 两段提交  准备阶段,TC-->TM-->RM 提交阶段,commit或者rollback
- 性能问题, 阻塞的,不适合高并发,可能部分提交导致数据不一致
- 无法解决commit 后宕机,协调者和消费参与者同时宕机
-  AT模式 无业务入侵 最终一致性的两阶段提交 默认
-  XA模式 无业务入侵 强一致性的 牺牲可用性

成功情况
v2-c6bec5eb89af72bad6055c2a46b5d560_1440w.webp
失败情况
v2-4a56b58dde5beb2e569cefe9d0cbf652_1440w.webp

3PC

CanCommit 准备阶段, PreCommit 预提交阶段, DoCommit 提交阶段
降低了阻塞范围 无法保证数据一致性, 可以自动补偿 监控事务异常

2PC和3PC不适合高并发高性能的场景,延迟比较高,但提供强一致性和强事务

TCC

Try-Confirm-Cancel 应用层的两阶段提交 代码入侵性强 最终一致性
性能提高,最终一致性,可靠
执行时间较短,实时性要求高,数据一致性要求高的场景,  如交易 支付 财务

成功情况
v2-d5d7ed818d6067b3397e70db1e072a4a_1440w.webp

失败情况
v2-6dc4b22fc1285a41804f55a364fc3187_1440w.webp

Saga

相比TCC 等于直接提交,没有try 
补偿动作容易处理的场景

本地事务表

事务主动方-->消息中间件-->事务被动方
适用于可异步执行的业务，且后续操作无需回滚的业务

MQ事务消息

封装本地事务

对一致性要求不高,有人工检查,对账

最大努力通知

- 发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。
- 有一定的消息重复通知机制。
- 消息校对机制。
- 提供接口，让接受通知放能够通过接口查询业务处理结果
- 消息队列ACK机制，消息队列按照间隔1min、5min、10min、30min、1h、2h、5h、10h的方式，逐步拉大通知间隔 ，直到达到通知要求的时间窗口上限。之后不再通知
- 最大努力通知适用于业务通知类型，例如微信交易的结果，就是通过最大努力通知方式通知各个商户，既有回调通知，也有交易查询接口