lienlien
現在信息科技的高速發展離不開數據庫，在國內使用最多的數據庫主要有：SQL Server、MySQL、Oracle ，其實不管是哪種數據庫，在數據量及併發量達到一定程度後，單一數據庫節點都會存在性能降低的現象。為了避免數據庫瓶頸影響性能，就需要對數據庫做分佈式集群部署，而分佈式集群部署又要依懶數據的主從同步。
什麼是數據庫主從同步？
數據庫的主從同步架構是當下最為常見的一種數據庫架構，通過主從同步可以使數據從一個數據庫節點複製到另一個數據庫節點，這樣才能保障數據庫分式布集群部署時數據是同步統一的。
在主從同步數據時，一臺服務器會充當主服務器（Master），其它服務器便會充當從服務器（Slave），一般是一主多從模式。
數據庫主從同步的目的
數據庫主從同步的主要作用有以下幾點：
便於架構擴展，降低單節點服務器壓力；
讀寫分離：將數據庫讀操作與寫操作分離至不同服務器，使得數據庫併發性更好；
數據熱備：將主庫數據同步到從庫數據庫後，一旦主庫服務器發生故障可以切換到從庫服務器，保障了業務穩定。
數據庫主從同步帶來的一些問題
上面提到的都是數據庫主從同步的優點，但在實際實施過程中，數據庫主從同步也會帶來一些問題，最為常見的就是：主庫與從庫之間的同步存在延遲！
這種同步延遲會導致：明明向主庫寫入了數據，但在一段時間內無法從從庫中查詢到，看上去數據存在不統一，也就無法保證主從架構下的強一致性。
如何規避數據庫主從同步的延遲？
可以這樣說，數據庫主從同步操作帶來的延遲是不可避免的，但我們可以通過一些方案來儘可能降低延遲時間，比如說：
將主庫和從庫放置在同一網絡節點，避免不同網關帶來的通信開銷；
主從節點同步時統一走內網IP通訊，不要走公網IP；
如果主從同步的延遲影響了業務，建議在數據庫上層加個Redis來緩衝數據。
網絡圈
SQL Server中的高可用特性工作中使用SQL Server高可用特性的場景也就是數據庫主從複製，可以用的特性有三個：複製、鏡像、日誌傳送。複製（發佈-訂閱模式）：
複製嚴格來說並不算是一個為高可用性設計的功能，但的確可以被應用於高可用性。複製提供了數據庫對象級別的保護。複製使用的是發佈-訂閱模式，即由主服務器（稱為發佈服務器）向一個或多個輔助服務器或訂閱服務器發佈數據。複製可在這些服務器間提供實時的可用性和可伸縮性。它支持篩選，以便為訂閱服務器提供數據子集，同時還支持分區更新。訂閱服務器處於聯機狀態，並且可用於報表或其他功能，而無需進行查詢恢復。
SQL Server 提供四種複製類型：快照複製、事務複製、對等複製以及合併複製。
我們一般選擇快照複製或事務複製，兩者概念介紹如下：
快照複製
1、概念 快照複製是完全按照數據和數據庫對象出現時的狀態來複制和分發它們的過程。快照複製不需要連續地監控數據變化，因為已發佈數據的變化不被增量地傳播到訂閱服務器，而是週期性的被一次複製。
2、 適用情況 數據主要是靜態的，比如將數據倉庫複製到數據集市中 一段時間內允許有已過時的數據拷貝的情況 小批量數據 站點經常脫離連接，並且可接受高延遲
事務複製
1、概念 使用事務複製，初始快照數據將被傳播到訂閱服務器，因此該訂閱服務器就具有了一個所謂的初始負載，這是可以開始工作的內容。當出版服務器上發生數據修改時，這些單獨的事務會被及時捕獲並複製到訂閱服務器。並保留事務邊界，當所有的改變都被傳播後，所有訂閱服務器將具有與傳播服務器相同的值。
2、適用情況 需要數據修改經常在其發生的幾秒鐘內被傳播到訂閱服務器 需要事務是原子性的 訂閱服務器在通常是連接到出版服務器上的 應用程序不能忍受訂閱服務器接收改變的高延遲 創建發佈-訂閱的數據庫服務器名不能是IP，只能是具體的服務器名稱，如：
可以執行以下SQL查看：
結果：
如果上下一致，則說明沒有問題，否則就需要改成一致的。如果右鍵點擊創建發佈或訂閱都不報錯，那麼可以進行下一步。根據具體情況使用不同的複製類型，這裡我使用了事務複製：
具體創建過程參考https://www.cnblogs.com/zhaow/articles/8275064.html，這裡我們創建個名叫DBPublishZW20180815的發佈。
並且成功地在訂閱數據庫中創建了訂閱，如：
創建發佈-訂閱後，我們可以監測發佈和訂閱狀態，如：
還可以監測發佈JOB和Agent的運行狀態：
複製中發佈服務器和訂閱服務器內容不一致的解決辦法在事務複製的過程中，有時候會由於各種各樣的原因導致發佈服務器和訂閱服務器的數據不一致，造成這種情況往往是由於以下幾種原因之一：①某個Agent運行出現錯誤或者Agent進程崩潰②比較大型的發佈是使用了備份還原，而不是快照複製初始化，而備份後發佈端修改了數據③非Distribution Agent線程修改了訂閱服務器的數據上面三種情況是最常見的導致發佈端和訂閱端數據不一致的原因，其中第三種原因往往出現的最多，在這種情況下，通常來說，可以通過重新初始化訂閱來解決該問題，但對於比較大的訂閱來說，或者發佈和訂閱之間相隔太遠而造成網絡寬帶的問題，則重新初始化訂閱就不是那麼吸引人的提案了。因此通過數據對比分析工具來比對有差異的數據，並僅僅更新那些和源不同步的數據則是更好的選擇。這類工具包括類似Redgate和xSql的數據對比工具，也可以使用Visual Studio自帶的數據對比工具。首先，我刪除訂閱庫中表中的一條數據（其實訂閱庫應該是隻讀的），此時訂閱庫就與發佈庫數據不一致了。我們來看下監測結果：
可以看到，這裡已經有了數據不同步的Log了，還可以看到發佈-訂閱的整個過程Log：
使用Visual Studio自帶的數據對比工具關於Visual Studio的SQL SERVER數據庫項目介紹：1、打開VS，點擊文件-新建項目-SQL SERVER 數據庫項目（tips:安裝vs時需要添加數據庫管理插件）2、創建項目後，在創建的解決方案下右鍵點擊導入-數據庫-選擇數據庫所在連接，導入設置默認就好，如果你們的數據庫權限範圍較高的話，根據自身情況設置3、啟動成功後，會自動掃描數據庫的相關配置加載到VS列表當中，這樣對系統的數據庫架構就一覽無遺了4、打開某個表的結構文件，可以看到我們表結構設計，相關的索引、主鍵、觸發器等，當然都只是結構，並且我們在界面上修改後，同時會生成對應的SQL語句，我們可以直接到數據庫中F5執行 以下即可由於我本機Visual Studio沒裝這個項目類型，所以參考https://www.cnblogs.com/CareySon/p/3302369.html吧！1、找出被刪除的數據
2、然後我們點擊"更新目標"，則被刪除的數據會由發佈端同步到訂閱端。如：
我們再次進行驗證訂閱，顯示已經通過訂閱。Echa攻城獅
延時只能逼近，不能解決，先說說你的問題場景，究竟對延時需要多高的要求。
夢虛竹林
你需要在主機寫入之後，保證在備機一定能夠讀取到已經寫入的數據，也就是說，你需要主從架構下的強一致性。
主機與備機之間的物理延遲是不可控的，也是無法避免的。但是如果僅僅需要滿足這種強一致性，是相對簡單的事：只需要在主機寫入時，確認更新已經同步到備機之後，再返回寫操作成功即可。
