1. ACID
atom（原子性）
consistency（一致性）
isolation（隔离线） - 保证事务前后变更数据一致
duration（持久性）
2. CAP
consistency（一致性）
强一致性，弱一致性，最终一致性
available（可用性）
partition tolerance（分区容忍性）
- CP为了达到一致性，放弃部分可用性，网络问题会直接让整个系统不可用
- AC 传统数据库
- AP 为了达到可用性，放弃部分强一致性
3. BASE
basically available（基本可用）
soft state（软状态）
eventually consistent（最终一致性）
CA的一种权衡补充，牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态
方案：
-
二阶段提交（单点协调者，资源会
阻塞等待提交）
传统的数据库提供的XA，通过添加coordination协调者，对resourceManager进行协调
一阶段，各业务做预处理，并上报业务处理结果，协调者决定是否回滚
二阶段，回滚 或 执行提交 -
TCC（多点管理者）
TCC服务本身挂了, TCC框架本身管理者会记录分布式事务的活动日志(阶段和状态), 重启后读取对应的状态
适合强隔离，一致性高，短时间完成，中/小型规模的业务
一个业务由一个主业务和多个从业务组成
主业务负责发起和完成整个业务活动
从业务提供给T(try)C(confirm)C(cancel)功能
try: 预留资源执行，也就是冻结(不实际更新值, 而是使用一个预留资源的概念)的概念
confirm：需要提供幂等性，支持重试
cancel：需要提供幂等性，支持重试
- 创建订单的时候调用 try 接口来冻结库存
- 当所有 try 都成功的时候, 调用 confirm 接口来扣减实际库存
- 如果有一个不成功, 调用 cancel 接口来返还冻结库存
-
本地消息表（通过mq修改消息状态以及扫描状态）
适合没有理由失败的业务
本地消息.png
我们使用消息事务
- 创建订单的时候采用冻结库存的概念
- 使用监听db insert/update 动作来实现 分布式事务
- 当监听到状态为 closed 的时候需要调用 恢复库存
-
消息可靠性最终一致事务 RocketMQ分布事务
分布式消息事务.png
- 业务方先发送一条prepare的mq msg
- 业务方执行事务操作, 并根据结果发送 状态给mq
- mq 根据状态决定是 修改 msg 为成功还是删除
- 如果 mq 状态迟迟没有修改, mq会有一个后台定时进程
回查业务方获取结果(这里是保证消息可靠性) - 消费方消费, 并反馈结果给mq 更行msg 为已完成
- 消费方需要保证幂等性, 因为 mq在 msg迟迟没有更新为 已完成的时候, 会重复发送
halfMessage编程普通message的时候会重新复制一份
资源会浪费一倍，好处是尽可能让数据在PageCache上，读取快
减少读取早起的prepare信息导致缺页中断
mq4.2.0之前不支持事务回查功能, 可能出现问题
