对等复制通过跨多个服务器实例（也称为 节点）维护数据副本，从而提供横向扩展和高可用性解决方案。 基于事务复制的基础，对等复制以近乎实时的方式传播具有事务一致性的更改。 这样，需要横向扩展读取操作的应用程序就可以将客户端的读取请求分布到多个节点上。 由于数据在几乎实时的节点上进行维护，因此对等复制提供数据冗余，从而提高数据的可用性。
请考虑 Web 应用程序。 这可以通过以下方式受益于对等复制：
目录查询和其他读取分散在多个节点上。 这使性能随着读取量增加而保持稳定。
如果系统中的某个节点发生故障，则应用程序层可以将该节点的写入重定向到另一个节点。 这将保持可用性。
如果某个节点需要维护或整个系统需要升级，则可以使每个节点脱机，并重新添加到系统，而不会影响应用程序的可用性。
尽管对等复制允许横向扩展读取操作，但拓扑的写入性能与单节点相似。 这是因为最终所有插入、更新和删除都传播到所有节点。 复制可识别何时将更改应用到给定节点，并防止更改多次循环遍历节点。 我们强烈建议每一行的写入操作仅在一个节点上进行，原因如下：
如果一行在多个节点上被修改，当该行被传播到其他节点时，可能会导致冲突，甚至导致更新被覆盖或丢失。
复制更改时，始终存在一些延迟。 对于需要立即看到最新更改的应用程序，跨多个节点对应用程序进行动态负载均衡可能会有问题。
对等复制包含一个选项，可以在对等拓扑中启用冲突检测。 此选项有助于防止导致未检测到冲突的问题，包括不一致的应用程序行为和丢失的更新。 通过启用此选项，默认情况下，发生冲突的更改被视为导致分发代理失败的关键错误。 发生冲突时，拓扑保持不一致状态，直到手动解决冲突，并且数据在整个拓扑中保持一致。 有关详细信息，请参阅 对等复制中的冲突检测。
注释
若要避免潜在的数据不一致，请确保避免对等拓扑中的冲突，即使启用了冲突检测。 为了确保对特定行的写入操作仅在一个节点上执行，访问和更改数据的应用程序必须对插入、更新和删除操作进行分区。 此分区可确保对源自一个节点的给定行的修改与拓扑中的所有其他节点同步，然后再由其他节点修改该行。 如果应用程序需要复杂的冲突检测和解决功能，请使用合并复制。 有关详细信息，请参阅合并复制并检测和解决合并复制冲突。
对等网络拓扑
以下场景展示了对等复制的典型用途。
具有两个参与数据库的拓扑
上述两个图示都显示了两个参与的数据库，用户流量通过应用程序服务器定向到数据库。 此配置可用于各种应用程序，从网站到工作组应用程序，并提供以下优势：
改进了读取性能，因为读取分散在两个服务器上。
如果需要维护或在一个节点上发生故障，则可用性更高。
在这两个图示中，读取活动在参与的数据库之间负载均衡，但更新的处理方式不同：
左侧是两个服务器之间的更新分区。 例如，如果数据库包含产品目录，则可以将自定义应用程序直接更新到以 A 到 M 开头的产品名称的节点 A ，并将从 N 到 Z 开始的产品名称直接更新到节点 B 。然后，更新将复制到另一个节点。
在右侧，所有更新都定向到节点 B。在此处，更新将复制到节点 A。如果 B 处于脱机状态（例如维护），则应用程序服务器可以将所有活动定向到 A。当 B 重新联机时，更新可以流向其中，应用程序服务器可以将所有更新移回 B 或继续将它们定向到 A。
对等复制可以支持这两种方法，但右侧的中心更新示例也经常与标准事务复制搭配使用。
具有三个或多个参与数据库的拓扑
上图显示了三个参与的数据库，这些数据库为全球软件支持组织提供数据，并在洛杉矶、伦敦和台北设有办事处。 每个办公室的支持工程师都会拨打客户电话，并输入和更新有关每个客户呼叫的信息。 三个办公室的时区相隔八个小时，因此工作日没有重叠。 随着台北办公室的关闭，伦敦办公室开始新的一天的工作。 如果在一个办公室即将关闭时呼叫仍在进行，则呼叫会转接到下一个即将开放的办公室的代表。
每个位置都有一个数据库和一个应用程序服务器，支持工程师在输入和更新有关客户呼叫的信息时使用。 拓扑按时间进行分区。 因此，更新仅在当前为业务打开的节点上发生，然后更新将流向其他参与的数据库。 此拓扑具有以下优势：
独立而不隔离：每个办公室可以独立插入、更新或删除数据，但也可以共享数据，因为它被复制到所有其他参与的数据库。
一旦发生故障或需要维护参与的一个或多个数据库时，系统的可用性会更高。
上图显示了向三节点拓扑添加节点。 出于以下原因，可以在此方案中添加节点：
因为另一个办公室成立了。
若要提供更高的可用性，以支持维护，或者在发生磁盘故障或其他主要故障时提高容错能力。
请注意，在三节点和四节点拓扑中，所有数据库都发布并订阅所有其他数据库。 如果维护需求或一个或多个节点发生故障，这可提供最大可用性。 添加节点时，必须根据性能和部署和管理的复杂性平衡可用性和可伸缩性需求。
配置对等复制
配置复制对等拓扑与配置一系列的标准事务性发布和订阅非常相似。 以下主题中所述的步骤显示了三节点系统的配置，类似于上图中左侧所示的配置，其中显示了对等拓扑。
使用对等复制技术时需要考虑的因素或注意事项
本部分提供了在使用对等复制时要考虑的信息和准则。
一般注意事项
对等复制仅在 SQL Server 的企业版本中可用。
参与对等复制的所有数据库应包含相同的架构和数据：
对象名称、对象架构和发布名称应相同。
出版物必须允许架构更改被复制。 这是发布属性replicate_ddl的1设置，也是默认设置。有关详细信息，请参阅对发布数据库进行架构更改。
不支持行和列筛选。
建议每个节点使用自己的分发数据库。 这样就消除了出现单一故障点的可能性。
表和其他对象不能包含在单个发布数据库中的多个对等发布中。
必须在创建任何订阅之前为对等复制启用发布。
必须使用备份或 “仅复制支持” 选项初始化订阅。 有关详细信息，请参阅 在不使用快照的情况下初始化事务订阅。
不建议使用标识列。 使用标识时，必须手动管理分配给每个参与数据库的表的范围。 有关详细信息，请参阅 复制标识列中的“为手动标识范围管理分配范围”部分。
功能限制
对等复制支持事务复制的核心功能，但不支持以下选项：
使用快照初始化和重新初始化。
行和列筛选器。
时间戳列。
非 SQL Server 发布服务器和订阅服务器。
立即更新和排队更新订阅。
匿名订阅。
部分订阅。
可附加订阅和可转换订阅。 （这两个选项已在 SQL Server 2005 中弃用。
共享分发代理。
分发代理参数 -SubscriptionStreams 和日志读取器代理参数 -MaxCmdsInTran。
文章属性 @destination_owner 和 @destination_table。
对等事务复制不支持创建对等发布的单向事务订阅
以下属性有特殊注意事项：
发布属性 @allow_initialize_from_backup 需要一个值
true。文章属性 @replicate_ddl 需要
true的值, @identityrangemanagementoption 需要manual的值, 并且 @status 需要设置选项 24。文章属性@ins_cmd、@del_cmd和@upd_cmd的值不能设置为
SQL。订阅属性 @sync_type 需要值为
none或automatic。
维护注意事项
以下作要求系统静止。 这意味着停止所有节点上已发布表上的活动，并确保每个节点已收到来自所有其他节点的所有更改。
将 SQL Server 2005 节点添加到现有拓扑
向现有出版物添加文章
进行架构更改
从备份还原节点
有关详细信息，请参阅使复制拓扑保持静止状态（复制 Transact-SQL 编程） 和 管理对等拓扑结构（复制 Transact-SQL 编程）。
如果将新节点添加到对等拓扑，则仅应从添加新节点后创建的备份还原。
不能在对等拓扑中重新初始化订阅。 如果必须确保节点具有新的数据副本，请在节点上还原备份。