完整性和一致性基石——GBase8s锁浅析

Posted 2022-03-24 麒思妙想

基本概念

什么是锁

锁的对象是数据库中的数据对象，如关系型数据库中的表、记录、属性、索引等， 对数据对象加锁的时机是在事务对其进行操作之前，向系统发出加锁请求。加锁后事务 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