CN116414843A - 一种数据更新方法及装置 - Google Patents

Abstract

本申请提供一种数据更新方法及装置，该方法可应用于数据库系统。在该方法中接收数据更新请求消息，该数据更新请求消息中包括待更新的数据，然后根据缓存规则在缓存中确定与待更新的数据相关联的数据对象，最后更新缓存中与待更新的数据相关联的数据对象。这样在下次进行数据查询时能够从缓存中找到最新数据，能够提升数据查询效率，并且减少开发人员的工作量。如果缓存中不存在与待更新的数据相关联的数据对象的查询记录，则更新数据库，这样在下次进行数据查询时可以从数据库中查询数据，并将查询结果重新保存在缓存中，进而保证数据库中的数据与缓存中的数据的一致性，提升用户体验。

Description

一种数据更新方法及装置

技术领域

本申请涉及互联网技术领域，尤其涉及一种数据更新方法及装置。

背景技术

通常，数据库数据都是保存在磁盘中，但磁盘的访问速度相比内存慢很多，并且磁盘占用、消耗的资源也较多，因此，在数据库缓存技术中可将经常被查询的数据存储在内存中，这样可更快的返回数据访问的结果，为应用提供了良好的访问速度。

但数据库服务器所在的计算机上的内存一般是有限的，不能完全满足数据缓存的需要，此时一般需要外接专用的缓存服务来扩展缓存数据的容量。

为了确保从缓存服务中查询到的数据是最新的，需要保证缓存服务中的数据与数据库中的数据是一致的。目前，如果要在数据库的数据发生变更的同时修改缓存服务中的数据，就需要开发人员编写大量代码在数据库中查找到相应数据，然后修改缓存服务中相应的数据，这种方式需要开发人员投入大量的时间，增加了开发与测试工作量，且开发效率不高。

发明内容

本申请提供一种数据更新方法及装置，用以实现数据库数据和缓存服务中数据的一致性，提升开发效率，并且能够提升数据查询效率。

第一方面，本申请提供一种数据更新方法，该方法包括：接收数据更新请求消息，该数据更新请求消息中包括待更新的数据；待更新的数据包括待更新的数据对象和/或待更新的关系对象，所述关系对象为不同的数据对象之间的关联关系；然后，根据缓存规则在缓存中确定与待更新的数据对象和/或待更新的关系对象相关联的数据对象，所述缓存规则用于表征不同数据对象之间的关联关系以及每一个数据对象在数据查询场景所对应的角色；最后，更新所述缓存中与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象。

通过上述技术方案，可根据缓存规则找到与待更新的数据相关联的数据对象，然后在缓存中对相关联的数据对象进行更新，从而在下次进行数据查询时能够从缓存中获取到最新数据。这种方式在数据发生变更时无需开发人员编写大量代码去查询数据库，能够自动维护数据库与缓存服务中数据的一致性，减少开发人员的工作量，并且能够提升数据查询效率，提升用户体验。

在一种可能的实现中，根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象，包括：

若所述待更新的数据为所述关系对象，则根据缓存规则确定与所述关系对象相关联的数据对象为第一数据对象，所述第一数据对象为所述缓存规则中角色为输入对象的数据对象。

通过上述技术方案，当更新数据对象之间的关系时，可根据缓存规则找到相关联的数据对象为作为输入对象的数据对象，这样当数据象之间的嵌套关系较多时，无需去数据库反复查询获取结果，直接根据缓存该规则就可以找到相关联的数据，能够提升数据查询效率。

在一种可能的实现中，所述数据更新请求消息中还包括待更新的数据的更新类型，所述数据的更新类型包括新增、删除、修改中的至少一种。

在一种可能的实现中，所述根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象，包括：

若所述待更新的数据为数据对象，且所述数据对象的更新类型为删除类型时，则根据缓存规则确定与所述数据对象相关联的数据对象为第一数据对象，所述第一数据对象为所述缓存规则中角色为输入对象的数据对象。

通过上述技术方案，当删除数据对象时，可根据缓存规则在缓存中找到相关联的数据，并删除缓存中相关联的数据，这样在下次进行数据查询时，可从数据库查询到结果重新建立缓存，实现数据库与缓存服务中数据的一致性。

在一种可能的实现中，所述根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象，包括：

若所述待更新的数据为第一数据对象，且所述第一数据对象的更新类型为修改类型时，则根据缓存规则确定与所述第一数据对象相关联的数据对象为第二数据对象，所述第二数据对象为所述缓存规则中除去所述第一数据对象之外的数据对象，所述第一数据对象为所述缓存规则中角色为输出对象的数据对象。

通过上述技术方案，当需要修改数据对象且该数据对象为缓存规则中作为输出对象的数据对象时，可根据缓存规则找到相关联的其它数据对象。

在一种可能的实现中，所述缓存规则包括：用户预先根据至少一个数据查询场景定义的规则，和/或应用学习到的查询场景，并根据学习到的查询场景定义的规则。

通过上述技术方案，用户可根据不同的数据查询场景定义不同的缓存规则，这样在嵌套关系较多的场景下，可通过缓存规则找到所有相关联的数据，能够提升查询效率。应用也可以学习查询场景，自动生成缓存规则，比如可针对用户经常查询的场景自动定义缓存规则，无需用户单独去编写缓存规则，能够提升用户体验。

第二方面，本申请提供一种数据更新装置，该装置包括：接收单元，用于接收数据更新请求消息，所述数据更新请求消息中包括待更新的数据；所述待更新的数据包括待更新的数据对象和/或待更新的关系对象，所述关系对象为不同的数据对象之间的关联关系；确定单元，用于根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象，所述缓存规则用于表征不同数据对象之间的关联关系以及每一个数据对象在数据查询场景所对应的角色；更新单元，用于更新所述缓存中与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象。

在一种可能的实现中，所述确定单元具体用于按如下方式根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象：

若所述待更新的数据为所述关系对象，则根据缓存规则确定与所述关系对象相关联的数据对象为第一数据对象，所述第一数据对象为所述缓存规则中角色为输入对象的数据对象。

在一种可能的实现中，所述数据更新请求消息中还包括待更新的数据的更新类型，所述数据的更新类型包括新增、删除、修改中的至少一种。

在一种可能的实现中，所述确定单元具体用于按如下方式根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象：

若所述待更新的数据为数据对象，且所述数据对象的更新类型为删除类型时，则根据缓存规则确定与所述数据对象相关联的数据对象为第一数据对象，所述第一数据对象为所述缓存规则中角色为输入对象的数据对象。

在一种可能的实现中，所述确定单元具体用于按如下方式根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象：

若所述待更新的数据为第一数据对象，且所述第一数据对象的更新类型为修改类型时，则根据缓存规则确定与所述第一数据对象相关联的数据对象为第二数据对象，所述第二数据对象为所述缓存规则中除去所述第一数据对象之外的数据对象，所述第一数据对象为所述缓存规则中角色为输出对象的数据对象。

在一种可能的实现中，所述缓存规则包括：

用户预先根据至少一个数据查询场景定义的规则，和/或应用学习到的查询场景，并根据学习到的查询场景定义的规则。

第三方面，本申请提供一种数据更新设备，该设备具有实现第一方面或第一方面任一种可能实现方式中的方法的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。

所述设备包括：存储器和处理器；所述存储器，用于存储有计算机指令；所述处理器用于执行所述存储器所存储的计算机指令，以使所述设备执行上述第一方面或第一方面任一种可能实现方式中所述的方法。

第四方面，本申请还提供一种计算机可读存储介质，所述存储介质存储有计算机指令，当所述计算机指令被计算机执行时，使得所述计算机执行上述第一方面或第一方面任一种可能实现方式中所述的方法。

第五方面，本申请还提供一种计算机程序产品，所述计算机程序产品包括计算机指令，当所述计算机指令被计算机执行时，使得所述计算机执行上述第一方面或第一方面任一种可能实现方式中所述的方法。

关于第二方面至第五方面各种实施方式所带来的技术效果，可以参考对于第一方面或第一方面的各种实施方式的技术效果的介绍，在此处不作过多赘述。

附图说明

图1为本申请实施例提供的一种应用场景示意图；

图2A为本申请实施例提供的一种系统架构图；

图2B为本申请实施例提供的一种系统框架示意图；

图3为本申请实施例提供的一种数据更新方法流程图；

图4为本申请实施例提供的一种数据对象之间的对应关系示意图；

图5为本申请实施例提供的一种数据对象与关系对象的示意图；

图6为本申请实施例提供的一种数据更新装置的结构示意图；

图7为本申请实施例提供的一种数据更新设备的结构示意图。

具体实施方式

下面将结合附图对本实施例的实施方式进行详细描述。

当数据存储在缓存中时，可直接在缓存中进行数据查询，相比于从数据库查询的方式可缩短数据查询的时间，更快的得到数据查询的结果。在一些场景下，需要保证缓存中的数据与数据库中的数据一致，但是，当数据库中的数据发生变更时，就需要对缓存中的数据进行更新，这样才能在进行数据查询时查询到最新、最准确的数据。目前，可通过如下两种方式更新缓存中的数据：

方式1：为缓存数据设置生存时间值(time to live，TTL)，当TTL到期时，自动删除缓存数据。当缓存中数据不存在时，从数据库中获取查询结果的同时，将该结果写入到缓存中。

在方式1中，如果TTL到期将缓存中的数据删除，可能会使得在进行数据查询时查询不到相应的数据，使得数据查询的命中率降低。

方式2：开发人员编写大量代码以在数据库的数据发生变更的同时修改缓存中对应的数据，但这种方式需要开发人员投入大量的时间，增加了开发与测试工作量，且开发效率不高。

有鉴于此，本申请实施例提供一种数据更新方法，通过将存储在数据库中的数据对象及数据对象之间的关系按照预定义的规则存储在缓存中，当数据对象和/或数据对象之间的关系发生变化时，根据数据对象之间的关系找到相关联的数据，并在缓存中更新(比如，删除)相关联的数据，然后再变更数据库，这样在下次进行数据查询时可重新根据数据库中的数据在缓存中建立对应的数据，以维护缓存与数据库的中存储数据的一致性。通过本申请实施例的方法，无需开发人员额外写代码以查找变更的数据，能够减少开发人员的工作量，并且能够提高数据查询的准确率。

需要说明的是，本申请可适用于以微服务部署，对关系型数据库强依赖，数据库读高并发的场景，能够提升系统的响应速度和可用性。

图1所示为本申请实施例提供的一种应用场景示意图。参阅图1所示，该场景可包括应用服务器11、数据库服务器12、缓存服务器13。其中，应用服务器11可以是终端上安装的网络应用程序对应的后台服务器，数据库服务器12可以是用来存储网络应用程序产生的网络业务数据的服务器。缓存服务器13可以用来存储用户通过数据库服务器查询的数据的查询记录。并且，应用服务器11可通过网络与数据库服务器12进行通信，缓存服务器13可通过网络与数据库服务器12建立通信连接。

如图2A所示，为本申请实施例提供的一种系统架构图，参阅图2A所示，可包括应用程序(application，APP)、数据库(data base，DB)、缓存。其中，数据库中可存储数据，缓存中可存储数据库中的数据对象及数据对象之间的关系。APP可包括拦截器，该拦截器可用于在用户发起数据更新请求时，拦截应用对数据库的变更操作。应理解，在实际产品实现时，该拦截器可以为应用中的一个插件。

在一些实施例中，当用户发起数据查询请求时，应用先在缓存中查询是否存在所需数据，若缓存中存在用户所需的数据，则直接返回查询结果给应用。若缓存中不存在所需数据，则应用从数据库中获取查询结果，并将查询结果保存在缓存中。

在一些实施例中，当用户发起数据更新请求时，应用可接收到数据变更请求，该变更请求中可携带数据变更的内容，然后应用可根据缓存规则找到缓存中相关联的数据，并更新，比如删除缓存中与数据变更相关联的数据。然后，应用可在更新缓存中的相关联数据之后对数据库中的数据进行变更，这样在进行数据查询时，可从数据库中进行查询，并将查询结果保存在缓存中，以保证缓存中的数据与数据库中的数据一致。

在另一些实施例中，当用户发起数据更新请求时，应用可接收到数据变更请求，该变更请求中可携带数据变更的内容，然后应用可根据数据变更请求修改数据库，修改完成之后可拦截修改结果，即不反馈给用户，接着，应用再根据修改结果找到缓存中相关联的数据，并更新，比如删除缓存中与数据变更相关联的数据。这样在进行数据查询时，可从数据库中进行查询，并将查询结果保存在缓存中，从而保证缓存中的数据与数据库中的数据一致。

图2B所示为本申请实施例提供的一种系统框架示意图，如图2B所示，该系统框架可包括应用、关系数据库和缓存服务。其中，应用中的应用程序接口(applicationprogramming interface，API)接入层提供给外部使用的接口API，开发人员可通过这些本地API接口来操纵数据库。

应用中的数据操作层负责结构化查询语言(structured query language，SQL)查找、解析、执行和执行结果映射等，主要用于根据调用的请求完成一次数据库操作。自动缓存管理拦截器可位于数据操作层，用来拦截对数据库的变更操作。

在申请实施例中可以使用如下两种拦截技术。应理解，也可以使用其它的拦截技术，对此不作限定。

1、MyBatis：MyBatis是一个Java持久化框架，它通过XML描述符或注解把对象与存储过程或SQL语句关联起来，映射成数据库内对应的纪录。MyBatis允许在映射过程中的某一点进行拦截，使开发者可以在拦截点的前后执行其他操作或阻止其执行。

2、JPA：JAVA持久化API，为关系型数据库管理系统提供持久化特性，为Java程序开发人员提供了一个对象关系映射工具，使用Java领域模型来管理关系型数据库。JPA提供了从会话回调应用程序的机制，这种回调机制可以允许应用程序在持久化对象被保存、更新、删除或是加载之前，检查或修改其属性。

数据操作层可对数据驱动层执行透传、拦截、主动操作等，数据驱动层可以从关系数据库中获取数据，数据操作层可从缓存驱动层读取缓存，缓存驱动层可以从缓存服务中获取缓存。

以下结合方法流程图对本申请实施例的数据更新方法进行详细介绍。如图3所示，为本申请实施例提供的一种数据更新方法流程图，参阅图3所示，该方法可包括如下步骤：

S301、应用服务器接收数据更新请求消息。

其中，数据更新请求消息中可包括待更新的数据，该数据可以为数据对象(dataobject，DO)和/或关系对象(relation object，RO)。即数据更新可包括对DO的更新和/或RO的更新，具体可包括对数据对象和/或关系对象的新增、删除和修改。RO可以为不同的DO之间的引用关系，该引用关系可以为一对多的引用关系，也可以为多对多的引用关系。应理解，在本申请实施例中引用关系也可以称为：对应关系、关联关系。

需要说明的是，DO在数据库中可以对应一张描述实体对象的表，表的唯一ID为表的主键。主键可以唯一确定表中的一行数据，或者可以唯一确定一个实体。并且，主键可以被外键引用，外键用于与另一张表建立关联。

下面以实际场景为例介绍数据库中的一对多引用关系和多对多引用关系。示例性的，假设某工厂使用由以下四类数据对象，比如客户(customer)、订单(order)、商品(product)和原料(material)组成的系统，这四类数据对象之间的对应关系可参阅图4所示。

第一种对应关系：一对多的对应关系

从图4中可以看出，每个客户可以有多个销售订单，即客户(customer)和订单(order)之间为一对多的关系。示例性的，如下所示，假设表1为客户对应的表格，表2为订单对应的表格，表3为客户和订单之间的关系表。

表1客户表

字段名	字段类型	字段说明
			id	INT	客户ID
name	VARchar	客户名

表2订单表

字段名	字段类型	字段说明
			id	INT	订单ID
create_time	TIMESTAMP	订单创建时间

表3客户-订单关系表

字段名	字段类型	字段说明
			customer_id	INT	客户ID
order_id	INT	订单ID

其中，表3中的customer_id字段对应表1的id字段，order_id字段对应表2的id字段。

作为一种示例，客户和订单之间的关系可以参阅如下定义的规则：

应理解，在上述定义的规则中，关系名称为客户和订单之间的关系，关系类型为一对多的关系，且客户为“一对多”关系中的“一”，订单为“一对多”关系中的“多”。

在另一些实施例中，对于一对多对应关系中也可以不建立对应的关系表，即可以不建立表3所示的关系表，比如可以在“一对多”的关系中“多”的一侧的数据表中添加“一”的一侧的主键作为外键属性，例如下述表4所示。

表4订单表

字段名	字段类型	字段说明
			id	INT	订单ID
create_time	TIMESTAMP	订单创建时间
			Customer_id	INT	客户ID

第二种对应关系：多对多的对应关系

示例1：还是以图4为例，每个订单中可以包含多种商品，每种商品也可以放在不同的订单里面，因此，订单和商品之间存在多对多的引用关系。示例性的，如下所示，假设表5为商品对应的表格，表6为订单和商品之间的关系表。

表5商品表

字段名	字段类型	字段说明
			id	INT	商品ID
name	VARchar	商品名

表6订单-商品关系表

字段名	字段类型	字段说明
			order_id	INT	订单ID
product_id	INT	商品ID

其中，表6中的order_id字段对应表2的id字段，product_id字段对应表5的id字段。

作为一种示例，订单和商品之间的关系可以参阅如下定义的规则：

应理解，在上述定义的规则中，关系名称为订单和商品之间的关系，关系类型为多对多的关系。

示例2：在图4所示示意图中，每个商品可由多个原材料(也称为：原料)组成，每种原材料也可以被应用在多个商品中，因此，商品和原料之间也是多对多的引用关系。示例性的，如下所示，假设表7为原料对应的表格，表8为商品和原料之间的关系表。

表7原料表

字段名	字段类型	字段说明
			id	INT	原料ID
name	VARchar	原料名

表8商品-原料关系表

字段名	字段类型	字段说明
			product_id	INT	商品ID
material_id	INT	原料ID

其中，表8中的product_id字段对应表5的id字段，material_id字段对应表7的id字段。

作为一种示例，商品和原料之间的关系可以参阅如下定义的规则：

应理解，在上述定义的规则中，关系名称为商品和原料之间的关系，关系类型为多对多的关系。

通过上述介绍可知，不同的数据对象可以为一对多或者多对多的关系，并且，可将数据对象之间的关系定义为上述所示示例中的规则。当然，上述规则及数据对象的数量等仅是一种示意性说明，本申请对此不作限定。

以三个DO和两个RO为例，如图5所示，可将三个DO和两个RO之间的关系表示为图5所示的示意图。其中，RO1表示DO1和DO2之间存在的对应关系，RO2表示DO2和DO3之间存在的对应关系。应理解，DO和RO之间的关系可以为一个网状的树形图，DO可以为树形图的节点，本申请实施例中并不限定节点的查询方向，即在一个网状的树形图中存在多种应用场景，比如从DO1为起点查询DO3为一种应用场景，从DO3为起点查询DO1为另一种应用场景等。

在一些实施例中，可对数据对象和关系对象定义缓存规则，并按照定义的缓存规则将数据存储在缓存中。示例性的，假设DO1、DO2、DO3为三个数据对象，RO1表示DO1和DO2之间存在一对多或多对多的关系，例如记为：rel-DO1-DO2，RO2表示DO2和DO3之间存在一对多或多对多的关系，例如记为：rel-DO2-DO3。

作为一种示例，定义的缓存规则可以如下：

应理解，在缓存中可按照上面定义的规则将数据分为3层，最顶层存放DO1的业务对象，中间层存放与DO1相关的DO2对象，最下层存放与DO2相关的DO3对象。类比Redis的Hash类型，Key字段存放DO1，Field字段存放DO2，Value字段存放DO3。

以图4所示示意图中的数据对象，比如订单、商品和原料进行举例，比如在上述缓存规则中DO1为订单，DO2为商品，DO3为原料，则上述缓存规则对应的查询场景可以理解为完成该订单需要哪些原材料。当然，在不同的场景下，比如查询场景为某原料被用在了哪些订单上，此时订单可能为DO3，原料可能为DO1等，本申请对此不作限定。需要说明的是，上述缓存规则仅是一种示意性说明，本申请实施例中对于其它的应用场景可以参照上述缓存规则进行定义。

在另一些实施例中，应用也可以记录用户查询数据的规律(或者习惯)，然后按照用户查询数据的规律自动定义规则。以图5为例，比如，DO1为订单，DO2为商品，DO3为原料，假设用户经常查询的场景为：完成订单需要哪些原材料，即查询场景的方向为：DO1-DO3，因此，应用可按照用户的查询习惯等生成缓存规则，这样无需开发人员在每一次查询场景下定义一次缓存规则，能够减少开发人员的工作量，并且能够提升用户体验。

继续参照图3的S302、根据缓存规则查询缓存中是否有与待更新的数据对象和/或关系对象相关联的数据。若缓存中存在与待更新的数据对象和/或关系对象相关联的数据，则执行S303，若缓存中不存在与待更新的数据对象和/或关系对象相关联的数据，则修改数据库，对数据库进行更新。

在本申请实施例中，当用户查询过数据之后，缓存中可存储有查询的记录，应用可根据缓存规则查找与数据更新请求消息中包括的待更新的数据相关联的数据。如果缓存中没有记录，则说明用户没有查询过与待更新的数据相关联的数据记录，则可以直接对数据库进行修改，这样当用户进行数据查询时，可从数据库查询到结果，并将查询结果保存在缓存中。

S303、更新缓存中与待更新的数据对象和/或关系对象相关联的数据。

示例性的，以图5所示示意图为例，对本申请实施例中数据的更新场景进行说明，具体可参阅如下表9所示。

表9

下面以上述表格为例介绍不同的更新场景下如何查找与更新的数据相关联的数据，并在缓存中更新相关联的数据的过程。

1、新增，具体可包括DO的新增和/或RO的新增。

在一些实施例中，由于DO为新增的DO，缓存中必然没有查询记录，因此，缓存中不存在与新增的DO相关联的数据，因此无需对缓存进行更新操作。

在另一些实施例中，当新增RO1时，可以通过RO1的字段在缓存中判断是否存在DO1的查询记录，如果缓存中存在DO1的查询记录，则更新缓存，如果不存在DO1的查询记录，则不需要对缓存更新。示例性的，当RO1为订单-商品关系表时，如果新增RO1则可以通过RO1的字段，比如order_id字段(表6所示为RO1对应的表格)查询缓存中是否有DO1(订单)的查询记录，如果缓存中存在DO1的查询记录，则可在缓存中增加RO1；如果缓存中不存在DO1的查询记录，则直接对数据库进行更新。

举例来说，比如按照上述表格及表格对应的缓存规则为例，当新增订单-商品关系时，由于DO1为订单，即缓存的输入为订单，因此在缓存中查询时需要以订单为输入进行查询，即查询缓存中是否有订单的查询记录。应理解，新增订单-商品关系可包括一个商品新增订单或者在订单中新增商品。

需要说明的是，在不同的应用场景下查询的缓存中的数据对象可能不同，比如商品为DO1，订单为DO2时，可在缓存中查询是否有商品作为输入时的查询记录。

在又一些实施例中，当新增RO2时，需要反查数据库，确定新增RO2时受影响的DO1，然后在缓存中查询是否存在DO1的查询记录，如果缓存中存在DO1的查询记录，则更新缓存，如果缓存中不存在DO1的查询记录，则不需要对缓存更新。

继续以上述表格及表格对应的缓存规则为例来说，由于缓存规则中的输入为订单，商品和订单之间存在对应关系，因此，当新增商品-原料关系时，需要通过查询数据库确定在新增商品-原料关系时与商品相关联的订单，即需要在缓存中确定是否存在与商品相关联的订单的查询记录。

2、删除，具体可包括DO的删除和/或RO的删除。

在一些实施例中，当删除DO1时，可以直接在缓存中定位是否存在DO1的查询记录，如果缓存中存在DO1的查询记录，则直接清除缓存中对应的DO1，即在缓存中删除DO1的查询记录。

在另一些实施例中，由于RO1和RO2分别为DO1-DO2，DO2-DO3的对应关系，当删除DO2或DO3时，会同时触发RO1和RO2的删除操作，而缓存中记录的是DO之间的对应关系，因此，可以通过监控RO的变化来更新缓存，无需监控DO2、DO3的变化来变更缓存记录。

在另一些实施例中，当删除RO1时，可以通过RO1的字段直接在缓存中确定是否存在DO1的查询记录，如果缓存中存在DO1的查询记录，则在缓存中删除RO1，如果缓存中不存在DO1的查询记录，则不需要对缓存更新。

以上述表格及表格对应的缓存规则为例，由于在缓存规则中输入为订单，即DO1为订单，因此，在删除订单-商品关系时需要以订单为输入在缓存中进行查询，即查询缓存中是否有订单的查询记录。应理解，删除订单-商品关系可包括一个商品删除订单或者在订单中删除某个商品。

在又一些实施例中，当删除RO2时，需要反查数据库，确定新增RO2时受影响的DO1，然后在缓存中查询是否存在DO1的查询记录，如果缓存中存在DO1的查询记录，则更新缓存，如果不存在DO1的查询记录，则不需要对缓存更新。

以上述表格及表格对应的缓存规则为例来说，由于缓存规则中的输入为订单，商品和订单之间存在对应关系，因此，当删除商品-原料关系时，需要通过查询数据库确定在删除商品-原料关系时与商品相关联的订单，即需要在缓存中确定是否存在订单的查询记录。

3、修改，具体可包括DO的修改和/或RO的修改。

在一些实施例中，由于缓存中一般是按照主键属性存储的，并不会存放DO1、DO2的普通字段属性(非主键属性)，而主键属性通常是不允许更新的，因此，当修改DO1或DO2时并不会影响缓存中存在的对应关系，即无需对缓存进行更新操作。

在另一些实施例中，当修改DO3时，由于缓存中会存放DO3的所有属性，因此在更新DO3时会对缓存中的数据有影响，因此在更新DO3时，需要通过反查数据库的方式获取受影响的DO1和DO2，将缓存中存在的受影响的数据均要进行更新。

继续以上述表格及表格对应的缓存规则为例来说，在上述缓存规则的输入DO1为订单，DO2为商品，DO3为原料，且商品和订单之间存在对应关系，商品和原料之间也存在对应关系时，当修改原料时，需要通过查询数据库确定在修改原料时与原料相关联的商品以及与商品相关联的订单，即需要在缓存中确定是否存在相关联的商品和订单的查询记录。

进一步的，在本申请实施例中可以定义多个缓存规则，比如可定义多个场景的缓存规则，此时，如果要更新数据，则可遍历缓存规则，然后通过定义的缓存规则找到与更新的数据相关联的数据。示例性的，以两个缓存规则为例，比如缓存规则1定义了以订单为输入，原料为输出的场景，即缓存规则1中DO1为订单，DO2为商品，DO3为原料，缓存规则2定义了以原料为输入，订单为输出的场景，即缓存规则2中DO1为原料，DO2为商品，DO3为订单，那么如果要删除RO2，即删除商品-原料对应关系中的一个对应关系，则需要通过数据库查找商品-原料对应关系中与商品相关联的订单，然后在缓存中确定是否存在以相关联的订单为输入的查询记录以及是否存在以原料为输入的查询记录。

也就是说，在本申请实施例中，应用服务器可通过缓存服务器中存储的缓存规则在缓存中查找是否有与要更新的数据相关联的数据的查询记录，如果缓存中存在查询记录，则更新缓存，以便下次进行数据查询时能够获取到最新的数据；如果缓存中没有查询记录，则可直接更新数据库，这样用户在进行数据查询时可查询数据库，然后将数据库的查询结果保存在缓存中，从而保证了数据库中的数据与缓存中的数据的一致性，能够提升用户体验。

举个例子，比如以User(用户)、UserGroup(用户组)、Role(角色)三个数据对象为例，一个User可能加入多个UserGroup，每个UserGroup也存在多个User，User和UserGroup为多对多的关系。每个UserGroup存在多个Role，而每个Role也对应多个UserGroup。UserGroup和Role也是多对多关系。在实际使用中，经常会遇到查询某个User对应Role的场景，在这种场景下，按照现有技术从数据库查询通常需要查询多个实体表和多个关系表才能获取所需的结果，在高并发场景下数据库的查询压力较大。

而本申请实施例中可将User、UserGroup、Role之间的两层多对多关系抽象成缓存规则，然后在用户执行数据修改操作时，可自动生成相对应的数据库操作拦截器。对于查询请求，可以先在缓存中查询是否存在所需数据，如存在则直接返回结果；如果不存在，则从数据库中获取查询结果，并将查询结果以规定的格式保存在缓存中，然后返回。对于数据变更请求(也可以称为：数据更新请求)，可先判断出变更操作受影响的缓存数据，将受影响的缓存数据更新，比如删除(驱逐)后再变更数据库，从而维护了缓存数据与数据库的一致性。

相比较而言，在申请中优先读取缓存相比直接查询数据库，查询性能提升了5倍左右。即从缓存中读取数据比查询数据库的方式能够提升查询性能。

另外，现有的SpringCache的缓存技术，需要在读取或修改的方法上添加@Cacheable和@CacheEvict两个注解，而本申请仅需在配置文件中添加简单的配置即可使用，对代码的侵入程度较低。

进一步的，本申请还可以扩展应用到同类数据对象嵌套关系的缓存中。比如，可将同类数据对象的嵌套关系抽象成父子关系，一个父对象可关联多个子对象，每个子对象最多仅关联一个父对象，这样数据对象之间的嵌套组合就形成了一个树形结构。举例来说：公司内的部门为常见的树形结构，上级部门存在多个下级部门，每个下级部分仅存在一个直属上级部门。在实际应用中，经常存在查询子部门所属直接上级部门或最上层部分的场景。

基于此，本申请中可将部门之间的嵌套关系抽象成缓存规则，自动生成数据库操作拦截器，对于嵌套关系的查询请求，优先读取缓存中的数据，如果不存在缓存数据，则从数据库中获取查询结果并重建缓存。对于嵌套对象或嵌套关系的变更操作，可自动过滤出缓存中受影响的数据，将其驱逐，以维护数据库与缓存的数据一致性。

在本申请中，与直接读取数据库相比，读取缓存可使得性能有较大的提升，且嵌套层数越深，提升效果越明显。并且，在现有方案中对于多层嵌套关系的查询需要多次查询数据库来获取返回结果，而本申请中仅需一次缓存查询即可获得返回结果，能够加快查询响应速度。其次，删除(淘汰)数据时可以通过缓存数据中的属性字段快速定位已缓存的数据，避免反查数据库或全扫描等其他耗时操作。

通过上述实施例，基于数据对象及其关系的元数据定义，可自动生成对象及其关系的增删改的数据访问对象(data access object，DAO)层接口及SQL实现，通过DAO层的拦截器拦截所有的数据库操作来建立缓存，并在缓存中查找到所需数据。并且，可拦截对数据库数据变更的操作，通过对象关系的元数据定义自动找到受影响的缓存键值并驱逐这些键值，在下次服务查询这些数据的时候从数据库中重建缓存，实现缓存与数据库的一致性。

本申请的方案能够解决现有使用关系数据库时为了扩大服务并发数或者减少数据系统压力或者缩短服务的响应时间的目的，使用缓存系统缓存数据库数据时候缓存维护困难，数据一致性难保障的问题。

基于上述实施例，本申请还提供一种数据更新装置，该装置可以是应用服务器。参阅图6所示，该数据更新装置600可包括：接收单元601、确定单元602、更新单元603。

其中，接收单元601，用于接收数据更新请求消息，所述数据更新请求消息中包括待更新的数据；所述待更新的数据包括待更新的数据对象和/或待更新的关系对象，所述关系对象为不同的数据对象之间的关联关系。

确定单元602，用于根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象，所述缓存规则用于表征不同数据对象之间的关联关系以及每一个数据对象在数据查询场景所对应的角色。

更新单元603，用于更新所述缓存中与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象。

在一种可能的实现中，所述确定单元602具体用于按如下方式根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象：

若所述待更新的数据为所述关系对象，则根据缓存规则确定与所述关系对象相关联的数据对象为第一数据对象，所述第一数据对象为所述缓存规则中角色为输入对象的数据对象。

在一种可能的实现中，所述数据更新请求消息中还包括待更新的数据的更新类型，所述数据的更新类型包括新增、删除、修改中的至少一种。

在一种可能的实现中，所述确定单元602具体用于按如下方式根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象：

若所述待更新的数据为数据对象，且所述数据对象的更新类型为删除类型时，则根据缓存规则确定与所述数据对象相关联的数据对象为第一数据对象，所述第一数据对象为所述缓存规则中角色为输入对象的数据对象。

在一种可能的实现中，所述确定单元602具体用于按如下方式根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象：

若所述待更新的数据为第一数据对象，且所述第一数据对象的更新类型为修改类型时，则根据缓存规则确定与所述第一数据对象相关联的数据对象为第二数据对象，所述第二数据对象为所述缓存规则中除去所述第一数据对象之外的数据对象，所述第一数据对象为所述缓存规则中角色为输出对象的数据对象。

在一种可能的实现中，所述缓存规则包括：用户预先根据至少一个数据查询场景定义的规则，和/或应用学习到的查询场景，并根据学习到的查询场景定义的规则。

本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，另外，在本申请各个实施例中的各功能模块可以集成在一个处理器中，也可以是单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

如图7所示为本申请实施例提供的一种数据更新设备700，该设备可以是应用服务器或者是应用服务器中的一个或多个设备。该数据更新设备700包括至少一个处理器702，用于实现或用于支持数据更新设备700实现如本申请实施例提供的图6所示的确定单元602和更新单元603的功能。示例性地，处理器702可以根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象，所述缓存规则用于表征不同数据对象之间的关联关系以及每一个数据对象在数据查询场景所对应的角色；更新所述缓存中与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象等，具体参见方法示例中的详细描述，此处不做赘述。

数据更新设备700还可以包括至少一个存储器701，用于存储程序指令。存储器701和处理器702耦合。本申请实施例中的耦合是装置、单元或模块之间的间接耦合或通信连接，可以是电性，机械或其它的形式，用于装置、单元或模块之间的信息交互。处理器802可能和存储器701协同操作。处理器702可能执行存储器701中存储的程序指令和/或数据。所述至少一个存储器中的至少一个可以包括于处理器中。

数据更新设备700还可以包括通信接口703，用于通过传输介质和其它设备进行通信。处理器702可以利用通信接口703收发数据。在另一些实施例中，通信接口703可以为收发器，或者接收器、发射器。示例性的，通信接口703用于接收数据更新请求消息，所述数据更新请求消息中包括待更新的数据；所述待更新的数据包括待更新的数据对象和/或待更新的关系对象，所述关系对象为不同的数据对象之间的关联关系。

本申请不限定上述通信接口703、处理器702以及存储器701之间的具体连接介质。本申请实施例在图7中以存储器701、处理器702以及通信接口703之间通过总线704连接，总线在图7中以粗线表示。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

在本申请实施例中，处理器702可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接由硬件处理器执行完成，或者由处理器中的硬件及软件模块组合执行完成。

在本申请实施例中，存储器701可以是非易失性存储器，比如硬盘(hard diskdrive，HDD)或固态硬盘(solid-state drive，SSD)等，还可以是易失性存储器(volatilememory)，例如RAM。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令。

可选的，本申请实施例中的计算机执行指令也可以称之为应用程序代码，本申请实施例对此不作具体限定。

本申请实施例中还提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行上述实施例的方法。

本申请实施例中还提供一种计算机程序产品，包括指令，当其在计算机上运行时，使得计算机执行上述实施例的方法。

本申请实施例中还提供一种芯片，所述芯片中的逻辑用于执行上述实施例的方法。

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

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

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

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (14)

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

接收数据更新请求消息，所述数据更新请求消息中包括待更新的数据；所述待更新的数据包括待更新的数据对象和/或待更新的关系对象，所述关系对象为不同的数据对象之间的关联关系；

根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象，所述缓存规则用于表征不同数据对象之间的关联关系以及每一个数据对象在数据查询场景所对应的角色；

更新所述缓存中与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象。

2.如权利要求1所述的方法，其特征在于，根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象，包括：

若所述待更新的数据为所述关系对象，则根据缓存规则确定与所述关系对象相关联的数据对象为第一数据对象，所述第一数据对象为所述缓存规则中角色为输入对象的数据对象。

3.如权利要求1或2所述的方法，其特征在于，所述数据更新请求消息中还包括待更新的数据的更新类型，所述数据的更新类型包括新增、删除、修改中的至少一种。

4.如权利要求3所述的方法，其特征在于，所述根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象，包括：

若所述待更新的数据为数据对象，且所述数据对象的更新类型为删除类型时，则根据缓存规则确定与所述数据对象相关联的数据对象为第一数据对象，所述第一数据对象为所述缓存规则中角色为输入对象的数据对象。

5.如权利要求3所述的方法，其特征在于，所述根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象，包括：

若所述待更新的数据为第一数据对象，且所述第一数据对象的更新类型为修改类型时，则根据缓存规则确定与所述第一数据对象相关联的数据对象为第二数据对象，所述第二数据对象为所述缓存规则中除去所述第一数据对象之外的数据对象，所述第一数据对象为所述缓存规则中角色为输出对象的数据对象。

6.如权利要求1-5任一项所述的方法，其特征在于，所述缓存规则包括：

用户预先根据至少一个数据查询场景定义的规则，和/或

应用学习到的查询场景，并根据学习到的查询场景定义的规则。

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

接收单元，用于接收数据更新请求消息，所述数据更新请求消息中包括待更新的数据；所述待更新的数据包括待更新的数据对象和/或待更新的关系对象，所述关系对象为不同的数据对象之间的关联关系；

确定单元，用于根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象，所述缓存规则用于表征不同数据对象之间的关联关系以及每一个数据对象在数据查询场景所对应的角色；

更新单元，用于更新所述缓存中与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象。

8.如权利要求7所述的装置，其特征在于，所述确定单元具体用于按如下方式根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象：

若所述待更新的数据为所述关系对象，则根据缓存规则确定与所述关系对象相关联的数据对象为第一数据对象，所述第一数据对象为所述缓存规则中角色为输入对象的数据对象。

9.如权利要求7或8所述的装置，其特征在于，所述数据更新请求消息中还包括待更新的数据的更新类型，所述数据的更新类型包括新增、删除、修改中的至少一种。

10.如权利要求9所述的装置，其特征在于，所述确定单元具体用于按如下方式根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象：

若所述待更新的数据为数据对象，且所述数据对象的更新类型为删除类型时，则根据缓存规则确定与所述数据对象相关联的数据对象为第一数据对象，所述第一数据对象为所述缓存规则中角色为输入对象的数据对象。

11.如权利要求9所述的装置，其特征在于，所述确定单元具体用于按如下方式根据缓存规则在缓存中确定与所述待更新的数据对象和/或待更新的关系对象相关联的数据对象：

若所述待更新的数据为第一数据对象，且所述第一数据对象的更新类型为修改类型时，则根据缓存规则确定与所述第一数据对象相关联的数据对象为第二数据对象，所述第二数据对象为所述缓存规则中除去所述第一数据对象之外的数据对象，所述第一数据对象为所述缓存规则中角色为输出对象的数据对象。

12.如权利要求7-11任一项所述的装置，其特征在于，所述缓存规则包括：

用户预先根据至少一个数据查询场景定义的规则，和/或

应用学习到的查询场景，并根据学习到的查询场景定义的规则。

13.一种数据更新设备，其特征在于，包括：存储器和处理器；

所述存储器，用于存储有计算机指令；

所述处理器用于执行所述存储器所存储的计算机指令，以使所述设备执行如权利要求1-6中任一项所述的方法。

14.一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机指令，当所述计算机指令被计算机执行时，使得所述计算机执行如权利要求1-6中任一项所述的方法。

Images