一种服务器、分布式服务器集群及其状态驱动方法
技术领域
本申请涉及数据库领域,尤其涉及一种服务器、分布式服务器集群及其状态驱动方法。
背景技术
数据库(Database)是按照数据结构来组织、存储和管理数据的仓库,在各个领域都得到了广泛的应用。随着科学技术的发展,数据库的方式也由集中式数据库发展为分布式数据库,但是,在分布式数据库中,客户端和服务端通过长链接进行注册,长链接是指基于套接字(Socket)的链接,其中,控制台通过短链接向服务端发送控制命令给客户端,短链接是指基于会话对象(Session)的链接,控制台有多个,服务端是一个集群,客户端也是一个集群,因此,如何把控制命令发送给指定的客户端并实现强一致和容错,并把客户端应答返回给发送的控制台,这需要更可靠的分布式服务器集群。
发明内容
本发明了提供了一种服务器、分布式服务器集群及其状态驱动方法。
第一方面,本说明书实施例提供了一种分布式服务器集群的状态驱动方法,包括:
基于分布式服务器集群的一节点中本地对象的当前状态执行处理逻辑;
在所述处理逻辑被执行完成后,触发与所述本地对象关联的集群对象的状态变化;以及
所述节点获取所述分布式服务器集群的变化信息,并将所述变化信息同步到所述节点的本地对象;
利用所述本地对象的状态变化触发所述节点的本地回调,以更新所述节点的状态。
第二方面,本说明书实施例提供了一种分布式服务器集群的状态驱动装置,包括:
执行单元,用于基于分布式服务器集群的一节点中本地对象的当前状态执行对应的处理逻辑;
触发单元,用于在所述处理逻辑被执行完成后,触发与所述本地对象关联的集群对象的状态变化;
同步单元,用于获取所述分布式服务器集群的变化信息,并将所述变化信息同步到所述节点的本地对象;
回调单元,用于利用所述本地对象的状态变化触发所述节点的本地回调,以更新所述节点的状态。
第三方面,本说明书实施例提供了一种服务器,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现第一方面任一项所述方法的步骤。
第四方面,本说明书实施例提供了一种分布式服务器集群,包括多第二方面所述的服务器。
第五方面,说明书实施例提供了分布式系统,包括客户端、控制台和如第四方面所述的分布式服务器集群。
第六方面,本说明书实施例提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现第一方面任一项所述方法的步骤。
本说明书实施例有益效果如下:
由于利用了本地对象的状态变化来触发关联的集群对象的状态变化,以及根据分布式服务器集群的变化信息将变化信息更新到本地对象并触发本地回调,所以保证了本地事件状态和集群事件状态的强一致性,实现了本地回调,并且,由于通过状态驱动的方式来驱动节点状态和集群状态发生变化,简化了代码的开发,提升了代码的可读性。
附图说明
图1为本说明书实施例提供的分布式服务器集群的使用场景图;
图2为本说明书实施例提供的分布式服务器集群的状态驱动方法的流程图;
图3A示出了本说明书实施例提供的ZooKeeper的节点目录结构,图3B示出了本说明书实施例提供的ZooKeeper中SERVER节点的初始化过程,图3C示出了本说明书实施例提供的ZooKeeper中Leader节点的失效的处理过程;图3D示出了本说明书实施例提供的ZooKeeper中Worker节点的失效的处理过程;
图4为本说明书实施例提供的分布式服务器集群的状态驱动装置的模块图;
图5为本说明书实施例提供的服务器的结构示意图。
具体实施方式
为了更好的理解上述技术方案,下面通过附图以及具体实施例对本说明书实施例的技术方案做详细的说明,应当理解本说明书实施例以及实施例中的具体特征是对本说明书实施例技术方案的详细的说明,而不是对本说明书技术方案的限定,在不冲突的情况下,本说明书实施例以及实施例中的技术特征可以相互组合。
请参考图1,图1为本说明书实施例提供的分布式服务器集群的使用场景图,如图1所示,从物理层面来说,分布式服务器集群10可以包括多个服务器101,从虚拟层面来说,分布式服务器集群10包括多个节点101,其中节点指的是某个独立的Server进程,可以用IP+端口来区分,节点可以部署在一台或者多台服务器上,一般来说一台物理服务器独立部署一个节点,以实现高可用,图1中的101可以是服务器,也可以是节点,在此不做限制。
请继续参考图1,客户端11与分布式服务器集群10之间的通信方式为基于Socket的长链接,控制台12与分布式服务器集群10之间的通信方式为基于Session的短链接。
本说明书实施例提供的分布式服务器集群的状态驱动方法即基于图1所示的服务器集群的系统架构,请参考图2,图2为本说明书实施例提供的分布式服务器集群的状态驱动方法的流程图,如图2所示,该方法包括:
S1:基于分布式服务器集群的一节点中本地对象的当前状态,执行对应的处理逻辑;其中,节点中本地对象可以是需要和分布式服务器集群中集群对象保持一致的数据单元,例如,某一节点中本地对象为一Session,该Session的状态可以为生命周期终止、过期、初始化、提交到集群、被消费、驱动回应或已应答给客户端中的任一个状态,设定该Session的状态例为被消费,则可以基于该Session的状态执行对应的处理逻辑,则该Session的状态会变化为驱动回应;相应地,分布式服务器集群中也保存有与该Session关联的对象,也即集群对象;
S3:在处理逻辑被执行完成后,触发与本地对象关联的集群对象的状态变化;例如,该节点中Session的状态变化为驱动回应之后,则能够被分布式服务器集群通过集群监听器等方式检测到,从而即能够触发分布式服务器集群中与与该Session关联的集群对象的状态变化,沿用前面的具体例子,分布式服务器集群中与该Session关联的集群对象的状态就由“被消费”变为了“驱动回应。”这样,保证了节点和分布式服务器集群之间的数据强一致性,也即保证了本地事件状态和集群事件状态的强一致性;以及
S5:节点获取分布式服务器集群的变化信息,并将变化信息同步到节点的本地对象;例如,分布式服务器集群中其他节点发生了状态变化,例如其他节点中某一个变为不可用等等,则该节点可以通过分布式服务器集群的集群监听器等方式,获取分布式服务器集群的变化信息,这样即能够根据该变化信息并将变化信息同步到节点的本地对象中,例如在该节点中,节点目录作为该节点的本地对象之一,可以用于记录分布式服务器集群的节点状态变化情况,因此可以将变化信息同步到节点中的节点目录中,这样,该节点就不会向该已经变为不可用状态的节点发送信息;
S7:利用本地对象的状态变化触发节点的本地回调,以更新节点的状态,具体来讲,由于S5中本地对象已经发生了状态变化,所以可以利用该状态编号来触发节点的本地回调,从而更新该节点的状态,沿用前面的例子,此时更新的节点状态具体是:其他节点中某一个为不可用(即S5中获知的信息);在实际应用中,节点的状态是指该节点在集群中的状态,例如节点本身是否可用,该节点具体是什么类型的节点,该节点中有哪些本地对象,这些本地对象的状态是什么等等。这样,保证了节点和分布式服务器集群之间的数据强一致性,也即集群事件状态和本地事件状态的强一致性。
需要说明的是,上述对本说明书特定实施例进行了描述。其他实施例在所附权利要求书范围内。在一些情况下,在权利要求书中记载的动作或者步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能够实现期望的结果。在某些实施例中,多任务处理和并行处理也是可能的或者可能是更有利的。
可以看出,由于利用了本地对象的状态变化来触发关联的集群对象的状态变化,以及根据分布式服务器集群的变化信息将变化信息更新到本地对象并触发本地回调,所以保证了本地事件状态和集群事件状态的强一致性,同时实现了本地回调,并且,由于通过状态驱动的方式来驱动节点本地状态和集群状态发生变化,简化了代码的开发,提升了代码的可读性。
在接下来的部分中,将详细介绍上述技术方案。
在具体实施过程中,分布式服务器集群10的的状态驱动方法实现方式有许多种类,也即分布式服务器集群10的状态驱动方法所采用的编程语言或者编程方案可以是任一种能够实现本说明书实施例中介绍的步骤或者功能即可,在此不做限制。
在本说明书实施例中,为了详细地介绍本说明书实施例中的技术方案,将以分布式服务器集群10的状态驱动方法利用ZooKeeper来实现进行介绍。其中,ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,它是集群的管理者,监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终,将简单易用的接口和性能高效、功能稳定的系统提供给用户。
需要说明的是,在本说明书实施例中,生产者和消费者是指操作系统中一种常用且重要的模型中的两个角色,该模型描述的是一种等待和通知的机制,属于本领域技术人员的公知技术,在接下来的部分中不再赘述。
请参考图3A~图3C,图3A示出了本说明书实施例提供的ZooKeeper的节点目录结构,图3B示出了本说明书实施例提供的ZooKeeper中Server节点的初始化过程,图3C示出了本说明书实施例提供的ZooKeeper中Leader节点的失效的处理过程;图3D示出了本说明书实施例提供的ZooKeeper中Worker节点的失效的处理过程。
如图3A所示,节点分为两类节点:Leader节点和Worker节点。其中,Leader和Worker功能相互独立互不干涉,彼此之间不直接进行通信,只通过ZooKeeper进行通信。Worker节点间目前数据量传输不大,彼此之间也不直接进行通信,只会通过ZooKeeper进行通信;Leader节点和Worker节点采用进程的方式启动;无论是启动Leader还是Worker都是相同的代码,在部署上并不区分节点类型,通过Leader Election来区分应该成为哪个角色。可以看出,通过状态驱动的方式来驱动节点本地状态和集群状态发生变化,在代码的开发过程中无需针对Leader节点和Worker节点进行区别,简化了代码的开发,提升了代码的可读性。
基于图3A~图3C所示的ZooKeeper中各类型节点的初始化过程,在接下来的部分中,将介绍本说明书实施例提供的分布式服务器集群中各类事件的处理步骤:
A、Socket Worker接收到生产者的事件(Event)请求→在ZooKeeper Socket目录对应的Worker节点上创建事件节点,并监听事件的状态变化→将事件的状态变化通过Socket反馈给生产者;步骤A相当于执行了图2所示的分布式服务器集群的状态驱动方法中的S1和S3,其中生产者例如可以是分布式服务器集群10中的节点101、客户端11或控制台12,生产者的事件请求也即本地对象,创建事件节点也即与本地对象关联的集体对象,这样,通过事件的状态变化来驱动Worker节点上事件节点变化,使得集群对象与本地对象保持一致;
可选地,在生产者为控制台12时,步骤A能够实现控制台的事件回调,例如控制台12向分布式服务器集群10发出了一个命令,分布式服务器集群10会根据该命令的执行状态的变化向控制台12返回信息,这样即实现了控制台的事件回调,从而使得控制台能够清楚地了解所发出命令的执行状态,在此就不再赘述了;
B、Leader监听到新事件节点的建立,将事件分发成具体到某个Session的事件,并在Session的事件列表里建立相应的事件节点;
C、驱动器轮询Worker节点,获取需要处理的事件→将事件处理结果通过REST(REpresentational State Transfer,表属性状态传递)接口反馈给Worker节点→Worker节点更新自己对应的事件的状态和Socket事件的状态,以及将结果存储数据库;步骤C相当于执行了图2所示的分布式服务器集群的状态驱动方法中的S5和S7,Worker节点通过获取变化信息,并将所述变化信息同步到所述节点的本地对象,再根据本地对象的状态变化触发本地回调,这样即能够更新Worker节点的本地状态,通过事件的状态变化来驱动Worker节点上的本地状态变化,使得本地对象与集群对象保持一致;
D、生产者通过生产者Socket将事件请求发送给Socket Worker→接收到生产者Socket的反馈后,读取数据库从而获取到相应的结果。
在具体实施过程中,消费者Session连接分布式服务器集群可以由如下步骤实现:
1、消费者可以使用动态域名绑定服务,随机对域名绑定的连接分布式服务器集群中一族节点中的某一Worker节点进行请求,如果请求的节点失效(fail),则超时之后该消费者选择另外一个节点连接;
2、被请求的该节点会根据ZooKeeper集群上的节点Session数量计算出最空闲的节点,将最空闲节点的IP端口返回给消费者;
3、消费者连接被返回的节点,若被返回的节点fail,消费者等待超时之后进行重连,回到步骤1;若节点拓扑发生变化,由于网络问题消费者等待超时之后重连,请求的节点已经不是负载最小的节点,该节点会继续计算返回一个负载最小的节点,消费者连接新的节点。
分布式服务器集群中对应的Leader节点会定时检查过去的消费者Session,并清理掉过期的消费者Session。
在具体实施过程中,消费者Session的建立可以由如下步骤实现:
1、消费者本地无可用Session_id,请求节点创建Session,节点返回Session_id,同时在ZooKeeper集群上注册相应的Session;这一步骤相当于节点建立一个本地对象,同时分布式服务器集群保存一个与该本地对象关联的集群对象,实质上,该集群对象为该本地对象的反序列化对象;
2、消费者定期使用心跳和节点进行通信,每次通信成功时,节点会更新Session的接触时间(touch time);
3、Session在touch time经过预设时间之后失效,失效后,节点会抛出自动异常,提示驱动重新请求创建Session,回到1;
当然,若消费者本地有Session_id,使用Session_id和节点进行通信时,节点发现ZooKeeper集群上无该Session,说明Session已经过期,节点会抛出AuthException,提示驱动重新请求创建Session,回到1。
在实际应用中,Session可以分两种,一种是和ZooKeeper连接的节点Session,另一种是消费者维持用于业务处理的Session。
其中,和ZooKeeper连接的节点Session可以叫ZSession,由ZooKeeper客户端维持,通过EPHEMERAL NODE(临时节点,一种类的实现方式)实现,在客户端连接断开预设时间例如设置为TIMEOUT的时间后失效,不主动过期,可以用于检测节点状态。
消费者维持用于业务处理的Session可以叫DSession,由消费者维持,为持久化到ZooKeeper的节点,不因为连接断开而失效,DSession作为持久化节点,可以在ZooKeeper的节点上进行迁移(Leader分配),由消费者主动注销或自身预设时间段不激活(TIMEOUT)后失效,失效后,需要将该DSession中未处理的事件存入数据库中作为日志。当然,也可以设计DSession绑定到消费者实例,并且设计恢复机制从数据库中取回也是可以的。
DSession的设计可以如下:DSession由Server集群产生并持久化到ZooKeeper,消费者实例在内存中维持该DSession并用于和集群进行通信,DSession_ID保持全集群唯一。
由于DSession可能会因为Worker failed而进行迁移,因此需要保存一个Transfering标记位,用于标识该DSession是否处于迁移状态。当然,由于网络问题和驱动fail的问题导致DSession TIMEOUT,会使得原有DSession被删除,新的连接(无论消费者是否fail)都会创建新的Session重新开始。DSession过期由Leader定期扫描完成,过期误差可以为扫描的周期。
在具体实施过程中,Session过期检查和销毁可以通过如下步骤来实现:
1、可以使用集群延迟队列的方式进行Session过期判断,集群延迟队列监听为全节点监听,获取到消费者权限的节点,负责进行Session检测判断;
2、检测间隔可以根据(网络延迟+消费者重连耗时+心跳间隔)*N进行确定,当然N为正整数,具体数值不做选择,集群延迟队列的消费者检测该Session是否过期,如果过期,则删除该Session,不重复放入集群延迟队列中,如果未过期,则将Session再放入集群延迟队列中;当然,获取到消费者权限的节点,在Session timeout的情况下,处理Session过程中节点fail,因此节点必须保证先删除处理Session完毕,再移除集群延迟队列中的Session_id;
3.事件处理:
事件存在自己的生命周期,事件过期检查目前在Session过期检查中处理,消费到Session_id的节点,判断Session过期有两种情况:a、过期:将节点下的所有事件删除并存入数据库;b、没过期:将节点下的过期事件删除并存入数据库;当然,过期判断中,操作某个Session中,必须先获得Session写锁,写锁会阻塞其他Session操作的读写操作。
在具体实施过程中,Session机制为集群特性高可用,并可以在节点fail自动转移,Session转移可以由如下步骤实现:
1、节点不在本地保存Session信息,所有Session状态都在ZooKeeper集群上保存;
2、任何时候对于消费者请求中的一个Session_id,接受请求的节点,都会在ZooKeeper集群上进行Session操作和判断,并使用读写锁进行互斥操作,只有判断Session过期,以及删除Session的时候是写锁,其他为读锁;其中,对于某节点的RMS(Read-Modify-Set,读取修改集),ZooKeeper可以保证其原子性,但是对于一批节点的RMS无法保证,因此对于一批节点的操作,需要使用分布式锁,例如:
List<String>nodes=Node.getChildren(path”,watch,stat);
For(String n:nodes){//do some node-relationed operations}
可以看出,在for循环内并不能保证其原子性,如果Leader此时需要计算出一批节点信息并协调任务时,则需要使用分布式锁,也即读写锁;
3、删除Session可以是任意一个节点,该节点为集群延迟队列的消费者,但是同一时刻只会有一个节点处理一个Session。
在具体实施过程中,分布式服务器集群的事件可以分为两类:请求事件和响应事件;其中。请求事件为生产者发给Server,响应事件为消费者回应给Server。
事件状态的状态,也即本地对象的状态可以为生命周期终止、过期、初始化、提交到集群、被消费、驱动回应或已应答给客户端。在实际应用中,可以将生命周期终止的序号值设置为-2,可以将过期的序号值设置为-1:可以将初始化的序号值设置为0,可以将提交到集群的序号值设置为1,可以将被消费的序号值设置为2,可以将驱动回应的序号值设置为3,可以将已应答给客户端的序号值设置为4。这样,状态设计为>0的状态,也即本地对象的当前状态从初始化、提交到集群、被消费、驱动回应到已应答给客户端顺次单步变化,每次+1;状态一旦到<0之后就不能变化,只能由回收机制回收。其中,初始化是指生产者提交到Server一个新的事件,都会从这个状态开始;提交到集群是指事件提交集群成功,并相应的在集群上持久化;被消费是指事件被某个Server消费;驱动回应是指消费者对于该事件有应答;已应答给客户端是指客户端已获得响应;生命周期终止是指事件生命周期正常结束;过期是指事件异常结束,等待被回收。
可以看出,由于利用了本地对象的状态变化来触发关联的集群对象的状态变化,以及根据分布式服务器集群的变化信息将变化信息更新到本地对象并触发本地回调,所以保证了本地事件状态和集群事件状态的强一致性,同时实现了本地回调。
在具体实施过程中,在节点崩溃失效时,整个分布式服务系统可以执行以下步骤,以保证生产者的消息被持久化到ZooKeeper:
1、重新连接成功时,生产者选择重发或者废弃该条消息;
2、如果生产者选择废弃该条消息,使用新的消息ID重发,那么就是正常流程;
3、如果选择重发,则集群需要依据重发消息ID判断消息目前状态:
如果ID=0,表明消息处于初始化状态,选择重新提交;
ID<0,-2:表明Server回应给生产者之后才会结束消息的生命周期,出现此问题一定是因为网络问题导致消息传输给生产者丢失,等待回收即可;
ID<0,-1:表明消息过期,错误回传给页面,同时等待回收;
ID>0,表明消息处在某个中间状态时候生产者fail,在此情况下,立即执行回调,将状态延续。
在本说明书实施例中,通过重发消息ID来标明重发消息的状态,在其他实施例中,本领域所属的技术人员也可以通过其他方式来标明重发消息的状态,在此不做限制。
在节点崩溃失效时,整个分布式服务系统可以执行以下步骤,以保证消费者的消息被持久化到ZooKeeper:
1、消费者并未收到响应,则消费者选择新的节点进行发送;其中,若节点已经将响应消息提交到ZooKeeper,则由于Session节点为全节点监听,所以具有该条响应消息的本地回调会应答给生产者,如果没有本地回调,则等待消息过期;若尚未将消息提交到ZooKeeper,则重新提交;
2、消费者收到应答,则不重复发送,因为收到应答表示节点保证已经写入ZooKeeper成功。
可以看出,节点崩溃失效会导致生产者或消费者重新连接到另一个节点,由于消息变化是全节点监听,因此连接成功到任意一个节点,都会保证能处理消息变化,并且上次提交的消息已经被持久化到ZooKeeper,从而进一步保证了本地事件状态和集群事件状态的强一致性。
第二方面,基于同一发明构思,本说明书实施例提供一种分布式服务器集群的状态驱动装置,请参考图4,图4为本说明书实施例提供的分布式服务器集群的状态驱动装置的模块图,如图4所示,包括:
执行单元401,用于基于分布式服务器集群的一节点中本地对象的当前状态执行处理逻辑;
触发单元402,用于在所述处理逻辑被执行完成后,触发与所述本地对象关联的集群对象的状态变化;
同步单元403,用于获取所述分布式服务器集群的变化信息,并将所述变化信息同步到所述节点的本地对象;
回调单元404,用于利用所述本地对象的状态变化触发所述节点的本地回调,以更新所述节点的状态。
在一种可选的方式中,所述集群对象为所述本地对象的反序列化对象。
在一种可选的方式中,所述装置还包括回收单元405,所述回收单元405用于在所述装置确定所述本地对象的状态终止时,回收所述本地对象,并触发所述分布式服务器集群回收所述集群对象。
在一种可选的方式中,所述当前状态为生命周期终止、过期、初始化、提交到集群、被消费、驱动回应或已应答给客户端。
在一种可选的方式中,所述当前状态在从初始化、提交到集群、被消费、驱动回应到已应答给客户端之间顺次单步变化;
所述当前状态在为生命周期终止或过期中的任一个状态时,所述装置确定所述本地对象的状态终止。
在一种可选的方式中,所述装置还包括处理单元406,所述处理单元406用于在所述节点接收到生产者的重发消息时,根据所述重发消息的状态,并且基于确定后所述重发消息的状态,进行相应的处理。
第三方面,基于与前述实施例中分布式服务器集群的状态驱动方法同样的发明构思,本说明书实施例还提供一种服务器,请参考图5,图5为本说明书实施例提供的服务器的结构示意图,如图5所示,包括存储器604、处理器602及存储在存储器604上并可在处理器602上运行的计算机程序,处理器602执行程序时实现前文分布式服务器集群的状态驱动方法的任一方法的步骤。
其中,在图5中,总线架构(用总线600来代表),总线600可以包括任意数量的互联的总线和桥,总线600将包括由处理器602代表的一个或多个处理器和存储器604代表的存储器的各种电路链接在一起。总线600还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口606在总线600和接收器601和发送器603之间提供接口。接收器601和发送器603可以是同一个元件,即收发机,提供用于在传输介质上与各种其他装置通信的单元。处理器602负责管理总线600和通常的处理,而存储器604可以被用于存储处理器602在执行操作时所使用的数据。
第四方面,基于与前述实施例中分布式服务器集群的状态驱动方法同样的发明构思,本说明书实施例还提供一种分布式服务器集群,该分布式服务器集群包括多个如第三方面所述的服务器。
第五方面,基于与前述实施例中分布式服务器集群的状态驱动方法同样的发明构思,本说明书实施例还提供一种分布式系统,该分布式系统包括客户端、控制台和第四方面所述的分布式服务器集群。
第六方面,基于与前述实施例中分布式服务器集群的状态驱动方法同样的发明构思,本说明书实施例还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现前文分布式服务器集群的状态驱动方法的任一方法的步骤。
本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的设备。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令设备的制造品,该指令设备实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。