1 引言

本文将深入讨论达梦共享存储集群DSC和Oracle RAC集群最核心的技术内核——缓存一致性机制与全局并发控制。如果说集群控制服务是集群的“大脑”，存储管理是集群的“四肢”，那么本章所要讨论的缓存融合/交换与全局锁管理，就是集群的“心脏”与“神经系统”——它们直接决定了集群在多节点并发访问同一份数据时的性能与正确性。
无论是Oracle RAC还是达梦DSC，都面临着一个相同的根本挑战：多个数据库实例同时访问、修改同一套数据文件，如何保证数据的一致性？如何让一个节点修改的数据被其他节点即时感知？如何避免多个节点同时修改同一数据块造成的冲突？
Oracle用Cache Fusion（缓存融合） 回答了这些问题，达梦则用缓存交换（Buffer Swap） 给出了自己的答案。二者在核心理念上高度一致——利用高速网络替代磁盘I/O，在内存层面完成节点间的数据传递——但在实现细节、服务划分上存在显著差异。

2 技术实现原理对比

2.1 缓存融合技术 VS 缓存交换技术

2.1.1 Oracle RAC的Cache Fusion（缓存融合）

缓存融合是一种高级的集成缓存机制，它是Oracle RAC架构的核心。它允许一个数据库实例的缓冲区缓存（Buffer Cache）直接通过高速互连网络（如Infiniband）为另一个数据库实例的缓冲区缓存提供数据块，而无需首先将数据块写入磁盘。 这意味着集群中的所有实例的缓冲区缓存被有效地“融合”成一个逻辑上统一的、被所有实例共享的庞大缓存池。
在了解缓存融合技术的原理之前，需要先了解缓存融合的核心服务组件。

2.1.1.1 核心服务组件

全局缓存服务 (GCS - Global Cache Service)：
作用：缓存融合的“大脑”。它负责跟踪每个数据块在集群所有实例中的状态和位置（主节点/Master Node），并协调实例间的块传输请求。GCS维护着一个全局资源目录（GRD），记录着每个数据块的当前状态和锁信息。
全局队列服务 (GES - Global Queue Service)：
作用：管理全局入队（Enqueue）资源，如库缓存锁和字典缓存锁，确保这些逻辑结构在集群中也是一致的。
全局资源目录 (GRD - Global Resource Directory)：
作用：GCS和GES所使用的内存中心库，存储着所有共享资源（数据块、锁）的当前状态。GRD并不集中存储，而是分布式地存在于所有活动实例的内存中。每个资源都有一个主节点（Master Instance），由该节点负责管理该资源的所有锁请求。

2.1.1.2 工作流程示例

Oracle RAC是如何利用缓存融合处理数据同步的呢？我们通过一个三节点RAC集群（节点A、节点B、节点C） 的场景来逐步拆解其工作流程。在Cache Fusion机制中，每一个数据块都会被动态分配一个Master Instance（主实例）——也就是集群A、B、C三节点中的某一个。这个Master节点的GRD（全局资源目录）中完整记录着该数据块在所有节点上的使用状态（谁在读、谁在写、最新版本在谁的缓存里）。当任何节点想要访问该数据块时，都必须先向它的Master节点发起请求，由Master节点协调全局锁的分配，确保数据一致性。
每个数据块的Master节点可以不同，目的是均衡负载。例如数据块X的Master是节点A，数据块Y的Master是节点B，数据块Z的Master是节点C。当一个数据块被某个节点频繁访问时，Oracle还可能通过DRM（Dynamic Resource Remastering，动态资源重主控） 将其Master节点迁移到访问最频繁的节点上，以减少跨节点通信开销。
假设在本示例中，数据块Block X的Master节点是节点B，所有关于Block X的全局资源信息都由节点B的GRD管理。集群中的三个节点分别为节点A、节点B、节点C。

场景一：节点从磁盘读取一个新块
节点C想要读取Block X，但该块当前不在任何节点的缓存中。
请求锁：节点C的前台进程向Master节点B的LMS进程发送请求，希望获得Block X的共享锁。
Master节点授权：Master节点B查询GRD，发现Block X没有被任何节点锁定或缓存。于是，节点B的LMS进程授权给节点C一个共享锁（Shared-Local-noPI） 。
读取磁盘：节点C获得锁后，将Block X从共享磁盘读入自己的Buffer Cache。
更新目录：节点C向Master节点B发送消息，更新GRD，记录Block X现在由节点C以共享模式持有。

场景二：节点从另一个节点的缓存中读取块
接着场景一，节点A现在也想读取Block X。
请求锁：节点A的前台进程向Master节点B请求Block X的共享锁。
Master节点转发：Master节点B查询GRD，发现Block X当前以共享模式缓存在节点C中。于是，节点B的LMS进程将节点A的请求转发给节点C的LMS进程。
缓存融合传输：节点C的LMS进程通过高速私有网络，将Block X直接发送给节点A。同时，节点C保留该块的一个一致性读副本（CR Block） 。
更新目录：节点A向Master节点B发送消息，更新GRD，记录Block X现在由节点A和节点C共同以共享模式持有。

场景三：节点修改一个被共享的块
继续场景二，节点A现在想要修改Block X。
请求独占锁：节点A向Master节点B发送请求，希望获得Block X的独占锁。
Master节点协调：Master节点B查询GRD，发现Block X正被节点A和节点C以共享模式持有。为了满足独占锁请求，节点B向所有共享锁持有者（节点A和节点C）发送消息，要求它们释放锁——其中节点A既是请求者也是持有者，需要先降级自己的共享锁再升级为独占锁。
缓存融合传输与锁降级：节点C收到消息后，通过私有网络将Block X发送给节点A，然后释放自己的共享锁。节点A在收到来自节点C的数据后，完成锁升级，获得独占锁。
获取独占锁并修改：节点A获得Block X的独占锁，在本地修改数据块（此时Block X变为脏块，但尚未写盘），并更新GRD。

场景四：节点修改一个已被修改的块
继续场景三，节点C现在也想修改Block X。
请求独占锁：节点C向Master节点B请求Block X的独占锁。
Master节点协调与传输：Master节点B查询GRD，发现Block X正被节点A以独占模式持有。于是，节点B向节点A发送消息，要求其释放锁。
传递“脏块”与创建镜像：节点A通过私有网络将Block X（脏块）发送给节点C。关键步骤：在发送之前，节点A必须在内存中创建一个Block X的过去镜像（PI, Past Image） ，并确保所有更改的Redo日志已刷入磁盘。发送完成后，节点A的锁降级为空，但保留了PI副本。
获取锁并提交：节点C获得Block X的独占锁，进行修改并提交事务。

场景五：Master节点自身需要重新读取已被修改的块
继续场景四，节点C已经以独占模式修改了Block X，Block X在节点C的Buffer中是一个脏块（尚未写盘），尚未被写入共享存储。此时，Master节点B（也就是Block X的GRD归属节点）由于某些业务需求，需要重新读取Block X。
Master节点查询GRD：节点B作为Block X的Master节点，其GRD中完整记录了该块的当前状态——它知道Block X当前以独占模式（X模式） 被节点C持有，并且是一个脏块。
Master节点发起请求：节点B需要读取Block X，但它同样需要遵循Cache Fusion协议。节点B的LMS进程向节点C的LMS进程发起请求，要求获取Block X的共享锁，并传递数据。
节点C响应请求：节点C收到请求后，发现自己持有的是独占锁且数据已被修改。此时，节点C需要：
将Block X的数据块内容通过私有网络发送给节点B
在发送之前，节点C在本地Buffer中创建该块的过去镜像（PI, Past Image） 副本
确保该块修改所对应的Redo日志已刷入磁盘
将自己的锁模式从独占（X）降级为共享（S） ，因为现在有了第二个读者（节点B）
节点B接收并更新GRD：节点B收到数据后，将Block X读入自己的Buffer Cache，并在本地的GRD中更新状态——记录Block X现在由节点B和节点C共同以共享模式持有。由于节点B本身就是Master节点，这个更新可以直接完成，无需跨节点通信。
节点B完成读取：节点B获得Block X的一致读副本，可以正常访问该数据块。

2.1.2 达梦DSC的缓存交换（Buffer Swap）

根据目前的硬件发展状况来看，网络的传输速度比磁盘的读、写速度更快，因此，DMDSC 集群引入了缓存交换（Buffer Swap）技术，节点间的数据页尽可能通过网络传递，避免通过磁盘的写入、再读出方式在节点间传递数据，从而减少数据库的 IO 等待时间，提升系统的响应速度。
同样，在了解缓存交换技术之前，先了解一下缓存交换技术的核心服务组件。

2.1.2.1 核心服务组件

缓存交换的实现依赖于GBS（Global Buffer Services，全局缓存服务） 和LBS（Local Buffer Services，本地缓存服务）。在DMDSC集群中，每个节点上都部署了一个GBS和一个LBS。

GBS（全局缓存服务）
GBS也可以称为Global Latch Services（GLS）。它负责协调节点间的闩（Latch）请求和权限回收。闩（Latch）是数据库管理系统的一种内部数据结构，通常用来协调、管理数据缓冲区、字典缓存和数据库文件等资源的并发访问。与锁（Lock）在事务生命周期中一直保持不同，闩（Latch）通常只保持极短的一段时间，比如修改 Buffer 中数据页内容后，马上会释放。闩（Latch）的封锁类型也比较简单，就是共享（Share）和独占（Exclusive）两种类型。
与Oracle GCS不同，达梦的GBS采用分布式管理方式——它不是由一个中心节点统一管理，而是由集群中所有节点共同管理。Buffer中的数据页会根据数据页号（Page No）进行划分，从而分配给某一个节点的GBS进行处理。这意味着每个数据页都有一个“归属”的GBS节点，在功能上对标Oracle GRD中的Master节点。
GBS中维护着Buffer数据页的核心元数据信息：
闩的封锁权限（LATCH） ：控制数据页的并发访问权限，模式值包括0（N_LATCH/空）、1（X_LATCH/独占）、2（S_LATCH/共享）、4（F_LATCH/特殊）
访问映射（Access MAP） ：记录哪些节点访问过此数据页
最新数据位置（Fresh EP） ：标识最新版本数据保存在哪一个节点
数据页最新的LSN值（Fresh LSN） ：用于日志恢复和一致性判断

LBS（本地缓存服务）
LBS也可以称为Local Latch Services（LLS）。它负责根据用户请求向GBS发起latch请求，或者根据GBS的请求回收本地的latch。
LBS的工作可以理解为“本地代理”——每个节点的LBS代表本节点与GBS通信，申请对特定数据页的访问权限，并在获得授权后执行实际的读写操作。
GBS与LBS之间的协作信息（如锁模式、访问映射等）会作为请求的附加信息在节点间传递，不会带来额外的通讯开销。

2.1.2.2 工作流程示例

下面以两节点DMDSC集群（EP0、EP1）访问数据页P1为例，通过几种常见场景逐步解析缓存交换的工作原理。
在开始之前，先交代数据页P1的初始状态：
1、P1位于共享存储上，尚未被任何节点加载到Buffer中
2、P1的GBS控制结构位于节点EP1（即该数据页的归属管理节点是EP1）
3、P1的当前LSN为10000，表示该页未被修改过

场景一：节点EP0首次访问数据页P1
请求闩权限：节点EP0的本地LBS向EP1的GBS请求数据页P1的S LATCH（共享闩） 权限。
GBS授权：EP1的GBS修改P1的控制结构，记录访问节点EP0的封锁模式为S LATCH（数据分布节点标记为EP0），并向EP0的LBS返回授权响应。
读取磁盘：EP0的LBS获得GBS授权后，记录授权模式为S_LATCH。由于P1数据不在任何其他节点的Buffer中，EP0发起本地I/O请求，从共享磁盘读取P1数据。
更新本地信息：I/O完成后，EP0修改本地的LBS控制结构，记录数据页上的LSN信息。

场景二：节点EP1访问数据页P1
接场景一，此时P1的数据已缓存在EP0的Buffer中（以S LATCH模式持有），且GBS控制结构记录了数据分布节点为EP0。
当节点EP1需要访问P1时，缓存交换正式发挥作用：
请求闩权限：节点EP1的本地LBS向EP1的GBS（P1的控制归属节点）请求数据页P1的S LATCH（共享闩） 权限。
GBS授权：EP1的GBS修改P1的控制结构，记录访问节点EP1的封锁模式为S LATCH，数据分布节点更新为EP0/EP1（表示两个节点均缓存了该页），并向EP1的LBS返回授权响应。
缓存交换传输：EP1的LBS获得GBS授权后，记录授权模式为S_LATCH。此时，根据GBS中的访问映射（Access MAP） 信息，EP1发现P1的数据分布节点为EP0（即数据已在EP0的Buffer中）。于是，EP1不读取磁盘，而是直接通过内部网络（MAL链路）向EP0发起P1的读请求，从EP0的Buffer中获取数据页。
完成访问：EP1收到EP0传递过来的P1数据后，更新本地LBS控制结构，完成数据页的访问。

场景三：节点 EP0 修改数据页 P1。
接场景二，此时P1的数据已缓存在EP0和EP1两个节点的Buffer中，均以S LATCH模式持有。节点EP0现在需要修改P1。
当EP0需要修改P1时，它需要将持有的共享闩（S LATCH）升级为独占闩（X LATCH）。缓存交换的处理流程如下：
请求独占闩：节点EP0的本地LBS向EP1的GBS请求数据页P1的X LATCH（独占闩） 权限。
权限回收：EP1的GBS修改P1控制结构的LSN值，并从EP1的LBS回收P1的S LATCH权限。由于EP1当前持有S LATCH，与X LATCH不兼容，必须先回收EP1的权限。
GBS授权：EP1的GBS将EP0的锁模式修改为S+X LATCH（同时持有共享和独占权限），并向EP0的LBS返回授权响应。
完成修改：EP0的LBS获得GBS授权后，记录授权模式为S+X LATCH，即可在本地修改P1的数据。

场景四：节点 EP1 修改数据页 P1。
接场景三，此时P1已被EP0以S+X LATCH模式持有并完成修改，P1成为脏页，EP1的S LATCH权限已被回收。节点EP1现在也需要修改P1。
当EP1需要修改P1时，它需要向GBS申请X LATCH。缓存交换的处理流程如下：
请求独占闩：节点EP1的本地LBS向EP1的GBS（P1的控制归属节点）请求数据页P1的X LATCH（独占闩） 权限。
权限回收与脏页传递：EP1的GBS查询P1的控制结构，发现P1当前以X LATCH被EP0持有，且EP0已经修改了P1（产生了脏页，Fresh EP标记为EP0）。GBS向EP0的LBS发送请求，要求回收X LATCH权限并传递数据页。
传递脏页：EP0收到回收请求后，通过MAL链路将修改后的P1（脏页）传递给EP1。EP0在传递前需要确保修改对应的Redo日志已刷入磁盘。
GBS授权：EP1的GBS修改控制结构，将锁模式从EP0的X LATCH转移为EP1的X LATCH，并响应EP1的LBS请求。
完成修改：EP1的LBS获得授权后，即可在本地继续修改P1。

2.1.3 缓存融合与缓存交换技术对比

2.1.3.1 核心服务对比

Oracle的缓存融合由GCS（全局缓存服务） 和GES（全局队列服务） 两大服务组成。GCS负责跟踪每个数据块在集群中的状态和位置，协调实例间的数据块传递；GES负责管理全局入队资源，确保库缓存锁、字典缓存锁等逻辑结构在集群中的一致性。二者在GRD（全局资源目录）的基础上协同工作。
达梦的缓存交换由GBS（全局缓存服务） 和LBS（本地缓存服务） 实现，采用分布式管理方式——每个节点都部署了GBS和LBS。Buffer中的数据页根据页号划分，分配给某一节点的GBS进行处理。GBS维护着闩的封锁权限、访问映射、最新数据位置和LSN值等元数据信息；LBS负责向GBS发起请求或根据GBS指令回收本地的闩。
Oracle将GCS和GES分拆为两个独立的服务，各自由专门的LMS和LMD进程承载，服务职责划分更细。达梦采用GBS/LBS的统一框架，将类似功能整合在同一服务体系中，架构更为紧凑。

2.1.3.2 资源管理模式对比

Oracle的GRD分布式地存在于所有活动实例的内存中，每个数据块都有一个Master节点负责管理该资源的锁请求。当一个数据块被某个节点频繁访问时，Oracle可通过DRM（动态资源重主控）将其Master节点迁移到访问最频繁的节点上，实现资源的动态优化。
达梦的GBS同样采用分布式管理，数据页根据页号哈希分配给不同节点的GBS，每个数据页有明确的归属节点负责管理其闩权限和访问映射。归属关系基于页号固定分配，管理逻辑清晰，避免了动态迁移带来的额外开销。

2.1.3.3 数据传递与锁机制对比

Oracle Cache Fusion支持Null/Share/Exclusive三种资源模式，支持锁模式在不同场景下的转换。在传递脏块时，Oracle会在持有节点内存中创建过去镜像（PI, Past Image），并确保Redo日志刷盘。在共享读取场景下，持有节点保留一致性读副本（CR Block）供其他节点读取。
达梦缓存交换的闩模式包括N_LATCH/S_LATCH/X_LATCH/F_LATCH四种。在脏页传递时，达梦同样要求Redo日志刷盘以确保数据一致性。通过GBS中的访问映射（Access MAP），节点可以快速定位数据页的当前位置并直接从持有节点获取。

3 小结

缓存融合与缓存交换，分别是Oracle RAC与达梦DSC在缓存一致性层面的核心技术实现。
回顾全文，二者在核心理念上高度一致——利用高速网络替代磁盘I/O，在内存层面完成节点间的数据传递。Oracle Cache Fusion自Oracle 9i引入以来，通过GCS与GES的分工协作、GRD的分布式资源管理、PI镜像机制等设计，构建了一套成熟完备的缓存一致性体系。达梦Buffer Swap则通过GBS/LBS的统一服务框架、基于页号哈希的分布式归属管理、MAL链路的高速传输，实现了数据页在节点间的高效交换。
从技术实现来看，Oracle的Cache Fusion在服务划分上更加精细化——GCS与GES各司其职，GRD记录丰富的资源状态信息；达梦的Buffer Swap在架构设计上更追求整体性——GBS与LBS构成对称的服务框架，访问映射（Access MAP）、最新数据位置（Fresh EP）等元数据信息在GBS/LBS之间高效传递，无需额外的通讯开销。
总的来说二者都是实现共享存储集群的关键技术之一，确保共享存储集群的缓存一致性，并提高集群性能。
https://eco.dameng.com