一. 前言
1. 背景
大部分場景中，DB操作80%是讀，20%是寫，對於時效性要求不高的數據，為了減少磁盤讀和寫的競爭，引入讀寫分離的概念，即在數據庫上進行主從配置，一個主，多個從，實現主從同步，從而業務上實現讀寫分離。
讀寫分離在網站發展初期可以一定程度上緩解讀寫並發時產生鎖的問題，將讀寫壓力分擔到多台服務器上。基本原理是讓主數據庫處理增、刪、操作，而從數據庫處理SELECT查詢操作。隨着系統的業務量不斷增長，數據不斷增多，數據庫的IO操作壓力會很大，讀寫分離也是數據庫分庫的一種方案。
(1). 主庫：叫讀寫庫，主要用來處理 增刪改，特殊情況也可以查。
(2). 從庫：叫只讀庫，主要用來查詢數據。
2. 需要解決的問題
在業務上區分哪些業務是允許一定時間延遲的，可以接受數據同步的耗時。
3. 常見實現方式
復制模式、鏡像傳輸、日志傳輸、和 Always On技術
二. SQLServer各種模式介紹
1. 復制模式
(1). 簡介
復制模式也被稱為【發布-訂閱模式】，是由主服務器進行發布消息，備份服務器進行訂閱，當主服務器數據發生變更時，就會發布消息，備份服務器讀取消息進行同步更新，中間過程延遲比較短。
復制方式是以前很常見的一種主備，速度快，延遲小，可以支持部分同步等優點，但是也有一個很明顯的缺點，因為是部分同步，如果是表修改，可以主動同步，但是如果是新增表、視圖等操作，必須在發布屬性中，將新加的表或者視圖添加到同步配置中，否則對這個表做的任何操作都不會同步。
復制模式同步，要求數據庫名稱和主機名稱必須一致，否則查找不到數據庫主機；要求數據庫不能使用端口，必須是可以通過ip直接訪問的。
(2). 發布分為4種模式：
A.快照發布
發布服務器按'預定的時間間隔'向訂閱服務器發送已發布數據的快照。
快照發布，就是將所有要發布的內容，做成一個鏡像文件，然后一次性復制到訂閱服務器，兩次快照之間的更新不會實時同步,而是按照設置的'預定間隔'進行。這種方式占用帶寬較多，因此比較適用內容不是很大，或者更新不需要很頻繁的場景。
B.事務發布
在訂閱服務器收到已發布數據的初始快照后，發布服務器將事務流式傳輸到訂閱服務器。
事務發布，是在第一次設置好事務復制之后，所有發布的內容都會進行鏡像快照，訂閱服務器收到已發布數據的初始快照后，發布服務器將事務流式傳輸到訂閱服務器。當主服務器數據發生變更時，會通過日志傳遞同步
給訂閱服務器，數據近似於同步更新。
此方式會對主服務器性能造成很大影響（實時同步每次變更，而不是最終變更），適用於對數據及時性要求比較嚴格主備方案，但是目前已被微軟提供的集群Always On所取代。
C.對等發布
對等發布支持多主復制。發布服務器將事務流式傳輸到拓撲中的所有對等方。所有對等節點可以讀取和寫入更改，且所有更改將傳播到拓撲中的所有節點。
D.合並發布
合並發布是相當於兩台都是主服務器，都可以對數據進行更新修改等操作，然后定時將發布服務器上的內容與訂閱服務器上的內容進行合並，並根據配置保留相應內容，此種很少用。
(3). 該模式的訂閱分兩種：
A.請求訂閱：從數據庫按照既定的周期來請求主數據庫，將增量數據腳本獲取回去執行，從而實現數據的同步。
B.推送訂閱：主數據庫數據有變更的時候，會將增量數據腳本主動發給各個從數據庫(性能優於請求訂閱模式，建議使用)。
注：從數據庫中表設計的時候，主鍵不要用自增！！
2. 鏡像傳輸
數據庫鏡像傳輸，嚴格來說不是主從架構，而是主備架構，將兩台數據庫服務器通過一台中間監控服務器關聯起來，兩台服務器通過鏡像文件，實時同步數據（有延遲，延遲很短）。當主服務器宕機之后，監控服務器自動切換到備份服務器上。
此方案優點是可以快速的切換主備方案，相比較Always on集群，可以不用共享磁盤即可實現，避免了數據庫集群存儲單點故障，導致整個集群崩潰。
缺點也很明顯，無論是主備服務器，要實現同步操作，都是依賴於性能低的那一端，因此兩台服務器都要是高性能的才可以保證同步的及時性；同時備份服務器只是備份和故障轉移，不能提供從服務器的只讀訪問，
因此才說是主備服務器，而且是一對一，只能有一台備份服務器。
3. 日志傳輸
與鏡像傳輸模式類似，是將主數據庫日志備份，發送到從服務器上，然后從服務器還原日志，更新數據。
此方式優點在於從服務器可以有多台從服務器，而且當主服務器腳本操作異常后，只需要在日志同步之前，及時攔截日志傳輸，即可保留從服務器數據，減少災難損失；此方式相較於“復制發布”模式，還有一個有點就是無論是新增表、視圖等等，都會通過日志同步給從服務器，而復制模式不行
而相應的缺點就是通過日志備份傳輸，在還原，會有較大的時間延遲。而且無法自動轉移故障，只能手動轉移。
4. Always On技術
AlwaysOn是基於Windows的故障轉移集群，集群技術是微軟提供的，可用性最高的主備方案。它是將多台服務器通過一個共享的外部存儲區域（SAN），連接成一個資源共享的服務器群體，數據庫文件和實例，都存放並運行在該共享區域節點上，每台服務器相當於一個節點，共同訪問共享的節點實例。服務器只有一個節點處於活動狀態，當活動節點出現故障，會有其他節點主動啟動，取代當前故障點，整個過程只需要幾秒鍾，用戶無法感知。
集群有很多優點，是目前最高效的高可用技術，但是他也有很明顯的缺點，所有的節點，都依賴於共享節點實例，如果共享節點出現故障，將會導致整個集群失去作用，且很難恢復。
三. 發布訂閱模式實操
事先准備：
(1). 啟動SQLServer代理模式。
A. 在服務中啟動：運行services.msc，找到 ‘SQL Server 代理 (MSSQLSERVER)’，手動啟動。
B. 在開始菜單中找到SQLServer Configure Manger頁面配置，手動啟動。
(2). SQLServer要用本機名登錄，不能Localhost
(3). 准備數據庫(1主2從)
A. 主庫：ReadWriteMaster
B. 從庫：ReadWriteSlave1、ReadWriteSlave2
結構：含有一張UserInfor表，如下圖：
PS：從庫也可以不用創建，因為在新建訂閱的時候，可以選擇自動創建，會自動同步數據庫結構。
1. 配置分發服務器
(1). 如果是首次配置讀寫分離，需要配置分發服務器，后續不再配置。 如果不想用之前的分發服務器，可以右鍵復制，禁用分發服務器，然后重新配置。
注：配置過程中，快照地址要有讀寫權限，不要放到C盤。
2. 新建發布
下面的演示步驟，是以【快照發布】的模式進行創建的，配置成10s同步一次； 也可以選擇【事務發布】，實時同步，不需要配置同步頻率。
3. 新建訂閱
下面的演示步驟，采用的是【推送訂閱】的模式進行，配置的是已經創建好的從數據庫ReadWriteSlave1（ReadWriteSlave2相同），也可以現場創建。
補充：右鍵啟動復制監視器，查看發布訂閱的同步情況
四. 實操測試
1.單純的SQL測試
use [ReadWriteMaster]
select * from [dbo].[UserInfor]
--delete from [dbo].[UserInfor]
use [ReadWriteSlave1]
select * from [dbo].[UserInfor]
--delete from [dbo].[UserInfor]
use [ReadWriteSlave2]
select * from [dbo].[UserInfor]
--delete from [dbo].[UserInfor]
insert into [dbo].[UserInfor] values('008','ypf1',26,'2020-07-08')
結果：
向主數據庫中插入一條數據，約10s后（用到是上面的快照發布），查詢從數據庫，數據已經通過來了。