背景
《SQL Server 2012實施與管理實戰指南》中指AlwaysON同步過程如下：
任何一個SQL Server里都有個叫Log Writer的線程，當任何一個SQL用戶提交一個數據修改事務時，
它會負責把記錄本次修改的日志信息先記入一段內存中的日志緩沖區，然后再寫入物理日志文件（日志固化）。
所以對於任何一個數據庫，日志文件里都會有所有數據變化的記錄。
對於配置為AlwaysOn主副本的數據庫，SQL Server會為它建立一個叫Log Scanner的工作線程。
這個線程專門負責將日志記錄從日志緩沖區或者日志文件里中讀出，打包成日志塊，發送給各個輔助副本。
由於它的不間斷工作，才使主副本上的數據變化，可以不斷地向輔助副本上傳播。
在輔助副本上，同樣會有兩個線程，完成相應的數據更新動作，它們是固化（Harden）和重做（Redo）。
固化線程會將主副本Log Scanner所發過來的日志塊寫入輔助副本的磁盤上的日志文件里（這個過程被稱為"固化"）。
而重做線程，則負責從磁盤上讀取日志塊，將日志記錄翻譯成數據修改操作，在輔助副本的數據庫上完成。
當重做線程完成其工作以后，輔助副本上的數據庫就會跟主副本一致了。AlwaysOn就是通過這種機制，保持副本之間的同步。
重做線程每隔固定的時間點，會跟主副本通信，告知它自己的工作進度。主副本就能夠知道兩邊數據的差距有多遠。
這些線程在工作上各自獨立，以達到更高的效率。Log Scanner負責傳送日志塊，而無須等待Log Writer完成日志固化；輔助副本完成日志固化以后就會發送消息到主副本，告知數據已經傳遞完畢，而無須等待重做完成。其設計目標，是盡可能地減少AlwaysOn所帶來的額外操作對正常數據庫操作的性能影響。
這個同步並不是數據的實時同步，當主副本數據發生變化時，同步模式下的輔助副本並不能立即取到變化的數據。哈哈 這個是不是很坑？據我所知有大型的軟件產品因為這個陷阱吃了大虧！！
那么微軟為什么不作成真正的實時同步呢？比如世面上的moebius集群，還能自動作負載均衡這多霸氣？ 我想微軟還是從很多嚴謹性方面考慮吧，這里就不過多的廢話了，下面進入這個同時間差到底有多大呢？
-------------------------------------------轉載請注明出處 ----------http://www.cnblogs.com/double-K/p/5131563.html--------------------------------
測試環境
SELECT @@VERSION 結果：
Microsoft SQL Server 2014 - 12.0.4100.1 (X64)
Apr 20 2015 17:29:27
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)
系統server 2012 、sql 2014
3節點AlwaysOn 拓撲圖：
| 實例名 |
IP |
節點屬性 |
| VPC2012_1 |
192.168.2.55 |
主節點 |
| VPC2012_2 |
192.168.2.56 |
同步輔助節點 |
| VPC2012_3 |
192.168.2.57 |
異步輔助節點 |
工具准備
自開發測試程序、系統性能監視器、AlwaysOn監視器，系統性能計數器。
自開發程序介紹：
連接主副本和其中一個輔助副本，在設定的時間內循環 在主副本執行insert 操作，並根據設置的時間間隔，在輔助節點查詢所插入的數據，如果查詢到數據則成功，否則失敗。
並發數：模擬並發壓力，啟動線程數。
等待時間：查詢數據后查詢等待的時間。
執行時間：模擬場景運行的時間。
系統性能監視器
通過系統性能監視器察看是否執行過程用有內存、磁盤隊列、CPU壓力。
性能計數器：
主要收集3個節點以下計數器觀察AlwaysOn 同步狀態
batch requests/sec 主要用於檢查系統處理能力是否到達極限。
avg.disk read queue lenth 主要用於檢查是否由於IO瓶頸導致時間延遲。
avg.disk write queue lenth 主要用於檢查是否由於IO瓶頸導致時間延遲。
SQLServer：Database Replica 主要用於檢查是否由於AlwaysOn同步異常導致時間延長。
測試展示
- AlwaysOn壓力測試工具
a) 測試以50並發 等待200毫秒開始，逐步增加等待時間查看並發數下的等待時間，當失敗數為0時，增加並發數，測試等待時間下最大支持的並發數。
測試1同步節點
經過增加等待時間到1000毫秒 幾次執行失敗數均為0
增大並發測試 500並發左右1000毫秒出現失敗情況
縮短等待時間錯誤數量大量增加
異步節點測試：
異步節點在節點無任何查詢壓力下等待時間大約為1200毫秒
系統指標
性能監控器監控期間CPU、內存、IO隊列 未出現明顯壓力。
性能計數器
AlwaysOn儀表盤監測
-------------------------------------------轉載請注明出處 ----------http://www.cnblogs.com/double-K/p/5131563.html--------------------------------
結果
並發測試 500並發內AlwayOn 需要1000毫秒左右才能完成數據可讀，異步節點在節點無任何查詢壓力下等待時間大約為1200毫秒。
本例中的測試結果只是為了演示說明AlwaysOn同步節點數據可讀時間的差異，而不是提供准確時間。
本例結果均針對本機AlwaysOn環境，及簡單的測試語句，由於硬件環境，程序處理復雜度，數據量等等情況不同，結果也必不相同！！