回到事务这个话题。上一篇提到：
?
数据库事务 = 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 事务的理论。
?
下一篇我准备深入介绍一些?这样的理论。
?
敬请期待。
?
