浅析MongoDB中的意向锁

  • 时间:
  • 浏览:1

上方大家分析了MongoDB中意向锁的形态学 图,假设大家现在对db1加了多量的IS锁,现在大家要对db1加IX锁,为了检查IX锁不是和GrantList冲突,能够 对GrantList进行遍历进行冲突检测,什么都有有做是不高效的。

MongoDB意向锁的死锁检测基于广度优先遍历(BFS)算法。某个锁请求不是会产生死锁,等价于 “从有向图中的其他出发,不是可不可不可不可以够找到3个 环”。如保使用BFS算法找有向图的环,不在 本文的讨论范围内。在将死锁检测规约为成环问题报告 的过程中,如保构图是关键,如保描述"点",点与点的依赖关系(边)是哪些地方?读者不妨先自行思考一下。

上图中,有3个 Lock,分别为Lock1, Lock2, Lock3,Lock1当前持有Res1,等待英文英文Res2, Lock2当前持有Res2,等待英文英文Res3,Lock3 当前持有Res3,等待英文英文Res1。很明显死锁了,其他如保将其转化为有向图,使得计算机能帮大家检测死锁呢。

该参数的作用机制如下代码诠

mongoDB 默认是行级并发,大家希望多行并发读写互不影响,其他大家又希望对在dropCollection时,不到有任何对表的读写在操作,你是什么 “不希望”也是双向的,即在对表并发读写时,大家什么都有有希望dropCollection在操作。

在对Collection2中的记录进行读操作时,能够 先获得其IS锁。其他先递归获得其父节点Global的IS锁。

通过上述的例子,大家可不可不可不可以够发现,意向锁的设计较为简洁,仅仅通过3个 矩阵(冲突矩阵),两条原则(递归加锁)就可不可不可不可以够满足数据库系统中对资源的并发控制的需求。

03

其使用法子为:

图中Release动作的依赖并全部都是能够 的,可不可不可不可以够繁复成:

而mongoDB引入的compatibleFirst属性,可不可不可不可以够理解为对该繁复版模型的3个 优化,引入了等待英文优先级,其他将优先级的设置暴露给了意向锁的使用者。在mongoDB中,不到Global的S/X锁设置了compatibleFirst=true,其解释如下:

3. 可能性获锁成功,则将锁请求加入到GrantList中,并累加锁资源的compatibleFirstCount计数器。

我我觉得意向锁的设计非常简洁,其他理论和工程实践上,大家至少能够 考虑如下几点:

04

此时,可能性执行对collection2的记录的写操作,则能够 获得Global的IX锁,Db2的IX锁,Collection2的IX锁,从根节点一路下来,IX与IS情况报告互不冲突,其他加锁成功。如下图:

Mongo中意向锁的实现

死锁检测

在执行dbStats命令时,希望和dropDB/insert命令互斥,其他又不影响对表的并发读。

比如,大家你会给DB添加X锁,就可不可不可不可以够执行 (newLockObject).lock("mydb", MODE_X)。

在工程实践中,可不可不可不可以够通过GrantList判断某个资源不是被某个锁持有。核心代码如下:

MongoDb使用了繁复版的意向锁协议,抛却了SIX情况报告,保留了 IS/IX/S/X有一种锁情况报告。其冲突矩阵为:

大家从Lock1 Acquire Res2来看, 可能性Res2被Lock2持有,什么都有有Lock1 Acquire Res2 依赖 Lock2 Release Res2。 而Lock2 Release Res2 依赖 Lock2 Acquire Res3, Lock2 Acquire Res3 依赖 Lock3 Release Res3。 如下图所示:

而意向锁协议,是有一种对树形(层级)资源进行并发控制的协议。它由"操作约定"和"冲突矩阵"两累积组成,且看下文。

每个Bucket是ResourceId->LockHead的哈希表。该哈希表被Bucket对象中的mutex保护。

代码框架上,使用_queue进行BFS的迭代。

如保处理死锁。

思考与尝试

第3个 例子中,大家似乎用传统的rwlock就可不可不可不可以够处理,在对表进行并发读写前,加rlock,在对表进行dropCollection前,加wlock。 暂不论rwlock的r情况报告和并发写的行为不一致,至少也全部都是行得通的。 什么都有有遇到了第3个例子,大家发现rwlock的rw3个 情况报告无法表达大家的锁需求了,到了第3个 例子,假使 能隐约我我觉得,你是什么 锁,还得有层级形态学 。

1. 可能性锁请求与该锁目前的grantModes冲突,则进入等待英文,你是什么 点毫无问题报告 。

对3个 节点加IX/X锁时,能够 先(递归)获取其父节点的IX锁。

死锁检测的构图

举个例子:MongoDB中的资源层级形态学 如下:

对3个 节点加IS/S锁时,能够 先(递归)获取其父节点的IS锁。

MongoDB中的意向锁的定义

此时,可能性执行对Db2的drop操作,则能够 获得Db2的X锁,可能性Db2 目前所处IS锁情况报告,且IS锁与X锁互斥,其他锁无法立即获得。

为了处理你是什么 问题报告 ,MongoDB中为加锁操作增加了compatibleFirst参数。

970行检查node不是为初始入队元素。根据BFS的性质判断不是成环。

其整体形态学 如下图所示:

MongoDB中,3个 锁依赖图 G=(V, E), Vi = (Request, Resource, Mode), 即图中的3个 点的含义为对某个资源的有一种模式的锁请求,3个 点Vi对什么都有有点Vj有依赖 当且仅当 Vj 持有 Vi.Resource的锁,且锁模式与Vi.Mode冲突,且Vj 有一种也等待英文英文其他资源。概念有点绕,举个例子。

为了处理你是什么 问题报告 ,MongoDB为GrantList和ConflictList增加了引用计数数组。在将3个 对象增加到GrantList中时,顺带对grantedCounts[mode] 累加,可能性grantedCounts[mode]是从0到1的变化, 则将grantedModes对应的bitMask设置为1。 从GrantList中删除对象时,是3个 逆向的对称操作。什么都有有,在判断某个模式不是与GrantList中已有对象冲突时,可不可不可不可以够通过对grantedModes和待加节点的mode进行比较,将时间繁复度从O(n)降到O(1)。

LockHead

心智性成熟的句子的句子期图片 图片 期期 的数据库设计中,能够 3个 模块对资源的并发控制进行管理。意向锁什么都有有实现资源并发控制管理的经典法子。在讨论它的概念与设计前,大家先举2个MongoDB的经典场景。

02

Bucket

和grantedMode不冲突,但和conflictModes冲突,依然进入等待英文,你是什么 点处理了饿死。

3个 高并发读写的db中,IS/IX锁源源不断的添加来,且相互不冲突,在你是什么 条件下,如保处理X锁的饿死。

可能性写每个db的每张表,都能够 往oplog中写记录,其他oplog是全局的,大家希望在truncate oplog你是什么 全局操作在进行时,任何db对oplog的写操作都被阻塞。

BucketArray

3个 锁请求,可能性和GrantList无冲突,就将其添加到GrantList中,并加锁成功,其他就加到ConflictList中,并等待英文grantedModes变更时,从ConflictList中确定一批与grantedModes兼容的加锁请求进入GrantList。 这是很显然的调度策略。不过你是什么 调度策略无法处理3个 问题报告 ,可能性ConflictList包含X锁等待英文英文,而GrantedList中的IS/IX锁源源不断的进来,这样X锁就时不时得不到调度。

LockHead是对应于某个ResourceId的锁对象。LockHead维护着所有对该ResourceId的锁请求。LockHead由ConflictList和GrantList组成。ConflictList是该锁的等待英文队列, GrantList是持有锁的对象链表。

2. 207行可不可不可不可以够看后可能性请求与grantModes不冲突,什么都有有用说能加锁成功,能够 检验锁资源上的compatibleFirstCount, 该变量可不可不可不可以够解释为:锁资源的GrantList中compatibleFirst=true的属性的锁请求的元素的个数。可能性GrantList中无compatibleFirst的锁请求,且conflictList非空(有等待英文的锁请求),则将请求加入到conflictList中。

979行迭代ResourceId对于的Lock的GrantList,可能性某个GrantList中的元素全部都是依赖的Resource,则将其入队。

和grantedModes冲突,则进入等待英文。你是什么 点毫无问题报告 。

带着你是什么 个 问题报告 ,大家分析mongoDB 意向锁的实现。 整体形态学 mongoDB中的意向锁实现主要在 lockmanager.cpp/lockstate.cpp两累积。3个 繁复的意向锁的原语可不可不可不可以够用如下两条语录来表达。

上图中,意向锁划分为128个元素的BucketsArray, BucketsArray可不可不可不可以够无锁访问,3个 lock(ResourceId, LockMode)操作,首先通过Hash(ResourceId)%128 找到对于的bucket,你是什么 步无锁操作非常重要,充分利用了不同ResourceId的无关性,使得意向锁模块具备水平扩展性。

上述第二点,实则提供了等待英文优先级的概念。可能性所有锁请求的compatibleFirst都为false,则上述算法则可不可不可不可以够简述成如下更直接,更容易理解的防饿死控制: