完整性和一致性基石——GBase8s锁浅析_数据库

基本概念

什么是锁

锁的对象是数据库中的数据对象,如关系型数据库中的表、记录、属性、索引等, 对数据对象加锁的时机是在事务对其进行操作之前,向系统发出加锁请求。加锁后事务 T 就取得了对该数据对象的控制,在事务 T 释放它的锁之前,其他事务不能对此数据对象进 行任何操作。封锁是一种排队机制,将并行任务按锁的先后顺序排队,把并行任务变成串行任务。

为什么要加锁

加锁的目的,其实是为了保证数据的一致性。 当多个线程并发访问某个数据时,加锁,可以保证这个数据在任何时刻最多只有一个线程在访问,保证数据的完整性和一致性。

锁的分类

锁可以按照锁粒度划分,可以按照数据库管理角度划分。

按照锁粒度划分

按照锁粒度划分,可以将锁划分成 行锁,页锁和表锁。

按照数据库管理角度划分

按照数据库管理角度划分,可以将锁分成排他锁和共享锁。

共享锁:

共享锁,也叫读锁,或者 S 锁,共享锁锁定的资源可以被其他用户读取,但不能修改。 在进行 SElECT 的时候,会将对象进行共享锁锁定,当数据读取完毕之后,就会释放共享锁,这样就可以保证数据在读取时不被修改。

排他锁:

排他锁也叫做独占锁,写锁或者 X 锁,排他锁锁定的数据只允许进行锁定操作的事务使用,其他事务无法对已锁定的数据进行查询或者修改。

从程序员角度进行划分

乐观锁,认为对同一个数据并发操作不会总发生,是小概率事件,因此不用每次对数据进行更新或者删除。

悲观锁(Pessimistic Locking),通过数据库自身的锁机制来实现,从而保证数据操作的排他性。

  • 乐观锁适合读操作多的场景,相对来说写的操作⽐较少。它的优点在于程序实现,不存在死锁问题,不过适⽤场景也会相对乐观,因为它阻⽌不了除了程序以外的数据库操作。
  • 悲观锁适合写操作多的场景,因为写的操作具有排它性。采⽤悲观锁的⽅式,可以在数据库层⾯阻⽌其他事务对该数据的操作权限,防⽌读-写和写-写的冲突

GBase 8S 的锁

GBase8s 采用全局管理的封锁机制,在共享内存中分配一块内存集中标记锁的使用情 况,在每个锁结构中保存锁的拥有者、锁定的对象(是表、记录、还是行)、锁的类型等。 在 GBase8s中每个锁占用 128 Byte。

数据库级锁(Database-Ievel Locks)

在我们通过 CONNECT DATABASE 或者 CREATE DATABASE 语句访问数据库时, 系统都将自动在该数据库上加上一个共享(S)锁,这样可以防止其他用户删除数据库或 者在该数据库上加排它(X)锁。

表级锁(Table-Ievel Locks)

表级锁就是指锁定的对象是一个表,可以通过如下语句显式地对表加锁和释放锁:

BEGIN WORK;

LOCK TABLE tab1 IN EXCLUSIVE MODE;

LOCK TABLE tab2 IN SHARE MODE;

UNLOCK TABLE tab1;

在执行如下一些 DDL 语句时,GBase8t 会自动对表进行加锁,如 ALTER FRAGMENT、 ALTER INDEX、ALTER TABLE、CREATE INDEX (如果没有使用 ONLINE 模式)、DROP INDEX(如果没有使用 ONLINE 模式)、RENAME COLUMN、RENAME TABLE。

在整个表或者表中的大部分数据需要更新时,使用表级锁的效率高。

页级锁(Page Locks)

GBase8t 物理上把多行记录存放在数据页(Page)上,页级锁指锁的对象是一个数据 页,当采用页级锁访问记录时,GBase8t 会自动对访问的数据页进行加锁。当按物理顺序 访问和更新多条记录时,使用页级锁的效率较高。

可以通过如下方式指定页级锁模式:

ALTER TABLE tab1 LOCK MODE (PAGE);

CREATE TABLE tab1 () LOCK MODE PAGE ;

CREATE TABLE 时若不指定锁模式,则将采用 ONCONFIG 参数 DEF_TABLE_ LOCKMODE 来指定表的锁模式。

行级锁(Row Locks)

关系型数据库的数据是按行来管理的,所以行级锁很容易理解。在 OLTP 系统中行级 锁的使用很广泛,只需要锁定所访问的少数记录情况,使用行级锁的效率较高。

可以通过如下方式指定行级锁模式:

ALTER TABLE tab1 LOCK MODE (ROW);

CREATE TABLE tab1 () LOCK MODE ROW ;

CREATE TABLE 时若不指定锁模式,则将采用 ONCONFIG 参数 DEF_TABLE_ LOCKMODE 来指定表的锁模式。

索引锁(Index key)

索引采用 B+树的存储结构,所以对索引的锁管理就是管理索引的 Key 值。数据库采 用开、闭区域的方式进行索引的锁管理,示例如下:

Create table tab1 (c1 int,c2 int) lock mode row;
Create unique index idx_tab1 on tab1(c1);
Insert into tab1 values(1,2);
Insert into tab1 values(2,2);
Insert into tab1 values(3,2);

假设表中只有如上 3 行记录,当执行 update tab1 set c1=0 where c1>=3;语句时,GBase8s 将对索引 key 值为 3 的记录进行闭区间加锁,意味着此时不能新增 key 值大于 3 的记录。 若此时执行 insert into tab1 values(4,2),则会提示 Index 锁冲突错误。

活锁、死锁问题的解决

锁的问题(锁等待、死锁)大部分由于没有正确理解锁的管理、使用方式导致。要解决锁的问题,我们可以从如下几个方面进行尝试。

(1) 应用程序锁使用模式设置

通过 onstat -g sql 查看 SESSION 使用的锁等待模式和隔离级别,要为不同的应用设置 合理的隔离级别和锁等待模式。如在应用程序加入如下语句:

1)Dirty Read(脏读)
设置为Dirty Read隔离级别的参考语句如下:
SET ISOLATION TO DIRTY READ;

2)Commited Read(只读已提交的数据)
设置为该级别的参考语句如下:
SET ISOLATION TO COMMITTED READ;

3)Cursor Stability(游标稳定性)
参考设置语句如下:
SET ISOLATION TO CURSOR STABILITY;

4)Repeatable Read(可重复读)
参考设置语句如下:
SET ISOLATION TO REPEATABLE READ;

5)Last Committed Read(读取最后提交的数据)
设置语句参考如下:
SET ISOLATION TO COMMITTED READ LAST COMMITTED;

(2)应用程序避免使用不必要的锁

许多应用程序的 SQL 语句由于没有正确地使用索引 INDEX,导致对整个表进行了锁 定,导致并发遇到锁的问题。需要通过 SQL 优化和创建合理的索引,避免顺序扫描带来 的锁冲突问题。

由于顺序扫描导致的锁等待问题:创建表 test_lock,采用行级锁,并在 c1 字段上创建 索引,插入 3 行测试数据。

create table test_lock (c1 int,c2 int,c3 char(10)) lock mode row;
create index idx_test_lock on test_lock(c1);
insert into test_lock values(1,1,'abc');
insert into test_lock values(2,2,'abc');
insert into test_lock values(3,3,'abc');

Session 1 通过索引扫描来修改第 2 行记录:

Begin work;
update test_lock set c3='new' where c1=2;

参考链接

https://zhuanlan.zhihu.com/p/153546467