容灾方法及装置、服务器与流程

本申请涉及网络技术领域，尤其涉及一种容灾方法及装置、服务器。

背景技术：

随着云计算技术如火如荼的开展，服务器、存储、网络、应用系统等基础服务异常的小概率事件变成了必然事件。为了提高服务的高可用，规避单台服务器导致的风险，降低运维成本，急需高可用容灾切换的技术手段。

现有技术中的容灾切换系统，主要的核心在于探测、诊断、切换、修复四个处理过程，而大多数容灾切换系统的重点在探测和切换两个逻辑处理中，在数据业务出现抖动但非连续抖动的情况下，现有技术尚未有相关的处理方案，而是由人工判断是否需要对数据业务进行切换，如果人工武断的进行数据业务的切换，会出现数据业务不稳定的情况。

技术实现要素：

有鉴于此，本申请提供一种新的技术方案，可以避免人工干预切换数据业务，降低数据业务的质量风险。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种容灾方法，包括：

读取数据业务对应的多个第一状态数据，形成数据队列，所述第一状态数据表示所述数据业务的健康状态；

基于监控窗口，统计所述数据队列中健康状态表示异常的第一状态数据，得到所述监控窗口对应的特征值；

根据所述特征值确定所述数据业务是否需要切换。

根据本申请的第二方面，提出了一种容灾装置，包括：

数据读取模块，用于读取数据业务对应的多个第一状态数据，形成数据队列，所述第一状态数据表示所述数据业务的健康状态；

统计模块，用于基于监控窗口，统计所述数据读取模块得到的所述数据队列中健康状态表示异常的第一状态数据，得到所述监控窗口对应的特征值；

第一确定模块，用于根据所述统计模块得到的所述特征值确定所述数据业务是否需要切换。

根据本申请的第三方面，提出了一种服务器，所述服务器包括：

处理器；用于存储所述处理器可执行指令的存储器；

其中，所述处理器，用于读取数据业务对应的多个第一状态数据，形成数据队列，所述第一状态数据表示所述数据业务的健康状态；基于监控窗口，统计所述数据队列中健康状态表示异常的第一状态数据，得到所述监控窗口对应的特征值；根据所述特征值确定所述数据业务是否需要切换。

由以上技术方案可见，本申请在对数据业务进行诊断时，根据监控窗口内健康状态表示异常的第一状态数据的特征值确定该数据业务需要触发切换，从而可以避免数据业务出现抖动但非连续抖动的情形时数据业务切换频繁的情况，避免了人工干预切换数据业务，确保数据业务触发切换的高可用，进而确保数据业务的稳定性，提高数据业务的服务质量。

附图说明

图1示出了根据本发明的示例性实施例一的容灾方法的流程图；

图2示出了根据本发明的示例性实施例二的容灾方法的流程图；

图3示出了根据本发明的示例性实施例三的容灾方法的流程图；

图4a示出了根据本发明的一示例性实施例的服务器集群的部署架构图；

图4b示出了根据本发明的一示例性实施例的服务器集群的业务架构图；

图4c示出了服务器集群中的第二服务器如何探测得到第一消息队列的 流程图；

图5a示出了根据本发明的示例性实施例四的容灾方法的流程图；

图5b示出了根据本发明的示例性实施例四的监控窗口的示意图之一；

图5c示出了根据本发明的示例性实施例四的监控窗口的示意图之二；

图6a示出了根据本发明的示例性实施例五的容灾方法的流程图；

图6b示出了根据本发明的示例性实施例五的监控窗口的示意图；

图7a示出了根据本发明的示例性实施例六的容灾方法的流程图；

图7b示出了根据本发明的示例性实施例六的步骤701的流程图；

图8示出了根据本发明的示例性实施例七的容灾方法的流程图；

图9示出了根据本发明的一示例性实施例的服务器的示意结构图；

图10示出了根据本发明的示例性实施例一的容灾装置的结构图；

图11示出了根据本发明的示例性实施例二的容灾装置的结构图；

图12示出了根据本发明的示例性实施例三的容灾装置的结构图；

图13示出了根据本发明的示例性实施例四的容灾装置的结构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种 信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

为对本申请进行进一步说明，提供下列实施例：

图1示出了根据本发明的示例性实施例一的容灾方法的流程图；如图1所示，包括如下步骤：

步骤101，读取数据业务对应的多个第一状态数据，形成数据队列，第一状态数据表示数据业务的健康状态。

步骤102，基于监控窗口，统计数据队列中健康状态表示异常的第一状态数据，得到监控窗口对应的特征值。

步骤103，根据特征值确定数据业务是否需要切换。

在上述步骤101中，在一实施例中，数据业务可以为服务器为用户提供的应用服务，例如，即时聊天、购物等应用程序。在一实施例中，第一状态数据可以由提供数据业务的服务器主动探测得到，也可以通过专用于探测数据业务健康状态的服务器探测得到，本申请对第一状态数据的来源不做限制。在一实施例中，第一状态数据可以用0或1的离散方式来表示，例如，0表示数据业务为一个探测周期内为正常状态，1表示数据业务在一个探测周期内出现异常，此时，数据队列中包含0和1；在另一实施例中，第一状态数据可以用每个探测周期内数据业务异常的持续时长和正常的持续时长来表示，进而统计连续设定个数的探测周期内每个探测周期内出现异常的持续总时长、以及正常的持续总时长，此时，数据队列中的每一个数据对应一个时间长度。

在上述步骤102中，在一实施例中，一个监控窗口内可以包含设定个数的探测周期，例如，一个探测周期为1毫秒，监控窗口包含了8个探测周期，则监控窗口对应的时间长度为8毫秒。在一实施例中，可以通过统计监控窗 口内数据队列中的健康状态表示异常的第一状态数据的个数得到监控窗口对应的特征值；在另一实施例中，可以通过统计监控窗口内数据队列中的健康状态表示异常的持续总时长，得到监控窗口对应的特征值。

在上述步骤103中，在一实施例中，可以设置一个预设阈值，当特征值大于或者等于该预设阈值时，可以确定数据业务需要切换。

本实施例中，在对数据业务进行诊断时，根据监控窗口内健康状态表示异常的第一状态数据的特征值确定该数据业务需要触发切换，从而可以避免数据业务出现抖动但非连续抖动的情形时数据业务切换频繁的情况，避免了人工干预切换数据业务，确保数据业务触发切换的高可用，进而确保数据业务的稳定性，提高数据业务的服务质量。

图2示出了根据本发明的示例性实施例二的容灾方法的流程图；本实施例在上述图1所示实施例的基础上，以特征值为监控窗口内健康状态表示异常的第一状态数据的个数为例进行示例性说明，如图2所示，包括如下步骤：

步骤201，读取数据业务对应的多个第一状态数据，形成数据队列，第一状态数据表示数据业务的健康状态。

步骤202，在监控窗口对应的设定时间段内，确定数据队列中健康状态表示异常的第一状态数据。

步骤203，统计健康状态表示异常的第一状态数据的个数。

步骤204，根据健康状态表示异常的第一状态数据的个数确定数据业务是否需要切换，当健康状态表示异常的第一状态数据的个数达到预设阈值时，执行步骤205，当健康状态表示异常的第一状态数据的个数未达到预设阈值时，执行步骤206。

步骤205，当健康状态表示异常的第一状态数据的个数达到预设阈值时，确定数据业务需要触发切换。

步骤206，当健康状态表示异常的第一状态数据的个数未达到预设阈值时，控制继续读取数据业务对应的第一状态数据。

步骤201的描述可以参见上述图1所示实施例的相关描述，在此不再详 述。

在上述步骤202-步骤205中，在一个示例性场景中，监控窗口对应的设定时间段为8毫秒，探测周期为1毫秒，则该监控窗口对应8个探测周期，相应地，该监控窗口对应数据队列中的8个第一状态数据，该8个第一状态数据例如为：0、1、1、0、1、0、0、0，统计该监控窗口内第一状态数据中健康状态表示异常的第一状态数据为：1、1、1，健康状态表示异常的第一状态数据的个数为3个，当预设阈值为5时，由于3小于5，出现异常的原因可能是提供该数据业务的服务器出现了瞬间的抖动，并已经得到了恢复，因此可以确定数据业务不需要触发切换，控制继续读取数据队列中的第一状态数据。

在另一个示例性场景中，该监控窗口对应数据队列中的8个第一状态数据，该8个第一状态数据例如为：0、1、1、0、1、0、1、1，统计该第一状态数据中健康状态表示异常的第一状态数据为：1、1、1、1、1，该监控窗口内的健康状态表示异常的第一状态数据的个数为5个，当预设阈值为5时，由于个数5已经等于预设阈值5，出现异常的原因可能是提供该数据业务的服务器的业务能力超过该服务器能接受的范围，因此可以确定数据业务需要触发切换。

本实施例中，在对数据业务进行诊断时，根据监控窗口内健康状态表示异常的第一状态数据的个数确定该数据业务需要触发切换，从而可以避免数据业务出现抖动但非连续抖动的情形时数据业务切换频繁的情况，避免了人工干预切换数据业务，确保数据业务触发切换的高可用，进而确保数据业务的稳定性，提高数据业务的服务质量。

图3示出了根据本发明的示例性实施例三的容灾方法的流程图；本实施例在上述图1所示实施例的基础上，以特征值为健康状态表示异常的第一状态数据的持续总时长为例进行示例性说明，如图3所示，包括如下步骤：

步骤301，读取数据业务对应的多个第一状态数据，形成数据队列，第一状态数据表示数据业务的健康状态。

步骤302，在监控窗口对应的设定时间段内，确定数据队列中健康状态表示异常的每一个第一状态数据的持续时长。

步骤303，根据每一个第一状态数据的持续时长统计监控窗口内的全部健康状态表示异常的第一状态数据的持续总时长。

步骤304，根据持续总时长确定数据业务是否需要切换，当持续总时长达到预设阈值时，执行步骤305，当持续总时长未达到预设阈值时，执行步骤306。

步骤305，当持续总时长达到预设阈值时，确定数据业务需要触发切换。

步骤306，当持续总时长未达到预设阈值时，控制继续读取数据业务对应的第一状态数据。

步骤301的描述可以参见上述图1所示实施例的相关描述，在此不再详述。

在上述步骤302中，本一实施例中，第一状态数据的持续时长可以由用于探测数据业务的健康状态的服务器来确定，例如，每一个第一状态数据占用半个字节，该字节中的第1位用于记录探测到的健康状态，例如，0或者1，后3位用于记录对应健康状态的持续时长。

在上述步骤302-步骤305中，在一个示例性场景中，监控窗口对应的设定时间段为8毫秒，该监控窗口对应数据队列中的10个第一状态数据，该10个第一状态数据例如为：0、1、1、0、1、0、0、0、0、0，统计该监控窗口内健康状态表示异常的第一状态数据为：1、1、1，确定该3个第一状态数据各自对应的持续时长，例如，第一个第一状态数据的持续时长为0.3毫秒，第二个第一状态数据的持续时长为0.5毫秒，第三个第一状态数据的持续时长为0.2毫秒，则该监控窗口内的全部健康状态数据表示异常的第一状态数据的持续总时长为：0.3+0.5+0.2＝1毫秒，当预设阈值为4毫秒时，由于1毫秒小于预设阈值4毫秒，出现异常的原因可能是提供该数据业务的服务器出现了瞬间的抖动，并已经得到了恢复，因此可以确定数据业务不需要触发切换，控制继续读取数据队列中的第一状态数据。

在另一个示例性场景中，该监控窗口对应数据队列中的7个第一状态数据，该7个第一状态数据例如为：0、1、0、1、0、1、0，统计该监控窗口内健康状态表示异常的第一状态数据为：1、1、1，确定该3个第一状态数据各自对应的持续时长，例如，第一个第一状态数据的持续时长为0.4毫秒，第二个第一状态数据的持续时长为2.5毫秒，第三个第一状态数据的持续时长为1.8毫秒，则该监控窗口内的全部健康状态数据表示异常的第一状态数据的持续总时长为：0.4+2.5+1.8＝4.7毫秒，当预设阈值为4毫秒时，由于4.7毫秒小于预设阈值4毫秒，出现异常的原因可能是提供该数据业务的服务器的业务能力超过该服务器能接受的范围，因此可以确定数据业务需要触发切换。

本实施例中，在对数据业务进行诊断时，根据监控窗口内的全部健康状态表示异常的第一状态数据的持续总时长确定该数据业务需要触发切换，从而可以避免数据业务出现抖动但非连续抖动的情形时数据业务切换频繁的情况，避免了人工干预切换数据业务，确保数据业务触发切换的高可用，进而确保数据业务的稳定性，提高数据业务的服务质量。

图4a示出了根据本发明的一示例性实施例的服务器集群的部署架构图，图4b示出了根据本发明的一示例性实施例的服务器集群的业务架构图，图4c示出了服务器集群中的第二服务器如何探测得到第一消息队列的流程图。

如图4a和图4b所示，该服务器集群40可包括多台服务器401-40e，其中，e表示该服务器集群40中的服务器的数量，该服务器401-40e可以按照探测、诊断、切换、修复四个阶段的逻辑业务划分出图4b所示的第一服务器411和第一服务器412、第二服务器421-42m、第三服务器431和第三服务器432、第四服务器441和第四服务器442，同一台服务器上实现不同的逻辑业务时，可以划分为不同的第一、第二等服务器，例如，服务器401可实现对其自身数据业务的健康状态的探测功能，此时，服务器401可视为第一服务器411，服务器401还可以根据第一消息队列的第一状态数据通过本申请对服务器402进行诊断，此时，服务器401可视为第二服务器421，在 具体实现时，服务器401可通过多线程的方式实现不同的逻辑业务。

如图4b所示，第一服务器411和第一服务器412、第二服务器421-42m、第三服务器431和第三服务器432、第四服务器441和第四服务器442，其中，m表示服务器集群中包含的第二服务器的个数。其中，第一服务器411和第二服务器412可以通过各自对应的诊断模块执行本申请提供的容灾方法，在此先不详述。

第二服务器421-42m可以通过各自对应的探测模块对各自提供的数据业务(例如app1、app2、…、appn，其中，n表示第二服务器421-42m提供的数据业务的个数)的健康状态进行探测，并将探测的第一状态数据按照预设的规则和特征投递到第一消息队列451中，也即，第二服务器421-42m为状态消息的生产者，预设的规则和特征例如为：对于app1：{app1：{服务器状态：0，服务端口状态：0，业务状态：0}}，并将该第一状态数据投放到第一消息队列451中与app1对应的比特位，再例如，对于app4，{app4：{服务器状态：1，服务端口状态：0，业务状态：0}}，表示提供app4业务数据的第二服务器422出现异常。在一实施例中，每一个第二服务器对于各自提供的数据业务，可以通过多进程的方式进行探测，从而实现并行探测。

第二服务器421-42m的探测过程如图4c所示，第二服务器421-42m主要探测第二服务器421-42m是否异常、提供数据业务的服务端口是否异常、业务状态是否异常。如果服务器检测失败，直接将用于表示服务器异常的状态数据放入第一消息队列451中；如果服务器的状态正常，检测提供数据业务(例如，第二服务器421上提供的app1数据业务)的服务端口是否正常，如果服务端口检测失败，将用于表示服务端口异常的状态数据放入第一消息队列451；如果服务端口检测正常，检测业务状态是否正常，业务状态是否正常均可将业务状态的第一状态数据放入第一消息队列451中。

第三服务器431和第三服务器432根据第二消息队列452中表示需要切换的服务接口或者服务切换的逻辑(例如，0表示不需要切换，1表示需要切换)，通过各自对应的切换模块进行切换服务，使出现异常的数据业务尽可 能快的修复。由于不同的数据业务有不同的切换机制，因此本申请中所述的切换流程可以根据数据业务自身的需求进行定制化的设置，本申请对此不再详述。

数据业务切换之后，对于需要进行修复的数据业务，需要有一些善后处理的逻辑，第四服务器441和第四服务器442根据第三消息队列453中用于表示需要修复的数据业务通过各自对应的修复模块进行修复。由于修复过程同样根据不同数据业务的条件，进行不同的修复处理，因此本申请对此不再详述。

本申请提供的服务器集群中，将探测过程执行在第二服务器421-42m，诊断过程执行在第一服务器411和第二服务器412上，切换过程执行在第三服务器431和第三服务器432，修复过程执行在第四服务器441和第四服务器442，因此可以将探测、诊断、切换、修复四个过程完全拆分，通过消息队列的方式形成分布式系统，从而可以确保服务器集群的高可用，提高服务器集群的服务质量。

图5a示出了根据本发明的示例性实施例四的容灾方法的流程图，图5b示出了根据本发明的示例性实施例四的监控窗口的示意图之一，图5c示出了根据本发明的示例性实施例四的监控窗口的示意图之二；本实施例以上述图4a中的第一服务器411执行本申请的方法流程为例并结合图4a和图4b进行示例性说明，如图5a所示，包括如下步骤：

步骤501，从第一消息队列中读取数据业务的多个第一状态数据，形成该数据业务对应的数据队列，第一状态数据用于表示该数据业务的健康状态。

步骤502，以监控窗口的方式，沿着数据业务对应的数据队列移动，确定监控窗口中健康状态表示异常的第一状态数据的个数。

步骤503，确定监控窗口中健康状态表示异常的第一状态数据的个数是否大于或者等于预设阈值，当监控窗口中健康状态表示异常的第一状态数据的个数大于或者等于预设阈值时，执行步骤504，当监控窗口中健康状态表示异常的第一状态数据的个数小于预设阈值时，执行步骤505。

步骤504，当监控窗口中健康状态表示异常的第一状态数据的个数大于或者等于预设阈值时，确定数据业务需要触发切换。

步骤505，当监控窗口中健康状态表示异常的第一状态数据的个数小于预设阈值时，控制继续从第一消息队列中读取该数据业务对应的第一状态数据。

在上述步骤501中，由于每一台第二服务器提供不同的数据业务，因此第一服务器411为了能够识别出第一消息队列451中所记录的每一台第二服务器提供的数据业务对应的第一状态数据，可以在第二服务器421-42m之间约定向第一消息队列451中投放各自提供的数据业务对应的第一状态数据的方式，例如，可以将第一消息队列以设定比特位的方式存储第一状态数据，第一消息队列451对应的存储空间被划分为100个比特位，app1对应的第一状态数据存放在第一消息队列451中的第0-5个比特位，app2对应的第一状态数据存放在第一消息队列451中的第6-10个比特位，以此类推，从而可以使第一服务器411在顺次读取第一状态数据的过程中，识别出第一状态数据对应的数据业务，例如，在读取到第6-10个比特位时，即可获知该第一状态数据对应app2。

在上述步骤502-步骤505中，在一实施例中，监控窗口的宽度可根据需求进行设置，预设阈值为监控窗口内判断数据业务出现异常时的阈值。第一服务器411可以通过用于诊断的线程从第一消息队列(mq)151中读取第一状态数据，其中，健康状态表示正常时用0表示，健康状态表示异常时用1表示。如图5b和图5c所示，以监控窗口51的宽度＝10并且预设阈值＝5为例进行示例性说明，其中，箭头52表示监控窗口51沿着数据队列的滑动方向，箭头53表示从第一消息队列451读取第一状态数据的顺序，图5b中，监控窗口51中的第一状态数据均为0，表示监控窗口51无表示异常的第一状态数据，图5c中，当健康状态表示异常的第一状态数据“1”进入监控窗口51之后，监控窗口中健康状态表示异常的第一状态数据的个数为5，达到预设阈值5，确定该数据队列对应的数据业务需要触发切换。

由上述描述可知，本发明实施例通过上述步骤501-步骤505，在对数据业务进行诊断时，根据监控窗口内健康状态表示异常的第一状态数据的个数与预设阈值进行比较，当健康状态表示异常的第一状态数据的个数大于或等于预设阈值时，确定该数据业务需要触发切换，从而可以避免数据业务出现抖动但非连续抖动的情形时数据业务切换频繁的情况，避免了人工干预切换数据业务，确保数据业务触发切换的高可用，进而确保数据业务的稳定性，提高数据业务的服务质量；此外，通过将第一消息队列作为第一服务器与第二服务器之间进行信息交互的介质，当第一服务器的诊断出现异常时仍可以确保第二服务器探测各自提供的数据业务的健康状态。

图6a示出了根据本发明的示例性实施例五的容灾方法的流程图，图6b示出了根据本发明的示例性实施例五的监控窗口的示意图；本实施例以如何确定数据队列中的第一状态数据是否被全部填充为例进行示例性说明，如图6a所示，包括如下步骤：

步骤601，确定监控窗口内是否被数据队列中的第一状态数据全部填充。

步骤602，当监控窗口内被数据队列中的第一状态数据全部填充时，将数据队列中最先加入到监控窗口中的第一状态数据从监控窗口中剔除。

步骤603，当监控窗口内未被数据队列中的第一状态数据全部填充时，控制继续从第一消息队列中读取第一状态数据。

当第一服务器411在首次读取第一消息队列中的第一状态数据时，会从第一消息队列中依次周期性读取，由于监控窗口的宽度包含有设定个数的第一状态数据，如图6b所示，监控窗口51中包含有7个第一状态数据，而监控窗口51的宽度为10个第一状态数据，此时监控窗口51尚未被全部填充，此时第一服务器继续从第一消息队列451中读取第一状态数据。在上述图5b中，数据队列中已有54个第一状态数据，此时已经将监控窗口51全部填充，当第一服务器411再次读取第一消息队列451中的第一状态数据时，监控窗口51需要向右滑动一位，而监控窗口51内最先加入到监控窗口51中的第一状态数据(0)剔除。

本实施例中，当监控窗口内被数据队列中的第一状态数据全部填充时，将数据队列中最先加入到监控窗口中的第一状态数据从监控窗口中剔除，从而可以确保第一状态数据在监控窗口内的实时性，确保能够准确地诊断数据业务的异常状态。

图7a示出了根据本发明的示例性实施例六的容灾方法的流程图，图7b示出了根据本发明的示例性实施例六的步骤701的流程图；本实施例结合图4a进行示例性说明，如图7a所示，包括如下步骤：

步骤701，通过守护线程确定用于读取第一消息队列以形成数据队列的第一线程是否产生了数据堆积。

步骤702，当第一线程产生数据堆积时，通过守护线程启动第二线程。

步骤703，通过第二线程读取数据队列，控制第一线程停止读取数据队列。

如图4a所示，第一服务器411可以通过第一线程读取第一消息队列451中的第一状态数据，当第一线程出现异常时，会在第一线程中产生数据堆积时。因此本申请可以为每一台第一服务器提供一个守护线程，例如，第一服务器411通过其守护线程检查数据队列是否在第一线程中产生了数据堆积。当确定第一线程中产生了数据堆积时，守护线程会主动触发启动一个新的第二线程，通过第二线程接管该第一消息队列，并控制第一线程停止读取数据队列。

在一实施例中，如图7b所示，步骤701可包括如下步骤：

步骤711，确定第一线程当前从数据队列中读取第一状态数据的第一时间点以及读取与当前状态数据的上一个第一状态数据的第二时间点。

步骤712，确定第一时间点与第二时间点之间的时间差是否大于预设倍数的探测周期，当时间差大于预设倍数的探测周期时，执行步骤713，当时间差小于或者等于预设倍数的探测周期时，执行步骤714，其中，探测周期为第二服务器探测多个应用服务的状态的时间周期。

步骤713，当时间差大于预设倍数的探测周期时，确定第一线程产生数 据堆积。

步骤714，当时间差小于或者等于预设倍数的探测周期时，确定第一线程未产生数据堆积。

在上述步骤711和步骤712中，第一服务器411通过第一线程从数据队列中读取第一状态数据以及当前状态数据的上一个第一状态数据时，可以分别记录各自对应的第一时间点和第二时间点，当第一时间点与第二时间点之间的时间差大于预设倍数的探测周期时，确定通过第一线程读取状态数据有延时，第一线程产生数据堆积；当第一时间点与第二时间点之间的时间差小于或者等于预设倍数的探测周期时，确定第一线程未产生数据堆积。

在一实施例中，预设倍数可以为2倍，探测周期可以由第二服务器421-42m探测状态数据的时间周期来确定。

本实施例中，当第一线程产生数据堆积时，通过守护线程启动第二线程，通过第二线程读取数据队列，并停止第一线程读取数据队列，从而可以避免数据堆积，有效解决高可用容灾系统不能正常工作的问题。

图8示出了根据本发明的示例性实施例七的容灾方法的流程图；本实施例结合上述图4a和图4b进行示例性说明，如图8所示，包括如下步骤：

步骤801，从第一消息队列中读取多个数据业务各自对应的第一状态数据，形成多个数据业务各自对应的数据队列，第一状态数据表示对应的数据业务的健康状态。

步骤802，以监控窗口的方式，沿着多个数据业务各自对应的数据队列移动，确定监控窗口中健康状态表示异常的第一状态数据的个数。

步骤803，当监控窗口中健康状态表示异常的第一状态数据的个数大于或者等于预设阈值时，确定数据队列对应的数据业务需要触发切换。

步骤804，生成用于表示数据队列对应的数据业务需要触发切换的第二状态数据。

步骤805，将第二状态数据投放到第二消息队列中。

上述步骤801-步骤803的描述可以参见上述图5a所示实施例的相关描 述，在此不再详述。

上述步骤804和步骤805中，本实施例中的第二消息队列的生成类似上述第一消息队列，例如，第二消息队列452对应的存储空间被划分为100个比特位，app1对应的第二状态数据存放在第二消息队列452中的第0-5个比特位，app2对应的第二状态数据存放在第二消息队列452中的第6-10个比特位，以此类推，从而可以使第三服务器431和第三服务器432在顺次读取第二状态数据的过程中，识别出第二状态数据对应的数据业务，并使第三服务器431和第三服务器432根据相应的第二状态数据判断是否需要执行切换的动作。

本实施例具有上述实施例有益技术效果的基础上，通过第二消息队列作为第一服务器与第三服务器之间进行信息交互的介质，并通过第一消息队列和第二消息队列在第一服务器、第二服务器、第三服务器之间的消息系统形成分布式系统，从而可以解决单台服务器在实现探测、诊断、切换、修复的过程中出现的瞬间抖动问题。

对应于上述的容灾方法，本申请还提出了图9所示的根据本发明的一示例性实施例的服务器的示意结构图。请参考图9，在硬件层面，该服务器包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成容灾装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

其中，处理器，用于读取数据业务对应的多个第一状态数据，形成数据队列，第一状态数据表示数据业务的健康状态；基于监控窗口，统计数据队列中健康状态表示异常的第一状态数据，得到监控窗口对应的特征值；根据特征值确定数据业务是否需要切换。

图10示出了根据本发明的示例性实施例一的容灾装置的结构图；如图 10所示，容灾装置可以包括：数据读取模块11、统计模块12、第一确定模块13；其中，

数据读取模块11，用于读取数据业务对应的多个第一状态数据，形成数据队列，第一状态数据表示数据业务的健康状态；

统计模块12，用于基于监控窗口，统计数据读取模块11得到的数据队列中健康状态表示异常的第一状态数据，得到监控窗口对应的特征值；

第一确定模块13，用于根据统计模块12得到的特征值确定数据业务是否需要切换。

图11示出了根据本发明的示例性实施例二的容灾装置的结构图；在上述图10所示实施例的基础上，如图11所示，统计模块12可包括：

第一确定单元121，用于在监控窗口对应的设定时间段内，确定数据读取模块得到的数据队列中健康状态表示异常的第一状态数据；

第一统计单元122，用于统计第一确定单元121确定的健康状态表示异常的第一状态数据的个数，个数为监控窗口对应的特征值。

在一实施例中，统计模块12可包括：

第二确定单元123，用于在监控窗口对应的设定时间段内，确定数据队列中健康状态表示异常的每一个第一状态数据的持续时长；

第二统计单元124，用于根据第二确定单元123确定的每一个第一状态数据的持续时长统计监控窗口内的全部健康状态表示异常的第一状态数据的持续总时长，持续总时长为监控窗口对应的特征值。

在一实施例中，数据读取模块11可包括：

数据读取单元111，用于从第一消息队列中读取数据业务对应的多个第一状态数据，形成数据业务对应的数据队列。

在一实施例中，第一消息队列通过对数据业务的健康状态进行探测后生成。

图12示出了根据本发明的示例性实施例三的容灾装置的结构图；在上述图10或图11所示实施例的基础上，如图12所示，装置还可包括：

第二确定模块14，用于确定统计模块12采用的监控窗口内是否被数据队列中的第一状态数据全部填充；

剔除模块15，用于当第二确定模块14确定监控窗口内被数据队列中的第一状态数据全部填充时，将数据队列中最先加入到监控窗口中的第一状态数据从监控窗口中剔除；

第一控制模块16，用于当第二确定模块14确定监控窗口内未被数据队列中的第一状态数据全部填充时，控制继续从第一消息队列中读取第一状态数据。

在一实施例中，装置还可包括：

第三确定模块17，用于通过守护线程确定用于读取第一消息队列以形成数据队列的第一线程是否产生了数据堆积；

线程启动模块18，用于当第三确定模块17确定第一线程产生数据堆积时，通过守护线程启动第二线程；

第二控制模块19，用于通过线程启动模块18启动的第二线程读取数据队列，控制第一线程停止读取数据队列。

在一实施例中，第三确定模块17包括：

第三确定单元171，用于确定第一线程当前从数据队列中读取第一状态数据的第一时间点以及读取与当前状态数据的上一个第一状态数据的第二时间点；

第四确定单元172，用于确定第三确定单元171确定的第一时间点与第二时间点之间的时间差是否大于预设倍数的探测周期，其中，探测周期为第二服务器探测多个应用服务的状态的时间周期；

第五确定单元173，用于当第四确定单元172确定时间差大于预设倍数的探测周期时，确定第一线程产生数据堆积；

第六确定单元174，用于当第四确定单元172确定时间差小于或者等于预设倍数的探测周期时，确定第一线程未产生数据堆积。

图13示出了根据本发明的示例性实施例四的容灾装置的结构图；在上述图 10-图12任一所示实施例的基础上，如图13所示，第一确定模块13可包括：

第七确定单元131，用于当统计模块12得到的特征值达到预设阈值时，确定数据业务需要触发切换；

控制单元132，用于当统计模块12得到的特征值未达到预设阈值时，控制继续读取数据业务对应的第一状态数据。

在一实施例中，装置还可包括：

消息生成模块20，用于当第一确定模块13确定数据业务需要触发切换时，生成用于表示数据业务需要触发切换的第二状态数据；

状态投放模块21，用于将消息生成模块20生成的第二状态数据投放到第二消息队列中。

上述实施例可见，通过监控窗口技术可以很好的避免数据业务出现服务抖动时的诊断错误问题；通过分布式的高可用系统，可以提高服务器集群的服务质量。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

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

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。