AlwaysON同步的原理及可用模式

新一代讀寫分離技術——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的可用模式爲「同步提交模式，反之，則是「異步提交模式」。

異步提交模式

使用此可用性模式的可用性副本稱爲"異步提交副本"。

當輔助副本處於異步提交模式下或者儘管輔助副本在同步提交模式下，但此時主副本在異步提交模式時，主副本無須確認該輔助副本是否已經完成日誌固化， 就能夠提交事務。所以，主數據庫事務提交不會受到輔助數據庫的影響而產生等待。可是，輔助數據庫的更新可能會滯後於主數據庫，若是發生故障轉移，可能會導 致某些數據丟失。所以這種可用模式適合於可用性副本的分佈距離較遠的狀況。

同步提交模式

使用此可用性模式的可用性副本稱爲"同步提交副本"。同步提交模式要求主副本和輔助副本必須設置成同步提交副本。

在同步提交模式中，主副本必須確認輔助副本已經完成日誌固化才能夠提交事務（不須要等待輔助副本完成日誌重作），這樣就保證兩邊的數據始終是同步的。可是這種保障的代價是主數據庫上的事務提交會有滯後時間。能夠說，同步提交模式相對於性能而言更強調高可用性。