呼叫中心的容灾方法、装置、设备及存储介质与流程

本发明涉及呼叫中心技术领域，尤其涉及一种呼叫中心的容灾方法、装置、设备及存储介质。

背景技术：

呼叫中心，又称客户服务中心，起源于20世纪30年代，最初是把用户的呼叫转移到应答台或者专家处。此后，随着要转移的呼叫和应答增多，开始建立起交互式语音应答系统，这种系统能把客户部分常见问题的应答实现由机器“自动话务员”来应答和处理。传统意义上的呼叫中心，是指以电话接人为主的呼叫响应中心，为客户提供各种电话响应服务。

目前，各大企业推出的呼叫中心系统，其呼入电话的排队派工操作是通过freeswitch(一个电话的软交换解决方案)的callcenter(呼叫中心)模块来处理的。然而callcenter模块在一个呼叫中心系统只能启动一个实例，因而当callcenter模块本身或者callcenter模块所在的服务器发生异常时，便会导致整个呼叫中心系统呼入电话的排队派工全部失败，从而给企业造成严重影响。

所以，亟需提供一种呼叫中心的容灾方法，以降低业务风险，从而保证呼叫中心系统的稳定性和可靠性。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

技术实现要素：

本发明的主要目的在于提供一种呼叫中心的容灾方法、装置、设备及存储介质，旨在解决现有技术中呼叫中心系统稳定性差，可靠性低的技术问题。

为实现上述目的，本发明提供了一种呼叫中心的容灾方法，所述方法包括:

启动主呼叫中心，采集所述主呼叫中心运行过程中产生的日志信息；

对所述日志信息进行实时分析，判断所述主呼叫中心的运行状态是否正常；

若所述主呼叫中心运行状态正常，则在预先分配的虚拟地址接收到呼叫业务时，根据第一对应关系，将所述呼叫业务通过所述主呼叫中心的物理地址转接到所述主呼叫中心，所述第一对应关系为所述虚拟地址与所述主呼叫中心的物理地址之间的对应关系；

若所述主呼叫中心运行状态异常，则启动备份呼叫中心，并在所述虚拟地址接收到所述呼叫业务时，根据第二对应关系，将所述呼叫业务通过所述备份呼叫中心的物理地址转接到所述备份呼叫中心，所述第二对应关系为所述虚拟地址与所述备份呼叫中心的物理地址之间的对应关系。

优选地，所述启动主呼叫中心的步骤之前，所述方法还包括：

根据呼叫中心业务需求，搭建第一呼叫中心和第二呼叫中心；

将所述第一呼叫中心和所述第二呼叫中心的任意一个指定为所述主呼叫中心，另一个指定为所述备份呼叫中心。

优选地，所述将所述第一呼叫中心和所述第二呼叫中心的任意一个指定为所述主呼叫中心，另一个指定为所述备份呼叫中心的步骤，包括：

根据预设的监控指标，分时段采集所述第一呼叫中心提供的第一监控指标数据和所述第二呼叫中心提供的第二监控指标数据；

分别对各时段的第一监控指标数据和各时段的第二监控指标数据进行分析，得到所述第一呼叫中心对应的监控指标变化率和所述第二呼叫中心对应的监控指标变化率；

根据预设的主呼叫中心选取规则，将监控指标变化率符合所述主呼叫中心选取规则的所述第一呼叫中心指定为所述主呼叫中心，所述第二呼叫中心指定为所述备份呼叫中心；或者，将监控指标变化率符合所述主呼叫中心选取规则的所述第二呼叫中心指定为所述主呼叫中心，将所述第一呼叫中心指定为所述备份呼叫中心。

优选地，所述分别对各时段的第一监控指标数据和各时段的第二监控指标数据进行分析，得到所述第一呼叫中心对应的监控指标变化率和所述第二呼叫中心对应的监控指标变化率的步骤，包括：

基于预设的分析模型，分别对各时段的第一监控指标数据和各时段的第二监控指标数据进行分析，得到所述第一呼叫中心对应的监控指标变化率和所述第二呼叫中心对应的监控指标变化率。

优选地，所述基于预设的分析模型，分别对各时段的第一监控指标数据和各时段的第二监控指标数据进行分析的步骤之前，所述方法还包括：

基于深度机器学习法，构建所述分析模型；

其中，所述基于深度机器学习法，构建所述分析模型的步骤，包括：

根据样本数据构建第一训练模型；

根据预设的分层标准，将所述第一训练模型中各隐藏层的初始网络层拆分为至少两个子网络层；

采用自下上升的非监督训练方式，以与所述第一训练模型中输入层相连的隐藏层为起点，与所述第一训练模型中输出层相连的隐藏层为终点，依次对所述第一训练模型中各隐藏层中的子网络层进行训练，得到第二训练模型；

采用自顶向下的监督训练方式，以与所述第二训练模型中输出层相连的隐藏层为起点，与所述第二训练模型中输入层相连的隐藏层为终点，依次对所述第二训练模型中各隐藏层中的子网络层进行训练，得到所述分析模型。

优选地，所述启动备份呼叫中心的步骤之后，所述方法还包括：

监控所述主呼叫中心的运行状态是否恢复正常；

若所述主呼叫中心的运行状态恢复正常，则向所述备份呼叫中心发送停止运行指令，以使所述备份呼叫中心停止运行，并在所述备份呼叫中心停止运行后，重启所述主呼叫中心。

优选地，所述启动备份呼叫中心的步骤之后，所述方法还包括：

根据所述日志信息，生成预警信息；

根据预设的预警通知方式，将所述预警信息通知给所述主呼叫中心的管理人员。

此外，为实现上述目的，本发明还提出一种呼叫中心的容灾装置，所述装置包括：

日志信息采集模块，用于启动主呼叫中心，采集所述主呼叫中心运行过程中产生的日志信息；

日志信息分析模块，用于对所述日志信息进行实时分析，判断所述主呼叫中心的运行状态是否正常；

第一呼叫业务转接模块，用于在所述主呼叫中心运行状态正常，预先分配的虚拟地址接收到呼叫业务时，根据第一对应关系，将所述呼叫业务通过所述主呼叫中心的物理地址转接到所述主呼叫中心，所述第一对应关系为所述虚拟地址与所述主呼叫中心的物理地址之间的对应关系；

第二呼叫业务转接模块，用于在所述主呼叫中心运行状态异常时，启动备份呼叫中心，并在所述虚拟地址接收到所述呼叫业务时，根据第二对应关系，将所述呼叫业务通过所述备份呼叫中心的物理地址转接到所述备份呼叫中心，所述第二对应关系为所述虚拟地址与所述备份呼叫中心的物理地址之间的对应关系。

此外，为实现上述目的，本发明还提出一种呼叫中心的容灾设备，所述设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的呼叫中心的容灾程序，所述呼叫中心的容灾程序配置为实现如上文所述的呼叫中心的容灾方法的步骤。

此外，为实现上述目的，本发明还提出一种存储介质，所述存储介质上存储有呼叫中心的容灾程序，所述呼叫中心的容灾程序被处理器执行时实现如上文所述的呼叫中心的容灾方法的步骤。

本发明提供的呼叫中心的容灾方案，在判断主呼叫中心的运行状态是否正常的时候，具体是采用软件检测的方式，即在主呼叫中心启动后，通过实时采集主呼叫中心运行过程中产生的日志信息，然后基于对日志信息的分析，确定主呼叫中心的运行状态是否正常，当确定主呼叫中心的运行状态正常时，在有呼叫业务时，则直接由主呼叫中心处理；当确定主呼叫中心的运行状态异常时，则启动备份呼叫中心，由备份呼叫中心接管主呼叫中心处理的呼叫业务，通告这种方式，不仅可以检测到部署主呼叫中心的服务器是否发生异常，还可以检测到主呼叫中心的进程和端口是否发生异常，进而保证了呼叫中心系统能够稳定且可靠的为用户处理呼叫业务。

此外，本发明提供的呼叫中心的容灾方案，从始至终提供给用户的都是一个固定且唯一的虚拟地址，而主、备呼叫中心物理地址的切换是根据主、备呼叫中心的运行状态及预先构建的第一对应关系和第二对应关系实现的，因而切换过程用户是感知不到的，从而有效的保证了用户体验效果。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的呼叫中心的容灾设备的结构示意图；

图2为本发明呼叫中心的容灾方法第一实施例的流程示意图；

图3为本发明呼叫中心的容灾方法第二实施例的流程示意图；

图4为本发明呼叫中心的容灾装置第一实施例的结构框图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。

参照图1，图1为本发明实施例方案涉及的硬件运行环境的呼叫中心的容灾设备结构示意图。

如图1所示，该呼叫中心的容灾设备可以包括：处理器1001，例如中央处理器(centralprocessingunit，cpu)，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(display)、输入单元比如键盘(keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(wireless-fidelity，wi-fi)接口)。存储器1005可以是高速的随机存取存储器(randomaccessmemory，ram)存储器，也可以是稳定的非易失性存储器(non-volatilememory，nvm)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的结构并不构成对呼叫中心的容灾设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及呼叫中心的容灾程序。

在图1所示的呼叫中心的容灾设备中，网络接口1004主要用于与网络服务器进行数据通信；用户接口1003主要用于与用户进行数据交互；本发明呼叫中心的容灾设备中的处理器1001、存储器1005可以设置在呼叫中心的容灾设备中，所述呼叫中心的容灾设备通过处理器1001调用存储器1005中存储的呼叫中心的容灾程序，并执行本发明实施例提供的呼叫中心的容灾方法。

本发明实施例提供了一种呼叫中心的容灾方法，参照图2，图2为本发明一种呼叫中心的容灾方法第一实施例的流程示意图。

本实施例中，所述呼叫中心的容灾方法包括以下步骤：

步骤s10，启动主呼叫中心，采集所述主呼叫中心运行过程中产生的日志信息。

具体的说，本实施例提供的呼叫中心的容灾方法主要是应用于预先搭建的呼叫中心系统，在实际应用中，所述呼叫中心系统大致包括部署有主呼叫中心的服务器、部署有备份呼叫中心的服务器以及分别用于控制主呼叫中心的交换机，和用于控制备份呼叫中心的交换机。

相应地，上述步骤s10中所说的启动呼叫中心的操作，具体是由与部署有主呼叫中心的访问通信连接，用于控制主呼叫中心的交换机执行的。

此外，本实施例中所说的交换机，具体为基于虚拟路由冗余协议的交换机，在实际应用中，可以选用keepalived软件代替。

所谓，keepalived是一个类似于layer3，4&5交换机制的软件，也就是我们平时说的第3层、第4层和第5层交换。其作用主要是检测服务器的状态，并且整个检测过程是自动完成，不需要人工干涉的。

为了便于理解，以下举例说明：

比如说，在使用keepalived检测服务器的状态时，如果有一台服务器宕机，或工作出现故障，keepalived将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当被剔除的服务器工作正常后，keepalived又会自动将该服务器加入到服务器群中，并且这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。

此外，上述所说的虚拟路由冗余协议(virtualrouterredundancyprotocol，vrrp)，是由国际互联网工程任务组(theinternetengineeringtaskforce，ietf)提出的解决局域网中配置静态网关出现单点失效现象的路由协议，1998年已推出正式的rfc2338协议标准。vrrp广泛应用在边缘网络中，它的设计目标是支持特定情况下物联网协议地址(internetprotocoladdress，ip)数据流量失败转移不会引起混乱，允许主机使用单路由器，以及及时在实际第一跳路由器使用失败的情形下仍能够维护路由器间的连通性。

关于vrrp和keepalived的工作原理和使用方式，本领域的技术人员可以查看相关的技术文档获知，此处不再赘述。

此外，值得一提的是，在实际应用中，执行启动所述主呼叫中心的步骤之前，需要确定主呼叫中心和备份呼叫中心。

关于，确定主呼叫中心和备份呼叫中心的操作，大致可以如下所述：

首先，根据呼叫中心业务需求，搭建第一呼叫中心和第二呼叫中心。

然后，将所述第一呼叫中心和所述第二呼叫中心的任意一个指定为所述主呼叫中心，另一个指定为所述备份呼叫中心

为了便于理解，本实施例给出一种确定主呼叫中心和备份呼叫中心的具体实现方式，大致如下：

(1)根据预设的监控指标，分时段采集所述第一呼叫中心提供的第一监控指标数据和所述第二呼叫中心提供的第二监控指标数据。

具体的说，上述所说的监控指标，可以是指定网络链路中传输的数据流量、地址解析协议(addressresolutionprotocol，arp)、介质访问控制(mediaaccesscontrol或者mediumaccesscontrol，mac)地址等常见网络指标，以便根据这些网络指标确定第一呼叫中心和第二呼叫中心的网络状态是否稳定，并发处理能力是否良好。在实际应用中，监控指标的选取可以由本领域的技术人员根据需要设置，本案对此不做限制。

相应地，上述所说的第一监控指标数据，便是所述第一呼叫中心在运行过程中产生的与所述监控指标对应的数据；所述第二监控指标数据，便是所述第二呼叫中心在运行过程中产生的与所述监控指标对应的数据。

为了便于理解本实施例中所说的网络指标数据所表示的含义，以下举例说明：如果监控指标为arp，则第一监控指标数据即为第一呼叫中心在运行过程中提供的arp数量，第二监控指标数据即为第二呼叫中心在运行过程中提供的arp数量；如果监控指标为mac地址，则第一监控指标数据即为第一呼叫中心在运行过程中mac地址的漂移情况，第二监控指标数据即为第二呼叫中心在运行过程中mac地址的漂移情况。

通过上述描述不难发现，本实例中在从第一呼叫中心和第二呼叫中心采集预设的监控指标对应的第一监控指标数据和第二监控指标数据时，具体是分时段采集的，从而可以使得后续的分析是针对一个周期内所述监控指标对应的监控指标数据的变化情况进行分析，而并非仅仅对某一时间点的情况进行分析。因此，可以有效的排除瞬时异常的情况，尽可能的保证确定的主呼叫中心和备份呼叫中心的合理性。

(2)分别对各时段的第一监控指标数据和各时段的第二监控指标数据进行分析，得到所述第一呼叫中心对应的监控指标变化率和所述第二呼叫中心对应的监控指标变化率。

具体的说，在实际应用中，为了方便对各时段的第一监控指标数据和各时段的第二监控指标数据进行分析，以便快速准确的获得第一呼叫中心的监控指标变化率和第二呼叫中心的监控指标变化率，可以基于预设的分析模型，分别对各时段的第一监控指标数据和各时段的第二监控指标数据进行分析，得到所述第一呼叫中心对应的监控指标变化率和所述第二呼叫中心对应的监控指标变化率。

关于，构建分析模型的方式，在实际应用中可以基于深度机器学习法进行构建。

具体的说，本实施例中所说的深度学习法具体是采用无监督学习方式(如深度置信网(deepbeliefnets，dbns))和有监督学习方式(如卷积神经网络(convolutionalneuralnetworks，cnns))相结合的方式，来构建所述分析模型。

为了便于理解，以下针对基于深度机器学习法，构建所述分析模型的操作具体简要说明，具体步骤如下：

(2-1)，根据样本数据构建第一训练模型。

具体的说，构建的第一训练模型具体包括一个输入层、一个输出层和多个隐藏层。并且，多个隐藏层均位于输入层和输出层之间，各层之间采用全连接。

此外，为了保证训练结果的准确性，还可以在每层之前加入一个滤波器，用于滤出样本数据中的干扰信息。

此外，应当理解的是，本实施例中在构建第一训练模型时用到的样本数据，具体可以为各大数据平台中存储的海量数据，因而可以保证构建出的第一训练模型能够更好的刻好出数据的丰富内在信息和特征，使得基于第一训练模型训练出的分析模型能够更好的预测出监控指标对应的变化率。

(2-2)根据预设的分层标准，将所述第一训练模型中各隐藏层的初始网络层拆分为至少两个子网络层。

具体的说，上述所说的分层标准，具体用于规定将初始网络层拆分为至少两个多大尺寸的子网络层。

比如说，在初始网络层的尺寸为5×5的卷积核时，分层标准可以是规定将尺寸为5×5的卷积核拆分为两个3×3的卷积核。

这样，在执行后续的步骤(2-3)和步骤(2-4)时，通过对初始网络层拆分后的第一训练模型来进行训练，便可以增加训练模型的网络深度，从而使得后续训练出的分析模型能够根据精准的预测出监控指标对应的变化率。

(2-3)采用自下上升的非监督训练方式，以与所述第一训练模型中输入层相连的隐藏层为起点，与所述第一训练模型中输出层相连的隐藏层为终点，依次对所述第一训练模型中各隐藏层中的子网络层进行训练，得到第二训练模型。

具体的说，由于在实际应用中，构建第一训练模型的数据可以是由标定的数据，也可以是无标定的数据。而针对不同的训练数据构建的第一训练模型的训练方式也会有所不同，为了便于理解，以下以训练数据为无标定数据为例，进行具体说明。

具体的，在采用自下上升的非监督训练方式，对第一训练模型中各隐藏层中的子网络层进行训练时，需要先训练第一层(与输入层连接的隐藏层)，学习第一层的参数。然后，在学习得到第一层的参数后，将第一层的输出作为第二层的输入，依次类推，在学习得到第n-1层后，将n-1层的输出作为第n层的输入，训练第n层，由此分别得到各层的参数。

由于第一训练模型容量的限制以及稀疏性约束，因此在训练过程中能够学习到数据本身的结构，从而得到比输入更具有表示能力特征的第二训练模型。

需要说明的是，以上仅为举例说明，对本发明的技术方案并不构成限定，在具体实现中，本领域的技术人员可以根据需要选取训练数据进行训练，此处不做限制。

(2-4)采用自顶向下的监督训练方式，以与所述第二训练模型中输出层相连的隐藏层为起点，与所述第二训练模型中输入层相连的隐藏层为终点，依次对所述第二训练模型中各隐藏层中的子网络层进行训练，得到所述分析模型。

具体的说，通过采用自顶向下的监督训练方式对步骤(2-3)中训练获得的第二训练模型中各层进行训练，使得误差自顶向下传输，从而达到了对整个网络的微调，进而得到能够得到效果更好的分析模型。

应当理解的是，关于上述提到的无监督学习方式和有监督学习方式的具体使用方式，本领域的技术人员可以通过查找相关资料自行实现，此处不再赘述。

(3)根据预设的主呼叫中心选取规则，将监控指标变化率符合所述主呼叫中心选取规则的所述第一呼叫中心指定为所述主呼叫中心，所述第二呼叫中心指定为所述备份呼叫中心；或者，将监控指标变化率符合所述主呼叫中心选取规则的所述第二呼叫中心指定为所述主呼叫中心，将所述第一呼叫中心指定为所述备份呼叫中心。

具体的说，在实际应用中，所述主呼叫中心选取规则中可以规定选取网络状态稳定，并发处理能力好的呼叫中心作为主呼叫中心。

相应地，在选取主呼叫中心的时候，则可以通过比较第一呼叫中心的监控指标变化率和第二呼叫中心的监控指标变化率，从中筛选出符合所述主呼叫中心选取规则的呼叫中心作为主呼叫中心，另一个作为备份呼叫中心。

比如说，在所述第一呼叫中心的监控指标变化率符合所述主呼叫中心选取规则，则将所述第一呼叫中心指定为所述主呼叫中心，所述第二呼叫中心指定为所述备份呼叫中心。

还比如说，所述第二呼叫中心的监控指标变化率符合所述主呼叫中心选取规则，则将所述第二呼叫中心指定为所述主呼叫中心，所述第一呼叫中心指定为所述备份呼叫中心。

需要说明的是，以上仅为举例说明，对本发明的技术方案并不构成任何限定，本领域的技术人员可以根据需要设置预警策略，此处不做限制。

此外，应当理解的是，上述所说的“第一呼叫中心”中的“第一”仅仅是用于区别该呼叫中心与其他呼叫中心，并不对呼叫中心本身造成限定，且该第一呼叫中心可以为呼叫中心系统中的任意一个呼叫中心。

相应地，所述“第二呼叫中心”中的“第二”仅仅是用于区别该呼叫中心与其他呼叫中心，并不对呼叫中心本身造成限定，且该第二呼叫中心可以为呼叫中心系统中除所述第一呼叫中心之外的任意一个呼叫中心。

此外，不论是第一呼叫中心，还是第二呼叫中心，在实际应用中都是部署于服务器上的，因而在指定其中的一个为主呼叫中心，另一个为备份呼叫中心时，它们各自对应的服务器便可以称之为主服务器和备份服务器。

此外，在实际应用中，不论是主服务器，还是备份服务器都可以是传统的物理服务器(占用实际物理空间)，或者虚拟云服务器，具体的选取方式，此处不做限制。

步骤s20，对所述日志信息进行实时分析，判断所述主呼叫中心的运行状态是否正常。

具体的说，本实施例中所说的日志信息主要包括主呼叫中心各端口和进程产生的数据信息，以及部署所述主呼叫中心的服务器运行过程中产生的各种数据信息。

因而，通过对采集到的日志信息进行分析，不仅可以实现对主呼叫中心各端口和进程的运行状态的检测，还可以实现对部署所述主呼叫中心的服务器的检测。

相应地，通过分析判断，若检测到所述主呼叫中心运行状态正常(主呼叫中心和部署主呼叫中心的服务器均正常)，则执行步骤30中的操作；若检测到所述主呼叫中心运行状态异常(主呼叫中心和/或部署主呼叫中心的服务器发生异常)，则执行步骤s40中的操作。

步骤s30，在预先分配的虚拟地址接收到呼叫业务时，根据第一对应关系，将所述呼叫业务通过所述主呼叫中心的物理地址转接到所述主呼叫中心。

具体的说，上述所说的虚拟地址，具体是指virtualipaddress，即通常所说的虚拟ip，简称vip。它是一个不与特定计算机或一个计算机中的网络接口卡(nic)相连的ip地址。

相应地，所述物理地址，即通常所说的网络之间互连的协议(internetprotocol，ip)，本案中用于表明主呼叫中心的ip即为其真实的物理ip。

需要说明的是，在实际应用中，vip是分配给用户访问的，用户在访问过程中产生的数据包被发送到这个vip地址后，再由vip转接给真实的物理ip，即上述所说的根据第一对应关系，将所述呼叫业务通过所述主呼叫中心的物理地址转接到所述主呼叫中心，以使所述主呼叫中心对所述呼叫业务进行处理。

此外，值得一提的是，上述所说的第一对应关系，具体为所述虚拟地址与所述主呼叫中心的物理地址之间的对应关系。

步骤s40，启动备份呼叫中心，并在所述虚拟地址接收到所述呼叫业务时，根据第二对应关系，将所述呼叫业务通过所述备份呼叫中心的物理地址转接到所述备份呼叫中心。

具体的说，在实际应用中，当确定所述主呼叫中心的运行状态存在异常时，用于控制主呼叫中心的keepalived会通知用于控制备份呼叫中心的keepalived，此时执行主体切换为控制备份呼叫中心的keepalived，由控制备份呼叫中心的keepalived启动所述备份呼叫中心，即启动备份呼叫中心中的callcenter模块，使备份呼叫中心进入工作状态，从而可以在所述虚拟地址接收到所述呼叫业务时，由控制备份呼叫中心的keepalived根据第二对应关系，将所述呼叫业务通过所述备份呼叫中心的物理地址转接到所述备份呼叫中心，使备份呼叫中心能够对所述呼叫业务进行处理操作。

此外，为了便于理解上述切换方式，以下进行举例说明：

比如说，部署主呼叫中心的服务器的物理ip是：10.37.255.1，部署备份呼叫中心的备份服务器的物理ip是：10.37.255.2，预先分配的vip是：10.37.255.3，正常情况下vip：10.37.255.3是与主呼叫中心对应的物理ip：10.37.255.1绑定的，所以用户访问10.37.255.3的时候，其实是在访问10.37.255.1，当主呼叫中心，或者部署主呼叫中心的服务器出现异常时，vip会自动切换到备份呼叫中心对应的物理ip：10.37.255.2上，这时用户访问10.37.255.3时，实际上访问的是10.37.255.2。但是，对应用户来讲，物理ip的切换是无感的，整个访问过程，用户都只需要访问10.37.255.3就可以。

需要说明的是，以上仅为举例说明，对本发明的技术方案并不构成任何限定，在实际应用中，本领域的技术人员可以根据需要进行设置，此处不做限制。

通过上述描述不难发现，本实施例中提供的呼叫中心的容灾方法，在判断主呼叫中心的运行状态是否正常的时候，具体是采用软件检测的方式，即在主呼叫中心启动后，通过实时采集主呼叫中心运行过程中产生的日志信息，然后基于对日志信息的分析，确定主呼叫中心的运行状态是否正常，当确定主呼叫中心的运行状态正常时，在有呼叫业务时，则直接由主呼叫中心处理；当确定主呼叫中心的运行状态异常时，则启动备份呼叫中心，由备份呼叫中心接管主呼叫中心处理的呼叫业务，通告这种方式，不仅可以检测到部署主呼叫中心的服务器是否发生异常，还可以检测到主呼叫中心的进程和端口是否发生异常，进而保证了呼叫中心系统能够稳定且可靠的为用户处理呼叫业务。

此外，本实施例中提供的呼叫中心的容灾方法，从始至终提供给用户的都是一个固定且唯一的虚拟地址，而主、备呼叫中心物理地址的切换是根据主、备呼叫中心的运行状态及预先构建的第一对应关系和第二对应关系实现的，因而切换过程用户是感知不到的，从而有效的保证了用户体验效果。

此外，值得一提的是，在实际应用中，为了保障呼叫中心系统产生的信息的安全性，在部署所述第一呼叫中心和所述第二呼叫中心的时候，还可以在部署所述第一呼叫中心的服务器和部署所述第二呼叫中心的服务器中分别开辟一个基于区块链的数据存储区域，或者单独部署几台服务器用于存储呼叫中心系统产生的信息。

关于所述基于区块链的数据存储区域的创建，大致可以如下：

根据所述呼叫中心系统支持的呼叫业务建立数个区块，依次连接数个所述区块形成一条区块链。

相应地，在向所述区块链中添加待存储的信息的操作，大致可以如下：

(1)在将接收到的所述呼叫业务转接到对应呼叫中心后，实时获取处理所述呼叫业务过程中产生的业务数据；

(2)根据预设的转换规则，对所述业务数据进行数据转换处理，得到待加密字符串；

具体的说，在实际应用中预设的转换规则可以是二进制转换规则。

相应地，对所述业务数据进行数据转换处理操作后得到的待加密字符串便是仅有0和1组成的二进制字符串。

需要说明的是，本实施例中之所以将所述业务数据转换为二进制格式，是为了方便后续处理，并且避免由于数据格式不统一导致加密后的信息发生异常。

应当理解的是，以上给出的仅为一种具体的转换规则，在实际应用中，本领域的技术人员可以根据需要进行设置，此处不做限制。

(3)根据所述呼叫业务，确定存储所述业务数据的区块，并获取所述区块的区块编号；

应当理解的是，上述所说的区块编号，具体为技术人员在根据所述呼叫中心系统支持的呼叫业务创建区块时，为区块分配的用于标识区块唯一性的标识号。

(4)根据预先建立的映射关系表，确定所述区块的原始密钥，所述映射关系表为所述区块编号与所述原始密钥之间的对应关系；

需要说明的是，在实际应用中，为了保证原始密钥的唯一性和安全性，所述原始密钥可以根据从数字中心申请到的具有唯一性的数字证书生成。

比如说，在生成任一区块的原始密钥时，可以先获取所述区块对应的数字证书，然后将所述数字证书中的字符根据预设规则进行排列组合，进而得到所述区块的原始密钥。

应当理解的是，以上仅为举例说明，对本发明的技术方案并不构成任何限定，在实际应用中，本领域的技术人员可以根据需要进行设置，此处不做限制。

(5)获取所述原始密钥的原始密钥向量，采用同态加密算法对所述原始密钥向量进行加密获得同态加密向量；

(6)采用哈希密钥算法对所述同态密钥向量中的随机数进行加密获得哈希结果；

(7)采用对称加密算法对所述同态加密向量中的密文数据进行加密获得对称加密结果；

(8)对所述哈希结果和所述对称加密结果进行异或运算，生成目标密钥；

(9)利用所述目标密钥对所述待加密字符串进行加密，得到所述业务数据对应的密文数据，并将所述密文数据存储到所述区块中。

此外，在实际应用中，为了进一步提升所述业务数据的安全性，在根据预设转换规则，对所述业务数据进行数据转换操作之前，还可以根据预设规则，对所述业务数据中的字符进行排列组合，然后在根据预设转换规则，对排列组合后的业务数据进行数据转换操作。

应当理解的是，以上给出的仅为一种具体的信息备份方式，对本发明的技术方案并不构成任何限定，在实际应用中，本领域的技术人员可以根据需要进行设置，此处不做限制。

参考图3，图3为本发明一种呼叫中心的容灾方法第二实施例的流程示意图。

本实施例提供的呼叫中心的容灾方法，在第一实施例的基础上做了进一步改进，具体改进之处为：在确定所述主呼叫中心的运行状态异常，启动所述备份呼叫中心之后，继续监控所述主呼叫中心的运行状态，并在监控到所述主呼叫中心的运行状态恢复正常时，所述虚拟地址漂移会主呼叫中心的物理地址前，先停止所述备份呼叫中心的运行。

为了便于理解，以下结合图3进行具体说明：

步骤s50，启动所述备份呼叫中心，并监控所述主呼叫中心的运行状态是否恢复正常。

具体的说，由于启动所述备份呼叫中心后，执行主体已经更换为了用于控制备份呼叫中心的keepalived，因而对主呼叫中心的运行状态的监控，具体可以是由控制备份呼叫中心的keepalived从控制主呼叫中心的keepalived获取主呼叫中心当前时刻的日志信息，然后对获取到的日志信息进行分析处理，进而确定所述主呼叫中心的运行状态是否恢复正常。

相应地，获取到的主呼叫中心的日志信息，同样可以包括主呼叫中心各端口和线程的日志信息，以及部署所述主呼叫中心的服务器的日志信息。

步骤s60，若所述主呼叫中心的运行状态恢复正常，则向所述备份呼叫中心发送停止运行指令，以使所述备份呼叫中心停止运行，并在所述备份呼叫中心停止运行后，重启所述主呼叫中心。

具体的说，为了避免虚拟地址在主呼叫中心和备份呼叫中心之间来回切换形成“脑裂”，在检测到所述主呼叫中心的运行状态恢复正常后，本实施例给出的呼叫中心的容灾方法，具体是先由控制备份呼叫中心的keepalived向备份呼叫中心发送停止运行指令，以使备份呼叫中心上自定义的停止脚本根据所述停止运行指令，关闭备份呼叫中心的callcenter模块和esl应用。

同时，在上述模块和应用关闭后，控制所述备份呼叫中心的keepalived会重启，进入待机状态，此时执行主体切换为控制主呼叫中心的keepalived，由控制主呼叫中心的keepalived重启所述主呼叫中心，以使后续的呼叫业务能够转接到所述主呼叫中心进行处理。

需要说明的是，本实施例中所说的“脑裂”，具体是指在主呼叫中心和备份呼叫中心两者之间进行切换时，由于切换不彻底或其他原因，导致客户端和slave(从设备)误以为出现两个activemaster(主机)，最终使得整个集群处于混乱状态。

而esl，具体是freeswitch提供的一个接口，全称是event-sodket-library，在实际应用中通常被理解为电话事件处理组件。通过esl接口，freeswitch实现接受外部的控制，将freeswitch发出的消息事件进行过滤、并封装成dto(数据传输对象)，具体使用就是通过esl获取坐席的软电话状态，坐席外呼或呼入的时候实现电话条翻转，标识当前坐席的状态，比如示忙，通话中，空闲等。

通过上述描述不难发现，本实施例中提供的呼叫中心的容灾方法，在检测到主呼叫中心的运行状态恢复正常后，虚拟地址并非直接漂移回主呼叫中心，而是先向备份呼叫中心发送停止运行指令，在所述备份呼叫中心根据所述停止运行指令停止运行后，才重启主呼叫中心，使虚拟地址漂移回主呼叫中心，通过这种切换方式有效防止了虚拟地址来回切换形成的脑裂，从而保证了后续呼叫业务的正常处理。

此外，在实际应用中，为了方便管理呼叫中心系统的管理人员能够及时获知发送异常的呼叫中心的情况，并快速、准确的定位故障问题，在检测到所述主呼叫中心的运行状态出现异常，启动所述备份呼叫中心之后，还可以根据采集到的主呼叫中心的日志信息，生成预警信息，然后根据预设的预警通知方式，将所述预警信息通知给所述主呼叫中心的管理人员。

应当理解的是，上述所说的预警通知方式，具体可以是短信、邮件等通知方式，此处不再一一列举，对此也不做限制。

此外，为了能够让管理人员及时查看预警信息，及时针对主呼叫中心可能存在的异常作出应对措施，比如远程调整主呼叫中心的参数，或者直接到现场检查主呼叫中心或者部署主呼叫中心的服务器的状况，在将预警信息发送给管理人员后，还可以控制收到预警信息的设备作出响铃、震动、屏幕闪烁等预警。

此外，本发明实施例还提出一种存储介质，所述存储介质上存储有呼叫中心的容灾程序，\所述呼叫中心的容灾程序被处理器执行时实现如上文所述的呼叫中心的容灾方法的步骤。

参照图4，图4为本发明呼叫中心的容灾装置第一实施例的结构框图。

如图4所示，本发明实施例提出的呼叫中心的容灾装置包括：日志信息采集模块4001、日志信息分析模块4002、第一呼叫业务转接模块4003和第二呼叫业务转接模块4004。

其中，所述日志信息采集模块4001，用于启动主呼叫中心，采集所述主呼叫中心运行过程中产生的日志信息；所述日志信息分析模块4002，用于对所述日志信息进行实时分析，判断所述主呼叫中心的运行状态是否正常；所述第一呼叫业务转接模块4003，用于在所述主呼叫中心运行状态正常，预先分配的虚拟地址接收到呼叫业务时，根据第一对应关系，将所述呼叫业务通过所述主呼叫中心的物理地址转接到所述主呼叫中心；所述第二呼叫业务转接模块4004，用于在所述主呼叫中心运行状态异常时，启动备份呼叫中心，并在所述虚拟地址接收到所述呼叫业务时，根据第二对应关系，将所述呼叫业务通过所述备份呼叫中心的物理地址转接到所述备份呼叫中心。

需要说明的是，本实施例中所说的第一对应关系具体为所述虚拟地址与所述主呼叫中心的物理地址之间的对应关系。

相应地，所述第二对应关系具体为所述虚拟地址与所述备份呼叫中心的物理地址之间的对应关系。

此外，值得一提的是，在实际应用中，执行启动所述主呼叫中心的步骤之前，需要确定主呼叫中心和备份呼叫中心。

关于，确定主呼叫中心和备份呼叫中心的操作，大致可以如下所述：

首先，根据呼叫中心业务需求，搭建第一呼叫中心和第二呼叫中心。

然后，将所述第一呼叫中心和所述第二呼叫中心的任意一个指定为所述主呼叫中心，另一个指定为所述备份呼叫中心

为了便于理解，本实施例给出一种确定主呼叫中心和备份呼叫中心的具体实现方式，大致如下：首先，根据预设的监控指标，分时段采集所述第一呼叫中心提供的第一监控指标数据和所述第二呼叫中心提供的第二监控指标数据；然后，分别对各时段的第一监控指标数据和各时段的第二监控指标数据进行分析，得到所述第一呼叫中心对应的监控指标变化率和所述第二呼叫中心对应的监控指标变化率；最后，根据预设的主呼叫中心选取规则，将监控指标变化率符合所述主呼叫中心选取规则的所述第一呼叫中心指定为所述主呼叫中心，所述第二呼叫中心指定为所述备份呼叫中心；或者，将监控指标变化率符合所述主呼叫中心选取规则的所述第二呼叫中心指定为所述主呼叫中心，将所述第一呼叫中心指定为所述备份呼叫中心。

具体的说，在实际应用中，所述主呼叫中心选取规则中可以规定选取网络状态稳定，并发处理能力好的呼叫中心作为主呼叫中心。

相应地，在选取主呼叫中心的时候，则可以通过比较第一呼叫中心的监控指标变化率和第二呼叫中心的监控指标变化率，从中筛选出符合所述主呼叫中心选取规则的呼叫中心作为主呼叫中心，另一个作为备份呼叫中心。

比如说，在所述第一呼叫中心的监控指标变化率符合所述主呼叫中心选取规则，则将所述第一呼叫中心指定为所述主呼叫中心，所述第二呼叫中心指定为所述备份呼叫中心。

还比如说，所述第二呼叫中心的监控指标变化率符合所述主呼叫中心选取规则，则将所述第二呼叫中心指定为所述主呼叫中心，所述第一呼叫中心指定为所述备份呼叫中心。

需要说明的是，以上仅为举例说明，对本发明的技术方案并不构成任何限定，本领域的技术人员可以根据需要设置预警策略，此处不做限制。

此外，应当理解的是，上述所说的“第一呼叫中心”中的“第一”仅仅是用于区别该呼叫中心与其他呼叫中心，并不对呼叫中心本身造成限定，且该第一呼叫中心可以为呼叫中心系统中的任意一个呼叫中心。

相应地，所述“第二呼叫中心”中的“第二”仅仅是用于区别该呼叫中心与其他呼叫中心，并不对呼叫中心本身造成限定，且该第二呼叫中心可以为呼叫中心系统中除所述第一呼叫中心之外的任意一个呼叫中心。

此外，不论是第一呼叫中心，还是第二呼叫中心，在实际应用中都是部署于服务器上的，因而在指定其中的一个为主呼叫中心，另一个为备份呼叫中心时，它们各自对应的服务器便可以称之为主服务器和备份服务器。

此外，在实际应用中，不论是主服务器，还是备份服务器都可以是传统的物理服务器(占用实际物理空间)，或者虚拟云服务器，具体的选取方式，此处不做限制。

此外，值得一提的是，在实际应用中，为了方便对各时段的第一监控指标数据和各时段的第二监控指标数据进行分析，以便快速准确的获得第一呼叫中心的监控指标变化率和第二呼叫中心的监控指标变化率，可以基于预设的分析模型，分别对各时段的第一监控指标数据和各时段的第二监控指标数据进行分析，得到所述第一呼叫中心对应的监控指标变化率和所述第二呼叫中心对应的监控指标变化率。

关于，构建分析模型的方式，在实际应用中可以基于深度机器学习法进行构建。

具体的说，本实施例中所说的深度学习法具体是采用无监督学习方式(如深度置信网(deepbeliefnets，dbns))和有监督学习方式(如卷积神经网络(convolutionalneuralnetworks，cnns))相结合的方式，来构建所述分析模型。

为了便于理解，以下针对基于深度机器学习法，构建所述分析模型的操作具体简要说明，具体步骤如下：

首先，根据样本数据构建第一训练模型。

然后，根据预设的分层标准，将所述第一训练模型中各隐藏层的初始网络层拆分为至少两个子网络层。

接着，采用自下上升的非监督训练方式，以与所述第一训练模型中输入层相连的隐藏层为起点，与所述第一训练模型中输出层相连的隐藏层为终点，依次对所述第一训练模型中各隐藏层中的子网络层进行训练，得到第二训练模型。

最后，采用自顶向下的监督训练方式，以与所述第二训练模型中输出层相连的隐藏层为起点，与所述第二训练模型中输入层相连的隐藏层为终点，依次对所述第二训练模型中各隐藏层中的子网络层进行训练，得到所述分析模型。

关于上述提到的无监督学习方式和有监督学习方式的具体使用方式，本领域的技术人员可以通过查找相关资料自行实现，此处不再赘述。

应当理解的是，以上仅为举例说明，对本发明的技术方案并不构成任何限定，在具体应用中，本领域的技术人员可以根据需要进行设置，本发明对此不做限制。

通过上述描述不难发现，本实施例中提供的呼叫中心的容灾装置，在判断主呼叫中心的运行状态是否正常的时候，具体是采用软件检测的方式，即在主呼叫中心启动后，通过实时采集主呼叫中心运行过程中产生的日志信息，然后基于对日志信息的分析，确定主呼叫中心的运行状态是否正常，当确定主呼叫中心的运行状态正常时，在有呼叫业务时，则直接由主呼叫中心处理；当确定主呼叫中心的运行状态异常时，则启动备份呼叫中心，由备份呼叫中心接管主呼叫中心处理的呼叫业务，通告这种方式，不仅可以检测到部署主呼叫中心的服务器是否发生异常，还可以检测到主呼叫中心的进程和端口是否发生异常，进而保证了呼叫中心系统能够稳定且可靠的为用户处理呼叫业务。

此外，本实施例中提供的呼叫中心的容灾装置，从始至终提供给用户的都是一个固定且唯一的虚拟地址，而主、备呼叫中心物理地址的切换是根据主、备呼叫中心的运行状态及预先构建的第一对应关系和第二对应关系实现的，因而切换过程用户是感知不到的，从而有效的保证了用户体验效果。

需要说明的是，以上所描述的工作流程仅仅是示意性的，并不对本发明的保护范围构成限定，在实际应用中，本领域的技术人员可以根据实际的需要选择其中的部分或者全部来实现本实施例方案的目的，此处不做限制。

另外，未在本实施例中详尽描述的技术细节，可参见本发明任意实施例所提供的呼叫中心的容灾方法，此处不再赘述。

基于上述呼叫中心的容灾装置的第一实施例，提出本发明呼叫中心的容灾装置第二实施例。

在本实施例中，所述呼叫中心的容灾装置还包括：主呼叫中心监控模块和切换模块。

其中，所述主呼叫中心监控模块，用于在启动所述备份呼叫中心之后，监控所述主呼叫中心的运行状态是否恢复正常。

所述切换模块，用于在所述主呼叫中心的运行状态恢复正常时，向所述备份呼叫中心发送停止运行指令，以使所述备份呼叫中心停止运行，并在所述备份呼叫中心停止运行后，重启所述主呼叫中心。

通过上述描述不难发现，本实施例中提供的呼叫中心的容灾装置，在检测到主呼叫中心的运行状态恢复正常后，虚拟地址并非直接漂移回主呼叫中心，而是先向备份呼叫中心发送停止运行指令，在所述备份呼叫中心根据所述停止运行指令停止运行后，才重启主呼叫中心，使虚拟地址漂移回主呼叫中心，通过这种切换方式有效防止了虚拟地址来回切换形成的脑裂，从而保证了后续呼叫业务的正常处理。

此外，在实际应用中，为了方便管理呼叫中心系统的管理人员能够及时获知发送异常的呼叫中心的情况，并快速、准确的定位故障问题，在检测到所述主呼叫中心的运行状态出现异常，启动所述备份呼叫中心之后，还可以根据采集到的主呼叫中心的日志信息，生成预警信息，然后根据预设的预警通知方式，将所述预警信息通知给所述主呼叫中心的管理人员。

应当理解的是，上述所说的预警通知方式，具体可以是短信、邮件等通知方式，此处不再一一列举，对此也不做限制。

此外，为了能够让管理人员及时查看预警信息，及时针对主呼叫中心可能存在的异常作出应对措施，比如远程调整主呼叫中心的参数，或者直接到现场检查主呼叫中心或者部署主呼叫中心的服务器的状况，在将预警信息发送给管理人员后，还可以控制收到预警信息的设备作出响铃、震动、屏幕闪烁等预警。

需要说明的是，以上所描述的工作流程仅仅是示意性的，并不对本发明的保护范围构成限定，在实际应用中，本领域的技术人员可以根据实际的需要选择其中的部分或者全部来实现本实施例方案的目的，此处不做限制。

另外，未在本实施例中详尽描述的技术细节，可参见本发明任意实施例所提供的呼叫中心的容灾方法，此处不再赘述。

此外，需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如只读存储器(readonlymemory，rom)/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。