1. Always On高可用工程全景

SQL Server Always On 并不是一个单一功能，而是一组围绕“减少停机时间、保护数据不丢失、提升只读扩展能力”构建的高可用与灾难恢复技术集合。很多初学者会把 Always On 等同于“可用性组”，或者把“故障转移集群实例”当成它的升级版，这两种理解都会导致选型偏差。要真正掌握 Always On 工程，第一步是建立一张清晰的全景图：它由哪些组件构成、各组件解决什么问题、它们之间如何协作，以及在什么业务场景下应该选择哪一种形态。

一、Always On 技术体系的组成

Always On 的核心能力建立在 Windows Server 故障转移集群（WSFC）之上。WSFC 提供集群成员管理、仲裁、资源健康检测和故障转移协调，是 Always On 的“地基”。在此之上，SQL Server 提供两类高可用形态：

• Always On 故障转移集群实例（FCI）：以“实例”为保护单位，多个节点共享同一份数据存储（通常为共享磁盘、SAN 或 SMB 共享），同一时刻只有一个节点拥有该实例并对外提供服务。
• Always On 可用性组（AG）：以“数据库”为保护单位，每个副本节点各自维护一份独立的数据副本，通过日志传输与重做实现数据同步，支持自动或手动故障转移，并可将辅助副本用于只读查询。

此外，Always On 还包含“可用性组侦听器”这一关键访问入口。客户端连接侦听器的虚拟网络名称和端口，而不是直接连接某个物理节点，故障转移后由侦听器把连接导向新的主副本，从而避免应用端硬编码节点地址。理解“WSFC 提供集群协调、FCI 保护实例、AG 保护数据库、侦听器提供统一入口”这条主线，是后续所有工程实践的基础。

二、可用性组与故障转移集群实例的本质区别

两者最根本的差异在于保护粒度和存储模型。FCI 保护的是整个实例，实例下的所有数据库、登录名、作业、链接服务器等一起被保护；它依赖共享存储，因此故障转移时数据只有一份，不存在数据同步延迟问题，但共享存储本身成为潜在的单点。AG 保护的是数据库级别，每个副本有独立存储，通过日志传输保持同步，因此可以跨机房、跨地域部署，也支持把辅助副本用于只读分流，但需要关注同步延迟、日志发送队列和重做队列等指标。

从故障转移速度看，FCI 通常更快，因为不需要等待数据同步，实例在备用节点上直接挂载共享存储即可启动；AG 的故障转移需要辅助副本完成日志重做，若采用同步提交模式，主副本必须等待辅助副本确认日志写入才能提交事务，因此会带来一定的写入延迟。从扩展能力看，AG 明显更强：一个可用性组最多可包含多个辅助副本，其中部分可配置为可读辅助副本，用于报表、备份或读扩展；FCI 则无法提供只读分流能力。

三、典型业务场景与选型决策

选型不是“哪个技术更先进”，而是“哪个技术更匹配业务约束”。以下三类场景具有代表性：

• 场景一：同机房内要求实例级快速切换。例如一套老 ERP 系统，应用连接串写死了实例名，无法改造为侦听器模式，且所有数据库必须一起切换。此时 FCI 更合适，因为它保护整个实例，切换后实例名不变，应用无需改动。
• 场景二：核心交易库需要异地容灾，同时希望报表查询不占用主库资源。此时 AG 更合适。可以把主副本放在生产机房，一个同步提交辅助副本放在同城灾备机房保证 RPO 接近零，另一个异步提交辅助副本放在异地用于报表只读查询。
• 场景三：多个数据库分属不同业务线，需要按库独立切换。AG 允许把不同数据库放入不同可用性组，各自独立故障转移，互不影响；FCI 无法做到这一点。

四、选型决策的关键判断点

面对具体项目时，可以按以下顺序快速判断：第一，应用能否使用侦听器或连接字符串是否可改？如果完全不能改且必须保持实例名不变，优先考虑 FCI。第二，恢复目标要求是什么？如果要求 RPO 接近零且需要异地容灾，AG 的同步提交加异步提交组合更合适。第三，是否需要只读分流？如果需要把报表、备份卸载到辅助节点，只有 AG 能满足。第四，共享存储是否可用且距离可控？如果无法提供满足延迟要求的共享存储，FCI 方案不可行。第五，数据库是否必须整体切换？如果多个数据库需要独立切换，AG 的按库保护粒度更灵活。

需要特别强调的是，Always On 的高可用能力并不等于“永不宕机”。它解决的是计划内维护和单点故障导致的停机，对于人为误操作、逻辑数据损坏、存储静默错误等问题，仍需配合备份、DBCC 校验和延迟副本等策略。把 Always On 放进整体数据保护体系中理解，才能避免“上了 AG 就万无一失”的误区。