前言：你是否真的明白分布式事务？
- 事务的ACID中的C一致性和分布式CAP理论中C分别是什么，有什么关系？
- 分布式环境下，事务的ACID中的原子性通常怎么实现的？隔离性呢？
- 分布式事务是一个纯技术问题，为什么很多分布式事务方案会侵入业务？
从事务ACID说起
- Transaction Atomicity：all-or-nothing
- undo log
- Isolation
- 2PL
- Timestamp Ordering（T/O）
- Base T/O
- Optimistic Currency Control(OCC)
- Multi-Version Concurrency Control(MVCC)
- Durability
- Redo log
- Consistency
思考：怎么理解ACID中的一致性？
原子性，隔离性和持久性是数据库的属性，而一致性（在ACID意义上）是应用程序的属性。应用可能依赖数据库的原子性和隔离属性来实现一致性，但这并不仅取决于数据库。
Consistency ensures that a transaction can only bring the database from one valid state to another, maintaining database invariants: any data written to the database must be valid according to all defined rules, including constraints, cascades,triggers, and any combination thereof. This prevents database corruption by an illegal transaction, but does not guarantee that a transaction is \correct.(From wikipedia)
CAP分布式理论
- Consistency（Linearizability Consistency）
- Availability（100% Availability）
- Partition
思考：CAP中的C和ACID中的C是相同的吗？
Both C’s stand for consistency, but the notion of consistency in CAP means that “all nodes see the same data at the same time” and the notion of consistency in ACID means that “any transaction the database performs will take it from one consistent state to another”. (From Wikipedia.)
- ACID C:（multi-object
、multi-operation） - CAP C: （single-object
、single-operation）多个副本的一致性
分布式环境给事务带来哪些挑战？
分布式环境下，原子性怎么保证？
2PC原子协议
####
2PC→3PC
- 2PC存在什么问题
- 3PC解决了什么问题，存在什么问题（为什么很少工程化的实践）
2PC VS Paxos
2PC blocks if the transaction manager fails, requiring human intervention to restart. 3PC algorithms (there are several such algorithms) try to fix 2PC by electing a new transaction manager when the original manager fails.
Paxos does not block as long as a majority of processes (managers) are correct. Paxos actually solves the more general problem of consensus, hence, it can be used to implement transaction commit as well. In comparison to 2PC it requires more messages, but it is resilient to manager failures. In comparison to most 3PC algorithms, Paxos renders a simpler, more efficient algorithm (minimal message delay), and has been proved to be correct.
Gray and Lamport compare 2PC and Paxos in an excellent paper titled “consensus on transaction commit”.
Isolation & Consistency
分布式领域，事务分成了两个子问题，一个是隔离性（isolation），一个是一致性（consistency）
X/Open XA
XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准。
XA 规范 描述了全局的事务管理器与局部的资源管理器之间的接口。 XA规范 的目的是允许的多个资源（如数据库，应用服务器，消息队列等）在同一事务中访问，这样可以使 ACID 属性跨越应用程序而保持有效。
XA 规范 使用两阶段提交（2PC，Two-Phase Commit）来保证所有资源同时提交或回滚任何特定的事务。
思考：XA存在什么问题？
- 提示：2PC存在什么问题？
- 锁定引入什么问题？
柔性事务
- BASE理论
- 非ACID
思考：分布式事务场景，ACID & CAP 怎么选？
ACID ：Transaction Atomicity： ✅
ACID ：Durability： ✅
ACID ： Database Consistency： ✅
ACID ： Isolation ：RU、RC、Cursor Stability、RR、Snapshot Isolation、Serializable ？
CAP ： Consistency ：Linearizability、Sequential、Causal、PRAM…?
CAP： Availability : 0~100% ?
思考：分布式事务场景，ACID & CAP 怎么选？隔离性 VS 性能
牺牲隔离性，换取性能
分布式事务解决方案（应用层）
TCC
事务消息
【注】Pulsar、Kafka消息中间件的事务支持跟RocketMQ的事务消息有所不同
可靠消息
思考：可靠消息方案的原子性怎么保证？
Saga
关于Saga
Saga区别XA，是基于服务统一排程，而非资源管理器，同TCC；- Saga区别TCC，没有try步骤，性能优于TCC
- Saga适用长事务（Long-running-transaction），TCC适用短事务
- Saga最大的问题是隔离性带来的问题
Saga VS 可靠消息
- 可靠消息下游业务不需要Cancel
- 可靠消息像是Saga的特例
其他
- 幂等操作+可回查（叫什么不重要）
探讨：XA 与常见的分布式方案有什么不同？
聊一聊：Seata：分布式事务标准化平台
思考：
- 讨论一个分布式事务框架，我们首先讨论什么？
- 性能、业务侵入、隔离性？
延伸：分布式系统设计中CAP、ACID可以如何取舍
- 在满足传统数据库的强一致性约束下，我们能做到多高的可用性，以及多低的延迟？
- 在满足 100% Read Write Availability 的约束下，我们能做到多高的一致性？
- 在这两者之间还存在什么？
强烈推荐：CAP，ACID，我们能做什么
小结
分布式事务没有银弹！分布式事务业务层的解决方案本质是在性能、隔离性、业务侵入性等做取舍。互联网业务场景常常为了高性能而选择牺牲隔离性，通过具体的业务场景或者特定的架构设计去规避隔离性缺失引入的业务问题。所以，很多我们所熟知的分布式事务方案几乎都是限定业务场景的。分布式事务没有银弹！分布式事务业务层的解决方案本质是在性能、隔离性、业务侵入性等做取舍。
FAQ
Q1：隔离性并发控制分类
详见：https://www.zhihu.com/question/60278698
Q2：一致性模型线性一致性和顺序一致性的区别？
详见：一致性模型笔记
Q3：Raft相关
- Raft 协议Leader是否一定有最新的数据？
- 是，Leader Completeness
- Raft协议判定一个值committed是否一定要等follower ack？
- 否，Entry committed if known to be stored on majority of servers，但是正常流程是等过半数node ack后由Machine State committed，
详见下次技术探讨