简介

     本系列文章的对复制是什么做了一个概述。本篇文章根据发布服务器，分发服务器和订阅服务器的组织方式和复制类型来讲述常用复制的几种模式。

 

模式的选择

    选择复制的模式取决于多个方面。首先需要考虑具体的业务需求，在此之后还需要考虑硬件和网络的限制。对于业务需求来说考虑的角度可以分为两个部分：自治和延时。自治是指”数据不被影响的程度”,比如说一个业务场景：公司的总部在北京，发布服务器和分发服务器全在总部，各个地区的分部有订阅服务器，使用快照复制来接收推送订阅总部每个月一次的公司员工通讯录。在这个业务场景中，订阅服务器仅仅是接收发布服务器发布的通讯录信息，对于这些信息的修改是不会回传给总部服务器的，这个业务场景的自治程度就是非常低的。而对于延时来说,就是”在发布服务器上的数据修改应用到订阅服务器上的时间”,比如还是上面那个例子，每次订阅服务器的订阅周期是一个月，在此期间总部的通讯录可能经过了多次修改，但一个月以后才会同步到订阅服务器，那么这种场景的延时是非常高的。

    其次就是硬件和网络的限制，比如将发布服务器和分发服务器设置在一台服务器上，在现有的情况下CPU是否能够承受这些负担？或是使用快照复制，发布服务器和订阅服务器之间的网络宽带是否能够承受在一定发布周期内的数据量传输？

    在简单了解了模式选择的标准后，下面我们来看常用的几种复制模式。

 

以发布服务器为中心的复制模式

    这种模式多个订阅服务器以一个发布服务器为中心进行订阅，如图1所示。

   

    图1.多个订阅服务器以发布服务器为中心的模式

 

    这种模式也是复制模式中最简单的模式，这种模式可以使用快照发布和事务发布。不难看出，这种情景的自治性是比较低的，因此这种模式适用于以下几种业务场景。

•     订阅服务器用于报表生成.
•     发布服务器用来发布类似前文所说的员工通讯录，产品资料等主（Master)信息
•     使用事务发布，使得订阅服务器承担部分负载
•     在发布服务器Down了以后，作为紧急备用服务器

 

    当然，这种模式的缺陷也是显而易见的。

•      首先是发布服务器和分发服务器在同一台服务器上对CPU和内存的消耗服务器硬件是否能够承受是一个问题
•      在OLTP环境中如果每天要修改的数据量过大，比如超过10%，那么需要传送到的订阅服务器的数据量过大也是不得不考虑的一个问题

 

以发布服务器和分发服务器为中心的复制模式

    这种模式其实和上一种模式区别不大，只是分离了发布服务器和分发服务器，如图2所示。

   

    图2.以发布服务器和分发服务器为中心的复制模式

 

    这种模式是将分发任务对CPU,内存和网络带来的负载转移到另一台分发服务器了。从而减轻发布服务器的压力和支持更多的订阅服务器。此外，我们知道一个分发服务器支持多个发布服务器的，因此也可以多个发布服务器使用一个分发服务器。

    这种模式还有一个好处是可以将分发服务器放到DMZ区域和订阅服务器连接以避免发布服务器直接暴漏在外网。

    当然了，这种模式最重要的一点是发布服务器和分发服务器一定要有可靠的网络连接，这种模式和图1提到的第一种模式适用的业务场景基本一致。

 

发布-订阅的复制模式

    这种模式使得发布服务器也是订阅服务器，如图3所示。

   

     图3.发布-订阅复制模式

 

    这种模式适用于服务器A和服务器B的网络非常昂贵但服务器B和各个订阅服务器的网络成本很低的情况。比如，公司的总部在北京，服务器A在北京，服务器B是上海分公司的，各个订阅服务器通过局域网和服务器B进行连接。在这个例子中，服务器A和服务器B通过VPN进行连接，这个费用是相当昂贵的，而服务器B和各个订阅服务器通过局域网连接的成本可以忽略。

 

以订阅服务器为中心的复制模式

    这种模式以订阅服务器为中心，如图4所示。

   

    图4.以订阅服务器为中心复制模式

 

    这种模式适用的场景比如：各个区域将各自的业务数据汇总到总部这种类型的业务场景。

 

多个发布服务器和多个订阅服务器的复制模式

    这种模式适用于数据对等的环境,一个简化的版本如图5所示。

   

    图5.多个发布服务器和多个订阅服务器

 

    这种模式非常适合业务数据对等的环境，比如说这类业务场景，一个销售公司在同一个城市有3个分店，这三个分店之间是对等的，它们之间通过复制来同步库存。使得每个店都可以了解其它分店的库存情况。这类业务场景适合使用多个发布服务器和多个订阅服务器的复制模式。

 

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

    这种模式非常类似图1中所说的模式，但这种模式允许订阅服务器更新数据。如图6所示。

   

    图6.具有可更新订阅事务的发布模式

 

    在这种模式下，比如订阅服务器B更新了数据，这个数据会传送回发布服务器，如果发布服务器接收了这个数据，那么这个数据会同时同步到其它订阅服务器。

 

合并发布模式

    合并发布模式适用于所有服务器共享一部分数据的场景，如图7所示。

   

    图7.合并发布模式

 

    这种模式下，每个服务器并不是互相订阅，而是互相共享。这种模式同样适用于图5所述的业务模式。

 

总结

    本文讲述了复制的几种模式以及它们的所适用的一些场景，很多更复杂的复制模式大多都是对以上几种模式的组合或者拓展。理解上述简单的复制模式是理解复杂复制模式的基础。