事务复制
在初始化订阅后(可通过快照初始化，或者由备份初始化，请参阅：http://www.sql-server-performance.com/2012/replication-without-creating-snapshot/)，由发布服务器上将需要被复制的部分的日志标记为复制.由分发服务器的log reader agent来读取发布服务器上这部分日志,当分发服务器将所有的日志传递给订阅服务器，则发布服务器上的日志就可以清空了
通过原理不难看出,每个数据库只能有一个log reader agent,因此数据库中发布内容过多，或者重复发布，则会产生严重的性能问题。此外log reader agent需要读取所有的日志，不会有任何奇迹发生来跳过那些没有被标记为复制的日志.因此当对复制的文章进行了筛选的话，会影响性能(这里可不像索引,设置了筛选条件能够提高查询速度)。
性能因素取决于很多地方,发布服务器的速度，更改频率，分发服务器的速度等等。
通常可以用于做实时报表，虽然会有些许延迟，但效果非常好。
合并复制
合并复制可以实现数据的多处更新，当更新冲突时，可以设置规则，比如北京和上海的服务器，我可以设置北京的服务器永远赢。
Peer-To-Peer复制
P2P复制是基于事务日志之上的一种复制类型，他允许每个节点都成为对等的实体。因此可以非常好的用于HA和负载均衡，即使某一个节点宕机，完全不会影响其它节点的可用性。
自SQL Server 2012以来，PeerToPeer复制已经成为了一种单独的发布类型。
一个Peer-To-Peer的简单例子如图2所示。
▲图2.对等复制
从图2中可以看出，节点A、B、C、D分别对同一份数据保存相同的副本，并且每个节点上都可以进行读写操作。我们可以假设每个节点都是在不同的地理位置，因此假如说节点A宕机，则可以直接将应用程序连接字符串重定向到其它节点，实现了高可用性。从图2中还可以看出，对于任一节点我们都可以进行读写操作，因此实现了负载均衡的效果。此外，NodeB进一步将数据发布到只读服务器上，进一步实现了读写分离。
因此，这种方式具有极大的灵活性，和其它高可用性技术结合可以实现多种数据库拓扑。
在SQL Server 2008之后的版本，当遇见数据更新冲突时，可以通过冲突查看器进行查看并解决冲突，还可以在数据更新冲突出现后，进行报警。
为什么选用复制
每一种高可用性技术都有其自身的优点和缺陷，如果某种技术相较与其它技术只有有点，没有缺陷，那”其它技术“一定会被淘汰。
相比较其它高可用性技术而言，复制有如下好处：
•复制是对象级别，您可以仅复制您需要复制的内容
•复制可以工作在简单恢复模式下。
•您可以拥有无限多个订阅(日志传送也可以实现，但要考虑到网络带宽和性能问题，通常来说，订阅数量稍微多一点就要考虑请求订阅，将Distribution Agent的负载OffLoad到订阅服务器)
•复制允许在高可用的另一端(也就是用于冗余的一端)进行更新，没有其它高可用性技术可以做到这一点
•在故障转移的时候，不需要Redo或Rollback日志，只需要将应用重定向到仍然在线的节点
但同样，复制也有其自身局限性，比如：
• 复制建立、调错都相对比较复杂
• 复制是对象级别(没错，这一点既可以是优势，同样也是劣势，基于不同的场景)
• 分发库上不能建立镜像，因此分发库有可能成为Single-Point-Of-Failure
• 复制很容易影响发布服务器的性能
• 不能进行热备，这意味着就不能进行故障检测和故障排除
• 对于复制来说，故障转移容易，想转移回来就比较麻烦，因此这种情况下可以考虑P2P复制
但不得不说，复制的确是非常的强大，套用京东“首席DB Replicationor(自造词)”陈璟的话说就是：“想复制什么复制什么，想复制多远复制多远，想怎么复制就怎么复制，想复制的多复杂就多复杂”，同时结合其它技术可以实现很多有意思的拓扑，比如图3(同样来自陈璟同学)。
▲图3.利用复制分发写数据，同时实现高可用性
通过图3这种方式，分发了写压力，同时相同的读库实现了负载均衡以及高可用性，当某个读库宕机后，会有足够的时间进行修复。
小结
本篇文章对复制在高可用架构的角色做了一个概述。复制作为高可用性中最为灵活的技术，与其它技术结合，可以实现很多有意思的拓扑。
