CN110362599A - 数据存储方法、装置、电子设备及计算机可读介质 - Google Patents

Abstract

本公开提供一种数据存储方法、装置、电子设备及计算机可读介质，属于互联网技术领域。该数据存储方法包括：按照关键字映射关系，利用关键字对待处理数据进行标识，得到元数据；对所述元数据进行读操作和写操作的逻辑控制，以完成所述待处理数据的更新和缓存；根据所述元数据进行版本的更新和缓存。通过利用关键字对待处理数据进行标识后再进行相应的读写操作，可以解决缓存和数据库的数据存在的一致性问题，对数据的版本进行更新和缓存，缩短数据达到最终一致性的时间，保证数据的实时性和可靠性。

Description

数据存储方法、装置、电子设备及计算机可读介质

技术领域

本公开总体涉及互联网技术领域，具体而言，涉及一种数据存储方法、装置、电子设备及计算机可读介质。

背景技术

互联网系统往往选择传统数据库结合分布式缓存的数据存取方式，分别利用它们各自具有的优势，即传统数据库具有结构化SQL(Structured Query Language，结构化查询语言)查询的优势，而分布式缓存作为高性能的cache(高速缓存存储器)功能使用。

但是cache-db(即缓存-数据库)种数据存取方式在使用上也存在不少难题，如cache和db中的数据一致性的问题。多种存储介质中数据一致性对每个系统来说都非常重要，根据系统所处的应用环境又分为强一致性和最终一致性，强一致性的要求非常高，往往由于各种复杂的因素很难实现，大多数系统满足最终一致性即可，但是最终一致性的前提条件下，数据达成一致的时间越短越好，时间越短意味着数据使用方加载到最新数据的时间就越快。

因此，现有技术中的技术方案中存在数据一致性的问题，还存在有待改进之处。

在所述背景技术部分公开的上述信息仅用于加强对本公开的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开提供一种数据存储方法、装置、电子设备及计算机可读介质，解决上述技术问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一方面，提供一种数据存储方法，包括：

按照关键字映射关系，利用关键字对待处理数据进行标识，得到元数据；

对所述元数据进行读操作和写操作的逻辑控制，以完成所述待处理数据的更新和缓存；

根据所述元数据进行版本的更新和缓存。

在本公开的一个实施例中，利用关键字对待处理数据进行标识，得到元数据包括：

根据关键字集合与待处理数据集合进行映射，利用所述关键字集合中的关键字对所述待处理数据集合中的待处理数据进行一一标识，得到元数据；

其中所述待处理数据集合中包括M个参数，所述关键字集合中包括N个关键字，所述元数据包括：初级的版本key集合，且所述初级的版本key结集合中包括M个版本key，M≤N。

在本公开的一个实施例中，对所述元数据进行写操作的逻辑控制包括：

将所述元数据写入数据库，完成所述数据库中对所述待处理数据的更新，并响应接口写操作成功。

在本公开的一个实施例中，将所述元数据写入数据库之后还包括：

根据所述数据库更新的数据对所述初级的版本key集合进行补全版本key，得到完整的版本key集合。

在本公开的一个实施例中，完整的版本key集合之后还包括：

将所述完整的版本key集合存储至所述数据库中。

在本公开的一个实施例中，根据所述元数据进行版本更新包括：

根据所述完整的版本key集合对所述版本key和所述版本key对应的值进行更新，并缓存至缓存区中。

在本公开的一个实施例中，对所述元数据进行读操作的逻辑控制包括：

从缓存区读取针对所述元数据的缓存数据；

根据所述元数据和所述缓存数据进行版本对比，如果所述缓存数据的版本key对应的值V1大于等于所述元数据的版本key对应的值V2，则直接返回所述缓存数据；如果所述缓存数据的版本key对应的值V1小于等于所述元数据的版本key对应的值V2，则从所述数据库中获取针对所述元数据的数据并缓存至所述缓存区。

根据本公开的再一方面，提供一种数据存储装置，包括：

关键字映射单元，配置为存储有关键字的映射关系；

元数据构造器，配置为利用关键字集合对待处理数据进行标识，得到元数据；

逻辑控制器，配置为对所述元数据的读操作和写操作进行控制；

数据缓存器，配置为根据所述逻辑控制单元的控制进行所述待处理数据的更新和缓存；

版本缓存器，配置为根据所述元数据进行版本的更新和缓存。

根据本公开的又一方面，提供一种电子设备，包括处理器；存储器，存储用于所述处理器控制如上所述的方法步骤的指令。

根据本公开的另一方面，提供一种计算机可读介质，其上存储有计算机可执行指令，所述可执行指令被处理器执行时实现如上所述的方法步骤。

根据本公开实施例提供的数据存储方法、装置、电子设备及计算机可读介质，一方面，通过利用关键字对待处理数据进行标识后再进行相应的读写操作，可以解决缓存和数据库的数据存在的一致性问题；另一方面，除了数据的缓存和更新，还进一步对数据的版本进行更新和缓存，缩短数据达到最终一致性的时间，保证数据的实时性和可靠性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

通过参照附图详细描述其示例实施例，本公开的上述和其它目标、特征及优点将变得更加显而易见。

图1示出本公开一实施例中提供的一种数据存储方法的流程图。

图2示出为实现本公开实施例中的数据存储方法的总体框架图。

图3示出本公开一实施例中进行写操作的流程示意图。

图4示出本公开一实施例中进行读操作的流程示意图。

图5示出本公开另一实施例提供的一种数据存储装置的示意图。

图6示出本公开一实施例提供的适于用来实现本申请实施例的电子设备的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知结构、方法、装置、实现、材料或者操作以避免喧宾夺主而使得本公开的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

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

随着互联网的井喷发展，系统的并发能力往往起着至关重要的作用，而提升系统的并发能力从负载均衡到前端，再到应用后台，直至存储有很多种提升系统并发处理能力的技术和方法，其中分布式缓存技术是一种提升并发能力的关键及技术，分式缓存追求高性能而往往就不支持类似SQL那样的结构化查询，而是以简单的k/v方式存储。

在本公开的相关实施例中，cache-db使用方式一般分为两种：

(1)并发不高的情况：

写:写db->写db成功，再写cache(ttl)；

读:读cache->如果cache中没有数据，则读db->把db数据写回cache；如果cache中有数据，则直接从cache中读取；

这种情况下会存在一致性问题：写db成功后，准备写cache时，在很多情况下，在db中写入一条数据，就会有无数种用法，这就意味着有无数个缓存key。即使将缓存key注册管理起来，还会存在是否需要更新所有key的问题，即使服务有能力异步完成所有key的更新，但是更新的所有key中value并不一定仅是这一条完整数据，大多数情况这条数据只是缓存的其中之一。另外，随意更新缓存中的数据，意味着业务没有解耦，各种突发情况，会导致数据异常，缓存中更新的数据都可能出现问题。总之，更新db的同时，直接更新使用方的缓存不是一种很好的做法。

(2)并发高的情况:

写：如果是异步的写，则先写入cache的缓存，就直接返回；worker定期或特定动作将数据保存到db；

读:读cache->如果cache中没有数据，则读db->把db数据写回cache；如果cache中有数据，则直接从cache中取。

这种情况下也会存在一致性问题：读数据优先从缓存中读取，由于是先写缓存再写db，一定能保证获取到最新的数据，但是缓存向数据库同步的时候，却依赖的是其它高性能的worker，这种处理方式通常容易引起拥塞，导致缓存中的越来越多，数据库中的数据和缓存中的数据达到一致的时间越来越长。另外，直接从同一种缓存中去读取数据使用，就完全没有利用SQL结构化的优势，因此，这种设计方法的应用范围较小。

当然除了以上两种方式，还有第三种使用比较普遍的方式就是采用写数据到db成功后通知的办法，去告知订阅方数据有变更，订阅方收到通知应该让自己关联的缓存时效，从而下次加载数据时，直接从db中加载到最新数据，再缓存。这种方式无论是在生产者-消费者之间的低耦合，还是普适范围都有了明显的提升，但由于往往由于订阅方对缓存key没有有效的管理，收到变更通知时，不知更新哪些key，加之更新通知还会存在通知失败的情况，导致消费者长时间都使用不到最新的数据。

基于上述，仍然需要一种更好的办法来支撑和解决cache和db之间的数据一致性问题。

图1示出本公开一实施例中提供的一种数据存储方法的流程图，包括以下步骤：

如图1所示，在步骤S110中，按照关键字映射关系，利用关键字对待处理数据进行标识，得到元数据。

如图1所示，在步骤S120中，对元数据进行读操作和写操作的逻辑控制，以完成待处理数据的更新和缓存。

如图1所示，在步骤S130中，根据元数据进行版本的更新和缓存。

本公开实施例提供的数据存储方法，一方面，通过利用关键字对待处理数据进行标识后再进行相应的读写操作，可以解决缓存和数据库的数据存在的一致性问题；另一方面，除了数据的缓存和更新，还进一步对数据的版本进行更新和缓存，缩短数据达到最终一致性的时间，保证数据的实时性和可靠性。

图2示出为实现本公开实施例中的数据存储方法的总体框架图，如图2所示，包括：逻辑控制层、数据缓存层、版本缓存层、持久层以及关键字映射单元，通过上述各层实现数据的读服务和写服务。其中各层的功能分别为：

逻辑控制单元层主要负责读写数据的逻辑控制以及cache和db之间切换逻辑；数据缓存层主要负责从db中读出的数据缓存起来，让接口的响应更快；版本缓存层主要负责将各种关键字对应的版本key和版本key的值(用time stamp时间戳来表示版本key的值)缓存起来；持久层就是db层，主要负责往db中读写数据；关键字映射单元主要负责将db中的数据表用关键字标识出来，供后续版本缓存的流程使用。

以下结合图2所示的总体框架图对本公开提供的数据存储方法进行详细介绍，具体如下：

在步骤S110中，按照关键字映射关系，利用关键字对待处理数据进行标识，得到元数据。

在本公开的一个实施例中，关键字映射关系由关键字映射单元提供，其中的关键字可以为字段名，以员工信息管理数据为例，关键字可以包括但不限于姓名、工号、电话号码等。其中工号不可变唯一，姓名和电话号码可变不唯一，相应的，关键字映射单元的字段有{'工号'，'电话号码'}。待处理数据可以为待写入的数据，也可以是待读出的数据。

在本公开的一个实施例中，该步骤具体为：

根据关键字集合与待处理数据集合进行映射，利用关键字集合中的关键字对待处理数据集合中的待处理数据进行一一标识，得到元数据；

其中待处理数据集合中包括M个参数，用paramSet表示待处理数据集合，paramSet＝{param1＝value1,param2＝value2,…,paramM＝valueM}；

关键字集合中包括N个关键字，用KeySet表示关键字集合，KeySet＝{key1,key2,…,keyN}。

需要说明的是，本公开实施例中元数据构造器根据待处理数据集合和关键字集合，构造各种后续步骤所需要的元数据，如版本key、数据库查询元数据和数据缓存key的前缀元数据等。

基于各个版本key，得到版本key集合为：

versionKeySet＝{versionKey1,versionKey2,…,versionKeyN}，其中版本key是由param和key共同决定的，即版本key集合中的任一个版本key为：

versionKeyX＝'paramA＝valueA'+'paramB＝valueB'+……

其中paramA、valueA、paramB、valueB均为待处理数据集合paramSet中的元素。

需要说明的是，在待处理数据集合paramSet、关键字集合KeySet和版本key集合versionKeySet中的字段名均与关键字的字段名一致，以保证映射顺利完成。读写数据是产生的版本key都保存在相同的缓存分片上，可用进程间通信替代，如：MQ/Kafka。

还需要说明的是，待处理数据集合{paramX}是关键字集合{KeyX}的子集，通常paramSet中有效元素paramX个数小于KeySet集合中元素的个数，即M≤N。经过元数据构造器实际构造出来的初级的版本key集合元素的个数是与待处理数据集合元素的个数相同，即初级的版本key集合元素的个数也是M，初级的版本key集合元素的个数一定小于N，用subVersionKeySet表示初级的版本key集合。

在步骤S120中，对元数据进行读操作和写操作的逻辑控制，以完成待处理数据的更新和缓存。

以下，元数据经过逻辑控制总线分别对待处理数据进行相应的读操作或是写操作做介绍：

图3示出进行写操作的流程示意图，如图3所示，在逻辑控制总线之前，元数据构造器根据写数据入口单元要写的数据集合(即待处理数据)与关键字映射单元结合映射关系构造得到元数据。

在本公开的一个实施例中，写数据时逻辑控制总线的控制逻辑包括：

首先，将元数据写入数据库，完成数据库中对待处理数据的更新，并响应接口写操作成功。其中写入数据库时按照SQL语句查询并进行相应的存储。

然后，根据数据库更新的数据对初级的版本key集合进行补全版本key，得到完整的版本key集合。由于步骤S110中元数据构造器得到的初级的版本key集合并不完整，为了达到数据更新通知到所有版本key的目的，还需要补全相应的版本key。因此，异步线程优先再次从数据库中取出更新的数据完整的字段，记为fieldSet＝{field1＝value1,field2＝value2,…,fieldT},一般情况下，filedSet的大小T应该比关键字集合KeySet的个数N要大，即T>N>M。获取到完整的数据后，就可以补全subVersionKeySet了，即补全的版本key集合记为diffVersionKeySet，因此存在以下关系：

versionKeySet＝subVersionKey+diffVerisonKey。

最后，将完整的版本key集合存储至数据库中，具体可以通过异步更新的方式更新所有的版本key。如图3所示，具体的，更新所有版本key后通过版本缓存执行器将其缓存至缓存区Redis中，以此完成写数据的操作。

图4示出进行读操作的流程示意图，如图3所示，在逻辑控制总线之前，元数据构造器根据写数据入口单元要读的数据集合(即待处理数据)与关键字映射单元结合映射关系构造得到元数据。

在本公开的一个实施例中，读数据时逻辑控制总线的控制逻辑包括：

首先，与写数据不同的是，读数据时想要从数据库中读出数据，就需要先读缓存区。

具体的，如图4所示，从缓存区Redis中读取数据具体包括：

第一步，通过数据缓存执行器在从缓存区从缓存区读取针对元数据的缓存数据；

第二步，根据元数据和缓存数据进行版本对比，如果缓存数据的版本key对应的值V1大于等于元数据的版本key对应的值V2，则直接返回缓存数据；如果缓存数据的版本key对应的值V1小于等于元数据的版本key对应的值V2，则从数据库中获取针对元数据的数据并缓存至缓存区。

需要说明的是，与写数据还有不同在于：读数据流程中还将构造一个本次读操作唯一的版本key，记为readVersionKey，readVersionKey和写数据过程中subVersionKeySet的构造方法一样，此处不再赘述。

针对上述第二步，优先从缓存区中读取数据DataX(DataX的数据版本号暂记为V1，此时，不能直接将读取的数据DataX返回，需要对比版本号，即将从数据库读取数据产生的readVersionKey对应的版本号V2提取出来，如果对比结果为V1≥V2，即立即将读取的数据DataX返回；如果V2>V1，则说明缓存区中的数据已经部署最新的数据，需要重新从数据库中加载最新的数据DataY了，并将DataY存入缓存区中，以便下一次读数据能读到最新的数据，这样在读数据时就能直接快速地从缓存区读取最新的实时数据，保证数据的实时缓存，可靠性增强。

然后，根据数据库更新的数据对初级的版本key集合进行补全版本key，得到完整的版本key集合。

与写数据的过程相同，在读数据时，由于步骤S110中元数据构造器得到的初级的版本key集合并不完整，为了达到数据更新通知到所有版本key的目的，还需要补全相应的版本key。因此，异步线程优先再次从数据库中取出更新的数据完整的字段，记为

fieldSet＝{field1＝value1,field2＝value2,…,fieldT},一般情况下，filedSet的大小T应该比关键字集合KeySet的个数N要大，即T>N>M。获取到完整的数据后，就可以补全subVersionKeySet了，即补全的版本key集合记为diffVersionKeySet，因此存在以下关系：

versionKeySet＝subVersionKey+diffVerisonKey。

最后，将完整的版本key集合存储至数据库中，具体可以通过异步更新的方式更新所有的版本key。

此时开始异步更新所有版本key中的版本号，而且在补全版本key之后，不用再次造访数据库了，因为DataY已经是最新的数据，具备fieldSet所有字段。

在步骤S130中，根据元数据进行版本的更新和缓存。

在本公开的一个实施例中，该步骤具体包括：

根据完整的版本key集合对版本key和版本key对应的值进行更新，并缓存至缓存区中。具体的，更新所有版本key后通过版本缓存执行器将其缓存至缓存区Redis中，以此完成读数据的操作。

需要说明的是，本公开实施例中是以Redis和MySQL分别来代替cache和db。

以下以一实例具体对数据的读写操作进行介绍：

假设员工信息＝{'工号'，'姓名'，'电话号码'}，工号不可变唯一，姓名和电话号码可变不唯一，关键字映射单元的字段有{'工号'，'电话号码'}。

在写操作时：

更新员工姓名时(从'zhangsan1修改为zhangsan2'),提交的数据为待处理数据集合paramSet＝{'工号':1005,'姓名':'zhangsan2'}，原本的版本key集合的全集应该是

versionKey1＝'工号＝1005'

versionKey2＝'电话号码＝xxx'，

但是由于待处理数据结合中只有工号和姓名，因此，通过与关键字映射单元进行映射，元数据构造器只能构造出初级的版本key集合，即subVersionKeySet，subVersionKeySet中只包含versionKey1，缺少的versionKey2，只能通过后续数据库的数据来补全。通过工号从数据库中查询出该员工的完整信息是{'工号':1005,'姓名':'zhangsan1','电话号码':xxx}，补全的版本key集合diffversionKey，即versionKey2＝'电话号码＝xxx'。

当更新完数据库后，还需要更新版本key的value，假设本次更新前的value＝v20180226，本次更新的value＝v20180227。

因此，此时通知更新versionKey1＝'工号＝1005'和versionKey2＝'电话号码＝xxx'的版本号value都是v20180227。

在读操作时：

无论根据员工号或电话号码查询员工信息时，提交的参数只有员工号，从缓存中读出员工信息数据，发现数据版本v20180226，而版本key中的值是v20180227，通过对比版本发现数据已经不是最新的了。此时，从数据库中先读出最新的数据并返回，然后再异步更新缓存区中的最新数据。另外，版本key也可以采用上述写操作相同的方法进行更新，此处不再赘述。

通过这种为读写提供统一的内部逻辑，每一次数据的变更都带有唯一的版本key，再通过关键字的标注即可完成cache与db之间的一致性问题。另外，该方法还存在如下优点：

1)可靠性：写数据通知失败，读数据时可能被通知到，可靠性增强；

2)实时性：读写口的数据保持是最新的实时数据，实时性强；

3)db负载：由于读接口获取到实时数据的可靠性高，那么数据缓存的TTL(Time ToLive，生存时间)理论上可以设置很长，这样也就避免了更少的访问db的次数；

4)db负载平稳性：由于数据缓存的TTL理论上可以设置更长，意味着不再存在流量低谷时，缓存集体失效，导致流量下次突然高峰时，数据库负载急剧升高，使得db负载平稳性增强；

5)最终一致性时间：由于实时性非常高，最终一致性的时间显著缩短；

6)普适性：由于保证一致性前提下，复杂而繁琐的读写流程都被封装起来，这样应用仅需传参数调用实时缓存组件即可，具有更强的普适性，对于cache-db结构均可适用。

综上所述，本公开实施例提供的数据存储方法，一方面，通过利用关键字对待处理数据进行标识后再进行相应的读写操作，可以解决缓存和数据库的数据存在的一致性问题；另一方面，除了数据的缓存和更新，还进一步对数据的版本进行更新和缓存，缩短数据达到最终一致性的时间，保证数据的实时性和可靠性，此外基于上述，还具有较强的普适性和db负载平稳性，降低db负载。

图5示出本公开另一实施例提供的一种数据存储装置的示意图，如图5所示，该装置500中包括：关键字映射单元510、元数据构造器520、逻辑控制器530、数据缓存器540和版本缓存器550。

关键字映射单元510配置为存储有关键字的映射关系；元数据构造器520配置为利用关键字集合对待处理数据进行标识，得到元数据；逻辑控制器530配置为对所述元数据的读操作和写操作进行控制；数据缓存器540配置为根据所述逻辑控制单元的控制进行所述待处理数据的更新和缓存；版本缓存器550配置为根据所述元数据进行版本的更新和缓存。

在本公开的一个实施例中，关键字映射单元510中关键字的映射关系由关键字映射单元提供，其中的关键字可以为字段名，以员工信息管理数据为例，关键字可以包括但不限于姓名、工号、电话号码等。其中工号不可变唯一，姓名和电话号码可变不唯一，相应的，关键字映射单元的字段有{'工号'，'电话号码'}。待处理数据可以为待写入的数据，也可以是待读出的数据。

在本公开的一个实施例中，元数据构造器520根据关键字集合与待处理数据集合进行映射，利用关键字集合中的关键字对待处理数据集合中的待处理数据进行一一标识，得到元数据。

其中待处理数据集合中包括M个参数，用paramSet表示待处理数据集合，paramSet＝{param1＝value1,param2＝value2,…,paramM＝valueM}；

关键字集合中包括N个关键字，用KeySet表示关键字集合，KeySet＝{key1,key2,…,keyN}。

需要说明的是，本公开实施例中元数据构造器根据待处理数据集合和关键字集合，构造各种后续步骤所需要的元数据，如版本key、数据库查询元数据和数据缓存key的前缀元数据等。

基于各个版本key，得到版本key集合为：

versionKeySet＝{versionKey1,versionKey2,…,versionKeyN}，其中版本key是由param和key共同决定的，即版本key集合中的任一个版本key为：

versionKeyX＝'paramA＝valueA'+'paramB＝valueB'+……

其中paramA、valueA、paramB、valueB均为待处理数据集合paramSet中的元素。

需要说明的是，在待处理数据集合paramSet、关键字集合KeySet和版本key集合versionKeySet中的字段名均与关键字的字段名一致，以保证映射顺利完成。读写数据是产生的版本key都保存在相同的缓存分片上，可用进程间通信替代，如：MQ/Kafka。

还需要说明的是，待处理数据集合{paramX}是关键字集合{KeyX}的子集，通常paramSet中有效元素paramX个数小于KeySet集合中元素的个数，即M≤N。经过元数据构造器实际构造出来的初级的版本key集合元素的个数是与待处理数据集合元素的个数相同，即初级的版本key集合元素的个数也是M，初级的版本key集合元素的个数一定小于N，用subVersionKeySet表示初级的版本key集合。

在本公开的一个实施例中，逻辑控制器530对待处理数据进行相应的读操作或是写操作具体为：

1)写数据时逻辑控制总线的控制逻辑包括：

首先，将元数据写入数据库，完成数据库中对待处理数据的更新，并响应接口写操作成功。其中写入数据库时按照SQL语句查询并进行相应的存储。

然后，根据数据库更新的数据对初级的版本key集合进行补全版本key，得到完整的版本key集合。由于步骤S110中元数据构造器得到的初级的版本key集合并不完整，为了达到数据更新通知到所有版本key的目的，还需要补全相应的版本key。因此，异步线程优先再次从数据库中取出更新的数据完整的字段，记为fieldSet＝{field1＝value1,field2＝value2,…,fieldT},一般情况下，filedSet的大小T应该比关键字集合KeySet的个数N要大，即T>N>M。获取到完整的数据后，就可以补全subVersionKeySet了，即补全的版本key集合记为diffVersionKeySet，因此存在以下关系：

versionKeySet＝subVersionKey+diffVerisonKey。

最后，将完整的版本key集合存储至数据库中，具体可以通过异步更新的方式更新所有的版本key。如图3所示，具体的，更新所有版本key后通过版本缓存执行器将其缓存至缓存区Redis中，以此完成写数据的操作。

2)读数据时逻辑控制总线的控制逻辑包括：

首先，与写数据不同的是，读数据时想要从数据库中读出数据，就需要先读缓存区。

具体的，从缓存区Redis中读取数据具体包括：

第一步，通过数据缓存执行器在从缓存区从缓存区读取针对元数据的缓存数据；

第二步，根据元数据和缓存数据进行版本对比，如果缓存数据的版本key对应的值V1大于等于元数据的版本key对应的值V2，则直接返回缓存数据；如果缓存数据的版本key对应的值V1小于等于元数据的版本key对应的值V2，则从数据库中获取针对元数据的数据并缓存至缓存区。

需要说明的是，与写数据还有不同在于：读数据流程中还将构造一个本次读操作唯一的版本key，记为readVersionKey，readVersionKey和写数据过程中subVersionKeySet的构造方法一样，此处不再赘述。

针对上述第二步，优先从缓存区中读取数据DataX(DataX的数据版本号暂记为V1，此时，不能直接将读取的数据DataX返回，需要对比版本号，即将从数据库读取数据产生的readVersionKey对应的版本号V2提取出来，如果对比结果为V1≥V2，即立即将读取的数据DataX返回；如果V2>V1，则说明缓存区中的数据已经部署最新的数据，需要重新从数据库中加载最新的数据DataY了，并将DataY存入缓存区中，以便下一次读数据能读到最新的数据，这样在读数据时就能直接快速地从缓存区读取最新的实时数据，保证数据的实时缓存，可靠性增强。

然后，根据数据库更新的数据对初级的版本key集合进行补全版本key，得到完整的版本key集合。

与写数据的过程相同，在读数据时，由于步骤S110中元数据构造器得到的初级的版本key集合并不完整，为了达到数据更新通知到所有版本key的目的，还需要补全相应的版本key。因此，异步线程优先再次从数据库中取出更新的数据完整的字段，记为

fieldSet＝{field1＝value1,field2＝value2,…,fieldT},一般情况下，filedSet的大小T应该比关键字集合KeySet的个数N要大，即T>N>M。获取到完整的数据后，就可以补全subVersionKeySet了，即补全的版本key集合记为diffVersionKeySet，因此存在以下关系：

versionKeySet＝subVersionKey+diffVerisonKey。

最后，将完整的版本key集合存储至数据库中，具体可以通过异步更新的方式更新所有的版本key。

此时开始异步更新所有版本key中的版本号，而且在补全版本key之后，不用再次造访数据库了，因为DataY已经是最新的数据，具备fieldSet所有字段。

在本公开的一个实施例中，数据缓存器540根据逻辑控制单元的控制进行待处理数据的更新和缓存，其中对写数据和读数据的更新和缓存参见上述逻辑控制过程的介绍，此处不再赘述。

在本公开的一个实施例中，版本缓存器550根据完整的版本key集合对版本key和版本key对应的值进行更新，并缓存至缓存区中。具体的，更新所有版本key后通过版本缓存执行器将其缓存至缓存区Redis中，以此完成读数据的操作。

在本公开的一个实施例中，该数据存储装置能过与上述图2所示的总体架构中的各层对应，另外，还需包括数据库(图5未示出)，以完成数据的写操作和读操作。

该装置中各个模块的功能参见上述方法实施例中的相关描述，此处不再赘述。

另一方面，本公开还提供了一种电子设备，包括处理器和存储器，存储器存储用于上述处理器控制以下方法的操作指令：

按照关键字映射关系，利用关键字对待处理数据进行标识，得到元数据；对所述元数据进行读操作和写操作的逻辑控制，以完成所述待处理数据的更新和缓存；根据所述元数据进行版本的更新和缓存。

下面参考图6，其示出了适于用来实现本申请实施例的电子设备的计算机系统600的结构示意图。图6示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图6所示，计算机系统600包括中央处理单元(CPU)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储部分607加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。在RAM603中，还存储有系统600操作所需的各种程序和数据。CPU 601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

以下部件连接至I/O接口605：包括键盘、鼠标等的输入部分606；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分607；包括硬盘等的存储部分608；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至I/O接口605。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装入存储部分608。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分609从网络上被下载和安装，和/或从可拆卸介质611被安装。在该计算机程序被中央处理单元(CPU)601执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读介质或者是上述两者的任意组合。计算机可读介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括发送单元、获取单元、确定单元和第一处理单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，发送单元还可以被描述为“向所连接的服务端发送图片获取请求的单元”。

另一方面，本公开还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括以下方法步骤：

按照关键字映射关系，利用关键字对待处理数据进行标识，得到元数据；对所述元数据进行读操作和写操作的逻辑控制，以完成所述待处理数据的更新和缓存；根据所述元数据进行版本的更新和缓存。

应清楚地理解，本公开描述了如何形成和使用特定示例，但本公开的原理不限于这些示例的任何细节。相反，基于本公开公开的内容的教导，这些原理能够应用于许多其它实施方式。

以上具体地示出和描述了本公开的示例性实施方式。应可理解的是，本公开不限于这里描述的详细结构、设置方式或实现方法；相反，本公开意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。

Claims (10)

1.一种数据存储方法，其特征在于，包括：

按照关键字映射关系，利用关键字对待处理数据进行标识，得到元数据；

对所述元数据进行读操作和写操作的逻辑控制，以完成所述待处理数据的更新和缓存；

根据所述元数据进行版本的更新和缓存。

2.根据权利要求1所述的数据存储方法，其特征在于，利用关键字对待处理数据进行标识，得到元数据包括：

根据关键字集合与待处理数据集合进行映射，利用所述关键字集合中的关键字对所述待处理数据集合中的待处理数据进行一一标识，得到元数据；

其中所述待处理数据集合中包括M个参数，所述关键字集合中包括N个关键字，所述元数据包括：初级的版本key集合，且所述初级的版本key结集合中包括M个版本key，M≤N。

3.根据权利要求2所述的数据存储方法，其特征在于，对所述元数据进行写操作的逻辑控制包括：

将所述元数据写入数据库，完成所述数据库中对所述待处理数据的更新，并响应接口写操作成功。

4.根据权利要求3所述的数据存储方法，其特征在于，将所述元数据写入数据库之后还包括：

根据所述数据库更新的数据对所述初级的版本key集合进行补全版本key，得到完整的版本key集合。

5.根据权利要求4所述的数据存储方法，其特征在于，完整的版本key集合之后还包括：

将所述完整的版本key集合存储至所述数据库中。

6.根据权利要求4所述的数据存储方法，其特征在于，根据所述元数据进行版本更新包括：

根据所述完整的版本key集合对所述版本key和所述版本key对应的值进行更新，并缓存至缓存区中。

7.根据权利要求2所述的数据存储方法，其特征在于，对所述元数据进行读操作的逻辑控制包括：

从缓存区读取针对所述元数据的缓存数据；

根据所述元数据和所述缓存数据进行版本对比，如果所述缓存数据的版本key对应的值V1大于等于所述元数据的版本key对应的值V2，则直接返回所述缓存数据；如果所述缓存数据的版本key对应的值V1小于等于所述元数据的版本key对应的值V2，则从所述数据库中获取针对所述元数据的数据并缓存至所述缓存区。

8.一种数据存储装置，其特征在于，包括：

关键字映射单元，配置为存储有关键字的映射关系；

元数据构造器，配置为利用关键字集合对待处理数据进行标识，得到元数据；

逻辑控制器，配置为对所述元数据的读操作和写操作进行控制；

数据缓存器，配置为根据所述逻辑控制单元的控制进行所述待处理数据的更新和缓存；

版本缓存器，配置为根据所述元数据进行版本的更新和缓存。

9.一种电子设备，其特征在于，包括：

处理器；

存储器，存储用于所述处理器控制如权利要求1-7任一项所述的方法步骤。

10.一种计算机可读介质，其上存储有计算机可执行指令，其特征在于，所述可执行指令被处理器执行时实现如权利要求1-7任一项所述的方法步骤。