并发控制简介

PostgreSQL提供了多种方式以控制对数据的并发访问。在数据库内部,数据的一致性使用多版本模式(多版本并发控制(Multiversion Concurrency Control),即MVCC)维护。这意味着每个SQL语句查询到的数据,是查询开始时间节点的快照(一个数据版本),而与查询期间数据状态无关。此机制确保语句不会查询到由并发事务对同一行数据进行修改而产生的不一致数据,从而为每个数据库会话提供了事务隔离特性。MVCC通过避免传统数据库系统中的锁定方法,最大程度上减小了在多用户并发场景下的锁争用,从而提高了性能。

在PG中,mvvc只适用于读已提交、可重复度两个隔离级别。

事务隔离

四种现象

脏读

事务读取到另一并发事务未提交的数据。

不可重复读

同一事务内,读取之前读过的数据时,发现读取到了开始查询时间点之后其他事务修改后的数据。

幻读

同一事务,重复执行查询出来的符合条件行数,受另一最近提交的事务影响。

序列化异常

一次提交一组事务,与随机顺序单个事务运行的结果不同。

事务隔离级别

隔离级别

脏读

不可重复读

幻读

序列化异常

读未提交

允许,但PG中不允许

可能

可能

可能

读已提交

不可能

可能

可能

可能

可重复读

不可能

不可能

允许,但PG中不允许

可能

序列化(串行化)

不可能

不可能

不可能

不可能

读未提交:一个事务可以读取另一个事务未提交的内容。pg中不存在该级别,pg的mvcc机制使读未提交和读已提交表现一致。

读已提交:一个事务可以读取另一个已提交事务的内容,这可能导致同一个事务中两次查询得到的结果不一致。

可重复读:一个事务可以读取另一个已提交事务的数据(列表层面)。

序列化:串行执行

PG中的锁

表级锁

以下列出了可用的锁模式,以及在何种场景下PostgreSQL会自动使用它们。也可以使用LOCK命令显式地获取这些锁。请谨记,所有这些锁模式均为表级锁,即使锁名中包含“行”(这种命名是历史遗留问题)。名称在某种程度上反应了每个锁模式的典型用法--但语义都相同。各种锁模式之间的唯一真正区别就是锁模式之间的冲突。两个事务不能同时在同一张表获取相互冲突的锁模式。(不过,事务本身无冲突,例如,对于同一张表,它可以先获得ACCESS EXCLUSIVE锁,随后又获得ACCESS SHARE锁。)多个事务可以并行获取不冲突的锁模式。请注意,有些锁模式,与自身会产生冲突(例如,同时仅可以有一个事务获得ACCESS EXCLUSIVE锁);有些却不会(例如,多个事务可同时获取ACCESS SHARE锁)。

表级锁模式

ACCESS SHARE(访问共享)

仅与ACCESS EXCLUSIVE锁模式冲突。

SELECT命令会在相关表上获取该锁。一般情况下,所有仅读取表而不更改表的查询均会获取该锁模式。

ROW SHARE(行共享)

与EXCLUSIVE和ACCESS EXCLUSIVE锁模式冲突。

SELECT FOR UPDATE和SELECT FOR SHARE命令在目标表上获取该锁模式(在其他相关但未选择为FOR UPDATE/FOR SHARE的表上获取ACCESS SHARE锁)。

ROW EXCLUSIVE(行排他)

与SHARE,SHARE ROW EXCLUSIVE,EXCLUSIVE和ACCESS EXCLUSIVE锁模式冲突。

UPDATE,DELETE和INSERT命令在目标表上获取此锁模式(在其他相关表上获取ACCESS SHARE锁)。一般情况下,所有更改表数据的命令均会获取该锁模式。

SHARE UPDATE EXCLUSIVE(共享更新排他)

与SHARE UPDATE EXCLUSIVE,SHARE,SHARE ROW EXCLUSIVE,EXCLUSIVE和ACCESS EXCLUSIVE锁模式冲突。此模式可防止表发生并发模式(schema)更改和VACUUM。

由以下命令获取:VACUUM(无FULL)、ANALYZE、CREATE INDEX CONCURRENTYLY、REINDEX CONCURRENTLY、CREATE STATISTICS以及特殊的ALTER INDEX和ALTER TABLE变体(更多新详情请参见命令ALTER INDEX和ALTER TABLE)。

SHARE

与ROW EXCLUSIVE,SHARE UPDATE EXCLUSIVE,SHARE ROW EXCLUSIVE,EXCLUSIVE和ACCESS EXCLUSIVE锁模式冲突。该模式可防止表发生并发数据变更。

由命令CREATE INDEX(无CONCURRENTLY)获取。

SHARE ROW EXCLUSIVE

与ROW EXCLUSIVE,SHARE UPDATE EXCLUSIVE,SHARE,SHARE ROW EXCLUSIVE,EXCLUSIVE和ACCESS EXCLUSIVE锁模式冲突。该模式可防止表发生并发数据更改,且是自排他,所以可保证每次仅一个会话可持有该锁。

由命令CREATE TRIGGER和ALTER TABLE的某些格式获取。

EXCLUSIVE

与ROW SHARE,ROW EXCLUSIVE,SHARE UPDATE EXCLUSIVE,SHARE,SHARE ROW EXCLUSIVE,EXCLUSIVE和ACCESS EXCLUSIVE锁模式冲突。该模式仅允许并发的ACCESS SHARE锁,即,若事务持有该锁,那么仅可并行执行读取表数据的操作。

由REFRESH MATERIALIZED VIEW CONCURRENTLY命令获取。

ACCESS EXCLUSIVE

与所有锁模式冲突(ACCESS SHARE,ROW SHARE,ROW EXCLUSIVE,SHARE UPDATE EXCLUSIVE,SHARE,SHARE ROW EXCLUSIVE,EXCLUSIVE和ACCESS EXCLUSIVE)。该模式确保仅持有该锁的事务访问该目标表。

由命令DROP TABLE,TRUNCATE,REINDEX,CLUSTER,VACUUM FULL和REFRESH MATERIALIZED VIEW(无CONCURRENTLY)获取。ALTER INDEX和ALTER TABLE的一些模式同样获取此级别的锁模式。这也是LOCK TABLE语句的默认锁模式。

冲突模式

Requested Lock Mode

Current Lock Mode

ACCESS SHARE

ROW SHARE

ROW EXCLUSIVE

SHARE UPDATE EXCLUSIVE

SHARE

SHARE ROW EXCLUSIVE

EXCLUSIVE

ACCESS EXCLUSIVE

ACCESS SHARE

             

X

ROW SHARE

           

X

X

ROW EXCLUSIVE

       

X

X

X

X

SHARE UPDATE EXCLUSIVE

     

X

X

X

X

X

SHARE

   

X

X

 

X

X

X

SHARE ROW EXCLUSIVE

   

X

X

X

X

X

X

EXCLUSIVE

 

X

X

X

X

X

X

X

ACCESS EXCLUSIVE

X

X

X

X

X

X

X

X

行级锁

除了表级锁,还有行级锁,以下列出了行级锁及在什么情况下PostgreSQL会自动的使用它们。请注意,在不同的子事务中,事务可以在同一行上获得冲突的锁;但除此之外,两个事务永远不能在同一行上获得冲突的锁。行级锁不会影响检索数据;它们仅会阻塞对同一行的写入及锁。如表级锁一样,行级锁仅会在事务结束或快照回滚时释放。

行级锁模式

FOR UPDATE

FOR UPDATE将SELECT语句返回的行锁定用于更新。这可以防止这些行在事务结束之前被其他事务锁定、修改或删除。也就是说,其他尝试针对这些行执行UPDATE,DELETE,SELECT FOR UPDATE,SELECT FOR NO KEY UPDATE,SELECT FOR SHARE或者SELECT FOR KEY SHARE的事务在当前事务结束之前会一直被阻塞;相反的,SELECT FOR UPDATE将会等待在同一行执行这些命令的并行事务,然后会返回更新后的行(如果这些行被删除了,那么不会返回行)。不过,在可重复读或序列化事务中,如果被锁定的行在事务开始后被修改了,那么会抛出错误。

DELETE行以及UPDATE某一列值,也会获取FOR UPDATE锁模式。当前,UPDATE情况下考虑的为可以在其上有唯一索引、可用于外键的列(所以不考虑部分索引和表达式索引),不过将来这种机制可能会改变。

FOR NO KEY UPDATE

行为与FOR UPDATE类似,不过锁级别低一些;该锁不会阻塞在同一行上的SELECT FOR KEY SHARE命令。那些不获取FOR UPDATE锁的UPDATE命令均获取该锁。

FOR SHARE

行为与FOR NO KEY UPDATE类似,不过它是在检索到的行上加共享锁而不是排它锁。共享锁会阻塞在相同行上执行的UPDATE,DELETE,SELECT FOR UPDATE或者SELECT FOR NO KEY UPDATE命令,但不会阻塞SELECT FOR SHARE或者SELECT FOR KEY SHARE命令。

FOR KEY SHARE

行为与FOR SHARE类似,但锁级别更低一些:会阻塞SELECT FOR UPDATE,但不会阻塞SELECT FOR NO KEY UPDATE。该锁会阻塞其他事务执行DELETE或那些改变键值的UPDATE操作,但不会阻塞其他UPDATE操作,也不会阻塞SELECT FOR NO KEY UPDATE,SELECT FOR SHARE或SELECT FOR KEY SHARE。

PostgreSQL并不会在内存中记录变更行的信息,所以对于同一时间锁定的行数没有限制。不过,锁定行可能会导致磁盘写,例如:SELECT FOR UPDATE修改选取的行以将其标记为锁定,从而会导致磁盘写。

行级锁冲突

quested Lock Mode

Current Lock Mode

FOR KEY SHARE

FOR SHARE

FOR NO KEY UPDATE

FOR UPDATE

FOR KEY SHARE

     

X

FOR SHARE

   

X

X

FOR NO KEY UPDATE

 

X

X

X

FOR UPDATE

X

X

X

X

页级锁

除了表级锁和行级锁,还有页级共享/排他锁用以控制对于共享缓冲池中表页的读/写。这些锁在行被获取或更新后立马释放。应用程序开发者一般无需关系此类锁。

咨询锁

一种显式可重入锁策略,完全由应用程序控制。

咨询锁函数

Name

Return Type

Description

pg_advisory_lock(key bigint)

void

Obtain exclusive session level advisory lock

pg_advisory_lock(key1 int, key2 int)

void

Obtain exclusive session level advisory lock

pg_advisory_lock_shared(key bigint)

void

Obtain shared session level advisory lock

pg_advisory_lock_shared(key1 int, key2 int)

void

Obtain shared session level advisory lock

pg_advisory_unlock(key bigint)

boolean

Release an exclusive session level advisory lock

pg_advisory_unlock(key1 int, key2 int)

boolean

Release an exclusive session level advisory lock

pg_advisory_unlock_all()

void

Release all session level advisory locks held by the current session

pg_advisory_unlock_shared(key bigint)

boolean

Release a shared session level advisory lock

pg_advisory_unlock_shared(key1 int, key2 int)

boolean

Release a shared session level advisory lock

pg_advisory_xact_lock(key bigint)

void

Obtain exclusive transaction level advisory lock

pg_advisory_xact_lock(key1 int, key2 int)

void

Obtain exclusive transaction level advisory lock

pg_advisory_xact_lock_shared(key bigint)

void

Obtain shared transaction level advisory lock

pg_advisory_xact_lock_shared(key1 int, key2 int)

void

Obtain shared transaction level advisory lock

pg_try_advisory_lock(key bigint)

boolean

Obtain exclusive session level advisory lock if available

pg_try_advisory_lock(key1 int, key2 int)

boolean

Obtain exclusive session level advisory lock if available

pg_try_advisory_lock_shared(key bigint)

boolean

Obtain shared session level advisory lock if available

pg_try_advisory_lock_shared(key1 int, key2 int)

boolean

Obtain shared session level advisory lock if available

pg_try_advisory_xact_lock(key bigint)

boolean

Obtain exclusive transaction level advisory lock if available

pg_try_advisory_xact_lock(key1 int, key2 int)

boolean

Obtain exclusive transaction level advisory lock if available

pg_try_advisory_xact_lock_shared(key bigint)

boolean

Obtain shared transaction level advisory lock if available

pg_try_advisory_xact_lock_shared(key1 int, key2 int)

boolean

Obtain shared transaction level advisory lock if available

咨询锁用法

库级:

select pg_advisory_lock(1)
select pg_advisory_unlock(1)

表级:

select pg_advisory_lock(1) from users
select pg_advisory_unlock(1) from users

行级:

select pg_advisory_lock(tableoid::int,id),tableoid,* from users where id = 1;
select pg_advisory_unlock(tableoid::int,id),* from users where id = 1; select pg_advisory_lock(id) from users
select pg_advisory_unlock(id) from users

MVCC

Multi-Version Concurrency Control 多版本并发控制,MVCC 是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问;在编程语言中实现事务内存。(MVCC:百度百科)

在PG提供的三种隔离级别中,MVCC机制只工作在读已提交和可重复读两个隔离级别中,序列化使用锁控制事务串行化执行。

实例

测试表:

CREATE TABLE users (
id int4 NOT NULL,
age int4
);
ALTER TABLE users ADD CONSTRAINT "user_pkey" PRIMARY KEY ("id");

MVCC验证

验证数据库默认事务隔离级别为提交读

show transaction_isolation;

--result:
read committed

事务1执行:

BEGIN;
SELECT * from users;

id

age

1

3

事务2执行:

BEGIN;
UPDATE users set age = 4 where "id" = 1;
SELECT * from users;

id

age

1

4

在事务1中再次执行SELECT * from users

查询结果不变:

id

age

1

3

可见,事务1和事务2的可见性不同,所以sqlSELECT * from users查询结果也不同。证明多版本的存在。

脏读

PG中不存在未提交读隔离级别,显示使用未提交读隔离级别时,PG内部会使用为提交读隔离级别处理,脏读在PG中不会发生。

不可重复读现象验证

继续 MVCC验证 的测试。在事务2中执行COMMIT提交事务。

事务1中再次执行SELECT * from users

查询结果:

id

age

1

4

事务1的查询结果发生了改变,即发生了“不可重复读”现象,在同一个事务(事务1)中,两次查询返回的结果不一致。

消除不可重复读验证

解说上述所有事务。

事务1执行:

BEGIN;
set default_transaction_isolation='repeatable read';
SELECT * from users;

id

age

1

6

事务2执行:

BEGIN;
set default_transaction_isolation='repeatable read';
UPDATE users set age = 7 where "id" = 1;
SELECT * from users;

id

age

1

7

执行COMMIT提交事务2,并在事务1中再次查询SELECT * from users

查询结果:

id

age

1

6

事务1没有发生不可重复读现象,age仍然是6。证明在repeatable read事务隔离级别中解决了不可重复读现象。

mvvc解决不可重复读的方式:这个级别与Read Committed不同,可重复读事务中的查询在事务中第一个非事务控制语句开始时确定快照,而不是在事务中当前语句开始时确定快照。因此,单个事务中的连续SELECT命令会看到相同的数据,也就是说,它们不会看到在自己的事务启动后提交的其他事务所做的更改

幻读

PG的MVCC机制在可重复读隔离级别中解决了幻读问题。数据插入时或更新时,会在相应数据行中设置xmin,xmax,xmin,xmax,PG会根据这些辅助列控制事务的可见性,实现效果类似InnoDB的间隙锁。在提交读中,会发生幻读现象,在可重复读中,因为一直使用事务开始时数据库快照,所以消除了幻读。

隐藏列

PostgreSQL中,对于每一行数据(称为一个tuple),包含有多个隐藏字段。

查询命令:select * from pg_attribute where attrelid in (select oid from pg_class where relname = 'users');

attrelid

attname

atttypid

attstattarget

attlen

attnum

attndims

attcacheoff

atttypmod

attbyval

attstorage

attalign

attnotnull

atthasdef

atthasmissing

attidentity

attgenerated

attisdropped

attislocal

attinhcount

attcollation

attacl

attoptions

attfdwoptions

attmissingval

56034

tableoid

26

0

4

-6

0

-1

-1

t

p

i

t

f

f

   

f

t

0

0

         

56034

cmax

29

0

4

-5

0

-1

-1

t

p

i

t

f

f

   

f

t

0

0

         

56034

xmax

28

0

4

-4

0

-1

-1

t

p

i

t

f

f

   

f

t

0

0

         

56034

cmin

29

0

4

-3

0

-1

-1

t

p

i

t

f

f

   

f

t

0

0

         

56034

xmin

28

0

4

-2

0

-1

-1

t

p

i

t

f

f

   

f

t

0

0

         

56034

ctid

27

0

6

-1

0

-1

-1

f

p

s

t

f

f

   

f

t

0

0

         

56034

id

23

-1

4

1

0

-1

-1

t

p

i

t

f

f

   

f

t

0

0

         

56034

........pg.dropped.2........

0

0

-1

2

0

-1

259

f

x

i

f

f

f

   

t

t

0

100

         

56034

age

23

-1

4

3

0

-1

-1

t

p

i

f

f

f

   

f

t

0

0

         

xmin :在创建(insert)记录(tuple)时,记录此值为插入tuple的事务ID。
xmax :默认值为0.在删除tuple时,记录此值。
cmin和cmax :标识在同一个事务中多个语句命令的序列值,从0开始,用于同一个事务中实现版本可见性判断。

oid:行的对象标识符(对象 ID)。这个字段只有在创建表的时候使用了 WITH OIDS,或者是设置了配置参数 default_with_oids 时出现。 这个字段的类型是 oid(和字段同名); 参阅Section 8.12 获取有关这种类型的更多信息。

tableoid: 包含本行的表的 OID。这个字段对那些从继承层次中选取的查询特别有用(参阅 Section 5.8), 因为如果没有它的话,我们就很难说明一行来自哪个独立的表。 tableoid 可以和pg_class 的 oid 字段连接起来获取表名字。

ctid: 一个行版本在它所处的表内的物理位置。请注意,尽管 ctid 可以用于非常快速地定位行版本,但每次 VACUUM FULL 之后, 一个行的 ctid 都会被更新或者移动。 因此 ctid 是不能作为长期的行标识符的。 应该使用OID,或者更好是用户定义的序列号,来标识一个逻辑行。

MVCC与锁

MVCC主要是为解决读写并发加锁的问题,最终是为了减少锁的使用,提高查询效率。在消除不可重复读验证用例中,写对读没有影响。但是在一些必须的场景中,在查询时不允许变更,比如在盘点库存时,不允许出入库,此时可以显式使用for update加上更高级别的锁,从而阻止更新语句并发访问。

参见:

csdn-blog:并发控制

PG官方文档:并发控制

PG官方文档:咨询锁函数

PGSLQ并发控制的更多相关文章

  1. Entity Framework Core 实现MySQL 的TimeStamp/RowVersion 并发控制

    将通用的序列号生成器库 从SQL Server迁移到Mysql 遇到的一个问题,就是TimeStamp/RowVersion并发控制类型在非Microsoft SQL Server数据库中的实现.SQ ...

  2. EntityFramework与TransactionScope事务和并发控制

    最近在园子里看到一篇关于TransactionScope的文章,发现事务和并发控制是新接触Entity Framework和Transaction Scope的园友们不易理解的问题,遂组织此文跟大家共 ...

  3. MySQL MVCC(多版本并发控制)

    概述 为了提高并发MySQL加入了多版本并发控制,它把旧版本记录保存在了共享表空间(undolog),当事务提交之后将重做日志写入磁盘(前提innodb_flush_log_at_trx_commit ...

  4. LINQ to SQL语句(13)之开放式并发控制和事务

    Simultaneous Changes开放式并发控制 下表介绍 LINQ to SQL 文档中涉及开放式并发的术语: 术语 说明 并发 两个或更多用户同时尝试更新同一数据库行的情形. 并发冲突 两个 ...

  5. SQLite剖析之锁和并发控制

    在SQLite中,锁和并发控制机制都是由pager.c模块负责处理的,用于实现ACID(Atomic.Consistent.Isolated和Durable)特性.在含有数据修改的事务中,该模块将确保 ...

  6. [NHibernate]并发控制

    目录 写在前面 文档与系列文章 并发控制 乐观并发控制(Optimistic Concurrency) 一个例子 悲观并发控制(Pessimistic Concurrency) 总结 写在前面 上篇文 ...

  7. Go并发控制之sync.WaitGroup

    WaitGroup 会将main goroutine阻塞直到所有的goroutine运行结束,从而达到并发控制的目的.使用方法非常简单,真心佩服创造Golang的大师们! type WaitGroup ...

  8. MVCC PostgreSQL实现事务和多版本并发控制的精华

    原创文章,同步发自作者个人博客,http://www.jasongj.com/sql/mvcc/ PostgreSQL针对ACID的实现机制 事务的实现原理可以解读为RDBMS采取何种技术确保事务的A ...

  9. mysql事务和并发控制

    谈到事务,首先想到的问题是并发控制.比如两个用户同时操作数据库里面的一张表,一个正在读数据,一个正在删除数据,那么读数据的读出的结果究竟是多少?并发可以提高系统的性能,让多个用户同时操作一份数据,但为 ...

随机推荐

  1. go协程调度

    目录 前言 1. 线程池的缺陷 2.Goroutine 调度器 3.调度策略 3.1 队列轮转 3.2 系统调用 3.3 工作量窃取 4.GOMAXPROCS设置对性能的影响 参考 前言 Gorout ...

  2. windows 10 + tensorflow-gpu 环境搭建

    安装过程可基本按照ubuntu装法,参考https://www.cnblogs.com/xbit/p/9768238.html 其中: conda配置文件:C:\Users\Administrator ...

  3. MySQL高可用主从复制部署

    原文转自:https://www.cnblogs.com/itzgr/p/10233932.html作者:木二 目录 一 基础环境 二 实际部署 2.1 安装MySQL 2.2 初始化MySQL 2. ...

  4. vue 微信二维码扫码登录,附加 自定义样式

    大概流程:   先安装 微信 的登录, 然后 局部引入,局部注册,方法调用,存 token,跳转路由 npm 安装 npm install vue-wxlogin --save-dev 微信安装 微信 ...

  5. 【HMS Core 6.0全球上线】Network Kit全链路网络加速技术,应用无惧网络拥塞

    HMS Core 6.0已于7月15日全球上线,本次版本向广大开发者开放了众多全新能力与技术.其中HMS Core Network Kit开放了全链路网络加速技术,助力开发者为用户提供低时延的畅快网络 ...

  6. fwm环境APP菜品数据加载失败的优化操作

    1)在项目的.env文件中添加如下一行: RESPONSE_CACHE_ENABLED=true 2)拷贝 laravel-worker.conf.example,将laravel字段替换为域名,并执 ...

  7. 安全系列之:跨域资源共享CORS

    目录 简介 CORS举例 CORS protocol HTTP request headers HTTP response headers 基本CORS Preflighted requests 带认 ...

  8. C# AutoMaper简单使用

    AutoMapper它是一种对象与对象之间的映射器,让AutoMapper有意思的就是在于它提供了一些将类型A映射到类型B这种无聊的实例,只要B遵循AutoMapper已经建立的惯例,那么大多数情况下 ...

  9. 加载映射文件几种方式和mapper接口注解执行sql语句

    一.加载映射文件几种方式 二.mapper接口注解执行sql语句 就将xml中的sql语句放到注解的括号中就可以,一般只用于简单的sql语句合适:

  10. MySQL索引、事务、存储引擎

    一.MySQL 索引 1.索引的概念 ●索引是一个排序的列表,在这个列表中存储着索引的值和包含这个值的数据所在行的物理地址(类似于C语言的链表通过指针指向数据记录的内存地址).●使用索引后可以不用扫描 ...