一种业务保护方法、网络设备及分布式业务处理系统与流程

本发明涉及通信领域，尤其涉及一种业务保护方法、网络设备及分布式业务处理系统。

背景技术：

l2tp(layer2tunnelingprotocol)是一种二层隧道协议隧道技术，是建立安全vpn(virtualprivatenetwork，虚拟专用网络)的基本技术之一。lac(l2tpaccessconcentrator，l2tp访问集中器)为l2tp的接入设备，它提供各种用户接入的aaa(authentication,authorization,accounting，认证授权计费)服务，发起隧道和会话连接的功能，以及对vpn用户的代理认证功能。lns(l2tpnetworkserver，l2tp网络服务器)为l2tp企业侧的vpn服务器，该服务器完成对用户的最终授权和验证，接收来自lac的隧道和连接请求，并建立连接lns和用户的ppp通道。

在实际应用中，lns设备与lac设备负载的l2tp业务均呈逐渐增加趋势，为了满足日益增加业务负荷需求，提出了基于分布式架构的l2tp多核业务处理，多核业务板极大地分散分的主控板的压力，负载能力强。不过，一旦多核业务板出现需要重启才能恢复的故障或因芯片等器件造成的不可恢复的故障时，l2tp业务就会中断，从而对电信运营上造成损失。

技术实现要素：

本发明实施例提供的业务保护方法、网络设备及分布式业务处理系统，主要解决的技术问题是：解决相关技术中基于分布式架构的l2tp多核业务容易因为多核业务板或者多核业务板上芯片的故障而中断，从而影响用户通信业务的体验。

为解决上述技术问题，本发明实施例提供一种业务保护方法，包括：

收集本cpu上的隧道信息与会话信息，所述隧道信息为本cpu所承载隧道的信息，所述会话信息为所述隧道所承载会话的信息；

将所述隧道信息与所述会话信息发送给主控板，所述隧道信息与所述会话信息用于所述主控板将本cpu上的业务发送给备用cpu，供所述备用cpu继续处理本cpu上的业务。

本发明实施例还提供一种业务保护方法，包括：

接收被保护cpu发送的隧道信息与会话信息，所述隧道信息为所述被保护cpu所承载的隧道的信息，所述会话信息为所述隧道所承载会话的信息；

确定所述被保护cpu对应的备用cpu，所述备用cpu与所述被保护cpu属于同一分布式业务处理系统；

根据所述隧道信息与所述会话信息将所述被保护cpu的业务发送给所述备用cpu。

本发明实施例还提供一种业务保护方法，包括：

向主控板上报本cpu的资源空余信息；

接收所述主控板发送的被保护cpu的业务；

对所述被保护cpu的业务进行处理。

本发明实施例还提供一种网络设备，该网络设备包括处理器、存储器及通信总线；

所述通信总线用于实现处理器和存储器之间的连接通信；

所述处理器用于执行存储器中存储的第一业务保护程序，以实现上述第一种业务保护方法的步骤；或，所述处理器用于执行存储器中存储的第二业务保护程序，以实现上述第二种业务保护方法的步骤；所述处理器用于执行存储器中存储的第三业务保护程序，以实现上述第三种业务保护方法的步骤。

本发明实施例还提供一种分布式业务处理系统，其包括主控板以及多个cpu，所述主控板为上述处理器执行第二业务保护程序的网络设备，所述多个cpu中的部分为上述处理器执行第一业务保护程序的网络设备，部分为上述处理器执行第三业务保护程序的网络设备。

本发明实施例还提供一种存储介质，该存储介质存储有第一业务保护程序、第二业务保护程序以及第三业务保护程序中的至少一个，所述第一业务保护程序可被一个或者多个处理器执行，以实现上述第一种业务保护方法的步骤；所述第二业务保护程序可被一个或者多个处理器执行，以实现上述第二种业务保护方法的步骤；所述第三业务保护程序可被一个或者多个处理器执行，以实现上述第三种业务保护方法的步骤。

本发明的有益效果是：

本发明实施例提供的业务保护方法、网络设备及分布式业务处理系统，当一个cpu不能继续进行业务处理的时候，其可以将自己的隧道信息与会话信息发送给主控板，让主控板从分布式业务处理系统中的其他cpu中为自己确定一个备用cpu，让备用cpu继续对自己的业务进行处理，避免因为自己的原因而导致自身所承载的全部业务均中断，进而影响用户体验的情况，有利于提升分布式业务处理系统的容灾性能，增强系统稳定性，提升用户的业务体验。

本发明其他特征和相应的有益效果在说明书的后面部分进行阐述说明，且应当理解，至少部分有益效果从本发明说明书中的记载变的显而易见。

附图说明

图1为本发明实施例一中提供的业务保护方法的一种交互流程图；

图2为本发明实施例一中提供的分布式业务处理系统的一种架构图；

图3为本发明实施例一中示出的lac设备与lns设备侧cpu建立会话的一种交互流程图；

图4为本发明实施例一中示出的方案一中确定备用cpu的一种流程图；

图5为本发明实施例一中示出的方案三中确定备用cpu的一种流程图；

图6为本发明实施例二中提供的业务保护方法被保护cpu侧的一种流程图；

图7为本发明实施例二中提供的业务保护方法主控板侧的一种流程图；

图8为本发明实施例三中提供的网络设备的一种硬件结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，下面通过具体实施方式结合附图对本发明实施例作进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

实施例一：

随着通信应用的扩展，lns设备和lac设备所承载的业务量越来越多，负载压力也越来越大，以lns为例来看：一台lns设备可能和多台lac设备建立vpn隧道连接，所以，lns设备承载了很多的l2tp业务，传统的集中式l2tp部署在主控板上，但因为主控板的cpu资源有限、处理效率不高，因此不能满足日益增加业务负荷需求。为了解决这个问题，可以将lns设备进行分布式部署，利用多个分布式部署的业务板来承载原本主控板需要承担的业务，进而分散主控板的压力。在一块业务板上，多个cpu负责处理lns业务，但当其中一个cpu故障的时候，该cpu所承载的业务就会因此受到影响而被迫中断，从而影响用户体验，对此，本实施例提供一种业务保护方法，请参见图1示出的业务保护方法的一种交互流程图：

s102：被保护cpu收集本cpu上的隧道信息与会话信息。

在本实施例中，cpu分为被保护cpu与备用cpu，其中被保护cpu就是指所承载业务被备用cpu继续处理，得到保护的cpu，被保护cpu通常可以是指因为各种故障而不得不中指业务处理的故障cpu。而备用cpu则是指对被保护cpu的业务进行继续处理的cpu。可以理解的是，任何一个cpu，都可能在某些情景下作为被保护cpu，在另一些情境下作为备用cpu。

隧道信息是指被保护cpu所承载隧道的信息，而会话信息则是指各隧道中所承载的会话的信息。通常，一个cpu可以承载多个隧道，而一个隧道中又可以承载多个会话。通常情况下，被保护cpu是在自己出现故障，不能继续对自身所承载的业务进行处理的情况下收集本cpu上的隧道信息与会话信息的。例如，在本实施例的一些示例当中，一个cpu确定自己需要进行复位以应对当前的故障，则该cpu可以确定自己是被保护cpu，因此收集自身的隧道信息与会话信息。

s104：被保护cpu将隧道信息与会话信息发送给主控板。

被保护cpu收集到自己的隧道信息和会话信息之后，可以将这些信息发送给主控板。图2示出了一种分布式业务处理系统，请参见图2：

分布式业务处理系统2当中包括主控板21、第一业务板22以及第二业务板23、报文收发处理板24。其中，主控板21负责管理整个分布式业务处理系统2的系统管理、协议报文处理及路由管理，报文收发处理板24负责接口流量管理、报文转发、交换流量管理，能够将l2tp报文根据主控板21设定的处理规则分发到各个业务板上。在本实施例中，各个业务板相互独立，并行地进行分布式处理，从而提高系统的吞吐量。第一业务板22上包括多个cpu，第二业务板23上也包括多个cpu。这里假定分布式业务处理系统2是分布式的lns设备，请参见图3示出的l2tp的建立流程示意图：

s302：lac发起隧道建立的请求sccrq报文；

s304：cpu应答sccrp报文；

s306：lac在收到应答后向lns返回确认scccn报文；

至此，lac与cpu之间的隧道建立。

s308：lac发起会话建立请求icrq报文；

s310：cpu收到请求后返回应答icrp报文；

s312：lac收到应答后返回确认iccn报文；

至此，会话建立。会话建立后，lns可与用户进行ppp(pointtopointprotocol，点对点协议)交互过程，并为用户分配ip地址，随后，用户即可访问网络。

s106：主控板确定被保护cpu对应的备用cpu。

在本实施例中，主控板接收到被保护cpu发送的隧道信息与会话信息之后，可以确定被保护cpu暂时不能继续处理其业务，因此主控板需要为被保护cpu确定备用cpu，以便备用cpu能够对被保护cpu上不能进行的业务进行处理，从而实现对这些业务的保护，避免这些业务被中断。

在本实施例中，主控板为被保护cpu所选择确定的备用cpu也是分布式业务处理系统中的cpu，而分布式业务处理系统中的cpu原本也承载一些业务，因此，备用cpu是利用自己在处理自身业务同时剩余的资源来保护被保护cpu上的业务。所以，主控板在确定被保护cpu对应的备用cpu时，会参考各cpu的资源空余信息，也即一个cpu在处理自身业务的同时还能额外承载的业务的能力。

在本实施例的一些示例当中，对以一个cpu，主控板可以根据该cpu的cpu利用率、内存使用率、可用隧道数以及可用会话数中的至少一个来确定其资源空余信息。

pri＝w1*(1-cpurate)+w2*(1-memrate)+w3*t+w4*s；

其中，pri能够表征cpu的资源空余情况，pri值越高，则cpu的资源空余越多，反之，则cpu的资源空余越少。因此，一个cpu的pri值越高，则该cpu被选择作为备用cpu的概率也越高。cpurate就是指cpu利用率，w1即为cpu空余率的权重；memrate为内存使用率，w2则为内存剩余率的权重；t可以表征可用隧道数的多少，w3则为可用隧道数的权重；s可以表征可用会话数的多少，w4为可用会话数的权重。

应当理解的是，可用会话数、可用隧道数与cpu空余率和内存剩余率的度量不一致，因此，在本实施例中，需要将可用会话数、可用隧道数进行归一化处理，从而使得四者的度量一致。例如，t的取值可以是可用隧道数与分布式业务处理系统中额定总隧道数的比值，取值区间为(0,1)；s的取值是可用会话数与分布式业务处理系统中额定总会话数的比值，取值区间为(0,1)。

可以理解的是，一个cpu能够作为备用cpu，除了其当前的资源空余以外，该cpu本身的状态也是非常重要的，例如，在一些情况下，虽然一个cpu还剩余很多处理资源，这些处理资源足以处理很多额外的业务，但如果该cpu自身不正常，则其也不能作为备用cpu。所以，在本实施例的一些示例当中，

pri＝stat*[w1*(1-cpurate)+w2*(1-memrate)+w3*t+w4*s]；

其他字符的含义不变，stat表示cpu的运行状态，如果stat的值为1，则表征cpu的运行状态正常，而当cpu的运行状态异常时，stat的值就为0。所以，无论一个cpu的cpu空余率、内存剩余率以及可用隧道数。可用会话数如何，只要cpu的运行状态不正常，则该cpu的pri值就为0。

在本实施例的另一些示例当中，主控板可以仅根据cpu的cpu空余率或者内存剩余率来确定该cpu的资源空余信息。除此以外，主控板也可以仅根据一个cpu的可用隧道数或者可用会话数来确定该cpu的资源空余信息。

毫无疑义的是，在主控板确定被保护cpu对应的备用cpu之前，主控板应当先获取到分布式业务处理系统中各cpu的资源空余信息，下面介绍几种可供参考的主控板获取各cpu资源空余信息以及确定备用cpu的方案：

方案一：

主控板周期性获取分布式业务处理系统中各cpu的资源空余信息，并周期性地为各cpu确定备用cpu，请结合图4：

s402：主控板周期性确定分布式业务处理系统中各cpu的资源空余信息。

在这种方案当中，分布式业务处理系统中的各个cpu会定时地向主控板上报自己的资源空余信息，在本实施例的一些示例当中，cpu向主控板上报的能够表征自己资源空余的信息包括自己的cpu利用率、内存利用率以及可用隧道数、可用会话数等。

在本实施例中，因为分布式业务处理系统中存在很多cpu，而这些cpu基本都会向主控板上报自己的资源空余信息，因为，为了保证主控板在收到一个上报信息之后，能够确定该上报信息对应的资源空余信息属于哪一个cpu，因此，在cpu向主控板上报自己的资源空余信息的时候，会在上报信息中携带能够在分布式业务处理系统中唯一标识自己的信息，例如在本实施例的一种示例当中，cpu可以通过l(a)n(b)标识来唯一表征自己的身份，其中l代表“location”，能够表征该cpu所处的业务板，其中a就是该cpu所处业务板的编号，而n则表示该cpu在其所处的业务板上的序号，b就是该cpu在业务板上的唯一标识。通过l(a)n(b)标识，主控板可以确定自己受到的上报信息中所携带的资源空余信息属于哪一个业务板上的哪一个cpu。

s404：主控板根据最近一次获取的各cpu的资源空余信息为各cpu确定出对应的备用cpu，并存储各cpu与对应备用cpu间的映射关系。

在该示例当中，每当主控板重新获取一次各cpu的资源空余信息，其就会重新为各cpu配置一次备用cpu。对于一个cpu，主控板就是从该cpu所属的分布式业务处理系统中的其他cpu中为其选择备用cpu，因此，一个cpu与其备用cpu都是同属一个分布式业务处理系统的cpu。例如，在本实施例的一种示例当中，主控板按照如下方式为分布式业务处理系统中的各cpu确定备用cpu：

主控板根据各cpu的资源空余信息计算各cpu的pri值，计算方式请参见前面的介绍，这里不再赘述。计算出各cpu的pri值之后，主控板确定出其中pri值最高的一个cpu，将该cpu作为分布式业务处理系统当中除了该cpu自身以外其他所有cpu的被用cpu。另外，主控板还需要为pri值最高的cpu选择出一个备用cpu，在一个示例当中，主控板可以将pri值次高的cpu作为pri值最高的cpu的备用cpu。

假定在一个分布式业务处理系统当中，包括cpu1、cpu2、cpu3以及cpu4和cpu5五个cpu，经过计算，cpu3的pri值最高，其次是cpu4，因此，主控板可以确定各cpu及其对应的备用cpu之间的映射关系如表1所示：

表1

主控板确定出各cpu与其备用cpu之间的映射关系之后，可以将该映射关系进行存储，以便在下次更新该映射关系之前有cpu需要被保护时使用。

s406：主控板根据映射关系查询被保护cpu对应的备用cpu。

当有一个cpu向主控板上报自身的隧道信息和会话信息之后，主控板可以根据预先存储的映射关系查询出该cpu对应的备用cpu。在这种方案当中，当一个cpu故障之后，主控板无须临时获取分布式业务处理系统中各cpu的资源空余信息，也无须进行临时的计算，因此能够提升确定备用cpu的速度，以便更加快速地将被保护cpu的业务切换到备用cpu上，避免业务因选择备用cpu的时间过程而被影响，有利于降低用户侧对被保护cpu故障的感知度。

可以理解的是，因为主控板是周期性为分布式业务处理系统中的各cpu确定备用cpu，因此，有时候，主控板为各cpu确定备用cpu之后，备用cpu可能并不会发生作用，因为可能在某一个周期当中，分布式业务处理系统中的各cpu均是正常的，没有出现过被保护cpu。

方案二：

主控板周期性地获取分布式业务处理系统中各cpu的资源空余信息，但临时确定被保护cpu对应的备用cpu。在这些方案当中，主控板可以和方案一中一样，周期性地获取分布式业务处理系统中各cpu的资源空余信息，例如，主控板周期性地向分布式业务处理系统中各cpu发送空余信息请求，让各cpu根据空余信息请求上报自身的资源空余信息。当然，无论是方案一中还是本方案中，主控板可以不必周期性地发送空余信息请求，而是由各cpu自己进行周期监测，当上报周期到达时，各cpu自动向主控板上报自己的资源空余信息，这样可以降低主控板的负担。

不过，在方案二中，和方案一中不同的是，主控板并不会在每一次获取到各cpu的资源空余信息之后都为每一个cpu确定备用cpu，而是将新获取到的各cpu的资源空余信息进行存储，当出现某一个cpu故障时，可以临时为该故障cpu，也即被保护cpu确定出对应的被用cpu。由于主控板不用频繁地为分布式业务处理系统中的各个cpu确定备用cpu，而且，在为被保护cpu确定备用cpu的时候，也不需要为分布式业务处理系统中的其他cpu确定备用cpu，因此可以降低对自身处理资源的占用。

可以理解的是，在本方案和方案一当中，由于主控板会周期性地获取到分布式业务处理系统中各个cpu的资源空余信息，但主控板在确定备用cpu的时候却总是依据最新获取到的资源空余信息，因此，处于降低存储资源耗费的目的，主控板可以采用各cpu最新一次的资源空余信息覆盖之前的资源空余信息。

方案三：

在前两个方案当中，主控板都是周期性地获取分布式业务处理系统中各cpu的资源空余信息，但在本方案当中，主控板只会在需要为某一个被保护cpu确定备用cpu的时候才会临时获取分布式业务处理系统中各cpu的资源空余信息。下面请结合图5示出的主控板为被保护cpu确定备用cpu的一种流程图：

s502：向分布式业务处理系统中除被保护cpu以外的其他cpu发送空余信息请求。

在本方案当中，由于分布式业务处理系统中的某一个cpu何时故障，分布式业务处理系统中的其他cpu是不确定的，因此，分布式业务处理系统中的其他cpu没有办法在一个被保护cpu出现后主动向主控板上报自己的空余信息请求，所以，在本实施例中，当主控板接收到一个被保护cpu发送的隧道信息与会话信息，确定需要确定备用cpu的时候，主控板可以向分布式业务处理系统中除被保护cpu以外的其他cpu发送空余信息请求，该空余信息请求能够通知其他cpu上报自己的资源空余信息。

s504：接收各cpu根据空余信息请求上报的自身的资源空余信息。

在分布式业务处理系统中的其他cpu接收到空余信息请求之后，会根据空余信息请求向主控板上报自身的资源空余信息，因此，主控板会接收这些cpu发送的资源空余信息。

s506：根据各cpu的资源空余信息为被保护cpu确定出对应的备用cpu。

在获取到除被保护cpu以外其他cpu的资源空余信息之后，主控板可以根据这些资源空余信息确定出被保护cpu的备用cpu。可以理解的是，由于此时主控板仅需要为被保护cpu选择备用cpu，因此，主控板可以直接选择资源空余信息所表征的资源空余情况最优的一个作为备用cpu。当然，在本实施例的其他一些示例当中，主控板也可以仅选择资源空余情况较优的cpu作为备用cpu，不用选择最优的一个。例如，如果主控板通过计算确定有3个cpu的资源空余情况都比较好，均足以承载被保护cpu的全部业务，那在这种情况下，主控板可以从这3个cpu中任意选择一个作为被保护cpu的备用cpu，甚至，主控板还可以选择这3个cpu中资源空余最少的一个作为备用cpu，因为这样就可以将资源空余情况较优的另外两个cpu留着，以防后续有承载业务量更大的cpu故障之后，需要选择备用cpu的情况出现。

s108：主控板根据隧道信息与会话信息将被保护cpu的业务发送给备用cpu。

主控板确定出被保护cpu的备用cpu之后，可以根据被保护cpu上报的隧道信息与会话信息将被保护cpu的业务发送给备用cpu，以便备用cpu可以对被保护cpu的业务进行处理。可以理解的是，在一些情况下，主控板为被保护cpu所选择的备用cpu的资源空余较大，备用cpu的资源空余足以承载被保护cpu的全部业务，在这种情况下，主控板可以直接将被保护cpu的全部业务均下发给备用cpu。但在另外一些情况下，主控板所选择出来的备用cpu的资源空余不多，可能只能在处理其自身业务的同时承担被保护cpu上部分业务的处理，此时，主控板就需要从被保护cpu的业务中进行挑选，仅筛选出部分业务下发给备用cpu。

在本实施例的一些示例当中，主控板可以根据备用cpu的资源空余从被保护cpu的业务中随机选择一部分业务下发到备用cpu上。不过，毫无疑义的是，对于被保护cpu上的某一个业务，如果其没能通过选择被下发到备用cpu上，则该业务就会被中断，这自然会影响对应用户的体验。因此，在本实施例中，主控板在筛选被保护cpu的业务时，可以按照业务的重要程度等因此来选择。在本实施例的一些示例当中，主控板以隧道为单位选择被保护cpu的业务，也即，如果一个隧道被主控板选中，则该隧道上所承载的所有业务均会被下发到备用cpu上，如果一个隧道被筛除，则该隧道上所承载的所有业务都只能中断。

下面介绍一种以隧道为单位选择业务的方案：

主控板可以根据隧道的隧道状态ts、隧道保活时间tk、隧道内的会话量tn确定各隧道的保护敏感度。例如，

sent(tid)＝ts*tk*tn；

其中tid是指隧道编号，而sent则是指一个隧道对应的保护敏感度，从上述公式中可以看出，一个隧道的保护敏感度等于该隧道对应的隧道状态、隧道保活时间以及隧道内会话量三者的乘积。毫无疑义的是，在本实施例的其他一些示例当中，主控板也可以采用其他方式来计算各隧道对应的保护敏感度，或者是采用其他方式筛选被保护cpu的业务。

s110：备用cpu对被保护cpu的业务进行处理。

备用cpu接收到主控板下发的被保护cpu的业务之后，可以对这些业务进行处理。可以理解的是，由于备用cpu本身也有自己的业务需要处理，因此，本实施例提供的备用cpu实际上是在利用自己的多余资源对被保护业务进行保护，所以，本实施例提供的业务保护方案实际上是一种冗余保护方案。

可以理解的是，当被保护cpu的故障恢复以后，主控板有可以将下发到备用cpu上的业务重新切回已经恢复的被保护cpu上，让被保护cpu继续对其原本的业务进行处理。自此，被保护cpu与备用cpu之间的保护与被保护的关系就可以解除了。

本发明实施例提供的业务保护方法，在cpu无法继续处理自身所承载业务时，由主控板为该cpu选择一个备用cpu，以便继续处理故障cpu的全部或部分业务，从而减少故障cpu的故障给用户业务带来的影响，增强用户体验。

更进一步地，由于选择备用cpu的时候是并基于各cpu的资源空余情况进行的，因此，可以选择资源空余较多的cpu作为备用cpu，进而让备用cpu尽可能多地承担故障cpu上的业务。

另外，当备用cpu无法承载故障cpu上全部的业务时，主控板可以对备用cpu需要承载的故障cpu的业务进行筛选，避免备用cpu的负载过大，影响备用cpu自身业务的问题。

实施例二：

本实施例将结合一些示例继续对前述业务保护方法进行介绍，请参见图6示出的业务保护方法一种流程图：

s602：cpu确定自身不能继续处理业务。

在本实施例中，cpu如果发生了需要复位的故障，或者发生了暂时无法金恢复的故障，则cpu可以确定自己当前无法继续进行业务处理。

s604：cpu收集自身的隧道信息与会话信息。

在本实施例中，cpu收集的隧道信息是指该cpu所承载隧道的信息，而会话信息则是指各隧道中所承载的会话的信息。一个cpu可以承载多个隧道，而一个隧道中又可以承载多个会话。

s606：cpu将自身的隧道信息与会话信息发送给主控板。

cpu收集到自己的隧道信息和会话信息之后，可以将这些信息发送给主控板。

在本实施例的一些示例当中，在cpu未发生故障的时候，cpu还会定时向主控板上报自身的资源空余信息，或者是在主控板的请求下向主控板上报自身的资源空余信息。cpu上报的资源空余信息包括但不限于该cpu自身的l(a)n(b)标识、运行状态标记、cpu利用率、内存利用率、可用隧道资源数据、可用会话资源数据等几种。cpu上报的这些资源空余信息可以供主控板在其他cpu故障之后确定本cpu是否适合做故障cpu的备用cpu。

请接续结合图7示出的业务处理方法中主控板侧的流程：

s702：主控板接收分布式业务处理系统中各cpu定时上报的资源空余信息。

在本实施例中，主控板采用实施例一中方案一对应的方式确定分布式业务处理系统中各cpu对应的被用cpu，因此，主控板可以定时获取各cpu上报的资源空余信息。

s704：主控板根据最新上报的资源空余信息为分布式业务处理系统中各个cpu确定出备用cpu。

主控板在获取到分布式业务处理系统中各cpu上报的资源空余信息之后，可以根据cpu的cpu利用率、内存使用率、可用隧道数以及可用会话数中的一个或多个确定出该cpu的pri值，然后基于各cpu的pri值确定出各个cpu对应的备用cpu。

s706：主控板存储各cpu与对应备用cpu之间最新的映射关系。

确定出各cpu与对应备用cpu之间的映射关系之后，主控板可以对该映射关系进行存储。可以理解的是，每当各cpu上报一次资源空余信息，主控板就会确定出一种映射关系，但因为主控板在为一个被保护cpu确定备用cpu的时候，总是依据当前最新的映射关系，因此主控板在存储映射关系的时候，可以进行覆盖式的存储，即总是以最新的映射关系覆盖前一次获取到的映射关系，这样可以减少映射关系存储对主控板侧的存储资源的占用。

s708：主控板接收被保护cpu发送的隧道信息与会话信息。

当主控板接收到一个cpu发送的隧道信息与会话信息后，可以确定该cpu应该是故障了，无法继续处理其自身业务，因此，主控板确定该cpu是当前的被保护cpu。

s710：主控板根据存储的映射关系查询该被保护cpu对应的备用cpu。

由于在此之前主控板已经确定除了分布式业务处理系统中各cpu对应的被用cpu，因此，主控板确定被保护cpu之后，可以通过查询存储的映射关系确定出该被保护cpu对应的备用cpu是哪一个。

s712：主控板判断备用cpu的资源空余是否足以承载被保护cpu的全部业务。

查询到被保护cpu对应的备用cpu之后，主控板可以确定备用cpu的资源空余是否足以承载被保护cpu的全部业务，若判断结果为是，则进入s714，否则，进入s716。

s714：主控板根据被保护cpu的隧道信息与会话信息将被保护cpu的全部业务均下发给备用cpu。

如果主控板为被保护cpu所选择的备用cpu的资源空余较大，备用cpu的资源空余足以承载被保护cpu的全部业务，那么主控板可以直接将被保护cpu的全部业务均下发给备用cpu。

s716：主控板确定被保护cpu上各隧道对应的保护敏感度。

如果主控板所选择出来的备用cpu的资源空余不多，只能在处理其自身业务的同时承担被保护cpu上部分业务的处理，那么主控板就需要从被保护cpu的业务中进行挑选，仅筛选出部分业务下发给备用cpu。

在本实施例中，主控板基于被保护cpu上各隧道对应的保护敏感度来选择下发给备用cpu的业务。所以，当主控板确定备用cpu的资源空余不足以承载被保护cpu的全部业务后，主控板会计算被保护cpu上各隧道对应的保护敏感度。例如，主控板根据sent(tid)＝ts*tk*tn公式计算各隧道对应的保护敏感度。

s718：主控板根据备用cpu的资源空余按照隧道保护敏感度从高到低的顺序从被保护cpu的业务中选择出备用cpu可以承载的部分。

确定出各隧道对应的保护敏感度之后，主控板可以根据备用cpu的资源空余按照隧道保护敏感度从高到低的顺序从被保护cpu的业务中选择出备用cpu可以承载的部分。由于被保护cpu上各隧道中所承载的会话量并不是固定的，因此，主控板无法直接根据各隧道所承载的业务量决定选择多少个隧道中的业务。在本实施例的一种示例当中，主控板可以首先选择被保护cpu上保护敏感度值最高的一个隧道，判断备用cpu承载了该隧道中的全部业务之后，是否还有资源空余，若是，则主控板进一步选择保护敏感度值次高的隧道，确定备用cpu进一步承载该隧道中的业务之后，是否还有资源空余承载其他隧道的业务……如此循环，直到备用cpu没有资源空余或者资源空余不足以承载某一隧道中的业务为止。

s720：主控板将选择出的业务下发给备用cpu。

主控板选择出业务之后，将选择出的业务下发给备用cpu，让备用cpu对下发的业务进行处理。

s722：主控板监测被保护cpu是否恢复。

在主控板将被保护cpu的业务全部或部分下发到备用cpu上之后，主控板可以对被保护cpu的状态进行监测，确定被保护cpu的状态是否已经恢复，若判断结果为是，则进入s724，否则继续执行s722。

在本实施例的一些示例当中，主控板可以定时向被保护cpu发送转状态询问信息，根据被保护cpu的反馈确定被保护cpu的状态。在本实施例的另外一些示例当中，被保护cpu可以在自己状态恢复之后主动向主控板上报自己状态恢复的信息。

s724：主控板将被保护cpu的业务切回被保护cpu上。

当主控板确定被保护cpu的状态恢复之后，可以将原本属于被保护cpu的业务切回到被保护cpu上处理，这些业务包括备用cpu额外承载的业务，也包括因为备用cpu资源空余优先而没有被主控板下发给备用因为的业务。

本实施例提供的业务保护方法，主控板通过预先为分布式业务处理系统中各cpu确定备用cpu，因此，当一个cpu出现故障的时候，主控板能够快速地查询出该cpu的备用cpu，从而在cpu故障后，尽快实现该故障cpu上业务的迁移，避免了业务长时间中断，影响用户体验的问题。

实施例三：

本实施例提供一种存储介质，该存储介质中可以存储有一个或多个可供一个或多个处理器读取、编译并执行的计算机程序，在本实施例中，该存储介质可以存储有第一业务保护程序、第二业务保护程序和第三业务保护程序中的至少一个，其中，第一业务保护程序可供一个或多个处理器执行实现前述实施例介绍的任意一种业务保护方法被保护cpu侧的流程，第二业务保护程序可供一个或多个处理器执行实现前述实施例介绍的任意一种业务保护方法主控板侧的流程，第三业务保护程序可供一个或多个处理器执行实现前述实施例介绍的任意一种业务保护方法备用cpu侧的流程。

另外，本实施例提供一种网络设备，如图8所示：网络设备80包括处理器81、存储器82以及用于连接处理器81与存储器82的通信总线83，其中存储器82可以为前述存储有第一业务保护程序的存储介质。处理器81可以读取第一业务保护程序，进行编译并执行实现前述实施例中介绍的业务保护方法中被保护cpu侧的流程：

处理器81收集本cpu上的隧道信息与会话信息，其中，隧道信息为本cpu所承载隧道的信息，会话信息为隧道所承载会话的信息；

处理器81将隧道信息与会话信息发送给主控板，这些隧道信息与会话信息用于主控板将本cpu上的业务发送给备用cpu，供备用cpu继续处理本cpu上的业务。

在本实施例的一些示例当中，处理器81可以本端cpu需要进行复位时，收集本cpu上的隧道信息与会话信息。

处理器81还可以读取第二业务保护程序，进行编译并执行实现前述实施例中介绍的业务保护方法中主控板侧的流程：

处理器81接收被保护cpu发送的隧道信息与会话信息，然后确定被保护cpu对应的备用cpu，并根据隧道信息与会话信息将被保护cpu的业务发送给备用cpu。

在本实施例的一些示例当中，备用cpu是根据分布式业务处理系统中各cpu的资源空余信息确定的，资源空余信息能够表征cpu的资源空余。

一个cpu的资源空余信息根据cpu的cpu利用率、内存使用率、可用隧道数以及可用会话数中的一个或多个确定。

在本实施例的一种示例当中，处理器81接收被保护cpu发送的隧道信息与会话信息之前，还会周期性确定分布式业务处理系统中各cpu的资源空余信息，然后根据最近一次获取的各cpu的资源空余信息为各cpu确定出对应的备用cpu，并存储各cpu与对应备用cpu间的映射关系。在需要确定被保护cpu对应的备用cpu时，根据映射关系查询被保护cpu对应的备用cpu。

在本实施例的一种示例当中，处理器81接收被保护cpu发送的隧道信息与会话信息之前，还会先周期性确定分布式业务处理系统中各cpu的资源空余信息。在需要确定被保护cpu对应的备用cpu时，根据最近一次获取的各cpu的资源空余信息为被保护cpu确定出对应的备用cpu。

在本实施例的另一种示例当中，处理器81在确定被保护cpu对应的备用cpu时，会向分布式业务处理系统中除被保护cpu以外的其他cpu发送空余信息请求，然后接收各cpu根据空余信息请求上报的自身的资源空余信息并根据各cpu的资源空余信息为被保护cpu确定出对应的备用cpu。

另外，处理器81根据隧道信息与会话信息将被保护cpu的业务发送给备用cpu之后，还会在被保护cpu恢复正常运行状态之后，将属于被保护cpu的业务切回被保护cpu。

在本实施例中，处理器81会根据备用cpu的资源空余信息确定备用cpu的资源空余是否足以承载被保护cpu上的全部业务；若否，则对被保护cpu的业务进行筛选，并将筛选保留的业务下发给备用cpu。若确定备用cpu的资源空余足以承载被保护cpu上的全部业务，则处理器81直接将被保护cpu的全部业务下发给备用cpu。

可选地，处理器81以隧道为单位确定各隧道对应的保护敏感度，保护敏感度表征隧道中业务被保护的需求度，保护敏感度越高，则隧道中业务被保护的需求度越高；确定出保护敏感度后，处理器81根据备用cpu的资源空余按照保护敏感度从高到低的顺序选择保留的业务。

例如，处理器81可以根据隧道的隧道状态ts、隧道保活时间tk、隧道内的会话量tn确定各隧道的保护敏感度。

处理器81还可以读取第三业务保护程序，进行编译并执行实现前述实施例中介绍的业务保护方法中备用cpu侧的流程：

处理器81向主控板上报本cpu的资源空余信息，然后接收主控板发送的被保护cpu的业务，并对被保护cpu的业务进行处理。

本实施例还提供一种分布式业务处理系统，其中包括主控板以及多个cpu，主控板为上述处理器81执行第二业务保护程序的网络设备，多个cpu中的部分为上述处理器81执行第一业务保护程序的网络设备，部分为处理器81执行第三业务保护程序的网络设备。

本实施例提供的网络设备及分布式业务处理系统，当一个cpu不能继续进行业务处理的时候，其可以将自己的隧道信息与会话信息发送给主控板，让主控板从分布式业务处理系统中的其他cpu中为自己确定一个备用cpu，让备用cpu继续对自己的业务进行处理，避免因为自己的原因而导致自身所承载的全部业务均中断，进而影响用户体验的情况，有利于提升分布式业务处理系统的容灾性能，增强系统稳定性，提升用户的业务体验。

显然，本领域的技术人员应该明白，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件(可以用计算装置可执行的程序代码来实现)、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于ram,rom,eeprom、闪存或其他存储器技术、cd-rom，数字多功能盘(dvd)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。所以，本发明不限制于任何特定的硬件和软件结合。

以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。