如何拓扑

　　在此，我们最主要的是要确定选择使用哪种复制拓扑。选择错误的拓扑将带来非常令人不满意的结果。

　　当需要一个临时的数据下发时，我们可以使用快照复制。因为每次快照下发时，所有的数据都是一次性移动的，但是它需要花费大量的带宽。只有在需要复制的数据变化远远超过了初始数据集的规模才在缓慢的WAN上使用快照复制。换言之，如果大部分的数据都在不断地更新，那么选择使用快照技术是非常正确的。如果并非如此，那么就不能选择它。

　　当需要在发行端和订阅端之间进行传输时，就应该选择合并复制。当有多个订阅端时，数据变化会及时地在网络上从发行端复制到所有的订阅端。

　　事务技术可能是复制最常见的形式。它是用来在几乎实时地（或按照调度）将数据变化传输到一个或多个订阅端。事务复制最常用于服务器之间的实时传输。

　　不管我们使用哪种SQL Server复制拓扑，订阅端之间都是完全独立的。订阅端可以因为多种原因而落后，包括网络拥挤、磁盘I/O拥挤以及用户进程锁定和阻塞。由于订阅端彼此都是独立的，因此，一个订阅端的速度下降并不影响其他的订阅端。

　　复制代理

　　数据是由复制代理传输的，其中每个发布都有几个复制代理需要创建。快照代理可以用在三种复制拓扑上。当复制创建后，就会得到物件快照并被上传到每个订阅端。当使用合并复制或事务复制时，将会有一个日志读取器代理在分发端上运行并捕捉事务日志的变化。然后这些变化会被记录到发行数据库上。

　　当使用事务复制时，数据变化将从发行数据库上读取并通过发行代理应用到订阅端上。当使用合并复制时，数据变化通过合并代理从发行数据库上读取。合并代理又将从订阅端上获取数据变化并上传到发行端以便分配到其他订阅端上。

　　当创建订阅时，我们有两个选项用于创建每个订阅端。我们可以使用发送订阅或请求订阅。当分配代理运行在发行数据库的服务器上工作时就是发送订阅。而当请求代理运行在订阅数据库的服务器上时就是请求订阅。

　　发送订阅的优点是分配代理集中在分发端上。这就能够限制管理开销同时保持订阅端的分配（或合并）代理低负载。请求订阅的优点是分配代理的工作量分散到所有订阅端上。当分配数据库位于同一台服务器或实例上作为发行端时，建议使用请求订阅。