服务器RAC（Real Application Cluster，真实应用集群）是Oracle公司推出的一种高可用数据库集群技术，旨在通过多台服务器协同工作，构建一个共享存储、逻辑单一的数据库环境，从而实现数据库服务的高可用性、可扩展性和负载均衡，传统单机数据库架构中，若服务器硬件或软件发生故障，整个数据库服务将中断，而RAC通过冗余节点和集群管理机制，能够有效避免单点故障，确保业务连续性，广泛应用于金融、电信、电商等对数据可靠性要求极高的领域。
RAC架构与核心组件
RAC的核心在于“共享存储+多节点协同”，其架构主要由节点服务器、共享存储、集群件和数据库实例四部分组成，各组件通过紧密协作实现集群的高效运行。
节点服务器
节点是RAC集群的基本单元，通常由2台或更多台配置相同（或相近）的服务器组成，每个节点运行独立的操作系统和数据库实例，但所有节点共享同一套数据文件，节点间通过高速私有网络（如10GbE InfiniBand或专用以太网）进行通信，确保缓存同步和心跳检测的低延迟。
共享存储
共享存储是RAC的关键基础设施，所有节点通过存储区域网络（SAN）、网络附加存储（NAS）或Oracle ASM（自动存储管理）访问同一套数据文件、控制文件和重做日志，常见的共享存储技术包括光纤通道阵列、iSCSI或ASM的ASM Disk Group，其核心要求是支持多节点并发读写，并具备高I/O性能和数据一致性保障。
集群件（Clusterware）
集群件是RAC的“神经中枢”，负责管理集群节点的状态、资源分配和故障转移，主要包括以下组件：
- OCR（Cluster Registry，集群注册表）：以二进制格式存储集群的配置信息（如节点名称、实例名、网络参数等），通常部署在共享存储的多块磁盘上，实现冗余容错。
- Voting Disk（投票磁盘）：用于节点间的“心跳检测”，在集群出现分区时，通过投票机制决定哪些节点继续提供服务（通常遵循“多数派原则”），避免“脑裂”问题。
- Cluster Synchronization Services（CSS，集群同步服务）：管理节点间的通信和时钟同步，确保集群状态的一致性。
数据库实例
每个节点运行一个独立的数据库实例（包括SGA、后台进程等），但所有实例共同访问同一套物理数据文件，通过Oracle的Cache Fusion技术，实例间可以直接共享内存中的数据块，避免磁盘I/O，提升整体性能。
以下是RAC核心组件的功能总结表：
| 组件名称 | 功能描述 | 关键技术点 |
|---|---|---|
| 集群件（Clusterware） | 管理集群节点状态、资源配置，实现故障检测与转移 | OCR冗余、Voting Disk心跳机制 |
| 共享存储 | 存储数据文件、控制文件、重做日志，供所有节点并发访问 | 多路径冗余、ASM存储管理 |
| 节点服务器 | 运行独立数据库实例，通过私有网络协同工作 | 配置一致性、私有网络低延迟 |
| 数据库实例 | 每节点一个实例，通过Cache Fusion共享内存数据块，减少磁盘I/O | SGA全局缓存、全局队列管理 |
RAC的核心优势
RAC之所以成为企业级高可用数据库的首选，源于其在多个维度的显著优势：
高可用性（High Availability）
通过多节点冗余和故障自动转移（Failover），RAC能够消除单点故障，当某个节点发生硬件故障（如CPU、内存损坏）或软件崩溃时，其上的数据库实例会自动重启，客户端连接通过TAF（Transparent Application Failover）技术无缝切换至其他健康节点，业务中断时间通常控制在秒级甚至毫秒级，满足核心业务“7×24小时”不中断的需求。
可扩展性（Scalability）
RAC支持横向扩展（Scale-Out），通过增加节点线性提升数据库性能和处理能力，在电商大促期间，可临时增加节点应对流量高峰；活动结束后，再缩减节点以节约成本，这种“弹性扩展”能力相比纵向扩展（Scale-Up，升级单机硬件）更具灵活性和性价比。
负载均衡（Load Balancing）
RAC提供客户端和服务器端的负载均衡：客户端可通过Oracle Net Services或VIP（Virtual IP）将请求分发至负载较轻的节点；服务器端通过Cache Fusion动态调整数据块在实例间的分布，避免单个节点I/O或CPU过载。
灾难恢复（Disaster Recovery）
结合Oracle Data Guard或GoldenGate，RAC可实现跨数据中心的容灾，当主数据中心故障时，备数据中心可快速接管服务，RPO（恢复点目标）接近0，RTO（恢复时间目标）控制在分钟级，满足企业级灾难恢复要求。
典型应用场景
RAC的高性能和高可靠性使其成为对数据一致性、服务连续性要求严苛的核心业务系统的首选：
- 金融核心系统：如银行交易系统、证券清算系统，需确保每笔交易数据不丢失、服务不中断，RAC的故障自动转移和数据冗余特性可有效满足监管要求。
- 电信计费系统：面对海量用户的实时计费和话单处理，RAC的多节点负载均衡和高并发处理能力可支撑峰值流量，同时保障计费数据的准确性。
- 大型电商平台：在“双十一”等促销活动中，订单量、访问量激增，RAC的弹性扩展能力可快速增加节点，应对瞬时高并发，避免系统崩溃。
- 企业级ERP/CRM系统：如SAP、Oracle EBS等系统，数据集中管理且需支持多地域用户访问，RAC的高可用性和负载均衡可保障系统稳定运行。
部署关键注意事项
尽管RAC优势显著，但部署和运维需严格遵循规范，否则可能引发集群不稳定：
- 硬件选型：节点服务器配置应尽量一致（避免CPU、内存差异过大导致负载不均），存储需选择支持多路径冗余的高性能阵列，网络需划分公共网络（客户端访问）、私有网络（节点间通信）和心跳网络（故障检测），避免流量冲突。
- 存储规划：共享存储的LUN配置需考虑IOPS和吞吐量要求，OCR和Voting Disk建议部署在不同物理磁盘上实现冗余，ASM Disk Group可根据数据重要性选择外部冗余（External Redundancy）或正常冗余（Normal Redundancy）。
- 集群软件安装：需确保操作系统版本、Clusterware版本、数据库版本兼容，安装前关闭防火墙或配置正确的端口策略（如CSS的3138端口、VIP的VIP地址漂移）。
- 性能优化：通过AWR（Automatic Workload Repository）报告监控节点间Cache Fusion流量，避免 excessive interconnect traffic；合理配置SGA大小，减少内存争用。
FAQs
问题1：RAC如何实现故障自动转移？具体流程是怎样的？
解答：RAC的故障自动转移依赖集群件（Clusterware）和实例的协同机制，当某个节点发生故障（如宕机、网络中断）时，Clusterware的CSS模块会通过Voting Disk检测到节点心跳丢失，剩余节点通过OCR重新协商集群状态，遵循“多数派原则”（即存活节点数≥总节点数/2）决定是否继续提供服务，若故障节点上的数据库实例未正常关闭，Clusterware会在其他节点自动重启该实例（通过SRVCTL命令），客户端通过TAF技术自动切换至健康节点的VIP，实现连接透明恢复，整个过程通常在30秒内完成，对业务影响极小。
问题2：部署RAC时，共享存储网络选择有哪些注意事项？
解答：共享存储网络是RAC性能和稳定性的关键，需重点关注三点：一是低延迟和高带宽，推荐使用光纤通道（16Gbps以上）或InfiniBand（40Gbps以上），避免使用普通以太网（延迟过高）；二是多路径冗余，需配置多路径软件（如Linux的Multipath、Solaris的MPxIO），确保单条链路故障时自动切换，避免存储访问中断；三是隔离性，存储网络应与公共网络、私有网络分离，避免网络拥塞影响I/O性能，存储LUN的配置需支持“多设备共享”（如ALUA模式）,确保所有节点可并发访问同一LUN。
原创文章，发布者：酷番叔，转转请注明出处：https://cloud.kd.cn/ask/46680.html
