简介

　　本篇文章根据发布服务器，分发服务器和订阅服务器的组织方式和复制类型来讲述常用复制的几种模式。

　　模式的选择

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

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

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

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

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

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

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

　　● 订阅服务器用于报表生成.

　　● 发布服务器用来发布类似前文所说的员工通讯录，产品资料等主（Master)信息

　　● 使用事务发布，使得订阅服务器承担部分负载

　　● 在发布服务器Down了以后，作为紧急备用服务器

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

　　● 首先是发布服务器和分发服务器在同一台服务器上对CPU和内存的消耗服务器硬件是否能够承受是一个问题

　　● 在OLTP环境中如果每天要修改的数据量过大，比如超过10%，那么需要传送到的订阅服务器的数据量过大也是不得不考虑的一个问题

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

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

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

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

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

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