背景《SQL Server 2012實施與管理實戰指南》中指AlwaysON同步過程如下：任何一個SQL Server里都有個叫Log Writer的線程，當任何一個SQL用戶提交一個數據修改事務時，它會負責把記錄本次修改的日誌信息先記入一段記憶體中的日誌緩衝區，然後再寫入物理日誌文件（日誌固化）。所...
背景
《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環境，及簡單的測試語句，由於硬體環境，程式處理複雜度，數據量等等情況不同，結果也必不相同！！
