“同步送出可用性模式”是否確保副本之間的一致性？
如果參考 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 月）”標題數據延遲下的部分讀取（強調我的）。
在輔助副本上執行的報告工作負載會產生一些數據延遲，通常為幾秒到幾分鐘，具體取決於主要工作負載和網路延遲。即使您已將輔助副本配置為同步模式，也存在數據延遲。雖然同步副本確實有助於在理想條件下（即 RPO = 0）通過在向主節點發送 ACK 之前強化已送出事務的事務日誌記錄來確保不失去數據，但它並不能保證 REDO 執行緒次要副本上確實已將關聯的日誌記錄應用到數據庫頁面. 所以會有一些數據延遲。您可能想知道，當您將輔助副本配置為非同步模式時，是否更有可能出現這種數據延遲。這是一個更難回答的問題。如果主副本和輔助副本之間的網路無法跟上事務日誌流量（即，如果沒有足夠的頻寬），非同步副本可能會進一步落後，從而導致更高的數據延遲。在同步副本的情況下，網路頻寬不足不會導致輔助節點上的數據延遲更高，但會減慢主工作負載的事務響應時間和吞吐量。
如果您的報告工作負載不能容忍任何數據延遲，您必須在主副本上執行它。好消息是，通常大多數報告工作負載可以容忍一些數據延遲，因此可以安全地遷移到輔助副本。
雖然 Microsoft 文件的廣度並不矛盾，但我覺得它可以更加明確。“同步”並不意味著ACID首字母縮寫詞中使用的原子性和一致性。
SYNCHRONIZED 狀態僅確保寫入由輔助（寫入磁碟的日誌）硬化。它沒有說明它們正在被應用（數據已更改）。
我可以期望每次都從兩個副本返回一致的結果嗎？
是的。讀取始終是一致的。但請記住，在關係用語中，一致性 (ACID) 與分佈式 (CAP) 一致性具有不同的含義。您不能保證閱讀最新的一致狀態。特別是，不能保證您會閱讀自己送出的寫入。並且來自每個副本的讀取，雖然每個都是一致的，但可能不匹配。