1. 程式人生 > 實用技巧 >第十九節:SQLServer通過釋出訂閱實現主從同步(讀寫分離)詳解

第十九節:SQLServer通過釋出訂閱實現主從同步(讀寫分離)詳解

一.前言

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代理模式,兩種方式:去服務中直接啟動,或者去 SQLServer Configure Manger頁面配置

(2). ReadWriteMaster 主庫 (含有一張UserInfor表)

  ReadWriteSlave1 從庫1

  ReadWriteSlave2 從庫2 (從庫可以在新建訂閱的時候,現場建立即可, 會自動同步表結構)

(3). SQLServer要用本機名登入,不能Localhost。

1. 配置分發伺服器

(PS:僅首次需要配置,配置的快照地址要有讀寫許可權,不要放到C盤)

右鍵複製→配置分發

需要實現開啟代理伺服器。

2. 新建釋出

3. 新建訂閱

四.實操測試

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')

2.結合EFCore進行測試

!

  • 作者 : Yaopengfei(姚鵬飛)
  • 部落格地址 : http://www.cnblogs.com/yaopengfei/
  • 宣告1 : 如有錯誤,歡迎討論,請勿謾罵^_^。
  • 宣告2 : 原創部落格請在轉載時保留原文連結或在文章開頭加上本人部落格地址,否則保留追究法律責任的權利。