共用方式為

  • 發行項

提升延展性

中間層應用程式通常使用單一資料庫儲存資料，隨著資料庫負載的增加這會將導致調整限制。應用程式執行讀取操作多於寫入時，例如使用網路架構目錄，則可能會透過多個資料庫快取唯讀資料，並且平均連接用戶端以分散負載的方式，來向外延展工作負載的讀取部份。

下圖說明所用資料來自三台快取伺服器任一台之應用程式和 Web 伺服器的組態。

使用複寫來調整讀取活動

如果您的應用程式也需要增加可用性，及 (或) 需要給定使用者的讀取和更新流向指定應用程式伺服器，之後流向指定快取伺服器，請參閱＜提高可用性和延展性＞中的範例。

Adventure Works 循環範例

Adventure Works Cycles 是虛構的製造公司，用於示範資料庫概念與案例。 如需詳細資訊，請參閱＜AdventureWorks 範例資料庫＞。

Adventure Works Cycles 最近已升級其網站，包含下列新功能：

  • 客戶線上產品訂購。

  • 線上訂單狀態查看。

  • 更佳的產品文宣搜尋能力。

允許從網站進行線上產品訂購，將大幅增加公司在專用於 MicrosoftSQL Server 之單一電腦上的活動。由 Adventure Works 管理員決定將此電腦用作複寫資料的來源。所有的讀取活動會向外延展至執行 SQL Server 的其他三台電腦，這些電腦將從來源電腦快取資料。快取電腦處理所有的讀取活動，包括使用者瀏覽和搜尋產品目錄以及查看訂單狀態。所有的寫入活動均導向來源資料庫。

這個狀況的一般需求

使用複寫來處理延展性的應用程式通常具有下列需求，適當的複寫方案必須提出因應對策：

  • 系統必須維護交易一致性。

  • 系統應該具有低度延遲：來源端的更新必須快速達到快取要求。

  • 系統應該具有高輸送量：它應該能處理大量交易的複寫。

  • 複寫處理應要求來源端承受最小負擔。

  • 快取端所需的資料可以是來源端可用資料的子集。

這個狀況要使用的複寫類型

SQL Server 使用的是出版業的字眼，來描述複寫系統的元件。元件包含發行者、訂閱者、發行集與發行項，以及訂閱。如需系統元件的詳細資訊，請參閱＜複寫發行模型概觀＞。

在上圖中，來源為「發行者」。來源端資料部份或全部資料包含於發行集中，每個資料表的資料則是發行項 (發行項也可以是其他資料庫物件，例如預存程序)。每個快取是發行集的「訂閱者」，以訂閱的方式接收結構描述和資料。

SQL Server 為不同的應用程式需求提供不同類型的複寫：快照式複寫、交易式複寫和合併式複寫。此狀況很符合處理前一章節所列出的需求大綱，最適合實作交易式複寫。如需交易式複寫的資訊，請參閱＜交易式複寫概觀＞以及＜交易式複寫的運作方式＞。

依設計，交易式複寫可解決此狀況的主體需求：

  • 交易一致性

  • 低度延遲

  • 高度輸送量

  • 最低負擔

此狀況要考慮的主要選項為篩選。交易式複寫可允許您篩選資料行和資料列，這樣訂閱者資料表中可以只容納應用程式需要的資料。如需詳細資訊，請參閱＜篩選發行的資料＞。

實作這個狀況的步驟

若要實作這個狀況，您必須先建立發行集與訂閱，然後初始化每個訂閱。按一下下列的連結，以取得有關每個步驟的詳細資訊：

在初始化訂閱，而且資料在發行者與訂閱者之間流動之後，您可能需要參考下列主題，以取得一般管理與監視工作的資訊：