簡介
SQL Server中的復制(Replication)是SQL Server高可用性的核心功能之一,在我看來，復制指的並不僅僅是一項技術，而是一些列技術的集合,包括從存儲轉發數據到同步數據到維護數據一致性。使用復制功能不僅僅需要你對業務的熟悉，還需要對復制功能的整體有一個全面的了解，本系列文章旨在對SQL Server中的復制進行一個簡單全面的探討。(PS:在我的上篇文章中我發現某些文章的圖片使用mspaint手繪更有感覺，但被很多人吐槽，因此在不考慮個人羞恥感的前提下，本系列文章中的一些圖片繼續使用mspaint
)。
復制是什么
復制，英文是Replication,這個詞源自於拉丁文replicare，原意是重復。SQL Server中的復制也是這個意思，復制的核心功能是存儲轉發，意味着在一個在一個位置增刪改了數據以后，重復這個動作到其他的數據源，概念如圖1所示。
圖1.復制的基本概念
當然，上面的這個模型是復制最簡單的模型，實際中的模型可能會復雜很多，但是大多數使用復制的原因可以分為如下幾類：
1.負載均衡—-通過將數據復制到其它數據庫服務器來減少當前服務器的負載，比如說最典型的應用就是分發數據來分離OLTP和OLAP環境。
2.分區—-將經常使用的數據和歷史數據隔離，將歷史數據復制到其它數據庫中
3.授權—-將一部分數據提供給需要使用數據的人，以供其使用
4.數據合並-每個區域都有其各自的數據，將其數據進行合並。比如一個大公司，每個地區都有其各自的銷售數據，總部需要匯總這些數據。
5.故障轉移—-復制所有數據，以便故障時進行轉移。
雖然需要使用復制的原因多種多樣，但是在使用之前你首先要了解復制技術所需的組成元素。
復制的組成部分
復制的概念很像發行雜志的模型，從發行商那里出版后，需要通過報刊亭等地方分發到訂閱雜志的人手里。對於SQL Server復制來說，這個概念也是如此。對於SQL Server復制來說，發行商，報刊亭，訂閱者分別對應的是發布服務器，分發服務器，訂閱服務器。概念如圖2所示。
圖2.發布分發訂閱的基本概念
發布服務器
圖2中的發布服務器包含了需要被發布的數據庫。也就是需要向其它數據源分發內容的源數據庫。當然，被發布的數據首先需要被允許發布。關於這里的詳細設置會在文章后面提到。
分發服務器
圖2中的分發服務器包含了分發數據庫，分發數據庫的作用是存儲轉發發布服務器發過來的數據。一個分發服務器支持多個發布服務器，就像一個報刊亭可以出售多個出版社所出的雜志一樣。同理，分發服務器也可以和發布服務器是同一個實例，這就像出版商不通過報刊亭，自己直接販賣雜志一樣。
訂閱服務器
圖2中的訂閱服務器包含了發布服務器所發布的數據的副本。這個副本可以是一個數據庫，或者一個表，甚至是一個表的子集。根據不同的設置，有些發布服務器發布的更新到訂閱服務器就是只讀的（比如說用於出報表的OLAP環境），或者是訂閱服務器也可以進行更新來將這些改變提交到發布服務器。
發布和文章
發布指的是可以發布的文章的集合，這些文章包括表，存儲過程，視圖和用戶自定義函數，如圖3所示。
圖3.可以發布的內容
當我們發布表時,還可以根據限定條件只發布表的子集。
訂閱
訂閱是相對發布的一個概念，訂閱定義了訂閱服務器從哪個分發服務器接收發布。有兩類訂閱方式，推送訂閱（Push)和請求訂閱（Pull),根據名字就可以望文生義的知道,在推送訂閱的情況下，當發布服務器產生更新時，分發服務器直接更新訂閱的內容，而請求訂閱需要訂閱服務器定期查看分發服務器是否有可用更新，如果存在可用更新，則訂閱服務器更新數據。
復制類型
SQL Server將復制方式分為三大類，每一個發布只能有一種復制類型，分別為:快照復制，事務復制和合並復制。
快照復制
快照復制將發布的所有表做成一個鏡像，然后一次性復制到訂閱服務器。中間的更新不會像其它復制類型那樣自動傳送到訂閱服務器。由這個概念不難看出，快照復制的特點會是:
1.占用網絡寬帶，因為一次性傳輸整個鏡像，所以快照復制的內容不應該太大。
2.適合那些更新不頻繁，但每次更新都比較大的數據。比如企業員工信息表，每半年更新一次這類的業務場景。
3.適合訂閱服務器是OLAP只讀的環境。
來自MSDN的配圖能很好的闡述快照復制，如圖4所示。
圖4.快照復制
事務復制
事務復制就像其名字一樣，復制事務。在第一次設置好事務復制后，發布的表、存儲過程等將會被鏡像，之后每次對於發布服務器所做的改動都會以日志的方式傳送到訂閱服務器。使得發布服務器和訂閱服務器幾乎可以保持同步。因此，可以看出事務復制的特點是:
2.發布服務器，分發服務器，訂閱服務器之間的網絡連接要保持暢通。
3.訂閱服務器也可以設置成請求訂閱,使得訂閱服務器也可以不用一直和分發服務器保持連接。
4.適用於要求實時性的環境。
來自MSDN的配圖能很好的闡述事務復制，如圖5所示
圖5.事務復制
合並復制
合並復制即允許發布服務器更新數據庫，也允許訂閱服務器更新數據。定期將這些更新進行合並，使得發布的數據在所有的節點上保持一致。因此，有可能發布服務器和訂閱服務器更新了同樣的數據，當沖突產生時，並不是完全按照發布服務器優先來處理沖突，而是根據設置進行處理，這些會在后續文章中講到。
來自MSDN的配圖能很好的闡述合並復制，如圖6所示。
圖6.合並復制
建立一個簡單的事務復制
下面我進行一個簡單的事務復制。首先，在本地安裝兩個SQL Server實例，我本機安裝的兩個實例分別為SQL Server 2008R2和SQL Server 2012,其中，SQL Server 2008R2作為發布和分發服務器，SQL Server 2012作為訂閱服務器，如圖7所示。
圖7.復制的兩個實例
首先在SQL Server 2008R2上配置發布服務器和分發服務器，選擇配置分發，如圖8所示。
圖8.配置分發
設置快照文件夾，由上面MSDN的圖可知，快照代理是需要在分發服務器上暫存快照的，設置這個目錄，如圖10所示。
圖10.設置快照文件夾
這里值得注意的是，需要給這個目錄對於Everyone設置讀取權限，如圖11所示。
圖11.設置讀取權限
下一步配置分發向導就按照默認值來，如圖12所示。
圖12.配置分發向導
剩下的步驟都保持默認值，最后成功在SQL Server 2008R2實例上配置發布服務器和分發服務器，如圖13所示。
圖13.成功配置發布和分發服務器
下面就要建立一個發布了，選擇新建發布，如圖14所示。
圖14.新建發布
一路next,在選擇發布類型時選擇事務發布，如圖15所示。
圖15.選擇事務發布
發布用於測試的一個表，只有兩個列，一個為自增的int型主鍵id,另一個為隨便設置的列，如圖16所示。
圖16.設置發布的表(文章)
下一個頁面不過濾文章，直接保持默認值下一步。在下一個窗口中選擇立即創建快照並初始化..如圖17所示。
圖17.立即創造快照並初始化
安全設置保持和SQL Server Agent一樣的賬戶，如圖18所示。
圖18.快照代理和日志讀取代理設置和SQL Server Agent同一個賬戶
剩下的步驟一路下一步，設置好發布名稱后，成功創建發布,如圖19所示。
圖19.成功創建發布
下面我們來在SQL Server 2012的實例上創建訂閱，選擇新建訂閱，如圖20所示。
圖20.新建訂閱
在歡迎界面選擇下一步后，選擇剛剛創建的發布,如圖21所示。
圖21.選擇發布服務器
下一步選擇推送訂閱，以便發布服務器所做的改動能自動更改到訂閱服務器，如圖22所示。
圖23.選擇推送訂閱
選擇保持連接，下一步保持默認值，然后在分發代理安全性下選擇模擬進程賬戶。如圖24所示。
圖24.選擇模擬進程賬戶
保持默認值，一路下一步直到訂閱創建完成，如圖25所示。
圖25.創建訂閱成功
現在我們進行測試，向表中插入100條數據，監視狀態，發現100個事務已經成功傳到了訂閱服務器，如圖26所示。
圖26.插入的100條數據已經成功傳送到訂閱服務器
現在我們再來看訂閱服務器(SQL Server 2012),在發布服務器插入的100條數據已經成功存在於訂閱服務器，如圖27所示。
圖27.100條數據已經成功發布到了訂閱服務器
總結
本文對SQL Server的復制進行了大致的講解，並實現了一個簡單的復制。復制的概念需要對SQL Server的各個方面都要有所涉獵，本系列文章的下一篇將會將復制應用的一些模式。
本篇文章根據發布服務器，分發服務器和訂閱服務器的組織方式和復制類型來講述常用復制的幾種模式。
模式的選擇
選擇復制的模式取決於多個方面。首先需要考慮具體的業務需求，在此之后還需要考慮硬件和網絡的限制。對於業務需求來說考慮的角度可以分為兩個部分：自治和延時。自治是指”數據不被影響的程度”,比如說一個業務場景：公司的總部在北京，發布服務器和分發服務器全在總部，各個地區的分部有訂閱服務器，使用快照復制來接收推送訂閱總部每個月一次的公司員工通訊錄。在這個業務場景中，訂閱服務器僅僅是接收發布服務器發布的通訊錄信息，對於這些信息的修改是不會回傳給總部服務器的，這個業務場景的自治程度就是非常低的。而對於延時來說,就是”在發布服務器上的數據修改應用到訂閱服務器上的時間”,比如還是上面那個例子，每次訂閱服務器的訂閱周期是一個月，在此期間總部的通訊錄可能經過了多次修改，但一個月以后才會同步到訂閱服務器，那么這種場景的延時是非常高的。
其次就是硬件和網絡的限制，比如將發布服務器和分發服務器設置在一台服務器上，在現有的情況下CPU是否能夠承受這些負擔？或是使用快照復制，發布服務器和訂閱服務器之間的網絡寬帶是否能夠承受在一定發布周期內的數據量傳輸？
在簡單了解了模式選擇的標准后，下面我們來看常用的幾種復制模式。
以發布服務器為中心的復制模式
這種模式多個訂閱服務器以一個發布服務器為中心進行訂閱，如圖1所示。
這種模式也是復制模式中最簡單的模式，這種模式可以使用快照發布和事務發布。不難看出，這種情景的自治性是比較低的，因此這種模式適用於以下幾種業務場景。
當然，這種模式的缺陷也是顯而易見的。
- 首先是發布服務器和分發服務器在同一台服務器上對CPU和內存的消耗服務器硬件是否能夠承受是一個問題
- 在OLTP環境中如果每天要修改的數據量過大，比如超過10%，那么需要傳送到的訂閱服務器的數據量過大也是不得不考慮的一個問題
以發布服務器和分發服務器為中心的復制模式
這種模式其實和上一種模式區別不大，只是分離了發布服務器和分發服務器，如圖2所示。
這種模式是將分發任務對CPU,內存和網絡帶來的負載轉移到另一台分發服務器了。從而減輕發布服務器的壓力和支持更多的訂閱服務器。此外，我們知道一個分發服務器支持多個發布服務器的，因此也可以多個發布服務器使用一個分發服務器。
這種模式還有一個好處是可以將分發服務器放到DMZ區域和訂閱服務器連接以避免發布服務器直接暴漏在外網。
當然了，這種模式最重要的一點是發布服務器和分發服務器一定要有可靠的網絡連接，這種模式和圖1提到的第一種模式適用的業務場景基本一致。
發布-訂閱的復制模式
圖3.發布-訂閱復制模式
這種模式適用於服務器A和服務器B的網絡非常昂貴但服務器B和各個訂閱服務器的網絡成本很低的情況。比如，公司的總部在北京，服務器A在北京，服務器B是上海分公司的，各個訂閱服務器通過局域網和服務器B進行連接。在這個例子中，服務器A和服務器B通過VPN進行連接，這個費用是相當昂貴的，而服務器B和各個訂閱服務器通過局域網連接的成本可以忽略。
以訂閱服務器為中心的復制模式
這種模式以訂閱服務器為中心，如圖4所示。
圖4.以訂閱服務器為中心復制模式
這種模式適用的場景比如：各個區域將各自的業務數據匯總到總部這種類型的業務場景。
多個發布服務器和多個訂閱服務器的復制模式
這種模式適用於數據對等的環境,一個簡化的版本如圖5所示。
這種模式非常適合業務數據對等的環境，比如說這類業務場景，一個銷售公司在同一個城市有3個分店，這三個分店之間是對等的，它們之間通過復制來同步庫存。使得每個店都可以了解其它分店的庫存情況。這類業務場景適合使用多個發布服務器和多個訂閱服務器的復制模式。
具有可更新訂閱的事務發布模式
這種模式非常類似圖1中所說的模式，但這種模式允許訂閱服務器更新數據。如圖6所示。
圖6.具有可更新訂閱事務的發布模式
在這種模式下，比如訂閱服務器B更新了數據，這個數據會傳送回發布服務器，如果發布服務器接收了這個數據，那么這個數據會同時同步到其它訂閱服務器。
合並發布模式
合並發布模式適用於所有服務器共享一部分數據的場景，如圖7所示。
圖7.合並發布模式
這種模式下，每個服務器並不是互相訂閱，而是互相共享。這種模式同樣適用於圖5所述的業務模式。
總結
本文講述了復制的幾種模式以及它們的所適用的一些場景，很多更復雜的復制模式大多都是對以上幾種模式的組合或者拓展。理解上述簡單的復制模式是理解復雜復制模式的基礎。