PostgreSQL的MVCC并发处理方式

MVCC(Multi-Version Concurrency Control,多版本并发控制):在并发操作数据库时,读操作可能会产生不一致的数据,为了避免这种情况,需要实现数据库的并发访问控制,使得每次读取到的数据都一致,最简单的方式便是加锁访问。也就是,将所有操作串行化,这样就不会出现不一致的情况。但是,串行化的读操作会被写操作阻塞,导致性能下降。

试想,“双十一”时淘宝的数据库订单读写如果采用串行化访问,如何能够保证每秒14万订单的峰值?

熟悉java的同学可能对java concurrent包中的CopyOnWrite系列的类有所了解,即写时复制机制,核心思想是读写分离,因为高并发往往是读多写少。而大多统计类项目也都是这种情况,进行读操作时,不加锁以保证读性能,写操作时加锁,以保证正确性。而MVCC机制类似,每个读操作会看到一个一致性的快照(复制),允许数据在数据库中存在多个版本,版本号当然必须是时间戳或者全局递增的事务ID,也就是保证同一时间点,不同的事务看到的数据是不同的。

而PostgreSQL的mvcc则是当一行记录被更新时,该行数据的新版本将被创建并插入表中,之前版本提供一个指针指向新版本,之前的版本则被标记为“过期”,但是还会保留在数据库中,直到垃圾收集器回收(因此也会存在空间占用问题,以及vacuum机制)。具体来讲,每个事务都会有一个叫做XID的事务ID,当一个事务开始时,postgresql递增该XID,可通过语句select txid_current()获取当前事务ID。

那么,如何根据每个事务ID保证高并发呢?这就需要谈谈几个在没行数据中隐藏的四个字段:xmin,xmax,cmin,cmax

xmin:插入的事务标识符,在insert一条记录时,记录此值为插入数据库的事务ID,如果一直操作同一条数据,则体现为递增;

xmax:删除更新的事务标识符,默认值为0,在删除数据行时,记录此值为当前事务号,如果此值为0,表示该行数据还未提交或者回滚(一般要看到此值的变化,需要使用begin-commit/rollback);

cmin,cmax:标识同一个事务中多个操作语句的序列值,从0开始,用于在同一个事务中实现版本可见性判断。

当插入一条记录时,PostgreSQL会把当前事务的XID存储在这一行中并称之为xmin。只有那些已提交而且xmin比当前事务XID小的记录才对当前事务是可见的。所以,可以在开始一个新事务插入一条记录,直到commit之前,插入的这条记录对其他事务永远是不可见的。等到提交后,其他的事务才能看到这行记录,因为满足了xmin<XID的条件,而且创建记录的事务已经完成。

即:一条记录要想可见,需要满足以下两个条件:

  • xmin < XID:
  • xmax > XID 或 xmax=0:

看下面的执行流程:

首先执行建表一句: create table test(id int, name varchar);

首先,需要明白上图中的事务XID是如何执行的:一套BEGIN/COMMIT作为一个事务;单独的一条SQL语句也是一个事务;事务ID的在一个数据库中是从1开始,因为上图中所在的数据库中存在其他的表,所以图中的事务XID是从820开始的。而为了简化图中事务的执行顺序,XID从1开始。执行顺序也比较简单,这里不再描述。

下面说一种复杂的情况:假设两个事务同时修改一条记录,怎么办?

这就涉及到每个数据库中都会涉及到的数据库的隔离级别(transaction isolation level):一个事务的执行不能被其他事务干扰。

隔离级别脏读不可重复读幻读
读未提交(read uncommited)
读已提交(read committed)避免
可重复读(repeatable read)避免避免
可串行化(serializable)避免避免避免

.幻读:重新执行一个查询,由于最近另一个事务的提交,导致返回的结果和刚才不同;

不可重复读:针对同一条记录,一个事务内多次查询,由于近期另一个事务的提交,导致结果不同;

脏读:一个事务读取了另一个事务还未提交的改动。

 

在PostgreSQL中,默认隔离级别是读已提交。当有两个事务同时修改一行数据时,后发生的事务在初始事务提交前就可以进行查找,然后不执行进行等待,待初始事务提交后retry,检查查找条件是否仍然满足,如果满足,后续操作才会被执行。删除操作类似。

例如,上图中,在事务827提交之前,PostgreSQL机制会让事务827进入等待,直到827事务提交后才可以执行操作。如果没有MVCC机制,在执行事务828的update操作时,会直接拒绝执行,而有了MVCC机制,在事务827结束之前,就可以进入操作工作,事务828一直在retry,直到事务827提交,因此,相比于拒绝执行机制节省了等待时间。

MVCC优缺点

优点:

①由于数据库中保存着旧数据,回滚方便。

缺点:

①事务ID由32位数保存,支持大约40亿个事务,用完时,会出现wraparound问题;

②大量过期数据(dead rows)占用空间降低操作性能。

以上两个问题,都是通过VACUUM机制解决(类似java虚拟机中“标记-复制”垃圾回收方式回收磁盘空间)。

Spread the word. Share this post!

Meet The Author

Leave Comment