RAC的并发操作与分布式锁DLM

1、RAC并发

RAC的本质是一个数据库，只不过现在这个数据库运行在了多台计算机上，在原先的单实例中，一个进程是否可以修改一条数据，取决于是否有其他进程（同一台计算机上）并发修改。在RAC环境下，这种判断已经不够了，还必须坚持其他计算机上的进程是否有并发修改。

于是RAC要解决的第一个问题就是：如何在多台计算机环境下感知并发的存在？

对于检查本机上的并发，用传统的单实例中的锁机制就可以解决，单对于其他计算机上的并发检测，必须引入一个新的机制，这个机制就是分布式锁管理器（distributed lock management DLM），我们可以把DLM想象成一个“仲裁”，他记录着哪个节点正在用哪种方式操作哪个数据，比负责协调解决节点间的竞争。

下面我们用一个例子来说明DLM的机制原理：

一个2节点的RAC，节点1想要修改数据A，节点1想DLM请求，DLM发现数据A还没有被任何节点使用，DLM就授权给节点1，并向DLM登记节点1对数据1的使用，这时，节点2也想修改数据A，节点2向DLM请求，DLM发现数据A正被节点1使用，DLM就会请求节点1，“先给节点2用吧”，节点1收到请求后释放其对数据1的占用，节点2能够操作数据A。DLM记录这个过程。

需要强调的是DLM负责的是节点间的协调，而节点内的协调不是DLM的责任，我们继续考虑上面的例子：

这时，节点2的进程1在修改数据A，节点2的进程2也想修改数据A，节点2仍然请求DLM，但是DLM发现节点2已经有权限，无序授权。进程2对DLM的请求被通过，但是进程2是否能够修改数据A，还需要进一步通过传统的锁模式检查。

解决了第一个问题后，第二个问题就出现了，我们上文提到的数据A到底是啥呢？或者说DLM到底在那个层次上对资源的冲突进行协调？那个A是一行记录？还是一个数据块？还是一个数据文件？哈哈——答案是：数据块！！！

也就是说，进程想要修改A时，向DLM提出申请的是“数据块A的操作权限”。

oracle集群发展历史分为两个阶段，最初的是oracle并行服务器（oracle parallel server OPS），之后到9i时改成RAC，两个阶段的DLM名称也不同，ops的叫做pcm，RAC的叫做Cache Fusion。现在看来我们只需知道一点：现在DLM的名称叫Cache Fusion。

在DLM中，根据资源数量，活动密集程度，把资源分成两类：cache fusion 和 non-cache fusion。

cache fusion resource：是指数据块这种资源，包括普通数据块，索引数据块，段头块（segement header）， undo 数据块。

非数据块资源全部都归类为non-cache fusion resource ：包括数据文件，控制文件，数据字典视图，library cache，row cache等等。

2、 GRD（Global Resource Directory ）

可以把 GRD 看作一个内部数据库，这里记录的是每一个数据块在集群间分布图，它位于每一个实例的SGA 中，但是每个实例 SGA 中都是部分 GRD ，所有实例的GR 汇总在一起就是个完整的 GRD 。

RAC 会根据每个资源的名称从集群中选择一个节点作为它的 Master Node ，而其他节点叫作 Shadow Node。 Master Node 的 GRD 中记录了该资源在所有节点上的使用信息，而 Shadow Node 的 GRD 中只需要记录资源在该节点上的使用情况，这些信息实际就是PCM Lock信息。 PCM Lock 有 3个属性： Mode ，Role和 PI(Past Image)。下图显示了GRD内容结构：

3、PCM Lock

由上文我们知道了GRD中记录的是pcm lock信息，这种锁有3个属性：mode，role，PI。

下面我们挨个看看这三个属性是怎么个意思：

1）mode：这个属性用于描述锁的模式，其中有3种取值，如下所示：

2）role：每个数据块可以被多个节点修改，role这个属性是用来描述“脏数据块”在集群间的分布状况的，其中有local 和 global 两个取值，下面结合mode来解释各个role的含义：

对于local role，可能的mode 只会是S 和 X；如果mode是S ，代表这个内存数据块时和磁盘上的内容完全一致的；如果mode是X，则代表这个数据块在内存中做过修改，但是修改没有被写回磁盘，也就是“脏数据块”；对于拥有local role的实例而言，如果要把这个数据块写到磁盘，不需要联系GRD，由本实例完成即可。

如果拥有local role的X mode 的实例要给其他实例发送这个数据块，如果发送的是和磁盘一直的版本，也就是说接收方收到的也是磁盘一致的版本，那么本实例就仍然保持local role；如果发送的是和磁盘不一致的版本，那么角色就要转变成global，同时接收方的角色也是global，代表同时有多个实例拥有“脏数据块”版本。

如果是global role，可能的mode 是S,X,Null，global role 首先意味着有多个实例拥有和磁盘一致版本，这时如果想要把这个数据写到擦盘，必须联系GRD，由拥有数据块的current版本来完成写动作。

3）past Image：下面通过一个例子说明什么是past image，假设一个2节点的rac集群，某个数据块在磁盘上的scn=100：

好了下面我们开始。。。实例1要修改这个数据块，从磁盘读入SGA进行修改，修改后内存的scn=110。实例2也要修改该这个数据块，实例1就会通过cache fusion 把这个数据块传送给实例2，发送的是scn=110的版本，即current copy的数据块；这时实例1还会保留这个scn=110的数据块在sga中，但是不能在进行任何修改操作，这时实例1拥有的这个拷贝就是一个past image，其中scn=110；在实例1发送这个数据块之前，会把log buffer 的内容写到redo log中。接下来实例2修改这个数据块，修改后的scn=120；注意，此时磁盘上的版本仍然是scn=100；假设实例1现在因为日志切换，触发了检查点动作，因为实例1上的数据块是个脏数据块（但不是最脏的，哈哈，还有实例2上那个scn=120的版本最脏），所以要把这个数据块也同步到磁盘。实例1会找到GRD，发现实例2拥有这个数据块的current版本，GRD会通知实例2把这个数据块写入磁盘。实例2完成写入之后，会通知其他实例（所有拥有PI版本的实例）释放他们拥有的PI内存了。这时，实例1会在log buffer中记录一条BWR（block write record）记录，然后释放PI内存。

假设实例2没有完成写时就异常宕机了，这时会触发实例1上进行crash recovery（不同与单实例instance recovery）虽然修改动作都被记录在各个节点的联机日志中，但是因为实例1拥有最近的PI，所以只需要实例1的PI及实例2的联机日志就可以完成恢复。

所以，past image代表着这个实例的SGA中是否拥有和磁盘内容不一致的版本，以及版本顺序，并不是代表这个节点是否曾经修改过这个数据块，past image主要能够加速crash recovery的恢复过程。

下面通过读写实例介绍RAC的工作过程：

4、AST

到现在为止，想必各位已经知道了所谓的cache fusion资源（也就是数据块）是如何被传输工作的了，但是前面的讲述故意遗漏了一个细节还没有交代，就是这些请求在DLM中是如何管理的，主要是避免分散读者的注意力，现在把这部分内容补上。

DLM使用两个队列跟踪所有的lock 请求，并用两个ASTs（asynchronous traps）来完成请求的发送和响应，实际就是异步中断（interrupt）或者陷阱（trap）。下图显示的是资源和队列的关系，granted queue中记录的是所有已经获得的lock的进程，而convert queue记录时是所有等待lock的进程。

进程1和进程2拥有数据块S模式的锁，因此在granted queue 中有记录，假设现在进程2要获得X模式的锁，进程2必须先向DLM提出请求；请求提交给DLM后，DLM就要把进程2放在convert queue中。向拥有不兼容模式锁的进程1发送一个blocking ASTs，这是一个异步请求，所以DLM不必等待响应。当进程1接受到这个BAST之后，就会把这个lock降级为null模式，DLM把进程2的锁模式转换为x模式，如下图所示：

然后，DLM发送一个acquisition ASTn（AAST）给进程2，并把进程2放到Granted queue中，如下图所示，进程2就可以继续处理了：

5、RAC并发控制总结

在cache fusion中，每一个数据块都会被映射成一个cache fusion 资源，或者说是一个PCM资源，pcm资源实际是一个数据结构，资源的名称就是数据块的地址（dba）。每个数据请求动作是分步完成的。首先把数据块地址x转换成pcm资源名称，然后把这个pcm资源请求提交给DLM，DLM进行global lock的申请，释放活动，只有获得了pcm lock，才能继续下一步；也就是说第一步“实例要获得数据块的使用权”

除了获得数据块的使用权，还要考虑数据块状态。在单实例中，进程想要修改数据块，必须在数据块的当前版本（current copy）上进行修改，在RAC环境下也一样，如果实例要修改该数据块，必须获得这个数据块的当前版本拷贝，这就涉及一系列的问题：如何获得数据块的拷贝在集群节点间的分布图，如何知道哪个节点拥有的是当前的拷贝，如何完成传递过程，这一些问题的解决机制就是内存融合技术（cache fusion）。一旦实例获得了访问权限，并且也得到了正确的版本。然后进程就能访问资源了，进程间仍然使用传统的lock，latch，这一点和单实例没有区别。

RAC的并发操作与分布式锁DLM相关推荐

Zookeeper命令操作（初始Zookeeper、JavaAPI操作、分布式锁实现、模拟12306售票分布式锁、Zookeeper集群搭建、选举投票）
Zookeeper命令操作(初始Zookeeper.JavaAPI操作.分布式锁实现.模拟12306售票分布式锁.Zookeeper集群搭建.选举投票) 1.初始Zookeeper Zookeeper ...
java 下单锁_JAVA 高并发下单解决方案-分布式锁
背景:高并发情况下,商品出现超卖的情况. 最终目标:保证数据的最终一致性. Contrrler 层框架 : Spring MVC 第一次尝试:最初的时候,发现Spring MVC是一个单例多线程的Co ...
利用Redis解决重复数据时候的并发异常和分布式锁解决方案
最近公司里有一个并发业务.多个线程消费一个kafka数据流,这个kafka数据流里数据的某个字段有重复.需要根据这个字段来做下去重. 一开始的方案是利用Redis来实现,先查Redis如果没有的话则s ...
【漫画】分布式锁究竟可以多少并发？
程序员萌萌在浏览关于分布式锁的文章,突然下面的话引起了萌萌的注意: 在锁操作的客户端打日志获取锁: T13:31:51.230 redis name-lock:hsetnx E13:31:5 ...
分布式锁--Redis小试牛刀
参考文章: Redis分布式锁的正确实现方式分布式锁看这篇就够了在这两篇文章的指引下亲测 Redis分布式锁引言分布式系统一定会存在CAP权衡问题,所以才会出现分布式锁什么是CAP理论? 为 ...
一句话说清分布式锁，进程锁，线程锁
一句话说清分布式锁,进程锁,线程锁在分布式集群系统的开发中,线程锁往往并不能支持全部场景的使用,必须引入新的技术方案分布式锁. 线程锁,进程锁,分布式锁线程锁:大家都不陌生,主要用来给方法.代码块 ...
实战系列-分布式锁的Redis实现
导语本篇博客,博主使用本地的Docker 搭建了一套测试环境,用来手写一个属于自己的基于Redis分布式锁实现方案,通过自己实现来了解分布式锁的原理.并且对整个的构建过程做了分享,希望可以对大家 ...
正在等待缓存锁:无法获得锁_一句话说清分布式锁，进程锁，线程锁
推荐阅读 1. Java 性能优化:教你提高代码运行的效率 2. Java问题排查工具清单 3. 记住:永远不要在MySQL中使用UTF-8 4. Springboot启动原理解析在分布式集群系统的 ...
分布式锁-Redis解决方案和Redisson解决方案
文章目录 1:分布式锁的概念 1:概念 2:锁/分布式锁/事务区别 2:本文使用的案例场景 1:需求 2:controller层代码 3:锁控制层代码(使用synchronized 不成功) 4:调用 ...

RAC的并发操作与分布式锁DLM

RAC的并发操作与分布式锁DLM相关推荐

最新文章

热门文章