门户资源分享网站模板,一篇好的营销软文,php网站开发职位,江门网站建设推广策划PostgreSQL是如何实现隔离级别的#xff1f;
事务有哪些特性#xff1f;
事务看起来感觉简单#xff0c;但是要实现事务必须要遵守 4 个特性#xff0c;分别如下#xff1a;
原子性#xff08;Atomicity#xff09;#xff1a;一个事务中的所有操作#xff0c;要么…PostgreSQL是如何实现隔离级别的
事务有哪些特性
事务看起来感觉简单但是要实现事务必须要遵守 4 个特性分别如下
原子性Atomicity一个事务中的所有操作要么全部完成要么全部不完成不会结束在中间某个环节而且事务在执行过程中发生错误会被回滚到事务开始前的状态就像这个事务从来没有执行过一样就好比买一件商品购买成功时则给商家付了钱商品到手购买失败时则商品在商家手中消费者的钱也没花出去。一致性Consistency是指事务操作前和操作后数据满足完整性约束数据库保持一致性状态。比如用户 A 和用户 B 在银行分别有 800 元和 600 元总共 1400 元用户 A 给用户 B 转账 200 元分为两个步骤从 A 的账户扣除 200 元和对 B 的账户增加 200 元。一致性就是要求上述步骤操作后最后的结果是用户 A 还有 600 元用户 B 有 800 元总共 1400 元而不会出现用户 A 扣除了 200 元但用户 B 未增加的情况该情况用户 A 和 B 均为 600 元总共 1200 元。隔离性Isolation数据库允许多个并发事务同时对其数据进行读写和修改的能力隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致因为多个事务同时使用相同的数据时不会相互干扰每个事务都有一个完整的数据空间对其他并发事务是隔离的。也就是说消费者购买商品这个事务是不影响其他消费者购买的。持久性Durability事务处理结束后对数据的修改就是永久的即便系统故障也不会丢失。
事务隔离
PostgreSQL 是如何保证isolation的 接下来我们通过这篇文章来了解 PostgreSQL 如何实现事务隔离
标准SQL事务隔离级别
隔离级别脏读不可重复读幻读读未提交可能可能可能读已提交不可能可能可能可重复读不可能不可能可能可串行化不可能不可能不可能
SQL标准定义了四个级别的事务隔离。
各个级别不应该发生的现象是 脏读 一个事务读取了另一个未提交事务写入的数据。 不可重复读 一个事务重新读取前面读取过的数据发现该数据已经被另一个已经提交的事务修改。 幻读 一个事务重新执行一个查询返回符合查询条件的行的集合发现满足查询条件的行的集合因为其它最近提交的事务而发生了改变。
**在PostgreSQL里你可以请求四种可能的事务隔离级别中的任意一种。但是在内部 实际上只有三种独立的隔离级别分别对应读已提交可重复读和可串行化。**如果你选择了读未提交的级别 实际上你获得的是读已提交并且在PostgreSQL的可重复读实现中幻读是不可能的 所以实际的隔离级别可能比你选择的更严格。这是 SQL 标准允许的四种隔离级别只定义了哪种现像不能发生 但是没有定义那种现像一定发生。PostgreSQL只提供三种隔离级别的原因是 这是把标准的隔离级别与多版本并发控制架构映射起来的唯一合理方法。
PostgreSQL实现的事务隔离等级如下表所示
隔离等级脏读不可重复读幻读串行化异常读已提交不可能可能可能可能可重复读[1]不可能不可能PG中不可能可能可串行化不可能不可能不可能不可能
PostgreSQL 在 MVCC 里如何工作的
PostgreSQL事务标识
每当事务开始时事务管理器就会为其分配一个称为**事务标识transaction id, txid**的唯一标识符。 PostgreSQL的txid是一个32位无符号整数总取值约42亿。在事务启动后执行内置的txid_current()函数即可获取当前事务的txid如下所示。
testdb# BEGIN;
BEGIN
testdb# SELECT txid_current();txid_current
--------------100
(1 row)PostgreSQL保留以下三个特殊txid
0表示**无效Invalid**的txid。1表示**初始启动Bootstrap**的txid仅用于数据库集群的初始化过程。2表示**冻结Frozen**的txid.
txid可以相互比较大小。例如对于txid100的事务大于100的txid属于“未来”且对于txid100的事务而言都是**不可见invisible**的小于100的txid属于“过去”且对该事务可见如下图(a)所示。 因为txid在逻辑上是无限的而实际系统中的txid空间不足4字节取值空间约42亿因此PostgreSQL将txid空间视为一个环。对于某个特定的txid其前约21亿个txid属于过去而其后约21亿个txid属于未来。如(b)所示。
元组结构
可以将表页中的堆元组分为两类普通数据元组与TOAST元组。本节只会介绍普通元组。
堆元组由三个部分组成即HeapTupleHeaderData结构空值位图以及用户数据如下图所示。
元组结构 HeapTupleHeaderData结构在src/include/access/htup_details.h中定义。 typedef struct HeapTupleFields
{TransactionId t_xmin; /* 插入事务的ID */TransactionId t_xmax; /*删除或锁定事务的ID*/union{CommandId t_cid; /* 插入或删除的命令ID */TransactionId t_xvac; /* 老式VACUUM FULL的事务ID */} t_field3;
} HeapTupleFields;typedef struct DatumTupleFields
{int32 datum_len_; /* 变长头部长度*/int32 datum_typmod; /* -1或者是记录类型的标识 */Oid datum_typeid; /* 复杂类型的OID或记录ID */
} DatumTupleFields;typedef struct HeapTupleHeaderData
{union{HeapTupleFields t_heap;DatumTupleFields t_datum;} t_choice;ItemPointerData t_ctid; /* 当前元组或更新元组的TID *//* 下面的字段必需与结构MinimalTupleData相匹配! */uint16 t_infomask2; /* 属性与标记位 */uint16 t_infomask; /* 很多标记位 */uint8 t_hoff; /* 首部位图填充的长度 *//* ^ - 23 bytes - ^ */bits8 t_bits[1]; /* NULL值的位图 —— 变长的 *//* 本结构后面还有更多数据 */
} HeapTupleHeaderData;typedef HeapTupleHeaderData *HeapTupleHeader;虽然HeapTupleHeaderData结构包含七个字段但后续部分中只需要了解四个字段即可。
t_xmin保存插入此元组的事务的txid。t_xmax保存删除或更新此元组的事务的txid。如果尚未删除或更新此元组则t_xmax设置为0即无效。t_cid保存命令标识command id, cidcid意思是在当前事务中执行当前命令之前执行了多少SQL命令从零开始计数。例如假设我们在单个事务中执行了三条INSERT命令BEGIN;INSERT;INSERT;INSERT;COMMIT;。如果第一条命令插入此元组则该元组的t_cid会被设置为0。如果第二条命令插入此元组则其t_cid会被设置为1依此类推。t_ctid保存着指向自身或新元组的元组标识符tid。tid用于标识表中的元组。在更新该元组时其t_ctid会指向新版本的元组否则t_ctid会指向自己。
元组的增删改查
元组的具体表示如下图所示 插入
在插入操作中新元组将直接插入到目标表的页面中如下图所示 假设元组是由txid99的事务插入页面中的在这种情况下被插入元组的首部字段会依以下步骤设置。
Tuple_1
t_xmin设置为99因为此元组由txid99的事务所插入。t_xmax设置为0因为此元组尚未被删除或更新。t_cid设置为0因为此元组是由txid99的事务所执行的第一条命令所插入的。t_ctid设置为(0,1)指向自身因为这是该元组的最新版本。 pageinspect PostgreSQL自带了一个第三方贡献的扩展模块pageinspect可用于检查数据库页面的具体内容。 testdb# CREATE EXTENSION pageinspect;
CREATE EXTENSION
testdb# CREATE TABLE tbl (data text);
CREATE TABLE
testdb# INSERT INTO tbl VALUES(A);
INSERT 0 1
testdb# SELECT lp as tuple, t_xmin, t_xmax, t_field3 as t_cid, t_ctid FROM heap_page_items(get_raw_page(tbl, 0));
tuple | t_xmin | t_xmax | t_cid | t_ctid
--------------------------------------1 | 99 | 0 | 0 | (0,1)
(1 row)删除
在删除操作中目标元组只是在逻辑上被标记为删除。目标元组的t_xmax字段将被设置为执行DELETE命令事务的txid。如下图所示 假设Tuple_1被txid111的事务删除。在这种情况下Tuple_1的首部字段会依以下步骤设置。
Tuple_1
t_xmax被设为111。
如果txid111的事务已经提交那么Tuple_1就不是必需的了。通常不需要的元组在PostgreSQL中被称为死元组dead tuple。
死元组最终将从页面中被移除。清除死元组的过程被称为清理VACUUM过程。
更新
在更新操作中PostgreSQL在逻辑上实际执行的是删除最新的元组并插入一条新的元组。 假设由txid99的事务插入的行被txid100的事务更新两次。
当执行第一条UPDATE命令时Tuple_1的t_xmax被设为txid 100在逻辑上被删除然后Tuple_2被插入接下来重写Tuple_1的t_ctid以指向Tuple_2。Tuple_1和Tuple_2的头部字段设置如下。
Tuple_1
t_xmax被设置为100。t_ctid从(0,1)被改写为(0,2)。
Tuple_2
t_xmin被设置为100。t_xmax被设置为0。t_cid被设置为0。t_ctid被设置为(0,2)。
当执行第二条UPDATE命令时和第一条UPDATE命令类似Tuple_2被逻辑删除Tuple_3被插入。Tuple_2和Tuple_3的首部字段设置如下。
Tuple_2
t_xmax被设置为100。t_ctid从(0,2)被改写为(0,3)。
Tuple_3
t_xmin被设置为100。t_xmax被设置为0。t_cid被设置为1。t_ctid被设置为(0,3)。
与删除操作类似如果txid100的事务已经提交那么Tuple_1和Tuple_2就成为了死元组而如果txid100的事务中止Tuple_2和Tuple_3就成了死元组。
提交日志clog
PostgreSQL在提交日志Commit Log, clog中保存事务的状态。提交日志通常称为clog分配于共享内存中并用于事务处理过程的全过程。
事务状态
PostgreSQL定义了四种事务状态即IN_PROGRESSCOMMITTEDABORTED和SUB_COMMITTED。
前三种状态涵义显而易见。例如当事务正在进行时其状态为IN_PROGRESS依此类推。
SUB_COMMITTED状态用于子事务。
提交日志如何工作
提交日志下称clog在逻辑上是一个数组由共享内存中一系列8KB页面组成。数组的序号索引对应着相应事务的标识而其内容则是相应事务的状态。clog的工作方式如下图所示 T1txid 200提交txid 200的状态从IN_PROGRESS变为COMMITTED。 T2txid 201中止txid 201的状态从IN_PROGRESS变为ABORTED。 txid不断前进当clog空间耗尽无法存储新的事务状态时就会追加分配一个新的页面。
当需要获取事务的状态时PostgreSQL将调用相应内部函数读取clog并返回所请求事务的状态。
事务快照
**事务快照transaction snapshot**是一个数据集存储着某个特定事务在某个特定时间点所看到的事务状态信息哪些事务处于活跃状态。这里活跃状态意味着事务正在进行中或还没有开始。
事务快照在PostgreSQL内部的文本表示格式定义为100:100:。举个例子这里100:100:意味着txid 100的事务处于非活跃状态而txid ≥ 100的事务处于活跃状态。 内置函数txid_current_snapshot及其文本表示 函数txid_current_snapshot显示当前事务的快照。 testdb# SELECT txid_current_snapshot();
txid_current_snapshot
-----------------------
100:104:100,102
(1 row)txid_current_snapshot的文本表示是xmin:xmax:xip_list各部分描述如下。 xmin 最早仍然活跃的事务的txid。所有比它更早的事务txid xmin要么已经提交并可见要么已经回滚并生成死元组。 xmax 第一个尚未分配的txid。所有txid ≥ xmax的事务在获取快照时尚未启动因而其结果对当前事务不可见。 xip_list 获取快照时活跃事务的txid列表。该列表仅包括xmin与xmax之间的txid。 例如在快照100:104:100,102中xmin是100xmax是104而xip_list为100,102。 以下显示了两个具体的示例 事务快照的表示样例 第一个例子是100:100:如图图(a)所示此快照表示 因为xmin为100因此txid 100的事务是非活跃的因为xmax为100因此txid ≥ 100的事务是活跃的 第二个例子是100:104:100,102如图(b)所示此快照表示 txid 100的事务不活跃。txid ≥ 104的事务是活跃的。txid等于100和102的事务是活跃的因为它们在xip_list中而txid等于101和103的事务不活跃。 **事务快照是由事务管理器提供的。在READ COMMITTED隔离级别事务在执行每条SQL时都会获取快照其他情况下REPEATABLE READ或SERIALIZABLE隔离级别事务只会在执行第一条SQL命令时获取一次快照。**获取的事务快照用于元组的可见性检查。
使用获取的快照进行可见性检查时所有活跃的事务都必须被当成IN PROGRESS的事务等同对待无论它们实际上是否已经提交或中止。这条规则非常重要因为它正是READ COMMITTED和REPEATABLE READ/SERIALIZABLE隔离级别中表现差异的根本来源我们将在接下来几节中频繁回到这条规则上来。
如下图所示
事务管理器与事务
事务管理器始终保存着当前运行的事务的有关信息。假设三个事务一个接一个地开始并且Transaction_A和Transaction_B的隔离级别是READ COMMITTEDTransaction_C的隔离级别是REPEATABLE READ。 T1 Transaction_A启动并执行第一条SELECT命令。执行第一个命令时Transaction_A请求此刻的txid和快照。在这种情况下事务管理器分配txid200并返回事务快照200:200:。 T2 Transaction_B启动并执行第一条SELECT命令。事务管理器分配txid201并返回事务快照200:200:因为Transaction_A(txid200)正在进行中。因此无法从Transaction_B中看到Transaction_A。 T3 Transaction_C启动并执行第一条SELECT命令。事务管理器分配txid202并返回事务快照200:200:因此不能从Transaction_C中看到Transaction_A和Transaction_B。 T4 Transaction_A已提交。事务管理器删除有关此事务的信息。 T5 Transaction_B和Transaction_C执行它们各自的SELECT命令。 Transaction_B需要一个新的事务快照因为它使用了READ COMMITTED隔离等级。在这种情况下Transaction_B获取新快照201:201:因为Transaction_A(txid200)已提交。因此Transaction_A的变更对Transaction_B可见了。 Transaction_C不需要新的事务快照因为它处于REPEATABLE READ隔离等级并继续使用已获取的快照即200:200:。因此Transaction_A的变更仍然对Transaction_C不可见。
总结
PostgreSQL 是支持事务的事务的四大特性是原子性、一致性、隔离性、持久性我们这次主要讲了隔离性。
当多个事务并发执行的时候会引发脏读、不可重复读、幻读这些问题那为了避免这些问题SQL 提出了四种隔离级别分别是读未提交、读已提交、可重复读、串行化从左往右隔离级别顺序递增隔离级别越高意味着性能越差PostgreSQL 引擎的默认隔离级别是读已提交。
**在PostgreSQL里你可以请求四种可能的事务隔离级别中的任意一种。但是在内部 实际上只有三种独立的隔离级别分别对应读已提交可重复读和可串行化。**如果你选择了读未提交的级别 实际上你获得的是读已提交并且在PostgreSQL的可重复读实现中幻读是不可能的 所以实际的隔离级别可能比你选择的更严格。
而对于幻读现象不建议将隔离级别升级为串行化因为这会导致数据库并发时性能很差。PostgreSQL 引擎的默认隔离级别虽然是「读已提交」
PostgreSQL 事务快照是由事务管理器提供的。在READ COMMITTED隔离级别事务在执行每条SQL时都会获取快照其他情况下REPEATABLE READ或SERIALIZABLE隔离级别事务只会在执行第一条SQL命令时获取一次快照。获取的事务快照用于元组的可见性检查;
参考资料
[1] Abraham Silberschatz, Henry F. Korth, and S. Sudarshan, “Database System Concepts”, McGraw-Hill Education, ISBN-13: 978-0073523323[2] Dan R. K. Ports, and Kevin Grittner, “Serializable Snapshot Isolation in PostgreSQL”, VDBL 2012[3] Thomas M. Connolly, and Carolyn E. Begg, “Database Systems”, Pearson, ISBN-13: 978-0321523068[4] PostgreSQL指南内幕探索[5] PostgreSQL 9.4.4 中文手册[6] 事务隔离级别是怎么实现的
