前提：

发布订阅只能是同一个内网的机器上才能使用，其实这个可以用配置管理器的别名功能设置之后就可以了，外网的也能通过这样的方式来搞。

配置过程参考老D的文章：

原理图：

单向：

双向：

参考：

SQL Server发布订阅功能测试：

（我发觉这个功能很不行，为什么不行，我下面其中一台设置错误了就要全部重来，那么如果我下面有几百台机器，怎么重来？）

1、采用事务发布/快照发布进行发布订阅机制只能是读写分离的方案，也就是说A发布B订阅，只能是操作A的数据，B是同步过来，即使在B新增后，A不会新增。（也就是说单向同步，不是双向的）

1.1、采用合并复制进行发布订阅是可以A发布B订阅，A操作B得到最新数据，B操作A得到最新数据。（也就是说双向），（自增ID）这个功能测试后发现两者的数据是经过处理的，比如A的之间为100，B的最大值为9，下一条是10，那么同步过来之后，A的这台数据里面就不是100了，而是10；也就说数据会经过处理。这个功能会在每张表上增加一个rowid的列，这个列是GUID，估计是用于双向同步的作用而设计的。

2、2008新建订阅时，如果输入错误，是找不到这个订阅的，只能删除发布，再来重新搞。

3、2008上如果数据库连接端口更改，不是1433默认的之后，那么两端同步的时候都会不行，即使在配置管理器上新建了别名，也是不行的。（最后发现是可以的，如果新建了别名之后，要把原来的发布删除再重建）

4、同步的时间间隔大概是1分钟左右

操作说明：

一、基本的订阅发布过程配置

事务发布操作省略，配置过程参考老D的文章：

合并发布：

 

注意：这里是本机sa登录密码

 

订阅：

注意：这里是用来订阅的数据库

 

注意：这里是本机sa登录密码

 

 

最后查看效果：

 

 

发布类型官方说明：

快照发布:

发布服务器按预定的时间间隔向订阅服务器发送已发布数据的快照。

事务发布:

在订阅服务器收到已发布数据的初始快照后，发布服务器将事务流式传输到订阅服务器。

具有可更新订阅的事务发布:

在 SQL Server 订阅服务器收到已发布数据的初始快照后，发布服务器将事务流式传输到订阅服务器。来自订阅服务器的事务被应用于发布服务器。

合并发布:

在订阅服务器收到已发布数据的初始快照后，发布服务器和订阅服务器可以独立更新已发布数据。更改会定期合并。Microsoft SQL Server Compact Edition 只能订阅合并发布。

通俗说明：

快照发布：

发行端依排程定时将快照集传送到订阅端，缺点是数据量很大，时间较长。

这个只能是单向发布。

事务发布：

发行端第一次与订阅端同步数据完后，依排程定时传送日志资料，供订阅端重做。优点是数据量较小，适合长期同步数据所用。

这个只能是单向发布。

合并复制：

合并复制可以实现数据的多处更新，当更新冲突时，可以设置规则，比如北京和上海的服务器，我可以设置北京的服务器永远赢。

也就是说双向发布。

这里参考这位SQL MVP的文章：

深入说明：

参考这本书【Pro SQL Server 2005 Replication】