一种共识方法及装置
技术领域
本申请涉及计算机技术领域,尤其涉及一种共识方法及装置。
背景技术
目前,区块链技术得到了广泛应用,其去中心化的模式保证了数据不易被篡改,从而提升了安全性。
在实际应用中,包含多个节点(节点可认为是区块链中参与处理业务的设备)的区块链能够为客户端提供相应的业务服务。具体而言,区块链中的各节点将针对客户端的业务请求进行处理,并向客户端反馈处理结果,在此过程中,独立运行的各节点所生成的处理结果有可能不一致,为了保证客户端能够接收到正确的处理结果,故采用基于拜占庭容错算法(Practical Byzantine Fault Tolerance,PBFT)实现各节点之间的共识(即,使得各节点能够共同认可正确的处理结果)。
在运用PBFT的过程中,共识通常在视图(View)下进行,具体而言,在一个视图下,区块链中的某一个节点作为主节点(primary),其余的节点作为备份节点(backup)。此时,由主节点接收客户端的业务请求,将该业务请求广播给所有备份节点,并由主节点发起共识。达成共识的节点将针对该业务请求进行处理,并向客户端反馈处理结果。
现有技术中,备份节点会发起视图切换,由备份节点所发起的视图切换通常需要得到视图中的其他节点的认可。具体而言,备份节点向该视图下的其他节点(包括主节点)发起视图切换请求,即,向其他节点发起基于视图切换请求的共识(此次共识仍采用PBFT,与基于业务请求的共识过程不同的是,在针对视图切换请求的共识过程中,各节点将暂停对业务请求的共识,故,基于视图切换请求的共识,实质上是一次额外的共识过程)。在一定数量的节点达成共识后,将确定某个备份节点成为新的主节点。新的主节点向外广播新视图消息,完成视图切换。
然而,上述的机制中,由备份节点发起的视图切换需要额外进行一次共识过程,额外的共识过程会增加系统运算量,而且,视图切换的共识过程需要等待一定数量的节点确认后才能达成一致,最终由新的主节点对外广播新视图消息,整个过程将会耗费一定的时间。显然,现有的视图切换方式不仅会增加系统的运算量,同时也增加对业务请求的处理耗时,导致处理效率较低。
发明内容
本申请实施例提供一种共识方法及装置,用以解决目前的视图切换方式增加区块链的运算量并增加了处理耗时的问题。
本申请实施例提供的一种共识方法,所述方法包括:
区块链主节点监测对视图切换条件的触发;
当监测到触发视图切换条件时,所述区块链主节点选定继任节点;
所述区块链主节点根据所述继任节点,将当前视图切换为以所述继任节点作为区块链主节点的视图,以使得继任的区块链主节点发起共识。
本申请实施例提供的一种共识装置,所述装置包括:
监测模块,监测对视图切换条件的触发;
节点确定模块,当所述监测模块监测到触发视图切换条件时,选定继任节点;
视图切换模块,根据所述继任节点,将当前视图切换为以所述继任节点作为区块链主节点的视图,以使得继任的区块链主节点发起共识。
本申请实施例提供一种共识方法及装置,在任一视图中,区块链主节点会主动监测对视图切换条件的触发,如果触发了视图切换条件,则需要执行视图切换,进而,区块链主节点从其他区块链节点中选定一个继任节点,作为下一视图中的区块链主节点,基于此,区块链主节点进行视图切换,在切换后的视图中,继任节点作为新的区块链主节点以进行业务的处理,同时,仍会按照前述过程执行视图切换。显然,上述的视图切换均是由区块链主节点所发起,这样的方式避免出现区块链备份节点发起视图切换共识的情况,换言之,也就能够避免出现额外共识的现象,从而能够减少区块链中额外的运算量以及处理耗时。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1a为本申请实施例提供的共识过程所基于的架构;
图1b为本申请实施例提供的共识过程;
图2为本申请实施例提供的在任一视图中基于三阶段协议的共识过程的示意图;
图3为本申请实施例提供的一种视图切换的应用实例的执行过程示意图;
图4为本申请实施例提供的共识装置结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
正如前述,区块链内各节点之间采用PBFT进行共识的过程中,一旦区块链主节点失效,则区块链备份节点会发起视图切换。区块链备份节点发起的视图切换需要进行额外的共识,也即,需要得到其他区块链节点的认可,才可完成视图切换。显然,额外的共识过程无疑增加了区块链的运算量,同时也增加了处理耗时。
基于此,本申请实施例中提供一种共识方法,针对任一视图下的区块链主节点,在一次共识结束后,由该区块链主节点发起视图切换,更换区块链主节点,而无需额外的共识过程。为了便于描述,以下将区块链主节点简称为:主节点,将区块链备份节点简称为:备份节点。同时,下文中出现有关“节点”的描述,应理解为区块链网络中参与共识的节点。
需要说明的是,在本申请实施例中,共识方法所采用的架构如图1a所示。从图1a中可见,区块链网络中包含多个节点,多个客户端可与该区块链进行业务交互。其中,所述的区块链网络的应用类型,可以是联盟链和/或私有链,能够向用户提供业务服务。所述的节点,包括但不限于:服务器、计算机、移动终端等具有计算处理功能的设备。所述的客户端,可包括浏览器、应用等,客户端可以运行在诸如终端、服务器、数据库中,这里不作具体限定。
基于图1a中所示的关系架构,本申请实施例提供的一种共识过程,如图1b所示,该过程具体包括以下步骤:
S101:主节点监测对视图切换条件的触发。
在本申请实施例中,所述的视图切换条件,可认为是进行视图切换所满足的条件,诸如:主节点超时未广播业务请求、完成共识等。
作为本申请实施例中的一种可能的方式,可通过在主节点中设置的定时器,实现对视图切换条件触发的监测,如:通过定时器对主节点广播业务请求的行为计时,以监测主节点广播业务请求的行为是否超时。其中,所述的定时器可认为是运行在主节点中的计时功能或服务,当然,这里并不构成对本申请的限定。
S102:当监测到触发视图切换条件时,所述主节点选定继任节点。
如果触发了视图切换条件,则主节点需要执行视图切换。需要说明的是,在任一视图中,有且只有一个主节点,其余节点均为备份节点,所以,视图切换也就是主节点的切换。故在本步骤中,主节点将选定继任节点,作为下一任主节点(本申请实施例中的继任节点,与当前视图中的主节点不是同一节点,也即,主节点不能将自己作为继任节点)。
S103:主节点根据所述继任节点,将当前视图切换为以所述继任节点作为主节点的视图,以使得继任的主节点发起共识。
确定了继任节点后,主节点便会执行视图切换。与现有的备份节点发起视图切换共识的方式不同,由备份节点发起视图切换共识的过程,可看作是针对视图中主节点“弹劾”的过程,而本申请实施例中主节点自行执行视图切换的过程,可看作是主动“禅让”的过程,而由主节点执行视图切换,无需发起共识,显然,也就避免了额外的共识过程。执行了视图切换后,新上任的主节点负责在切换后的视图中发起共识,并可以理解地,新上任的主节点也会执行上述的视图切换过程,这里便不再过多赘述。
通过上述步骤,在任一视图中,主节点会主动监测对视图切换条件的触发,如果触发了视图切换条件,则需要执行视图切换,进而,主节点从其他节点中选定一个继任节点,作为下一视图中的主节点,基于此,主节点进行视图切换,在切换后的视图中,继任节点作为新的主节点以进行业务的处理,同时,仍会按照前述过程执行视图切换。显然,上述的视图切换均是由主节点所发起,这样的方式避免出现备份节点发起视图切换共识的情况,换言之,也就能够避免出现额外共识的现象,从而能够减少区块链中额外的运算量以及处理耗时。
在实际应用中,存在不同的视图切换条件,下面将针对视图切换条件的触发进行详细说明:
第一种场景:
在实际应用中,客户端会向主节点发送业务请求,在正常状态下,当主节点接收到业务请求之后,会向视图中的备份节点广播该业务请求,以便进行基于该业务请求的共识,然而,主节点可能是异常节点,在接收到业务请求后长时间不进行广播,那么,备份节点便会发起切换视图的共识。因此,为了避免备份节点因主节点超时不广播所发起的切换视图共识,主节点将自行进行计时,主动监测自身的超时现象。
换言之,在本场景下,视图切换条件为:主节点超时未广播业务请求,那么,触发视图切换条件,具体包括:所述主节点接收业务请求,并经过设定时长后未发起基于所述业务请求的共识。
其中,在实际操作时,计时可由主节点中具有计时功能的程序或服务所实现,如:前述提及的定时器。具体可从主节点接收到业务请求的时刻开始计时。设定时长,可设置为5s、10s等,具体将根据实际应用的需要进行确定,这里并不构成对本申请的限定。
第二种场景:
与前述场景不同,本场景下,主节点在接收到业务请求后,向当前视图中的各备份节点广播了该业务请求,换言之,主节点在设定时长到达前,已发起了基于业务请求的共识,相应地,视图中的各节点便会进行基于该业务请求的共识,并产生共识结果。
这里需要说明的是,基于现有的视图切换机制,如果共识结果为共识失败,则备份节点将会发起视图切换的共识。显然,共识失败可看作是一种视图切换条件。换言之,在本场景下,主节点会在共识失败时,主动执行视图切换,从而避免由备份节点发起额外的视图切换共识。
此外,基于现有的视图切换机制,如果共识结果为达成共识,则主节点将继续发起基于其他业务请求的共识,但是,该主节点有可能在后续的运行过程中失效,一旦主节点失效,备份节点仍会发起视图切换的共识。故为了避免该情况的出现,在本申请实施例中,达成共识后,主节点仍会执行视图切换。
可见,在本场景中,无论共识结果为达成共识或共识失败,主节点在确定出共识结果后,均会执行视图切换。即,触发视图切换条件,具体包括:所述主节点接收业务请求,发起基于所述业务请求的共识,并确定出共识结果。
也就是说,在本场景中,主节点需要确定出某一次共识已达成或共识失败。下面将详细说明主节点如何确定某一次共识已达成或共识失败:
首先需要说明的是,基于业务请求的共识过程,实质上是基于三阶段协议的共识过程,其中所述的三阶段包括:预准备阶段(pre-prepare)、准备阶段(prepare)、确认阶段(commit),这三个阶段共同组成完整的共识过程。在每个阶段,各节点(既包括主节点,也包括各备份节点)均会向彼此发送共识消息。也就是说,对于视图中的每个节点而言,若要进入不同的阶段,必须得到其他节点的认可,所以,三阶段中的每个阶段,都可以看作是一种共识的过程。通常,当节点均进入确认阶段,便可以认为是共识过程的完成。
具体而言,如图2所示,为某一视图下,各节点基于三阶段协议的共识过程。图2中,客户端(Client)向标号为0的节点(replica 0,也即,主节点)发起业务请求(request),主节点向各备份节点(replica 1、replica 2、replica 3)广播该业务请求,开始进行三阶段共识。各节点达成共识后,对业务请求进行处理,并向客户端反馈处理结果。
基于此:
一、主节点确定共识失败。
在本申请实施例中,共识失败体现为共识过程超时(以下简称为:共识超时,共识超时是指共识耗时超过预设的共识时长,其中,共识耗时可以从主节点发起共识时刻起开始计算)。这是因为:
在一种情况下,主节点为失效节点(节点失效可认为是节点中用以执行共识的数据出错,或节点中的共识逻辑出错),也就是说,主节点向各备份节点所发送的业务请求中可能包含了错误的数据(如:错误的业务请求序号),在BPFT机制的保证下,各备份节点会针对主节点所广播的业务请求进行校验。一旦包含了错误的数据,则正常的备份节点并不会认可,此时,主节点可能会重复发送业务请求的过程,致使共识超时。
或者,在另一种情况下,主节点同样为失效节点,在该情况下,主节点可能会向其他备份节点发送错误的共识阶段的通知消息,即,主节点“错误”的认为已进入某一阶段。此时,各备份节点将对主节点的通知消息进行共识,以便确认主节点的通知消息的真实性。类似地,正常的备份节点仍不会认可该主节点发送的通知消息,此时,主节点可能会重复发送错误的通知消息的过程,致使共识超时。
当然,上述内容,仅是实际应用中可能导致共识超时的两种可能情况,这里并不应作为对本申请的限定。显然,从上述内容可见,一旦共识超时,则共识失败。
因此,在本申请实施例中,主节点可通过监测共识过程的整体耗时的方式,来监测某一次共识是否失败。一旦共识过程超时,主节点就会立即发起视图切换操作,从而就避免了备份节点发起视图切换的额外共识过程。也即,在本申请实施例中,主节点确定共识失败的过程可以为:主节点从向所述视图中的各备份节点发起基于所述业务请求的共识的时刻起,监测共识耗时,当监测到共识耗时超过设定时长时,则确定共识失败。
二、主节点确定达成共识。
基于前述的三阶段协议可知,若某一节点进入了确认阶段,那么,该节点便可以针对业务请求进行处理,并将生成的处理结果反馈给客户端。同时,又由于对于每一节点而言,其要进入某一阶段均需要得到视图中其他节点的认可,所以,如果某一节点进入了确认阶段,也就表明该节点得到了其他节点的认可。基于此,可见,如果主节点自身进入了确认阶段,也就表明共识已经达成,这是因为:在PBFT的机制下,若某一节点进入某一阶段后,就表明该节点的状态得到了视图中绝大多数节点的认可,相应的,也就表明绝大多数节点是正确的节点。
因此,该方式下,主节点确定达成共识的过程可以为:主节点监测自身对应的阶段,当所述主节点监测到自身进入确认阶段,且未超过预设的共识时长时,则确定完成共识。即,主节点在确认自身进行确认阶段的同时,还需保证其进入确认阶段的耗时并未超过设定时长。
作为本申请实施例中的另一种方式,主节点可能不会向其他节点发送通知消息(即,主节点可能是失效节点),但该主节点还能够接收到备份节点所发送的通知消息,此时,如果有设定数量的节点都进入到了确认阶段,那么,也可以认为共识完成。
在实际应用中,当某一节点进入确认阶段后,通常会向视图中的其他节点发送通知消息,其通知消息中可如:<commit,v,n,D(m)>。其中,commit表示该节点已进入确认阶段,v表示视图编号,n表示业务请求的序号,D(m)表示发出通知消息的节点对业务请求的签名。
主节点可统计其接收到的进入确认阶段的通知消息,如果接收到的通知消息的数量大于2f+1,则表示有足够多的节点彼此达成共识。那么,也就表示完成共识。其中,f为PBFT机制下最大可容忍的错误节点的数量。此时,主节点便可以确定完成共识。
所以,主节点确定达成共识的过程还可以为:主节点监测自身接收到的、备份节点进入确认阶段的通知消息,当主节点监测到接收的通知消息的数量超过设定数据,且未超过预设的共识时长,则确定完成共识。
在完成共识后,主节点将发起视图切换,以进行主节点的更换,进入新视图。
下面将说明本申请实施例中视图的切换过程。
在PBFT机制下,每一视图均具有相应的编号,正如前述示例中的v值,其代表了当前视图的编号。相应的,区块链中每个节点也都具有相应的编号,如果在区块链中一共有R个节点,那么,各节点的编号将从0开始取值,直到R-1,具体如:replica0、replica1、……、replicaR-1。具有不同编号的节点与视图编号满足一定的关系,具体地,若以replica p代表编号为p的节点,则该节点的编号与视图编号之间满足:
p=v mod R;
其中,v的取值为:从0至正无穷的整数。
该关系表示:节点编号p由视图编号v与区块链中所包含的节点数量R进行取模运算而得到。
换言之,由于v的取值从0到R-1,从而保证了主节点的身份有序的传递至不同节点。例如:如果当前视图的主节点为replica 0(其对应的视图编号为0),那么,下一个视图(编号为1)中的主节点为replica 1,以此类推,直到遍历完所有节点。
从而可见,在本申请实施例中,进行视图切换的过程包括:所述主节点确定自身的编号,根据该主节点自身的编号,确定编号排列于该主节点编号后一位的节点,根据确定出的所述节点,生成视图切换通知消息,发送给各备份节点,进行视图切换,以使得确定出的所述节点成为下一视图中的主节点。
下面以一具体应用实例进行说明,如图3所示,该实例中包括如下步骤:
S301:编号为v的视图中的主节点p接收客户端发送的业务请求,并计时。
S302:在到达设定时间时,判断是否向该视图中的各备份节点发起基于所述业务请求的共识,若是,则执行步骤S303,否则,则执行步骤S305。
S303:获取共识结果。
S304:判断是否达成共识,执行步骤S305。
S305:将视图v切换至视图v+1,并确定编号为p+1的节点作为视图v+1的主节点。
上述的视图切换均是由主节点所发起,这样的方式避免出现备份节点发起视图切换共识的情况。
以上为本申请实施例提供的共识方法,基于同样的思路,本申请实施例还提供一种共识装置,如图4所示,针对任一视图,所述共识装置包括:
监测模块401,监测对视图切换条件的触发;
节点确定模块402,当所述监测模块监测到触发视图切换条件时,选定继任节点;
视图切换模块403,根据所述继任节点,将当前视图切换为以所述继任节点作为区块链主节点的视图,以使得继任的区块链主节点发起共识。
所述监测模块401,当监测到接收业务请求并经过设定时长后未发起基于所述业务请求的共识时,确定为监测到触发视图切换条件。
所述监测模块401,当监测到接收业务请求,发起基于所述业务请求的共识,并确定出共识结果时,确定为监测到触发视图切换条件。
所述节点确定模块402,确定当前视图的下一视图,确定对应于所述下一视图的继任节点;
所述视图切换模块403,将所述当前视图切换为确定出的所述下一视图,其中,所述继任节点作为切换后的视图中的主节点。
任一视图中的节点,包括联盟链和/或私有链中的节点。
在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray,FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等,目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。