漫谈事务和分布式事务（2）- 数据库 ACID 的实现

回到事务这个话题。上一篇提到：

 

数据库事务 = ACID

 

ACID 并不是一个纸面理论。这个世界上有成千上万台满足 ACID 特性的数据库运行在大大小小的机构、政府部门和企业，为各式各样的复杂业务提供服务。其中有银行、电信、统计机构、实验室，以及你正在访问的网站。如果全球的数据库同时崩溃，那也许是一场世界末日，嘭！

 

让我先烧个香膜拜一下，然后很肤浅的看一下数据库实现 ACID 的方法。

 

数据库 ACID 的实现

 

基本上，数据库实现 ACID 最关键的技术是日志和锁。

 

A - 数据库依赖 Redo / undo 日志实现事务的原子性。 

 

      简单来说，Redo 日志记录事务后的修改数据, Undo 日志记录事务前的原始数据。在恢复时，数据库先检查事务中断在什么阶段：如果事务中断在 commit 阶段，则重放 Redo 日志；如果中断在 prepare 阶段，则利用 Undo 日志进行回滚。

 

      数据库用 检查点（check-point）确定事务的恢复位点。检查点代表：在这一点之前提交的事务所修改的数据已经全部写回磁盘。因此，数据库故障后只要找到最近一次检查点，就可以从这个位置开始处理 Redo / undo 日志。

 

C - 用类型检查、唯一索引、外键约束和级联更新保护数据的完整性。

 

I - 实现事务隔离的主要手段是锁。另外一个关键技术是 MVCC (Multi-version Concurrency Control), 它可以在一些场景避免加锁, 实现同时读写。

 

    不同的隔离级别在数据库中的加锁策略不一样：

 

    Read uncommitted - 读不需要加锁，写仅仅需要加行锁。

 

    Read committed - 需要加写锁，读必须等待写事务结束。

 

    Repeatable reads - 需要加读锁，当有事务在读一行记录，其他写同一行的事务都会阻塞。

 

    Serializable - 需要加范围锁，当有事务 SELECT 某个范围的数据时，其他访问同一范围的事务都会阻塞。

 

    MVCC 则优化了事务读的场景。数据库保存记录的多个版本，在进行更新时，其他只读事务 / 非事务读可以直接访问记录的上一个版本，不需要等待锁。

 

    引入锁在数据库层面上带来了另一个问题：事务中数据的更新不一定是有序的，因此请求锁的顺序也是无序的。无序的加锁必然会导致死锁。因此数据库实现了另一套机制：死锁检测，来防止业务陷入死锁。

 

    单机数据库实现死锁检测的基本办法（ps. 集中式死锁检测）是维护一个活动事务列表，记录每个活动事务上持有和等待的锁。这样——当加锁时，数据库有足够的信息判断等待这一个锁会不会形成闭环，从而识别和阻止死锁。

 

D - 数据库的持久化依赖磁盘和数据复制机制。

 

      在 linux 下，软件可以用 fsync 保证数据真正写入磁盘 / RAID 卡。另一方面，为了解决 RAID 恢复慢的问题，大部分数据库都支持以数据复制方式实现的 热备机制。一旦数据库发生故障，可以立即用备库代替故障的主库，不用等待较慢的 RAID 数据恢复。

 

总之，单机数据库 已经有一套很成熟的经验和理论，可以在合理的性能下实现业务需要的 ACID 特性。—— 但是，这套经验和理论还面临一个问题：

 

单机的硬件性能总是有上限的。

 

目前来看，ACID 事务处理的顶峰是 Oracle ——大概 500,000 TPS 每节点。这个数字是在小型机和高端存储设备上达到的 ——而一套这样的设备价值大约是 $30,000,000。

 

显然。当业务增长到单个数据库节点再也容纳不了的时候，自然需要扩容到多个节点。为了有效的维护多个节点上的数据，业务需要能够在多个节点 ——或者说在 分布式环境 上实现 ACID 事务的理论。

 

下一篇我准备深入介绍一些 这样的理论。

 

敬请期待。