强制性锁和建议性锁的区别

前言:

        所谓建议性锁就是假定人们都会遵守某些规则去干一件事。例如,人与车看到红灯都会停,而看到绿灯才会继续走,我们可以称红绿等为建议锁。但这只是一种规则而已,你并不防止某些人强闯红灯。而强制性锁是你想闯红灯也闯不了。 

       建议性锁只在cooperating processes之间才有用,对cooperating process的理解是最重要的,它指的是会影响其它进程的进程或被别的进程所影响的进程,举两个例子:(1)我们可以同时在两个窗口中运行同一个命令,对同一个文件进行操作,那么这两个进程就是cooperating processes;(2)cat file| sort,那么cat和sort产生的进程就是使用了pipe的cooperating processes。

------------------------------------------------------------------------------------------------------------------------------------------------------------------

APUE中的表述:

        fcntl有强大的功能,它能够复制一个现有的描述符,获得/设置文件描述符标记,获得/设置文件状态标记,获得/设置异步I/O所有权,获得/设置纪录锁。

        当多个用户共同使用,操作一个文件的情况,Linux通常采用的方法就是给文件上锁,来避免共享资源产生竞争的状态。

fcntl文件锁有两种类型:建议性锁和强制性锁

  • 建议性锁是这样规定的:每个使用上锁文件的进程都要检查是否有锁存在,当然还得尊重已有的锁。内核和系统总体上都坚持不使用建议性锁,它们依靠程序员遵守这个规定。(Linux默认是采用建议性锁)

  • 强制性锁是由内核执行的。当文件被上锁来进行写入操作时,在锁定该文件的进程释放该锁之前,内核会阻止任何对该文件的读或写访问,每次读或写访问都得检查锁是否存在。

        使用fcntl文件锁进行I/O操作必须小心:进程在开始任何I/O操作前如何去处理锁,在对文件解锁前如何完成所有的操作,是必须考虑的。如果在设置锁之前打开文件,或者读取该锁之后关闭文件,另一个进程就可能在上锁/解锁操作和打开/关闭操作之间的几分之一秒内访问该文件。当一个进程对文件加锁后,无论它是否释放所加的锁,只要文件关闭,内核都会自动释放加在文件上的建议性锁(这也是建议性锁和强制性锁的最大区别), 所以不要想设置建议性锁来达到永久不让别的进程访问文件的目的(强制性锁才可以)^_^;强制性锁则对所有进程起作用。

在Linux中实现上锁的函数有lock()和fcntl()。

  • lock()用于对文件施加建议性锁

  • fcntl()用于对文件施加建议性锁和强制性锁都行。同时还可以对文件某一条纪录进行上锁,也就是记录锁。

例子:

  • 例1,我有几个进程(不一定有亲缘关系)都通过fctnl机制来操作文件,这个就叫一致的方法。但是,如果同时,又有个流氓进程,管它3721,冲上去,open, write。
    这时候那几个进程fcntl对这种方式无能为力,这样就叫不一致。文件最后的状态就不定了。
    正因为这种锁约束不了其它的访问方式,所以叫建议行锁。强制性锁需要内核支持的,对read, write, open都会检查锁。

  • 例2,所谓建议性锁就是假定人们都会遵守某些规则去干一件事。例如,人与车看到红灯都会停,而看到绿灯才会继续走,我们可以称红绿等为建议锁。但这只是一种规则而已,你并不防止某些人强闯红灯。而强制性锁是你想闯红灯也闯不了。

如何在Linux系统上使用强制性锁呢?

要想让linux支持强制性锁,不但在mount的时候需要加上-o mand(APUE中文版有误,它写成了_omand), 而且对要加锁的文件也需要设置相关权限 (turn on set-group-ID and turn off group-execute)。

------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

  个人理解:

       fcntl使用三个参数 F_SETLK /F_SETLKW,F_UNLCK和F_GETLK,来分别要求、释放、测试record locks,record locks是对文件一部分而不是整个文件的锁,这种细致的控制使得进程更好地协作以共享文件资源。fcntl能够用于读取锁和写入锁,read lock也叫shared lock(共享锁),因为多个cooperating process能够在文件的同一部分建立读取锁;write lock被称为exclusive lock(排斥锁),因为任何时刻只能有一个cooperating process在文件的某部分上建立写入锁。如果cooperating processes对文件进行操作,那么它们可以同时对文件加read lock,在一个cooperating process加write lock之前,必须释放别的cooperating process加在该文件的read lock和wrtie lock,也就是说,对于文件只能有一个write lock存在,read lock和wrtie lock不能共存。

 

建议性锁 (针对合作进程而言的)

建议性锁,就是一种软弱的锁——必须要在参与所有共享数据操作的所有进程之间都遵守这样神圣的约定的前提,建议性的锁才发挥作用,而劝告性的建议锁对于协作进程来说已经足够了!!但是,有读写权限的进程,不遵守这个约定,就会把这一切都搞杂,约定对于他们来说,不好用。但建议性锁也有他的优势:相对与强制性锁,性能好一些。个人理解。

 

协作进程(cooperating processes):如果每个进程所使用的函数都以一致的方法处理记录锁,互斥锁等,则这些进程被称为协作进程。

 

强制性锁

         这个就好理解了,一旦加强制性锁(读锁或写锁),在“可以共享读,但不能共享写”的原则下,其他进程就被限制了,就不会出现不一致了。

<think>好的,我现在要解决用户的问题:REPEATABLE READSERIALIZABLE隔离级别如何通过记录实现数据一致性,以及与表索引的关系。用户之前已经问过关于索引的内容,现在需要结合之前的回答提供的引用内容来详细解答。 首先,我需要回顾一下用户提供的引用内容: 引用[1]提到间隙在REPEATABLE READ下防止幻读,定索引间隙。引用[2][3]解释了表区别,以及不同隔离级别下的行为。引用[4]提到了共享排他的使用。 用户现在的问题涉及两个隔离级别:REPEATABLE READSERIALIZABLE,以及它们如何通过记录(行)保证数据一致性,同时关联到索引的关系。需要详细说明每个隔离级别的机制,如何防止并发问题,并对比它们与表级的不同。 首先,我需要明确各个隔离级别的基本特性。REPEATABLE READ在InnoDB中通过行间隙来避免不可重复读幻读。而SERIALIZABLE通常通过更严格的,比如在读取时加共享,可能导致更多的冲突,甚至表级。 接下来,记录(行)的作用是定特定行,而间隙定索引之间的间隙,防止插入。这在REPEATABLE READ下组合成临键(Next-key Locks),定行间隙。SERIALIZABLE可能使用更强的机制,比如所有读取操作都加,导致类似表的行为。 需要结合索引的作用,因为InnoDB的行依赖于索引。如果没有索引,可能会升级为表,但根据用户之前的回答,即使没有索引,全表扫描也会导致行,但性能差。这可能不同,表是显式的LOCK TABLES,而行是隐式通过扫描施加的。 另外,用户之前的问题中提到对整张表的索引加的方法,如通过主键范围扫描加FOR UPDATE,这与隔离级别中的机制有关联。例如,在REPEATABLE READ下,这样的操作会施加行间隙,而SERIALIZABLE可能更严格。 现在需要组织这些信息,分点回答: 1. REPEATABLE READ隔离级别下的机制:记录、间隙、临键,如何防止不可重复读幻读,与索引的关系。 2. SERIALIZABLE隔离级别下的机制:是否所有SELECT都自动加,如何导致更高的冲突,可能涉及表级或更严格的行。 3. 数据一致性的实现:通过不同的组合,防止脏读、不可重复读、幻读。 4. 与索引的关系:行依赖索引,如果没有索引可能表或全表扫描加。 5. 与表的对比:表的粒度更粗,影响并发性能,而行间隙提供更细粒度的控制。 需要引用用户提供的资料,例如引用[1]中的间隙作用,引用[3]中的行隔离级别的关系,引用[4]中的FOR UPDATE排他。 同时,要确保回答结构清晰,分点明确,使用用户要求的格式,如行内公式用$...$,独立公式用$$...$$,但在这个问题中可能公式较少,主要关注机制的解释。 最后,生成相关问题,可能需要包括不同隔离级别的选择建议,机制对性能的影响,如何避免死等。</think>### **REPEATABLE READ与SERIALIZABLE隔离级别下机制与数据一致性分析** 在InnoDB中,**隔离级别**通过不同的策略(如记录、间隙、表等)实现数据一致性。以下从`REPEATABLE READ`(可重复读)`SERIALIZABLE`(可串行化)两个级别展开,结合记录、索引的关系进行详细说明。 --- ### **一、REPEATABLE READ隔离级别的机制** #### **1. 记录(行)与间隙的协同** - **记录(Row Locks)**: 定索引中的具体记录(如`SELECT ... FOR UPDATE`对主键加),防止其他事务修改或删除已读数据[^4]。 **示例**: ```sql -- 事务A BEGIN; SELECT * FROM users WHERE id = 10 FOR UPDATE; -- 对id=10的行加排他(X) ``` 其他事务若尝试修改`id=10`的记录会被阻塞,保证事务A的**可重复读**。 - **间隙(Gap Locks)**: 在`REPEATABLE READ`下,InnoDB会对**索引间隙**加,防止幻读。例如,若当前存在`id=5``id=15`的记录,对`id BETWEEN 10 AND 20`的查询会定`(5,15]`的间隙,阻止插入`id=12`的新记录[^1]。 **示例**: ```sql -- 事务A BEGIN; SELECT * FROM users WHERE id > 10 AND id < 20 FOR UPDATE; -- 定(10,20)的间隙 -- 事务B尝试插入id=15的记录会被阻塞 ``` - **临键(Next-Key Locks)**: 记录与间隙的组合(例如定`(5,15]`),既保护现有记录,又阻止新记录插入间隙。这是`REPEATABLE READ`防幻读的核心机制[^1]。 #### **2. 与索引的关系** - **依赖索引定位记录**: 记录间隙均通过索引实现。若查询条件无索引,InnoDB会退化为全表扫描并对所有记录加(等效于全表行+间隙)[^3]。 **示例**: ```sql -- 无索引的查询 UPDATE users SET name = 'Alice' WHERE age > 30; -- 全表扫描,对所有记录加 ``` --- ### **二、SERIALIZABLE隔离级别的机制** #### **1. 严格的策略** - **自动加**: 在`SERIALIZABLE`级别下,所有普通`SELECT`查询自动转换为`SELECT ... FOR SHARE`(共享),其他事务无法修改被定的行[^3]。 **示例**: ```sql -- 事务A(SERIALIZABLE级别) BEGIN; SELECT * FROM users WHERE id = 10; -- 自动加共享(S) -- 事务B尝试UPDATE users SET name='Bob' WHERE id=10会被阻塞 ``` - **冲突与表级倾向**: 频繁的共享可能导致大量竞争,甚至触发表级意向(如`IS`)的互斥,降低并发性能。极端情况下,可能退化为近似表的行为。 #### **2. 数据一致性的实现** - **完全串行化**: 通过强制事务串行执行,消除所有并发问题(脏读、不可重复读、幻读)。 - **与索引的关系**: 即使使用索引,`SERIALIZABLE`也会对涉及的行间隙加,但范围更严格(例如对全表加倾向更高)。 --- ### **三、与表索引的关系对比** | **特性** | **REPEATABLE READ** | **SERIALIZABLE** | **表** | |------------------------|------------------------------|------------------------------|------------------------------| | **粒度** | 行级+间隙 | 行级+更严格的间隙 | 整表定 | | **索引依赖** | 必须通过索引加 | 必须通过索引加 | 不依赖索引 | | **幻读处理** | 通过间隙防止 | 通过强制串行化消除 | 不直接解决 | | **并发性能** | 高(细粒度) | 低(频繁冲突) | 最低(完全阻塞) | #### **关键区别** - **表**(如`LOCK TABLES`)直接阻塞所有读写操作,而**行级**允许其他事务访问未定部分[^2]。 - **索引**(行/间隙)的生效依赖查询是否使用索引,否则可能退化为全表扫描加[^3]。 --- ### **四、数据一致性实现总结** 1. **REPEATABLE READ**: - 通过**记录**保证已读数据不被修改(可重复读)。 - 通过**间隙**阻止新数据插入(防幻读)。 - 依赖索引实现高效控制,若无索引则性能下降[^1][^3]。 2. **SERIALIZABLE**: - 所有读操作自动加共享强制事务串行化。 - 冲突更频繁,可能接近表的阻塞效果,但仍是行级实现[^3]。 3. **表与索引的协同**: - 显式表(如`LOCK TABLES`)与InnoDB的行级互斥(通过意向冲突)[^2]。 - 行级的细粒度控制依赖于合理的索引设计。 --- ### **相关问题** 1. 如何在`REPEATABLE READ`级别下优化索引以减少间隙范围? 2. `SERIALIZABLE`隔离级别是否会导致死概率增加? 3. 无索引表在`REPEATABLE READ`下的行为与表有何本质区别? --- **引用标注** [^1]: 间隙在`REPEATABLE READ`下定索引间隙以防止幻读,需依赖索引定位范围。 [^2]: 表直接阻塞整表操作,与行级通过意向实现互斥管理。 [^3]: `SERIALIZABLE`级别下普通查询自动加共享强制事务串行化执行。 [^4]: `SELECT ... FOR UPDATE`显式加排他定索引记录以保证数据一致性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值