“同步提交可用性模式”是否确保副本之间的一致性？

Question

如果您参考 MSDN 文档中的Synchronous-Commit Availability Mode，您可以阅读：

在同步提交可用性模式（synchronous-commit mode）下，从库加入可用性组后，会赶上对应的主库，进入SYNCHRONIZED状态。只要数据同步继续，辅助数据库就会保持同步。这保证了在给定主数据库上提交的每个事务也已在相应的辅助数据库上提交。当给定辅助副本上的每个辅助数据库同步时，整个辅助副本的同步健康状态为 HEALTHY。

假设我有一个三节点可用性组，其中有一个处于同步HEALTHY状态的数据库。所有副本都使用同步提交模式。

另外假设，我已经配置了只读路由，以便请求ApplicationIntent=Read-Only连接到辅助副本。

如果我通过读写连接提交更改，那么很快，使用ApplicationIntent=Read-Only连接通过另一个连接选择更改的记录，我是否可以期望每次都从两个副本返回一致的结果？

---

编辑 - 支持已接受答案的更多信息。

在 Microsoft 技术论文“AlwaysOn: Offloading Read-Only Workloads to Secondary Replicas（Sunil Agarwal，2012 年 7 月）”中，标题数据延迟下的部分读取（强调我的）。

在辅助副本上运行的报告工作负载会产生一些数据延迟，通常为几秒到几分钟，具体取决于主要工作负载和网络延迟。即使您已将辅助副本配置为同步模式，数据延迟仍然存在。虽然同步副本确实通过在向主服务器发送 ACK 之前强化已提交事务的事务日志记录来帮助保证在理想条件下（即 RPO = 0）不会丢失数据，但它并不能保证 REDO 线程在辅助副本上确实已将关联的日志记录应用到数据库页面. 所以有一些数据延迟。您可能想知道在异步模式下配置辅助副本时是否更可能出现这种数据延迟。这是一个更难回答的问题。如果主副本和次副本之间的网络无法跟上事务日志流量（即，如果没有足够的带宽），异步副本可能会进一步落后，从而导致更高的数据延迟。在同步副本的情况下，网络带宽不足不会导致次要数据延迟更高，但会减慢主要工作负载的事务响应时间和吞吐量。

如果您的报告工作负载不能容忍任何数据延迟，您必须在主副本上运行它。好消息是，通常大多数报告工作负载都可以容忍一些数据延迟，因此可以安全地迁移到辅助副本。

虽然 Microsoft 文档的广度并不矛盾，但我觉得它可以更明确。“同步”并不意味着ACID首字母缩写词中使用的原子性和一致性。

Answer 1

SYNCHRONIZED 状态仅确保写入由辅助节点（日志写入磁盘）强化。它没有说明它们被应用（数据改变）。

我可以期望每次都从两个副本返回一致的结果吗？

是的。读取始终是一致的。但请记住，在关系术语中，一致性 (ACID) 与分布式 (CAP) 一致性具有不同的含义。您不能保证读取最新的一致状态。特别是，您不能保证读取自己提交的写入。来自每个副本的读取，虽然每个都是一致的，但可能不匹配。