CN110807040A - 管理数据的方法、装置、设备及存储介质 - Google Patents

Abstract

本公开关于一种管理数据的方法、装置、设备及存储介质，应用于终端设备或服务端，该方法包括：响应于调用预设接口更改数据库中的目标数据，从预先获取的接口依赖关系表中查询依赖于所述预设接口的依赖接口，所述接口依赖关系表用于记录各个接口之间的依赖关系；基于所述预设接口更改的目标数据，对本地存储的缓存过期表中所述依赖接口对应的内容进行更新，得到更新后的缓存过期表。本公开可以基于预设接口更改的目标数据对缓存过期表中依赖接口对应的内容进行更新，得到更新后的缓存过期表，进而可实现后续基于该缓存过期表向用户提供数据，可以减少用户等待时间，提升用户体验，并且可以避免网络资源的浪费。

Description

管理数据的方法、装置、设备及存储介质

技术领域

本公开涉及互联网技术领域，尤其涉及一种管理数据的方法、装置、设备及存储介质。

背景技术

随着互联网技术的发展，用户可以通过终端设备中的浏览器或App(Application，应用程序)客户端请求API(Application Programming Interface，应用程序编程接口)获取远程数据。

然而相关技术中，当执行跳转、刷新页面或者重新打开页面等操作时，通过重新获取API的方式保持数据的及时性和有效性。具体来说，终端设备每次获取API都需要重新发送请求到服务端，以等待服务端从数据库获取数据，再返回该数据给终端设备。即使数据没有发生任何更改，即本次获取的数据和上次获取的数据一模一样，也不得不再次发送一次http请求，不仅导致用户需要等待API接口返回数据，影响用户体验，而且会导致网络资源的浪费。

发明内容

本公开提供一种管理数据的方法、装置及系统，以至少解决相关技术中的技术问题。

本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种管理数据的方法，包括：

响应于调用预设接口更改数据库中的目标数据，从预先获取的接口依赖关系表中查询依赖于所述预设接口的依赖接口，所述接口依赖关系表用于记录各个接口之间的依赖关系，所述预设接口包括用于增加、删除或修改数据的接口，所述依赖接口包括依赖于所述预设接口的用于获取数据的接口；

基于所述预设接口更改的目标数据，对本地存储的缓存过期表中所述依赖接口对应的内容进行更新，得到更新后的缓存过期表。

在一实施例中，在所述的管理数据的方法应用于服务端的情况下，所述的管理数据的方法，还包括：

向终端设备发送所述更新后的缓存过期表，以供所述终端设备以所述更新后的缓存过期表替换所述终端设备的本地存储的缓存过期表。

在一实施例中，所述的管理数据的方法，还包括：

响应于接收到用于调用目标接口获取目标数据的第一请求，从所述接口依赖关系表中查找所述目标接口；

响应于查找到所述目标接口，检测本地是否存在所述目标数据对应的第一缓存数据；

若存在所述第一缓存数据，则基于所述缓存过期表判断所述第一缓存数据是否有效；

若所述第一缓存数据有效，则将所述第一缓存数据作为目标数据提供给所述第一请求的发送方。

在一实施例中，所述的管理数据的方法，还包括：

若不存在所述第一缓存数据或所述第一缓存数据存在但已失效，则向目标设备发送用于获取所述目标数据的第二请求，其中，在所述的管理数据的方法应用于终端设备的情况下，所述目标设备包括服务端；在所述的管理数据的方法应用于服务端的情况下，所述目标设备包括数据库；

将所述目标设备响应于所述第二请求返回的数据作为目标数据提供给所述第一请求的发送方，并作为所述目标数据的第二缓存数据存储于所述本地，并记录所述第二缓存数据的缓存时间。

在一实施例中，所述的响应于查找到所述目标接口，检测本地是否存在所述目标数据对应的第一缓存数据的步骤，包括：

响应于查找到所述目标接口，判断所述目标接口的类型是否为获取数据的接口类型；

响应于所述目标接口的类型为获取数据的接口类型，检测所述本地是否存在所述目标数据对应的第一缓存数据。

在一实施例中，所述的缓存过期表中包含数据库中所述目标数据的修改时间；

所述的基于所述缓存过期表判断所述第一缓存数据是否有效的步骤，包括：

获取所述第一缓存数据的缓存时间；

若所述缓存时间晚于所述修改时间，则确定所述第一缓存数据有效；

若所述缓存时间早于或等于所述修改时间，则确定所述第一缓存数据已失效。

在一实施例中，在所述的管理数据的方法应用于服务端的情况下，所述的管理数据的方法还包括基于以下步骤构建所述接口依赖关系表：

获取服务端代码文件，所述代码文件中包含各个接口与各个服务层的第一调用关系、所述各个服务层与各个数据访问层的第二调用关系以及所述各个数据访问层与各个数据库table的第三调用关系；

基于所述第一调用关系、所述第二调用关系和所述第三调用关系确定所述各个接口与所述各个数据库table之间的依赖关系；

基于同一数据库table关联的多个接口之间的依赖关系生成接口依赖关系表。

根据本公开实施例的第二方面，提供一种管理数据的装置，应用于终端设备或服务端，包括：

依赖接口查询模块，被配置为执行响应于调用预设接口更改数据库中的目标数据，从预先获取的接口依赖关系表中查询依赖于所述预设接口的依赖接口，所述接口依赖关系表用于记录各个接口之间的依赖关系，所述预设接口包括用于增加、删除或修改数据的接口，所述依赖接口包括依赖于所述预设接口的用于获取数据的接口；

缓存过期表更新模块，被配置为执行基于所述预设接口更改的目标数据，对本地存储的缓存过期表中所述依赖接口对应的内容进行更新，得到更新后的缓存过期表。

在一实施例中，在所述的管理数据的装置应用于服务端的情况下，所述的管理数据的装置，还包括：

缓存过期表发送模块，被配置为执行向终端设备发送所述更新后的缓存过期表，以供所述终端设备以所述更新后的缓存过期表替换所述终端设备的本地存储的缓存过期表。

在一实施例中，所述的管理数据的装置，还包括目标数据提供模块；

所述目标数据提供模块，包括：

目标接口查找单元，被配置为执行响应于接收到用于调用目标接口获取目标数据的第一请求，从所述接口依赖关系表中查找所述目标接口；

第一数据检测单元，被配置为执行响应于查找到所述目标接口，检测本地是否存在所述目标数据对应的第一缓存数据；

第一数据判断单元，被配置为执行当存在所述第一缓存数据时，基于所述缓存过期表判断所述第一缓存数据是否有效；

第一数据提供单元，被配置为执行当所述第一缓存数据有效时，将所述第一缓存数据作为目标数据提供给所述第一请求的发送方。

在一实施例中，所述目标数据提供模块，包括：

第二请求发送单元，被配置为执行当不存在所述第一缓存数据或所述第一缓存数据存在但已失效时，向目标设备发送用于获取所述目标数据的第二请求，其中，在所述的管理数据的方法应用于终端设备的情况下，所述目标设备包括服务端；在所述的管理数据的方法应用于服务端的情况下，所述目标设备包括数据库；

第二数据提供单元，被配置为执行将所述目标设备响应于所述第二请求返回的数据作为目标数据提供给所述第一请求的发送方，并作为所述目标数据的第二缓存数据存储于所述本地，并记录所述第二缓存数据的缓存时间。

在一实施例中，所述第一数据检测单元还被配置为执行：

响应于查找到所述目标接口，判断所述目标接口的类型是否为获取数据的接口类型；

响应于所述目标接口的类型为获取数据的接口类型，检测所述本地是否存在所述目标数据对应的第一缓存数据。

在一实施例中，所述的缓存过期表中包含数据库中所述目标数据的修改时间；

所述第一数据判断单元还被配置为执行：

获取所述第一缓存数据的缓存时间；

若所述缓存时间晚于所述修改时间，则确定所述第一缓存数据有效；

若所述缓存时间早于或等于所述修改时间，则确定所述第一缓存数据已失效。

在一实施例中，在所述的管理数据的装置应用于服务端的情况下，所述的管理数据的装置还包括依赖关系表生成模块；

所述依赖关系表生成模块，包括：

代码文件获取单元，被配置为执行获取服务端代码文件，所述代码文件中包含各个接口与各个服务层的第一调用关系、所述各个服务层与各个数据访问层的第二调用关系以及所述各个数据访问层与各个数据库table的第三调用关系；

依赖关系确定单元，被配置为执行基于所述第一调用关系、所述第二调用关系和所述第三调用关系确定所述各个接口与所述各个数据库table之间的依赖关系；

依赖关系表生成单元，被配置为执行基于同一数据库table关联的多个接口之间的依赖关系生成接口依赖关系表。

根据本公开实施例的第三方面，提供一种管理数据的电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如上述任一项所述的管理数据的方法。

根据本公开实施例的第四方面，提供一种存储介质，当所述存储介质中的指令由管理数据的电子设备的处理器执行时，使得管理数据的电子设备能够执行如上述任一项所述的管理数据的方法。

根据本公开实施例的第五方面，提供一种计算机程序产品，当所述计算机程序产品由管理数据的电子设备的处理器执行时，使得管理数据的电子设备能够执行如上述任一项所述的管理数据的方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

本公开通过响应于调用预设接口更改数据库中的目标数据，从预先获取的接口依赖关系表中查询依赖于所述预设接口的依赖接口，所述接口依赖关系表用于记录各个接口之间的依赖关系，并基于所述预设接口更改的目标数据，对本地存储的缓存过期表中所述依赖接口对应的内容进行更新，得到更新后的缓存过期表，由于是基于预设接口更改的目标数据对缓存过期表中依赖接口对应的内容进行更新，得到更新后的缓存过期表，因而可确保终端设备中的缓存过期表的有效性，进而可以实现后续基于该缓存过期表向用户提供数据，可以减少用户等待时间，提升用户体验，并且可以避免网络资源的浪费。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种管理数据的方法的流程图。

图2是根据又一示例性实施例示出的一种管理数据的方法的流程图。

图3是根据再一示例性实施例示出的一种管理数据的方法的流程图。

图4是根据一示例性实施例示出的如何响应于查找到所述目标接口，检测所述本地是否存在所述目标数据对应的第一缓存数据的流程图。

图5是根据一示例性实施例示出的如何基于所述本地存储的缓存过期表判断所述第一缓存数据是否有效的流程图。

图6A是根据一示例性实施例示出的如何构建所述接口依赖关系表的流程图。

图6B是根据一示例性实施例示出的服务端代码文件中各层调用关系的示意图。

图7是根据一示例性实施例示出的一种管理数据的装置的框图。

图8是根据又一示例性实施例示出的一种管理数据的装置的框图。

图9是根据一示例性实施例示出的一种管理数据的电子设备的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

图1是根据一示例性实施例示出的一种管理数据的方法的流程图。本实施例的管理数据的方法可以用于服务端(如，一台服务器或多台服务器组成的服务器集群等)中，或者还可以用于终端设备(如，智能手机、平板电脑或台式电脑等)。如图1所示，包括以下步骤S101-S102：

在步骤S101中，响应于调用预设接口更改数据库中的目标数据，从预先获取的接口依赖关系表中查询依赖于所述预设接口的依赖接口。

本实施例中，当服务端调用预设接口更改数据库中的目标数据后，可以从本地存储的接口依赖关系表中查询依赖于所述预设接口的依赖接口。

其中，所述接口依赖关系表用于记录各个接口之间的依赖关系，所述预设接口可以包括用于增加(add)、删除(delete)或修改(update)数据的接口，所述依赖接口包括用于获取(get)数据的接口。

在步骤S102中，基于所述预设接口更改的目标数据，对本地存储的缓存过期表中所述依赖接口对应的内容进行更新，得到更新后的缓存过期表。

在一实施例中，当从所述接口依赖关系表中查询依赖于所述预设接口的依赖接口后，可以基于所述预设接口更改的目标数据，对所述缓存过期表中所述依赖接口对应的内容进行更新，例如可以对缓存过期表中所述依赖接口对应的缓存数据的过期时间(如，数据库中相应数据的修改时间)进行设置等，进而可以得到更新后的缓存过期表。

举例来说，当调用delete接口修改数据库中的数据(即，删除了数据库中目标数据后)，可以对缓存过期表中依赖于该delete接口的get接口对应的缓存数据的过期时间进行设置，如设置为delete接口修改数据库中的数据的时间等。

由上述描述可知，本实施例通过响应于调用预设接口更改数据库中的目标数据，从接口依赖关系表中查询依赖于所述预设接口的依赖接口，并基于所述预设接口更改的目标数据，对所述缓存过期表中所述依赖接口对应的内容进行更新，得到更新后的缓存过期表，可以实现及时维护本地存储的缓存过期表，进而可以实现后续基于该缓存过期表向用户提供数据，可以减少用户等待时间，进而可以提升用户体验，并且可以避免网络资源的浪费。

图2是根据又一示例性实施例示出的一种管理数据的方法的流程图。本实施例的管理数据的方法可以用于服务端(如，一台服务器或多台服务器组成的服务器集群等)中，或者还可以用于终端设备(如，智能手机、平板电脑或台式电脑等)。如图2所示，包括以下步骤S201-S203：

在步骤S201中，响应于调用预设接口更改数据库中的目标数据，从预先获取的接口依赖关系表中查询依赖于所述预设接口的依赖接口。

在步骤S202中，基于所述预设接口更改的目标数据，对本地存储的缓存过期表中所述依赖接口对应的内容进行更新，得到更新后的缓存过期表。

其中，步骤S201-S202的相关解释和说明可以参见上述实施例，在此不进行赘述。

在步骤S203中，向终端设备发送所述更新后的缓存过期表，以供所述终端设备以所述更新后的缓存过期表替换所述终端设备的本地存储的缓存过期表。

本实施例中，服务端在得到更新后的缓存过期表后，可以以该更新后的缓存过期表替换所述本地存储的缓存过期表，并可以向终端设备发送所述更新后的缓存过期表，以确保终端设备本地存储的缓存过期表的有效性。在此基础上，当终端设备接收到调用目标接口(如，get接口)获取数据的请求时，可以基于该缓存过期表确定本地是否存在有效的缓存数据，进而可以在存存储了有效的缓存数据的情况下，将本地存储的缓存数据提供给数据请求方。

由上述描述可知，本实施例通过响应于调用预设接口更改数据库中的目标数据，从所述接口依赖关系表中查询依赖于所述预设接口的依赖接口，并基于所述预设接口更改的目标数据，对所述缓存过期表中所述依赖接口对应的内容进行更新，得到更新后的缓存过期表，进而以所述更新后的缓存过期表替换所述本地存储的缓存过期表，并向终端设备发送所述更新后的缓存过期表，可以实现及时维护本地存储的缓存过期表，并可以及时向关联的终端设备推送该更新后的缓存过期表，确保终端设备中的缓存过期表的有效性。

图3是根据再一示例性实施例示出的一种管理数据的方法的流程图。本实施例的管理数据的方法可以用于服务端(如，一台服务器或多台服务器组成的服务器集群等)中，或者还可以用于终端设备(如，智能手机、平板电脑或台式电脑等)。如图3所示，包括以下步骤S301-S308：

在步骤S301中，响应于调用预设接口更改数据库中的目标数据，从预先获取的接口依赖关系表中查询依赖于所述预设接口的依赖接口。

在步骤S302中，基于所述预设接口更改的目标数据，对本地存储的缓存过期表中所述依赖接口对应的内容进行更新，得到更新后的缓存过期表。

其中，步骤S301-S302的相关解释和说明可以参见上述实施例，在此不进行赘述。

在步骤S303中，响应于接收到用于调用目标接口获取目标数据的第一请求，从所述接口依赖关系表中查找所述目标接口。

本实施例中，服务端可以预先获取接口依赖关系表，该接口依赖关系表用于记录各个接口之间的依赖关系，所述预设接口包括用于增加、删除或修改数据的接口，所述依赖接口包括依赖于所述预设接口的用于获取数据的接口；进而，当接收到用于调用目标接口获取目标数据的第一请求时，可以从所述接口依赖关系表中查找该目标接口。

举例来说，上述第一请求可以包括检测到用户触发的跳转、刷新页面或者重新打开页面等操作等，本实施例对此不进行限定。

其中，上述目标数据可以包括用户信息等数据，本实施例对此不进行限定。

在步骤S304中，响应于查找到所述目标接口，检测本地是否存在所述目标数据对应的第一缓存数据：若是，则执行步骤S305；若否，则执行步骤S307。

以终端设备为例，当该终端设备接收到用于调用目标接口获取目标数据的第一请求时，可以检测本地是否存在该目标数据对应的第一缓存数据，若存在则执行步骤S305；否则，执行步骤S307。

在另一实施例中，上述检测本地是否存在所述目标数据对应的第一缓存数据的方式还可以参见下述图4所示实施例，在此先不进行详述。

在步骤S305中，基于所述缓存过期表判断所述第一缓存数据是否有效：若是，则执行步骤S306；若否，则执行步骤S307。

本实施例中，当检测本地存在所述目标数据对应的第一缓存数据后，可以得到检测结果：

若检测结果表征存在所述第一缓存数据，则可以进一步判断所述第一缓存数据是否有效，例如可以基于所述本地存储的缓存过期表判断所述第一缓存数据是否有效。

在一实施例中，上述缓存过期表中可以包括本地存储的缓存数据的相关信息，如缓存时间、过期时间(如，数据库中相应数据的修改时间)等，本实施例对此不进行限定。在此基础上，当检测到存在所述第一缓存数据时，可以基于该缓存过期表判断所述第一缓存数据是否有效。

进一步地，当确定上述第一缓存数据有效时，可以执行步骤S306将该第一缓存数据作为目标数据提供给所述第一请求的发送方(即，目标数据的请求方)。

在另一实施例中，若检测到本地不存在所述第一缓存数据，或者存在所述第一缓存数据但所述第一缓存数据已失效，则可以执行步骤S307-S308。

在另一实施例中，上述基于所述缓存过期表判断所述第一缓存数据是否有效的方式还可以参见下述图5所示实施例，在此先不进行详述。

在步骤S306中，将所述第一缓存数据作为目标数据提供给所述第一请求的发送方。

在步骤S307中，向目标设备发送用于获取所述目标数据的第二请求。

在步骤S308中，将所述目标设备响应于所述第二请求返回的数据作为目标数据提供给所述第一请求的发送方，并作为所述目标数据的第二缓存数据存储于所述本地，并记录所述第二缓存数据的缓存时间。

举例来说，当不存在上述第一缓存数据或第一缓存数据已失效时，可以向目标设备发送用于获取所述目标数据的第二请求。

值得说明的是，在本实施例的管理数据的方法应用于终端设备的情况下，上述目标设备可以包括服务端。而在本实施例的管理数据的方法应用于服务端的情况下，上述目标设备可以包括数据库。

在此基础上，当向目标设备发送用于获取所述目标数据的第二请求后，可以将该目标设备响应于所述第二请求返回的数据作为目标数据提供给所述第一请求的发送方。具体来说，可以接收目标设备响应于所述第二请求返回的数据，进而可以将该数据提供给所述第一请求的发送方。

进一步地，当接收到目标设备响应于所述第二请求返回的数据后，可以利用该数据更新本地的第一缓存数据，例如可以将所述目标设备返回的数据作为所述目标数据的第二缓存数据存储于所述本地，并记录所述第二缓存数据的缓存时间。

由上述描述可知，本实施例通过响应于接收到用于调用目标接口获取目标数据的第一请求，检测本地是否存在所述目标数据对应的第一缓存数据，并当存在所述第一缓存数据时，基于所述本地存储的缓存过期表判断所述第一缓存数据是否有效，进而当所述第一缓存数据有效时，将所述第一缓存数据作为目标数据提供给所述第一请求的发送方，可以实现在本地存在目标数据的第一缓存数据且该第一缓存数据有效的情况下，将所述第一缓存数据作为目标数据提供给所述第一请求的发送方。由于是基于本地缓存的有效数据向数据请求方提供数据，因而无需向服务端或数据库重新请求数据，可以减少用户等待时间，提升用户体验，并且可以避免网络资源的浪费。

另一方面，当不存在第一缓存数据或第一缓存数据已失效时，向目标设备发送用于获取所述目标数据的第二请求，并将所述目标设备响应于所述第二请求返回的数据作为目标数据提供给所述第一请求的发送方，可以实现在无法基于本地缓存的数据向数据请求方管理数据的情况下才向目标设备发送用于获取所述目标数据的第二请求，可以避免无差别的向服务端或数据库重新请求数据，因而可以在一定程度上减少用户的等待时间以及避免网络资源的浪费；并且，由于将所述目标设备返回的数据作为所述目标数据的第二缓存数据存储于所述本地，并记录所述第二缓存数据的缓存时间，可以实现本地缓存数据的更新，并可以实现后续基于缓存时间判断第二缓存数据的有效性。

图4是根据一示例性实施例示出的如何响应于查找到所述目标接口，检测所述本地是否存在所述目标数据对应的第一缓存数据的流程图。本实施例在上述实施例的基础上以如何响应于查找到所述目标接口，检测所述本地是否存在所述目标数据对应的第一缓存数据为例进行示例性说明。如图4所示，上述步骤S304中所述的响应于查找到所述目标接口，检测本地是否存在所述目标数据对应的第一缓存数据，可以包括以下步骤S401-S402：

在步骤S401中，响应于查找到所述目标接口，判断所述目标接口的类型是否为获取数据的接口类型。

举例来说，当接收到用于调用目标接口获取目标数据的第一请求时，可以从预先获取的接口依赖关系表中查找所述目标接口。值得说明的是，如果目标接口存在于该接口依赖关系表中，则可以基于本公开实施例的方案向数据请求方提供数据。具体来说，若目标接口存在于上述接口依赖关系表中，则可以基于该表中的各个接口确保上述目标接口对应的缓存数据的有效性，因而可以基于本公开实施例的方案向数据请求方提供数据。相反，若目标接口未存在于上述接口依赖关系表中，则无法基于该表中的各个接口确保上述目标接口对应的缓存数据的有效性，因而无法基于本公开实施例的方案向数据请求方提供数据。

在一实施例中，上述接口依赖关系表可以用于记录各个接口之间的依赖关系，如：接口A依赖于接口B和接口C(即，接口B和接口C的数据改变均会影响接口A对应的缓存数据的有效性)等，本实施例对依赖关系的具体形式不进行限定。

在此基础上，当从接口依赖关系表中查找到上述目标接口后，还可以进一步判断该目标接口的类型是否为获取数据的接口类型(即，get类型)。

可以理解的是，若目标接口的类型为get类型，则可以响应于接收到用于调用该接口获取目标数据的第一请求，进而可以实现基于本地存储的有效的缓存数据向数据请求方提供数据。而若目标接口的类型不是get类型(如，add类型、delete类型等)，则无法响应于接收到用于调用该接口“获取”目标数据的第一请求；并且，add类型或delete类型的接口由于是用于更改数据而非获取数据，因而无法在本地预先缓存数据，故无法实现基于本地存储的有效的缓存数据向数据请求方提供数据。

在步骤S402中，响应于所述目标接口的类型为获取数据的接口类型，检测所述本地是否存在所述目标数据对应的第一缓存数据。

在一实施例中，当确定目标接口的类型为获取数据的接口类型的情况下，可以执行上述检测所述本地是否存在所述目标数据对应的第一缓存数据的步骤。其中，该步骤的具体执行方式可以参见上述实施例，在此不进行赘述。

由上述描述可知，本实施例通过响应于查找到所述目标接口，判断所述目标接口的类型是否为获取数据的接口类型，并当所述目标接口的类型为获取数据的接口类型时，检测所述本地是否存在所述目标数据对应的第一缓存数据，可以实现准确的基于接口依赖关系表确定目标接口是否适用于本公开实施例的方案，进而可以确保方案的顺利实施，提高方案的可实施性。

图5是根据一示例性实施例示出的如何基于所述本地存储的缓存过期表判断所述第一缓存数据是否有效的流程图。本实施例在上述实施例的基础上以如何基于所述本地存储的缓存过期表判断所述第一缓存数据是否有效为例进行示例性说明。

本实施例中，所述的缓存过期表中可以包含数据库中所述目标数据的修改时间。

如图5所示，上述步骤S305中所述的基于所述本地存储的缓存过期表判断所述第一缓存数据是否有效的步骤，可以包括以下步骤S501-S504：

在步骤S501中，获取所述第一缓存数据的缓存时间。

在步骤S502中，判断所述缓存时间是否晚于所述目标数据的修改时间：若是，则执行步骤S503；若否，则执行步骤S504。

在步骤S503中，确定所述第一缓存数据有效。

在步骤S504中，确定所述第一缓存数据已失效。

在一实施例中，当检测到本地存在所述目标数据对应的第一缓存数据后，可以获取所述第一缓存数据的缓存时间，并可以从本地存储的缓存过期表中获取数据库中所述目标数据的修改时间，进而可以将该第一缓存数据的缓存时间与目标数据的修改时间进行比较：

若所述第一缓存数据的缓存时间晚于所述目标数据的修改时间，即表示第一缓存数据是在数据库中目标数据修改后缓存的，因而可以确定该第一缓存数据有效(即，第一缓存数据与数据库中的目标数据相同)；

而若所述第一缓存数据的缓存时间早于或等于所述目标数据的修改时间，即表示第一缓存数据是在数据库中目标数据修改时或修改前缓存的，因而可以确定该第一缓存数据已失效(即，第一缓存数据与数据库中的目标数据不同)。

由上述描述可知，本实施例通过获取所述第一缓存数据的缓存时间，并当所述缓存时间晚于所述修改时间时，确定所述第一缓存数据有效，而当所述缓存时间早于或等于所述修改时间时，确定所述第一缓存数据已失效，可以实现准确的确定第一缓存数据是否有效，进而可以实现后续当第一缓存数据有效时基于本地缓存的有效数据向数据请求方提供数据，进而可以避免向服务端或数据库重新请求数据，可以减少用户等待时间，提升用户体验，并且可以避免网络资源的浪费。

图6A是根据一示例性实施例示出的如何构建所述接口依赖关系表的流程图。本实施例在上述实施例的基础上以如何构建所述接口依赖关系表为例进行示例性说明。如图6A所示，在所述的管理数据的方法应用于服务端的情况下，本实施例的管理数据的方法还可以包括基于以下步骤S601-S603构建所述接口依赖关系表：

在步骤S601中，获取服务端代码文件。

在一实施例中，为了构建接口依赖关系表，可以获取服务端代码文件，其中，该代码文件中可以包含各个接口与各个服务层(Service层)的第一调用关系、所述各个服务层与各个数据访问层(Dao层，Data access object)的第二调用关系以及所述各个数据访问层与各个数据库table的第三调用关系。

举例来说，图6B是根据一示例性实施例示出的服务端代码文件中各层调用关系的示意图。如图6B所示，get接口与Service层“userService.getUser”之间具有第一调用关系，Service层“userService.getUser”与Dao层“userDao.user”之间具有第二调用关系，Dao层“userDao.user”与数据库table“userTable”之间具有第三调用关系。

在步骤S602中，基于所述第一调用关系、所述第二调用关系和所述第三调用关系确定所述各个接口与所述各个数据库table之间的依赖关系。

在一实施例中，当确定上述第一调用关系、所述第二调用关系和所述第三调用关系后，可以基于所述第一调用关系、所述第二调用关系和所述第三调用关系确定所述各个接口与所述各个数据库table之间的依赖关系。

仍以图6B为例，可以基于get接口与Service层“userService.getUser”之间的第一调用关系，Service层“userService.getUser”与Dao层“userDao.user”之间的第二调用关系以及Dao层“userDao.user”与数据库table“userTable”之间的第三调用关系，确定get接口与数据库table“userTable”之间具有关联关系。

在步骤S603中，基于同一数据库table关联的多个接口之间的依赖关系生成接口依赖关系表。

在一实施例中，当确定get接口与数据库table“userTable”之间的依赖关系后，可以确定该数据库table“userTable”关联的各个接口：get接口、add接口以及delete接口，进而可以基于各个接口是否需要修改数据的特性，确定这些接口之间的依赖关系。如，“add接口→get接口”(即，add接口的数据改变会影响get接口对应的缓存数据的有效性)以及“delete接口→get接口”(即，delete接口的数据改变会影响get接口对应的缓存数据的有效性)。进而，基于这些依赖关系形成表格，即可得到上述接口依赖关系表。

由上述描述可知，本实施例通过获取服务端代码文件，并基于所述第一调用关系、所述第二调用关系和所述第三调用关系确定所述各个接口与所述各个数据库table之间的依赖关系，进而可以实现基于同一数据库table关联的多个接口之间的依赖关系生成接口依赖关系表，可以为后续基于接口依赖关系表中查找目标接口奠定基础，可以实现准确的基于接口依赖关系表确定目标接口是否适用于本公开实施例的方案，进而可以确保方案的顺利实施，提高方案的可实施性。

图7是根据一示例性实施例示出的一种管理数据的装置的框图。本实施例的管理数据的方法可以用于服务端(如，一台服务器或多台服务器组成的服务器集群等)中，或者还可以用于终端设备(如，智能手机、平板电脑或台式电脑等)。如图7所示，该装置包括：依赖接口查询模块110和缓存过期表更新模块120，其中：

依赖接口查询模块110，被配置为执行响应于调用预设接口更改数据库中的目标数据，从预先获取的接口依赖关系表中查询依赖于所述预设接口的依赖接口，所述接口依赖关系表用于记录各个接口之间的依赖关系，所述预设接口包括用于增加、删除或修改数据的接口，所述依赖接口包括依赖于所述预设接口的用于获取数据的接口；

缓存过期表更新模块120，被配置为执行基于所述预设接口更改的目标数据，对本地存储的缓存过期表中所述依赖接口对应的内容进行更新，得到更新后的缓存过期表。

由上述描述可知，本实施例通过响应于调用预设接口更改数据库中的目标数据，从接口依赖关系表中查询依赖于所述预设接口的依赖接口，并基于所述预设接口更改的目标数据，对所述缓存过期表中所述依赖接口对应的内容进行更新，得到更新后的缓存过期表，可以实现及时维护本地存储的缓存过期表，进而可以实现后续基于该缓存过期表向用户提供数据，可以减少用户等待时间，进而可以提升用户体验，并且可以避免网络资源的浪费。

图8是根据又一示例性实施例示出的一种管理数据的装置的框图。本实施例的管理数据的方法可以用于服务端(如，一台服务器或多台服务器组成的服务器集群等)中，或者还可以用于终端设备(如，智能手机、平板电脑或台式电脑等)。其中，依赖接口查询模块210和缓存过期表更新模块220与前述图7所示实施例中的依赖接口查询模块110和缓存过期表更新模块120的功能相同，在此不进行赘述。如图8所示，在所述的管理数据的装置应用于服务端的情况下，所述的管理数据的装置，还可以包括：

缓存过期表发送模块230，被配置为执行向终端设备发送所述更新后的缓存过期表，以供所述终端设备以所述更新后的缓存过期表替换所述终端设备的本地存储的缓存过期表。

在一实施例中，管理数据的装置，还可以包括目标数据提供模块240；

目标数据提供模块240，可以包括：

目标接口查找单元241，被配置为执行响应于接收到用于调用目标接口获取目标数据的第一请求，从所述接口依赖关系表中查找所述目标接口；

第一数据检测单元242，被配置为执行响应于查找到所述目标接口，检测本地是否存在所述目标数据对应的第一缓存数据；

第一数据判断单元243，被配置为执行当存在所述第一缓存数据时，基于所述缓存过期表判断所述第一缓存数据是否有效；

第一数据提供单元244，被配置为执行当所述第一缓存数据有效时，将所述第一缓存数据作为目标数据提供给所述第一请求的发送方。

在一实施例中，目标数据提供模块240，还可以包括：

第二请求发送单元245，被配置为执行当不存在所述第一缓存数据或所述第一缓存数据存在但已失效时，向目标设备发送用于获取所述目标数据的第二请求，其中，在所述的管理数据的方法应用于终端设备的情况下，所述目标设备包括服务端；在所述的管理数据的方法应用于服务端的情况下，所述目标设备包括数据库；

第二数据提供单元246，被配置为执行将所述目标设备响应于所述第二请求返回的数据作为目标数据提供给所述第一请求的发送方，并作为所述目标数据的第二缓存数据存储于所述本地，并记录所述第二缓存数据的缓存时间。

在一实施例中，第一数据检测单元242还可以被配置为执行：

响应于查找到所述目标接口，判断所述目标接口的类型是否为获取数据的接口类型；

响应于所述目标接口的类型为获取数据的接口类型，检测所述本地是否存在所述目标数据对应的第一缓存数据。

在一实施例中，缓存过期表中可以包含数据库中所述目标数据的修改时间；

所述第一数据判断单元还被配置为执行：

获取所述第一缓存数据的缓存时间；

若所述缓存时间晚于所述修改时间，则确定所述第一缓存数据有效；

若所述缓存时间早于或等于所述修改时间，则确定所述第一缓存数据已失效。

在一实施例中，在所述的管理数据的装置应用于服务端的情况下，所述的管理数据的装置还包括依赖关系表生成模块250；

依赖关系表生成模块250，可以包括：

代码文件获取单元251，被配置为执行获取服务端代码文件，所述代码文件中包含各个接口与各个服务层的第一调用关系、所述各个服务层与各个数据访问层的第二调用关系以及所述各个数据访问层与各个数据库table的第三调用关系；

依赖关系确定单元252，被配置为执行基于所述第一调用关系、所述第二调用关系和所述第三调用关系确定所述各个接口与所述各个数据库table之间的依赖关系；

依赖关系表生成单元253，被配置为执行基于同一数据库table关联的多个接口之间的依赖关系生成接口依赖关系表。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

值得说明的是，上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。

本发明的管理数据的装置的实施例可以应用在网络设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的，其中计算机程序用于执行上述图1～图6B所示实施例提供的管理数据的方法。从硬件层面而言，如图9所示，为本发明的管理数据的设备的硬件结构图，除了图9所示的处理器、网络接口、内存以及非易失性存储器之外，所述设备通常还可以包括其他硬件，如负责处理报文的转发芯片等等；从硬件结构上来讲该设备还可能是分布式的设备，可能包括多个接口卡，以便在硬件层面进行报文处理的扩展。

另一方面，本申请还提供了一种计算机可读存储介质，当该存储介质中存储的计算机程序由管理数据的电子设备的处理器执行时，使得管理数据的电子设备能够执行上述图1～图6B所示实施例提供的管理数据的方法。

另一方面，本申请还提供了一种计算机程序产品，当该计算机程序产品由管理数据的电子设备的处理器执行时，使得管理数据的电子设备能够执行上述图1～图6B所示实施例提供的管理数据的方法。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种管理数据的方法，其特征在于，应用于终端设备或服务端，包括：

响应于调用预设接口更改数据库中的目标数据，从预先获取的接口依赖关系表中查询依赖于所述预设接口的依赖接口，所述接口依赖关系表用于记录各个接口之间的依赖关系，所述预设接口包括用于增加、删除或修改数据的接口，所述依赖接口包括依赖于所述预设接口的用于获取数据的接口；

基于所述预设接口更改的目标数据，对本地存储的缓存过期表中所述依赖接口对应的内容进行更新，得到更新后的缓存过期表。

2.根据权利要求1所述的管理数据的方法，其特征在于，在所述的管理数据的方法应用于服务端的情况下，所述的管理数据的方法，还包括：

向终端设备发送所述更新后的缓存过期表，以供所述终端设备以所述更新后的缓存过期表替换所述终端设备的本地存储的缓存过期表。

3.根据权利要求1所述的管理数据的方法，其特征在于，所述的管理数据的方法，还包括：

响应于接收到用于调用目标接口获取目标数据的第一请求，从所述接口依赖关系表中查找所述目标接口；

响应于查找到所述目标接口，检测本地是否存在所述目标数据对应的第一缓存数据；

若存在所述第一缓存数据，则基于所述缓存过期表判断所述第一缓存数据是否有效；

若所述第一缓存数据有效，则将所述第一缓存数据作为目标数据提供给所述第一请求的发送方。

4.根据权利要求3所述的管理数据的方法，其特征在于，所述的管理数据的方法，还包括：

若不存在所述第一缓存数据或所述第一缓存数据存在但已失效，则向目标设备发送用于获取所述目标数据的第二请求，其中，在所述的管理数据的方法应用于终端设备的情况下，所述目标设备包括服务端；在所述的管理数据的方法应用于服务端的情况下，所述目标设备包括数据库；

将所述目标设备响应于所述第二请求返回的数据作为目标数据提供给所述第一请求的发送方，并作为所述目标数据的第二缓存数据存储于所述本地，并记录所述第二缓存数据的缓存时间。

5.根据权利要求3所述的管理数据的方法，其特征在于，所述的响应于查找到所述目标接口，检测本地是否存在所述目标数据对应的第一缓存数据的步骤，包括：

响应于查找到所述目标接口，判断所述目标接口的类型是否为获取数据的接口类型；

响应于所述目标接口的类型为获取数据的接口类型，检测所述本地是否存在所述目标数据对应的第一缓存数据。

6.根据权利要求3所述的管理数据的方法，其特征在于，所述的缓存过期表中包含数据库中所述目标数据的修改时间；

所述的基于所述缓存过期表判断所述第一缓存数据是否有效的步骤，包括：

获取所述第一缓存数据的缓存时间；

若所述缓存时间晚于所述修改时间，则确定所述第一缓存数据有效；

若所述缓存时间早于或等于所述修改时间，则确定所述第一缓存数据已失效。

7.根据权利要求1所述的管理数据的方法，其特征在于，在所述的管理数据的方法应用于服务端的情况下，所述的管理数据的方法还包括基于以下步骤构建所述接口依赖关系表：

获取服务端代码文件，所述代码文件中包含各个接口与各个服务层的第一调用关系、所述各个服务层与各个数据访问层的第二调用关系以及所述各个数据访问层与各个数据库table的第三调用关系；

基于所述第一调用关系、所述第二调用关系和所述第三调用关系确定所述各个接口与所述各个数据库table之间的依赖关系；

基于同一数据库table关联的多个接口之间的依赖关系生成接口依赖关系表。

8.一种管理数据的装置，其特征在于，应用于终端设备或服务端，包括：

依赖接口查询模块，被配置为执行响应于调用预设接口更改数据库中的目标数据，从预先获取的接口依赖关系表中查询依赖于所述预设接口的依赖接口，所述接口依赖关系表用于记录各个接口之间的依赖关系，所述预设接口包括用于增加、删除或修改数据的接口，所述依赖接口包括依赖于所述预设接口的用于获取数据的接口；

缓存过期表更新模块，被配置为执行基于所述预设接口更改的目标数据，对本地存储的缓存过期表中所述依赖接口对应的内容进行更新，得到更新后的缓存过期表。

9.一种管理数据的电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至7中任一项所述的管理数据的方法。

10.一种存储介质，当所述存储介质中的指令由管理数据的电子设备的处理器执行时，使得管理数据的电子设备能够执行如权利要求1至7中任一项所述的管理数据的方法。

Images