新一代讀寫分離技術——AlwaysOn
早在SQL Server 2005的時候微軟就已經實現了數據庫的查詢分離技術——發布訂閱。但生產庫和查詢庫的同步性能較差，時常出現性能問題，因此在大型生產環境中一直被人所詬病。
從SQL Server 2012開始，微軟逐漸使用AlwaysON技術來取代發布訂閱。AlwaysOn 作為SQL Server 2012引入的一種新的技術架構，性能相比發布訂閱而言提升很多，最明顯的區別在於其充分利用內存高效讀取的原理來實現日志的傳遞。下文將通過AlwaysOn的同步原理和可用模式來詳細了解AlwaysOn的同步優勢。
AlwaysOn同步原理
AlwaysON是一種整庫同步的技術，所有的成員服務器都維護一套相同的數據庫副本。當主副本上的數據發生變化時，數據會實時同步到輔助副本上。這點與數據庫鏡像非常類似。
下圖詳細描述了AlwaysON數據同步的整個過程，我們先來看看每個步驟所代表的意義。
① 主副本的logwiter把事務修改的日志信息先記入一段內存中的日志緩沖區，然后再寫入物理日志文件（日志固化）；
② 主副本的logscanner從緩存中或者日志文件中讀取日志塊，然后把它發送給AlwaysON的日志塊解碼器；
備注：解碼器會搜索日志中那些需要特別處理的操作，比如file stream操作、文件增長等。
③ 主副本將日志塊通過網絡傳送給輔助副本；
④ 和⑤
輔助副本接受到日志塊后，logwiter把事務修改的日志信息先記入一段內存中的日志緩沖區，然后再寫入物理日志文件（日志固化），另外，如果輔助副本處於同步可用模式時，在日志固化后，還必須反饋信息給主副本，主副本在接受到輔助副本完成固化的消息后才可以提交該事務，如果輔助副本在異步可用模式或者主副本在異步模式下，主副本提交事務與否跟輔助副本是否完成日志固化沒有關系，下文在介紹可用模式時會詳細介紹；
⑤ 重做（Redo）線程將日志中記錄的事務在輔助副本上重新演繹。重做線程每隔固定的時間點，會跟主副本通信，告知它自己的工作進度。主副本就能夠知道兩邊數據的差距有多遠。
AlwaysOn VS 發布訂閱
我們知道，事務日志發布訂閱通常不會用於整個數據庫的同步，而同步發布庫中的部分對象，而AlwaysON卻是整個數據庫都要同步，從數據量的角度來說，AlwaysON要同步的數據要更多，那為什么其性能還更好呢？
我們從如下兩個個方面的對比來尋找答案吧：
1. 同步對象
發布訂閱的同步對象是已經寫入到磁盤的事務日志，但不是所有的事務日志都發布，只有那些被標記為待發布的日志才會被發布，因此它不僅需要讀磁盤，而且對於某個事務，掃描所有日志才能篩選到標記為待發布的日志，如果這個事務的日志非常多而待發布的日志非常少，則日志讀取器的效率將非常低；
而AlwaysON同步的對象絕大部分位於內存的日志緩沖中，日志掃描器不需要讀取磁盤或者只需讀取少量磁盤，且AlwaysON是整庫同步，只要是主副本產生的日志都會同步到輔助副本，不需要進行日志篩選，因此不僅讀取速度快，而且效率還很高。
備注：AlwaysON同步的日志要比事務日志發布訂閱的要多，但從網絡角度來看不一定占用網絡帶寬也會更多，因為在AlwaysON中，網絡上傳遞的是壓縮了的日志，而發布訂閱則沒有做壓縮的優化。
2. 同步過程
在發布訂閱中，日志無法直接從發布庫到訂閱庫，期間必須通過分發庫中轉，每個過程都會產生大量的磁盤IO和網絡消耗；
而AlwaysON是點到點的數據同步，日志從主副本直接發送到輔助副本，中間不需要中轉，傳輸過程簡單高效。
AlwaysOn的可用性模式
上文在介紹AlwaysON同步原理時，我們考慮地比較簡單，只考慮了日志的同步情況。
如果要結合事務來整體考慮，AlwaysON的同步——更准確地說是可用模式，應該分為異步提交模式和同步提交模式。
可用性模式是AlwaysON中每個可用性副本的一個屬性，它決定了主副本在提交事務之前是否需要等待某個輔助副本將事務日志記錄固化到磁盤，如果需要等待，則該AlwaysON的可用模式為“同步提交模式，反之，則是“異步提交模式”。
異步提交模式
使用此可用性模式的可用性副本稱為"異步提交副本"。
當輔助副本處於異步提交模式下或者盡管輔助副本在同步提交模式下，但此時主副本在異步提交模式時，主副本無須確認該輔助副本是否已經完成日志固化，就可以提交事務。因此，主數據庫事務提交不會受到輔助數據庫的影響而產生等待。但是，輔助數據庫的更新可能會滯后於主數據庫，如果發生故障轉移，可能會導致某些數據丟失。因此這種可用模式適合於可用性副本的分布距離較遠的情況。
同步提交模式
使用此可用性模式的可用性副本稱為"同步提交副本"。同步提交模式要求主副本和輔助副本必須設置成同步提交副本。
在同步提交模式中，主副本必須確認輔助副本已經完成日志固化才可以提交事務（不需要等待輔助副本完成日志重做），這樣就保證兩邊的數據始終是同步的。但是這種保障的代價是主數據庫上的事務提交會有滯后時間。可以說，同步提交模式相對於性能而言更強調高可用性。
附上我的新浪微博二維碼，期待跟大家暢游SQL Server的世界。
