Oracle RAC（Real Application Clusters）的监听体系是实现集群高可用、负载均衡和故障转移的核心组件，其设计逻辑围绕 “分布式节点协同 + 统一客户端接入” 展开。以下从核心原理、组件交互、注册机制、连接流程四个维度进行深度解析：
一、RAC 监听的核心设计目标
- 高可用性：单个节点监听故障时，客户端可自动切换到其他节点，不影响业务访问；
- 负载均衡：将客户端连接请求均匀分发到集群各节点，避免单点压力过载；
- 统一接入：通过 SCAN（Single Client Access Name）提供单一连接入口，屏蔽节点物理 IP 的复杂性；
- 故障透明：节点故障时，监听体系配合集群服务自动完成连接转移，客户端无感知。
二、RAC 监听的核心组件与角色
RAC 监听由 “本地监听 + SCAN 监听 + VIP 监听” 组成，三者协同实现完整的连接管理：
| 组件类型 | 核心角色 | 部署与绑定对象 | 依赖组件 |
|---|---|---|---|
| 本地监听（Local Listener） | 处理本节点的连接请求，与实例直接通信；接收 SCAN 监听转发的连接；实例注册的直接目标 | 每个节点独立部署，绑定节点物理 IP:1521 | 节点物理网卡、Oracle 实例 |
| SCAN 监听（SCAN Listener） | 提供集群统一接入入口；实现跨节点负载均衡；故障时自动漂移到健康节点 | 集群级部署（默认 3 个），绑定 SCAN VIP:1521 | GNS（网格命名服务）、SCAN VIP |
| VIP 监听（VIP Listener） | 本地监听的 “虚拟 IP 绑定”，避免物理 IP 故障导致的连接中断；配合 TAF 实现快速故障转移 | 每个节点部署，绑定节点 VIP:1521 | 节点 VIP、Clusterware |
关键组件补充说明
- SCAN（Single Client Access Name）：不是监听本身，而是 DNS 解析的虚拟主机名，对应 3 个 SCAN VIP（默认），实现 “一个域名访问全集群”；
- 节点 VIP（Virtual IP）：与节点物理 IP 绑定，由 Clusterware 管理，节点故障时 10 秒内漂移到其他节点，确保客户端连接不直接访问物理 IP；
- OCR（Oracle Cluster Registry）：存储 SCAN 监听、VIP 监听的配置信息和状态，Clusterware 通过 OCR 统一管理集群资源。
三、RAC 监听的注册机制（实例与监听的关联）
RAC 实例需将自身信息（服务名、实例名、端口等）注册到监听，才能被客户端发现。注册机制分为两种：
1. 动态注册（默认推荐，RAC 核心）
- 触发主体：实例的 PMON（进程监控）后台进程；
- 注册目标：同时注册到 “本地监听” 和 “SCAN 监听”；
- 注册内容：服务名（如 ORCLCDB）、实例名（如 ORCLCDB1）、服务状态（READY/LOADING）、最大连接数等；
- 刷新机制：PMON 每 60 秒自动刷新注册信息；实例启动 / 重启时主动注册；执行
ALTER SYSTEM REGISTER可手动触发注册； - 优势：无需手动配置
SID_LIST_LISTENER，实例故障时自动从监听中移除，高可用适配性强。
2. 静态注册（备用方案）
- 配置方式：手动编辑
$GRID_HOME/network/admin/listener.ora，添加SID_LIST_LISTENER段，指定实例信息； - 适用场景：动态注册失败时（如 PMON 进程异常）、需要对外提供固定 SID 访问时；
- 局限性：实例故障后，监听仍会保留注册信息，需手动刷新，不适合 RAC 高可用场景，仅作为应急方案。
注册优先级
动态注册优先级高于静态注册，当两者同时存在时，客户端连接优先使用动态注册的服务信息。
四、RAC 监听的连接流程（客户端→数据库）
以 “客户端通过 SCAN 地址连接” 为例，完整流程如下：
- DNS 解析：客户端输入 SCAN 地址（如scan-rac.example.com:1521/ORCLCDB），DNS 将 SCAN 域名解析为 3 个 SCAN VIP 中的一个；
- SCAN 监听接收请求：客户端连接解析后的 SCAN VIP 对应的 SCAN 监听，SCAN 监听查询自身注册的所有实例状态；
- 负载均衡决策：SCAN 监听根据实例的负载情况（连接数、CPU 使用率等），选择最优节点（如节点 2）；
- 连接转发：SCAN 监听将客户端连接转发到节点 2 的 “本地监听”（通过节点 2 的 VIP）；
- 本地监听建立会话：节点 2 的本地监听接收转发请求，与实例建立 TCP 连接，返回会话信息给客户端；
- 连接维护：客户端与实例直接通信，监听不再参与后续数据传输，仅负责新连接的接收和转发。
故障转移场景流程（节点故障时）
- 若节点 2 故障，Clusterware 立即将节点 2 的 VIP 漂移到节点 3；
- 节点 2 的本地监听和 SCAN 监听从 OCR 中标记为 “OFFLINE”；
- 客户端未完成的连接（配置 TAF 故障转移）会被自动转发到节点 3 的本地监听，无需客户端重启；
- 新的客户端连接通过 SCAN 解析时，SCAN 监听会过滤故障节点，仅将请求分发到健康节点。
五、RAC 监听与单实例监听的核心区别
| 对比维度 | Oracle RAC 监听 | 单实例监听 |
|---|---|---|
| 监听类型 | 本地监听 + SCAN 监听 + VIP 监听，多组件协同 | 仅本地监听，单组件独立工作 |
| 接入方式 | SCAN 地址统一接入，屏蔽节点 IP | 直接访问物理 IP，无统一入口 |
| 负载均衡 | 支持跨节点负载均衡（SCAN 监听实现） | 仅支持单节点内连接队列均衡 |
| 故障转移 | 监听漂移 + 连接转发，支持节点级故障转移 | 无故障转移能力，监听故障即服务中断 |
| 配置存储 | SCAN/VIP 监听配置存储在 OCR，集群统一管理 | 配置存储在本地 listener.ora，独立管理 |
| 注册目标 | 实例同时注册到本地监听和 SCAN 监听 | 实例仅注册到本地监听 |
六、RAC 监听的高可用保障机制
- SCAN 监听漂移：SCAN 监听由 Clusterware 管理，某个 SCAN 监听故障时，自动在其他节点重启，确保 3 个 SCAN 监听至少 2 个可用；
- VIP 漂移：节点故障时，节点 VIP 快速漂移到健康节点，客户端连接不直接依赖物理 IP，避免 “物理 IP 不可用导致的连接中断”；
- 监听状态监控：Clusterware 通过 OHASD（Oracle High Availability Services Daemon）监控监听进程，监听崩溃时自动重启；
- 服务自动切换：实例故障时，PMON 自动从监听中移除该实例的注册信息，SCAN 监听不再将新连接分发到故障实例。
七、核心总结
- RAC 监听的核心是 “分布式协同 + 统一接入”，通过 SCAN 监听实现负载均衡，通过 VIP 监听和漂移机制实现高可用；
- 动态注册是 RAC 监听的核心机制，确保实例与监听的实时同步，适配集群故障转移；
- 客户端连接 RAC 时，必须通过 SCAN 地址或节点 VIP，避免直接访问物理 IP，否则会丧失故障转移能力；
- 监听配置的关键是 “Clusterware 统一管理”，SCAN 监听和 VIP 监听的配置需存储在 OCR 中，而非仅依赖本地文件。
若需深入了解 “RAC 监听故障排查”“SCAN 监听端口修改”“动态注册优化” 等实操场景，可进一步补充需求。
