早在sql server 2005的時候微軟就已經實現了資料庫的查詢分離技術——發布訂閱。但生產庫和查詢庫的同步效能較差，時常出現效能問題，因此在大型生產環境中一直被人所詬病。
從sql server 2012開始，微軟逐漸使用alwayson技術來取代發布訂閱。alwayson 作為sql server 2012引入的一種新的技術架構，效能相比發布訂閱而言提公升很多，最明顯的區別在於其充分利用記憶體高效讀取的原理來實現日誌的傳遞。下文將通過alwayson的同步原理和可用模式來詳細了解alwayson的同步優勢。
alwayson是一種整庫同步的技術，所有的成員伺服器都維護一套相同的資料庫副本。當主副本上的資料發生變化時，資料會實時同步到輔助副本上。這點與資料庫映象非常類似。
下圖詳細描述了alwayson資料同步的整個過程，我們先來看看每個步驟所代表的意義。
① 主副本的logwiter把事務修改的日誌資訊先記入一段記憶體中的日誌緩衝區，然後再寫入物理日誌檔案（日誌固化）；
② 主副本的logscanner從快取中或者日誌檔案中讀取日誌塊，然後把它傳送給alwayson的日誌塊解碼器；
備註：解碼器會搜尋日誌中那些需要特別處理的操作，比如file stream操作、檔案增長等。
③ 主副本將日誌塊通過網路傳送給輔助副本；
④ 和⑤
輔助副本接受到日誌塊後，logwiter把事務修改的日誌資訊先記入一段記憶體中的日誌緩衝區，然後再寫入物理日誌檔案（日誌固化），另外，如果輔助副本處於同步可用模式時，在日誌固化後，還必須反饋資訊給主副本，主副本在接受到輔助副本完成固化的訊息後才可以提交該事務，如果輔助副本在非同步可用模式或者主副本在非同步模式下，主副本提交事務與否跟輔助副本是否完成日誌固化沒有關係，下文在介紹可用模式時會詳細介紹；
⑤ 重做（redo）執行緒將日誌中記錄的事務在輔助副本上重新演繹。重做執行緒每隔固定的時間點，會跟主副本通訊，告知它自己的工作進度。主副本就能夠知道兩邊資料的差距有多遠。
我們知道，事務日誌發布訂閱通常不會用於整個資料庫的同步，而同步發布庫中的部分物件，而alwayson卻是整個資料庫都要同步，從資料量的角度來說，alwayson要同步的資料要更多，那為什麼其效能還更好呢？
我們從如下兩個個方面的對比來尋找答案吧：
發布訂閱的同步物件是已經寫入到磁碟的事務日誌，但不是所有的事務日誌都發布，只有那些被標記為待發布的日誌才會被發布，因此它不僅需要讀磁碟，而且對於某個事務，掃瞄所有日誌才能篩選到標記為待發布的日誌，如果這個事務的日誌非常多而待發布的日誌非常少，則日誌讀取器的效率將非常低；
而alwayson同步的物件絕大部分位於記憶體的日誌緩衝中，日誌掃瞄器不需要讀取磁碟或者只需讀取少量磁碟，且alwayson是整庫同步，只要是主副本產生的日誌都會同步到輔助副本，不需要進行日誌篩選，因此不僅讀取速度快，而且效率還很高。
備註：alwayson同步的日誌要比事務日誌發布訂閱的要多，但從網路角度來看不一定占用網路頻寬也會更多，因為在alwayson中，網路上傳遞的是壓縮了的日誌，而發布訂閱則沒有做壓縮的優化。
在發布訂閱中，日誌無法直接從發布庫到訂閱庫，期間必須通過分發庫中轉，每個過程都會產生大量的磁碟io和網路消耗；
而alwayson是點到點的資料同步，日誌從主副本直接傳送到輔助副本，中間不需要中轉，傳輸過程簡單高效。
上文在介紹alwayson同步原理時，我們考慮地比較簡單，只考慮了日誌的同步情況。
如果要結合事務來整體考慮，alwayson的同步——更準確地說是可用模式，應該分為非同步提交模式和同步提交模式。
可用性模式是alwayson中每個可用性副本的乙個屬性，它決定了主副本在提交事務之前是否需要等待某個輔助副本將事務日誌記錄固化到磁碟，如果需要等待，則該alwayson的可用模式為「同步提交模式，反之，則是「非同步提交模式」。
使用此可用性模式的可用性副本稱為"非同步提交副本"。
當輔助副本處於非同步提交模式下或者儘管輔助副本在同步提交模式下，但此時主副本在非同步提交模式時，主副本無須確認該輔助副本是否已經完成日誌固化，就可以提交事務。因此，主資料庫事務提交不會受到輔助資料庫的影響而產生等待。但是，輔助資料庫的更新可能會滯後於主資料庫，如果發生故障轉移，可能會導致某些資料丟失。因此這種可用模式適合於可用性副本的分布距離較遠的情況。
使用此可用性模式的可用性副本稱為"同步提交副本"。同步提交模式要求主副本和輔助副本必須設定成同步提交副本。
在同步提交模式中，主副本必須確認輔助副本已經完成日誌固化才可以提交事務（不需要等待輔助副本完成日誌重做），這樣就保證兩邊的資料始終是同步的。但是這種保障的代價是主資料庫上的事務提交會有滯後時間。可以說，同步提交模式相對於效能而言更強調高可用性。
mysql可重複讀現象及原理分析
mysql可重複讀現象及原理分析 一 可重複讀 我們先看看現象，再分析原理。我的mysql版本是5.5。下面是一張表，只有一條資料，並且我開啟了事物 此時，另乙個事物將record加1，因此我在開啟乙個命令列客戶端，執行下面的命令 成功加1之後，實際上，資料庫中record肯定是2。然後回到之前的客...
可擴充套件的檔案同步設計
在老的cms系統中通過新配置的同步系統，對cms生成的檔案進行同步。方便對機器新增的擴充套件，新新增的機器首先執行同步初始化的功能模組，此圖暫時沒有加上。在同步模組中進行配置源與目標伺服器的服務模組url。cms的新聞新增，修改及刪除需增加同步函式，以使得新聞新增修改和刪除的動作記錄到同步表中。同步...
ReentrantLock可重入鎖的原理及使用場景
從使用場景的角度出發來介紹對reentrantlock的使用，相對來說容易理解一些。a 忽略重複加鎖。b 用在介面互動時點選執行較長時間請求操作時，防止多次點選導致後台重複執行 忽略重複觸發 以上兩種情況多用於進行非重要任務防止重複執行，如 清除無用臨時檔案，檢查某些資源的可用性，資料備份操作等 i...