為了降低主要複本負載，除了倉儲與報表作業讀取非同步認可的複本，最近計畫把線上交易查詢改道同步認可的複本，一種類讀寫分流。
開始測試網站，就在明細頁修改完資料(主要複本)回到清單頁重查資料時(次要同步複本)，顯示的還是舊資料?
寫一段單元測試來觀察，測試程式的流程:
- 1.更新主要複本內特定資料列的值。
- 2.迴圈查詢次要複本，直到查詢到與主要複本有相同的值。
SQL Server 版本:Microsoft SQL Server 2012 (SP1) - 11.0.3153.0 (X64) Enterprise Edition (64-bit)
驚! 0.1秒(153毫秒)，真的出現延遲!
驚!驚! 0.3秒(320毫秒)
延遲時間落在0.1-0.4秒間(默默記下RPO)
一直認為AlwaysOn也把同步複本處理在ACID的範圍內，但理所當然的"隔離(Isolation)"竟然沒發生，查看同步設定，次要複本確實是設定同步複本啊!
有圖有真相:
好!又是釐清觀念的時間了: AlwaysOn Data Synchronization Process流程
主要複本偵測Log的產生、傳送，次要同步複本接收、Log Flush到Disk，最後才redo回次要複本上的Data Page!
好用的AlwaysOn就少了次要複本維持ACID的步驟，讀寫分流就好像破了馬拉松PB才發現這場里程數不足。(低頭喪志)
回到MSDN上的AlwaysOn 可用性群組 (SQL Server)介紹
「同步認可模式」(Synchronous-Commit Mode)。這種可用性模式強調的是高可用性和資料保護而非效能，但是相對地增加了"交易延遲"。
TODO:
同步複本(Synchronous)和非同步複本(Asynchronous)延遲性的差別?
參考:
AlwaysOn Data Synchronization Process
