`
in355hz
  • 浏览: 227541 次
社区版块
存档分类
最新评论

漫谈事务和分布式事务(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 事务的理论。
 
下一篇我准备深入介绍一些 这样的理论
 
敬请期待。
 
1
0
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics