工作流服务的故障探测切换方法及系统、计算机存储介质与流程

1.本发明属于weblogic技术领域，更具体的说，尤其涉及一种工作流服务的故障探测切换方法及系统、计算机存储介质。


背景技术：

2.随着银行业务的不断发展，业务流程也日趋复杂，相当多的中后台业务不能通过单一环节完成，要流转至多个环节。基于此，银行系统(主要是流程平台类系统)大量使用了工作流服务，工作流服务指的是一种技术方法，可以根据既定的业务规则，将业务操作流程拆分成具体工作项，如版面识别、影像拆分、一次录入、二次录入、录入仲裁、数据检核、记账等等，对应的业务人员或机器人可以获取到本角色的任务，处理后将结果写入工作流服务，并继续向后流转，从而保证复杂业务的按序处理。
3.weblogic作为一种大型的商业中间件，在银行it系统中得到了广泛的应用，大多数应用程序都是封装在weblogic中间件中，但这种基于weblogic容器的工作流服务因涉及到全局统一的任务排序，为避免任务重复获取和不同主机之间内存数据同步带来的锁和性能下降等问题，一般不支持集群部署。因此，这种基于weblogic工作流服务的高可用问题就成为了亟需解决的难题。


技术实现要素：

4.有鉴于此，本发明的目的在于提供一种工作流服务的故障探测切换方法及系统、计算机存储介质，用于进行探测并自动拉起备工作流服务，减少了人工操作，具有较高的时效性。
5.本技术第一方面公开了一种工作流服务的故障探测切换方法，包括：
6.基于故障探测脚本中预设的间隔时间，所述故障探测脚本向对应的主工作流服务发起探测请求；其中，所述故障探测脚本部署在所述备工作流服务，并在后台挂执行；
7.基于故障探测脚本中预设的探测次数和失败间隔时间，所述故障探测脚本判断所述主工作流服务是否存在故障；
8.若所述主工作流服务存在故障，则调起所述备工作流服务的启动脚本，启动所述备工作流服务接管业务。
9.可选的，调起所述备工作流服务的启动脚本，启动备工作流服务接管业务之前，还包括：
10.判断所述备工作流服务是否启动；
11.若否，则执行所述调起所述备工作流服务的启动脚本，启动所述备工作流服务接管业务的步骤。
12.可选的，在判断所述备工作流服务是否启动之后，还包括：
13.若所述备工作流服务已启动，则返回执行所述基于故障探测脚本中预设的间隔时间，所述故障探测脚本向对应的主工作流服务发起探测请求的步骤。
14.可选的，基于故障探测脚本中预设的探测次数和失败间隔时间，所述故障探测脚本判断所述主工作流服务是否存在故障，包括：
15.所述故障探测脚本判断是否连续进行预设次数探测均失败；
16.若是，则判定所述故障探测脚本判定所述主工作流服务存在故障；
17.若否，则判定所述故障探测脚本判定所述主工作流服务未存在故障。
18.可选的，所述故障探测脚本判断是否探测失败，包括：
19.所述故障探测脚本根据提供的接口对所述主工作流服务进行访问；
20.若接收到所述主工作流给出应答，则表示所述主工作流服务正常、探测成功；
21.若未接收到所述主工作流给出应答，则表示所述主工作流服务异常、探测失败。
22.本技术第二方面公开了一种工作流服务的故障探测切换系统，包括：
23.请求单元，用于基于故障探测脚本中预设的间隔时间，所述故障探测脚本向对应的主工作流服务发起探测请求；其中，所述故障探测脚本部署在所述备工作流服务，并在后台挂执行；
24.故障判断单元，用于基于故障探测脚本中预设的探测次数和失败间隔时间，所述故障探测脚本判断所述主工作流服务是否存在故障；
25.调起单元，用于若所述故障判断单元判定所述主工作流服务存在故障，则调起所述备工作流服务的启动脚本，启动所述备工作流服务接管业务。
26.可选的，还包括：
27.第一判断单元，用于判断所述备工作流服务是否启动；
28.若否，则触发所述调起单元执行所述调起所述备工作流服务的启动脚本，启动备工作流服务接管业务的步骤。
29.可选的，故障判断单元用于基于故障探测脚本中预设的探测次数和失败间隔时间，所述故障探测脚本判断所述主工作流服务是否存在故障时，具体用于：
30.所述故障探测脚本判断是否连续进行预设次数探测均失败；
31.若是，则判定所述故障探测脚本判定所述主工作流服务存在故障；
32.若否，则判定所述故障探测脚本判定所述主工作流服务未存在故障。
33.可选的，故障判断单元用于所述故障探测脚本判断是否探测失败时，具体用于：
34.所述故障探测脚本根据提供的接口对所述主工作流服务进行访问；
35.若接收到所述主工作流给出应答，则表示所述主工作流服务正常、探测成功；
36.若未接收到所述主工作流给出应答，则表示所述主工作流服务异常、探测失败。
37.本技术第三方面公开了一种计算机存储介质，其上存储有计算机程序，其中，计算机程序被处理器执行时实现如本技术第一方面任一项所述的工作流服务的故障探测切换方法。
38.从上述技术方案可知，本发明提供的一种工作流服务的故障探测切换方法，包括：基于故障探测脚本中预设的间隔时间，故障探测脚本向对应的主工作流服务发起探测请求；其中，故障探测脚本部署在备工作流服务，并在后台挂执行；基于故障探测脚本中预设的探测次数和失败间隔时间，故障探测脚本判断主工作流服务是否存在故障；若主工作流服务存在故障，则调起备工作流服务的启动脚本，启动备工作流服务接管业务；也即，当主工作流服务故障或无法正常提供服务后，可通过该方法进行探测并自动拉起备工作流服
务，减少了人工操作，具有较高的时效性；同时，不需要申请共享存储，只需要在备工作流服务上部署相关脚本，部署方案较为简单，且不存在频繁的io读写问题。
附图说明
39.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
40.图1是本发明实施例提供的一种工作流服务的故障探测切换方法的流程图；
41.图2是本发明实施例提供的另一种工作流服务的故障探测切换方法的流程图；
42.图3是本发明实施例提供的一种工作流服务的故障探测切换系统的示意图。
具体实施方式
43.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
44.在本技术中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
45.需要说明的是，高可用性(highavailability)通常来描述一个系统经过专门的设计，从而减少因硬件故障，程序缺陷等软硬件因素导致的停工时间，而保持其服务的高度可用性。常见的高可用方式包括主从方式、双机双工方式、集群工作方式等。
46.本技术实施例提供了一种工作流服务的故障探测切换方法，用于解决现有技术中weblogic作为一种大型的商业中间件，在银行it系统中得到了广泛的应用，大多数应用程序都是封装在weblogic中间件中，但这种基于weblogic容器的工作流服务因涉及到全局统一的任务排序，为避免任务重复获取和不同主机之间内存数据同步带来的锁和性能下降等问题，一般不支持集群部署的问题。
47.参见图1，该工作流服务的故障探测切换方法，包括：
48.s101、基于故障探测脚本中预设的间隔时间，故障探测脚本向对应的主工作流服务发起探测请求。
49.其中，故障探测脚本部署在备工作流服务，并在后台挂执行。
50.该故障探测脚本可以由系统的运维人员上传，并在后台挂起执行。
51.只需要在备工作流服务上部署相关脚本，部署方案较为简单。方法通过封装成shell脚本的方式，采用后台执行脚本并将脚本作为常驻进程nohup sh xx.sh&的方式即可在后台挂起执行。
52.s102、基于故障探测脚本中预设的探测次数和失败间隔时间，故障探测脚本判断
主工作流服务是否存在故障。
53.需要说明的是，故障探测脚本的参数是可以设置的，例如：
54.try_times＝2#队列探测次数；
55.delay＝5#失败后的间隔时间(秒)；
56.time_sleep＝30#下一轮的间隔时间(秒)；
57.其中，try_times即工作流服务探测次数，该参数决定了连续进行多少次探测失败，才会认为对应的主工作流服务出现故障。delay即失败后的间隔时间，即一次探测失败后会在该参数定义的时间后再次进行二次探测。time_sleep为下一轮的间隔时间，即一次探测判断主工作流服务无故障后会在该参数定义的时间后再进行二次探测。通过如上三个参数的配置，可以根据业务的重要程度自适应调整工作流服务探测及切换方法的敏感度。
58.若主工作流服务存在故障，则执行步骤s103。
59.s103、调起备工作流服务的启动脚本，启动备工作流服务接管业务。
60.在本实施例中，基于故障探测脚本中预设的间隔时间，故障探测脚本向对应的主工作流服务发起探测请求；其中，故障探测脚本部署在备工作流服务，并在后台挂执行；基于故障探测脚本中预设的探测次数和失败间隔时间，故障探测脚本判断主工作流服务是否存在故障；若主工作流服务存在故障，则调起备工作流服务的启动脚本，启动备工作流服务接管业务；也即，当主工作流服务故障或无法正常提供服务后，可通过该方法进行探测并自动拉起备工作流服务，减少了人工操作，具有较高的时效性；同时，不需要申请共享存储，只需要在备工作流服务上部署相关脚本，部署方案较为简单，且不存在频繁的io读写问题。
61.需要说明的是，现有技术中，方法一：部署一套备工作流服务，备工作流服务平时不启动，同时对主工作流服务设置监控，在主工作流服务宕掉后，手动启动备用服务；方法二：配置一套备工作流服务，同时在主工作流中部署进程监控脚本，将主工作流的进程数量写入到共享存储中，备工作流定时去共享存储中获取主工作流的进程数量，当进程数量异常时，备工作流调起自己的启动脚本，接管业务；而方法一即我们常说的冷备的方式，其优点是部署模式简单，但缺点也很明显，所有的操作需要依赖人工进行，处置速度难以保证，无法满足时效性要求。对于重要业务来讲，分钟级的中断就会带来较大的业务影响；方法二可以在一定程度上实现故障工作流服务的自动切换，但也存在一些问题，主要包括：a、方法二是基于检查进程数量的方式判断主工作流是否故障，存在一种特殊情况，当主工作流服务夯死时，进程本身存在，但已经无法提供服务，此时，该方法无法实现对备工作流服务的拉起；b、该方案需在主备工作流服务上分别部署脚本，部署方案比较复杂，且需要申请共享存储记录主工作流的状态，需要较多的资源。同时，该方法需要频繁对共享存储进行读写，存在一定的i/o压力。
62.而本技术实施例中，能实现主工作流服务故障后的自动切换，减少了人工操作，具有较高的时效性；不需要申请共享存储，只需要在备工作流服务上部署相关脚本，部署方案较为简单，且不存在频繁的io读写问题；支持参数化调整探测频率和压制次数，用户可根据业务的重要程度调整该方法的敏感度；以及，通过远程访问主工作流服务的方法而非简单地探测主工作流服务相关进程是否存在的方法，探测结果更精准。
63.在实际应用中，在步骤s103、调起备工作流服务的启动脚本，启动备工作流服务接管业务之前，还包括：判断备工作流服务是否启动。
64.若否，则执行步骤s103、调起备工作流服务的启动脚本，启动备工作流服务接管业务。
65.在实际应用中，在判断备工作流服务是否启动之后，还包括：
66.若备工作流服务已启动，则返回执行步骤s101。
67.也就是说，在判断主工作流服务故障之后，先检查备工作流服务是否拉起，若未被拉起，则调用本地的启动脚本拉起备工作流服务，若备工作流已被拉起，则继续上述循环。
68.具体的，相应的代码文本信息如下：
69.if[$ret-ne 0]；then
[0070]
echo"不正确，详细信息如下:"
[0071]
printf"$log\n"
[0072]
ps＝$(ps-ef|grep"dweblogic.name＝$servername"|grep java)
[0073]
if[$？-eq 0]；then
[0074]
echo"但是，备份服务器$servername已经起动.进程信息如下:"
[0075]
echo"uid pid ppid c stime tty time cmd"
[0076]
echo$ps
[0077]
else
[0078]
echo"起动$organ队列所在的服务器$servername..."
[0079]
cd$domain_path/bin
[0080]
./nm_start_mserver.sh$servername
[0081]
cd$shellpath
[0082]
echo
[0083]
fi
[0084]
else
[0085]
echo"正常"
[0086]
fi
[0087]
}
[0088]
while[true]；do
[0089]
date"+％y-％m-％d％h:％m:％s"
[0090]
for((i＝0；i《${#serverinfo[*]}；i++))；do
[0091]
read servername ip appname《《《$(echo${serverinfo[$i]})
[0092]
echo servername ip appname is:$servername$ip$appname
[0093]
detect
[0094]
done
[0095]
sleep$time_sleep
[0096]
done
[0097]
该文本代码所要实现的功能为在判断主工作流服务故障之后，先检查备工作流服务是否拉起，若未被拉起，则调用本地的启动脚本拉起备工作流服务，若备工作流已被拉起，则继续上述循环。
[0098]
在实际应用中，步骤s102、基于故障探测脚本中预设的探测次数和失败间隔时间，
故障探测脚本判断主工作流服务是否存在故障，包括：
[0099]
1)、故障探测脚本判断是否连续进行预设次数探测均失败。
[0100]
若是，则执行步骤2)。
[0101]
2)、故障探测脚本判定主工作流服务存在故障。
[0102]
若否，则执行步骤3)。
[0103]
3)、故障探测脚本判定主工作流服务未存在故障。
[0104]
需要说明的是，具体的探测脚本可以为：
[0105]
detect()
[0106]
{
[0107]
(！ifconfig|grep-w$ip》/dev/null)&&return
[0108]
organ＝$(expr$(echo$appname|sed"s/cosmainqueue//")\*1)
[0109]
organ＝${orgs[$organ]}
[0110]
printf"机构$organ的队列状态:"
[0111]
try＝0
[0112]
while[$try-lt$try_times]
[0113]
do
[0114]
log＝$(java-dsun.lang.classloader.allowarraysyntax＝true-cp${class_path}com/ccb/cost/management/dailymaintain/execqueuemonitor$organ2》/home/ap/cost/switch.log)
[0115]
ret＝$？
[0116]
printf"."
[0117]
if[$ret-eq 0]；then
[0118]
break
[0119]
fi
[0120]
try＝$(expr$try+1)
[0121]
sleep$delay
[0122]
done
[0123]
也即，在探测时，该脚本调用了execqueuemonitor方法来判断工作流服务的活动状态。execqueuemonitor主要是使用了rmi(remote method invoication)的一个接口。rmi是java编程语言里，一种用于实现远程过程调用的应用程序编程接口。
[0124]
在实际应用中，上述所涉及的故障探测脚本判断是否探测失败，包括：
[0125]
故障探测脚本根据提供的接口对主工作流服务进行访问。
[0126]
若接收到主工作流给出应答，则表示主工作流服务正常、探测成功。
[0127]
若未接收到主工作流给出应答，则表示主工作流服务异常、探测失败。
[0128]
具体的，主工作流服务提供一个服务端接口，探测方法根据提供的接口对主工作流服务进行访问，若主工作流给出应答，则表示主工作流服务正常；若主工作流无法给出应答，则表述主工作流服务异常。核心代码如下：
[0129]
public int getqueuestatus(string centercode){
[0130]
int revalue＝1；
[0131]
connection conn＝null；
[0132]
properties props＝null；
[0133]
try{
[0134]
conn＝this.connectionmanager.getconnection()；
[0135]
props＝dateexportutil.getqclientpropertiesfromdb(conn)；
[0136]
configuration.instance.init(props)；
[0137]
qworkitemhandlerworkitemhandler＝null；
[0138]
if(centercode！＝null&&centercode.tolowercase().contains("auto".tolowercase())){
[0139]
workitemhandler＝workitemhandlerfactory.getdefaulthandler()；
[0140]
}else if(centercode！＝null){
[0141]
workitemhandler＝workitemhandlerfactory.getrmihandlerbyarea(centercode)；
[0142]
}else{
[0143]
log.error("队列＝"+centercode+"，参数异常")；
[0144]
}
[0145]
taskqgroupstatus status＝workitemhandler.getstatus()；
[0146]
string description＝status.getdescription()；
[0147]
if(！"state_running".equals(description)&&！"正在运行".equals(description)&&！"state_initializing".equals(description)&&！"正在初始化".equals(description)){
[0148]
log.error("队列＝"+centercode+"，状态＝"+description)；
[0149]
}else{
[0150]
revalue＝0；
[0151]
log.info("队列＝"+centercode+"，状态＝"+description)；
[0152]
}
[0153]
}catch(throwable var12){
[0154]
revalue＝1；
[0155]
log.error(var12.getmessage()+"获取队列"+centercode+"运行状态异常"，var12)；
[0156]
}finally{
[0157]
this.safeclose(conn，revalue)；
[0158]
}
[0159]
returnrevalue；
[0160]
}
[0161]
使用如上方法比只进行简单的进程数量检查要更加准确，避免了应用进程虽然存在，但是已经无法提供服务。
[0162]
需要说明的是，若主工作流正常，则不会在探测失败delay后继续探测，而是在time_sleep后继续探测，这两个参数都是可设置的，通常time_sleep值会比delay更大。
[0163]
当探测脚本发现主工作流服务满足相关参数后，则判断主工作流服务故障。
[0164]
需要说明的是，如图2所示，具体的探测切换过程为：
[0165]
(1)故障探测脚本开始执行。
[0166]
(2)根据预设参数进行探测。
[0167]
(3)判断主队列是否存在故障，也即主工作流服务是否存在故障。
[0168]
若是，则执行步骤(4)；若否，则流程结束，等待下一轮的间隔时间time_sleep后，继续探测。
[0169]
(4)判断失败后的间隔时间delay后继续探测主工作流服务是否存在故障。
[0170]
若否，则流程结束，等待下一轮的间隔时间time_sleep后，继续探测。若是，则执行步骤(5)。
[0171]
(5)探测备工作流服务是否被拉起。
[0172]
若是，则流程结束，等待下一轮的间隔时间time_sleep后，继续探测。若是，则执行步骤(6)。
[0173]
(6)调用备工作流服务的启动脚本，启动服务。
[0174]
本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。
[0175]
虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序来执行。在一定环境下，多任务和并行处理可能是有利的。
[0176]
应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。
[0177]
可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括但不限于面向对象的程序设计语言—诸如java、smalltalk、c++，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
[0178]
本技术另一实施例提供了一种工作流服务的故障探测切换系统。
[0179]
参见图3，该工作流服务的故障探测切换系统，包括：
[0180]
请求单元101，用于基于故障探测脚本中预设的间隔时间，故障探测脚本向对应的主工作流服务发起探测请求；其中，故障探测脚本部署在备工作流服务，并在后台挂执行。
[0181]
故障判断单元102，用于基于故障探测脚本中预设的探测次数和失败间隔时间，故障探测脚本判断主工作流服务是否存在故障。
[0182]
调起单元103，用于若故障判断单元102判定主工作流服务存在故障，则调起备工作流服务的启动脚本，启动备工作流服务接管业务。
[0183]
在实际应用中，该工作流服务的故障探测切换系统还包括：
[0184]
第一判断单元，用于判断备工作流服务是否启动。
[0185]
若否，则触发调起单元103执行调起备工作流服务的启动脚本，启动备工作流服务接管业务的步骤。
[0186]
在实际应用中，故障判断单元102用于基于故障探测脚本中预设的探测次数和失败间隔时间，故障探测脚本判断主工作流服务是否存在故障时，具体用于：
[0187]
故障探测脚本判断是否连续进行预设次数探测均失败。
[0188]
若是，则判定故障探测脚本判定主工作流服务存在故障。
[0189]
若否，则判定故障探测脚本判定主工作流服务未存在故障。
[0190]
在实际应用中，故障判断单元102用于故障探测脚本判断是否探测失败时，具体用于：
[0191]
故障探测脚本根据提供的接口对主工作流服务进行访问。
[0192]
若接收到主工作流给出应答，则表示主工作流服务正常、探测成功。
[0193]
若未接收到主工作流给出应答，则表示主工作流服务异常、探测失败。
[0194]
该各个单元的具体工作过程和原理，详情参见上述实施例提供的工作流服务的故障探测切换方法，此处不再一一赘述，视实际情况而定即可，均在本技术的保护范围内。
[0195]
在本实施例中，请求单元101基于故障探测脚本中预设的间隔时间，故障探测脚本向对应的主工作流服务发起探测请求；故障判断单元102基于故障探测脚本中预设的探测次数和失败间隔时间，故障探测脚本判断主工作流服务是否存在故障；调起单元103若主工作流服务存在故障，则调起备工作流服务的启动脚本，启动备工作流服务接管业务；也即，当主工作流服务故障或无法正常提供服务后，可通过该方法进行探测并自动拉起备工作流服务，减少了人工操作，具有较高的时效性；同时，不需要申请共享存储，只需要在备工作流服务上部署相关脚本，部署方案较为简单，且不存在频繁的io读写问题。
[0196]
描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元的名称在某种情况下并不构成对该单元本身的限定，例如，第一获取单元还可以被描述为“获取至少两个网际协议地址的单元”。
[0197]
本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、片上系统(soc)、复杂可编程逻辑设备(cpld)等等。
[0198]
本技术另一实施例提供了一种计算机存储介质，其上存储有计算机程序，其中，计算机程序被处理器执行时实现如上述实施例中任意一项的工作流服务的故障探测切换方法。
[0199]
在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
[0200]
需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、rf(射频)等等，或者上述的任意合适的组合。
[0201]
上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。
[0202]
本说明书中的各个实施例中记载的特征可以相互替换或者组合，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
[0203]
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
[0204]
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。