• 项目

提高可用性和伸缩性

在许多应用程序中，提供较高的可用性和较高的读取可伸缩性是十分重要的；而复制便可作为提供这两方面的性能的解决方案的关键部分。 对于某些应用程序而言，其目标可能是通过复制来提高可用性或可伸缩性。 如果只需要提高其中一方面的性能，则可考虑使用下列方案之一：

下面关系图说明了从使用复制来提高可用性和可伸缩性中受益的两个应用程序。 在这两种情况下，关系图中的三个数据库都是对等的：它们包含相同的架构和数据。 必须对这些数据库的写入活动进行分区：例如，如果数据库已包含产品目录，则可以将产品名称以 A-I 开头的更新定向到第一个数据库，将产品名称以 J-R 开头的更新定向到第二个数据库，而将产品名称以 S-Z 开头的更新定向到第三个数据库。 然后再将更新复制到其他数据库。

在第一个关系图说明的配置中，每个 Web 和应用程序服务器都使用来自特定缓存服务器的数据。 给定用户的读取和更新操作流入特定的应用程序服务器，然后再流至缓存服务器。 由于应用程序服务器直接更新缓存，因此不需要中央源服务器。 每个缓存的更新都会传播到其他缓存。

使用复制扩展读取活动

第二个关系图显示三个地理上分散的服务器，三者之间均有数据流动，从而使每个服务器都能支持读请求并能提高可用性。

向分散位置的对等复制

Adventure Works Cycles 示例

Adventure Works Cycles 是一家虚构的制造公司，用于演示数据库概念和方案。 有关详细信息，请参阅AdventureWorks2008R2 示例数据库。

Adventure Works Cycles 在全世界设有多个办事处，所在地点包括洛杉矶、伦敦和台北。 每个地点都收集客户订单信息，然后将其复制到其他地点。

可以从任一位置读取订单信息；因此，如果伦敦办事处读取活动繁忙，则内部应用程序可将部分活动分发到另外两个办事处。

例如，如果伦敦办事处因维护而关闭服务器，仍可从其他位置检索订单，而且伦敦办事处的工作人员仍可继续读取和录入数据。 伦敦服务器重新联机后，在其停机期间收到的更改将传播到伦敦的服务器，以使其保持最新状态。

此方案的一般要求

使用复制来提供可伸缩性和可用性的应用程序通常具有下列要求，合适的复制解决方案必须满足这些要求：

  • 系统应当允许在任何服务器上进行更改，并可使更改复制到所有其他服务器。

  • 系统必须保持事务的一致性。

  • 系统的滞后时间应较短：一台服务器的更新必须快速到达其他服务器。

  • 系统的吞吐量应较高：应能处理大量事务的复制。

  • 复制处理所需的开销应当很小。

用于此方案的复制类型

Microsoft SQL Server 用出版业的术语来说明复制系统的组件。 这些组件包括发布服务器、订阅服务器、发布、项目和订阅。

在上面的关系图中，所有缓存服务器都身兼发布服务器和订阅服务器两种身份。 每台服务器复制数据库中的全部数据都包含在发布中，其中每个数据表都是一个项目（项目还可以是其他数据库对象，如存储过程）。 每个服务器都从其他服务器订阅发布，把架构和数据作为订阅来接收。 有关系统组件的详细信息，请参阅复制发布模型概述。

SQL Server 针对不同的应用程序要求提供了不同类型的复制：快照复制、事务复制以及合并复制。此方案使用对等事务复制来实现效果最佳，对等事务复制非常适合处理上一部分中概述的要求。 有关对等事务复制的详细信息，请参阅对等事务复制。

注意注意

如果应用程序需要同时在多个节点修改给定行，则可能出现数据冲突。 在这种情况下，请使用合并复制，这种复制非常适合处理冲突。 有关合并复制的详细信息，请参阅合并复制概述。

按照设计，事务复制可处理此方案下列主要要求：

  • 可在任何服务器上进行更改

  • 事务的一致性

  • 较低的滞后时间

  • 大吞吐量

  • 最低开销

事务复制的对等选项允许服务器发布和订阅相同的数据。 对等拓扑中的所有节点都是对等方：每个节点所发布和订阅的架构和数据都是相同的。对每个节点都可进行更改（插入、更新和删除），然后再将更改复制到所有其他节点。

实现此方案的步骤

若要实现此方案，必须先创建发布和订阅，并且初始化每个订阅。 有关详细信息，请参阅：

在初始化订阅以及数据在各对等方之间开始流动后，可能需要查阅下列主题，以获得有关常见管理和监视任务的信息：