前言：
SQLServer的复制技术最少从SQLServer2000时代已经出现，当初是为了分布式计算，不是为了高可用。但是到了今天，复制也成为了一种高可用技术，并且被广泛使用。很多问题都通过复制得以解决。
复制组件：
复制说白了就是一种发布/订阅模式，但是这种模式并不容易理解。下面介绍一下复制技术的一些概念。提醒一下，这里的复制在英文中不是COPY，而是Replication。它包含三个组件：发布者、分发者和订阅者。三者缺一不可，并且均以在发布和订阅中定义的项目为操作单元。
- 项目（Article）：是用于复制中的可配置的最小操作单元，它可以是一个单独的SQL Server对象，也可以是一个对象中的一个自己。这些对象通常是表、视图、存储过程等。还可以是表中的部分行或者列的集合。在非严格环境下，可以把多个对象定义为一个项目来发布和订阅。
- 发布（Publication）：注意这里是名词，是一组项目的逻辑集合，每个发布可以包含一个或多个项目。发布中的配置项会影响它包含的所有项目，通过这种方式，可以减少管理对象所带来的影响。其中最重要的配置项就是复制类型。
- 发布者（Publisher）：运行发布的实例，发布者监控所有项目的变更，并且告知这些信息给分发者。
- 分发者（Distributor）：是一个跟踪所有订阅和发布活动变更的实例，在复制过程中充当中间人，绝大部分的变更会存储在一个分发数据库（存在于系统数据库目录下，库名为distribution），可以是单独的实例，也可以运行在订阅服务器或者发布服务器上，但是通常会运行在发布者所在的机器上。
- 订阅者（Subscriber）：同样是一个实例，用于通过分发者，接收所有发布者传过来的信息。
- 订阅（Subscription）：与发布配对，用于决定哪个服务器（订阅者）接收从发布中传输过来的信息。每个订阅都会创建一个发布者和订阅者之间的连接。复制技术存在两种订阅方式，推送（push ）和提取（pull）。对于推送订阅，分发者直接在订阅数据库更新数据，对于提取订阅，订阅者会周期性询问分发者是否有新变更可用，如果有，就会自行更新自己的数据。
图中上半部分是分发者和发布者均在一个实例上的情况，下半部分是三者都分开实例。
复制类型：
粗略来说，SQLServer有三种主要的复制类型：快照复制、合并复制和事务复制。这里先简单介绍，后续会详细并演示每一种类型。
快照复制：
每次运行时，会创建被发布对象的完整副本及其数据，并使用SQLServer的BCP工具把每个表的内容写入到快照文件夹中。这类快照文件夹是由分发者创建的共享文件夹。复制过程中的所有参与者都必须能够访问快照文件夹。
每次快照复制开始运行后，分发者会从发布中抓取已配置的发布项的当前快照，并传送给订阅者，然后应用到订阅数据库中，当应用新快照时，订阅数据库上的项目会被删除并按新快照的内容重建，这个过程只会在每次快照复制启动时执行一次，发布和订阅端之间没有持续的数据流，并且这个过程是高带宽和存储开销的操作。
默认情况下，其他类型的复制会在初始化时通过分发者，通过快照来同步所有的订阅项。这种类型的复制最适合用于相对静态的数据环境。
事务复制：
基于事务的一种复制类型，每个在发布项中的已提交的事务都会被扫描，并通过分发者传输到订阅端。这个扫描操作是由日志读取器代理（log reader agent）通过读取发布数据库中的事务日志完成。如果已发布项中有修改，会把修改记录在分发者的分发数据库中。然后从分发数据库上，按照当前的订阅类型，应用到订阅者中。
事务复制可以接近实时同步，并只占用少量的发布者空间。同时，这种类型的复制可以配置成数据双向移动，但是事务复制的最初设计是仅仅用于单向的。
合并复制：
最初的设计是用于允许修改发生在发布者和订阅者上。同时，合并复制在订阅者不能持续连到发布者，可能隔天连一次这种情景下也很有用。这种情景下，可以每天晚上同步，但是当一个数据被同时来自于不同发布者的数据所修改时，就会产生冲突。可以通过一些配置来解决。
