提高伸缩性
中间层应用程序通常使用单一数据库存储数据，随着数据库负载的不断增长，这可能会导致伸缩受限。当应用程序执行读取多于写入（如使用基于 Web 的目录）时，通过在多个数据库间缓存只读数据，并在数据库间均匀连接客户端以分发负载，可以向外扩展工作负荷的读取分区。
下面的关系图说明了一种配置，在此配置中，应用程序和 Web 服务器使用来自三个缓存服务器中的任意一个的数据。
.gif "使用复制扩展读取活动")
如果应用程序还需要提高可用性，和/或需要给定用户的读取和更新流动到特定的应用程序服务器，然后再流动到特定的缓存服务器，请参阅提高可用性和伸缩性中的示例。
Adventure Works Cycles 示例
Adventure Works Cycles 是一家虚构的制造公司，用于演示数据库概念和方案。有关详细信息，请参阅示例和示例数据库。
Adventure Works Cycles 最近升级了其网站，包括了下列新功能：
- 针对客户的在线产品订购。
- 在线订单状态检查。
- 更强大的产品资料搜索功能。
实现网站上的在线产品订购极大地增加了公司专用于 Microsoft SQL Server 的计算机的活动。Adventure Works 管理员决定使用此计算机作为复制数据的源。所有读取活动都扩展到另外三台运行着 SQL Server 的计算机，这些计算机对来自源计算机的数据进行缓存。缓存计算机处理所有读取活动，包括用户浏览和搜索产品目录，以及检查订单状态。将所有写入活动都定向到源数据库。
此方案的一般要求
使用复制提供伸缩性的应用程序通常有下列要求，而相应的复制解决方案必须处理这些要求：
- 系统必须保持事务的一致性。
- 系统的滞后时间应较短：源的更新必须快速到达缓存。
- 系统的吞吐量应较大：应能处理大量事务的复制。
- 复制处理应要求尽量小的源开销。
- 缓存所需的数据应是源上可用数据的子集。
用于此方案的复制类型
SQL Server 使用出版业的术语来描述复制系统的组件。这些组件包括发布服务器、订阅服务器、发布、项目和订阅。有关系统组件的详细信息，请参阅复制发布模型概述。
在上面的关系图中，源是发布服务器。源的部分或所有数据都包括在发布中，其中每个数据的表都是一个项目（项目还可以是其他数据库对象，如存储过程）。每个缓存都是发布的订阅服务器，它接收架构和数据作为订阅。
SQL Server 针对不同应用程序的要求提供了不同的复制类型：快照复制、事务性复制以及合并复制。此方案最好用事务性复制来实现，事务性复制非常适合于处理上一部分中所述的要求。有关事务性复制的详细信息，请参阅事务复制概述和事务复制的工作机制。
按照设计，事务性复制可处理此方案下列主要要求：
- 事务的一致性
- 较短的滞后时间
- 大吞吐量
- 尽量小的开销
此方案需要考虑的首要选项是筛选。通过使用事务性复制，可以对列和行进行筛选，因此订阅服务器上的表可以只包含应用程序所必需的数据。有关详细信息，请参阅筛选已发布数据。
实现此方案的步骤
若要实现此方案，必须先创建一个发布和一些订阅，然后对各个订阅进行初始化。有关各步骤的详细信息，请单击下面的链接：
在对订阅进行了初始化且数据开始在发布服务器和订阅服务器之间流动之后，您可能需要查阅以下主题，了解常见管理任务和监视任务的有关信息：