本申请涉及通信领域，尤其涉及一种网络业务处理方法和负荷分担装置。
背景技术：
负荷分担是指在通信网络中，网络设备及业务处理实体之间工作负荷的彼此分担和分享功能。负荷分担的目的在于保证整个通信网络系统的稳定、有序运行，减少系统崩溃的概率。传统的，如果网络组网基于多个负荷分担节点，那么多个负荷分担节点按统一的、预定义好的分发规则发送业务请求。
如图1所示的网络组网图中，系统业务服务器1-10组成一个服务器整体，对外可以提供每台服务器最大300每秒试呼次数(callattemptpersecond，caps)的服务。负荷分担节点1的分发逻辑是：将30％的业务请求发送到服务器1，30％的业务请求发送到服务器2，30％的业务请求发送到服务器3，且最多不将100caps发送给每个服务器。负荷分担节点2的分发逻辑是：将30％的业务请求发送到服务器1，30％的业务请求发送到服务器2，30％的业务请求发送到服务器3，且最多不将100caps发送给每个服务器。负荷分担节点3的分发逻辑是：将30％的业务请求发送到服务器1，30％的业务请求发送到服务器2，30％的业务请求发送到服务器3，且最多不将100caps发送给每个服务器。
然而，上述预定义好的分发规则，无法预见在节点失效、新加入的负荷分担节点的场景，或者无法预见某个负荷分担节点失效的场景下，如何针对超负荷的场景进行对应的、合理的丢弃动作。
技术实现要素：
本申请提供了一种网络业务处理方法和负荷分担装置，该方法可以根据负荷分担节点后端的每台服务器的业务潜力，调节负荷信息的分发策略和分发阈值策略，以充分利用每台服务器，从而提升整个网络系统处理业务请求的能力和效率。
第一方面，提供了一种网络业务处理方法。该方法可以包括：第一负荷分担节点接收第二负荷分担节点广播发送的当前时刻的负荷信息，第二负荷分担节点为除第一负荷分担节点之外的负荷分担节点。第一负荷分担节点根据接收到的负荷信息以及自身的负荷信息，确定与第一负荷分担节点关联的服务器待接收的负荷量，接收到负荷信息包括第二负荷分担节点向关联的服务器发送的业务请求的负荷量。其中，业务请求可以是超文本传输协议(hypertexttransferprotocol，http)请求，或者网络服务(webservice)请求。第一负荷分担节点根据服务器待接收的负荷量，调整第一负荷分担节点自身分发的负荷信息。通过该方法向后端的服务器实时发送业务请求,对业务请求进行处理，从而充分利用每台服务器的业务潜能，提升了整个网络系统处理业务请求的能力，同时也避免了服务器接收超负荷的业务请求的问题。
在一个可选的实现中，第一负荷分担节点向至少一个第二负荷分担节点广播发送当前时刻的负荷信息。
在一个可选的实现中，该接收到负荷信息包括负荷分发阈值。第一负荷分担节点根据接收到的负荷信息以及自身的负荷信息，确定与第一负荷分担节点关联的服务器接收的负荷量，包括：第一负荷分担节点根据负荷分发阈值、第二负荷分担节点向关联的服务器发送的业务请求的负荷量以及自身的负荷信息，确定与第一负荷分担节点关联的服务器待接收的负荷量，从而在满足第一负荷分担节点的负荷分发阈值的基础上，进一步充分利用每台服务器的业务潜能。其中，自身的负荷信息可以包括当前时刻第一负荷分担节点接收的业务请求负荷量。接收到的负荷信息可以包括第二负荷分担节点向关联的服务器发送的业务请求的负荷量。
在一个可选的实现中，在第一负荷分担节点根据服务器待接收的负荷量，调整第一负荷分担节点自身分发的负荷信息之前，该方法还包括：第一负荷分担节点获取服务器承载的最大负荷量。第一负荷分担节点根据服务器待接收的负荷量，调整第一负荷分担节点自身分发的负荷信息，具体包括：第一负荷分担节点根据服务器待接收的负荷量和服务器承载的最大负荷量，调整第一负荷分担节点分发的负荷量。当服务器待接收的负荷量和服务器承载的最大负荷量的比值不小于预设平衡阈值时，第一负荷分担节点根据服务器承载的最大负荷量，增大第一负荷分担节点分发的负荷量。当服务器待接收的负荷量和服务器承载的最大负荷量的比值小于预设平衡阈值时，第一负荷分担节点不再调整第一负荷分担节点分发的述负荷量。
第二方面，提供了一种负荷分担装置。该负荷分担装置具有实现上述方法实际中负荷分担装置行为的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。
第三方面，提供了另一种负荷分担装置。该装置可以包括接收器、处理器和发送器。接收器用于接收第二负荷分担装置广播发送的当前时刻的负荷信息，第二负荷分担装置为除负荷分担装置之外的负荷分担装置。处理器用于根据接收到的负荷信息以及自身的负荷信息，确定与装置关联的服务器待接收的负荷量，接收到负荷信息可以包括第二负荷分担节点向关联的服务器发送的业务请求的负荷量。处理器还用于根据服务器待接收的负荷量，调整发送器分发的负荷量。
在一个可选的实现中，该装置还包括发送器，发送器用于向至少一个第二负荷分担装置广播发送当前时刻的负荷信息。
在一个可选的实现中，接收到负荷信息还包括负荷分发阈值。处理器还具体用于根据负荷分发阈值、第二负荷分担节点向关联的服务器发送的业务请求的负荷量以及自身的负荷信息，确定与装置关联的服务器待接收的负荷量。
在一个可选的实现中，处理器还用于获取服务器承载的最大负荷量。当服务器待接收的负荷量和服务器承载的最大负荷量的比值不小于预设平衡阈值时，处理器根据服务器承载的最大负荷量，增大发送器分发的负荷量。当服务器待接收的负荷量和服务器承载的最大负荷量的比值小于预设平衡阈值时，处理器不再调整发送器分发的负荷量。
该负荷分担装置还可以包括储存器，该存储器用于与处理器耦合连接，保存该负荷分担装置必要的程序指令和数据。
再一方面，提供了一种计算机存储介质，用于储存为上述负荷分担装置所用的计算机软件指令，其包含用于执行上述方面所设计的程序。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍。
图1为一种网络组网的结构示意图；
图2为本发明实施例提供的一种网络业务处理方法的流程示意图；
图3为本发明实施例提供的一种网络组网的结构示意图；
图4为本发明实施例提供的另一种网络组网的结构示意图；
图5为本发明实施例提供的一种负荷分担装置可能的结构示意图；
图6为本发明实施例提供的另一种负荷分担装置可能的结构示意图。
具体实施方式
下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。
本申请涉及的网络业务处理方法可以应用在图1所示的网络组网的业务场景中。该网络组网可以包括至少两个客户端(client)，如网关gprs支撑节点(gatewaygprssupportnode，ggsn)、至少两个负荷分担节点，如软件负载均衡器(softwareloaderbalance，slb)、信用控制协议适配器(creditcontroladapter，dccadapter)，和至少两个服务器，如业务管理点(businessmanagementpoint，bmp)，融合计费点(convergentbillingpoint，cbp)。
其中，客户端与负荷分担节点可以为非全网连接(即每个客户端分别与部分负荷分担节点连接)；负荷分担节点与服务器可以为全网连接，如图1所示。客户端与负荷分担节点也可以为全网连接(即每个客户端分别与每个负荷分担节点连接)；负荷分担节点与服务器也可以为非全网连接。
负荷分担节点接收前端客户端实时发送的业务请求，并动态决定相应负荷分担节点下一时刻负荷分发规则和分发阈值规则，以用于向后端的服务器实时发送业务请求,对业务请求进行处理，从而充分利用每台服务器的业务潜能，提升了整个网络系统处理业务请求的能力，同时也避免了服务器接收超负荷的业务请求的问题。
图2为本发明实施例提供的一种网络业务处理方法的流程示意图。如图3所示，该方法可以包括：
步骤210、第一负荷分担节点接收第二负荷分担节点广播发送的当前时刻的负荷信息。
第二负荷分担节点为网络组网中除第一负荷分担节点之外的其他负荷分担节点。
在执行步骤210之前，第一负荷分担节点和第二负荷分担节点接收客户端发送的业务请求，如超文本传输协议(hypertexttransferprotocol，http)请求，或者网络服务(webservice)请求，并对业务请求的负荷信息进行统计。
网络组网中的所有负荷分担节点都将自己的负荷信息广播给网络组网中的其他所有负荷分担节点，通过广播的方式可以确保除自己以外的其他负荷分担节点可以接收到自己的负荷信息。也就是说，第一负荷分担节点接收第二负荷分担节点广播发送当前时刻的负荷信息。可以理解的是，第一负荷分担节点也向第二负荷分担节点广播发送当前时刻的负荷信息。
步骤220、第一负荷分担节点根据接收到的负荷信息以及自身的负荷信息，确定与第一负荷分担节点关联的服务器接收的负荷量。
第一负荷分担节点根据接收的第二负荷分担节点广播发送的负荷信息，计算与第一负荷分担节点关联的服务器(如服务器1或服务器2)接收的负荷量，以使第一负荷分担节点获取关联的每个服务器在当前时刻接收业务请求的负荷量。
可选地，负荷信息可以包括第一负荷分担节点的自身的负荷信息和接收到的负荷信息。其中，自身的负荷信息可以包括当前时刻第一负荷分担节点接收的业务请求负荷量。
接收到的负荷信息可以包括相应负荷分担节点向关联的服务器发送的业务请求的负荷量。第一负荷分担节点对当前时刻接收的业务请求负荷量进行分发，如当前时刻第一负荷分担节点接收的业务请求负荷量为80caps，其向第一服务器发送40caps业务请求的负荷量，向第二服务器发送40caps业务请求的负荷量。
可选地，负荷信息还可以包括负荷分发阈值，负荷分发阈值为负荷分担节点支持的向关联的服务器发送的业务请求的最大负荷量，以避免超出该服务器接收的最大负荷量，起到保护服务器的作用。
在一个例子中，若第一负荷分担节点与第一服务器和第二服务器关联，且第一负荷分担节点在当前时刻接收的业务请求负荷量为200caps，第一负荷分担节点配置第一服务器的负荷分发阈值为100caps，配置第二服务器的负荷分发阈值为50caps。由于第一负荷分担节点总的负荷分发阈值为150caps小于200caps，此时第一负荷分担节点会将大于总的负荷分发阈值的部分丢弃，即丢弃50caps的负荷量。
第一负荷分担节点根据负荷分发阈值、第二负荷分担节点向关联的服务器发送的业务请求的负荷量以及自身的负荷信息，获取与第一负荷分担节点关联的服务器待接收的负荷量。
步骤230、第一负荷分担节点根据关联的服务器待接收的负荷量，调整第一负荷分担节点分发的负荷量，以充分利用服务器的业务性能。
在执行步骤230之前，第一负荷分担节点和第二负荷分担节点获取所有关联服务器可以服务的最大负荷量，即服务器可以承担的负荷性能。
第一负荷分担节点根据服务器待接收的负荷量和服务器可以服务的最大负荷量，识别第一负荷分担节点是否充分利用了服务器的业务性能。
可选地，当第一负荷分担节点计算出对两个关联的服务器的待接收业务请求的负荷量的差值与相应两个关联的服务器待接收业务请求的负荷量的和的占比，小于预置的平衡阈值时，第一负荷分担节点不再进行对该两个服务器分发的负荷量的动态调整，即此时第一负荷分担节点分给该两个服务器业务请求的负荷量已达到平衡。
当第一负荷分担节点根据两个关联的服务器待接收业务请求的负荷量的差值与相应两个关联的服务器待接收业务请求的负荷量的和的占比，不小于预置的平衡阈值时，第一负荷分担节点根据两个关联的服务器承载的最大负荷量，增大对该两个服务器分发的负荷量。
在一个例子中，设预置的平衡阈值为0.2，第一负荷分担节点对关联的第一服务器的待接收业务请求的负荷量为50caps，对关联的第二服务器的待接收业务请求的负荷量为70caps。两个待接收业务请求的负荷量的差值为20，两个待发送的负荷量的和为120，其占比为0.17。由于0.17小于0.2，第一负荷分担节点分给第一服务器和第二服务器的业务请求的负荷量已平衡，故不需要动态调整第一负荷分担节点分给第一服务器和第二服务器业务请求的负荷量。
需要说明的是，上述仅仅是一种可实现的方式，为了进一步提高调整的准确性，还可以根据设计需要通过降低预设平衡阈值的方式来实现，如相差0.05-0.1时，不再进行对负荷量的动态调整，本发明实施例在此对平衡服务器负荷量的实现方式不做限定。
进一步的，在某一负荷分担节点失效的情况下，整体负荷分担节点的处理能力将下降。但是通过增大整个系统中某个服务器的负荷分发阈值的数值，可以使服务器系统的业务能力并没有下降。再通过负荷分担节点的对负荷量分担能力的动态调整，获取整个系统的最大处理能力。
可以理解的是，本发明实施例提供的业务处理方法，不仅可以用在负荷分担节点失效的情况下，还可以应用在服务器节点失效，或新加入的负荷分担节点的场景下，本发明实施例在此不做赘述。
下面结合上述图2的方法步骤，对服务器与负荷分担节点间非全网络连接和全网络连接的两种结构的工作过程进行详细描述。
图3的网络组网包括4个bmp，3个slb和n个客户端。bmp与slb为非全网络连接，slb与客户端为全网络连接。每个bmp可以接收100caps应用请求的负荷量。其中，slb负责接入外部系统(如客户端)上报的应用请求，将应用请求路由给合适的应用，并将应用的响应返回给外部系统，也就是说，slb提供负荷分担节点的能力，其可以采用通用的硬件平台来构建。
第一进程：在第一时刻，slba广播自己的负荷信息为：slba接收80caps业务请求。slba向bmp1发送40caps业务请求的负荷量，负荷分发阈值为50caps。slba向bmp2发送40caps业务请求的负荷量，负荷分发阈值为50caps。
该时刻，slbb广播自己的负荷信息为：
slbb接收80caps业务请求。
slbb向bmp1发送40caps业务请求的负荷量，负荷分发阈值为50caps。
slbb向bmp2发送40caps业务请求的负荷量，负荷分发阈值为50caps。
该时刻，slbc广播自己的负荷信息为：
slbc接收80caps业务请求。
slbc向bmp3发送40caps业务请求的负荷量，负荷分发阈值为50caps。
slbc向bmp4发送40caps业务请求的负荷量，负荷分发阈值为50caps。
第二进程：slba收到如上广播报文后，计算出bmp1接收的负荷量总和为40caps，负荷分发阈值为50caps。slba计算出bmp2接收的负荷量总和为80caps，负荷分发阈值为100caps。
slbb收到如上广播报文后，计算出bmp2接收的负荷量总和为80caps，负荷分发阈值为100caps。slbb计算出bmp3接收的负荷量总和为80caps，负荷分发阈值为100caps。
slbc收到如上广播报文后，计算出bmp3接收的负荷量总和为80caps，负荷分发阈值为100caps。slbc计算出bmp4接收的负荷量总和为40caps，负荷分发阈值为50caps。
第三进程：由于bmp1接收业务请求的最大负荷量为50caps，bmp2接收业务请求的最大负荷量为100caps。bmp1与bmp2的业务性能相同，但bmp1最大服务的caps数与bmp2最大服务的caps数不平衡，即不能充分利用bmp1的业务性能。slba可以通过增大bmp1服务的caps数进行调整，由于bmp2最大服务的caps已经100caps，即已实现充分利用，故不需要进行调整。
对于bmp1和bmp2接收的负荷量不均衡的情况，slba可以通过增加向bmp1发送业务请求的负荷量，并减少向bmp2发送业务请求的负荷量，来均衡bmp1和bmp2的负荷量，达到充分利用bmp业务性能。
slba的调整方案如下：
slba调整向bmp1和bmp2发送的负荷量和负荷分发阈值。调整后slba向bmp1发送50caps业务请求的负荷量，负荷分发阈值为100caps。slba向bmp2发送30caps业务请求的负荷量，负荷分发阈值为50caps。
调整后的slba在第二时刻，向其他slb广播自己的负荷信息为：
slba接收80caps业务请求。
slba向bmp1发送50caps业务请求的负荷量，负荷分发阈值为100caps。
slba向bmp2发送30caps业务请求的负荷量，负荷分发阈值为50caps。
进一步的，slbb根据第二进程的比较与计算，识别出bmp2和bmp3分发的业务请求的负荷量是平衡的，即slbb仍然向bmp2发送业务请求40caps的负荷量，负荷分发阈值为50caps，同时向bmp3发送业务请求40caps的负荷量，负荷分发阈值为50caps。
同bmp1与bmp2的情况相同，bmp3最大服务的caps数与bmp4最大服务的caps数不平衡，即不能充分利用bmp4的业务性能，故需要调整slbc向bmp3和bmp4发送的负荷量和分发阈值，该调整方式与slba的调整方式相同，本发明实施例在此不再赘述。
第四进程，通过第三进程的调整，bmp1、bmp2、bmp3和bmp4收到的业务请求结果如下：
bmp1接收到50caps业务请求的负荷量，最大服务的负荷量为100caps，与bmp4相同。
bmp2接收到30+40＝70caps业务请求的负荷量,最大服务的负荷量为100caps，与bmp3相同。
在另一个例子中，图4的网络组网包括10个cbp，3个dccadapter和3个客户端。cbp与dccadapter为全网络连接，dccadapter与客户端为全网络连接。ggsn网元通过dccadapter转发计费请求给cbp(组网中总共cbp1-cbp10组成服务群组对外提供服务)进行计费。dccadapter提供负荷分担节点的能力，cbp1-cbp10提供业务服务器的能力。ggsn网元用于监控用户的流量使用并产生计费请求，计费请求中携带用户的流量使用量。每台cbp可以最大处理300caps，整个服务器系统组网可以处理300*10＝3000caps的计费请求。
在负荷分担节点dccadapter1-dccadapter3正常工作时，每个dccadapter设定最大分发给每个cbp最大100caps的业务处理请求，即整个系统可以处理(100caps*3*10＝3000caps)的业务处理请求的能力。
第一进程：8:00:00，dccadapter1广播自己的负荷信息为：
dccadapter1转发给cbp1计费请求的负荷量为x1caps，转发给cbp1最大计费请求的负荷量为100caps。
dccadapter1转发给cbp2计费请求的负荷量为x2caps，转发给cbp2最大计费请求的负荷量为100caps。
之后的cbp3-cbp10以此类推。
第二进程：当dccadapter3失效，失效的dccadapter3无法处理计费请求，也就无法广播自己的处理情况。但dccadapter1-2可以正常工作。
8:01:00，dccadapter1广播自己的负荷信息仍然为：
dccadapter1转发给cbp1计费请求的负荷量为x1caps，转发给cbp1最大计费请求的负荷量为100caps。dccadapter1转发给cbp2计费请求的负荷量为x2caps，转发给cbp2最大计费请求的负荷量为100caps。
之后的cbp3-cbp10以此类推。
8:01:00，dccadapter2广播自己的负荷信息为：
dccadapter2转发给cbp1计费请求的负荷量为y1caps，转发给cbp1最大计费请求的负荷量为100caps。dccadapter2转发给cbp2计费请求的负荷量为y2caps，转发给cbp2最大计费请求的负荷量为100caps。
之后的cbp3-cbp10以此类推。
第三进程：dccadapter1根据dccadapter2广播的负荷信息，与自己处理的负荷信息，获取cbp1-cbp10服务器的业务处理情况，如：
8:01:00，cbp1处理计费请求x1+y1，系统设定的最大请求100+100＝200caps。
8:01:00，cbp2处理计费请求x2+y2，系统设定的最大请求100+100＝200caps。
之后的cbp3-cbp10以此类推。
第四进程：dccapater1识别出在第三进程中系统设定的cbp1最大请求数200caps，并没有完全发挥cbp1的处理能力，由此dccadapter1调整对每台cbp设定的最大转发业务请求数，并在此时广播自己的处理情况：
8:01:00，dccadapter1转发给cbp1计费请求的负荷量为x1caps，转发给cbp1最大计费请求的负荷量为150caps。
8:01:00，dccadapter1转发给cbp2计费请求的负荷量为x2caps，转发给cbp2最大计费请求的负荷量为150caps。
本发明实施例提供的网络业务处理方法，通过动态调整负荷分担节点下一时刻负荷分发信息和分发阈值，以达到充分利用每台服务器的业务潜力，均衡整个系统的负载情况，从而保证整个通信网络系统的稳定有序运行，进而减少系统崩溃的概率。
需要说明的是，本发明实施例提供的方法还可以将bmp充当互联网超文本传输协议(internethypertexttransferprotocol，internethttp)服务器，用户通过slb分发或中转，使用ie浏览器登录bmp进行业务管理。或者，该方法还可以为多台短消息服务中心(shortmessageservicecenter，smsc)服务器提供功能，给大量用户发送短消息。其中，slb作为负荷分担节点，将大量的发送短消息服务sms请求，转发给smsc进行处理。
本发明实施例提供了一种负荷分担装置，以用于实施上述网络业务处理方法。
图5为本发明实施例提供的一种负荷分担装置可能的结构示意图。如图5所示，该装置可以包括：接收单元510、处理单元520和发送单元530。
接收单元510，用于接收第二负荷分担装置广播发送的当前时刻的负荷信息，第二负荷分担装置为该装置之外的负荷分担装置。
处理单元520，用于根据负荷信息，确定该装置关联的服务器待接收的负荷量。
处理单元520，还用于根据服务器待接收的负荷量，调整发送单元530分发的负荷信息，以充分利用服务器的业务性能。
可选地，该装置还包括发送单元530。发送单元530用于向至少一个第二负荷分担装置广播发送当前时刻的负荷信息。
可选地，负荷信息包括负荷分发信息。处理单元520具体用于根据负荷分发信息，确定与该装置关联的服务器待接收的负荷量。
可选地，负荷信息还包括负荷分发阈值。处理单元520还具体用于根据负荷分发信息和负荷分发阈值，确定与该装置关联的服务器待接收的负荷量。
可选地，处理单元520，还用于获取服务器承载的最大负荷量，并根据服务器待接收的负荷量和服务器承载的最大负荷量，调整发送单元530分发的负荷信息。
该负荷分担装置的各单元的功能，可以通过上述实施例的各步骤中负荷分担节点来实现，因此，本发明实施例提供的负荷分担装置的具体工作过程，在此不复赘述。
图6为本发明实施例提供的另一种负荷分担装置可能的结构示意图。如图6所示，该装置至少包括处理器610、接收器620、发送器630。
可选地，该装置还可以包括储存器640。
处理器610可以是中央处理器(centralprocessingunit，cpu)，或者cpu和硬件芯片的组合。上述硬件芯片可以是专用集成电路(application-specificintegratedcircuit，asic)，可编程逻辑器件(programmablelogicdevice，pld)或其组合。上述pld可以是复杂可编程逻辑器件(complexprogrammablelogicdevice，cpld)，现场可编程逻辑门阵列(field-programmablegatearray，fpga)，通用阵列逻辑(genericarraylogic,gal)或其任意组合。
存储器640可以包括易失性存储器，例如随机存取存储器(ram)；存储器640也可以包括非易失性存储器，例如只读存储器(rom)，快闪存储器(flashmemory)，硬盘或固态硬盘。存储器640还可以包括上述种类的存储器的组合。存储器640用于存储各种应用，操作系统和数据。存储器640可以将存储的数据传输给处理器610。
可以理解的是，存储器640可以集成在处理器610中，也可以独立存在。
接收器620，用于接收第二负荷分担装置广播发送的当前时刻的负荷信息，第二负荷分担装置为除负荷分担装置之外的负荷分担装置。
处理器610，用于根据负荷信息，确定与该装置关联的服务器待接收的负荷量。
处理器610，还用于根据服务器待接收的负荷量，调整发送器630分发的负荷信息，以充分利用服务器的业务性能。
可选地，发送器630，用于向至少一个第二负荷分担装置广播发送当前时刻的负荷信息。
可选地，负荷信息包括负荷分发信息。处理器610，具体用于根据负荷分发信息，确定与该装置关联的服务器待接收的负荷量。
可选地，负荷信息还包括负荷分发阈值。处理器610还具体用于根据负荷分发信息和负荷分发阈值，确定与该装置关联的服务器待接收的负荷量。
可选地，处理器610还用于获取服务器承载的最大负荷量，并根据服务器待接收的负荷量和服务器承载的最大负荷量，调整发送器630分发的负荷信息。
由于上述实施例中负荷分担装置各器件解决问题的实施方式以及有益效果可以参见图2所示的方法实施方式以及有益效果，故在此不复赘述。
结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器、闪存、只读存储器、可擦除可编程只读寄存器(erasableprogrammableread-onlymemory，eprom)存储器、电可擦可编程只读存储器存储器(electricallyerasableprogrammableread-onlymemory，eeprom)、硬盘、光盘或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。当然，处理器和存储介质也可以作为分立组件存在于用户设备中。
本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件、固件实现时，可以将这些功能存储在计算机可读介质中。
以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的技术方案的基础之上，所做的任何修改、改进等，均应包括在本申请的保护范围之内。