数据库事务原子性

ACID - Atomicity.md

• 问题: 多个独立的操作, 如何成为一个原子操作?
• 答案: 依赖一个支持原子操作的地方(单点).

实现方案:

1. 单点单标记, 指示中间态的数据(资源)的真正状态 - Commit Point
2. 单点多标记, 保存所有资源的中间状态(需要用原子操作来保存事务涉及的多个资源的状态)
3. 单点副本, 先在单点修改数据, 再异步地复制数据到最终的目的地 - Redo Log

经典的 2PC: 两阶段修改, 单点提交(确认). 属于方案1 - 单点单标记.

对于单点标记方案, 数据的使用者遇到中间态的数据时向单点求证. 对于单点副本方案, 数据的使用者每一次都要向单点求证是否有最新版本的数据.

Atomicity 不仅仅涉及写操作, 读操作也要配合, 才能体现原子性. 网上的资料几乎都没有特别指明读流程, 这造成了非常大的困惑. 如果读操作不遵守特殊规则的话, 便没有原子性可言了

冲突解决方案:

1. 悲观锁 - 序列化执行
2. 乐观锁 - 并发执行, 冲突检测

Oracle, Database Administrator's Guide - Distributed Transactions Concepts

https://docs.oracle.com/cd/B19306_01/server.102/b14231/ds_txns.htm

资源中间态, In-Doubt Resource 是很多资料没有提到的概念, 不知道为什么? 在读流程中, 如果对于中间态的资源不做特殊处理的话, 原子性从何谈起?

无论分布式事务还是单机事务, 本质上就是引入一个单点. 当我们在额外的地方修改完所有资源之后, 原子性地修改指针的指向, 指向新数据.

为了避免单点瓶颈, 才发明了一些优化, 使得某些读操作不用经过单点.