ACID&CAP&BASE

2PC/3PC和TCC的区别

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：需要提供幂等性，支持重试

1. 创建订单的时候调用 try 接口来冻结库存
2. 当所有 try 都成功的时候, 调用 confirm 接口来扣减实际库存
3. 如果有一个不成功, 调用 cancel 接口来返还冻结库存

• 本地消息表（通过mq修改消息状态以及扫描状态）
  适合没有理由失败的业务
  本地消息.png
  我们使用消息事务

1. 创建订单的时候采用冻结库存的概念
2. 使用监听db insert/update 动作来实现 分布式事务
3. 当监听到状态为 closed 的时候需要调用 恢复库存

• 消息可靠性最终一致事务 RocketMQ分布事务
  分布式消息事务.png

1. 业务方先发送一条prepare的mq msg
2. 业务方执行事务操作, 并根据结果发送 状态给mq
3. mq 根据状态决定是 修改 msg 为成功还是删除
4. 如果 mq 状态迟迟没有修改, mq会有一个后台定时进程回查业务方获取结果(这里是保证消息可靠性)
5. 消费方消费, 并反馈结果给mq 更行msg 为已完成
6. 消费方需要保证幂等性, 因为 mq在 msg迟迟没有更新为 已完成的时候, 会重复发送

halfMessage编程普通message的时候会重新复制一份
资源会浪费一倍，好处是尽可能让数据在PageCache上，读取快
减少读取早起的prepare信息导致缺页中断
mq4.2.0之前不支持事务回查功能, 可能出现问题