应用在区块链上的海量规则数据处理方法和系统与流程

本公开涉及区块链领域，尤其涉及一种应用在区块链上的海量规则数据处理方法和系统。

背景技术

在区块链应用中，参与到区块链上的用户隶属于不同的角色，有不同的操作权限，用户不允许访问未经授权的数据。例如，每个用户都有一个默认角色，默认角色的权限可以由区块链应用系统自定义，但是用户同时还可以定义自己的角色。若用户拥有特殊角色，则使用特殊角色，否则使用默认角色。定义角色、给角色增加资源、给用户授予角色，判断用户是否可以访问指定资源，这些都可以以api(applicationprogramminginterface，应用程序编程接口)的方式暴露给区块链的应用层，区块链底层接受到api请求，提供存储数据和查询数据的功能。对于区块链节点或者架构于区块链之上的web网关层而言，降低单节点的存储空间，提升节点查询效率，是区块链性能优化的一个重要环节。

技术实现要素：

本公开要解决的一个技术问题是提供一种应用在区块链上的海量规则数据处理方法和系统，能够降低数据存储空间。

根据本公开一方面，提出一种应用在区块链上的海量规则数据处理方法，包括：获取持久化存储数据库中的规则数据，其中，规则数据包括第一规则数据和第二规则数据；根据规则数据的数量以及键key-值value数据库中每个业务key可以承载的映射数量确定业务key的数量；根据商家标识id的哈希值与业务号构建业务key；遍历第二规则数据，将每条第二规则数据存储至相应的业务key对应的value中，并在每个业务key对应的value中存储相同的第一规则数据。

可选地，该方法还包括：对每条第一规则数据和每条第二规则数据建立对应的规则key。

可选地，该方法还包括：接收业务系统发送的商家规则数据查询请求；根据商家id确定业务key；基于业务key查询key-value数据库；若根据业务key能够在key-value数据库中查询到规则数据，则返回查询结果。

可选地，若根据业务key能够在key-value数据库中查询到规则数据，则返回查询结果包括：根据业务key判断key-value数据库中是否存储有第二规则数据；若有第二规则数据，则返回第二规则数据，否则，判断key-value数据库中是否有第一规则数据；若有第一规则数据，则返回第一规则数据。

可选地，该方法还包括：若根据业务key不能够在key-value数据库中查询到规则数据，则根据规则key查询key-value数据库；若根据规则key能够在key-value数据库中查询到规则数据，则返回查询结果，否则，在持久化存储数据库中查询规则数据，并返回查询结果。

可选地，将业务key存储在区块链中。

可选地，key-value数据库为redis数据库。

根据本公开的另一个实施例，还提出一种应用在区块链上的海量规则数据处理系统，包括：规则数据获取单元，用于获取持久化存储数据库中的规则数据，其中，规则数据包括第一规则数据和第二规则数据；业务key数量确定单元，用于根据规则数据的数量以及键key-值value数据库中每个业务key可以承载的映射数量确定业务key的数量；业务key构建单元，用于根据商家标识id的哈希值与业务号构建业务key；映射建立单元，用于遍历第二规则数据，将每条第二规则数据存储至相应的业务key对应的value中，并在每个业务key对应的value中存储相同的第一规则数据。

可选地，该系统还包括：规则key建立单元，用于对每条第一规则数据和每条第二规则数据建立对应的规则key。

可选地，该系统还包括：数据查询请求接收单元，用于接收业务系统发送的商家规则数据查询请求；规则数据查询单元，用于根据商家id确定的业务key查询key-value数据库，若根据业务key能够在key-value数据库中查询到规则数据，则返回查询结果。

可选地，规则数据查询单元还用于根据业务key判断key-value数据库中是否存储有第二规则数据；若有第二规则数据，则返回第二规则数据，否则，判断key-value数据库中是否有第一规则数据；若有第一规则数据，则返回第一规则数据。

可选地，规则数据查询单元还用于若根据业务key不能够在key-value数据库中查询到规则数据，则根据规则key查询key-value数据库；若根据规则key能够在key-value数据库中查询到规则数据，则返回查询结果，否则，在持久化存储数据库中查询规则数据，并返回查询结果。

可选地，将业务key存储在区块链中。

可选地，key-value数据库为redis数据库。

根据本公开的另一个实施例，还提出一种应用在区块链上的海量规则数据处理系统，包括：存储器；以及耦接至存储器的处理器，处理器被配置为基于存储在存储器的指令执行如上述的海量规则数据处理方法。

根据本公开的另一个实施例，还提出一种计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现上述的海量规则数据处理方法的步骤。

与现有技术相比，本公开实施例预估业务key的数量后构建业务key，并将第一规则数据存储在每一个业务key对应的value中，将第二规则数据分开存储在不同的业务key中，能够降低数据存储空间。

通过以下参照附图对本公开的示例性实施例的详细描述，本公开的其它特殊及其优点将会变得清楚。

附图说明

构成说明书的一部分的附图描述了本公开的实施例，并且连同说明书一起用于解释本公开的原理。

参照附图，根据下面的详细描述，可以更加清楚地理解本公开，其中：

图1为本公开应用在区块链上的海量规则数据处理方法的一个实施例的流程示意图。

图2为本公开应用在区块链上的海量规则数据处理方法的另一个实施例的流程示意图。

图3为本公开海量规则数据存储格式示意图。

图4为本公开应用在区块链上的海量规则数据处理方法的再一个实施例的流程示意图。

图5为本公开应用在区块链上的海量规则数据处理方法的又一个实施例的流程示意图。

图6为本公开应用在区块链上的海量规则数据处理系统的一个实施例的结构示意图。

图7为本公开应用在区块链上的海量规则数据处理系统的另一个实施例的结构示意图。

图8为本公开应用在区块链上的海量规则数据处理系统的又一个实施例的结构示意图。

图9为本公开应用在区块链上的海量规则数据处理系统的再一个实施例的结构示意图。

图10为本公开应用在区块链上的海量规则数据处理系统的再一个实施例的结构示意图。

具体实施方式

现在将参照附图来详细描述本公开的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本公开的范围。

同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。

在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。

图1为本公开应用在区块链上的海量规则数据处理方法的一个实施例的流程示意图。

在步骤110，获取持久化存储数据库中的规则数据，其中，规则数据包括第一规则数据和第二规则数据。海量规则数据是指业务规则的数据量级巨大，例如数据量大于上万条，可以将海量规则数据存储在持久化存储数据库中。在一个实施例中，第一规则数据为默认规则数据，第二规则数据为特殊规则数据。

在一个实施例中，电商在创建优惠券的时候一般都按批次来创建，创建的时候，支持设置优惠券的承担比例，格式类似于电商承担x％，商家承担y％，其中x+y＝100，此规则档位含义为成本默认规则档位。另外，按批次创建优惠券的时候，还可以设置特殊规则的承担比例，格式仍然是类似于电商承担m％，商家承担n％，其中m+n＝100。其中，特殊规则数据可以有多个。

在另一实施例中，在区块链应用中，参与到区块链上的用户隶属于不同的角色，有不同的操作权限，用户不允许访问未经授权的数据。用户修改、查询、删除业务的时候，会优先去查询给用户授予的角色，其中，每个用户都有一个默认角色，默认角色的权限可以由区块链应用系统自己自定义；但是用户同时还可以定义自己的角色，即特殊角色。在该实施例中，默认角色为默认规则数据，特殊角色为特殊规则数据。

在步骤120，根据规则数据的数量以及key-value(键值)数据库中每个业务key可以承载的映射数量确定业务key的数量。其中，key-value数据库例如为redis数据库。redis数据库中一个key中存储的map(映射)数据是有限的，因此需要预估业务key的大小。例如，业务规则数据有10万条，一个业务key可以承载的最大的map数量为5000，则需要提前准备20个业务key。

在步骤130，根据商家id(标识)的哈希值与业务号构建业务key。例如，业务号例如为批次号，对于各个商家，每个商家有不同的id。以批次创建优惠券的时候，假定批次号batchno为4901238932。例如设置了两档特殊规则数据，如，档位1，电商承担10％，商家承担90％，对应的商家列表范围为【12，13，14，15，16，17】；档位2，电商承担20％，商家承担80％，对应的商家列表范围为【22，23，24】。以商家列表12为例，redis的业务key为batchno_(hash(商家id)％20)，下划线后面的含义为对商家id(如12)先求一个hash，此处目的是为了让redis的分布数据比较均匀，hash函数可以采用murmurhash等算法，hash的结果再对rediskey的个数取模。redis的业务key形式可以为batchno_0,batchno_1,batchno_2,batchno_3…batchno_19等。

在步骤140，遍历第二规则数据，将每条第二规则数据存储至相应的业务key对应的value中，并在每个业务key对应的value中存储相同的第一规则数据。即将默认规则数据存储在每一个业务key对应的value中。而对于特殊规则数据，需要遍历每一个特殊规则数据，建立业务key与对应的特殊规则数据的映射关系，在一个实施例中，某一个业务key对应的value中可能没有存储特殊规则数据。

本领域的技术人员应当理解，在业务key对应的value中存储第一规则数据和第二规则数据的存储顺序没有限制。

在该实施例中，预估业务key的数量后构建业务key，并将第一规则数据存储在每一个业务key对应的value中，将第二规则数据分开存储在不同的业务key中，能够降低数据存储空间。

图2为本公开应用在区块链上的海量规则数据处理方法的另一个实施例的流程示意图。

在步骤210，获取持久化存储数据库中的规则数据，其中，规则数据包括默认规则数据和特殊规则数据。

在步骤220，根据规则数据的数量以及redis数据库中每个业务key可以承载的映射数量确定业务key的数量。

在步骤230，根据商家id的哈希值与业务号构建业务key。

在步骤240，遍历规则数据，建立业务key与对应的特殊规则数据的映射关系。

在步骤250，在每一个业务key对应的value中写入所有默认规则数据。

在步骤260，对每条默认规则数据和每条特殊规则数据建立对应的规则key。其中，规则key即存储内容的key，如图3所示，4901238932_0为业务key，{“jdrate”:”0.4”,”poprate”:”0.6”}为默认规则数据，{“jdrate”:”0.1”,”poprate”:”0.9”}为特殊规则数据。规则key为0对应的value值为默认规则数据，规则key为12对应的value值为特殊规则数据。

在上述实施例中，预估业务key的数量后构建业务key，将默认规则数据存储在每一个业务key对应的value中，将特殊规则数据分开存储在不同的业务key中，能够降低数据存储空间。另外，redis业务key中始终存储有默认规则数据和特殊规则数据，因此，在可以减少数据查询次数的同时，还能防止两部分数据分开存储的时候，若任一数据失效，程序上无法判断数据是真的没有，还是缓存数据丢失，影响业务逻辑的判断的问题。

图4为本公开应用在区块链上的海量规则数据处理方法的再一个实施例的流程示意图。

在步骤410，接收业务系统发送的商家规则数据查询请求。其中，可以通过接口批量查询规则数据。

在步骤420，根据商家id确定业务key。先确定待查询的商家范围列表，然后根据商家范围列表查询业务key。其中，该步骤中计算业务key的方法与数据存储时计算业务key的方法相同。

在步骤430，基于业务key查询key-value数据库。

在步骤440，判断根据业务key是否能够在key-value数据库中查询到规则数据，若是，则执行步骤480，否则，执行步骤450。

若根据业务key能够在key-value数据库中查询到规则数据，则返回查询结果。具体过程中，根据业务key判断key-value数据库中是否存储有特殊规则数据；若有特殊规则数据，则返回特殊规则数据，否则，判断key-value数据库中是否有默认规则数据；若有默认规则数据则返回默认规则数据。如果key-value数据库没有默认规则数据，则可能是缓存失效了或者缓存内容被污染了，或者也可能是key-value数据库真的没有数据。

在步骤450，根据规则key查询key-value数据库。

在步骤460，判断根据规则key是否能够在key-value数据库中查询到规则数据，若是，则执行步骤480，否则，执行步骤470。

在步骤470，在持久化存储数据库中查询规则数据，若查询到数据，则执行步骤480。

在步骤480，返回查询结果。

在该实施例中，先根据业务key在key-value数据库查找规则数据，若查询不到，再根据规则key在key-value数据库查询规则数据，若查询不到，才到持久化存储数据库中查询规则数据。能够提升查询效率，并且能够解决数据量巨大的情况下，操作查询数据库时容易产生热key以及单key保存的数据受限的问题。

图5为本公开应用在区块链上的海量规则数据处理方法的又一个实施例的流程示意图。

在步骤510，获取海量规则数据。即获取海量的默认规则数据和特殊规则数据。

在步骤520，持久化存储海量规则数据。redis中保存的数据分为两种，一种是key对应的内容为规则数据的全内容，作为持久化存储的cache来使用；一种是key对应的为map结构，值为默认规则数据和特殊规则数据的集合。可以先写第一种redis的数据。

在步骤530，发送规则数据的mq。发送mq主要是为了系统解耦、将同步流程异步化来处理，起到消减流量的目的。发送规则数据的mq后，说明新增规则数据成功。

上述步骤510-530即新增规则数据的步骤，其中，接收到新增规则数据的请求后，规则数据经过业务逻辑校验成功后并持久化存储后，系统发送规则数据的mq(messagequeue，消息队列)，表明新增规则数据成功。其中，mq若发送失败，捕获发送的异常，记录到日志系统中，不影响新增数据的流程。

在步骤540，开始消费规则数据的mq。发送mq本身速度很快，消费mq的处理逻辑可能稍微复杂点，消费速度可以稍微慢一点。一般而言，发送mq和消费mq可以是同一个系统，也可以是不同的系统。

在步骤550，预估规则数据大小，计算redis的大小。该实施例中采用redis的map结构来保存规则数据，考虑到redis一个key中存储的map数据是有限的。因此，可以根据业务的量级，提前估算好需要的rediskey的个数。以单key可以承载的最大的map数量为5000举例，若规则数据有10万条，则需要提前准备20个key。

在步骤560，分析计算出默认规则数据。

在步骤570，使用batchno_(hash(商家id)％20)的算法计算业务key。

在步骤580，在map<string,map<string,string>>结构添加特殊规则数据。

在步骤590，在map<string,map<string,string>>结构添加多个默认规则数据。

在步骤5100，读取map<string,map<string,string>>结构，批量写redis。其中，可以为每个默认规则数据和特殊规则数据建立对应的规则key。

在步骤5110，通过接口批量查询规则数据。

在步骤5120，分析计算待查询的范围列表。

在步骤5130，计算待查询的redis的业务key，计算业务key的规则为businessno_(hash(商家id)％20)，其中businessno为业务编号，hash规则和消费处理规则数据的hash规则保持一致；同时还要合并待查询的redis业务key对应的filed值，此方案中field值始终包含了有两部分内容：一是默认规则数据，一是特殊规则数据集合。最终待查询的内容可以表示为map<string,list<string>，其中map的业务key为待查询的redis的业务key，map的vaule值为待查询的redis的field值。

在步骤5140，查询redis。其中，可以使用redis的hmget命令，查询redis的值。

在步骤5150，判断redis是否有数，且数据无误，若是，则执行步骤5210，否则，执行步骤5160。若redis中有数据，需检验数据，发现默认数据存在，即认为数据有效；若默认数据不存在，则认为数据无效。此时查询规则为若查询的结果中有特殊规则档的数据，则查询的结果采用特殊规则档的数据；否则采用默认规则档的数据。

在步骤5160，查询规则数据内容的redis数据。即根据规则key查询redis。

在步骤5170，判断redis是否有数，且数据无误，若是，则执行步骤5180，否则，执行步骤5190。

在步骤5180，若redis有数，且数据不为空，则用内存计算的方式计算出本次的查询结果。

在步骤5190，若redis无数，或者数据为空，需要从持久化存储中查询出规则数据内容，然后执行步骤5180。

在步骤5200，发送redis失效的mq消息。mq若发送失败，捕获发送的异常，记录到日志系统中，不影响查询的流程，mq消费端的逻辑和消费规则数据的流程一样，不再重复表述。

在步骤5210，返回本次查询的结果。

在上述实施例中，对待存储的数据量进行预估，采用redis的map结构，将默认规则数据冗余保存，针对特殊规则数据分开保存数据的策略，理论上可以做到任意规则数据都已经放置到redis中，且保证查询的性能。

下面将以一个具体实施例为例对本公开的应用在区块链上的海量规则数据处理方法进行说明。

以批次创建优惠券的时候，假定批次号batchno为4901238932，设定的当前批次的优惠券承担比例为4比6，默认规则数据为电商承担40％，商家承担60％。另外，还需要附加特殊规则覆盖的商家列表。其中，特殊规则可以有多个档位，档位数量不限制；每一个档位的商家列表的个数，同样不加限制；创建、修改的时候，有一个商家只能出现在一个特殊规则档位的业务限制。

该实施例中设置两档特殊规则数据，例如，档位1，电商承担10％，商家承担90％，对应的商家列表范围为【12，13，14，15，16，17】。档位2，电商承担20％，商家承担80％，对应的商家列表范围为【22，23，24】。

假定此类规则数据可能会积累到10万条，提前准备20个redis的key，key和其value的数据可以用map<string,map<string,string>>来类似表达，其中map结构的key为redis的key，个数为提前准备的数量(如20个)，value为默认规则数据和特殊规则数据的集合。

其中，在计算业务key时，以商家列表12为例，redis的业务key为batchno_(hash(商家id)％20)，下划线后面的含义为对我们的商家id(如12)先求一个hash，此处目的是为了让redis的分布数据比较均匀，hash函数可以采用murmurhash等算法，hash的结果再对rediskey的个数取模。redis的key形式为batchno_0,batchno_1,batchno_2,batchno_3…batchno_19(最多共20个)。

redis的存储内容类似于图3所示，存储内容的规则key为两部分内容，一是通用默认数据(本例中key为0的为默认规则数据)，一是特殊规则数据(本例中key为12的为特殊规则数据)。其中，默认规则数据需要在每一个rediskey都要保存，例如若共有20个业务key，则每个业务key中都需要保存默认规则数据。

在通过接口批量查询规则数据时，先根据待查询的范围列表计算待查询的redis的业务key，其中，计算key的规则为businessno_(hash(商家id)％20)，其中businessno为业务编号，hash规则和消费处理规则数据的hash规则保持一致；同时还要合并待查询的rediskey对应的filed值，此方案中field值始终包含了有两部分内容：一是通用默认数据(本例中为0)，一是范围列表集合。最终待查询的内容可以表示为map<string,list<string>，其中map的key为待查询的redis的业务key，map的vaule值为待查询的redis的field值。

先利用业务key在redis中进行查询，若有查询结果则返回，否则，利用规则key查询redis，若有查询结果则返回，否则，从持久化存储中查询出规则数据内容。

在上述实施例中，业务系统中含有默认规则数据和特殊规则数据，在数据量巨大的情况下，通过精细的设计和计算，提供一种精心设计的数据结构和算法，将默认规则数据保存在rediskey的map数据中，将特殊规则数据按一定的hash规则划分为不同的rediskey去分开处理，分别保存。解决了数据量巨大的情况下，操作查询redis时容易产生热key、redis的单key保存的数据受限的问题。

在本公开的另一个实施例中，在区块链应用中，参与到区块链上的用户隶属于不同的角色，有不同的操作权限，用户不允许访问未经授权的数据。用户修改、查询、删除业务的时候，会优先去查询给用户授予的角色，每个用户都有一个默认角色，默认角色的权限可以由区块链应用系统自己自定义，但是用户同时还可以定义自己的角色，若用户拥有特殊角色，则使用特殊角色，否则使用默认角色。之后判断角色是否拥有此类资源的访问权限，其中，每个角色也可拥有默认资源和特殊资源，若没有给角色设置特殊资源，则使用角色的默认资源。定义角色、给角色增加资源、给用户授予角色，判断用户是否可以访问指定资源，这些都可以以api的方式暴露给区块链的应用层，区块链底层接受到api请求，提供存储数据和查询数据的功能。

该实施例中进行规则数据存储和查询的过程和上一实施例相似，此处不再进一步介绍。在该实施例中，可以将业务key存储在区块链中，由于区块链各节点保存的数据是相同的，但由于各节点保存了业务key，使得查询效率更高。对于区块链节点或者架构于区块链之上的web网关层而言，降低单节点的存储空间，提升节点查询效率，是区块链性能优化的一个重要环节。

图6为本公开应用在区块链上的海量规则数据处理系统的一个实施例的结构示意图。该系统包括规则数据获取单元610、业务key数量确定单元620、业务key构建单元630和映射建立单元640。

规则数据获取单元610用于获取持久化存储数据库中的规则数据，其中，规则数据包括第一规则数据和第二规则数据。在一个实施例中，第一规则数据为默认规则数据，第二规则数据为特殊规则数据。

业务key数量确定单元620用于根据规则数据的数量以及key-value数据库中每个业务key可以承载的映射数量确定业务key的数量。其中，key-value数据库例如为redis数据库。redis数据库中一个key中存储的map(映射)数据是有限的，因此需要预估业务key的大小。例如，业务规则数据有10万条，一个业务key可以承载的最大的map数量为5000，则需要提前准备20个业务key。

业务key构建单元630用于根据商家id的哈希值与业务号构建业务key。其中，业务key可以为batchno_(hash(商家id)％20)。

映射建立单元640用于遍历第二规则数据，将每条第二规则数据存储至相应的业务key对应的value中，并在每个业务key对应的value中存储相同的第一规则数据。即将默认规则数据存储在每一个业务key对应的value中。而对于特殊规则数据，需要遍历每一个特殊规则数据，建立业务key与对应的特殊规则数据的映射关系。

在该实施例中，预估业务key的数量后构建业务key，并将第一规则数据存储在每一个业务key对应的value中，将第二规则数据分开存储在不同的业务key中，能够降低数据存储空间。

在本公开的另一个实施例中，还可以如图7所示，该系统还包括规则key建立单元710用于对每条第一规则数据和每条第二规则数据建立对应的规则key。其中，规则key即存储内容的key，如图3所示，4901238932_0为业务key，{“jdrate”:”0.4”,”poprate”:”0.6”}为默认规则数据，{“jdrate”:”0.1”,”poprate”:”0.9”}为特殊规则数据。规则key为0对应的value值为默认规则数据，规则key为12对应的value值为特殊规则数据。

在本公开的另一个实施例中，还可以如图8所示，该系统还可以包括数据查询请求接收单元810和规则数据查询单元820。

数据查询请求接收单元810用于接收业务系统发送的商家规则数据查询请求。

规则数据查询单元820用于根据商家id确定的业务key查询key-value数据库，若根据业务key能够在key-value数据库中查询到规则数据，则返回查询结果。其中，根据业务key判断key-value数据库中是否存储有特殊规则数据；若有特殊规则数据，则返回特殊规则数据，否则，判断key-value数据库中是否有默认规则数据；若有默认规则数据则返回默认规则数据。如果key-value数据库没有默认规则数据，则可能是缓存失效了或者缓存内容被污染了，或者也可能是key-value数据库真的没有数据。

规则数据查询单元820还用于若根据业务key不能够在key-value数据库中查询到规则数据，则根据规则key查询key-value数据库；若根据规则key能够在key-value数据库中查询到规则数据，则返回查询结果，否则，在持久化存储数据库中查询规则数据，并返回查询结果。

在该实施例中，先根据业务key在key-value数据库查找规则数据，若查询不到，再根据规则key在key-value数据库查询规则数据，若查询不到，才到持久化存储数据库中查询规则数据。能够提升查询效率，并且能够解决数据量巨大的情况下，操作查询数据库时容易产生热key以及单key保存的数据受限的问题。

本公开的应用在区块链上的海量规则数据处理系统可以应用在电子商务领域，也可以应用在区块链领域，例如，在应用到区块链领域时，可以将业务key存储在区块链中。由于区块链各节点保存的数据是相同的，但由于各节点保存了业务key，使得查询效率更高。

图9为本公开应用在区块链上的海量规则数据处理系统的再一个实施例的结构示意图。该系统包括存储器910和处理器920，其中：

存储器910可以是磁盘、闪存或其它任何非易失性存储介质。存储器用于存储图1、3-5所对应实施例中的指令。处理器920耦接至存储器910，可以作为一个或多个集成电路来实施，例如微处理器或微控制器。该处理器920用于执行存储器中存储的指令。

在一个实施例中，还可以如图10所示，该系统1000包括存储器1010和处理器1020。处理器1020通过bus总线1030耦合至存储器1010。该系统1000还可以通过存储接口1040连接至外部存储装置1050以便调用外部数据，还可以通过网络接口1060连接至网络或者另外一台计算机系统(未标出)，此处不再进行详细介绍。

在该实施例中，通过存储器存储数据指令，再通过处理器处理上述指令，解决了海量数据存储问题，同时能够提升数据查询效率。

在另一个实施例中，一种计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现图1、2-5所对应实施例中的方法的步骤。本领域内的技术人员应明白，本公开的实施例可提供为方法、装置、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用非瞬时性存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本公开是参照根据本公开实施例的方法、设备(系统)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

至此，已经详细描述了本公开。为了避免遮蔽本公开的构思，没有描述本领域所公知的一些细节。本领域技术人员根据上面的描述，完全可以明白如何实施这里公开的技术方案。

虽然已经通过示例对本公开的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上示例仅是为了进行说明，而不是为了限制本公开的范围。本领域的技术人员应该理解，可在不脱离本公开的范围和精神的情况下，对以上实施例进行修改。本公开的范围由所附权利要求来限定。