2023-11-07 数据库-事务-ACID-原子性-思考

摘要:

2023-11-07 数据库-ACID-原子性-思考

原子性:

1. 从定义上看, 事务是包含一些列的操作, 将这些操作看作一个整体
2. 原子性所描述的, 即为这些看作一个整体的操作
3. 这些操作要么都成功, 要么都失败
4. 都成功好理解，那什么叫都失败?
5. 假设这些操作按照序列执行, 执行到中间某一个操作失败了, 那么前边也要看作失败
6. 但是这个时候前边的操作已经执行过了, 那怎么让前边执行过的操作, 去当作失败?
7. 有两个做法
   1. 一是记录回滚日志, 某一个操作失败, 就回滚前边前边执行的操作
   2. 二是执行的时候对数据的修改都在RAM的数据缓存中, 而非真正的修改磁盘数据. 这样某一个操作失败, 只要丢弃RAM中的数据即可

为什么需要原子性?

1. 是的，为什么需要原子性呢? 首先肯定是现实业务场景对DBMS的强烈需求, 由DBMS来保证一批的操作序列看作是完整的逻辑
2. 换个角度, 如果不保持原子性, 那么会出现什么后果呢？
3. 开启一个事务, 事务中有一批的操作, 执行到中间某个操作失败了, 回复给调用端事务失败，但是却有一部分操作被执行了,那么肯定是业务方无法接受, 反面教材就是redis的事务

如何实现原子性?

1. 关键是中间某个操作失败后, 如何处理前边已经执行过的操作序列
2. 像上面提到的, 两种做法
   1. 一种是每个操作都记录undo log, 某个操作失败后, 从这个操作向前逐个回滚
   2. 另一种是不真正的修改数据, 而是写到缓冲区中, 某个操作失败后, 就丢弃整个缓冲区的修改
3. monetdb采用的是第二种策略, 随后详细分析其实现