CN110109772B - 一种cpu的重启方法、通信设备及可读存储介质 - Google Patents

Abstract

本发明实施例公开了一种CPU的重启方法、通信设备及可读存储介质，其中，所述方法包括：接收用于重启CPU的第一通知消息；基于所述第一通知消息，查询业务注册表，获取客户端标识；根据所述客户端标识，向客户端发送第二通知消息，其中，所述第二通知消息用于通知所述客户端进行数据备份；如果在预设时间内接收到所述客户端发送的备份完成的第三通知消息，控制CPU进行重启。

Description

一种CPU的重启方法、通信设备及可读存储介质

技术领域

本发明涉及通信设备技术领域，尤其涉及一种CPU的重启方法、通信设备及可读存储介质。

背景技术

***通信设备为了提高***可靠性、提升转发性能，通常采用控制面和转发面分离的架构。控制面由负责***控制、协议处理等功能的通用中央处理器(CentralProcessing Unit，CPU)(也可称为控制CPU)组成，转发面则由负责报文转发的网络处理器等转发芯片组成，两者相互独立，共同完成路由学习和报文转发功能。***通信设备在***升级或软件运行异常时需要对控制CPU进行重启，通常重启控制CPU会引发整个单板重启进而导致业务中断，不满足***通信设备高可用性要求。

现有技术为了缩短业务中断时间，通常采用控制CPU重启而转发芯片不重启的方案，但如果控制CPU重启，运行其上操作转发芯片的业务软件也会重启，相关控制信息或数据丢失也会造成一定程度的业务受损或中断，并不能做到真正的业务不中断。针对这种情况，业界通常采用硬件冗余的方式来保证业务的不中断。这种方案需要给待重启控制CPU所在单板指定一个备用单板，在控制CPU重启前将相关数据同步到备用单板，同步完成后将所有业务切换到备用单板，然后重启控制CPU，完成业务升级等动作后再将业务切换回来。这种方式虽然能做到业务不中断，但需要增加备用单板，也就增加了生产成本，同时在升级的过程中需要频繁的跨板交互，也增加了***的复杂性。

发明内容

为解决现有存在的技术问题，本发明实施例提供一种CPU的重启方法、通信设备及可读存储介质，解决了现有技术中在重启CPU时需要增加单板才能实现业务不中断的问题，能够不借助其他单板，仅依靠本地存储来备份、恢复业务数据从而达到控制CPU重启业务不中断的目的，进而能够降低设备成本并减少跨板交互，进一步降低***的复杂性。

本发明实施例的技术方案是这样实现的：

第一方面，本发明实施例提供一种CPU的重启方法，所述方法包括：

接收用于重启CPU的第一通知消息；

基于所述第一通知消息，查询业务注册表，获取客户端标识；

根据所述客户端标识，向客户端发送第二通知消息，其中，所述第二通知消息用于通知所述客户端进行数据备份；

如果在预设时间内接收到所述客户端发送的备份完成的第三通知消息，控制CPU进行重启。

第二方面，本发明实施例提供一种CPU的重启方法，所述方法包括：

接收服务端发送的第二通知消息；

基于所述第二通知消息，获取与自身对应的第二业务的回调转储参数；

根据所述回调转储参数，获取所述第二业务的业务数据；

将所述业务数据存储至所述第一内存空间；

若所述业务数据存储完成，向所述服务端发送第三通知消息。

第三方面，本发明实施例提供一种通信设备，所述通信设备至少包括处理器和配置为存储可执行指令的存储介质，其中：

处理器配置为执行存储的可执行指令，所述可执行指令包括：

接收用于重启CPU的第一通知消息；

基于所述第一通知消息，查询业务注册表，获取客户端标识；

根据所述客户端标识，向客户端发送第二通知消息，其中，所述第二通知消息用于通知所述客户端进行数据备份；

如果在预设时间内接收到所述客户端发送的备份完成的第三通知消息，控制CPU进行重启。

第四方面，本发明实施例提供一种通信设备，所述通信设备至少包括处理器和配置为存储可执行指令的存储介质，其中：

处理器配置为执行存储的可执行指令，所述可执行指令包括：

接收服务端发送的第二通知消息；

基于所述第二通知消息，获取与自身对应的第二业务的回调转储参数；

根据所述回调转储参数，获取所述第二业务的业务数据；

将所述业务数据存储至所述第一内存空间；

若所述业务数据存储完成，向所述服务端发送第三通知消息。

第五方面，本发明实施例提供一种计算机可读存储介质，所述计算机存储介质中存储有计算机可执行指令，该计算机可执行指令配置为执行本发明实施例提供的CPU的重启方法。

在本发明实施例提供一种CPU的重启方法、通信设备及可读存储介质，其中，首先接收用于重启CPU的第一通知消息；然后基于所述第一通知消息，查询业务注册表，获取客户端标识；再根据所述客户端标识，向客户端发送第二通知消息，其中，所述第二通知消息用于通知所述客户端进行数据备份；最后如果在预设时间内接收到所述客户端发送的备份完成的第三通知消息，控制CPU进行重启。如此，能够不借助其他单板，仅依靠本地存储来备份、恢复业务数据从而达到控制CPU重启业务不中断的目的，进而能够降低设备成本并减少跨板交互，进一步降低***的复杂性。

附图说明

在附图(其不一定是按比例绘制的)中，相似的附图标记可在不同的视图中描述相似的部件。具有不同字母后缀的相似附图标记可表示相似部件的不同示例。附图以示例而非限制的方式大体示出了本文中所讨论的各个实施例。

图1为本发明实施例CPU的重启方法的实现流程示意图；

图2为本发明实施例CPU的重启方法的实现流程示意图；

图3为本发明实施例软复位***结构图；

图4为本发明实施例正常软复位的实现流程示意图；

图5为本发明实施例异常软复位的实现流程示意图；

图6为本发明实施例通信设备的组成结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对发明的具体技术方案做进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

实施例一

本发明实施例提供一种CPU的重启方法，图1为本发明实施例CPU的重启方法的实现流程示意图，如图1所示，所述方法包括以下步骤：

步骤S101，接收用于重启CPU的第一通知消息。

这里，所述步骤S101可以是由服务端实现的。需要说明的是，本发明实施例及其他实施例中的服务端是驻留在CPU复位控制进程中的，可以理解为是CPU复位控制进程中的一个线程。服务端是进行CPU重启的总控点。

第一通知消息可以是用户发出了重启CPU的操作指令而触发生成的，例如，可以是用户在网管上点击了重启CPU的控件按钮，还可以是用户输入了重启CPU的命令。另外，第一通知消息还可以是由于设备中的一些进程或组件出现异常而触发生成的，例如，设备中的硬盘出现故障，CPU进入死循环或者进程被挂起等等。

步骤S102，基于所述第一通知消息，获取客户端标识。

这里，所述步骤S102可以是由服务端实现的。在本实施例及其他实施例中，客户端驻留在每个业务进程中，用于协助业务备份恢复数据。一个业务进程对应一个客户端，即业务进程和客户端是一对一的关系。但是一个业务进程中可能会包括一个或多个业务，也就是说客户端与业务可能是一对一的关系也可能是一对多的关系。

在服务端收到第一通知消息后，获取服务端控制的客户端的标识信息根据所述客户端标识，向客户端发送第二通知消息。

这里，所述步骤S103可以是由服务端实现的。所述第二通知消息用于通知所述客户端进行数据备份。

步骤S104，如果在预设时间内接收到所述客户端发送的备份完成的第三通知消息，控制CPU进行重启。

这里，所述步骤S104可以是由服务端实现的。所述预设时间是根据各个客户端对应的业务进程中的每个业务进行数据备份的时间来确定的，所述预设时间大于或等于所有业务中进行数据备份需要的时间中的最长时间。比如，存在两个业务进程，业务进程1和业务进程2，并且业务进程1中包括业务1和业务2；业务进程2中包括业务3、业务4和业务5。其中，业务1进行数据备份的时间为2分钟，业务2进行数据备份的时间为2分钟，业务3进行数据备份的时间为5分钟，业务4进行数据备份的时间为1分钟，业务5进行数据备份的时间为3分钟，那么该预设时间至少为5分钟。

在所述步骤S104之前，所述方法还包括：判断在预设时间内是否接收到所述客户端发送的备份完成的第三通知消息。其中，如果在预设时间内接收到所述客户端发送的第三通知消息进入步骤S104；如果在预设时间内没有接收到客户端发送的第三通知消息，执行以下步骤：

步骤141，获取没有完成数据备份的第一业务的第一业务属性信息；

步骤142，根据所述第一业务属性信息，判断所述第一业务是否为第一类型的业务；

步骤143，如果所述第一业务为第一类型的业务，控制CPU不进行重启，并输出重启失败的提示信息。

步骤144，如果所述第一业务不是第一类型的业务，控制CPU进行重启。

在步骤141至步骤144所在的实施例中，第一业务属性信息可以包括：业务的名称、业务的类型、该业务需要占用的空间存储大小等信息。其中，业务的类型可以反映业务的关键程度，在实际实现中可以用关键程度系数来反应业务的关键程度。第一类型的业务是指关键程度系数满足预设条件的业务，其中，如果关键程度系数越小，表明业务的关键程度越高，那么预设条件为关键程度系数小于预设值；如果关键程度***越大，表明业务的关键程度越高，那么预设条件为关键程度***大于预设值。当业务的类型为第一类型时，表明该业务的关键程度高，如果关键程度高的业务没有完成数据备份，那么控制CPU不进行重启；当业务的类型为第二类型时，表明该业务的关键程度低，如果关键程度低的业务没有完成数据备份，忽略该业务，控制CPU进行重启。

在本发明实施例提供一种CPU的重启方法中，首先接收用于重启CPU的第一通知消息；然后基于所述第一通知消息，查询业务注册表，获取客户端标识；再根据所述客户端标识，向客户端发送第二通知消息，其中，所述第二通知消息用于通知所述客户端进行数据备份；最后如果在预设时间内接收到所述客户端发送的备份完成的第三通知消息，控制CPU进行重启。如此，能够不借助其他单板，仅依靠本地存储来备份、恢复业务数据从而达到控制CPU重启业务不中断的目的，进而能够降低设备成本并减少跨板交互，进一步降低***的复杂性。

实施例二

基于前述的实施例，本发明实施例再提供一种CPU的重启方法，应用在由服务端和客户端构成的C/S架构中，图2为本发明实施例CPU的重启方法的实现流程示意图，如图2所示，所述方法包括以下步骤：

步骤S201，服务端读取配置文件。

这里，所述配置文件中至少包括起始地址和内存空间大小。服务端驻留在通信设备的CPU复位控制进程中。需要说明的是，所述配置文件在通信设备的版本开发过程中，可以由版本的开发人员根据实际产品的需求对起始地址和内存空间大小进行设置或调整，但是一旦版本加载到通信设备中后，该配置文件只可读不可写。

步骤S202，所述服务端基于所述起始地址和所述空间大小确定第一内存空间。

这里，已知了起始地址和内存空间大小，那么就可以确定出一段内存空间，在本实施例中将该段内存空间称之为第一内存空间。本实施例中的第一内存空间也就是其他实施例中的保留空间。

步骤S203，所述服务端初始化所述第一内存空间。

这里，初始化第一内存空间可以理解为清除所述第一内存空间中已存储的数据，并将该第一内存空间设置为在CPU重启时不进行数据清理的内存空间，并将第一内存空间挂载到内存文件***。

步骤S204，客户端接收第二业务发送的业务属性信息。

这里，所述业务属性信息中至少包括第二业务的标识、第二业务的类型和回调转储参数。其中，第二业务的类型用于反映第二业务的关键程度。回调转储参数用于表征第二业务产生的业务数据的存储位置，在进行数据备份的过程中，可以通过回调转储参数确定一个业务的业务数据的存储位置，进而进行数据备份。

需要说明的是，在本实施例中，不限定客户端和第二业务的数量，可以有一个或多个客户端，同样也可以有一个或多个第二业务。当有多个第二业务时，客户端接收第二业务发送的业务属性信息是指，客户端接收每一个第二业务发送的业务属性信息。

步骤S205，所述客户端保存所述第二业务的业务属性信息。

步骤S206，所述客户端将所述第二业务的业务属性信息发送给服务端。

这里，服务端接收客户端发送的业务属性信息。

步骤S207，所述服务端保存所述业务属性信息，并将业务的备份状态添加至所述业务属性信息。

这里，在服务端保存第二业务的业务属性信息至少包括：第二业务的标识、第二业务的类型和回调转储参数以及第二业务的备份状态。业务的备份状态用于表征一个业务是否完成数据备份，并且服务端将业务的备份状态添加至所述业务属性信息时，初始值为未备份。

在实际实现过程中，服务端将业务属性信息以业务注册表的形式保存，管理起来。

步骤S208，所述服务端接收用于重启CPU的第一通知消息。

步骤S209，所述服务端基于所述第一通知消息，获取客户端标识。

这里，所述服务端在接收到第一通知消息后，可以通过查询业务注册表，获取相关客户端标识。

步骤S210，所述服务端根据所述客户端标识，向客户端发送第二通知消息。

这里，所述第二通知消息用于通知所述客户端进行数据备份。

步骤S211，所述客户端基于所述第二通知消息，获取与自身对应的第二业务的回调转储参数。

这里，所述客户端接收服务端发送的第二通知消息，并根据自身存储的第二业务的业务属性信息获取第二业务的回调转储参数。

步骤S212，所述客户端根据所述回调转储参数，获取所述第二业务的业务数据。

步骤S213，所述客户端将所述业务数据存储至所述第一内存空间。

这里，在其他实施例中，所述客户端将所述业务数据存储至第一内存空间后，还会执行以下步骤：

步骤241，所述客户端获取所述业务数据的存储信息；

步骤242，所述客户端建立所述存储信息和所述第二业务的对应关系，并保存所述对应关系。

在步骤241至步骤242所在的实施例中，业务数据的存储信息包括业务数据存储在第一内存空间的起始地址，以及业务数据占用的空间大小。建立并保存所述存储信息和所述第二业务的对应关系是为了在CPU重启之后，通过该对应关系获取第二业务的备份数据的存储信息，进而根据存储信息获取备份数据。

步骤S214，若所述业务数据存储完成，所述客户端向所述服务端发送第三通知消息。

这里，若所述业务数据存储完成指的是所述客户端对应的业务进程中的所有业务的业务数据都存储完成。在所述步骤S214之前，所述方法还包括：所述客户端判断是否所有业务的业务数据都存储完成，如果所有业务的业务数据都存储完成，进入步骤S214；如果不是所有业务的业务数据都完成存储，那么不发送第三通知消息。

步骤S215，如果在预设时间内接收到所述客户端发送的备份完成的第三通知消息，所述服务端控制CPU进行重启。

这里，在所述步骤S215之后，所述方法还包括：如果在预设时间内没有接收到所述客户端发送的第三通知消息，获取没有完成数据备份的第一业务的第一业务属性信息；根据所述第一业务属性信息，判断所述第一业务是否为第一类型的业务；如果所述第一业务为第一类型的业务，控制CPU不进行重启，并输出数据备份失败的提示信息；如果所述第一业务不为第一类型的业务，控制CPU进行重启。

在其他实施例中，在CPU重启之后，所述方法还包括：

步骤261，所述客户端接收第二业务发送的数据恢复请求，其中，所述数据恢复请求中至少携带有第二业务的标识；

步骤262，所述客户端根据所述第二业务的标识，获取所述第二业务对应的存储信息；

步骤263，所述客户端将携带有所述存储信息的数据恢复响应发送给第二业务。

步骤264，所述第二业务根据所述存储信息获取自身的业务数据，进行业务数据恢复，并在业务数据恢复完成后，恢复对相应业务芯片的控制。

在本发明实施例提供的CPU的重启方法中，在CPU重启之前，首先服务端读取配置文件，然后基于配置文件中的起始地址和空间大小确定第一内存空间；服务端初始化所述第一内存空间；客户端接收第二业务发送并保存的业务属性信息，然后将所述第二业务的业务属性信息发送给服务端；服务端保存所述业务属性信息，并将业务的备份状态添加至所述业务属性信息；当服务端接收到用于重启CPU的第一通知消息后基于所述第一通知消息，获取客户端标识，再根据所述客户端标识，向客户端发送第二通知消息；所述客户端基于所述第二通知消息，获取与自身对应的第二业务的回调转储参数。所述客户端根据所述回调转储参数，获取所述第二业务的业务数据并将所述业务数据存储至所述第一内存空间；若所述业务数据存储完成，所述客户端向所述服务端发送第三通知消息；如果在预设时间内接收到所述客户端发送的备份完成的第三通知消息，所述服务端控制CPU进行重启。如此，由于第一内存空间为通信设备自身内存的一部分，并且第一内存空间在CPU重启时不进行数据清理，在CPU重启之前将各个业务的业务数据存储到第一内存空间，那么在CPU重启之后各个业务可以从第一内存空间中获取到重启前的备份数据，从而保证业务不中断，并且不需要增加新的通信设备，从而能够降低成本，并降低***复杂度。

实施例三

针对***通信设备软件升级业务不中断的高可用性需求，本发明实施例提供一种不借助其他单板，仅依靠本地存储来备份、恢复业务数据的CPU重启方法，在本发明实施例中将该CPU重启方法称之为软复位，实施本发明实施例提供的软复位方法能够达到控制CPU重启时业务不中断的目的。

在本发明实施例提供的软复位方法中，首先在控制CPU重启前，在内存中划分出一段内存空间，用作业务数据备份，这段内存空间在CPU重启时不做数据清理，在本实施例中将这段内存空间称为保留内存。

软复位控制模块负责保留内存的使用和管理，通过配置文件描述保留内存的访问地址、大小等信息。

软复位模块采用客户端/服务器(Client/Server，C/S)架构，服务端驻留在CPU复位控制进程中，作为总控点；客户端驻留在每个业务进程中，协助业务备份恢复数据。

业务进程通过客户端接口向服务端注册业务名称、特性及转储回调等相关信息，服务端将这些信息以业务注册表的形式管理起来。服务端发起CPU重启前，查询业务注册表并依次通知相关客户端调用业务回调备份数据，等到所有客户端完成数据备份后重启CPU，业务进程重启后再调用客户端接口恢复数据。

本发明实施例提供的CPU重启方法包括以下步骤：

步骤31，软复位服务端读取配置文件，获取保留内存大小、地址空间等信息，初始化保留内存并挂载内存文件***；

步骤32，业务进程调用客户端接口向服务端注册业务名称、特性及转储回调等相关信息；

步骤33，服务端将客户端注册信息以业务注册表的形式管理起来；

步骤34，服务端查询业务注册表并依次通知相关客户端调用业务回调获取备份数据；

步骤35，客户端将获取的业务备份数据写入内存文件***(保留内存)，完成后通知服务端；

步骤36，服务端查询注册表，判断所有注册业务完成备份后发起CPU重启；

步骤37，业务进程重启后调用客户端接口恢复数据。

在步骤31至步骤37中，业务进程中各业务通过软复位客户端向服务端发起注册，注册信息包括业务名称、特性及转储回调接口等。图3为本发明实施例软复位***结构图，如图3所示，所述软复位***至少包括：软复位服务端301、软服务客户端302，其中：

软复位服务端301，负责管理保留内存、维护业务注册信息、监控客户端各业务备份状态、复位CPU；

软复位客户端302负责协助业务实体备份恢复数据、读写保留内存。

在***通信设备的工作过程中进行的软复位包括正常软复位和异常软复位，其中，正常软复位(升级、重启命令)是由用户指令下达到相应终端进程发起通知到软复位服务端；异常软复位是由异常进程触发，***监控进程感知到异常发起通知到软复位服务端。不管是正常软复位还是异常软复位，从总体上看，软复位服务端是软复位的总控点。

图4为本发明实施例正常软复位的实现流程示意图，如图4所示，所述流程包括以下步骤：

步骤S401，业务进程向软复位客户端发起业务模块注册。

步骤S402，软复位客户端向软复位服务端发起业务注册。

在所述步骤S401和步骤S402中，业务进程通过软复位客户端向服务端发起注册，注册信息包括业务名称、特性及转储回调接口等信息。

步骤S403，软复位服务端维护业务注册表。

这里，软复位服务端接收到各个业务进程的业务名称、特性及转储回调接口等信息后，将这些信息以业务注册表的形式存储起来，并维护业务注册表。

步骤S404，终端进程接收用户的命令或者网管动作。

这里，用户的命令或者网管动作用于指示进行CPU软复位。

步骤S405，终端进程向软复位服务端发起软复位。

步骤S406，软复位服务端通知软复位客户端进行业务数据备份。

这里，在如图1所示的软复位***中，包括软复位服务器和两个软复位客户端：软复位客户端A和软复位客户端B。软复位服务端通知所有软复位客户端(软复位客户端A、软复位客户端B)发起业务数据备份。

步骤S407，软复位客户端转储业务数据。

这里，软复位客户端A负责业务实体1、2、3的数据备份，软复位客户端B负责业务实体4、5的数据备份。各软复位客户端通过调用业务实体注册时提供的回调接口获取到业务数据，分别转储到保留内存对应的业务数据区域。

步骤S408，软复位客户端向软复位服务端发送业务备份完成的通知消息。

这里，软复位客户端检测到本业务进程中业务实体数据备份完成，向软复位服务端发送业务备份完成的通知消息，通知软复位服务端数据备份完成。

步骤S409，软复位服务端重启CPU。

这里，软复位服务端将业务注册表中相应业务实体的备份状态修改为备份完成。软复位服务端检查所有注册的业务实体(1、2、3、4、5)数据备份状态均完成后发起CPU重启。

步骤S410，业务进程进行重启。

步骤S411，业务进程向软复位客户端发送数据恢复请求。

这里，业务进程重启后，判断上一次CPU重启是否为软复位方式的重启，如果上一次CPU重启是软复位方式的重启，向软复位客户端发送数据恢复请求。

在实际实现过程中，在CPU重启之前，CPU会将包括复位方式的一些重启参数传递给***，并保存起来，当业务进程重启后可以通过查询上一次的重启参数确定上一次CPU重启是否为软复位方式的重启。

步骤S412，软复位客户端向业务进程进行发送数据恢复响应。

这里，软复位客户端调用数据恢复接口，从保留内存中获取每个业务进程对应的恢复数据，并将恢复数据携带于数据恢复响应中发送给业务进程，业务进程在业务实体数据恢复完成后，恢复对相应业务芯片的控制。

图5为本发明实施例异常软复位的实现流程示意图，如图5所示，所述流程包括以下步骤：

步骤S501，应用进程产生异常。

这里，应用进程发生异常可以是单板中硬盘发生故障、CPU跑死或进程挂起等情况。

步骤S502，***监控进程监测到该应用进程，并将该应用进程确定为异常进程。

步骤S503，***监控进程判断该异常进程是否为关键进程。

这里，判断该异常进程是否为关键进程在实现的过程中可以获取该异常进程的进程属性信息，通过进程属性信息可以来确定该异常进程是关键进程还是非关键进程。如果该异常进程为关键进程，说明需要重启CPU来重新启动该异常进程，此时进入步骤S504；如果该异常进程为非关键进程，那么仅仅需要单重启该异常进程即可，不需要重启CPU，此时单启动该异常进程结束流程。

步骤S504，***监控进程通知软复位服务端进行软复位。

这里，***监控进程调用回调钩子通知软复位服务端进行软复位，此时***监控进行进入阻塞等待的状态。

步骤S505，软复位服务端向软复位客户端发送业务备份通知消息。

步骤S506，软复位客户端在备份完成后，向软复位服务端发送备份完成的通知消息。

步骤S507，软复位服务端释放信号量。

这里，软复位服务端释放信号量是为了将***监控进程唤醒，以进行后续的处理。

步骤S508，***监控进程等待备份完成后通知应用进程下电。

这里，通知应用进程下电可以理解为需要结束该应用进程，通知应用进程进行结束前必要的数据保存及其他处理。

步骤S509，应用进程通知***监控进程下电完成。

步骤S510，***监控进程通知软复位服务端进行CPU复位。

步骤S511，软复位服务端重启CPU。

本发明实施例提供的CPU重启方法与现有技术相比，在实现真正的重启CPU不中断业务的情况下，能够不依赖硬件冗余，从而减少了设备成本，减少了板间交互，进一步降低了***的复杂性。

实施例四

本实施例提供一种通信设备，图6为本发明实施例通信设备的组成结构示意图，如图6所示，所述通信设备600包括处理器601和配置为存储可执行指令的存储介质602，其中：

处理器601配置为执行存储的可执行指令，所述可执行指令包括：

接收用于重启CPU的第一通知消息；

基于所述第一通知消息，查询业务注册表，获取客户端标识；

根据所述客户端标识，向客户端发送第二通知消息，其中，所述第二通知消息用于通知所述客户端进行数据备份；

如果在预设时间内接收到所述客户端发送的备份完成的第三通知消息，控制CPU进行重启。

需要说明的是，以上通信设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果，因此不做赘述。对于本发明通信设备实施例中未披露的技术细节，请参照本发明方法实施例的描述而理解。

对应地，本发明实施例提供一种计算机存储介质，所述计算机存储介质中存储有计算机可执行指令，该计算机可执行指令配置为执行本发明其他实施例提供的CPU的重启方法。

实施例五

本发明实施例提供一种通信设备，所述通信设备600包括处理器和配置为存储可执行指令的存储介质，其中：

处理器配置为执行存储的可执行指令，所述可执行指令包括：

接收服务端发送的第二通知消息；

基于所述第二通知消息，获取与自身对应的第二业务的回调转储参数；

根据所述回调转储参数，获取所述第二业务的业务数据；

将所述业务数据存储至所述第一内存空间；

若所述业务数据存储完成，向所述服务端发送第三通知消息。

需要说明的是，以上通信设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果，因此不做赘述。对于本发明通信设备实施例中未披露的技术细节，请参照本发明方法实施例的描述而理解。

对应地，本发明实施例提供一种计算机存储介质，所述计算机存储介质中存储有计算机可执行指令，该计算机可执行指令配置为执行本发明其他实施例提供的CPU的重启方法。

本领域内的技术人员应明白，本发明的实施例可提供为方法、***、或计算机程序产品。因此，本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (9)

1.一种中央处理器CPU的重启方法，其特征在于，所述方法包括：

接收用于重启CPU的第一通知消息；

基于所述第一通知消息，查询业务注册表，获取客户端标识；

根据所述客户端标识，向客户端发送第二通知消息，其中，所述第二通知消息用于通知所述客户端通过第一内存空间进行数据备份；

如果在预设时间内接收到所述客户端发送的备份完成的第三通知消息，控制CPU进行重启；

如果没有接收到所述客户端发送的第三通知消息，获取没有完成数据备份的第一业务的第一业务属性信息，其中，所述第一业务属性信息中至少包括业务类型，所述业务类型用于反映业务的关键程度；

根据所述第一业务属性信息，判断所述第一业务是否为第一类型的业务，其中，所述第一类型的业务为关键程度系数满足预设条件的业务；

如果所述第一业务为第一类型的业务，不控制CPU进行重启，并输出重启失败的提示信息。

2.根据权利要求1所述的方法，其特征在于，在所述接收用于重启CPU的第一通知消息的步骤之前，所述方法还包括：

读取配置文件，所述配置文件中至少包括起始地址和内存空间大小；

基于所述起始地址和所述空间大小确定第一内存空间；

初始化所述第一内存空间。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收客户端发送的业务属性信息；

并将业务的备份状态添加至所述业务属性信息，保存所述业务属性信息。

4.一种CPU的重启方法，其特征在于，所述方法包括：

接收第二业务发送的业务属性信息，其中，所述业务属性信息中至少包括第二业务的标识、类型和回调转储参数；

保存所述第二业务的业务属性信息；

将所述第二业务的业务属性信息发送给服务端；

接收所述服务端发送的第二通知消息，基于所述第二通知消息，获取与自身对应的第二业务的回调转储参数；

根据所述回调转储参数，获取所述第二业务的业务数据；

将所述业务数据存储至第一内存空间；

若所述业务数据存储完成，向所述服务端发送第三通知消息，以使所述服务端接收到所述第三通知消息后控制CPU进行重启。

5.根据权利要求4中所述的方法，其特征在于，在所述将所述业务数据存储至所述第一内存空间的步骤之后，所述方法还包括：

获取所述业务数据的存储信息；

建立所述存储信息和所述第二业务的对应关系，并保存所述对应关系。

6.根据权利要求4中所述的方法，其特征在于，所述方法还包括：

接收第二业务发送的数据恢复请求，其中，所述数据恢复请求中至少携带有第二业务的标识；

根据所述第二业务的标识，获取所述第二业务对应的存储信息；

将携带有所述存储信息的数据恢复响应发送给第二业务。

7.一种通信设备，其特征在于，所述通信设备至少包括处理器和配置为存储可执行指令的存储介质，其中：

处理器配置为执行存储的可执行指令，所述可执行指令包括：

接收用于重启CPU的第一通知消息；

基于所述第一通知消息，查询业务注册表，获取客户端标识；

根据所述客户端标识，向客户端发送第二通知消息，其中，所述第二通知消息用于通知所述客户端通过第一内存空间进行数据备份；

如果在预设时间内接收到所述客户端发送的备份完成的第三通知消息，控制CPU进行重启；

如果没有接收到所述客户端发送的第三通知消息，获取没有完成数据备份的第一业务的第一业务属性信息，其中，所述第一业务属性信息中至少包括业务类型，所述业务类型用于反映业务的关键程度；

根据所述第一业务属性信息，判断所述第一业务是否为第一类型的业务，其中，所述第一类型的业务为关键程度系数满足预设条件的业务；

如果所述第一业务为第一类型的业务，不控制CPU进行重启，并输出重启失败的提示信息。

8.一种通信设备，其特征在于，所述通信设备至少包括处理器和配置为存储可执行指令的存储介质，其中：

处理器配置为执行存储的可执行指令，所述可执行指令包括：

接收第二业务发送的业务属性信息，其中，所述业务属性信息中至少包括第二业务的标识、类型和回调转储参数；

保存所述第二业务的业务属性信息；

将所述第二业务的业务属性信息发送给服务端；

接收所述服务端发送的第二通知消息；

基于所述第二通知消息，获取与自身对应的第二业务的回调转储参数；

根据所述回调转储参数，获取所述第二业务的业务数据；

将所述业务数据存储至第一内存空间；

若所述业务数据存储完成，向所述服务端发送第三通知消息，以使所述服务端接收到所述第三通知消息后控制CPU进行重启。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机可执行指令，该计算机可执行指令配置为：执行上述权利要求1至3中任一项提供的CPU的重启方法，或者，执行上述权利要求4至6中任一项提供的CPU的重启方法。