数据库的基本原理：ACID 的含义及理解

发表于 1983 年的 《Principles of Transaction-Oriented Database Recovery》给出了 ACID 的定义，对数据库技术的发展影响深远。

本站链接：
https://www.modb.pro/doc/4455

ACID 被用来表达事务的特性。A、C、I、D分别代表“原子性”，“一致性”，“隔离性”和“持久性“。这四条特性指导了30多年来数据库的模型、设计和开发。那么这四个概念要如何理解呢？

• Atomicity，原子性。原子性是指一组对数据库的改变，要么最终成功执行完成，要不就全部回滚。这就要求数据库系统要实现某种回滚的机制，比如redo/undo log）。所以，也许这里用术语”revertability“可能更适合。与事务性数据库相比，一些NoSQL的数据库也声称支持原子性，但是意义不同。比如Redis事务的原子性的意思可能更接近于“一组指令被执行时，不受其他指令的干扰”，而不是“可以回滚”。
• Consistency, 一致性。ACID下的一致性指的是，在事务完成前后，数据都是要在业务意义上是”正确的“，所以也许术语”correctness“更适合这里的意思。但如果这样定义的话，数据库的位置就很尴尬了，因为保证业务是否正确是要业务代码来最终保证的，数据库能做的非常有限。目前数据库里实现的约束检查，比如唯一约束、外键约束、一些enum测检查、一些数据类型/长度/有效数字的检查等等，对于简单的场景还可以使用。对于复杂的业务约束检查，很难或者不可能实现。有一类数据正确性问题正是由于下面隔离性的使用不当而带来的。 真实复杂业务的数据正确性维护一般用正确的业务代码 + 合法性job来定时执行 + 数据库自身的简单合法性防护一起实现。
• Isolation，隔离性。是指一组对数据库的并发修改互相不影响。这个概念表面上看来并不是能说得通，因为如果并发修改的是互不相干的数据，那么自然隔离性可以得到满足；如果并发修改的是相关联的，或者就是同一份数据，就必然会相互影响。那么，此时可以做的就是区分哪个修改优先级更加高。而高优先级的修改应该覆盖掉低优先级的修改。但是，现实往往更复杂，因为并发的修改并不一定能够讲明白先来后到的（要不怎么叫并发呢），此时谁应该生效无法很好的定义。另外一种情况是“先读取，再基于读取结果对数据进行修改”这样业务逻辑。比如，先找到可用的库存，有则扣减，没有则提示缺货；再比如先读取当前的计数值，再往上加1。这时保证隔离性的主要问题不在于隔离本身，而在于如果将读取作为对数据修改的前提条件，之后在对数据进行修改的一刹那，读取时的前提条件还是否满足。毕竟读取和写入是两个分开的指令，而在这两个指令中间可能夹杂其他事务对数据的修改。保持隔离性的一个简单做法是保证对关联数据的修改串行化，对应事务性数据库的“Serializable”隔离级别。保证串行化的一种方案是锁，通过锁定可以彻底避免竞争条件。但是大家都能明白加锁对数据库并发的性能负面影响很大，所以就衍生出了几种弱一些的隔离性保证——READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ。此外MVCC能够解决一部分锁带来的问题。
• Duration，持久性。是指对数据的修改，一旦完成，该结果就应当永远不丢失。在现实当中，一般通过持久性存储设备（比如磁盘/SSD）写入并刷新来保证数据的持久性。如果觉得一个节点不靠谱，可以增加多个副本（replica）一起来保证持久；如果觉得这样还不够靠谱，可以在不同的地理位置的另一个数据中心做备份。实际上绝对的持久性是不存在的，因为整个存储层面有很多不确定因素，比如文件系统本身fsync指令实现有bug，磁盘的固件有bug，供电出现问题造成数据错乱，异步的数据复制没有生效等等。所以在现实当中的数据库，只能在当前成本和技术限制的约束下，尽量维持一定程度的持久性。
  所以这么整理起来。实际上事务性数据库实现的是

通俗一点：

1. 支持未完成的数据修改回滚的机制，对应“原子性”
2. 力所能及的数据合法性检查，对应“一致性”
3. 保证数据并发的修改的规则，对应“隔离性”
4. 使用基于持久化存储（磁盘、SSD）的方式对数据进行存储，对应“持久性”

ACID 在今天仍然是数据库必须遵从的基本法则。