本说明书涉及信息技术领域，尤其涉及一种共识验证的方法、装置及设备。
背景技术：
目前，基于区块链技术开发的各种区块链系统的应用前景较为广阔。广为人知的区块链系统有比特币、以太坊、超级账本等，各种区块链系统的架构不尽相同。
对于超级账本或其他类似于超级账本的架构的区块链系统而言，其大致架构可以如图1所示。在图1所示的区块链系统中，将对业务的共识验证过程分为两个阶段，即第一共识验证阶段和第二共识验证阶段(具体地，在超级账本系统中，所述第一共识验证阶段被称为背书阶段，所述第二共识验证阶段被称为确认阶段)。区块链节点的类型至少可以包括第一节点(图1中的空心节点)和第二节点(图1中的实心节点)，同一区块链节点可以既是第一节点，又是第二节点(在超级账本系统中，所述第一节点被称为背书节点，所述第二节点被称为确认节点)。
继续参见图1，各第一节点接收用户通过客户端发送的业务数据，并根据接收到各业务数据的先后顺序，依次针对每个业务数据执行第一共识验证。通过第一共识验证的各业务数据会被依次添加到待确认业务队列的队尾(对于业务数据txn而言，n越小，表明该业务数据被各第一节点接收到的时间越早)，各区块链节点都存储有所述待确认业务队列，并对所述待确认业务队列进行同步更新。各第二节点可以定期从待确认业务队列中，由前到后依次捞取若干业务数据打包成区块，并对该区块中的业务数据进行第二共识验证，包含的所有业务数据均通过第二共识验证的区块会被各第二节点存入区块链(即共享账本)。需要说明的是，针对所述待确认业务队列中的每个业务数据，若该业务数据已经被捞取，则各区块链节点会将该业务数据从所述待确认业务队列中删除。
上述的第一共识验证是指各第一节点基于共识算法，验证业务数据的合理性。具体地，各第一节点依次针对接收到的每个业务数据，模拟执行该业务数据对应的业务操作，得到模拟业务结果，然后根据模拟业务结果，判断该业务数据是否合理，若是，则确定该业务数据通过第一共识验证，否则，确定该业务数据不通过第一共识验证。上述的第二共识验证主要是基于共识算法，对业务数据的合理性之外的其他方面进行验证，如验证是否涉及重复花销(即一笔资产被花费不止一次)。
基于现有技术，需要一种对用户而言更为便利的共识验证方法。
技术实现要素：
本说明书实施例提供一种共识验证方法、装置及设备，以解决现有的共识验证方法容易给用户造成不便的问题。
为解决上述技术问题，本说明书实施例是这样实现的：
本说明书实施例提供的一种共识验证方法，区块链节点至少包括第一节点和第二节点，其中，第一节点用于执行第一共识验证，第二节点用于执行第二共识验证，所述方法包括：
第一节点接收业务数据，并对所述业务数据进行第一共识验证；
若所述业务数据通过第一共识验证，则将所述业务数据添加到待确认业务队列中，以便各第二节点从所述待确认队列中捞取业务数据生成区块，并对所述区块进行第二共识验证；
若所述业务数据未通过第一共识验证，则判断所述业务数据是否满足预设的可重试条件，若是，则将所述业务数据作为待重试的业务数据进行存储；
当确定触发预设的重试执行条件时，重新对待重试的业务数据进行第一共识验证。
本说明书实施例提供的一种共识验证装置，区块链节点至少包括所述装置和第二节点，其中，所述装置用于执行第一共识验证，第二节点用于执行第二共识验证，所述装置包括：
验证模块，接收业务数据，并对所述业务数据进行第一共识验证；当确定触发预设的重试执行条件时，重新对待重试的业务数据进行第一共识验证；
添加模块，若所述业务数据通过第一共识验证，则将所述业务数据添加到待确认业务队列中，以便各第二节点从所述待确认队列中捞取业务数据生成区块，并对所述区块进行第二共识验证；
判断存储模块，若所述业务数据未通过第一共识验证，则判断所述业务数据是否满足预设的可重试条件，若是，则将所述业务数据作为待重试的业务数据进行存储。
本说明书实施例提供的一种共识验证设备，区块链节点至少包括所述设备和第二节点，其中，所述设备用于执行第一共识验证，第二节点用于执行第二共识验证，所述设备包括一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：
接收业务数据，并对所述业务数据进行第一共识验证；
若所述业务数据通过第一共识验证，则将所述业务数据添加到待确认业务队列中，以便各第二节点从所述待确认队列中捞取业务数据生成区块，并对所述区块进行第二共识验证；
若所述业务数据未通过第一共识验证，则判断所述业务数据是否满足预设的可重试条件，若是，则将所述业务数据作为待重试的业务数据进行存储；
当确定触发预设的重试执行条件时，重新对待重试的业务数据进行第一共识验证。
由以上本说明书实施例提供的技术方案可见，在本说明书实施例中，针对每个业务数据，若该业务数据未通过第一共识验证，则第一节点不会直接将该业务数据视为无效而将其丢弃，而是判断该业务数据是否满足预设的可重试条件，若是，则将所述业务数据作为待重试的业务数据进行存储。第一节点当确定触发预设的重试执行条件时，可以重新对待重试的业务数据进行第一共识验证。如此一来，首次未通过第一共识验证的业务数据如果满足预设的可重试条件，后续就可以重新进入第一共识验证阶段。虽然由于某些原因(如用户的资产余额不足)导致某个业务数据首次未通过第一共识验证，但是随着时间的推移，上述阻碍该业务数据通过第一共识验证的原因可能会消除，此时，倘若第一节点可以重新对该业务数据进行第一共识验证，那么该业务数据就可以通过第一共识验证，而无需用户再次向第一节点发送相同的业务数据，也就不会给用户造成不便。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本说明书实施例提供的现有的区块链系统架构图；
图2是现有的共识验证方法存在的问题示意图；
图3是本说明书实施例提供的共识验证方法流程图；
图4是本说明书实施例提供的技术效果示意图；
图5是本说明书实施例提供的一种共识验证装置示意图；
图6是本说明书实施例提供的一种共识验证设备示意图。
具体实施方式
在现有的共识验证方法中，为了追求区块链节点部署的灵活性，在超级账本或其他类似于超级账本的架构中，将区块链节点的类型区分为第一节点和第二节点(也称背书节点和确认节点)。各第一节点根据接收到各业务数据的先后顺序，依次针对每个业务数据进行第一共识验证，并依次将通过第一共识验证的业务数据添加到待确认业务队列的队尾，而各第二节点通常由前到后依次从待确认队列中捞取若干业务数据进行第二共识验证。正是由于存在上述的顺序性，导致一个业务数据的合理性以其之前通过第一共识验证的业务数据为前提，而不能以其之后通过第一共识验证的业务数据为前提。实践中，对于某个未通过第一共识验证的业务数据而言，该业务数据未通过第一共识验证的原因(如用户的资产余额不足、用户暂时没有业务权限等)可能只是暂时存在的，会随着时间的推移而消除。但是，当该业务数据未通过第一共识验证的原因消除时，用户唯有再次向各第一节点发送相同的业务数据，才能实现相应的业务目的，这给用户带来了不便。
举例来说，如图2所示，将业务数据记为tx，假设用户张三当前的资产余额为5元，但是其想要向用户李四转账10元，张三通过客户端向各第一节点发送tx1，各第一节点对该业务数据进行第一共识验证，即模拟执行张三向李四转账10元，得到的模拟业务结果为张三的资产余额变为-5元，这显然是不合理的。因此，各第一节点会认定tx未通过第一共识验证，拒绝将tx1添加到待确认业务队列，从而使得张三发起的该笔转账交易无法进入第二共识验证阶段，也就无法被记入共享帐本，因而是无效的。
对于在tx1之后进入第一共识验证阶段的tx2(王五向张三转账20元)而言，当tx2通过第一共识验证和第二共识验证，被存入区块链时，张三的资产余额将会达到25元。此时，之前导致tx1未通过第一共识验证的原因已经消除，但是由于张三之前发送给各第一节点的tx1已经被确认无效而被丢弃了，因此张三唯有再次发送tx1给各第一节点，才能实现向李四转账10元的业务目的。
而在本说明书实施例中，未通过第一共识验证的业务数据如果满足预设的可重试条件，就不会直接被视为无效，而是成为待重试的业务数据。当预设的重试执行条件被触发时，各第一节点会重新对待重试的业务数据进行第一共识验证。如此，继续沿用上例，首次未通过第一共识验证的tx1成为待重试的业务数据，当所述重试执行条件被触发时，若tx2已经被确认有效，则tx1就可以通过新一次的第一共识验证，从而使得tx1可以顺利进入待确认业务队列(后续可以进入第二共识验证阶段)。因此，用户无需再次向第一节点发送tx1，也就不会给用户造成不便。
为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书一个或多个实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。通过本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本说明书保护的范围。
以下结合附图，详细说明本说明书各实施例提供的技术方案。
图3是本说明书实施例提供的一种共识验证方法流程图，包括以下步骤：
s300：第一节点接收业务数据。
在本说明书实施例中，所述区块链系统基于“超级账本”或其他类似于“超级账本”的架构。在所述区块链系统中，共识验证的过程分为第一共识验证阶段和第二共识验证阶段。组成所述区块链系统的区块链节点具体可以是具有通信功能和数据处理功能的设备。区块链节点的类型至少包括两种，即第一节点和第二节点，其中，第一节点用于执行第一共识验证，第二节点用于执行第二共识验证，同一个区块链节点可以同时是第一节点和第二节点。
众所周知，共识验证需要多个区块链节点参与，具体地，第一共识验证是由多个第一节点协力完成的。但是为了描述的方便，下文着重描述一个第一节点所执行的步骤，每个第一节点执行的步骤都是相同的。下文中“第一节点进行共识验证”实际上是指“第一节点与其他第一节点一起，进行共识验证”。
实际应用中，用户若想要发起一笔业务，则需要通过客户端向第一节点发送该笔业务的业务数据。例如，用户a若想要发起一笔转账业务(向用户b转账)，则转账方用户a需要通过客户端向各第一节点发送该笔转账业务涉及的收款方地址、转账金额等，作为业务数据。
s302：对所述业务数据进行第一共识验证，若所述业务数据通过第一共识验证，则执行步骤s304，若所述业务数据未通过第一共识验证，则执行步骤s306。
在本说明书实施例中，所述第一节点接收到业务数据后，对所述业务数据进行第一共识验证。其中，有关所述第一共识验证的说明可参见前文，不再赘述。
s304：将所述业务数据添加到待确认业务队列中。
若所述业务数据通过步骤s302所述的第一共识验证，则第一节点会将所述业务数据添加到待确认业务队列中。其中，所述待确认业务队列可以是第一节点预先在自身的内存或其他存储介质中创建的。
s306：判断所述业务数据是否满足预设的可重试条件，若是，则执行步骤s308，否则，执行步骤s310。
若所述业务数据未通过步骤s302所述的第一共识验证，则第一节点会进而判断所述业务数据是否可重试。其中，所述可重试条件可以根据需要预设。
具体地，可以根据所述业务数据未通过所述第一共识验证的原因，判断所述业务数据是否满足预设的可重试条件。也就是说，若所述业务数据未通过第一共识验证的原因可以随着时间的推移而消除，则所述业务数据满足预设的可重试条件。
例如，当所述业务数据是转账业务的业务数据时，若所述业务数据未通过第一共识验证，则第一节点可以当确定转账方的资产余额不足时(即所述业务数据未通过第一共识验证的原因是转账方的资产余额不足)，确定所述业务数据满足预设的可重试条件。需要说明的是，本申请实施例中的资产不限于货币，还可以是矿产、艺术品等其他财物。
再如，第一节点可以当确定业务数据涉及的用户缺少指定业务权限时(即所述业务数据未通过第一共识验证的原因是所述业务数据涉及的用户缺少指定业务权限)，确定所述业务数据满足预设的可重试条件。
s308：将所述业务数据作为待重试的业务数据进行存储。
在本说明书实施例中，第一节点会将未通过第一共识验证且满足预设的可重试条件的业务数据作为待重试的业务数据进行存储。具体地，第一节点可以将待重试的业务数据存入内存或其他存储介质。
s310：确认所述业务数据无效。
在本说明书实施例中，第一节点会将未通过第一共识验证且不满足预设的可重试条件的业务数据直接确认为无效的业务数据。
s312：当确定触发预设的重试执行条件时，重新对待重试的业务数据进行第一共识验证。
在本说明书实施例中，所述重试执行条件可以根据需要预设。具体地，倘若在区块链系统中，已经预先设定了每个区块的最大容量(如10兆)，和/或第二节点生成每个区块的周期(如10秒)，那么，确定触发预设的重试执行条件具体可以是：
若各第二节点从所述待确认队列中捞取的用于生成下一个区块的业务数据的数据总量与所述最大容量的差值落入第一指定数值范围，则确定触发预设的重试执行条件；和/或若当前时刻到当前所在周期的结束时刻的时间间隔落入第二指定数值范围，则确定触发预设的重试执行条件。其中，所述第一指定数值范围和所述第二指定范围可以根据需要指定。
在本说明书实施例中，针对每个待重试的业务数据，若在第一节点重新对该待重试的业务数据进行第一共识验证之前，导致该待重试的业务数据之前未通过所述第一共识验证的原因已经消除，则当第一节点重新对该待重试的业务数据进行第一共识验证时，该待重试的业务数据可以通过第一共识验证。若在第一节点重新对该待重试的业务数据进行第一共识验证之前，导致该待重试的业务数据之前未通过所述第一共识验证的原因仍未消除，则当第一节点重新对该待重试的业务数据进行第一共识验证时，该待重试的业务数据依然无法通过第一共识验证。
在本步骤s312中，第一节点可以重新对待重试的业务数据进行第一共识验证，直至所述待重试的业务数据通过第一共识验证，或直至对所述待重试的业务数据进行第一共识验证的次数达到指定次数。
通过图3所示的共识验证方法，针对每个业务数据，若该业务数据未通过第一共识验证，则第一节点不会直接将该业务数据视为无效，而是判断该业务数据是否满足预设的可重试条件，若是，则将所述业务数据作为待重试的业务数据进行存储。第一节点当确定触发预设的重试执行条件时，可以重新对待重试的业务数据进行第一共识验证。如此一来，首次未通过第一共识验证的业务数据如果满足预设的可重试条件，后续就可以重新进入第一共识验证阶段。虽然由于某些原因(如用户的资产余额不足)导致某个业务数据首次未通过第一共识验证，但是随着时间的推移，上述阻碍该业务数据通过第一共识验证的原因可能会消除，此时，倘若第一节点可以重新对该业务数据进行第一共识验证，那么该业务数据就可以通过第一共识验证，而无需用户再次向第一节点发送相同的业务数据，也就不会给用户造成不便。
图4是本说明书实施例提供的技术效果示意图。如图4所示，张三向各第一节点发送tx1后，各第一节点对tx1进行第一共识验证，由于张三的余额不足，导致tx1未通过第一共识验证。但是，后续王五向各第一节点发送向张三转账20元的tx2，若在各第一节点重新对tx1进行第一共识验证之前，tx2已经通过第一共识验证和第二共识验证，张三的资产余额变为25元，则各第一节点在重新对tx1进行第一共识验证时，tx1可以通过第一共识验证，张三无需再向各第一节点发送一次tx1。
需要说明的是，在图1所示的区块链系统的架构中，针对业务数据a，第一节点在对业务数据a进行第一共识验证时，第一节点模拟执行业务数据a所依据的基础数据不仅可以包括区块链上记录的已经生效的业务数据，还可以进一步包括已经通过第一共识验证，却还未完成第二共识验证的业务数据(是否通过第二共识验证未可知)。在图4所示的例子中，若在各第一节点重新对tx1进行第一共识验证之前，tx2已经通过第一共识验证，却还未完成第二共识验证，则第一节点可以以tx2为依据，预期张三的资产余额将会变为25元，在重新对tx1进行第一共识验证时，确定tx1通过第一共识验证。
此外需要说明的是，在步骤s304中，所述待确认业务队列中的各业务数据通常是有序排列的。具体地，第一节点可以按照特定的顺序(通常是接收到各业务数据的先后顺序)依次对每个业务数据进行第一共识验证，并依次将通过第一共识验证的每个业务数据添加到所述待确认业务队列的队尾。如此，待确认业务队列中的各业务数据排列的先后顺序与第一节点之前对各待确认的业务数据进行第一共识验证的先后顺序是一致的。相应地，各第二节点可以从所述待确认业务队列中由前到后捞取若干业务数据打包成区块，然后针对该区块进行第二共识验证，若该区块中包含的所有业务数据均通过第二共识验证，则各第二节点会将该区块存入区块链。
基于此，在步骤s312之后，即在第一节点重新对待重试的业务数据进行第一共识验证之后，第一节点可以将通过第一共识验证的待重试的业务数据添加到所述待确认业务队列中指定位置之前的位置。其中，所述指定位置可以根据需要指定，其具体可以是所述待确认业务队列中的队首。如此，待重试的业务数据若重新通过第一共识验证，则可以被添加到所述待确认业务队列中较为靠前的位置，从而可以尽快被各第二节点捞取进行第二共识验证。
还需要说明的是，在图4所示的例子中，第一节点在重新对tx1进行第一共识验证时，可以以之前通过第一共识验证的tx2为依据，认定tx1通过第一共识验证。但是，若后续tx2未通过第二共识验证，则tx1就丧失了合理的前提，也不应当被存入区块链。为此，在本说明书实施例中，采用指定规则，使得各第二节点将tx1和tx2打包进同一区块，可以解决此问题。具体地，可以将通过第一共识验证的待重试的业务数据添加到所述待确认业务队列中导致所述待重试的业务数据通过第一共识验证的业务数据的临近位置。例如，可以将重新通过第一共识验证的tx1添加到所述待确认业务队列中，tx2的后一位置，如此可以尽可能使得tx1和tx2被各第二节点打包进同一区块，如此，若tx2未通过第二共识验证，则该区块包含的所有业务数据(tx1也在内)都会被认定无效。
另外，在步骤s308中，第一节点可以将所述业务数据作为待重试的业务数据添加到预先创建的待重试业务队列的队尾。如此，所述待重试业务队列中的各业务数据排列的先后顺序与第一节点对各待重试的业务数据进行第一共识验证的先后顺序也是一致的。如此，在步骤s312中，第一节点可以从所述待重试业务队列中，依次捞取至少一个待重试的业务数据，并重新对捞取的待重试的业务数据进行第一共识验证。
基于图1所示的共识验证方法，本说明书实施例还对应提供了一种共识验证装置，如图5所示，区块链节点至少包括所述装置和第二节点，其中，所述装置用于执行第一共识验证，第二节点用于执行第二共识验证，所述装置包括：
验证模块501，接收业务数据，并对所述业务数据进行第一共识验证；当确定触发预设的重试执行条件时，重新对待重试的业务数据进行第一共识验证；
添加模块502，若所述业务数据通过第一共识验证，则将所述业务数据添加到待确认业务队列中，以便各第二节点从所述待确认队列中捞取业务数据生成区块，并对所述区块进行第二共识验证；
判断存储模块503，若所述业务数据未通过第一共识验证，则判断所述业务数据是否满足预设的可重试条件，若是，则将所述业务数据作为待重试的业务数据进行存储。
所述判断存储模块503，根据所述业务数据未通过所述第一共识验证的原因，判断所述业务数据是否满足预设的可重试条件。
所述业务数据包括：转账业务的业务数据；
所述判断存储模块503，当转账方的资产余额不足时，确定所述业务数据满足预设的可重试条件。
预先设定每个区块的最大容量，和/或第二节点生成每个区块的周期；
所述验证模块501，若各第二节点从所述待确认队列中捞取的用于生成下一个区块的业务数据的数据总量与所述最大容量的差值落入第一指定数值范围，则确定触发预设的重试执行条件；和/或若当前时刻到当前所在周期的结束时刻的时间间隔落入第二指定数值范围，则确定触发预设的重试执行条件。
所述判断存储模块503，将所述业务数据作为待重试的业务数据添加到预先创建的待重试业务队列的队尾；
所述验证模块501，从所述待重试业务队列中，由前到后依次捞取至少一个待重试的业务数据；重新对捞取的待重试的业务数据进行第一共识验证。
所述验证模块501，重新对待重试的业务数据进行第一共识验证，直至所述待重试的业务数据通过第一共识验证；或重新对待重试的业务数据进行第一共识验证，直至对所述待重试的业务数据进行第一共识验证的次数达到指定次数。
所述添加模块502，将所述业务数据添加到待确认业务队列的队尾；各第二节点从所述待确认队列中由前到后依次捞取若干业务数据生成区块；在所述验证模块重新对待重试的业务数据进行第一共识验证之后，将通过第一共识验证的待重试的业务数据添加到所述待确认业务队列中指定位置之前的位置。
基于图1所示的共识验证方法，本说明书实施例还对应提供了一种共识验证设备，如图6所示，区块链节点至少包括所述设备和第二节点，其中，所述设备用于执行第一共识验证，第二节点用于执行第二共识验证，所述设备包括一个或多个处理器及存储器，所述存储器存储有程序，并且被配置成由所述一个或多个处理器执行以下步骤：
接收业务数据，并对所述业务数据进行第一共识验证；
若所述业务数据通过第一共识验证，则将所述业务数据添加到待确认业务队列中，以便各第二节点从所述待确认队列中捞取业务数据生成区块，并对所述区块进行第二共识验证；
若所述业务数据未通过第一共识验证，则判断所述业务数据是否满足预设的可重试条件，若是，则将所述业务数据作为待重试的业务数据进行存储；
当确定触发预设的重试执行条件时，重新对待重试的业务数据进行第一共识验证。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于图6所示的设备而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmablelogicdevice,pld)(例如现场可编程门阵列(fieldprogrammablegatearray，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字符系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardwaredescriptionlanguage，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字符助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字符多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
以上所述仅为本说明书的实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。