CN111385296B - 一种业务进程重启方法、装置、存储介质以及*** - Google Patents

Abstract

本申请实施例公开了一种业务进程重启方法、装置、存储介质以及***，该方法应用于安装有数据平面开发套件DPDK的***中，通过启动守护进程，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由第一状态调整为第二状态；在业务进程重启的情况下，控制所述业务进程从所述守护进程获取第二状态对应的网口；基于所述第二状态对应的网口，控制所述业务进程与DPDK连接；这样，由于将业务进程和守护进程分离，并利用守护进程管理网口的状态，可以使得业务进程在重启后直接通过守护进程提供的网口连接DPDK，无需重新初始化网口，可以加快业务进程意外挂掉后的重启速度，从而能够提高数据处理效率。

Description

一种业务进程重启方法、装置、存储介质以及***

技术领域

本申请涉及通信网络技术领域，尤其涉及一种业务进程重启方法、装置、存储介质以及***。

背景技术

数据平面开发套件(Data Plane Development Kit,DPDK)是基于Linux***运行的用于快速数据包处理的函数库和驱动集合，可以加大提高数据处理性能和吞吐量，提高数据平面应用程序的工作效率。然而，在DPDK的使用过程中，如果业务进程意外挂掉，需要重新初始化网口，然后才能接入DPDK，导致业务进程重启速度缓慢，进而降低了数据处理效率。

发明内容

有鉴于此，本申请的主要目的在于提供一种业务进程重启方法、装置、存储介质以及***，可以加快业务进程意外挂掉后的重启速度，从而能够提高数据处理效率。

为达到上述目的，本申请的技术方案是这样实现的：

第一方面，本申请实施例提供了一种业务进程重启方法，该方法应用于安装有数据平面开发套件DPDK的***中，该方法包括：

启动守护进程，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由第一状态调整为第二状态；

在业务进程重启的情况下，控制所述业务进程从所述守护进程获取第二状态对应的网口；

基于所述第二状态对应的网口，控制所述业务进程与DPDK连接。

第二方面，本申请实施例提供了一种业务进程重启装置，该业务进程重启装置包括初始化单元、获取单元和连接单元；其中，

初始化单元，配置为启动守护进程，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由第一状态调整为第二状态；

获取单元，配置为在业务进程重启的情况下，控制所述业务进程从所述守护进程获取第二状态对应的网口；

连接单元，配置为基于所述第二状态对应的网口，控制所述业务进程与DPDK连接。

第三方面，本申请实施例提供了一种业务进程重启装置，该业务进程重启装置包括存储器和处理器；其中，

存储器，用于存储能够在所述处理器上运行的计算机程序；

处理器，用于在运行所述计算机程序时，执行如第一方面所述的业务进程重启方法。

第四方面，本申请实施例提供了一种计算机存储介质，所述计算机存储介质储存有业务进程重启程序，该业务进程重启程序被至少一种处理器执行时实现如第一方面所述的业务进程重启方法。

第五方面，本申请实施例提供了一种***，该***至少包括如第二方面或第三方面所述的业务进程重启装置。

本申请实施例提供的一种业务进程重启方法、装置、存储介质以及***，该方法应用于安装有DPDK的***中，通过启动守护进程，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由第一状态调整为第二状态；在业务进程重启的情况下，控制所述业务进程从所述守护进程获取第二状态对应的网口；基于所述第二状态对应的网口，控制所述业务进程与DPDK连接；这样，由于将业务进程和守护进程分离，并利用守护进程管理网口的状态，可以使得业务进程在重启后直接通过守护进程提供的网口连接DPDK，无需重新初始化网口，能够加快重启速度，从而能够提高数据处理效率；另外，通过守护进程管理网口的状态，保证网口状态在业务进程重启前后的一致性，可以有效避免业务进程异常退出后网口状态改变而导致多产品部署主备切换的问题。

附图说明

图1为本申请实施例提供的一种业务进程重启方法的流程示意图；

图2为本申请实施例提供的另一种业务进程重启方法的流程示意图；

图3为本申请实施例提供的一种守护进程的工作流程示意图；

图4为本申请实施例提供的一种业务进程的工作流程示意图；

图5为本申请实施例提供的一种业务进程重启装置的组成结构示意图；

图6为本申请实施例提供的另一种业务进程重启装置的组成结构示意图；

图7为本申请实施例提供的一种业务进程重启装置的具体硬件结构示意图；

图8为本申请实施例提供的一种***的组成结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

数据平面开发套件(Data Plane Development Kit，DPDK)是一种基于Linux***进行的，用于快速数据包处理的函数库与驱动集合，能够极大提高数据处理性能和吞吐量，提高数据平面应用程序的工作效率。DPDK通过创建环境抽象层来为不同的工作环境创造函数库集，创建后使用者即可将自己的应用与函数库进行连接，从而绕过Linux的内核协议栈。换句话说，在Linux的内核看来，DPDK是一个普通的用户态进程，它的编译、连接和加载方式和普通程序相同，也就是说，DPDK在用户空间实现了一套数据平面来进行数据包的收发与处理。

目前部署有DPDK的网络设备、平台，位于内核层的所有网口都会被用户层中基于DPDK的应用程序接口(Application Programming Interface，API)接管，而这些网口的配置信息也会统一存储在基于DPDK的API接口文档中。所以，业务进程又包含两大步骤，即业务进程对网口进行初始化接入DPDK，然后利用DPDK的预设函数通过网口进行作业。

目前业界使用DPDK的方式主要分为两大类，数据包读写(Input&Out，IO)和业务处理通过进程分离以及数据包IO和业务处理在同一个进程内；其中，

(1)数据包IO和业务处理通过进程分离，划分小部分中央处理器(CentralProcessing Unit，CPU)出来，数据包读写进程独占，剩余核心业务进程独占。这种模式对于CPU核数较少的低端设备不合适，数据包IO进程占用的CPU处理能力被浪费，不具有全硬件平台覆盖能力；

(2)数据包IO和业务处理在同一个进程内，将DPDK的业务进程进行整合，将数据包IO和业务处理合并在统一的业务进程呃逆，根据是否有失效转移(failover)机制分成两种，存在如下缺点：对于无failover机制，业务进程由于某种原因退出后，网卡会改变状态，重新拉起时需要耗费较长的时间处理网卡初始化，业务恢复慢；对于有失效转移机制，业务进程挂掉后单独拉起，但对于某些常见的场景不适合。比如单个业务进程挂掉后，其他业务进程并不知道业务进程挂掉的信息，这时候单进程重启时显然不满足这种场景，另外采用该模型需要深度修改现有的业务进程初始化代码，对于已经架构好的DPDK***，实施难度较大。

下面将结合附图对本申请各实施例进行详细说明。

本申请的一实施例中，参见图1，其示出了本申请实施例提供的一种业务进程重启方法的流程示意图，如图1所示，该方法应用于安装有DPDK的***，该方法可以包括：

S101：启动守护进程，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由第一状态调整为第二状态；

需要说明的是，网口在使用时，需要进行硬件和软件上的准备，硬件准备就是网口是否上电，比如网线的***与拔出，只有在网口上电后网口才能进行使用；在网口进行上电后，还要进行软件上的准备，即使用网口的进程还需要对网口的状态进行初始化。在实际使用中，网口一般具有两个状态，即低电平

(down)状态和高电平(up)状态，而初始化过程就是将网口由down状态拉起为up状态，只有在up状态下，网口才能被使用。

还需要说明的是，守护进程是一类在后台运行的特殊进程，用于执行特定的***任务，其开启与结束都独立于用户终端。在本实施例中，守护进程主要用于网口状态管理，所以在守护进程启动后，就会对多个网口进行初始化，将所述多个网口由第一状态调整为第二状态，即将down状态的多个网口拉起为up状态。同时，在守护进程的生命周期内，守护进程会一直保持网口的up状态。

S102：在业务进程重启的情况下，控制所述业务进程从所述守护进程获取第二状态对应的网口；

需要说明的是，所述业务进程的本质是调用DPDK进行作业的进程，而一个业务进程内又包含多个独立的任务，一般是一个控制面任务和多个数据面任务，其中，控制面任务主要包括建立连接、监听状态、退出连接以及配置下发数据面任务，而数据面任务就是利用网口进行数据包IO的任务。所以，业务进程会通过多个网口与DPDK建立连接，一个网口和一个数据面任务相对应，所述业务进程从所述守护进程获取第二状态对应的网口实际上为多个。

还需要说明的是，实际使用中，业务进程每次与DPDK连接前都需要初始化网口，即将网口状态由down状态拉到up状态，然后再通过初始化后的网口连接DPDK进行作业。如果业务进程意外挂掉，那么业务进程所使用的多个网口都会从工作的up状态变成down状态，如果在多产品联合部署的***中时还会引起主备***的切换；然后，业务进程重启时需要将所有的网口从down状态再次拉起到up状态，然后再连接DPDK进行作业，这个过程导致业务进程重启速度慢，进而降低了数据处理效率。

基于此，在本申请实施例中，通过提供独立的用于管理网口状态的守护进程，即守护进程与业务进程分离，而守护进程主要用来维持网口的up状态，这时候如果业务进程意外挂掉，那么守护进程将会继续维持网口的up状态。这样，在业务进程重启的情况下，业务进程只要从守护进程获取网口up状态的网口(获取第二状态对应的网口)，就可以实现业务进程与DPDK之间的连接，避免了业务进程重启时对网口的重新初始化，加快了重启速度。

S103：基于所述第二状态对应的网口，控制所述业务进程与DPDK连接。

需要说明的是，由于守护进程与业务进程分离，这时候业务进程可以直接从守护进程获取第二状态对应的网口，也即up状态对应的网口，然后实现业务进程与DPDK连接，此时无需重新将网口的状态从第一状态调整为第二状态，所以加快了重启速度。

还需要说明的是，DPDK在很多公司已经进行广泛使用以提高数据包的处理速度，而本实施例的提供的业务进程重启方法，即独立提供维持网口up状态的守护进程，无需深度修改DPDK的原始程序，可以直接对已经架构好的DPDK进行升级，加快业务进程的重启速度，进而提高数据的处理效率。

本实施例提供了一种业务进程重启方法，通过启动守护进程，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由第一状态调整为第二状态；在业务进程重启的情况下，控制所述业务进程从所述守护进程获取第二状态对应的网口；基于所述第二状态对应的网口，控制所述业务进程与DPDK连接；这样，由于将业务进程和守护进程分离，并利用守护进程管理网口的状态，可以使得业务进程在重启后直接通过守护进程提供的网口连接DPDK，无需重新初始化网口，能够加快重启速度，从而能够提高数据处理效率；另外，通过守护进程管理网口的状态，保证网口状态在业务进程重启前后的一致性，可以有效避免业务进程异常退出后网口状态改变而导致多产品部署主备切换的问题。

本申请的另一实施例中，参见图2，其示出了本申请实施例提供的另一种业务进程重启方法的流程示意图。如图2所示，该方法应用于安装有数据平面开发套件DPDK的***中，该方法可以包括：

S201：启动守护进程，控制所述守护进程初始化DPDK，获取多个网口的管理权限；

需要说明的是，对于安装有DPDK的***而言，DPDK会接管网口的管理，所以在启动守护进程后，需要控制所述守护进程连接DPDK进行初始化，获取多个网口的管理权限。

需要说明的是，对于大部分的DPDK的使用场景，为了达到更高的性能都采用多进程的形式运行在不同的核心线程上，此时为了保证多个进程的关键信息(比如内存资源)一致，需要将公共的数据储存在同一个文件中，这样任何一个进程对数据的修改都可以影响到其他进程。基于此，多进程***中，不同的进程又可分为两种角色，即primary角色和secondary角色；其中，通过primary角色运行的进程称为primary进程，能够创建可供其他进程共享的关键资源；通过secondary角色运行的进程称为secondary进程，只能使用由primary进程创建的关键资源而不可以创建关键资源；换句话说，secondary进程需要在primary进程运行之后启动，无法独立启动。基于此，本申请实施例中的守护进程在架构上属于primary进程，需要以primary角色启动。

进一步地，在一些实施例中，S201还可以包括：

控制所述守护进程导出共享数据结构；其中，所述共享数据结构用于在业务进程和守护进程之间共享所述多个网口的状态信息。

需要说明的是，作为primary进程，守护进程能够创建与其他进程共享的关键资源，在本实施中，所述共享数据结构就是所述守护进程创建的与所述业务进程共享网口状态信息的资源，也即业务进程通过在共享数据结构中读取、写入信息，实现业务进程和守护进程的信息共享。更进一步的，由于守护进程主要用于对网口状态的管理，所以该共享数据结构主要用于所述多个网口的状态信息(即每个网口的网口状态是up状态和down状态)；同时，共享数据结构能够有效减少数据的拷贝量，降低***运行负荷。

还需要说明的是，DPDK作为多进程组件，本身具有内在的共享数据机制，用于DPDK的多进程之间共享数据，这与守护进程所导出的共享数据结构是相互独立的，也就是说，守护进程所导出的共享数据结构是非DPDK共享内存结构，是向内核申请的单独数据空间。

S202：基于所获取的管理权限，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由第一状态调整为第二状态；

需要说明的：守护进程统一对多个网口进行初始化，即拉起down状态的多个网口得到up状态的多个网口，使得所有网口都处于随时与业务进程连接进行作业的状态。

S203：控制所述业务进程从所述守护进程获取第二状态对应的网口；

需要说明的是，由于业务进程需要从守护进程获取第二状态对应的网口，也就是获取up状态的网口连接DPDK，所以需要在所述守护进程启动后连接守护进程，然后连接DPDK。在这里，如果是业务进程首次启动，需要连接守护进程然后获取up状态网口；如果业务进程是在进行重启，那么存在两种情况，第一种情况下，业务进程仍然与守护进程保持连接，只是业务进程与DPDK的连接挂掉了，那么可以直接从守护进程获取网口连接DPDK；如果业务进程挂掉时与守护进程的连接也断开了，那么业务进程需要重新连接守护进程，然后得到网口连接DPDK。

进一步地，在一些实施例中，在S203之前，该方法还可以包括：

控制所述业务进程连接所述守护进程，以使得所述业务进程获取所述共享数据结构；

根据所述共享数据结构，控制所述业务进程从所述共享数据结构中获取所述多个网口的原始状态；其中，所述原始状态为所述多个网口中每一网口在所述业务进程初始化之后的第二状态；

通过所述业务进程获取所述多个网口中每一网口的当前状态，并将所述多个网口中每一网口的当前状态与对应的原始状态进行比较；

若其中一个网口的当前状态与原始状态不同，则将所述其中一个网口以及对应的当前状态通知前台程序，以使得所述其中一个网口的当前状态与原始状态相同。

需要说明的是，在业务进程意外挂掉后进行重启的情况下，由于守护进程负责网口状态的管理，所以网口并不会因为业务进程挂掉而从up状态变为down状态，所以网口的状态理论上仍然是up状态。但是，如果在业务进程挂掉期间，设备产生了硬件故障或者错误，可能导致某些网口的状态变为down状态，此时需要工作人员进行干预才能恢复网口的状态。基于此，在业务进程重启的情况下，需要判断网口的状态是否与第二状态一致；如果网口的状态发生了变化，说明可能在业务进程挂掉的器件产生了硬件故障或者软件错误，此时需要通知前台人员进行干预；如果网口的状态没有改变，那么可以通过该网口连接DPDK继续作业；这样，业务进程退出后也能感知网口状态的变化，这样在多数据面任务中，业务进程重启后，数据面任务也能感知到其他数据面任务在业务进程退出后的中断。

还需要说明的是，对于业务进程来说，需要通过多个网口与DPDK进行连接；那么业务进程重启时，如果部分网口的状态为up状态，部分网口的状态为down状态，那么业务进程是会通过那些up状态的网口恢复与DPDK的连接，然后在工作人员将那些down状态的网口拉起为up状态后，业务进程再通过那些网口与DPDK进行连接。

需要说明的是，业务进程和守护进程可以通过多种方式建立连接，比如业务进程通过守护进程预留的预设接口连接守护进程，进而连接DPDK进行工作；预留接口可以采用Linux Unix域套接字，Linux Unix域套接字是一种用于不同主机通信的高效率连接方法，当然也可以采用其他接口，本实施例不做限定。

在采用Linux Unix域套接字作为预留接口的情况下，只要守护进程已经接管多个网口的管理权限，那么业务进程通过Linux Unix域套接字发起的连接已经可以被守护进程获取，也就是说，理论上只要守护进程接管网口监听之后，业务进程就可以通过套接字接入守护进程，然而此时守护进程可能并没有做好相应的准备，比如守护进程还没有拉起所有的网口或者守护进程还没有完成上一退出的业务进程的遗留任务。

具体地，在一些实施例中，所述控制所述业务进程连接所述守护进程，可以包括：

控制所述业务进程向所述守护进程发送连接请求；

基于所述守护进程对所述连接请求的响应，若所述业务进程接收到所述守护进行反馈的响应消息，则确定所述业务进程与所述守护进程连接成功，执行所述控制所述业务进程从所述守护进程获取第二状态对应的网口的步骤。

需要说明的是，对于守护进程来说，在其启动之后，业务进程就可以通过预设接口接入守护进程，但是守护进程首次启动之后需要对所有网口进行初始化，可能并没有做好与业务进程连接的准备；同时在一些实施例中，守护进程还负责内存池的维护和回收，如果守护进程还没有处理完毕上一退出的业务进程的遗留问题，此时并不适合再次接入新的业务进程，所以在此设置响应机制，即业务进程通过预设接口连接守护进程后，如果守护进程反馈预设的响应字段，则确认连接成功；如果没有收到预设的响应字段，那么守护进程不接受业务进程的连接，业务进程将持续请求连接，直至接收到守护进程反馈预设的响应字段。具体的响应字段本申请实施例不做限定。

还需要说明的是，业务进程获取所述共享数据结构的方式可以有多种，诸如包括有内存映射、共享内存等，其中，内存映射至少包括mmap(一种内存映射文件的方法)，共享内存至少包括分为Posix共享内存区和System V共享内存区，Posix表示可移植操作***接口(Portable Operating System Interface)，Posix标准定义了操作***应该为应用程序提供的接口标准，System V又被称为AT&T System V，是Unix操作***众多版本中的一支。通过这些获取共享数据结构的方式，业务进程可以直接获取守护进程的监听的网口状态，同时也可以将感知的网口状态写入共享数据结构使得守护进程感知，避免重复性的数据拷贝，具有很高的操作效率。

S204：基于所述第二状态对应的网口，控制所述业务进程对DPDK进行初始化；

需要说明的是，业务进程通过所述第二状态对应的网口以secondary角色连接DPDK，即业务进程通过守护进程提供的up状态网口连接DPDK，而不是先对网口进行初始化然后再连接DPDK，所以业务进程的重启速度会明显提高。

S205：控制所述业务进程进行控制面作业和数据面作业；其中，所述控制面作业是调用DPDK的应用程序编程接口(可以用DPDK API表示)执行第一任务，所述数据面作业是调用DPDK API执行第二任务；其中，所述第一任务至少包括为所述第二状态对应的网口配置第二任务，所述第二任务至少包括利用其中一个所述第二状态对应的网口执行收发数据包任务；

需要说明的是，在业务进程接入DPDK之后，就可以按照常规流程调用DPDK中的预设函数进行相应作业，主要作业内容包括两大部分，即控制面作业(数据分配、下发以及其他控制层面的消息处理)和数据面作业(数据包处理、收发)，一般情况下，一个业务进程仅含有一个控制面作业，但是可以包括多个数据面作业，一般一个数据面作业是指利用一个网口执行收发数据的任务；同时，数据面作业是根据控制面作业所分配的任务进行的。

在一些实施例中，在业务进程进行正常作业的情况下，该方法还可以包括：

若所述守护进程监听到其中一个网口的状态变化，则控制所述守护进程向所述业务进程发送通知信息；

根据所述通知信息，控制所述业务进程获取所述状态变化的其中一个网口对应的当前状态，并将所获取的其中一个网口以及对应的当前状态记录在所述共享数据结构中。

需要说明的是，由于守护进程只能在primary层面上监听到网口状态改变，而不能直接调用DPDK API获取网口的实际状态，所以当守护进程监听到网口状态改变时，需要通知业务进程，业务进程通过调用DPDK API获取网口的实际状态，写入共享数据结构。其中，守护进程向业务进程发送消息，可以通过多种方式实现，比如守护进程预留和业务进程沟通的消息通道；也可以在共享数据结构中单独留出数据空间用于通知消息的交互。在业务进程接收到守护进程的通知消息后，可以通过调用DPDK API获取网口实际状态并记录在共享数据结构中，这样守护进程也得知了网口实际状态。

S206：在所述守护进程监听到所述业务进程从所述守护进程退出的情况下，通过所述守护进程判断所述业务进程调用的DPDK API是否调用完成；

这里，对于S206来说，如果DPDK API调用完成，那么可以执行S207；如果DPDK API没有调用完成，那么可以返回执行S203。

需要说明的是，如果业务进程退出，守护进程还有一个重要的任务是回收业务进程调用的内存资源，以便分配给其他进程。但是业务进程的退出存在两种情况，业务进程的正常退出和意外挂掉，在业务进程正常退出的情况下，即可进行内存资源回收；在业务进程意外挂掉的情况下，说明业务进程还需要重连以完成后续工作(即使业务进程不重连也需要其他进程或者上级对其进行处理)，此时不可进行内存资源回收，而通过DPDK API的调用情况可以很好的区分这两种情况。

还需要说明的是，DPDK API，即应用程序编程接口，是DPDK一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节，业务进程正是通过调用DPDK API进行作业，在业务进程正常退出，其DPDK API必然已经调用完成；而业务进程意外退出时，由于作业没有完毕，所以其调用的DPDKAPI仍在调用中。

还需要说明的是，在DPDK API没有调用完成的情况下，这时候发生了业务进程断开的情况，可以认为是业务进程挂掉，需要再次重启，此时守护进程等待业务进程重新连接，然后业务进程通过守护进程提供的工作网口再次接入DPDK，继续作业。

进一步地，在一些实施例中，判断DPDK API有没有调用完成可以通过DPDK API序列号保护机制进行，在调用DPDK API的情况下，所述方法还包括以下步骤：

在调用DPDK API之前，控制所述业务进程将DPDK API的序列号加1；

在调用DPDK API之后，控制所述业务进程将DPDK API的序列号加1；

若DPDK API的序列号是偶数，则将判断结果确认为所述业务进程所调用的DPDKAPI调用完成。

需要说明的是，通过序列号保护机制，DPDK API的初始值为0，如果DPDKAPI的序列号为奇数时，说明其还在调用中；如果DPDK API的序列号为偶数，说明处于未被调用的状态中。当然，如果DPDK API的初始值为奇数，则判断方式相反，即判断业务进程所调用的DPDKAPI的序列号是否为奇数，如果是，则调用完成，这种实施方式也在本申请实施例的保护范围之内。

还需要说明的是，在业务进程中，数据面作业需要对具体数据进行处理，处理时将会对使用的那部分内存进行上锁，避免使用中其他进程调用那部分内存，如果没有序列号机制，业务进程有可能在对守护进程的DPDK共享内存加锁后挂掉，业务进程再次启动后就会造成死锁；控制面作业一般是对于控制层面的处理量而不涉及具体数据包的收发，所以不涉及对内存的锁定，所以，在控制面作业时，可以不采用序列号保护机制，仅在数据面作业时对激活序列号保护机制。

S207：控制所述守护进程回收所述业务进程使用的内存资源；

需要说明的而是，如果退出的业务进程所调用的DPDK API调用完成，则确认业务进程是正常退出，然后回收分配给业务进程使用的内存资源。

还需要说明的是，在实际使用中，在业务进程退出后，其使用的内存资源并不一定都可以被回收。比如，业务进程中的数据面作业存在收发数据包任务，可能该作业已经接收数据包将其存储在被分配的内存资源中，然后按照发送数据包的命令将任务绑定在网口队列中，等待网口将其转发，此时，业务进程已经完成相应作业可以正常退出，但是存储有待发送数据包的内存资源是不可以进行回收的，需要保持分配状态，直到网口完成相应任务才会释放内存资源。

具体地，在在一些实施例中，S207可以包括：

判断内存资源是否属于绑定在网口的待执行第二任务队列所使用的内存资源；其中，所述第二任务队列为所述第二任务组成的队列；

若内存资源不属于绑定在网口的待执行第二任务队列所使用的内存资源，则控制所述守护进程回收所述内存资源。

这样，能够保证网口任务队列中涉及的内存资源不会被回收，保证网口任务队列可以正常进行。

本实施例提供了一种业务进程重启方法，通过启动守护进程，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由第一状态调整为第二状态；在业务进程重启的情况下，控制所述业务进程从所述守护进程获取第二状态对应的网口；基于所述第二状态对应的网口，控制所述业务进程与DPDK连接；这样，由于将业务进程和守护进程分离，并利用守护进程管理网口的状态，可以使得业务进程在重启后直接通过守护进程提供的网口连接DPDK，无需重新初始化网口，能够加快重启速度，从而能够提高数据处理效率；同时，通过守护进程管理网口的状态，保证网口状态在业务进程重启前后的一致性，可以有效避免业务进程异常退出后网口状态改变而导致多产品部署主备切换的问题；另外，通过DPDK API保护机制，能够进一步确认业务进程的退出状态，防止死锁的出现。

本申请的又一实施例中，参见图3，其示出了本申请实施例提供的一种业务进程重启方法中守护进程的工作流程示意图；如图3所示，该方法应用于安装有DPDK的***中，其中，守护进程的工作流程包括：

S301：守护进程启动；

需要说明的是，在接收到启动命令后，首先启动守护进程，进行网口的初始化和管理；一般在网口完成上电后，守护进程就会随之启动。

S302：以primary角色初始化DPDK；

需要说明的是，守护进程调用DPDK初始化接口，以Primary角色初始化，接管多个网口的管理权限。

S303：导出共享数据结构；

需要说明的是，守护进程所导出的共享数据结构是非DPDK的共享数据结构(DPDK有自己的共享内存机制，用于DPDK内部任务中共享数据)，而此处的共享数据结构是守护进程向内核申请的、用于和业务进程进行共享数据的一块内存。

S304：初始化所有网口；

需要说明的是，在现有技术中，初始化网口需要耗费比较长的时间，即每次业务进程重启后都需要耗费较长时间拉起网口，使得业务进程重启比较慢。在本申请中，在守护进程启动时即完成对所有网口的初始化，所以业务进程重启时不再需要对网口初始化，重启速度得到了较大提升，业务进程挂掉后的重启时间基本在1秒左右，用户层面几乎无感知。

S305：监听业务进程接入；

需要说明的是，完成前述步骤后，此时初始化已完成，守护进程等待业务进程连接。

S306：判断业务进程是否接入；

这里，对S306来说，如果判断结果为是，那么可以执行S307；如果判断结果为否，那么可以返回执行S305。

S307：向业务进程反馈响应消息；

这里，对于S306来说，如果判断结果为是，那么可以执行S307；如果判断结果为否，那么可以返回执行S305。

需要说明的是，若监听到业务进程的接入请求，同时守护进程已经做好了与业务进程的连接准备，则守护进程会应答业务进程的接入请求，即向业务进程反馈响应消息。因为在守护进程接管网口监听后，业务进程已经可以发起对守护进程的接入请求，而此时守护进程可能仍在做其他的初始化准备(工作网口等)，所以需要得到守护进程的响应后业务进程才可以接入守护进程。

S308：基于预留的消息通道处理业务进程消息；

需要说明的是，此处通过预留的消息通道处理业务进程的消息，用于通知业务进程网口状态改变或者获取业务进程从守护进程退出的消息。

S309：向业务进程上报网口状态改变；

需要说明的是，对于守护进程来说，其只能监听到网口状态改变的消息，无法直接调用DPDK API核实网口状态，所以守护进程需要将监听到的网口状态消息告知业务进程，然后业务进程再调用相关DPDK API获取网口实际状态。

S310：监听业务进程从守护进程退出；

这里，对于S310来说，如果监听到业务进程从守护进程退出，那么可以执行S311；如果没有监听到业务进程从守护进程退出，那么可以返回执行S308。

需要说明的是，在守护进程监测到业务进程退出的情况下，可能存在两种情况，一种是业务进程意外挂掉，此时守护进程将等待业务进程重新连接；另一种是业务进程正常退出，此时守护进程需要进行内存资源的回收和重置。在此，监听业务进程是否断开可以通过利用“监听业务进程接入”所使用的渠道进行，也可以使用预留的消息通道，也可采用共享数据结构。

S311：判断DPDK API保护序列号是否为偶数；

这里，对于S311来说，如果判断结果为是，那么可以执行S312；如果判断结果为否，那么可以执行S314。

需要说明的是，如果发现业务进程退出，首先检查DPDK API调用的完整性，如果业务进程的本地序列号是奇数，说明DPDK API还处于调用过程中，业务进程属于意外挂掉，此时守护进程无法自行退出，退出后会被***重新拉起，守护进程需要等待其他干预或者最后退出。

S312：重置mbuf内存池；

需要说明的是，内存缓冲组件(memory buffer，mbuf)是一种数据结构，主要用于保存在进程和网络接口间相互传递的用户数据，mbuf内存池则是在内存预先分配出来用于mbuf存储的空间，可以认为是一块内存。

需要说明的是，如果DPDK API序列号检查满足条件，守护进程需要回收给业务进程之前使用的内存以供其他进程使用。此处，如果业务进程仍有一些绑定在网口队列的任务，那么这些任务所调用的内存并不能被回收，而需要保持其分配状态，以防止任务失败。所以，采用以下步骤重置mbuf内存池：

(a)先遍历所有mbuf的内存块，清除标志；这样，将所有mbuf的标志清除，此处的标志是指业务进程调用mbuf内存块时产生的标志；

(b)遍历所有网卡驱动的接收/发送(receive/transmit，rx/tx)队列，给mbuf打上标志；这样，单独给网口队列内存块中的任务所调用的mbuf内存块单独打上标志；

(c)重新初始化DPDK的mbuf内存池；

(d)给mbuf内存池安装mbuf元素，通过地址空间遍历mbuf，如果没有打标志，就安装到内存池，若有打标志，就清除标志，不安装。这样，将没有打标志的mbuf内存块恢复到内存池中，如果打了标志，证明其还在使用中，就不恢复，同时消除标志。此处，清除标志的原因是，这里的标志指示为了区分其是不是在网口队列的任务所调用的内存块，至此已经发挥完作用，无需继续存在。

S313：确认mbuf内存池重置成功；

需要说明的而是，如果mbuf内存池重置成功，那么守护进程完成对此业务进程的工作，可以继续回到S305，等待下一业务进程接入，也可以执行退出动作；需要说明的而是，重置不成功，说明网口队列中仍有调用的内存块，需要等待网口将任务执行完成，回收所有的内存块，确认mbuf内存池重置成功，可以继续回到S305，等待下一业务进程接入，也可以执行退出动作。

S314：守护***退出。

需要说明的而是：守护***作为primary进程，一般和整体***的运行状态一致，即随着整体***的关闭而退出服务。同时，如果DPDK API序列号不是偶数且内存重置不成功时，守护进程只能等待外部干预或者最后退出。

这样，mbuf内存池可以正确回收之前被使用的mbuf，并且保证驱动队列中的mbuf处于被分配状态。

本实施例提供了一种业务进程重启方法，对前述实施例的具体实现进行了详细阐述，从中可以看出，通过前述实施例的技术方案，由于将业务进程和守护进程分离，并利用守护进程管理网口的状态，可以使得业务进程在重启后直接通过守护进程提供的网口连接DPDK，无需重新初始化网口，能够加快重启速度，从而能够提高数据处理效率；另外，通过守护进程管理网口的状态，保证网口状态在业务进程重启前后的一致性，可以有效避免业务进程异常退出后网口状态改变而导致多产品部署主备切换的问题；同时，守护进程还具有内存管理的功能，能够保证业务进程退出后使用的内存被回收，增加了内存的使用效率。

本申请的又一实施例中，参见图4，其示出了本申请实施例提供的一种业务进程重启方法中业务进程的工作流程示意图。如图4所示，该方法应用于安装有DPDK的***中，其中，业务进程的工作流程包括：

S401：业务进程启动；

需要说明的是，启动业务进程，业务进程可以与守护进程同步启动，也可以在守护进程启动之后进行启动。

S402：连接守护进程；

需要说明的是，业务进程本质是守护进程的用户，启动后通过UNIX域套接字连接守护进程。

S403：判断是否收到响应；

这里，对于S403来说，如果判断结果为否，那么可以返回执行S402；如果判断结果为是，那么可以执行S404。

需要说明的是，在监听到业务进程的接入请求的情况下，守护进程需要应答客户端接入请求。因为在守护进程接管网口监听后，说明业务进程已经可以发起对守护进程的接入请求，而此时守护进程可能仍在做其他的初始化准备(工作网口等)，所以需要得到守护进程的响应后业务进程才可以接入守护进程。所以如果业务进程没有得到守护进程的响应命令字，需要重新连接，直至接收到守护进程的相应机制。这种请求响应机制能保证守护进程在资源初始化和回收重置期间，业务进程不能使用共享数据结构，防止了内存被破坏的可能。

S404：映射共享数据结构；

需要说明的是，业务进程通过System-v内存映射的方式映射共享数据结构，读取守护进程导出的共享内存配置，以便于与守护进程共享网口状态信息。其中，System-v内存映射是一种内存共享的实现方式，通过映射特文件实现进程间的共享内存通信，当然这不是唯一的，Posix共享内存或者mmap内存映射都是可以选择的方式。

S405：通过守护进程提供网口以secondary角色进行DPDK初始化；

需要说明的是，在此，业务进程是通过守护进程提供的已工作网口进行连接DPDK，以secondary角色进行DPDK的初始化。由于网口已经由守护进程上电，这里不需要再拉起网口，大大节省了初始化时间。

S406：从共享数据结构中获取网口状态；

需要说明的是，在守护进程监听到网口状态改变时，会通知业务进程，业务进程会感知到的网口状态并将网口状态记录在共享数据结构中，再次启动后从共享内存中读取上次退出前保存的状态。这样设计可以保证在业务进程退出后，网口中断事件也能在业务进程再次启动后被通知，比如，业务进程退出前网口状态为up状态，若业务进程重启后发现网口状态为down状态，则在业务进程退出后，网口出现中断事件，需要通知前台人员进行干预，将该网口的网口状态恢复为up状态。

S407：判断是否为控制面任务；

这里，对于S407来说，如果判断结果是控制面任务，那么可以执行S408；如果判断结果是数据面任务，那么可以执行S411。

需要说明的是，进行完前述步骤业务进程开始进入常规作业，根据接收到的任务是否是控制面执行不同的任务，数据面执行数据收发任务，控制执行管理和配置下发任务。

S408：进行网口队列绑定；

需要说明的是，对于控制面任务，其中一个重要的部分是给每个数据面分配任务(每个数据面通过一个网口执行数据面任务)。实际使用中，在一台设备上同时存在多个CPU进行任务的处理，对于DPDK运行的环境，一般采用非一致存储器访问(Non Uniform MemoryAccess Architecture，NUMA)，特点如下：(1)CPU和本地内存拥有更小的延迟与更大的带宽；(2)整个内存可作为一个整体，任何CPU都能访问，跨本地内存访问相对于访问本地内存慢一些；(3)每个CPU可以有本地总线，和内存一样，访问本地总线延迟低，吞吐率高。也就是说，NUMA通过提供分离的存储器给各个处理器，避免当多个处理器访问同一个存储器产生的性能损失，在这种使用环境下，对于涉及到分散的数据的应用(在服务器和类似于服务器的应用中很常见)，NUMA可以通过一个共享的存储器提高性能至n倍，而n大约是处理器(或者分离的存储器)的个数。

在支持NUMA的多CPU***上会产生一个问题，某一个CPU对不在该CPU所属NUMA节点上的内存将比访问在该CPU所属NUMA节点上的内存花费更长的时间，这是由于它们相对于执行所述内存访问的CPU所在的物理位置不同，所以需要尽可能避免在一个CPU上执行的线程却在无意中访问属于非本地NUMA节点的内存。基于此，在业务进程进行网口队列绑定的情况下，需要尽可能将任务绑定在其无需跨NUMA节点的处理器上以及相应的网口的数据面上，而DPDK的本身包括对NUMA节点的感知，所以业务进程需要将网口队列按NUMA亲和性指派给绑定在各个中央处理器核心上的数据进程，并保证均匀性。

S409：处理网口配置消息；

需要说明的是，处理来自配置中心的网口配置下发消息，比如基于媒体存取控制位址(Media Access Control Address，MAC)地址、虚拟局域网(Virtual Local AreaNetwork，VLAN)进行任务下发等，如果业务进程执行下发任务，那么可能会面对多个设备(包括虚拟设备)，而每个设备的标识(或者称为地址)就是根据MAC地址或者VLAN。

还需要说明的是，此处还包括对守护进程发送的网口状态改变的通知消息处理，即如果接收到来自守护进程的通知消息，调用DPDK API感知网口的实际状态。

S410：检查退出标志位；

需要说明的是，退出标志位是业务进程收到退出信号后设置的标志，即如果业务进程检查到退出标志位，即可执行退出操作，用来保证进程平滑退出，不会挂在DPDK API中。

S411：等待开工信号；

需要说明的是，对于数据面任务需要等待控制面任务完成对网口队列绑定任务才能按照网口任务队列进行工作。

S412：调用DPDK API进行作业；

需要说明的是，接收到开工信号后，业务进程将调用DPDK API进行相应作业，并对DPDK API的序列号进行更新，方便后续检查DPDK API是否调用完成；以接收数据包的任务为例，调用收包API的函数rte_eth_rx_burst()之前，需要将本进程DPDK API保护序列号(可以用local_seq表示)加1，调用之后再加1，这样保证如果在DPDK API调用过程中数据进程意外挂掉了，守护进程在资源回收前能检测到这个异常，从而保证内存回收的正确性。

如果没有序列号机制，业务进程有可能在对守护进程的DPDK共享内存加锁后挂掉，业务进程再次启动后就会造成死锁。

S413：检查退出标志位；

这里，对S413来说，如果检查到退出标志位，那么可以执行业务进程的退出，如果没有检查到退出标志位，那么可以返回执行S411。

需要说明的是，退出标志位是业务进程收到退出信号后设置的标志，即如果业务进程检查到退出标志位，即可执行退出操作，用来保证进程平滑退出，不会挂在DPDK API中。

本实施例提供了的一种业务进程重启方法，对前述实施例的具体实现进行了详细阐述，从中可以看出，通过前述实施例的技术方案，由于将业务进程和守护进程分离，并利用守护进程管理网口的状态，可以使得业务进程在重启后直接通过守护进程提供的网口连接DPDK，无需重新初始化网口，能够加快重启速度，从而能够提高数据处理效率；另外，通过守护进程管理网口的状态，保证网口状态在业务进程重启前后的一致性，可以有效避免业务进程异常退出后网口状态改变而导致多产品部署主备切换的问题；同时，守护进程还具有内存管理的功能，能够保证业务进程退出后使用的内存被回收，增加了内存的使用效率。

本申请的再一实施例中，参见图5，其示出了本申请实施例提供的一种业务进程重启装置50的组成结构示意图。如图5所示，该业务进程重启装置50包括初始化单元501、获取单元502和连接单元503；其中，

初始化单元501，配置为启动守护进程，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由第一状态调整为第二状态；

获取单元502，配置为在业务进程重启的情况下，控制所述业务进程从所述守护进程获取第二状态对应的网口；

连接单元503，配置为基于所述第二状态对应的网口，控制所述业务进程与DPDK连接。

在上述方案中，所述初始化单元501，还配置为控制所述守护进程初始化DPDK，获取多个网口的管理权限；控制所述守护进程导出共享数据结构；其中，所述共享数据结构用于在业务进程和守护进程之间共享所述多个网口的状态信息；基于所获取的管理权限，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由第一状态调整为第二状态。

在上述方案中，所述获取单元502，还配置为控制所述业务进程连接所述守护进程，以使得所述业务进程获取所述共享数据结构；

根据所述共享数据结构，控制所述业务进程从所述共享数据结构中获取所述多个网口的原始状态；其中，所述原始状态为所述多个网口中每一网口在所述业务进程初始化之后的第二状态；通过所述业务进程获取所述多个网口中每一网口的当前状态，并将所述多个网口中每一网口的当前状态与对应的原始状态进行比较；若其中一个网口的当前状态与原始状态不同，则将所述其中一个网口以及对应的当前状态通知前台程序，以使得所述其中一个网口的当前状态与原始状态相同。

本申请的再一实施例中，参见图6，其示出了本申请实施例提供的另一种业务进程重启装置50的组成结构示意图。如图6所示，该业务进程重启装置50还可以包括监听单元504，配置为若所述守护进程监听到其中一个网口的状态变化，则控制所述守护进程向所述业务进程发送通知信息；根据所述通知信息，控制所述业务进程获取所述状态变化的其中一个网口对应的当前状态，并将所获取的其中一个网口以及对应的当前状态记录在所述共享数据结构中。

在上述方案中，所述连接单元503，还配置为基于所述第二状态对应的网口，控制所述业务进程对DPDK进行初始化，以实现所述业务进程与DPDK之间的连接。

在上述方案中，参见图6，该业务进程重启装置50还可以包括作业单元505，配置为控制所述业务进程进行控制面作业和数据面作业；其中，所述控制面作业是调用DPDK的应用程序编程接口(DPDK API)执行第一任务，所述数据面作业是调用DPDK API执行第二任务；其中，所述第一任务至少包括为所述第二状态对应的网口配置第二任务，所述第二任务至少包括利用其中一个所述第二状态对应的网口执行收发数据包任务。

在上述方案中，参见图6，该业务进程重启装置50还可以包括退出单元506，配置为在所述守护进程监听到所述业务进程从所述守护进程退出的情况下，通过所述守护进程判断所述业务进程调用的DPDK API是否调用完成；若判断到所述业务进程调用的DPDK API调用完成，则控制所述守护进程回收所述业务进程使用的内存资源。

在上述方案中，所述作业单元505，还配置为在调用DPDK API之前，控制所述业务进程将DPDK API的序列号加1；在调用DPDK API之后，控制所述业务进程将DPDK API的序列号加1；以及

通过所述守护进程判断所述业务进程所调用的DPDK API的序列号是否为偶数；若DPDK API的序列号是偶数，则将判断结果确认为所述业务进程所调用的DPDK API调用完成。

在上述方案中，所述获取单元502，还配置为控制所述业务进程向所述守护进程发送连接请求；基于所述守护进程对所述连接请求的响应，若所述业务进程接收到所述守护进行反馈的响应消息，则确定所述业务进程与所述守护进程连接成功，执行所述控制所述业务进程从所述守护进程获取第二状态对应的网口的步骤。

本申请实施例提供的一种业务进程重启装置，该业务重启装置包括初始化单元、获取单元和连接单元，从而实现启动守护进程，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由第一状态调整为第二状态；在业务进程重启的情况下，控制所述业务进程从所述守护进程获取第二状态对应的网口；基于所述第二状态对应的网口，控制所述业务进程与DPDK连接；这样，由于将业务进程和守护进程分离，并利用守护进程管理网口的状态，可以使得业务进程在重启后直接通过守护进程提供的网口连接DPDK，无需重新初始化网口，能够加快重启速度，从而能够提高数据处理效率；另外，通过守护进程管理网口的状态，保证网口状态在业务进程重启前后的一致性，可以有效避免业务进程异常退出后网口状态改变而导致多产品部署主备切换的问题。

可以理解地，在本实施例中，“单元”可以是部分电路、部分处理器、部分程序或软件等等，当然也可以是模块，还可以是非模块化的。而且在本实施例中的各组成部分可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

所述集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

因此，本实施例提供了一种计算机存储介质，该计算机存储介质存储有业务进程重启程序，所业务进程重启程序被至少一个处理器执行时实现前述实施例中任一项所述的方法的步骤。

基于上述业务进程重启装置50的组成以及计算机存储介质，参见图7，其示出了本申请实施例提供的一种业务进程重启装置50的具体硬件结构示例，可以包括：通信接口601、存储器602和处理器603；各个组件通过总线***604耦合在一起。可理解，总线***604用于实现这些组件之间的连接通信。总线***604除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图7中将各种总线都标为总线***604。其中，通信接口601，用于在与其他外部网元之间进行收发信息过程中，信号的接收和发送；

存储器602，用于存储能够在处理器603上运行的计算机程序；

处理器603，用于在运行所述计算机程序时，执行：

启动守护进程，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由第一状态调整为第二状态；

在业务进程重启的情况下，控制所述业务进程从所述守护进程获取第二状态对应的网口；

基于所述第二状态对应的网口，控制所述业务进程与DPDK连接。

可以理解，本申请实施例中的存储器602可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data RateSDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步链动态随机存取存储器(Synchronous link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。本申请描述的***和方法的存储器602旨在包括但不限于这些和任意其它适合类型的存储器。

而处理器603可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器603中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器603可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(APPlication Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器602，处理器603读取存储器602中的信息，结合其硬件完成上述方法的步骤。

可以理解的是，本申请描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(APPlication Specific Integrated Circuits，ASIC)、数字信号处理器(Digital SignalProcessing，DSP)、数字信号处理设备(DSP Device，DSPD)、可编程逻辑设备(ProgrammableLogic Device，PLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本申请所述功能的其它电子单元或其组合中。

对于软件实现，可通过执行本申请所述功能的模块(例如过程、函数等)来实现本申请所述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。

可选地，作为另一个实施例，处理器603还配置为在运行所述计算机程序时，执行前述实施例中任一项所述的方法的步骤。

基于上述业务进程重启装置50的组成以及硬件结构示例，参见图8，其示出了本申请实施例提供的一种***70的组成结构示意图。如图8所示，所述***70至少包括前述实施例中任一项所述的业务进程重启装置50。其中，该***中还安装有DPDK，能够将业务进程和守护进程分离，并利用守护进程管理网口的状态，可以使得业务进程在重启后直接通过守护进程提供的网口连接DPDK，无需重新初始化网口，能够加快重启速度，从而能够提高数据处理效率；另外，通过守护进程管理网口的状态，保证网口状态在业务进程重启前后的一致性，可以有效避免业务进程异常退出后网口状态改变而导致多产品部署主备切换的问题；同时，守护进程还具有内存管理的功能，能够保证业务进程退出后使用的内存被回收，增加了内存的使用效率。

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

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

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

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (13)

1.一种业务进程重启方法，其特征在于，所述方法应用于安装有数据平面开发套件DPDK的***中，所述方法包括：

启动守护进程，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由低电平状态调整为高电平状态；

在业务进程重启的情况下，控制所述业务进程从所述守护进程获取高电平状态对应的网口；

基于所述高电平状态对应的网口，控制所述业务进程与DPDK连接。

2.根据权利要求1所述的业务进程重启方法，其特征在于，所述启动守护进程之后，所述方法还包括：

控制所述守护进程初始化DPDK，获取多个网口的管理权限；

控制所述守护进程导出共享数据结构；其中，所述共享数据结构用于在业务进程和守护进程之间共享所述多个网口的状态信息；

相应地，所述控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由低电平状态调整为高电平状态，包括：

基于所获取的管理权限，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由低电平状态调整为高电平状态。

3.根据权利要求2所述的业务进程重启方法，其特征在于，在业务进程重启的情况下，所述方法还包括：

控制所述业务进程连接所述守护进程，以使得所述业务进程获取所述共享数据结构；

根据所述共享数据结构，控制所述业务进程从所述共享数据结构中获取所述多个网口的原始状态；其中，所述原始状态为所述多个网口中每一网口在所述业务进程初始化之后的高电平状态；

通过所述业务进程获取所述多个网口中每一网口的当前状态，并将所述多个网口中每一网口的当前状态与对应的原始状态进行比较；

若其中一个网口的当前状态与原始状态不同，则将所述其中一个网口以及对应的当前状态通知前台程序，以使得所述其中一个网口的当前状态与原始状态相同。

4.根据权利要求2所述的业务进程重启方法，其特征在于，在所述控制所述业务进程与DPDK连接之后，所述方法还包括：

若所述守护进程监听到其中一个网口的状态变化，则控制所述守护进程向所述业务进程发送通知信息；

根据所述通知信息，控制所述业务进程获取所述状态变化的其中一个网口对应的当前状态，并将所获取的其中一个网口以及对应的当前状态记录在所述共享数据结构中。

5.根据权利要求1所述的业务进程重启方法，其特征在于，所述基于所述高电平状态对应的网口，控制所述业务进程与DPDK连接，包括：

基于所述高电平状态对应的网口，对DPDK进行初始化，以实现所述业务进程与DPDK之间的连接。

6.根据权利要求1所述的业务进程重启方法，其特征在于，在所述基于所述高电平状态对应的网口，控制所述业务进程与DPDK连接之后，所述方法还包括：

控制所述业务进程进行控制面作业和数据面作业；其中，所述控制面作业是调用DPDK的应用程序编程接口API执行第一任务，所述数据面作业是调用DPDK API执行第二任务；其中，所述第一任务至少包括为所述高电平状态对应的网口配置第二任务，所述第二任务至少包括利用其中一个所述高电平状态对应的网口执行收发数据包任务。

7.根据权利要求6所述的业务进程重启方法，其特征在于，所述基于所述高电平状态对应的网口，控制所述业务进程与DPDK连接之后，所述方法还包括：

在所述守护进程监听到所述业务进程从所述守护进程退出的情况下，通过所述守护进程判断所述业务进程调用的DPDK API是否调用完成；

若判断到所述业务进程调用的DPDK API调用完成，则控制所述守护进程回收所述业务进程使用的内存资源。

8.根据权利要求7所述的业务进程重启方法，其特征在于，在调用DPDK API的情况下，所述方法还包括：

在调用DPDK API之前，控制所述业务进程将DPDK API的序列号加1；

在调用DPDK API之后，控制所述业务进程将DPDK API的序列号加1；

相应地，所述通过所述守护进程判断所述业务进程调用的DPDK API是否调用完成，包括：

通过所述守护进程判断所述业务进程所调用的DPDK API的序列号是否为偶数；

若DPDK API的序列号是偶数，则将判断结果确认为所述业务进程所调用的DPDK API调用完成。

9.根据权利要求1-8任一项所述的业务进程重启方法，其特征在于，在业务进程重启的情况下，所述方法还包括：

控制所述业务进程向所述守护进程发送连接请求；

基于所述守护进程对所述连接请求的响应，若所述业务进程接收到所述守护进程反馈的响应消息，则确定所述业务进程与所述守护进程连接成功，执行所述控制所述业务进程从所述守护进程获取高电平状态对应的网口的步骤。

10.一种业务进程重启装置，其特征在于，所述业务进程重启装置包括初始化单元、获取单元和连接单元；其中，

所述初始化单元，配置为启动守护进程，控制所述守护进程对多个网口的状态进行初始化，将所述多个网口由低电平状态调整为高电平状态；

所述获取单元，配置为在业务进程重启的情况下，控制所述业务进程从所述守护进程获取高电平状态对应的网口；

所述连接单元，配置为基于所述高电平状态对应的网口，控制所述业务进程与DPDK连接。

11.一种业务进程重启装置，其特征在于，所述业务进程重启装置包括存储器和处理器；其中，

所述存储器，用于存储能够在所述处理器上运行的计算机程序；

所述处理器，用于在运行所述计算机程序时，执行如权利要求1至9任一项所述的业务进程重启方法。

12.一种计算机存储介质，其特征在于，所述计算机存储介质存储有业务进程重启程序，所述业务进程重启程序被至少一种处理器执行时实现如权利要求1至9任一项所述的业务进程重启方法。

13.一种业务进程重启***，其特征在于，所述***至少包括如权利要求10或11所述的业务进程重启装置。

Images