CN114356921A - 数据处理方法、装置、服务器及存储介质 - Google Patents

Abstract

本申请提供一种数据处理方法、装置、服务器及存储介质，通过获取目标存储数据，该目标存储数据为数据库中的数据或者客户端的页面维护数据，然后基于预设键值对构建规则，对目标存储数据进行处理，得到目标存储数据对应的缓存键值对，其中，缓存键值对的键名用于指示目标存储数据的数据类型，缓存键值对的键值为指示目标存储数据的目标存储字段和该目标存储字段的属性值，最后将该键值对存储至缓存中。该技术方案中，服务器可以基于数据自身的特性，构建了专属的键值对，便于在特定场景下从缓存中查询出符合要求的数据，其提高了在缓存中查询的命中率以及复杂场景应用的适应性，不仅避免了资源浪费，而且提高了存取效率。

Description

数据处理方法、装置、服务器及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种数据处理方法、装置、服务器及存储介质。

背景技术

随着应用系统的不断扩大使用，数据库中存储的数据量越来越大，与其它领域应用系统相比，互联网金融系统自身所包含的金融类数据类型繁多且业务含义难懂，以及鉴于其所在的业务应用场景，如何保证在复杂业务场景下能够快速准确的获取满足业务需求的金融数据变的更为迫切重要。

现有技术中，数据存取方案为将需要存储的数据存储至数据库，同时，将部分数据的整条对象实体数据存储至缓存。当业务场景需要用到某条数据时，首先到缓存中进行查询，若在缓存中查询不到，则到数据库中进行查询，从而得到目标查询数据。

然而，在实际应用中，并不是数据表中的所有字段都会被使用，将整条对象实体数据进行存取的方案不仅浪费缓存资源，而且命中率低，存取效率低。

发明内容

本申请提供一种数据处理方法、装置、服务器及存储介质，以克服现有数据存取方案存在的浪费缓存资源，命中率低，存取效率低的问题。

第一方面，本申请提供一种数据处理方法，包括：

获取目标存储数据，所述目标存储数据为数据库中的数据或者客户端的页面维护数据；

基于预设键值对构建规则，对所述目标存储数据进行处理，得到所述目标存储数据对应的缓存键值对，所述缓存键值对的键名用于指示所述目标存储数据的数据类型，所述缓存键值对的键值为指示所述目标存储数据的目标存储字段和所述目标存储字段的属性值；

将所述键值对存储至缓存中。

在第一方面的一种可能设计中，所述目标存储数据为数据库中的数据；

相应的，所述获取目标存储数据，包括：

获取数据存储请求，所述数据存储请求包括：业务场景标识；

根据所述业务场景标识，筛选出所述数据库中的所述业务场景标识对应的热点数据集，所述热点数据集中的每条热点数据为使用频率大于预设频率阈值的数据；

基于数据的业务属性信息，对所述热点数据集中的热点数据进行分类，得到每类的目标存储数据。

在第一方面的另一种可能设计中，所述目标存储数据为客户端的页面维护数据；

相应的，所述方法还包括：

将所述目标存储数据存储至所述数据库。

在第一方面的再一种可能设计中，所述基于预设键值对构建规则，对所述目标存储数据进行处理，得到所述目标存储数据对应的缓存键值对，包括：

根据所述目标存储数据的业务属性信息，确定所述目标存储数据的数据类型；

根据所述目标存储数据的数据类型，确定所述目标存储数据的标识性字段和至少一个类区分度字段；

根据所述标识性字段和所述至少一个类区分度字段，确定所述目标存储数据的类型标识符，所述类型标识符作为所述键值对的键名；

确定所述目标存储数据的目标存储字段和所述目标存储字段的属性值；

确定所述目标存储字段在数据访问层的mapper映射文件中的类属性名；

根据所述类属性名和所述目标存储字段的属性值，构建所述缓存键值对的键值。

在第一方面的又一种可能设计中，所述方法还包括：

获取数据读取请求，所述数据读取请求包括：至少一个目标键名；

根据所述至少一个目标键名，确定所述缓存中的每个目标键名对应的目标键值对；

从确定出的所有目标键值对中，获取每个目标键值对中的键值，所述键值包括：至少一个目标字段以及每个目标字段的属性值；

基于所述缓存的管道模式，反馈数据读取响应，所述数据读取响应包括：所有目标键值对中的键值。

可选的，在所述根据所述至少一个目标键名，确定所述缓存中的每个目标键名对应的目标键值对之前，所述方法还包括：

将所述至少一个目标键名存入字符串数组中；

相应的，所述根据所述至少一个目标键名，确定所述缓存中的每个目标键名对应的目标键值对，包括：

基于所述字符串数组中的每个目标键名，依次在所述缓存中查询，获取每个目标键名对应的键值。

第二方面，本申请提供一种数据处理装置，包括：

获取模块，用于获取目标存储数据，所述目标存储数据为数据库中的数据或者客户端的页面维护数据；

处理模块，用于基于预设键值对构建规则，对所述目标存储数据进行处理，得到所述目标存储数据对应的缓存键值对，所述缓存键值对的键名用于指示所述目标存储数据的数据类型，所述缓存键值对的键值为指示所述目标存储数据的目标存储字段和所述目标存储字段的属性值；

存储模块，用于将所述键值对存储至缓存中。

在第二方面的一种可能设计中，所述目标存储数据为数据库中的数据；

相应的，所述获取模块，具体用于：

获取数据存储请求，所述数据存储请求包括：业务场景标识；

根据所述业务场景标识，筛选出所述数据库中的所述业务场景标识对应的热点数据集，所述热点数据集中的每条热点数据为使用频率大于预设频率阈值的数据；

基于数据的业务属性信息，对所述热点数据集中的热点数据进行分类，得到每类的目标存储数据。

在第二方面的另一种可能设计中，所述目标存储数据为客户端的页面维护数据；

相应的，所述存储模块，还用于将所述目标存储数据存储至所述数据库。

在第二方面的再一种可能设计中，所述处理模块，具体用于：

根据所述目标存储数据的业务属性信息，确定所述目标存储数据的数据类型；

根据所述目标存储数据的数据类型，确定所述目标存储数据的标识性字段和至少一个类区分度字段；

根据所述标识性字段和所述至少一个类区分度字段，确定所述目标存储数据的类型标识符，所述类型标识符作为所述键值对的键名；

确定所述目标存储数据的目标存储字段和所述目标存储字段的属性值；

确定所述目标存储字段在数据访问层的mapper映射文件中的类属性名；

根据所述类属性名和所述目标存储字段的属性值，构建所述缓存键值对的键值。

在第二方面的又一种可能设计中，所述获取模块，还用于获取数据读取请求，所述数据读取请求包括：至少一个目标键名；

所述处理模块，还用于：

根据所述至少一个目标键名，确定所述缓存中的每个目标键名对应的目标键值对；

从确定出的所有目标键值对中，获取每个目标键值对中的键值，所述键值包括：至少一个目标字段以及每个目标字段的属性值；

基于所述缓存的管道模式，反馈数据读取响应，所述数据读取响应包括：所有目标键值对中的键值。

可选的，所述存储模块，还用于将所述至少一个目标键名存入字符串数组中；

相应的，所述处理模块，还用于基于所述字符串数组中的每个目标键名，依次在所述缓存中查询，获取每个目标键名对应的键值。

第三方面，本申请提供一种服务器，包括：存储器和处理器；

所述存储器用于存储可在所述处理器上运行的计算机执行指令；

所述处理器执行所述计算机执行指令时实现如上述第一方面及各可能设计所述的方法。

可选地，上述处理器可以为芯片。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，所述计算机指令被处理器执行时用于实现如上述第一方面及各可能设计所述的方法。

第五方面，本申请提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述第一方面及各可能设计所述的方法。

本申请实施例提供的数据处理方法、装置、服务器及存储介质，通过获取目标存储数据，该目标存储数据为数据库中的数据或者客户端的页面维护数据，然后基于预设键值对构建规则，对目标存储数据进行处理，得到目标存储数据对应的缓存键值对，其中，缓存键值对的键名用于指示目标存储数据的数据类型，缓存键值对的键值为指示目标存储数据的目标存储字段和该目标存储字段的属性值，最后将该键值对存储至缓存中。该技术方案中，服务器可以基于数据自身的特性，构建了专属的键值对，便于在特定场景下从缓存中查询出符合要求的数据，其提高了在缓存中查询的命中率以及复杂场景应用的适应性，不仅避免了资源浪费，而且提高了存取效率。

附图说明

图1为本申请提供的数据处理方法所适用的应用场景示意图；

图2为本申请提供的数据处理方法实施例一的流程示意图；

图3为本申请提供的数据处理方法实施例二的流程示意图；

图4为本申请提供的数据处理方法实施例三的流程示意图；

图5为本申请提供的数据处理方法实施例的结构示意图；

图6是本申请提供的服务器实施例的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在介绍本申请的应用场景和技术方案之前，首先对本申请涉及到的部分术语进行介绍：

SSM框架：SSM框架是spring MVC，spring和mybatis框架的整合，是标准的MVC模式，将整个系统划分为表现层，controller层，service层，DAO层四层，其中，spring MVC负责请求的转发和视图管理，spring实现业务对象管理，mybatis作为数据对象的持久化引擎。具体的，Service层是业务层，专注业务逻辑，对于其中需要的数据库操作，都通过Dao层去实现；Dao是数据访问层，作用是封装对数据库的访问：增删改查，不涉及业务逻辑，只是达到按某个条件获得指定数据的要求；

Redis：完全开源的，遵守伯克利软件套件(berkeley software distribution，BSD)协议，是一个高性能的Key-value数据库

哈希数据结构：实质上是一种对数组进行了扩展的数据结构，可以说哈希表是在数组支持下标直接索引数据(value)的基础上进行优化并尽可能在常数时间内对数据进行增、删、改、查等操作

Key：用于定位查询缓存中的索引，在本申请实施例中，将其称为键值对的键名；

Value：在缓存中存储的数据，在本申请实施例中，将其称为键值对的键值；

Mapper映射文件：Mapper.xml映射文件中定义了操作数据库的结构化查询语言(structured query language，SQL)，每个SQL是一个statement，Statement是Java执行数据库操作的一个重要接口，用于在已经建立数据库连接的基础上，向数据库发送要执行的SQL语句。Statement对象，用于执行不带参数的简单SQL语句。该Mapper映射文件是mybatis框架的核心。

示例性的，Mapper映射文件的具体含义通过如下程序进行解释说明：

<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>

<！DOCTYPE mapper

PUBLIC＂-//mybatis.org//DTD Mapper 3.0//EN＂

＂http://mybatis.org//dtd/mybatis-3-mapper.dtd＂>//mybatis的DTD约束

<mapper namespace＝＂test＂>//mapper是根标签，namespace＝＂test＂是命名空间，其与ID属性组成一段sql的唯一标识

<select id＝＂selectUserList＂resultType＝＂com,qzw.bean.User＂>//select是查询操作，还有insert、update、delete；id＝＂selectUserList＂是sql语句的ID，与命名空间组成一段sql的唯一标识；resultType＝＂com,qzw.bean.User＂表示结果对应的数据类型

select*from user//sql语句

</select>

</mapper>

下述对本申请的应用场景进行解释说明：

随着互联网的发展，基于浏览器的Web类大型应用系统变得越来越普遍，伴随着业务应用场景的日趋复杂以及系统访问量、产生数据量的不断扩大，尤其是金融行业，大型商业银行客户数量和账户数量多，基本都在千万级的规模，并且金融类的数据类型复杂，有特定业务交易场景下，想要频繁的获取到一类符合特定条件的金融数据，比如，查询指定数据来源、数据种类、交易场所下的一条债券估值记录中某几个价格数据，这个时候如果直接去数据库中查询，效率会比较慢，尤其当查询请求量猛增时，响应速度将明显变慢且系统资源消耗严重。但把一整条数据记录都放入到Redis缓存中，又会浪费缓存空间，存储冗余数据且难以适应复杂场景对数据的需求。

因而，在实际应用中，需要根据金融数据的自身特性以及应用场景，构建出合适的Key，同时，选择恰当的数据结构对所需数据进行存储。因此，如何选择合适的数据结构来快速提高系统在业务场景下的响应速度以及查询缓存中数据的精确性变的尤为重要，成为一项急需要解决的问题。

由背景技术中介绍的现有技术可知，目前，数据存取方案是将待存储数据存储至数据库的同时，也会将部分数据存储至缓存，例如，在数据库中建立不同数据类型的数据表，将数据库中的频繁使用到的数据表中的一整条数据全部存储在缓存中；相应的，当业务场景需要用到某些数据时，服务器可以基于客户端的查询请求，首先将去缓存中进行查询，若缓存中不存在，再到数据库中进行查询，以获得响应数据，具体的，首先从缓存或数据库中逐一查询相应的存储数据，然后挑选出其中需要用到的字段数据。

由上述分析可知，现有技术的缺点主要有两点：

1、查询过程耗时且存在冗余数据，浪费缓存资源。

由于通常做法是将数据库中的频繁使用的数据表的一整条实体类对象(Entity)数据进行序列化成对象简谱(JSON)，然后存入到Redis中。在需要获取相关数据时，首先从缓存中查询出JSON，然后进行反序列化操作，获取整条Entity数据，再从该条Entity数据记录中获取到需要用到的字段，由此可见，该方案的弊端在于对Entity数据进行序列化操作比较耗时，由于实际应用中并不是整条数据的所有字段数据都会被使用，因而，缓存中存储了冗余数据，浪费了缓存资源，因此，依据待存储数据(例如，金融类数据)的特性，选择一种恰当的存储数据结构用以存储数据至关重要。

2、命中率低，且性能较差。

由于金融类数据种类复杂，未进行分类，统一存入到缓存中，不便于查询且会降低查询Redis的命中率。在实际应用中，金融类数据通常都会涉及到大量的专有名词，在缓存中键名(Key)的命名需要合理的规范以及明确的含义，否则在应用系统中各个模块在调用查询数据时会非常的不便。因而，在复杂的业务场景下，缓存Key的命名至关重要，假如Key的名称无法准确描述整条记录的特点，则难以准确的获取符合查询要求的金融数据，也难以充分发挥缓存读写性能的高效性。

综上所述，基于SSM框架的企业级Web应用系统，在某些特殊应用场景下，前后端数据的交互会非常频繁，在高并发环境下，大量的前端读写请求涌向数据库，对数据库会造成巨大的压力，同时整个系统的响应效率会很慢。随着应用系统的不断扩大使用，数据库中存储的数据量越来越大，与其它领域应用系统相比，互联网金融系统自身所包含的金融类数据类型繁多且业务含义难懂，以及其在业务应用场景，因此如何保证在复杂业务场景下能够快速准确的获取满足业务需求的金融数据变的更为迫切重要。

在本申请的实施例中，提供了一种数据处理方法，具体为基于Redis存储数据结构的缓存数据存取及同步处理方法，根据业务场景需求，筛选出现有数据库表中的金融热点数据，同时对这些热点数据，按照不同的类型进行分类，进而基于预设键值对构建规则，构建键值对，具体的，按照数据自身的特性，挑选出在数据库表中该条数据记录中具有明显标识意义以及区分度的字段，构建出专属的类型标签，以此作为其在Redis中存储时的Key，同时确定该类数据中需要在业务场景下被频繁使用到的字段，选用Redis中哈希数据结构作为存储对象，将该字段在持久化映射层(Dao层)mapper映射文件中的类属性名作为fileld，其对应的字段值作为Value，将整个哈希对象存入到缓存当中，业务逻辑层(service层)在处理过程中同时将数据刷入缓存当中，节省了Redis缓存的存储空间，减少了性能损耗，优化了缓存资源使用，提高了存储、以及读取效率。

可选的，下述首先对本申请技术方案的关键点进行总述：

1、根据业务场景的要求，首先对目标存储数据(金融热点数据)进行了明确的大致分类，其次结合目标存储数据自身的特性，根据预设键值对构建规则，构建了专属且具有明显标识意义的Key，能够提高在缓存中查询数据的精准性；

2、选用哈希数据结构对业务场景下的数据(例如，金融业务场景下的债券估值数据、债券评级数据、汇率信息、利率信息)具有比较强的针对性与适用性，只存储了需要用到的字段信息，去除了冗余数据，节省了Redis缓存的存储空间。

示例性的，图1为本申请提供的数据处理方法所适用的应用场景示意图。参照图1所示，该应用场景示意图可以包括：多个客户端设备(示例性的，客户端设备111和客户端设备112)、与每个客户端设备连接的服务器12、与服务器12连接的数据库13和缓存14，且数据库13和缓存14也可直接连接。

在实际应用中，客服人员可以基于用户的需求或接收终端设备的请求，通过客户端设备与服务器12进行交互，产生各种数据，例如，在金融场景下，产生的数据可以包括但不局限于债券估值数据、债券评级数据、汇率信息、利率信息等，为了后续的查询，服务器12需要将产生的各种数据存储至数据库13中，且，将部分数据存储至缓存14中。

可理解，服务器12可以直接将生成的数据存储至缓存14，也可以首先将生成的数据存储至数据库13，再将数据库中某些数据存储至缓存14，还可以同时将生成的数据存储至数据库13和缓存14中，其可以根据实际场景确定，本实施例不对其进行限定。

可选的，在本申请的实施例中，服务器12可以执行本申请的技术方案，即，服务器12获取到目标存储数据后，可以基于预设键值对构建规则，对目标存储数据进行处理，得到目标存储数据的缓存键值对，并存储至缓存中。

可选的，在本申请的实施例中，该应用场景示意图中还可以包括用户使用的终端设备，示例性的，包括：终端设备113和终端设备114。该终端设备113和终端设备114可以与某台客户端设备(例如，客户端设备111)进行通信，以实现业务办理的目的。

可以理解的是，图1示出的场景示意图仅是一种示例性说明。在实际应用中，该场景示意图上还可以包括其他设备，例如，计算机设备等，具体可以根据实际需求进行调整，本申请实施例并不对其进行限定。

在上述图1所示的场景示意图中，本申请实施例并不限定各设备的具体表现形式，例如，该客户端设备和终端设备可以是手机、平板电脑，PC终端等，此处不再一一举例说明。

可理解，在实际应用中，服务器可以执行本申请的技术方案并实现数据存储和读取的目的，本申请实施例并不对其进行限定。

下面，结合上述图1所示的场景示意图，通过具体实施例对本发明的技术方案进行详细说明。需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图2为本申请提供的数据处理方法实施例一的流程示意图。如图2所示，该数据处理方法可以包括如下步骤：

S201、获取目标存储数据，该目标存储数据为数据库中的数据或者客户端的页面维护数据。

在本申请实施例的一种可能设计中，若数据库中更新了数据，且更新的数据为使用频繁的数据，则为了后续查询方便，此时，需要将更新的数据同步存储至缓存。可理解，在该可能设计中，将需要更新至缓存的数据称为目标存储数据。

由此可知，在该可能设计中，该目标存储数据为数据库中的数据。

相应的，S201中的获取目标存储数据可以通过步骤实现：

A1、获取数据存储请求，该数据存储请求包括：业务场景标识；

可理解，在该种可能设计中，服务器执行数据存储方案可以是基于设定的周期性自动触发，也可以是基于外部的存储指令，还可以是其他方式，本实施例不对其进行限定。因而，当数据库中的数据需要更新至缓存中时，首先获取数据存储请求，该数据存储请求可以是数据库自动触发产生的，也可以是从外部获取到的，此处不作赘述。

由于后续有数据读取请求通常是在特定业务交易场景下，因而，为了简化数据维护成本，上述获取到的数据存储请求中需要包含业务场景标识。

A2、根据业务场景标识，筛选出数据库中的该业务场景标识对应的热点数据集。

其中，该热点数据集中的每条热点数据为使用频率大于预设频率阈值的数据。

在本实施例中，服务器对获取到的数据存储请求进行解析，可以得到业务场景标识，进而根据业务场景标识，即业务场景的使用需求，可以筛选出数据库中的热点数据集，且热点数据集是多条热点数据组成的集合。

可理解，热点数据集中的每条热点数据为使用频率大于预设频率阈值的数据，也即，热点数据是经常会被查询，但是不经常被修改或者删除的数据。

A3、基于数据的业务属性信息，对热点数据集中的热点数据进行分类，得到每类的目标存储数据。

可选的，对于基于业务场景标识从数据库中筛选出的热点数据集，可以按照不同的类型对其进行分类，例如，基于数据的业务属性信息进行划分，得到每类的目标存储数据。

示例性的，商业银行中的数据按照业务属性信息可以分为交易数据、客户数据、信用数据、资产数据四大类，而其中每一类数据又可以按照每类数据自身的特性细分为多类，此处不作赘述。

在本申请实施例的另一种可能设计中，目标存储数据可以是Web应用系统的前端页面维护的数据记录，称为客户端的页面维护数据。

示例性的，在基于SSM框架的Web应用系统的前端页面维护一条数据记录时，服务器(具体为业务逻辑层)在处理过程中，可以首先根据该数据记录的业务属性确定数据类型，从而得到客户端的页面维护数据。

S202、基于预设键值对构建规则，对目标存储数据进行处理，得到目标存储数据对应的缓存键值对。

其中，缓存键值对的键名用于指示目标存储数据的数据类型，缓存键值对的键值为指示目标存储数据的目标存储字段和该目标存储字段的属性值。

在实际应用中，Redis(缓存)是一个开源、支持网络、基于内存、可选持久性的键值对存储数据库，因而，将目标存储数据存储至缓存时，首先需要构建键值对。

可选的，服务器中可以存储有预设键值对构建规则，在本实施例中，预设键值对构建规则用于指示键名的构建方式以及键值的构建方式。因而，服务器在获取到目标存储数据后，便可以基于该预设键值对构建规则，对目标存储数据进行处理，分别构建目标存储数据对应的键名和键值。

具体的，可以根据预设键值对构建规则，构建出目标存储数据对应的Key，其次，从目标存储数据中挑选出需要存储的目标存储字段及其属性值，将其作为Key的键值value。

关于键值对的具体实现可以参见下述图3所示实施例中的记载，此处不作赘述。

S203、将该键值对存储至缓存中。

在本步骤中，当服务器确定出键值对后，便可以将键值对存储至缓存。

可理解，当目标存储数据为客户端的页面维护数据时，为了保证数据库和缓存中的数据一致，服务器同时还需要将目标存储数据存储至数据库。即，在目标存储数据存入数据库的同时，便可以将目标存储数据对应的键值对存储至缓存中。

本申请实施例提供的数据处理方法，通过获取目标存储数据，该目标存储数据为数据库中的数据或者客户端的页面维护数据，然后基于预设键值对构建规则，对目标存储数据进行处理，得到目标存储数据对应的缓存键值对，其中，缓存键值对的键名用于指示目标存储数据的数据类型，缓存键值对的键值为指示目标存储数据的目标存储字段和该目标存储字段的属性值，最后将该键值对存储至缓存中。该技术方案中，服务器可以基于数据自身的特性，构建了专属的键值对，便于在特定场景下从缓存中查询出符合要求的数据，其提高了在缓存中查询的命中率以及复杂场景应用的适应性，不仅避免了资源浪费，而且提高了存取效率。

示例性的，在上述实施例的基础上，图3为本申请提供的数据处理方法实施例二的流程示意图。如图3所示，上述S202可以通过如下步骤实现：

S301、根据目标存储数据的业务属性信息，确定目标存储数据的数据类型。

可选的，为了提高复杂应用场景的适用性，在本申请的实施例中，基于业务场景执行数据存储，因而，在获取到目标存储数据时，可以首先确定目标存储数据的业务属性信息，然后基于该业务属性信息，确定出目标存储数据的数据类型，进而根据目标存储数据的数据类型和目标存储数据，构建缓存键值对的键名。

S302、根据目标存储数据的数据类型，确定目标存储数据的标识性字段和至少一个类区分度字段。

可选的，目标存储数据是以数据表的形式存在的，因而，服务器可以挑选出目标存储数据对应数据表中的具有标识性的字段A以及具有区分不同类数据的至少一个字段B，具体为：目标存储数据的标识性字段和至少一个类区分度字段。

S303、根据该标识性字段和所述至少一个类区分度字段，确定目标存储数据的类型标识符，该类型标识符作为上述键值对的键名。

在本实施例中，为了构建出目标存储数据专属的键值对，可以将确定的标识性字段和至少一个类区分度字段进行结合，构建出类型标识符，以此作为该条目标存储数据专属的Key(键名)。

例如，在目标存储数据的标识性字段为A和至少一个类区分度字段为B时，构建出类型标识符A_B，并将该类型标识符A_B作为该条目标存储数据的Key。

可理解，由于目标存储数据中具有区分度的字段可能有多个，这时，构建类型标识符时需携带所有的区分度字段。

S304、确定目标存储数据的目标存储字段和该目标存储字段的属性值。

可选的，在本实施例中，服务器根据目标存储数据的数据类型，确定目标存储数据的标识性字段和至少一个类区分度字段的同时，还可以确定出目标存储数据中需要被频繁使用到的字段，在本实施例中，将其称为目标存储字段。因而，服务器可以根据目标存储数据的目标存储字段和目标存储字段的属性值，构建缓存键值对的键值。

S305、确定目标存储字段在数据访问层的mapper映射文件中的类属性名。

在本实施例中，可以选用Redis中哈希数据结构作为存储对象，即缓存键值对的键值，这时，将目标存储数据存储至缓存中时，确定出所要存入缓存(Redis)中的目标存储字段在Dao层(数据访问层)的mapper映射文件中的类属性名，将其作为fileld，其对应的字段值作为Value。

S306、根据该类属性名和目标存储字段的属性值，构建缓存键值对的键值。

可选的，在确定出类属性名和目标存储字段的属性值后，便可以构建缓存键值对的键值。具体的，键值(存储对象)的存储结构为{“fileld”：该目标存储字段在mapper映射文件中的属性名，“value”:该目标存储字段对应的属性值}。

基于上述S303确定的键名和S306确定的键值，可以生成目标存储数据对应的键值对。具体的，键值对在Redis中的表现形式为键值对Key:Map：{构建出的专属Key：{“fileld”：该目标存储字段在映射文件中的属性名，“value”:该目标存储字段对应的属性值}}。

由上述分析可知，本申请的技术方案与现有技术的区别在于：键值对中键名的命名规则不同，下述进行解释说明。

示例性的，现有的存储形式中，键值对中的键名(Key)基本不具备标识性，只是大致分类，例如，{INFRA:MD}:marketdatadefinition:main，键值对中的value为对Entity实例对象序列化后的JSON。

在本申请的技术方案中，键值对中的Key：对目标存储数据的类型以及特性具有明显的标识意义，根据本申请实施例中的预设键值对构建规则构建出Key，例如，{INFRA:MD}:currency:valuation010011_IB_CBOND_1，键值对中的value为目标存储字段的属性值。

本申请实施例提供的数据处理方法，根据目标存储数据的业务属性信息，确定目标存储数据的数据类型，进而确定目标存储数据的标识性字段和至少一个类区分度字段，从而构建出目标存储数据的类型标识符，即键值对的键名，进一步的，确定出目标存储数据的目标存储字段和该目标存储字段的属性值，根据目标存储字段在数据访问层的mapper映射文件中的类属性名和该目标存储字段的属性值，构建缓存键值对的键值。该技术方案中，通过根据目标存储数据自身的属性信息，构建了键值对的键名和键值，由于该键名是专属且具有明显标识意义的键名，提高了其在缓存中的查询精准性。

示例性的，在上述实施例的基础上，图4为本申请提供的数据处理方法实施例三的流程示意图。如图4所示，在本实施例中，该数据处理方法还可以包括如下步骤：

S401、获取数据读取请求，该数据读取请求包括：至少一个目标键名。

在本申请的实施例中，当客户端需要查询多个目标数据时，可以向服务器发送数据读取请求，并将多个目标数据对应的至少一个目标键名携带在数据读取请求中，以便为后续的数据查询提供索引信息。

S402、根据上述至少一个目标键名，确定缓存中的每个目标键名对应的目标键值对。

可选的，在本实施例中，服务器可以根据数据读取请求中的每个目标键名，在缓存中进行查询，定位出每个目标键名对应的目标键值对。

S403、从确定出的所有目标键值对中，获取每个目标键值对中的键值。

其中，该键值包括：至少一个目标字段以及每个目标字段的属性值。

可选的，针对在缓存中确定的所有目标键值对，可以从每个目标键值对中确定出对应的键值，从而确定出每个目标键名对应的至少一个目标字段以及每个目标字段的属性值。

S404、基于缓存的管道模式，反馈数据读取响应，该数据读取响应包括：所有目标键值对中的键值。

在本申请的实施例中，服务器未响应时，可以继续接收客户端发送的数据读取请求，但针对每个数据读取请求，会在所有的目标键名对应的键值确定后，再最终一次性反馈每个数据读取请求对应的响应数据，这个属性即是Redis的管道模式，其显著的提高了redis服务的性能。

示例性的，在本申请的实施例中，在上述S402之前，服务器还可以将数据读取请求中的至少一个目标键名存入字符串数组中，相应的，S402具体可以通过如下步骤实现：

基于字符串数组中的每个目标键名，依次在该缓存中查询，获取每个目标键名对应的键值。

在本实施例中，例如，在查询某个类型的金融数据时，例如，数据读取请求包括一个目标键名，即查询单条数据时，则采用Redis的事务的方式，一次性、按顺序地执行多个命令，且在事务执行过程期间，服务器可以不中断事务去执行其它客户端指令。

示例性的，在数据读取请求包括多个目标键名，即查询多条数据时，可以将多个目标键名统一存入字符串数组中，采用Redis的管道模式(PipeLine)批量查询出缓存中与之对应的Value，可理解，在客户端设备没有读取到旧请求的响应之前，服务器依然可以接收新请求的指令，针对每个请求，服务器可以一次性反馈响应结果，即，一次性反馈所有Key对应的Value，减少了数据往返传输所带来的时间成本，提高了Redis服务器的可执行操作效率。

本申请实施例提供的数据处理方法，通过获取数据读取请求，该数据读取请求包括：至少一个目标键名，根据至少一个目标键名，确定该缓存中的每个目标键名对应的目标键值对，然后从确定出的所有目标键值对中，获取每个目标键值对中的键值，最后基于缓存的管道模式，反馈数据读取响应，该数据读取响应包括：所有目标键值对中的键值。该技术方案中，服务器可以采用Redis的事务方式，一次性、按顺序地执行多个命令，并一次性反馈所有Key对应的Value，减少了数据往返传输所带来的时间成本，提高了Redis服务器的可执行操作效率。

下述通过金融场景的两个具体实施例对本申请的技术方案进行解释说明。

可理解，在本申请的实施例中，下述两个实施例的目的是提高金融类数据在缓存中的存取效率以及在一定程度上解决缓存与数据库之间数据一致性的问题。具体实现方案如下：

具体实施例一：

1、以资产数据中债券估值为例，一支债券，可细分为本币债券、外币债券；债券代码是每支债券必备的字段，记为A，具有明显的标识意义，但对于本币债券而言，无法单通过债券代码来锁定唯一一条本币债券估值信息，但债券代码与流通场所则可以确定唯一一条本币债券估值信息，因此，流通场所字段即具有区分不同类数据的特性，记为B，数据来源字段也是能够对不同的债券估值数据进行区分，记为C，构建出类型标识符A_B_C，以此作为该条债券在缓存中存储的Key。

2、依据实际金融业务场景，一条本币债券估值数据中被频繁使用到的字段数据是日间估价全价、估价净价、估价修正久期、估价基点价值；一条外币债券估值数据中被频繁使用到的字段数据是到期收益率、行权收益率。

3、选用Redis中哈希数据结构作为存储对象，最终生成在Redis的键值对Key:Map为{构建出的专属Key：{“fileld”：该字段在映射文件中的属性名，“value”:该字段对应的属性值}}，将整个哈希对象(Key:Map)存入到缓存中。

4、当在应用系统的前端页面录入一整条债券估值数据记录时，按照Key的命名规则，组合构建出一个Key，挑选出其中需要存入缓存的字段，在数据入库的同时将其刷入缓存当中，同时，假如通过前端页面删除、修改一条数据，也会对缓存进行同步的操作；

经过实际验证，依据本申请中提供的缓存存取方式，有效的提高了缓存中热点数据的查询效率以及命中率，优化了缓存资源使用，有效去除了冗余数据，且在一定程度上维护了数据库与缓存之间的一致性。

具体实施例二：

1、以资产数据中汇率数据为例，一支货币对的汇率信息，分为三种即期、掉期、远期，货币对的基准货币与非基准货币就是每条汇率信息必备的字段，记为A，具有明显的标识意义，而报价类型字段则分为即期、掉期、远期，则可认定报价类型字段具有区分不同类数据的特性，记为B，由此构建出类型标识符A_B，以此作为该条债券在缓存中存储的Key。

2、依据实际金融业务场景，一条即期汇率数据中被频繁使用到的字段数据是即期汇率买入价、卖出价、中间价；一条远期汇率数据中被频繁使用到的字段数据是远期汇率中间价、汇率期限类型。

3、选用Redis中哈希数据结构作为存储对象，最终生成在Redis的键值对Key:Map为{构建出的专属Key：{“fileld”：该字段在映射文件中的属性名，“value”:该字段对应的属性值}}，将整个哈希对象(Key:Map)存入到缓存中。

4、当在应用系统的前端页面录入一整条汇率数据记录时，按照Key的命名规则，组合构建出一个Key，挑选出其中需要存入缓存的字段，在数据入库的同时将其刷入缓存当中，同时假如通过前端页面删除、修改一条数据，也会对缓存进行同步的操作。

由上述各实施例可知，本申请的技术方案具有如下优点：省去了Java的序列化与反序列化操作，提高了存储、以及查询效率，节省了Redis缓存的存储空间，只存需要用到的信息，去除了冗余数据，同时易于维护存储数据，只需要针对Map中的键值对进行操作即可，简化了后续的维护流程，根据业务场景，对热点数据进行了分类，结合数据自身的特性，构建了专属的Key，便于在特定场景下从缓存中查询符合要求的数据，提高了缓存的命中率以及复杂场景应用的适应性。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图5为本申请提供的数据处理方法实施例的结构示意图。如图5所示，该数据处理装置可以包括：

获取模块501，用于获取目标存储数据，所述目标存储数据为数据库中的数据或者客户端的页面维护数据；

处理模块502，用于基于预设键值对构建规则，对所述目标存储数据进行处理，得到所述目标存储数据对应的缓存键值对，所述缓存键值对的键名用于指示所述目标存储数据的数据类型，所述缓存键值对的键值为指示所述目标存储数据的目标存储字段和所述目标存储字段的属性值；

存储模块503，用于将所述键值对存储至缓存中。

作为一种示例，所述目标存储数据为数据库中的数据；

相应的，所述获取模块501，具体用于：

获取数据存储请求，所述数据存储请求包括：业务场景标识；

根据所述业务场景标识，筛选出所述数据库中的所述业务场景标识对应的热点数据集，所述热点数据集中的每条热点数据为使用频率大于预设频率阈值的数据；

基于数据的业务属性信息，对所述热点数据集中的热点数据进行分类，得到每类的目标存储数据。

作为另一种示例，所述目标存储数据为客户端的页面维护数据；

相应的，所述存储模块503，还用于将所述目标存储数据存储至所述数据库。

在本申请实施例的一种可能设计中，所述处理模块502，具体用于：

根据所述目标存储数据的业务属性信息，确定所述目标存储数据的数据类型；

根据所述目标存储数据的数据类型，确定所述目标存储数据的标识性字段和至少一个类区分度字段；

根据所述标识性字段和所述至少一个类区分度字段，确定所述目标存储数据的类型标识符，所述类型标识符作为所述键值对的键名；

确定所述目标存储数据的目标存储字段和所述目标存储字段的属性值；

确定所述目标存储字段在数据访问层的mapper映射文件中的类属性名；

根据所述类属性名和所述目标存储字段的属性值，构建所述缓存键值对的键值。

在本申请实施例的另一种可能设计中，所述获取模块501，还用于获取数据读取请求，所述数据读取请求包括：至少一个目标键名；

所述处理模块502，还用于：

根据所述至少一个目标键名，确定所述缓存中的每个目标键名对应的目标键值对；

从确定出的所有目标键值对中，获取每个目标键值对中的键值，所述键值包括：至少一个目标字段以及每个目标字段的属性值；

基于所述缓存的管道模式，反馈数据读取响应，所述数据读取响应包括：所有目标键值对中的键值。

可选的，所述存储模块503，还用于将所述至少一个目标键名存入字符串数组中；

相应的，所述处理模块502，还用于基于所述字符串数组中的每个目标键名，依次在所述缓存中查询，获取每个目标键名对应的键值。

本申请实施例提供的装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，在此不再赘述。

需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(application specific integrated circuit，ASIC)，或，一个或多个微处理器(digital signal processor，DSP)，或，一个或者多个现场可编程门阵列(field programmable gate array，FPGA)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(centralprocessing unit，CPU)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，SOC)的形式实现。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘solid state disk(SSD))等。

图6是本申请提供的服务器实施例的结构示意图。如图6所示，该服务器可以包括：处理器601和存储器602。

其中，存储器602用于存储计算机程序，处理器601用于执行该计算机程序以实现如上述方法实施例的技术方案。

可选的，该服务器还可以包括：通信接口603和系统总线604，存储器602和通信接口603通过系统总线604与处理器601连接并完成相互间的通信，通信接口603用于和其他设备进行通信。

可选的，处理器601可以是通用处理器，包括中央处理器CPU、网络处理器(networkprocessor，NP)等；还可以是数字信号处理器DSP、专用集成电路ASIC、现场可编程门阵列FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

存储器602可能包含随机存取存储器(random access memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

通信接口603具体可以通过收发器实现。通信接口用于实现数据库访问装置与其他设备(例如客户端、读写库和只读库)之间的通信。

系统总线604可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选的，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，所述计算机指令被处理器执行时用于实现上述方法实施例的技术方案。

可选的，本申请实施例还提供一种运行指令的芯片，所述芯片用于执行上述方法实施例的技术方案。

本申请实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序存储在计算机可读存储介质中，至少一个处理器可以从所述计算机可读存储介质中读取所述计算机程序，所述至少一个处理器执行所述计算机程序时可实现上述方法实施例的技术方案。

本申请中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。在本申请的实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请的实施例的实施过程构成任何限定。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (10)

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

获取目标存储数据，所述目标存储数据为数据库中的数据或者客户端的页面维护数据；

基于预设键值对构建规则，对所述目标存储数据进行处理，得到所述目标存储数据对应的缓存键值对，所述缓存键值对的键名用于指示所述目标存储数据的数据类型，所述缓存键值对的键值为指示所述目标存储数据的目标存储字段和所述目标存储字段的属性值；

将所述键值对存储至缓存中。

2.根据权利要求1所述的方法，其特征在于，所述目标存储数据为数据库中的数据；

相应的，所述获取目标存储数据，包括：

获取数据存储请求，所述数据存储请求包括：业务场景标识；

根据所述业务场景标识，筛选出所述数据库中的所述业务场景标识对应的热点数据集，所述热点数据集中的每条热点数据为使用频率大于预设频率阈值的数据；

基于数据的业务属性信息，对所述热点数据集中的热点数据进行分类，得到每类的目标存储数据。

3.根据权利要求1所述的方法，其特征在于，所述目标存储数据为客户端的页面维护数据；

相应的，所述方法还包括：

将所述目标存储数据存储至所述数据库。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述基于预设键值对构建规则，对所述目标存储数据进行处理，得到所述目标存储数据对应的缓存键值对，包括：

根据所述目标存储数据的业务属性信息，确定所述目标存储数据的数据类型；

根据所述目标存储数据的数据类型，确定所述目标存储数据的标识性字段和至少一个类区分度字段；

根据所述标识性字段和所述至少一个类区分度字段，确定所述目标存储数据的类型标识符，所述类型标识符作为所述键值对的键名；

确定所述目标存储数据的目标存储字段和所述目标存储字段的属性值；

确定所述目标存储字段在数据访问层的mapper映射文件中的类属性名；

根据所述类属性名和所述目标存储字段的属性值，构建所述缓存键值对的键值。

5.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

获取数据读取请求，所述数据读取请求包括：至少一个目标键名；

根据所述至少一个目标键名，确定所述缓存中的每个目标键名对应的目标键值对；

从确定出的所有目标键值对中，获取每个目标键值对中的键值，所述键值包括：至少一个目标字段以及每个目标字段的属性值；

基于所述缓存的管道模式，反馈数据读取响应，所述数据读取响应包括：所有目标键值对中的键值。

6.根据权利要求5所述的方法，其特征在于，在所述根据所述至少一个目标键名，确定所述缓存中的每个目标键名对应的目标键值对之前，所述方法还包括：

将所述至少一个目标键名存入字符串数组中；

相应的，所述根据所述至少一个目标键名，确定所述缓存中的每个目标键名对应的目标键值对，包括：

基于所述字符串数组中的每个目标键名，依次在所述缓存中查询，获取每个目标键名对应的键值。

7.一种数据处理装置，其特征在于，包括：

获取模块，用于获取目标存储数据，所述目标存储数据为数据库中的数据或者客户端的页面维护数据；

处理模块，用于基于预设键值对构建规则，对所述目标存储数据进行处理，得到所述目标存储数据对应的缓存键值对，所述缓存键值对的键名用于指示所述目标存储数据的数据类型，所述缓存键值对的键值为指示所述目标存储数据的目标存储字段和所述目标存储字段的属性值；

存储模块，用于将所述键值对存储至缓存中。

8.一种服务器，其特征在于，包括：存储器和处理器；

所述存储器用于存储可在所述处理器上运行的计算机执行指令；

所述处理器执行所述计算机执行指令时实现如上述权利要求1至6任一项所述的方法。

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

10.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现上述权利要求1至6任一项所述的方法。

Images