在 SQL Server 的 Always On 可用性组（AG） 中，主副本（Primary replica）和副本（Secondary replica）之间的同步模式分为 异步同步（Asynchronous commit） 和 同步同步（Synchronous commit） 两种模式。它们对数据一致性的影响及适用的应用场景有所不同。以下是详细的对比：
1. 同步同步模式（Synchronous commit）
- 定义：在同步同步模式下，主副本和副本之间的数据传输是同步的。即主副本在提交事务之前，必须等待至少一个副本确认已将该事务写入日志并持久化（即事务日志已被写入副本）。一旦副本确认，事务才会提交到主副本。
- 数据一致性：在这种模式下，主副本和副本之间的数据是一致的，因为在主副本提交事务之前，副本必须确认接收到数据并将其持久化。这意味着在发生故障切换时，新的主副本不会丢失任何数据。
- 延迟：由于需要等待副本确认，可能会出现事务提交延迟，尤其是在网络延迟较高或副本负载较大的情况下。虽然保证了数据一致性，但会牺牲一定的性能。
- 适用场景：
- 需要高数据一致性的场景，要求在主副本和副本之间确保同步性。
- 金融、银行等对数据一致性和完整性要求非常高的应用系统。
- 适用于灾难恢复环境，保证主副本故障时不会丢失数据。
- 适合低延迟网络环境。
2. 异步同步模式（Asynchronous commit）
- 定义：在异步同步模式下，主副本和副本之间的数据传输是异步的。即主副本在提交事务时并不等待副本确认，而是立即提交事务并返回成功。这意味着事务日志会先写入主副本，然后异步地传输到副本。
- 数据一致性：在这种模式下，主副本和副本之间的数据一致性不是绝对保证的。因为事务提交到主副本后，副本可能还未接收到数据。如果在事务传输到副本之前发生故障（如主副本宕机），那么有可能丢失尚未同步到副本的数据。
- 延迟：由于不需要等待副本的确认，事务的提交速度较快，系统性能更高，适合高负载、对性能要求较高的场景。
- 适用场景：
- 适用于对性能要求较高的场景，尤其是主副本和副本之间存在较大网络延迟时。
- 适合不能容忍显著性能下降但可以容忍少量数据丢失的应用场景。
- 适合某些业务对数据一致性要求不那么严格，容忍一定的数据丢失风险的系统。
- 适用于异地灾难恢复，尤其是跨区域的高延迟网络环境。
3. 数据一致性对比
- 同步同步模式（Synchronous commit）：数据一致性更强，主副本和副本的数据保持一致，保证在主副本故障时不会丢失任何事务数据。因此，这种模式适用于对数据一致性要求非常高的业务系统。
- 异步同步模式（Asynchronous commit）：副本的数据可能会滞后于主副本，因此可能会有数据丢失的风险，尤其是在发生故障时。这种模式适用于那些对数据一致性要求不那么严格的场景，但需要优化性能和可用性。
4. 故障转移（Failover）
- 同步同步模式：因为主副本和副本的事务是同步的，因此当发生故障转移时，新的主副本会立即接管工作，且不会丢失任何数据。这种模式适用于对故障转移要求高的业务系统，确保零数据丢失。
- 异步同步模式：如果主副本发生故障转移，可能会丢失尚未同步到副本的数据。虽然这种模式可以提高系统的可用性，但在发生故障转移时，可能会导致数据丢失，尤其是当副本滞后较多时。
5. 应用场景总结
| 模式 | 数据一致性 | 性能 | 故障转移 | 适用场景 |
|---|---|---|---|---|
| 同步同步（Synchronous commit） | 强一致性，保证无数据丢失 | 性能可能下降，延迟较高 | 快速故障转移，零数据丢失 | 需要高一致性、零数据丢失、低延迟网络环境，如金融、银行等关键业务 |
| 异步同步（Asynchronous commit） | 一致性较弱，可能丢失数据 | 高性能，低延迟 | 故障转移可能导致数据丢失 | 高性能要求的应用，尤其是跨区域、大网络延迟环境，灾难恢复，或容忍少量数据丢失的系统 |
6. 总结
- 同步同步 模式提供了 零数据丢失 的保证，但可能牺牲 性能 和 响应速度，适合对一致性要求极高的系统。
- 异步同步 模式提供了 较高的性能，但可能会导致 数据丢失，适合对一致性要求不那么严格，且需要高可用性和快速响应的应用场景。
在选择模式时，需要根据具体的业务需求权衡一致性、性能和容忍的风险。例如，对于金融和医疗行业，通常会选择同步同步模式，而对于全球范围内的大规模分布式应用，可能更多采用异步同步模式。
