一种区块链共识方法及装置
技术领域
本申请涉及信息技术领域,尤其涉及一种区块链共识方法及装置。
背景技术
随着信息技术的发展,区块链技术由于其具有的开放性、不可篡改性、去中心化等优点,成为人们重点关注的技术。由于现有区块链技术的去中心化的特点,使得在该区块链中执行的业务在存储在区块链(即,上链)之前,还需要由该区块链中的各节点对该业务对应的业务数据(如,对业务进行处理后的结果)进行共识。
而由于通常区块链中的区块容量有限(如,事先约定的容量),但是节点中等待进行共识的业务数据所占用的空间有可能大于该区块容量,所以在现有技术中发起共识的节点还需要从存储的各业务数据中选择出部分业务数据,以对选择的业务数据进行共识。
通常节点根据业务数据中某一属性的数据(例如交易数据)对应的数值(例如交易金额)的多少,选择进行共识的业务数据。
具体的,该区块链中的每个节点,根据该节点存储的各业务数据的指定属性对应的数值(如交易金额),按照数值从大到小的顺序排列,确定一个由各业务数据组成的待共识列表。区块链中的各节点可以按照该节点内存储的该待共识列表中各业务数据的排列顺序,选择业务数据作为需要进行共识的业务数据,以完成对选择的各业务数据的共识。
但是,上述方法存在以下缺陷:由于该待共识列表中各待共识业务的排列顺序是以业务数据中指定属性对应的数值的多少确定的,那么对于数值较小的业务数据,等待共识的时间较长,导致其处理效率比较低。
发明内容
本申请实施例提供一种区块链共识方法,用于解决现有的区块链共识方法中有些业务数据等待共识的时间较长,导致其处理效率比较低的问题。
本申请实施例提供一种区块链共识装置,用于解决现有的区块链共识方法有些业务数据等待共识的时间较长,导致其处理效率比较低的问题。
本申请实施例提供了一种区块链共识方法,包括:
区块链中的节点接收业务数据,确定所述业务数据的受理时间;
所述节点存储携带所述受理时间的所述业务数据;
当需要对业务数据进行共识时,所述节点根据所述受理时间,选择待共识的业务数据,并对选择的所述待共识的业务数据进行共识。
本申请实施例提供了一种区块链共识装置,包括:
确定模块,接收业务数据,确定所述业务数据的受理时间;
存储模块,存储携带所述受理时间的所述业务数据;
选择模块,当需要对业务数据进行共识时,根据所述受理时间,选择待共识的业务数据;
共识模块,对选择的所述待共识的业务数据进行共识。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果:
首先,区块链中的节点在接收到业务数据时,确定该业务数据的受理时间,之后存储携带了该受理时间的所述业务数据,以便当需要对业务数据进行共识时,可根据该受理时间,选择进行共识的业务数据,并对选择的业务数据进行共识。可见通过本申请提供的方法,选择待共识的业务数据不再依赖于业务数据中某项属性对应的数值的大小,而是依据受理该业务数据的节点在受理该业务数据时的受理时间选择待共识的业务数据,这样有效保证各业务数据等待共识的时间相对均衡,避免了现有技术中有些业务数据等待共识的时间较长的问题,有效提升了业务数据的处理效率,提高了区块链的运行性能。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1为本申请实施例提供的一种区块链共识过程;
图2为本申请实施例提供的一种区块链共识装置的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
在现有区块链技术中,区块链中的数据是由该区块链网络中的各区块链节点(以后简称节点)共同维护的。节点在接收到业务请求时,一般需要经过缓存、共识和存储这三个环节方可将业务请求对应的业务数据存储至区块中,并将该区块上链至节点对应的区块链上。当该区块链网络中的多数节点存储该业务数据在各自节点的区块链数据中时,该业务数据才可视为是被存储在了各节点共同维护的区块链数据中。
共识作为必不可少的环节,目前采用的共识机制有工作量证明(POW)机制、拜占庭容错(PBFT)机制、权益机制证明等多种。这里以工作量证明机制为例进行说明。
具体的,首先,节点可接收用户发送的业务请求,该业务请求中包含业务数据,其中,该业务请求可以是用户直接输入该节点的,也可接收区块链网络中其他节点广播的业务请求。具体该节点如何接收该业务请求对业务的执行并不造成影响。
之后,该节点可根据该业务请求确定对应的业务数据。其中,该节点根据该业务请求确定对应的业务数据的过程可称为节点受理业务请求,至于如何确定该业务数据可能随着具体情况的不同而不同。如常见的业务请求中携带的业务数据已经包含了业务需要执行的内容。例如,对于交易业务请求,该交易业务请求中携带有支付方地址,支付方余额,支付金额,收款方地址等信息,则接收该业务请求的节点可直接根据该业务请求确定该业务数据。又如,由于通常业务请求中还可包含针对智能合约的指令等业务数据。这样,该节点在受理该业务请求时,根据业务请求中的业务数据的不同可能还需要根据业务数据进行业务处理,并得到业务处理的结果,则节点在确定业务数据时,也可将该业务处理的结果作为该业务数据。当然,该节点也可将该业务请求中携带的业务数据以及进行业务处理的结果一并作为该业务请求对应的业务数据。具体的该业务数据的内容可根据区块链的配置而不同,只要是与该业务请求对应的,需要存储在该区块链数据中的数据即可视为是业务数据。
需要说明的是,区块链网络中的节点针对一个业务请求可以分为受理节点和非受理节点,这里的受理节点是指接收用户或者其他设备发送该业务请求的节点,非受理节点是指通过广播方式从其他节点获取该业务请求的节点。
当确定的该业务数据没有被存储在已经经过共识的区块链数据中时,该业务数据为待共识的业务数据,并可以被存储在该节点的缓存中。
然后,在该节点确定该待共识的业务数据之后,该节点可将该待共识的业务数据向该区块链网络中的其他节点进行广播,也就是同步至该区块链网络中的其他节点中。这样,该区块链网络中的各节点可以接收通过广播的方式发送的该待共识的业务数据。在后续进行共识时,该区块链网络中的各节点可以对该待共识的业务数据进行共识。
最后,该区块链网络中的各节点可以根据该区块链的共识机制,确定发起共识的节点,并由该发起共识的节点从该节点存储的各待共识的业务数据中,选择用于共识的业务数据。进而由该区块链网络中的各节点可根据该区块链的共识机制,对该发起共识的节点选择的用于共识的业务数据进行共识。
其中,该区块链网络中的每个节点在对该发起共识的节点发送的各待共识的业务数据进行共识时,可判断接收到的各待共识的业务数据,是否也均存储在在该节点缓存中的待共识列表中,若是,则确定接收到的各待共识业务共识通过,并将记录各待共识的业务数据的新区块存储在该节点维护的区块链数据中,若否,则不存储。
以下结合附图,详细说明本申请各实施例提供的技术方案。
图1为本申请实施例提供的一种区块链共识的过程,具体可包括以下步骤:
S101:区块链中的节点接收业务数据,确定所述业务数据的受理时间。
在区块链网络中,通常存在两种类型的节点,一种节点是业务节点,通常业务节点用于发起业务请求,并且不是必要存在的节点。在该业务节点中可不存储完整的区块链数据,视区块链网络的构建情况决定。有些区块链网络中也可能不存在业务节点这种类型的节点。另一种节点是共识节点,通常共识节点为区块链网络中的必要节点,用于接收业务请求,并根据该区块链的共识机制,发起共识或者接收其他共识节点发送的共识提议。经过共识的业务数据将被存储在区块链的区块中。本申请实施例中所记载的节点可以视为是区块链网络中的共识节点,该节点可以接收业务请求,并根据该业务请求确定接收到的业务数据。
具体的,该节点可以是终端,如,手机、个人电脑/平板电脑等设备,或者该节点也可以是服务器,该服务器可以是单独的一台设备,也可以是有多台设备组成的系统,只要该设备作为该区块链网络的节点可接收业务请求,可发起共识即可,本申请对此并不做具体限定。
另外,在现有技术中,通常区块链中的业务请求包含但不限于如表1所示的业务数据。
表1
当然,表1所示了业务请求中业务数据可能包含的业务属性以及对应的内容,也就是说业务数据中还包含其他内容,这里不做具体限定。其中,以版本属性为例说明,该版本属性对应的内容既可以是在业务请求中携带的(也就是发送该业务请求的客户端或者节点写入的),也可以是后续对该业务请求进行业务处理过程中由该节点确定,并加入该业务数据对应的该版本属性中的。又如,业务对应的区块标识所对应的内容,可以是由该节点在确定可将该业务请求对应的业务数据存储在该区块链的新区块中时,确定该新区块的哈希值,而在该节点接收到该业务请求时,该项属性的内容可以是空的,具体内容可等待该节点写入。
另外,该业务标识,可以是该业务内容的摘要,也可以是该业务发起方确定的在该区块链中全局唯一的标识,也可以是该节点在受理该业务请求时确定的该业务数据的标识。具体的,该业务标识如何确定可采用与现有技术相同的方法,本申请对此并不做限定,只要可以在该区块链数据中唯一的确定该业务数据即可。
进一步地,在本申请实施例中,当该节点接收了该业务请求之后,便可根据该业务请求,确定该业务请求对应的业务数据(即,受理该业务请求),以便在后续在对选择进行共识的待共识的业务数据时,可确定是否将该业务数据作为待共识的业务数据存储在该区块链数据的新区块中(即,是否上链)。
更进一步地,为了使该业务数据在后续进行共识时,避免由于该业务数据中的某些属性的资源量的多少,而影响发起共识的节点选择该业务数据进行共识。在本申请实施例中,该节点在受理该业务请求(如,确定该与该业务请求对应的待共识的业务数据)时,可确定该节点本地的时间戳,并作为该待共识的业务数据的受理时间。
由于对于一个业务请求来说,受理该业务请求的节点通常仅存在一个,所以该节点在受理该业务请求确定对应的待共识的业务数据的受理时间在该区块链数据中也是唯一的,并且,该受理时间不会因该业务请求对应的该业务数据内容的不同而不同。另外,由于该受理时间是受理该业务请求的节点在受理时确定的,所以也使得通过广播方式接收到该待共识的业务数据的其他节点,不会因为接收该待共识的业务数据的时间的不同而在共识时确定不同的选择结果,使得该待共识的业务数据的受理时间戳受的影响(如,业务内容,网络延时)较少。
当然,在本申请实施例中,该节点也可以将该节点接收该业务请求时,该节点本地时间对应的时间戳,作为该业务请求对应的业务数据的受理时间。或者,该节点也可以以其他方式确定该业务数据的时间戳(例如:在接收到所述业务数据时,对所述业务数据进行处理,得到处理结果,将所述处理结果的生成时间确定为所述业务数据的受理时间),只要该业务数据的时间戳为接收该业务请求的节点确定的即可,也就是说,在该区块链数据中该业务数据的时间戳,可只由一个节点来确定。
另外,正如前述的,对于不同的区块链或者不同的业务请求来说,由于该业务请求对应的业务数据中可能还携带有针对智能合约的操作指令等数据,所以该节点有可能还需要根据该业务数据进行业务处理,并且得到业务处理结果,则该业务受理时间还可以是,该节点根据该业务请求(或者,该业务请求中的业务数据)进行业务处理之后得到业务处理结果时,该节点本地时间戳。
进一步地,若该节点确定的该受理时间的精度较低,如,秒级的时间精度,则当该节点在1秒内受理了多个业务请求时,则在这1秒内受理的该多个业务请求分别对应的各业务数据的受理时间相同,则可能导致后续选择待共识的业务数据时出现难以选择的问题,所以为了减少出现多个业务数据的受理时间相同的概率,在本申请实施例中,该受理时间的精度可以设置的较高例如,以毫秒精度确定该受理时间,具体可根据实际应用的需要由工作人员设置,如,在该区块链网络中的各节点平均每分钟接收一个业务请求,那么该受理时间的时间精度就可以设置的较低。
S102:所述节点存储携带所述受理时间的所述业务数据。
在本申请实施例中,当该节点确定该业务数据的受理时间之后,便可将携带有该受理时间的业务数据进行存储,例如:将携带有该受理时间的业务数据存储在该节点本地缓存中,以便后续需要进行共识时,可对该业务数据进行共识。
具体的,该节点可将在步骤S101中确定的该业务数据的受理时间加入该业务数据中,若该业务数据的各属性中已经有时间戳属性,并且该时间戳属性的内容为空时,则将确定的该业务数据的受理时间写入该时间戳属性中。当然若该业务数据原有的时间戳属性中已经写入数据,或者该业务数据中没有时间戳属性,则该节点可以为该业务数据添加新的“受理时间”属性,并将在步骤S101中确定的该业务数据的受理时间写入该“受理时间”属性中。
也就是说,在本申请实施例中,该节点在将该受理时间戳携带在该业务数据中时,该节点可以为该业务数据增加受理时间属性,并将该业务数据的受理时间的数值,作为该受理时间属性的内容,以使得该业务数据携带该受理时间。例如,以表1所示的业务数据为例,该节点可将该业务数据更新为表2所示的业务数据。
表2
当然,正如本申请实施例中在步骤S101中所述的,该受理时间也可是以该节点进行业务处理之后,确定业务处理结果的时间,所以该节点在执行本申请中步骤S102之前,还可以根据实际应用的情况,通过该业务请求和/或该业务数据,进行业务处理的操作。由于进行业务处理已经是现有区块链技术中节点处理业务的方法,所以本申请对此不再赘述。
进一步地,该节点还可以将携带有受理时间的业务数据存储在该节点的缓存中,以等待共识。
具体的,该节点在存储携带受理时间的该业务数据时,可以是将该携带受理时间的业务数据存储在该节点缓存中的待共识业务数据池中,或者以列表的形式,存储在该节点的缓存中,具体采用哪种形式进行存储本申请不做限定。
S103:当需要对业务数据进行共识时,所述节点根据所述受理时间,选择待共识的业务数据,并对选择的所述待共识的业务数据进行共识。
在本申请实施例中,一旦确定需要对业务数据进行共识,不管采用什么共识机制,区块链中的各节点统一按照业务数据的受理时间,选择待共识的业务数据,这样能够保证在进行共识时,所使用的业务数据是相同。
需要说明的是,本申请实施例中所记载的受理时间可以理解为时间戳,这个时间戳可以是节点受理业务请求时为该业务请求生成的时间戳,也可以是节点在接收到的业务请求时对业务请求进行处理之后生成的时间戳,这里不做具体限定。
节点可根据存储的各业务数据的受理时间的时间先后顺序,选择进行共识的待共识的业务数据。
具体的,该节点的缓存中可存储有多个业务数据,包括该节点通过接收业务请求确定的业务数据,以及该节点通过广播接收的由该区块链网络中其他节点同步至该节点的业务数据(即,其他节点确定的待共识业务)。其中,由该节点确定的业务数据的受理时间,是该节点确定该业务数据的受理时间,由其他节点确定的业务数据的受理时间,不是该节点确定,而是由受理该业务数据对应的业务请求的其他节点确定的。
由于该节点中存储的各业务数据均携带有对应的受理时间,并且各业务数据的受理时间通常不同,所以在本申请实施例中,首先,该节点可以根据各业务数据的受理时间,按照时间先后顺序,对各业务数据进行排序。
其次,该节点可根据该区块链的共识机制,确定新区块的区块容量,进而根据该区块容量,确定该新区块可记录的业务数据的数量。通常,为了减少区块链数据上记录数据的占用的存储空间,该业务数据在记录至该区块中时,是先计算该业务数据的摘要,并将该业务数据的摘要记录在该区块中,所以该节点在确定业务数据的数量时,可以是根据业务数据的摘要的占用空间大小以及该区块容量,确定可记录的业务数据的数量,当然,具体该节点如何确定可记录的业务数据的数量本申请不做限定,可根据实际应用的需要,通过对共识机制的配置来确定。
再次,该节点可根据确定进行共识的业务数据的数量,按照各业务数据的排序后的先后顺序,选择该数量的业务数据,作为待共识的业务数据。
由于对于该区块链网络中的每个节点,同一个待共识的业务数据的时间戳是相同的,所以在该区块链网络中不同节点若在同一时间确定的待共识的业务数据的排列顺序也是相同的,从而使得该区块链网络中的不同节点若在同一时间发起共识,不同节点选择的待共识的业务数据相同的几率也较高。
例如,假设对于区块链网络中的节点A,该节点A缓存中存储的各业务数据如表3所示。
业务数据的标识 |
受理时间的时间戳 |
业务1 |
100 |
业务2 |
99 |
业务3 |
102 |
业务4 |
70 |
表3
其中,该业务1以及该业务3为该节点A通过受理业务请求确定的业务数据,该业务2为节点B发送至该节点A的业务数据,该业务4位节点C发送至该节点A的业务数据。
则该节点A可根据各业务数据的受理时间,按照时间先后顺序,对各业务数据进行排序,并可确定如表4所示的列表排序。
业务数据的标识 |
受理时间的时间戳 |
业务4 |
70 |
业务2 |
99 |
业务1 |
100 |
业务3 |
102 |
表4
之后,该节点A便可根据共识机制确定需要进行共识的业务数量,假设该数量为2,则该节点A可将选择该业务4以及该业务2作为待共识的业务数据。
当然,该节点也可以不对存储的各业务数据按照受理时间的时间先后顺序进行排序,而是通过遍历各业务数据的受理时间,之后按照受理时间的时间先后顺序选择进行共识的业务数据。具体的,该节点如何根据各业务数据的受理时间,按照时间先后顺序,选择进行共识的业务数据,本申请并不限定。只要该节点选择的各待共识的业务数据是按照各业务数据的受理时间的时间先后顺序选择的即可,也就是说,达到先受理的业务数据先进行共识的结果即可。
通过如图1所示的区块链共识过程,该区块链网络中的节点,在接收到接收业务数据时,通过确定该业务数据的受理,并存储携带该受理时间的该业务数据,当需要对业务数据进行共识时,可以根据各业务数据的受理时间,确定各业务数据的受理时间的先后顺序,并以先受理先共识的原则,按顺序选择满足待存储的区块的区块容量的待共识的业务数据进行共识。使得即使是由其他节点发送来的业务数据,由于该业务数据的受理时间是接收该业务数据的节点受理该业务数据的时间戳,那么该区块链网络中的各节点所记录的该业务数据的受理时间戳是相同的,这样先受理的业务请求在区块链网络中将会被先进行共识,有效保证了业务数据等待共识时间相对均衡,相对现有技术,避免了现有技术中有些业务数据等待共识的时间较长的问题,有效提升了业务数据的处理效率,提高了区块链的运行性能。
另外,在本申请实施例步骤S102中,该节点在存储该业务数据时,便可以根据该业务数据的受理时间,按照时间先后顺序将该业务数据存储在缓存中,则该节点的缓存中可配置有业务数据列表,该列表中的业务数据均是按照受理时间的先后顺序排序的。则在步骤S103中,当需要进行业务数据共识时,仅需确定进行共识的业务数量,并从该业务数据列表中按顺序选择该业务数量的业务数据,作为该待共识的业务数据即可。
进一步地,在本申请实施例中,该节点在接收到该区块链网络中的其他节点广播的业务数据时,可以先判断该节点存储的各业务数据中是否已经存在相同的业务数据,若是,则不将该业务数据存储在该节点中(即,避免存储两个相同的待共识业务),若否,则将该业务数据存储在该节点的本地缓存中。
更进一步地,若该节点中存在按照时间先后顺序排序的业务数据列表,则该节点在确定存储该业务数据时,可根据该业务数据的受理时间,按照时间先后顺序,将接收的该业务数据加入该节点的业务数据列表中。
例如,假设如表4所述的业务数据列表,为节点A存储的业务数据。当该节点A接收到该节点B发送的业务数据为:业务5,并且该业务5的受理时间为10时,该节点A可按受理时间的时间先后顺序将该业务5插入该业务数据列表中,如表5所示。
业务数据的标识 |
受理时间的时间戳 |
业务5 |
10 |
业务4 |
70 |
业务2 |
99 |
业务1 |
100 |
业务3 |
102 |
表5
需要说明的是,本申请实施例所提供方法的各步骤的执行主体均可以是同一设备,或者,该方法也由不同设备作为执行主体。比如,步骤S101和步骤S102的执行主体可以为设备1,步骤S103的执行主体可以为设备2;又比如,步骤S101的执行主体可以为设备1,步骤S102和步骤S103的执行主体可以为设备2;等等。
基于图1所示的区块链共识方法,本申请实施例还对应提供一种区块链共识装置的结构示意图,如图2所示。
图2为本申请实施例提供的一种区块链共识装置的结构示意图,包括:
确定模块201,接收业务数据,确定所述业务数据的受理时间;
存储模块202,存储携带所述受理时间的所述业务数据;
选择模块203,当需要对业务数据进行共识时,根据所述受理时间,选择待共识的业务数据;
共识模块204,对选择的所述待共识的业务数据进行共识。
在本申请的另一个实施例中,所述确定模块201确定所述业务数据的受理时间,具体包括:
确定接收到所述业务数据的时间,将所述时间确定为所述业务数据的受理时间;或者
在接收到所述业务数据时,对所述业务数据进行处理,得到处理结果,将所述处理结果的生成时间确定为所述业务数据的受理时间。
在本申请的另一个实施例中,所述装置还包括:广播模块205,其中:
所述广播模块205,在确定所述业务数据的受理时间后,将携带所述受理时间的所述业务数据广播至所述区块链中的其他节点。
在本申请的另一个实施例中,所述确定模块201接收业务数据,确定所述业务数据的受理时间,包括:
通过广播的方式接收所述区块链中其他节点发送的业务数据;
将所述业务数据中包含的受理时间确定为所述业务数据的受理时间。
在本申请的另一个实施例中,所述选择模块203根据所述受理时间,选择待共识的业务数据,具体包括:
按照所述受理时间的时间先后顺序,选择出满足待存储的区块的区块容量的待共识业务数据。
具体的,如图2所示的一种区块链共识装置可以位于服务器中,该服务器可以单独的一台设备,或者由多台设备组成的系统。或者,该共识装置也可位于终端中,如,手机,平板电脑,个人电脑等设备。
在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、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。