3. Always On可用性组架构设计
可用性组（Availability Group，AG）的架构设计，本质上是在“数据安全”与“服务连续性”之间做取舍。这个取舍不是抽象概念，而是由四个可配置维度共同决定的：副本角色、可用性模式、故障转移模式、副本数量与读写路由。把这四项定清楚，AG 的行为就基本确定了；反之，如果只把副本加进去而不规划这四项，故障切换时很容易出现数据丢失、只读连接失败或应用连到错误节点等问题。
一、副本角色：主副本与辅助副本的职责边界
每个可用性组有且只有一个主副本（Primary Replica），它承载可读写的主数据库，接收所有事务写入，并把日志块发送给各辅助副本。辅助副本（Secondary Replica）维护数据库的同步副本，默认只读不可写。辅助副本又分为两类角色：
- 可读辅助副本：允许只读连接，可承担报表、查询卸载等读负载，需要配置只读路由。
- 仅同步辅助副本：不对外提供只读访问，只用于数据保护和故障转移，适合作为“数据保险”节点。
角色不是固定不变的。故障转移时，某个辅助副本会“升格”为主副本，原主副本降级为辅助副本。因此设计时要保证每个副本都具备成为主副本的能力，包括相同的数据库文件路径规划、登录名、作业、链接服务器等实例级对象。
二、可用性模式：同步与异步的取舍
可用性模式决定主副本是否等待辅助副本确认日志硬化后才提交事务：
- 同步提交：主副本等待同步辅助副本确认日志已写入，保证该辅助副本与主副本数据一致，可实现零数据丢失（RPO=0）。代价是提交延迟受副本间网络往返影响。
- 异步提交：主副本不等待确认，提交延迟低，但辅助副本可能落后，故障转移时可能丢失数据（RPO>0）。
一个可用性组内不同副本可以采用不同模式。典型做法是：同城两个副本用同步提交保证零丢失，异地灾备副本用异步提交控制延迟。需要注意，同步提交副本数量越多，主副本提交路径上的等待点越多，写入延迟越敏感。
三、故障转移模式：自动、手动与强制
故障转移模式决定“谁有权触发切换、切换是否自动”：
- 自动故障转移：仅同步提交副本可配置。主副本失联且满足健康条件时，WSFC 自动把某个同步辅助副本提升为主副本，实现无人值守切换。
- 手动故障转移：由 DBA 显式执行，适用于计划内维护、演练或异步副本切换。
- 强制故障转移：用于主副本不可用且无同步副本可用的紧急场景，可能丢数据，切换后需谨慎处理数据分歧。
自动故障转移通常只配置给一个同步辅助副本，避免“脑裂”式竞争。若配置多个自动故障转移副本，需明确优先级顺序。
四、副本数量与读写路由规划
副本数量不是越多越好。每个辅助副本都会消耗网络带宽、日志传输和存储资源。常见规划是：2 副本（1 主 1 同步辅助）满足基本高可用；3 副本（1 主 2 同步辅助）兼顾高可用与只读卸载；4 副本以上通常引入异步灾备节点。
读写路由的核心是只读路由列表。应用连接串使用 ApplicationIntent=ReadOnly 时，主副本根据路由列表把连接重定向到指定辅助副本。路由列表按优先级排列，可配置多个目标实现读负载分散。若目标副本不可用，连接会尝试下一个，全部失败则回退到主副本（取决于配置）。
-- 示例：为 AG1 配置只读路由（示例参数，非实测结果）
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON N'SQLNODE2' WITH
(SECONDARY_ROLE (READ_ONLY_ROUTING_URL = N'TCP://SQLNODE2.corp.local:1433'));
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON N'SQLNODE1' WITH
(PRIMARY_ROLE (READ_ONLY_ROUTING_LIST = (N'SQLNODE2', N'SQLNODE3')));下面这张图把本节四个维度整合成一张架构关系图，便于对照理解角色、模式、切换与路由之间的连接关系。
五、设计检查要点
把上述四项落到具体设计时，建议逐项确认：
- 每个副本是否都具备成为主副本的实例级条件（登录名、作业、路径、证书）。
- 同步副本数量是否控制在写入延迟可接受范围内，通常不超过 2 个同步辅助副本。
- 自动故障转移是否只配置给一个同步辅助副本，并明确其优先级。
- 只读路由列表是否按优先级排列，且目标副本确实配置了可读辅助角色。
- 异步灾备副本是否明确其 RPO 预期，并制定强制故障转移后的数据核对流程。
架构设计没有唯一正确答案，关键是让每个副本的角色、模式、切换方式和路由目标与业务对 RPO、RTO 和读负载的实际要求一致。设计完成后，应通过一次计划内手动故障转移验证路由和连接行为，确认应用在切换后仍能正确连接。