2. 复制拓扑与发布订阅模型

SQL Server 复制在物理上由三类服务器角色协作完成：发布服务器（Publisher）、分发服务器（Distributor）和订阅服务器（Subscriber）。理解这三者的职责边界，以及订阅采用推送还是请求、分发采用集中还是远程，是设计复制拓扑的第一步。拓扑选错，后期往往不是改几个参数能补救的，而需要重建发布与订阅。

三类角色的职责划分

发布服务器是数据的源头。它维护被复制的对象（表、视图、存储过程等），把哪些对象、哪些列、哪些行纳入复制范围定义为“项目（Article）”，再把一组项目组织成“发布（Publication）”。发布服务器还负责记录事务日志中需要传播的变更，供日志读取代理或快照代理采集。

分发服务器是复制的中转与调度中心。它持有分发数据库（默认为 distribution），用于暂存待传播的事务命令或快照数据，并运行分发代理把数据投递到订阅端。分发服务器同时承担元数据管理、代理作业调度和冲突/延迟监控的职责。可以说，分发数据库是复制的“缓冲区”和“账本”。

订阅服务器是数据的接收方。它保存订阅数据库，通过订阅（Subscription）与某个发布建立对应关系。订阅服务器不参与变更的产生，只负责接收并应用变更（事务复制）或接收整份数据（快照复制）。

三者的关系可以概括为：发布服务器产生变更，分发服务器缓存并转发变更，订阅服务器应用变更。下面这张图展示了集中分发拓扑下三者的连接关系与数据流向。

推送订阅与请求订阅的差异

订阅的“推”与“拉”，本质区别在于分发代理运行在哪里，以及谁发起同步动作。

推送订阅（Push Subscription）由分发服务器主动发起。分发代理作业运行在分发服务器上，按调度周期把变更推送到订阅端。它的优点是集中管理：管理员在分发端就能看到所有订阅的同步状态，新增订阅端时无需在订阅端部署代理作业。代价是分发服务器的 CPU、内存和网络出口压力随订阅数量线性增长。推送订阅适合订阅端数量较多、由同一团队统一运维的场景，例如总部向多个门店分发商品主数据。

请求订阅（Pull Subscription）由订阅服务器主动发起。分发代理作业运行在订阅服务器上，订阅端按自己的调度去分发数据库拉取变更。它的优点是分散负载：每个订阅端自行承担同步开销，分发端只负责写入分发数据库。代价是订阅端必须能访问分发服务器，且每个订阅端都要单独配置和维护代理作业。请求订阅适合订阅端数量少、地理位置分散、网络条件各异或需要订阅端自主控制同步时机的场景，例如多个分支机构各自按本地业务窗口拉取数据。

选择时可以用一个简单判断：如果订阅端多且集中管控，选推送；如果订阅端少且分散自治，选请求。两者并非互斥，同一个发布下可以混合使用。

集中分发与远程分发的选型

分发服务器的部署位置决定了拓扑形态。

集中分发（Central Distributor）指发布服务器与分发服务器位于同一台 SQL Server 实例。这是默认且最常见的部署方式。它的优点是配置简单、发布到分发的本地事务开销小、故障排查路径短。缺点是发布服务器的负载会叠加分发压力，当发布数量多、订阅端多时，单实例容易成为瓶颈。

远程分发（Remote Distributor）指分发服务器独立于发布服务器，部署在另一台实例上。它的优点是负载分离：发布服务器专注事务处理，分发服务器专注缓存与投递，二者可分别扩容。缺点是跨实例通信增加网络开销，且分发服务器一旦故障会影响所有发布。远程分发适合发布服务器本身负载已较高、或需要为多个发布服务器统一提供分发服务的场景。

选型时可参考以下判断依据：

一个可参考的拓扑配置示例

假设某企业有 1 台总部数据库服务器 SRV-PUB、1 台独立分发服务器 SRV-DIST、3 台门店订阅服务器 SRV-SUB01~03。总部希望统一管控同步，门店不承担代理运维。可设计为：

发布服务器：SRV-PUB
分发服务器：SRV-DIST（远程分发）
分发数据库：distribution
发布：Pub_Product（事务复制）
订阅：Push_Sub_01 / Push_Sub_02 / Push_Sub_03（推送订阅）
分发代理运行位置：SRV-DIST
同步周期：每 30 秒

配置完成后，可在分发服务器上通过 sp_replmonitorhelpsubscription 查看各订阅的同步状态与延迟。若某门店订阅长期处于“正在同步”或延迟持续增大，应优先检查该门店到分发服务器的网络质量，而不是直接调整发布端参数。判断拓扑是否合理的核心指标是：分发数据库的待分发命令数是否稳定、各订阅端延迟是否在业务可接受范围内、分发服务器资源是否留有冗余。