Cache updating method and apparatus based on multi-level cache, and device and medium

Abstract

Provided in the present application are a cache updating method and apparatus based on a multi-level cache, and a device and a medium. The method comprises: if target cache data matching target service data is found in a first-level cache, determining a first cache existence duration of the target cache data on the basis of a cache duration determination sub-policy in an asynchronous cache update policy; if the first cache existence duration meets a valid cache determination sub-policy in the asynchronous cache update policy, generating an asynchronous refresh task, and submitting the asynchronous refresh task to a second-level cache by means of a first task deduplicator, wherein the asynchronous refresh task is used for instructing that the second-level cache be searched for cache update data used for updating the target cache data; and receiving the cache update data returned by the second-level cache by means of the first task deduplicator, and updating in the first-level cache the target cache data to the cache update data. By using the present application, the timeliness and reliability of cache updating can be improved.

Description

Cache updating method and device based on multi-level cache, equipment and medium

[0001] The present application claims priority from the Chinese patent application No. 2024108966786, filed on July 4, 2024, and entitled "Cache updating method and device based on multi-level cache, equipment and medium", the whole content of which is incorporated herein by reference. TECHNICAL FIELD

[0002] The present application relates to the technical field of Internet, and in particular to a cache updating method and device based on multi-level cache, equipment and medium. BACKGROUND

[0003] At present, in the cloud service scenario, the cloud server can store some hot data with high access frequency through the cache such as Remote Dictionary Server (redis) to store some hot data with high access frequency. In this way, when the cloud server is used to provide corresponding cloud service for some business clients, it can first find out whether there is hot data in the cache (for example, redis), if not, it needs to read a large amount of underlying data (for example, the authentication information of the users corresponding to these business clients) from the underlying module (for example, the underlying database, storage or other micro-service module) to refresh to the cache (for example, redis), so that the subsequent cloud service can be provided through the underlying data refreshed in the cache (for example, redis).

[0004] However, the inventors have found in practice that the cache (for example, redis) can be used to share most of the request load, but it is difficult to ensure the timeliness and reliability of cache updating to some extent. For example, the existing cache updating scheme indicates that the underlying data modified in the underlying module needs to be refreshed to the cache by a background task periodically in the case that the upper layer business modifies the underlying data. However, in the actual production environment, the refresh period for refreshing the underlying data to the cache may need tens of minutes or even hours, and once the underlying data changes again within the refresh period, it will be difficult to refresh the latest changed underlying data to the cache, thereby reducing the timeliness and reliability of cache updating. SUMMARY

[0005] The present application provides a cache updating method and device based on multi-level cache, equipment and medium, which can improve the timeliness and reliability of cache updating.

[0006] The embodiment of the application provides a cache updating method based on a multi-level cache, the multi-level cache comprises a first level cache and a second level cache, the second level cache is a next level cache of the first level cache, a search priority of the first level cache is higher than a search priority of the second level cache, and the method comprises the following steps:

[0007] obtaining a data acquisition request sent by a service client, searching for target cache data matched with target service data carried by the data acquisition request in the first level cache;

[0008] if the target cache data is found in the first level cache, obtaining an asynchronous cache updating strategy associated with the first level cache; the asynchronous cache updating strategy comprises a cache time length determination sub-strategy and a valid cache determination sub-strategy;

[0009] determining a first cache existing time length of the target cache data in the first level cache based on the cache time length determination sub-strategy;

[0010] if the first cache existing time length meets the valid cache determination sub-strategy, generating an asynchronous refreshing task, and submitting the asynchronous refreshing task to the second level cache through a first task deduplicator associated with the first level cache; the asynchronous refreshing task is used for instructing searching for cache updating data for updating the target cache data in the second level cache;

[0011] receiving the cache updating data returned by the second level cache through the first task deduplicator, and updating the target cache data to the cache updating data in the first level cache.

[0012] The embodiment of the application provides a cache updating device based on a multi-level cache, the multi-level cache comprises a first level cache and a second level cache, the second level cache is a next level cache of the first level cache, a search priority of the first level cache is higher than a search priority of the second level cache, and the device comprises the following steps:

[0013] a cache searching module, used for obtaining a data acquisition request sent by a service client, searching for target cache data matched with target service data carried by the data acquisition request in the first level cache;

[0014] an existing time length determining module, used for obtaining an asynchronous cache updating strategy associated with the first level cache if the target cache data is found in the first level cache; the asynchronous cache updating strategy comprises a cache time length determination sub-strategy and a valid cache determination sub-strategy;

[0015] the existing time length determining module is further used for determining a first cache existing time length of the target cache data in the first level cache based on the cache time length determination sub-strategy;

[0016] The asynchronous refreshing module is configured to generate an asynchronous refreshing task if the first cache exists for a time length satisfying the effective cache determination sub-strategy, and submit the asynchronous refreshing task to the second level cache through a first task deduplicator associated with the first level cache; the asynchronous refreshing task is configured to indicate to search for cache update data for updating target cache data in the second level cache;

[0017] The cache data updating module is configured to receive the cache update data returned by the second level cache through the first task deduplicator, and update the cache data to be updated to the cache update data in the first level cache.

[0018] In an aspect, the present application provides a computer device, comprising a memory and a processor, the memory being connected with the processor, the memory being configured to store a computer program, and the processor being configured to call the computer program to enable the computer device to execute the method provided in the above aspect.

[0019] In an aspect, the present application provides a computer readable storage medium, the computer readable storage medium storing a computer program, the computer program being adapted to be loaded and executed by a processor to enable a computer device having the processor to execute the method provided in the above aspect.

[0020] In an aspect, the present application provides a computer program product or a computer program, the computer program product or the computer program comprising computer instructions stored in a computer readable storage medium. A processor of a computer device reads the computer instructions from the computer readable storage medium, and the processor executes the computer instructions to enable the computer device to execute the method provided in the above aspect.

[0021] The multi-level cache can include a first level cache and a second level cache. It should be understood that the first level cache and the second level cache are any two adjacent level caches in the multi-level cache. Specifically, in the embodiments of the present application, the second level cache can be the next level cache of the first level cache, and the search priority of the first level cache is higher than that of the second level cache. For ease of understanding, the first level cache is taken as the current cache, and the second level cache is taken as the next level cache of the current cache. When the target cache data is found in the current cache, and the cache existence time length (i.e., the first cache existence time length) of the target cache data meets the effective cache determination sub-strategy in the asynchronous cache update strategy, how to submit the asynchronous refresh task generated in the first level cache to the second level cache through the task deduplicator (i.e., the first task deduplicator) associated with the current cache to find the cache update data for updating the target cache data in the second level cache is described. Specifically, when the computer device (such as a cloud server in a cloud service scenario) obtains a data acquisition request sent by a business client, it can first search the first level cache (such as the current cache) to determine whether there is target cache data matching the target business data carried by the data acquisition request. For example, if the target cache data is found in the first level cache (such as the current cache), the computer device (such as a cloud server in a cloud service scenario) can obtain an asynchronous cache update strategy associated with the first level cache (such as the current cache). The asynchronous cache update strategy can include a cache time length determination sub-strategy and an effective cache determination sub-strategy. Further, the computer device can determine the first cache existence time length of the target cache data in the first level cache (such as the current cache) based on the cache time length determination sub-strategy in the asynchronous cache update strategy. Further, the computer device can determine whether the first cache existence time length meets the effective cache determination sub-strategy in the asynchronous cache update strategy.For example, if it is determined that the first cache exists for a time length satisfying the valid cache determination sub-strategy, the computer device (such as a cloud server in a cloud service scenario) can further generate an asynchronous refresh task, and submit the asynchronous refresh task to the second level cache (such as the next level cache) through the first task deduplicator associated with the first level cache (such as the current cache). It can be understood that the asynchronous refresh task here can be used to indicate whether there is cache update data for updating the target cache data in the second level cache (such as the next level cache). It should be understood that the embodiments of the present application provide a task deduplicator between any two adjacent caches, for example, for the current cache and the next cache of the current cache, the task deduplicator deployed between the two adjacent caches for receiving and storing the asynchronous refresh task can be collectively referred to as the first task deduplicator associated with the current cache (for example, the first level cache). In this way, when the computer device generates an asynchronous refresh task in the first level cache, the asynchronous refresh task can be submitted to the first task deduplicator to determine whether there is a task in the task pool maintained by the first task deduplicator that is the same as the asynchronous refresh task and is dispatched to the next cache (that is, the second level cache) of the current cache. If so, the cache update data found by the dispatched asynchronous refresh task in the second level cache can be reused through the first task deduplicator, which means that at this time, the computer device can receive the cache update data returned by the second level cache through the first task deduplicator, and update the target cache data still in the valid state in the first level cache to the latest obtained cache update data. It should be understood that in the cloud service scenario, the first level cache can be used to provide cache lookup services for a large number of business clients. Therefore, when the computer device performs cache lookup for target business data requested by a business client and generates an asynchronous refresh task, the first task deduplicator can receive the asynchronous refresh task submitted by the first level cache. In this way, not only can the current cache (for example, the first level cache) continue to provide cache lookup services for other business clients, but also can avoid the instantaneous invocation pressure caused by repeated invocation and access of the second level cache by a large number of tasks the same as the asynchronous refresh task, thereby improving the efficiency of finding cache update data in the next cache in the process of updating the cache of the current cache. As can be seen, the embodiments of the present application can use a new asynchronous refresh mechanism to refresh the cache update data obtained from the second cache level to the current cache (that is, the first level cache) through the first task deduplicator before the target cache data stored in the first level cache is invalidated.In other words, in the embodiments of the present application, the computer device (such as a cloud server in a cloud service scenario) can improve the timeliness and reliability of cache updating through a brand-new asynchronous refreshing mechanism in the process of updating the target cache data cached in the current cache (i.e., the first level cache). BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0023] FIG. 1 is a structural schematic diagram of a network architecture provided by the present application;

[0024] FIG. 2 is a schematic diagram of a scenario of data interaction in a cloud service scenario provided by the embodiments of the present application;

[0025] FIG. 3 is a flow schematic diagram of a cache updating method based on multi-level cache provided by the present application;

[0026] FIG. 4 is a schematic diagram of a local data storage memory deployed in an access server provided by the embodiments of the present application;

[0027] FIG. 5 is a schematic diagram of a scenario of querying target service data in a current cache provided by the embodiments of the present application;

[0028] FIG. 6 is a flow schematic diagram of another cache updating method based on multi-level cache provided by the present application;

[0029] FIG. 7 is a schematic diagram of a scenario of traversing and updating each level of cache in multi-level cache in a preservation update manner provided by the embodiments of the present application;

[0030] FIG. 8 is a schematic diagram of a scenario of directly modifying underlying data in an underlying module provided by the embodiments of the present application;

[0031] FIG. 9 is a structural schematic diagram of a cache updating apparatus based on multi-level cache provided by the embodiments of the present application;

[0032] FIG. 10 is a structural schematic diagram of a computer device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0033] The concept of related technical terms involved in the embodiments of the present application will be described below:

[0034] One, a cache system, a system composed of multiple levels of cache, which can use multi-level cache technology to improve the performance of computer systems. In the embodiment of the application, the cache system refers to the setting of N levels of cache for data caching through multi-level cache technology, that is, different levels or different levels. Here N is a positive integer greater than or equal to 2. In this way, in the cloud service scenario, the cache system composed of N levels of cache can maximize the access efficiency of the cache data stored in the corresponding level of cache. It should be understood that the cache data refers to the data frequently accessed in the cloud server in the cloud service scenario when providing corresponding cloud services through the corresponding service process. The frequently accessed data refers to the data with an access frequency greater than a preset frequency threshold. In the embodiment of the application, the frequently accessed data can be collectively referred to as cache data and stored in N levels of cache.

[0035] In the embodiment of the application, each level of cache in the N levels of cache can correspond to a different service process. It should be understood that the service process refers to the process launched by a service program in the cloud service scenario for providing corresponding cloud services. In one implementation, these different service processes can be deployed in the same computer device (for example, a cloud server) to provide different cloud services.

[0036] Alternatively, in another implementation, these different service processes can also be independently deployed in different computer devices, which can be different cache service devices for providing different cloud services. For example, the first level of cache in the N levels of cache can correspond to a local access process closest to the upper business (here the upper business refers to the business provided to the business client), which can be deployed in an access server (that is, a cache server). For example, the next level of cache of the first level of cache can correspond to a distributed service process next closest to the upper business, which can be deployed in a distributed server (that is, another cache server) independent of the access server. By analogy, for other levels of cache in the N levels of cache, the service process corresponding to the other levels of cache can also be deployed in other cache servers. For example, the last level of cache in the N levels of cache can correspond to a database service process closest to the bottom module, which can be deployed in a database server (that is, another cache server). For ease of understanding, the embodiment of the application can collectively refer to each level of cache in the N levels of cache as a cache, and each cache is set (or configured) at different levels in the cache system, and the caches at different levels correspond to different service processes. Here, the service process corresponding to each cache (that is, each level of cache) in the N levels of cache will not be exemplified.

[0037] II. Multi-level cache, N-level cache arranged according to search priority (i.e. data access priority) of N different levels of cache. In the embodiments of the present application, the multi-level cache (i.e. N-level cache) can include a first level cache and a non-first level cache. Here, the non-first level cache refers to the other level caches in the multi-level cache except the first level cache.

[0038] For ease of understanding, the N-level cache can be L1 cache, L2 cache, L3 cache, …, L N cache, wherein the L1 cache can be the first level cache in the multi-level cache, and the N-1 level caches (e.g. L2 cache, L3 cache, …, L N cache) other than the L1 cache in the multi-level cache are non-first level caches in the multi-level cache. In addition, it can be understood that in the N-level cache, the L N cache can be the last level cache in the multi-level cache.

[0039] It can be understood that in the cache updating scheme involved in the embodiments of the present application, for ease of understanding, any two adjacent level caches in the N-level cache can be collectively referred to as a first level cache and a second level cache, wherein the second level cache refers to the next level cache of the first level cache, and the search priority of the first level cache is higher than that of the second level cache. In other words, the search priority (i.e. data access priority) of the cache data stored in the first level cache will be higher than that of the cache data stored in the second level cache. Wherein, if the first level cache is the L1 cache, the second level cache is the L2 cache; alternatively, if the first level cache is the L2 cache, the second level cache is the L3 cache, and so on.

[0040] Based on this, in order to ensure the timeliness provided by the upper layer service, when the cloud server (specifically, the processor in the cloud server) needs a certain data (i.e. target service data needed to provide the upper layer service), the first level cache (e.g. L1 cache) can be searched first in the cache system according to the above search priority. If the data searched is hit in the L1 cache (i.e. the data exists in the L1 cache), the data hit in the L1 cache can be directly used; otherwise, the second level cache (e.g. L2 cache) needs to be further searched, and so on.

[0041] Optionally, it should be understood that in the cloud service scenario, if the processor in the cloud server does not find the data after querying all caches in the multi-level cache, the data needs to be obtained from the underlying module. The underlying module here can be a data storage module where the corresponding business database is located. For example, the embodiments of the present application can further dispatch one or more data synchronization tasks from the business database associated with the multi-level cache through a de-duplicator (for example, a request de-duplicator such as Single flight) to obtain data, and put the obtained data into each level cache in a sequential update manner for future use.

[0042] The sequential update manner refers to that the processor in the cloud server can first put the data obtained from the underlying module into (i.e., write into) L N cache, and then put the data into (i.e., write into) L N-1 cache, and so on, until the data is put into (written into) the L1 cache.

[0043] III. Business database, a database used to provide data persistence storage service at the bottom. The business database here can include an underlying database, an underlying storage service, or other microservices. In the embodiments of the present application, if the processor in the cloud server does not find the data after querying all caches in the multi-level cache, the data needs to be obtained from the business database associated with the multi-level cache.

[0044] Among them, the database (Database) can be simply regarded as an electronic file cabinet (i.e., a place for storing electronic files), in the embodiments of the present application, the user can add, query, update, delete, etc. The data in the data file stored in the database. The so-called "database" is a collection of data stored together in a certain way, shared by multiple users, with as little redundancy as possible, and independent of application programs.

[0045] Among them, the database management system (English: Database Management System, DBMS for short) is a computer software system designed to manage databases, generally with basic functions such as storage, interception, security, backup, etc. The database management system can be classified according to the database model it supports, such as relational, XML (Extensible Markup Language, XML); or according to the type of computer it supports, such as server cluster, mobile phone; or according to the query language used, such as SQL (Structured Query Language, XQuery; or according to the performance focus, such as maximum size, highest speed; or other classification methods. Regardless of which classification method is used, some DBMSs can cross categories, such as supporting multiple query languages at the same time. For example, in the embodiments of the present application, the database management system can receive the data acquisition request forwarded by the last level cache in the multi-level cache forwarded by the deduplicator (for example, Single flight such as a request deduplicator), and identify the query language used by the acquired data acquisition request, and then the query language identified The data acquisition request can be parsed to extract the target business data (for example, business data under the corresponding business type) carried in the data acquisition request, and then the target business data (for example, business data under the corresponding business type) can be searched in the database managed by the database management system (that is, the above-mentioned business database).

[0046] Four, Single flight (that is, request or task deduplicator), Single flight here can be a request merger (also known as request deduplicator) for merging concurrent requests into a single request, in addition, Single flight here can also be another task deduplicator for task deduplication. Among them, in the embodiments of the present application, the task that needs to be deduplicated by the Single flight is an asynchronous flushing task, in addition, the concurrent request that needs to be merged by another Single flight is a data acquisition request for acquiring business data under a corresponding business type (that is, target business data) sent by a large number of clients (that is, a large number of business clients) through a cloud server in a cloud service scenario.

[0047] It can be understood that in the embodiments of the present application, in order to facilitate the distinction, the Single flight (i.e. task deduplicator) used for task deduplication can be collectively referred to as the first task deduplicator, and the Single flight (i.e. request deduplicator) used for request merging can be collectively referred to as the second task deduplicator. Specifically, for example, when the upper-layer service does not hit the cache due to cache invalidation, breakthrough, etc. (for example, the target cache data matching the target service data is not found in the last level cache in the multi-level cache), the lower-level module needs to be queried, and then the Single flight (i.e. the second task deduplicator) can be used for semaphore synchronization (here, the semaphore synchronization refers to request merging, for example, a large number of data acquisition requests for acquiring service data under the same service type can be merged into a single request, and the single request can be a target data acquisition request in a large number of data acquisition requests. This means that for a large number of data acquisition requests for acquiring service data under different service types, a plurality of single requests matching different service types can be obtained by merging respectively, and the task carried in the single request matching each service type is a data synchronization task marked in the task pool of the second task deduplicator, and a data synchronization task is essentially a request task in a target data acquisition request selected from a large number of data acquisition requests for finding target cache data). Only a small number of tasks (i.e. a small number of data synchronization tasks, which refer to request tasks indicated by data acquisition requests of different service types for finding target cache data matching service data under different service types) access the lower-level module, and other requests wait until the dispatched tasks (such as data synchronization tasks) retrieve data (such as target cache data) and refresh the cache, which can further notify all waiting tasks to use (i.e. can notify all other request tasks in the task pool of the second task deduplicator to reuse the retrieved target cache data). In this way, repeated calls to the lower-level module can be significantly reduced, thereby relieving the instantaneous pressure (i.e. instantaneous call pressure) of the lower-level module.

[0048] The asynchronous refresh task refers to a task generated for obtaining cache update data for updating (or refreshing) the target cache data from the next cache (i.e., the second level cache) of the current cache when the cache state of the target cache data found in the current cache (i.e., the first level cache) is a valid state. In the cloud service scenario involved in the embodiments of the present application, the service process corresponding to the current cache can request the cloud server (specifically, a processor in the cloud server) to allocate a service thread (i.e., an asynchronous refresh process) for asynchronous refreshing for the current cache, and then can call the asynchronous refresh process to generate an asynchronous refresh task for the target cache data, so that after the asynchronous refresh task is submitted to the first task deduplicator (here, the first task deduplicator can be a task deduplicator deployed between the current cache and the next cache) associated with the current cache, the service process corresponding to the current cache can continue to access the current cache, so that the accessed current cache can continue to provide data query services (e.g., cache query services) for other data acquisition requests sent by other business clients. It should be understood that at this time, the first task deduplicator can determine in the task pool it maintains whether there is a task identical to the asynchronous refresh task that has been dispatched to the next cache. If there is, the first task deduplicator can directly reuse the cache update data obtained from the next cache by the task that has been dispatched to the next cache. That is, the first task deduplicator involved in the embodiments of the present application can avoid the transient call pressure on the next cache caused by a large number of identical tasks in the asynchronous refresh tasks by task filtering of a large number of generated asynchronous refresh tasks, so that in the process of cache updating between any two adjacent caches, the search efficiency for searching the cache update data in the next cache can be effectively improved due to the avoidance of the transient call pressure, and the timeliness and reliability of cache updating can be improved when the target cache data is updated by the cache update data found quickly in the first level cache.

[0049] The data synchronization task can also be referred to as a synchronization refreshing task. The synchronization refreshing task refers to a request task marked in the task pool of the second task deduplicator and transmitted to the next cache, so as to find target cache data matching the target business data in the next cache (i.e., the second level cache), when the target cache data matching the target business data is not found in the current cache (i.e., the first level cache). For example, in the cloud service scenario involved in the embodiment of the present application, when the cloud server (specifically, a processor in the cloud server) does not find the target cache data in the first cache through the service process corresponding to the current cache, the cloud server can further submit a data acquisition request to the second task deduplicator, so that the second task deduplicator can further combine the data acquisition requests sent by a large number of business clients to obtain a single data acquisition request (for example, a target data acquisition request selected from a large number of data acquisition requests of the same business type), and mark the request task in the single data acquisition request as a data synchronization task and submit it to the next cache, so as to find the target cache data in the next cache according to the data synchronization task.

[0050] Five, cache operation, an operation performed on the cache. The cache operation can specifically include operations such as writing cache, reading cache, or deleting cache (i.e., clearing cache).

[0051] In the embodiment of the present application, writing cache refers to refreshing and writing the read data (such as data read from the next level cache) to the current cache (i.e., the current level cache) between multiple levels of caches according to the above order-preserving updating manner;

[0052] The reading cache refers to reading data from the current cache (i.e., the current level cache, for example, the L1 cache) according to the search priority in the multiple levels of caches. If the data is hit (i.e., read) in the current cache (i.e., the current level cache), the data can be directly read from the underlying module (i.e., the business database), thereby improving the data reading rate.

[0053] The deleting cache can include deleting or clearing certain cache data stored in a specified level cache, or deleting a certain type of cache data stored in multiple level caches. For example, in the embodiment of the present application, the database management system corresponding to the bottom module can receive an external service request (for example, an account information modification request for a service account, which can be target service data, and the account information modification request can be a write request for the target service data sent by the service client) forwarded by the processor in the cloud server and sent by the service client, and can modify the account data information corresponding to the service account of the service client in the bottom module (for example, a customer account database) according to the received account information modification request (for example, the account state of the service account of the service client can be modified). At this time, the account data information corresponding to the service account of the service client modified in the bottom module is the target cache data that can be updated in each level cache of the multi-level cache in a sequential update manner, so that the service client can be provided with data query service (i.e. cache query service) by the target cache data cached in each level cache.

[0054] In other words, in the bottom module, the account state (for example, Value, i.e. value) mapped by the service account of the service client (for example, Key, i.e. key) carried in the account information modification request can be found, and the found account state of the service account can be modified from the initial account state (for example, the old account data information of the service client is in the account overdue state) to the target account state (for example, the new account data information of the service client is in the account non-overdue state). In this way, when the account information of the service client in the bottom module changes, the processor in the cloud server can notify the service processes corresponding to each level cache in the multi-level cache of the account data information (for example, the account state of the service account of the service client can be modified) of the service client changed in the bottom module, so that each service process can delete the old cache data (i.e. initial cache data, for example, the old account data information of the service client) in the cache update process of each level cache, and then write new cache data (i.e. target cache data, for example, the new account data information of the service client) to prevent the phenomenon that the old cache data cached in the next level cache is refreshed back to the current cache in the subsequent reading process of the current cache.

[0055] It should be noted that all the data collected by the present application (i.e. target business data such as account data information of business clients and related data) is collected with the consent and authorization of the object to which the data belongs (such as a user, an enterprise or an institution), and the collection, use and processing of related data shall comply with relevant laws, regulations and standards of the country and region.

[0056] Further, please refer to FIG. 1, which is a structural schematic diagram of a network architecture provided by the present application. As shown in FIG. 1, the network architecture can include a server 100a and a terminal device cluster, which can include one or more terminal devices, and the number of terminal devices will not be limited here. As shown in FIG. 1, the plurality of terminal devices can specifically include terminal device 200a, terminal device 200b, …, terminal device 200n; as shown in FIG. 1, terminal device 200a, terminal device 200b, …, terminal device 200n can all be connected to server 100a in a network connection, so that each terminal device can interact with server 100a through the network connection.

[0057] It should be understood that in the cloud service scenario, the server 100a here can be the cloud server described above. The cloud service scenario here can include but is not limited to the medical cloud service scenario, the cloud game service scenario, the cloud education service scenario, the cloud conference service scenario, and the cloud social service scenario.

[0058] For example, in the medical cloud service scenario, medical personnel between medical institutions can achieve rapid resource sharing of medical resources through multi-level caching. For example, as shown in FIG. 1, the server 100a can receive a data acquisition request for acquiring target business data (for example, acquiring medical resources in the medical cloud service scenario through the business account information of the business object) sent by the business object (for example, medical personnel under each medical institution) through the business client (for example, the medical cloud client) on the corresponding terminal device (for example, terminal device 200a) in the terminal device cluster, and then based on the data acquisition request, the server 100a can preferentially search for cache resources matching the target business data (for example, medical resources such as electronic diagnosis information and electronic prescription information of patients) from the multi-level cache (for example, the L1 cache) associated with the server 100a, so that the found cache resources can be collectively referred to as target cache data. It should be understood that the target business data can specifically include one or more of business identifiers (for example, business account information of the business object) and business types (for example, medical resources of medical types in the medical cloud service scenario).

[0059] Optionally, it should be understood that, in the application embodiment itself, in order to further ensure the security and reliability of the target business data (for example, medical resources) acquisition, the server 100a involved in the application embodiment can also perform object authentication on the business object sending the data acquisition request before searching for the cached resource matching the target business data (for example, medical resources) in the multi-level cache, obtain an object authentication result, and then authorize the business object to acquire the target business data (for example, medical resources) when the object authentication result indicates that the object authentication is successful.

[0060] For example, the server 100a can perform object authentication (that is, identity authentication and / or access authentication) on the business object (for example, medical staff) sending the data acquisition request based on the request task (for example, identity authentication task and / or access authentication task) for the target business data (for example, medical resources) carried in the data acquisition request. Specifically, the server 100a searches the multi-level cache (for example, the L1 cache described above) to determine whether there is registered account data information (that is, target cached data) matching the business account information of the business object (for example, medical staff) currently submitted by the business object (that is, target business data, for example, access account data information entered by the business object when accessing the medical cloud client). If the multi-level cache (for example, the L1 cache described above) is hit (that is, the multi-level cache finds registered account data information matching the business account information currently submitted by the business object), an object authentication result when the object authentication is successful can be obtained, and the business object can be authorized to further acquire the target business data (for example, medical resources) through the multi-level cache when the object authentication result indicates that the object authentication is successful.

[0061] For another example, in a cloud game service scenario, resource sharing (for example, specifically, sharing resource acquisition) of game resources (for example, game scene rendering resources or character texture rendering resources) stored on a cloud server can be realized among game players. For example, the server 100a shown in FIG. 1 can receive data acquisition requests for acquiring target business data (for example, texture resources) requested by each game player sent by each business object (for example, each game player) through a business client (for example, a cloud game client) on a corresponding terminal device (for example, a terminal device 200a) in a terminal device cluster, and then can search for cached resources matching the target business data (for example, texture resources, such as scene texture resources in a certain cloud game) from the multi-level cache (for example, the L1 cache described above) associated with the server 100a based on the data acquisition request, so that the found cached resources can be collectively referred to as target cached data.

[0062] By analogy, in the cloud education service scenario, the registered object resources (for example, the registered account data information submitted by each business object during account registration) matched with the access object resources submitted by each business object can be obtained through multi-level caching, and then the identity authentication of each business object can be implemented through the obtained registered object resources. For example, as shown in FIG. 1, the server 100a can receive a data acquisition request for acquiring target business data (for example, authentication data information, that is, the authentication data information can be registered account data information matched with the access account information submitted by each student) sent by each business object (for example, each student) through a business client (for example, a cloud education client) on a corresponding terminal device (for example, terminal device 200a) in the terminal device cluster, and then based on the data acquisition request, the server 100a can preferentially search for cached resources matched with the target business data (for example, registered account data information) from the multi-level cache (for example, the L1 cache) associated with the server 100a, so that the found cached resources can be collectively referred to as target cached data. In this way, the server 100a can further execute the request task (for example, an identity authentication task for identity authentication) carried in the data acquisition request based on the target cached data in the process of providing object storage service, and then the authentication result when the identity authentication is successful can be taken as the task execution result (that is, business processing result) obtained by executing the request task. At this time, the server 100a can return the business processing result to the business client, so that the business client can subsequently acquire (that is, access to) the education resources in the cloud education service scenario based on the business processing result, and display the education resources on the business client (for example, the cloud education client).

[0063] It should be understood that the specific processing mode of the identity authentication of the business object in the cloud conference service scenario and the cloud social service scenario can refer to the specific processing mode of the identity authentication of the business object in the cloud education service scenario, which will not be listed one by one.

[0064] It should be understood that the server 100a shown in FIG. 1 can be a stand-alone physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs, and big data and artificial intelligence platforms, and the like. Basic cloud computing services.

[0065] In addition, the terminal devices in the terminal device cluster can include smart phones, tablet computers, notebook computers, palm computers, mobile internet devices (MIDs), wearable devices (for example, smart watches, smart bands, and the like), smart voice interaction devices, smart home appliances (for example, smart televisions, and the like), vehicle-mounted devices, and the like.

[0066] For ease of understanding, here, taking at least two levels of caches in the multi-level cache as an example, a specific process of implementing cache updating (for example, asynchronous updating) between the two levels of caches through an asynchronous flushing mechanism is described. Further, please refer to FIG. 2, which is a scene diagram of data interaction in a cloud service scenario according to an embodiment of the present application. As shown in FIG. 2, the two levels of caches in the multi-level cache can specifically be the L1 cache and the L2 cache shown in FIG. 2. Here, the two levels of caches refer to any two adjacent levels of caches in the multi-level cache.

[0067] It can be understood that the cloud server 22a shown in FIG. 2 can be a service device cluster (in nature, a cache service device cluster corresponding to the cache system) for providing different cloud services. In the service device cluster (that is, the cache service device cluster), the cache service device corresponding to the L1 cache can be an access server in the cloud server 22a. Similarly, the cloud service device (that is, another cache device) corresponding to the L2 cache can be a distributed server in the cloud server 22a.

[0068] As shown in FIG. 2, for the upper-layer service (for example, cloud game service) provided by the cloud server 22a in the cloud service scenario (for example, cloud game service scenario), to ensure the timeliness of the execution of the upper-layer service (for example, cloud game service), the present embodiment proposes that the cache data for providing the cloud game service, which is obtained in advance from the bottom-layer module (that is, the service database), can be stored in the multi-level cache (for example, the L1 cache and the L2 cache shown in FIG. 2). In this way, when the cloud server 22a obtains a certain external service request (for example, the data acquisition request 1 shown in FIG. 2) sent by a certain terminal device (for example, the terminal device 21a shown in FIG. 2) running a service client, the cloud server 22a can find, based on the data acquisition request 1, cache data matching the target service data (for example, the service data A11 shown in FIG. 2, for example, game resources) requested by the service object (for example, the user U1 shown in FIG. 2) through the service account information (for example, the account 1 shown in FIG. 2) in the multi-level cache. Specifically, the cloud server 22a can find, based on the data acquisition request 1, cache data matching the target service data (for example, the service data A11 shown in FIG. 2, for example, game resources, that is, service data of a game type) requested by the service object (for example, the user U1 shown in FIG. 2) through the service account information (for example, the account 1 shown in FIG. 2) in the multi-level cache.

[0069] For example, as shown in FIG. 2, the cloud server 22a (for example, specifically a local access process corresponding to an L1 cache in the cloud server 22a) can perform request analysis on the currently received data acquisition request 1 to parse the to-be-queried data information (that is, target service data, for example, the account 1 selected by the user U1 in FIG. 2 for which the user U1 needs to query, and the service data A11 corresponding to the account 1 (for example, game resources needed by the user U1 when running cloud games) entered by the user U1 on the service display interface 20a from the data acquisition request 1. In this way, when the user U1 needs to query the to-be-queried data information in the service display interface 20a, the terminal device 21a can add the to-be-queried data information to the data acquisition request 1 and send the data acquisition request 1 to the cloud server 22a. Then, the cloud server 22a can obtain the account 1 and the service data A11 requested by the account 1 from the to-be-queried data information carried in the data acquisition request 1.

[0070] As shown in FIG. 2, the service data A11 here can be service data information entered by the user U1 (for example, a game player) for loading a specific game service, for example, the user U1 can query the game texture resources needed when loading a corresponding game scene through the account 1.

[0071] Optionally, as shown in FIG. 2, the service data A11 here can also be service data information entered by the user U1 (for example, a game player) for querying a virtual asset state, for example, the user U1 can query the virtual asset state information (for example, whether there is available virtual asset, etc.) of the user U1 under the corresponding cloud game through the account 1.

[0072] Optionally, as shown in FIG. 2, the service data A11 here can also be service data information entered by the user U1 (for example, a game player) for querying an account attribute state, for example, the user U1 can query the account permission state information (for example, whether it is a game member, etc.) of the user U1 under the corresponding cloud game through the account 1.

[0073] Specifically, as shown in FIG. 2, the cloud server 22a can access the L1 cache in the multi-level cache (e.g., two-level cache) through the local access process, and then can find (e.g., read) in the L1 cache (e.g., the local memory of the local access process) whether there is an account (i.e., a target cache data) matching the service account data information (i.e., a target service data, such as the account 1 shown in FIG. 2) requested by the user U1, and if so, can further find in the L1 cache (e.g., the local memory of the local access process) whether there is cache data (i.e., another target cache data, such as the cache data P11 shown in FIG. 2) matching another target service data (e.g., the service data A11 shown in FIG. 2) requested by the user U1 through the account 1.

[0074] For example, as shown in FIG. 2, when the cloud server 22a finds in the L1 cache through the local access process that there is cache data P11 matching the service data A11 requested by the account 1, the cloud server 22a can generate an asynchronous refresh task based on the asynchronous cache update strategy, and then can submit the generated asynchronous refresh task to the first task deduplicator, so that the first task deduplicator can notify another service process (e.g., the above-mentioned distributed service process) to find in the L2 cache (e.g., redis) of the multi-level cache (e.g., two-level cache) whether there is cache update data P11' for refreshing (i.e., updating) the cache data P11. It should be understood that if the cloud server 22a finds in the L2 cache that there is cache update data P11' for refreshing (i.e., updating) the cache data P11, the found cache update data P11' can be asynchronously updated to the L1 cache through the first task deduplicator to achieve asynchronous refreshing (i.e., asynchronous updating) of the L1 cache. It should be understood that the asynchronous updating here refers to an updating mode in which the cache data P11 in the L1 cache is updated to the cache update data P11' in advance when the cache data P11 in the L1 cache has validity (i.e., the cache state of the cache data P11 in the L1 cache is valid). It should be understood that the present application can improve the timeliness of cache updating through the asynchronous updating mode (i.e., the above-mentioned asynchronous updating mechanism), and thus can ensure that the cache data updated and cached in the L1 cache always has validity and reliability, so that when the upper service provides data query service through the cache data with validity cached in the L1 cache, the timeliness of data query can be ensured.

[0075] Optionally, for example, as shown in FIG. 2, when the cloud server 22a does not find the cache data P11 matching the service data A11 requested by the account 1 in the L1 cache through the local access process, it can be determined that the cache data P11 does not exist in the L1 cache, and then the data acquisition request 1 currently acquired by the service process (for example, the above-mentioned local access process) corresponding to the L1 cache can be synchronously forwarded to the service process (for example, the above-mentioned distributed service process) corresponding to the L2 cache through the second task deduplicator shown in FIG. 2, so that the service process (for example, the above-mentioned distributed service process) corresponding to the L2 cache can further query whether the cache data P11 exists in the L2 cache, and then when it is found that the cache data P11 exists in the L2 cache, it can be further determined whether the cache data P11 stored in the L2 cache is valid, so that when the cache data P11 stored in the L2 cache is valid, the found cache data P11 with validity can be synchronously updated to the L1 cache, so as to realize the synchronous refreshing of the L1 cache.

[0076] It can be understood that in the identity authentication scenario, the service data A11 can be the service data information (for example, password authentication data information, biometric authentication data information, two-dimensional verification code information, etc.) entered by the user U1 (for example, a game player) for identity authentication (or identity authentication).

[0077] For example, in the cloud game service scenario, in order to ensure the security and reliability of the acquisition of game resources in the cloud game service scenario, it is proposed that before the business object (for example, the user U1 shown in FIG. 2) enters a certain cloud game (for example, cloud game X) through the business client, the user U1 accessing the cloud game X can be authenticated by identity authentication, and then in the process of identity authentication, the target service data (for example, the authentication signature information corresponding to the account 1 and password authentication data information entered by the user U1 in the game login interface) to be queried can be preferentially acquired from another data acquisition request (for example, a game access request for requesting access to the cloud game). In this way, when the cloud server 22a acquires another data acquisition request (for example, a game access request for requesting access to the cloud game), it can preferentially find the cache data matching the service data (that is, the target service data, for example, the authentication signature information corresponding to the account 1 and password authentication data information entered by the user U1 in the game login interface) for identity authentication of the business object (for example, the user U1 shown in FIG. 2) in the multi-level cache based on another data acquisition request.

[0078] For example, the cached data in this case can be a key-value pair (e.g., the key can be the account 1, and the value can be the authentication signature information corresponding to the password authentication data information) of the business account information indicated by the business account information in the underlying module (e.g., the underlying module in this case can specifically refer to the business database corresponding to the object storage server) and cached in the two-level cache (e.g., the L1 cache and the L2 cache shown in FIG. 2). For example, the key-value pair of the business account information in the underlying module can refer to the above-mentioned registration account data information (e.g., the account 1 and the authentication signature information corresponding to the password authentication data information) submitted by the user U1 to the business database corresponding to the object storage server for data storage when registering the cloud game X through the cloud game client.

[0079] In other words, in the embodiments of the present application, the registration account data information cached in the multi-level cache (e.g., two-level cache) can be used as target cache data for indirectly providing object storage services in the cloud server 22a, which means that at this time, the cloud server 22a can temporarily replace the underlying module (e.g., the business database corresponding to the object storage server) to provide object storage services through the target cache data cached in the multi-level cache.

[0080] It should be understood that in the embodiments of the present application, if the cloud server 22a does not hit in the multi-level cache (e.g., the L1 cache and the L2 cache in the two-level cache shown in FIG. 2), it can be further determined that the data acquisition request 1 submitted by the business object (e.g., the user U1 shown in FIG. 2) is a cold read request, and therefore the registration account data information (e.g., the account 1 and the authentication signature information corresponding to the password authentication data information) of the business object can be obtained from the underlying module (e.g., the IAM database, which is a kind of business database for providing identity recognition and access management services in the object storage server) through the Single flight (i.e., the second task deduplicator, e.g., the request deduplicator for request merging described above) associated with the last layer of cache (e.g., the L2 cache) in the multi-level cache, so as to realize the identity authentication of the business object sending the data acquisition request 1 through the registration account data information obtained from the IAM database, and then the current obtained data acquisition request can be determined as a legal request when the identity authentication is successful. At this time, the cloud server 22a can authorize the business object (e.g., the user U1 shown in FIG. 2) to obtain cloud service data in the corresponding cloud service scenario. For example, in the cloud game service scenario, the business client can be allowed to access the cloud game, and the game data corresponding to the cloud game can be returned to the business client, so that the game player can see the game screen corresponding to the game data on the business client.

[0081] It should be understood that for the multi-level cache containing other levels of cache in addition to the L1 cache and the L2 cache, the description of the specific process of implementing cache asynchronous flushing between the two levels of cache shown in the above Figure 2 can still be referred to; this means that for any two adjacent levels of cache in the multi-level cache of the cloud server, cache updating can be performed through the asynchronous flushing mechanism, and the specific process of cache updating between any two adjacent levels of cache can be referred to the embodiments corresponding to Figures 3-8.

[0082] Further, please refer to Figure 3, which is a flowchart of a cache updating method based on a multi-level cache provided by the present application. In the cloud service scenario, the cache updating method based on the multi-level cache can be executed by the cloud server, and the cloud server here can be the cloud server 22a shown in the above Figure 2. Among them, the multi-level cache can include a first level of cache and a second level of cache, and the second level of cache is the next level of cache of the first level of cache, and in addition, the search priority of the first level of cache is higher than that of the second level of cache. As shown in Figure 3, the method can at least include steps S101-S105:

[0083] Step S101, obtaining a data acquisition request sent by a business client, searching for target cache data matching target business data carried by the data acquisition request in the first level of cache;

[0084] Specifically, when the cloud server obtains the data acquisition request sent by the business client for acquiring the target business data, it can search for the target cache data matching the target business data in the first level of cache based on the data acquisition request; wherein the data acquisition request here can be a read request for reading the target business data.

[0085] It should be understood that in the embodiments of the present application, if the cloud server is a server cluster for providing different cloud services, for the cache system constituted by the multi-level cache, since different levels of cache correspond to different service processes, and these service processes can be deployed on different computer devices, therefore, the cloud server here can at least include a first cache server (for example, the above access server) corresponding to the first level of cache (for example, the above L1 cache) and a second cache server (for example, the above distributed server) corresponding to the second level of cache (for example, the above L2 cache).

[0086] It can be understood that in the embodiments of the present application, if the first level of cache includes the first level of cache in the multi-level cache, for example, at this time, if the first level of cache is the above L1 cache closest to the upper business in the cloud service scenario, the cloud server can be equivalent to the access server corresponding to the first level of cache (for example, the above L1 cache) when executing step S101 when executing step S101.

[0087] Specifically, if the first level cache includes a first level cache in the plurality of level caches (e.g., the L1 cache described above), the access server can specifically include the first level cache and a local access process associated with the first level cache; at this time, the storage memory corresponding to the first level cache (e.g., the L1 cache described above) can be collectively referred to as the local data storage memory of the access server. In this way, the cloud server (e.g., the access server) can receive a data read request (i.e., the external service request described above) sent by the service client for reading target service data through the local access process, and then the data read request can be used as a data acquisition request acquired by the local access process; further, the cloud server (e.g., the access server) can search for target cache data matching the target service data in the local data storage memory based on the data acquisition request, for example, specifically, the cloud server (e.g., the access server) can read the target service data in the local data storage memory based on the data acquisition request, and search for target cache data matching the target service data in the local data storage memory.

[0088] For ease of understanding, further, please refer to FIG. 4, which is a scene diagram of a local data storage memory deployed in an access server according to an embodiment of the present application. As shown in FIG. 4, the cache system shown in FIG. 4 includes N (N is a positive integer greater than or equal to 2) levels of caches, which specifically can include an L1 cache, an L2 cache, …, an LN cache. N-1 The L1 cache and the L2 cache. N The L1 cache and the L2 cache.

[0089] As shown in FIG. 4, when the first level cache is the L1 cache, the service process corresponding to the L1 cache can be the local access process described above, which can be deployed in the access server 41b shown in FIG. 4, wherein the local data storage memory corresponding to the local access process can be the L1 cache shown in FIG. 4.

[0090] As shown in FIG. 4, it can be understood that when the business client (for example, the business client 41a shown in FIG. 4) sends a data read request for obtaining (for example, reading) target business data to the cloud server, specifically, the business client (for example, the business client 41a shown in FIG. 4) can be equivalent to sending a data read request for obtaining (for example, reading) target business data to the access server 41b shown in FIG. 4, at this time, the access server can take the received data read request as the data acquisition request in the above-mentioned step S101 through the local access process, and perform request analysis on the data acquisition request to obtain the target business data requested by the business object (for example, the target business data here can be the business data A11 shown in FIG. 2) through analysis. Then, the local access process can access the local data storage memory (for example, the L1 cache shown in FIG. 4) of the access server 41b shown in FIG. 4, and then determine whether the target business data requested by the business object can be read in the local data storage memory (for example, the L1 cache shown in FIG. 4), if the determination is yes, further search for target cache data matching the currently read target business data in the local data storage memory (for example, the L1 cache shown in FIG. 4).

[0091] Optionally, the data acquisition request analyzed by the local access process can also be a fee status query request in a cloud service scenario, which can be used to instruct the cloud server (for example, the access server 41b shown in FIG. 4) to query whether there is fee status information of the business object (for example, the user U1 shown in FIG. 2) in the L1 cache in the cloud service scenario, where the fee status information is the above-mentioned target cache data, and the business account information (for example, the account 1 of the user U1) corresponding to the fee status information is the above-mentioned target business data.

[0092] As shown in FIG. 4, if the access server 41b queries the fee status information of the business object (for example, the user U1 shown in FIG. 2) in the L1 cache through the local access process (that is, the account 1 corresponding to the user U1 is in the business data information of the overdue state), it can be determined that the target cache data matching the target business data is found in the first level cache, and then the following step S102 can be continued.

[0093] Optionally, it is understood that, as shown in Figure 4, if the access server 41b does not find the service object (e.g., user U1 as shown in Figure 2) in the L1 cache through the local access process, the service object's (i.e., the service data information of account 1 corresponding to user U1 being in arrears) in the cloud service scenario, the service object's (i.e., the service object's) fee status query request (i.e., the data acquisition request) currently obtained by the access server 41b can be further forwarded to the next level cache of the L1 cache (i.e., the second level cache, e.g., the L2 cache shown in Figure 4) through the second task deduplication device associated with the L1 cache, so that the service process corresponding to the L2 cache (i.e., the cache service process, e.g., the distributed service process mentioned above) can continue to provide the lookup service (e.g., data query service) for finding the target cache data.

[0094] Similarly, as shown in Figure 4, if the cloud server uses L... N-1 The service process corresponding to the cache is not in L N-1 If the service object (e.g., the new first-level cache, which can be a non-first-level cache in the multi-level cache, such as the L3 cache when N=4) is found in the cache (i.e., the new first-level cache, which can be a non-first-level cache in the multi-level cache, such as the L3 cache when N=4), then the L3 cache can be used to retrieve the service object's (e.g., the user U1 shown in Figure 2 above) billing status information (i.e., the target cache data, such as the business data information of account 1 corresponding to user U1 being in arrears) in this cloud service scenario, then the L3 cache can be retrieved. N-1 The service process corresponding to the cache currently obtains the tariff status query request (i.e., data retrieval request), and further communicates with the L... N-1 The second task deduplicator associated with the cache forwards the request to the L. N-1 The next level of cache (i.e., the new second-level cache, for example, L shown in Figure 4) N Caching, for example, could be an L4 cache when N=4, so that the service process corresponding to the L4 cache (i.e., a new cache service process, such as the database service process mentioned above) can continue to provide lookup services (e.g., data query services) for finding target cached data.

[0095] It is understandable that when N=4, if the billing status information (i.e., target cache data, such as the business data information that the account 1 corresponding to user U1 is in arrears) of the business object (e.g., user U1 shown in Figure 2 above) is not found in any of the four cache levels, the billing status query request (i.e., data acquisition request) currently obtained by the service process corresponding to the L4 cache (i.e., the last cache in the multi-level cache) can be further forwarded to the underlying module through the second task deduplication device associated with the L4 cache, so that the underlying module can continue to provide the search service for finding the target cache data.

[0096] Therefore, in the cache updating process, the embodiments of the present application can pre-deploy (or configure) task deduplicators adapted to different tasks between any two adjacent caches (for example, the current cache and the next cache). For example, the embodiments of the present application can deploy a first task deduplicator adapted to the above-mentioned asynchronous refreshing task between any two adjacent caches, and can also deploy a second task deduplicator adapted to the above-mentioned data synchronization task between any two adjacent caches, so as to reduce the instantaneous calling pressure when calling the next cache through the deployed task deduplicator, thereby improving the efficiency of querying the target cache data or cache updating data in the next cache. Based on this, for the cache system 4a shown in FIG. 4, the task deduplicators adapted to different tasks can be used to deduplicate different tasks. Thus, for the process of refreshing the cache updating data obtained from the next cache to the current cache by means of asynchronous updating, it can be ensured that only a small number of asynchronous refreshing tasks can be submitted to the next cache. Similarly, for the process of traversing the target cache data in each next cache by means of synchronous updating, it can be ensured that the number of data synchronization tasks finally traversed and transmitted to each next cache presents a trend of being able to decrease in turn. Thus, for the last layer cache in the cache system 4a shown in FIG. 4, it can finally be realized that only a small number of single requests of different business types can be transmitted to the L N cache. Similarly, by analogy, task deduplicators adapted to different tasks can also be deployed between the last layer cache and the underlying module of the cache system 4a.

[0097] Optionally, it can be understood that when N=2, if the service object (for example, the user U1 shown in FIG. 4) is not queried in the 2-level caches (for example, the L1 cache and the L2 cache shown in FIG. 4) in the cloud service scenario (i.e., the target cache data, for example, the service data information of the account 1 corresponding to the user U1 in the state of arrears), the L2 cache is the last layer cache in the multi-level cache, and therefore the service process currently obtained by the L2 cache (i.e., the last layer cache in the multi-level cache) corresponding to the service process The fee state query request (i.e., the data acquisition request) is forwarded to the underlying module through the second task deduplicator associated with the L2 cache, so as to further continue to provide the search service for searching the target cache data through the underlying module.

[0098] In other words, if the second level cache includes a distributed cache (for example, the above-mentioned L2 cache) associated with a cache service process, and the distributed cache is the last layer cache of the multi-level cache, and the cache service process is a service process different from the local access process;

[0099] At this time, if the target cache data is not found in the local data storage memory, the cloud server can submit a data acquisition request to the cache service process (here, the cache service process can be the distributed service process described above, which can be a service process deployed in a distributed server, and here, the distributed server can be a cache server different from the access server). Here, the data acquisition request can further be used to instruct the cache service process to find the target cache data in the second level cache, and when the target cache data is not found, the data acquisition request can be determined as a cold read request, and the target cache data can be acquired in the business database associated with the multi-level cache based on the cold read request. For example, the distributed server can send the cold read request to the second task deduplicator, so that the second deduplicator acquires the target cache data in the underlying module (i.e., the business database associated with the multi-level cache) based on the cold read request.

[0100] Optionally, it can be understood that for the access server 41b, a data synchronization write request for the target cache data sent by the cache service process can also be received; here, the data synchronization write request is generated by the cache service process when the target cache data is acquired from the business database and successfully written into the distributed cache; further, the access server 41b can also write the target cache data into the local data storage memory based on the data synchronization write request, so that the target cache data can be directly queried in the local data storage memory of the access server 41b when a new data acquisition request is acquired.

[0101] Step S102, if the target cache data is found in the first level cache, an asynchronous cache update strategy associated with the first level cache is acquired; the asynchronous cache update strategy includes a cache duration determination sub-strategy and an effective cache determination sub-strategy;

[0102] Specifically, if the target cache data is found in the first level cache, the cloud server can acquire an asynchronous cache update strategy associated with the first level cache.

[0103] Step S103, determining a first cache existence duration of the target cache data in the first level cache based on the cache duration determination sub-strategy;

[0104] Specifically, the cloud server can determine a cache time length determination sub-strategy from the asynchronous cache update strategy, and then can obtain a cache write parameter and a cache system parameter based on the cache time length determination sub-strategy, determine a parameter value of the cache write parameter as a first cache write timestamp, and determine a parameter value of the cache system parameter as a system timestamp of a cache system where the multi-level cache is located; wherein the cache write parameter refers to a time parameter for inserting the target cache data extracted from the write log of the first level cache into the first level cache, and the cache system parameter refers to a time parameter currently recorded in real time by the cache system where the multi-level cache is located; further, the cloud server can determine a time difference between the system timestamp and the first cache write timestamp as a first cache existing time length of the target cache data in the first level cache.

[0105] For ease of understanding, hereinafter, taking N level caches as 3 level caches as an example, further, please refer to FIG. 5, which is a scene diagram of querying target service data in a current cache according to an embodiment of the present application. Among them, the 3 level caches can be the last cache, the current cache and the next cache of the current cache shown in FIG. 5. For ease of understanding, hereinafter, taking the L2 cache shown in FIG. 4 as an example, at this time, the last cache (i.e. the last level cache) of the L2 cache can be the L1 cache, and by analogy, the next cache (i.e. the next level cache) of the L2 cache can be the L3 cache.

[0106] It should be understood that in the embodiments of the present application, the last cache and the current cache can constitute a two-level cache including the first level cache and the second level cache, wherein the current cache is the next level cache of the last cache. Similarly, the current cache and the next cache can also constitute another two-level cache including the first level cache and the second level cache, wherein the next cache is the next level cache of the current cache.

[0107] As shown in FIG. 5, when the cloud server does not find the target cache data matching the target service data in the last cache (for example, the L1 cache), it can perform step S10 (i.e. forwarding the data acquisition request for acquiring the target service data to the current cache), for example, the cloud server can forward the data acquisition request (for example, the data acquisition request 1 shown in FIG. 2) currently acquired by the service process (for example, the local access process corresponding to the L1 cache) of the last cache to the service process (i.e. the cache service process, for example, the distributed service process) corresponding to the current cache (for example, the L2 cache) through the second task deduplicator (for example, the Single flight) associated with the last cache (for example, the L1 cache), so that the cache server (for example, the distributed server) corresponding to the distributed service process can access the current cache in priority to further perform step S11 (performing a search in the current cache).

[0108] For example, a cloud server (e.g., a distributed server in a cloud server) can search in the current cache (e.g., an L2 cache, where the first-level cache is not the first level cache among multiple levels of cache) to determine whether the target business data requested by the user can be read in the current cache. If the target business data requested by the user can be read in the current cache, step S12 (i.e., determining whether there is target cache data that matches the target business data requested by the user) can be further executed. If it is determined that there is target cache data that matches the target business data requested by the user in the current cache, then step S13 (obtaining the cache duration of the target cache data in the current cache) can be further executed.

[0109] It can be understood that for any two adjacent cache levels forming a two-level cache, where the current cache (e.g., L2 cache) is the first-level cache and the next cache after the current cache (e.g., L3 cache) is the second-level cache, the cache duration of the target cache data in the first-level cache can be collectively referred to as the first cache duration. Similarly, the cache duration of the target cache data in the second-level cache can also be collectively referred to as the second cache duration.

[0110] It should be understood that in the embodiments of this application, when a data acquisition request (e.g., a read request) for reading target business data arrives (i.e., is transmitted to) the current cache (i.e., the cache layer) from the upper layer (i.e., the upper cache layer shown in Figure 5), it can be determined whether the target business data can be read in the current cache (i.e., query the current cache). If the target business data is read, it can be further queried whether there is target cache data in the current cache (i.e., query the current cache) that matches the target business data carried in the read request (i.e., the data acquisition request). If there is, the sub-strategy can be determined according to the cache duration indicated by the following formula (1), and the existence time (i.e., existence duration, also called cache existence duration) of the target cache data currently stored in the current cache can be calculated: timeDurationt = timeNow – timeCreate Formula (1);

[0111] In the formula (1), the time parameter timeCreate can be used to represent the time of inserting the target cache data extracted from the current cached post-write log into the current cache (i.e., the cache write parameter), that is, the cache write parameter refers to the time parameter of inserting the target cache data extracted from the post-write log of the current cache (i.e., the first level cache) into the first level cache, and the time parameter timeNow is used to represent the cache system parameter currently recorded in real time by the cache system where the multi-level cache is located, that is, the cache system parameter refers to the time parameter currently recorded in real time by the cache system where the multi-level cache is located. In this way, after obtaining the two time parameters, the cloud server can determine the parameter value of the cache write parameter as the first cache write timestamp, and determine the parameter value of the cache system parameter as the system timestamp of the cache system where the multi-level cache is located, and then can calculate the time difference between the system timestamp and the first cache write timestamp according to the above formula (1), and then can take the calculated time difference as the cache existence duration of the target cache data in the current cache (i.e., the first level cache, for example, L2 cache) (i.e., the above first cache existence duration). For ease of understanding, it is assumed that the cache existence duration in the L2 cache (i.e., the above first cache existence duration) calculated according to the above formula (1) is 5 seconds, so that the first cache existence duration can be further judged by step S104 whether it meets the valid cache determination sub-strategy in the asynchronous cache update strategy.

[0112] In step S104, if the first cache existence duration meets the valid cache determination sub-strategy, an asynchronous refresh task is generated, and the asynchronous refresh task is submitted to the second level cache through the first task deduplicator associated with the first level cache; the asynchronous refresh task is used to indicate the cache update data for updating the target cache data in the second level cache;

[0113] For example, if the first cache existence duration meets the asynchronous cache update strategy (which can be the valid cache determination sub-strategy in the asynchronous cache update strategy), the cloud server can determine the target cache data found as the valid cache data to be updated, generate an asynchronous refresh task for refreshing the cache data to be updated, and then submit the asynchronous refresh task to the second level cache through the first task deduplicator associated with the first level cache; the asynchronous refresh task is used to indicate that when the cache update data corresponding to the cache data to be updated is found in the second level cache, the cache update data is returned to the first task deduplicator.

[0114] Specifically, the specific implementation manner of the cloud server generating the asynchronous refresh task based on the asynchronous cache update strategy can be described as follows: the cloud server can obtain an effective cache determination sub-strategy from the asynchronous cache update strategy, obtain a cache effective parameter corresponding to the first-level cache based on the effective cache determination sub-strategy, and determine a parameter value of the cache effective parameter as a first cache effective duration of the target cache data; wherein the cache effective parameter refers to a time parameter extracted by the cloud server from a cache configuration log corresponding to the first-level cache; further, the cloud server can obtain a cache refresh sub-strategy from the asynchronous cache update strategy, obtain a cache refresh parameter corresponding to the first-level cache based on the cache refresh sub-strategy, and determine a parameter value of the cache refresh parameter as a first cache refresh duration corresponding to the target cache data; wherein the cache refresh parameter refers to a time parameter extracted by the cloud server from the cache configuration log; further, if a first cache existing duration is less than the first cache effective duration and the first cache existing duration is greater than the first cache refresh duration, the cloud server can determine that the first cache existing duration satisfies the asynchronous cache update strategy; further, the cloud server can determine the target cache data corresponding to the first cache existing duration satisfying the cache update strategy as valid to-be-updated cache data, and then generate an asynchronous refresh task for refreshing the to-be-updated cache data, and submit the asynchronous refresh task to the second-level cache through a first task deduplicator associated with the first-level cache. The to-be-updated cache data refers to the target cache data in an effective state.

[0115] In the embodiments of the present application, the asynchronous cache updating strategy can specifically include a cache duration determination sub-strategy, an effective cache determination sub-strategy, and a cache refresh sub-strategy. The cache duration determination sub-strategy can be used to determine the cache existing duration of the target cache data found in the current cache. The effective cache determination sub-strategy can be used to determine the cache effective duration of the target cache data found in the current cache. Similarly, the cache refresh sub-strategy can be used to determine the cache refresh duration of the target cache data found in the current cache. In this way, the specific process of determining the cache data to be updated with validity based on the first cache existing duration and the asynchronous cache updating strategy can also be described as follows: the cloud server (for example, the service process corresponding to the first cache in the multi-level cache) can obtain the effective cache determination sub-strategy from the asynchronous cache updating strategy, and can obtain the cache effective parameter corresponding to the first level cache based on the effective cache determination sub-strategy, and then the parameter value of the cache effective parameter can be used as the first cache effective duration of the target cache data. Further, the cloud server (for example, the service process corresponding to the first level cache) can obtain the cache refresh sub-strategy from the asynchronous cache updating strategy, and then can obtain the cache refresh parameter corresponding to the first level cache based on the cache refresh sub-strategy, and can determine the parameter value of the cache refresh parameter as the first cache refresh duration corresponding to the target cache data. Further, if the first cache existing duration is less than the first cache effective duration, and the first cache existing duration is greater than the first cache refresh duration, the cloud server (for example, the service process corresponding to the first level cache) can determine that the first cache existing duration meets the asynchronous cache updating strategy. Further, the cloud server (for example, the service process corresponding to the first level cache) can determine the target cache data corresponding to the first cache existing duration meeting the cache updating strategy as the cache data to be updated with validity.

[0116] Alternatively, for example, as shown in FIG. 5, when the current cache (i.e., the first level cache) is not the first cache in the multi-level cache (i.e., the current cache is not the L1 cache, but the L2 cache), the cloud server (for example, the cache server corresponding to the L2 cache, such as a distributed server in the cloud server) can further perform step S14 (i.e., determining whether the cache existing duration is less than the cache effective duration), and then when it is determined that the cache existing duration of the target cache data stored in the current cache is less than the cache effective duration, the target cache data can be returned to the previous cache (for example, the L1 cache) of the current cache.

[0117] In the process of executing step S14, the cloud server can determine whether the target cache data corresponding to the cache existing duration in the current cache is valid data according to the effective cache determination sub-strategy indicated by formula (2) as follows: timeDuration < timeEffective Formula (2);

[0118] In formula (2), the time parameter timeEffective can be the cache effective parameter of the current cache (i.e., the first level cache) extracted from the cache configuration log corresponding to the current cache, that is, the cache effective parameter is the time parameter extracted from the cache configuration log corresponding to the current cache (i.e., the first level cache), and then the parameter value of the extracted cache effective parameter can be determined as the cache effective duration (i.e., the first cache effective duration) of the target cache data. In this way, when the cloud server determines that the cache existing duration (i.e., the first cache existing duration, for example, timeDurationt is 5 seconds) of the target cache data is less than the cache effective duration (i.e., the first cache effective duration, timeEffective is 6 seconds) based on formula (2), steps S15 and S16 shown in FIG. 5 can be further executed.

[0119] In other words, after the current cache successfully obtains the effective cache (i.e., the target cache data in the valid state is the target cache data with validity), the embodiment of the application can not only further execute step S15, but also additionally judge whether the asynchronous refresh task needs to be submitted through step S16. In this way, the cloud server can not only quickly and timely return the currently determined target cache data with validity to the previous cache (e.g., L1 cache) when executing step S15, but also asynchronously and in advance judge whether the cache refresh sub-strategy indicated by formula (3) as follows needs to be executed to determine whether the valid data (i.e., the target cache data with validity, which can also be referred to as effective cache data) existing in the current cache is the cache data to be updated: timeDuration > timeRefresh Formula (3);

[0120] In the formula (3), the time parameter timeRefresh can be the cache refresh parameter of the current cache (i.e., the first level cache) extracted from the cache configuration log corresponding to the current cache, and then the parameter value of the extracted cache refresh parameter can be determined as the cache refresh duration (i.e., the first cache refresh duration) of the target cache data. In this way, when the cloud server determines that the cache existence duration (i.e., the first cache existence duration, for example, timeDurationt is 5 seconds) of the target cache data is greater than the cache refresh duration (i.e., the first cache refresh duration, for example, timeRefresh is 4 seconds) based on the formula (3), the step S17 shown in FIG. 5 can be further executed to submit an asynchronous refresh task for the target cache data.

[0121] For example, as shown in FIG. 5, the cloud server (for example, a distributed server in the cloud server) can further execute step S16 (i.e., determine whether the cache existence duration is greater than the cache refresh duration) when executing step S15, and then when it is determined that the cache existence duration of the target cache data is greater than the cache refresh duration, it is determined that the cache existence duration of the target cache data is greater than the cache refresh duration, which means that the target cache data stored in the L2 cache is not so "fresh" at this time, and therefore the first cache existence duration of the target cache data stored in the L2 cache satisfies the cache refresh sub-strategy in the asynchronous cache update strategy, and the step S104 is further executed to generate an asynchronous refresh task.

[0122] It should be understood that in the embodiments of the present application, although the cloud server obtains valid cache data that can be used from the current cache, the cache state of the valid cache data can be a to-be-refreshed state, that is, at this time, the target cache data cached in the current cache is not "fresh" enough, and therefore at this time, the service process corresponding to the current cache needs to request an asynchronous refresh task for the target cache data that still has validity within the cache expiration duration (for example, timeExpire is 7 seconds) of the target cache data to improve the accuracy and timeliness of cache refresh.

[0123] Specifically, the service process corresponding to the current cache can request to allocate a service thread (i.e., an asynchronous refresh process) for the current cache for asynchronous refresh, to call the asynchronous refresh process to generate an asynchronous refresh task for the target cache data, and then the asynchronous refresh task can be submitted to the first task deduplicator associated with the current cache in advance when the target cache data still has validity. It should be understood that in the embodiments of the present application, the service process corresponding to the current cache can return to the current cache after submitting the asynchronous refresh task through the currently configured asynchronous refresh thread, so as to continue to provide data query services for data acquisition requests sent by other users through the current cache. In other words, in the embodiments of the present application, the service process corresponding to the current cache can quickly submit the request for the asynchronous refresh task to the first task deduplicator, and in this process, the request for the asynchronous refresh task does not need to wait until the cache state of the target cache data reaches the cache expiration state before being submitted. In this way, the efficiency of the cache update data used to update the target cache data can be improved from the root cause, and the cache update data can be obtained in advance.

[0124] In addition, the time delay of obtaining the cache update data from the next cache through the first task deduplicator will be small, because as long as there is an asynchronous refresh task for the target cache data dispatched in the task pool of the first task deduplicator, the next cache of the current cache can be quickly accessed through the dispatched asynchronous refresh task, and then the valid data (i.e., cache update data with validity) in the next cache that is successfully obtained can be quickly refreshed into the current cache, and thus the asynchronous refresh task for the target cache data can be ended. It should be noted that in the embodiments of the present application, timeRefresh<=timeEffective, so as to ensure that the target cache data cached in the current cache has the opportunity to keep the "freshness" of the cache data newly written into the current cache more efficiently and reliably before becoming invalid through the asynchronous refresh task.

[0125] It can be understood that in the embodiments of the present application, the above-mentioned time parameters (for example, timeRefresh, timeEffective and timeExpire) need to satisfy the following formula (4); timeRefresh <= timeEffective <= timeExpire Formula (4);

[0126] For example, as shown in FIG. 5, at this time, the cloud server can invoke the first task deduplicator (e.g., Single flight) associated with the L2 cache (i.e., the first level cache) to perform step S18, i.e., task deduplication can be performed through the first task deduplicator, and therefore the next cache (i.e., the second level cache, e.g., L3 cache) of the current cache can be accessed based on the deduplication result obtained by task deduplication, to further perform step S19, i.e., at this time, the cloud server can search in the L3 cache through the service process (e.g., the above-mentioned database service process) corresponding to the L3 cache to determine whether there is cache update data for updating the target cache data in the L3 cache.

[0127] Alternatively, in the embodiments of the present application, the server can also determine, in the process of performing step S12, that there is no target cache data in the current cache that matches the target service data requested by the user, and then directly invoke the second task deduplicator (e.g., another Single flight) associated with the current cache (e.g., L2 cache) to perform step S20 through the second task deduplicator, i.e., at this time, the second task deduplicator associated with the current cache (e.g., L2 cache) can receive the data acquisition request synchronized and forwarded by the service process corresponding to the current cache, and determine, based on the data acquisition request, whether there is a data synchronization task for the target service data in the second task deduplicator associated with the L2 cache. If not, the data acquisition request can be forwarded to the service process corresponding to the next cache (e.g., L3 cache) to enable the service process corresponding to the next cache to perform step S19 according to the data synchronization task to search in the next cache to determine whether there is target cache data that matches the target service data requested by the user.

[0128] Specifically, if the first level cache is not the first level cache in the multi-level cache (for example, the first level cache is the L2 cache), and the next level cache (i.e., the second level cache) of the first level cache exists, if the target cache data is not found in the first level cache, the cloud server can submit (i.e., synchronize) the data acquisition request to the second task deduplicator associated with the first level cache (for example, L2 cache), so that when the second task deduplicator detects that there is no data synchronization task associated with the target business data in the task pool (specifically, the mapping relationship table corresponding to the task pool), it can submit the data acquisition request currently acquired to the second level cache, and can mark the request task indicated by the data acquisition request as a data synchronization task in the task pool. At this time, the data synchronization task can be used to indicate searching for the target cache data in the second level cache (for example, L3 cache). It can be understood that the mapping relationship table corresponding to the task pool can be used to record the business type and business identifier carried in the data acquisition request. The business type here can be the above-mentioned fee status query type, identity authentication type, etc. The business identifier here can be the user's business account data information (for example, the above-mentioned account 1).

[0129] Optionally, during the execution of step S20, if it is judged that there is indeed a data synchronization task for the target business data, the request task indicated by the data acquisition request currently acquired needs to be taken as a waiting task in the task pool, so that when the data synchronization task in the task pool acquires the target cache data from the second level cache (for example, L3 cache), all waiting tasks in the task pool can be notified to reuse the target cache data currently acquired. In other words, if the first level cache is not the first level cache in the multi-level cache, and the next level cache (i.e., the second level cache) of the first level cache exists, if the target cache data is not found in the first level cache, the cloud server can also submit the data acquisition request to the second task deduplicator associated with the first level cache (for example, L2 cache), so that when the second task deduplicator detects that there is already a data synchronization task associated with the target business data in the task pool, it can further take the request task indicated by the data acquisition request as a waiting task in the task pool. At this time, the second task deduplicator can be used to further notify the waiting task in the task pool to reuse the target effective data when the target effective data is acquired from the second level cache (for example, L3 cache) through the data synchronization task. It should be understood that the target effective data here is the target cache data, and further, the cloud server can receive the target cache data returned by the second task deduplicator, and can synchronize and refresh the target cache data to the first level cache (for example, L2 cache).

[0130] Therefore, in the embodiment of the present application, if the cloud server does not query the target cache data (i.e. a cache key stored in the current cache, for example, a service identifier, which can be an account ID, such as ID123) matching the target service data requested by the service object (i.e. the user) in the current cache when performing step S12, the received request can be filtered (for example, the above request merging) through the second task deduplicator (for example, single flight). For example, the second task deduplicator can reconstruct the service type (for example, the above fee status query type, or the above service attribute status query type, or the flow attack risk query type) and the service identifier in the received data acquisition request into a globally unique cache key to achieve deduplication of the acquired request.

[0131] For example, in the embodiment of the present application, the cache key formed by the second task deduplicator can be cache key 1 recorded in the task pool, which can be a string Charge-ID123, which can be used to represent that the service identifier of the account ID123 needs to be queried in the fee status query scenario. For example, the cache key formed by the second task deduplicator can be cache key 2 recorded in the task pool, which can be a string Vip-ID123, which can be used to represent that the service identifier of the account ID123 needs to be queried in the service attribute query scenario. For example, the cache key formed by the second task deduplicator can be cache key 3 recorded in the task pool, which can be a string Highgps-ID123, which can be used to represent that the service identifier of the account ID123 needs to be queried in the flow attack query scenario. In this way, for different query service scenarios of the same account, a small number of data synchronization tasks for different query service scenarios can be dispatched by the second task deduplicator to the lower layer for query, and the request tasks indicated by other requests not dispatched out need to be used as waiting tasks in the task pool, so that after the data synchronization tasks dispatched by the second task deduplicator from the lower layer obtain valid data, all waiting requests in the current layer are notified to reuse the valid data obtained from the lower layer.

[0132] It should be understood that in the embodiment of the present application, if the first level cache is the first level cache in the multi-level cache, the lower layer can refer to the next level cache (i.e. the second level cache) of the first level cache.

[0133] It should be understood that in the embodiments of the present application, in the process of executing step S14, if the first cache existence duration is less than the first cache validity duration, the cloud server can determine that the first cache existence duration satisfies the effective cache determination sub-strategy indicated by the above formula (2), and thus can determine the target cache data corresponding to the first cache existence duration satisfying the effective cache determination sub-strategy as the effective cache data; further, the cloud server can return the effective cache data to the previous cache of the current cache (i.e. the first level cache) through step S15, so that the previous cache of the first level cache performs cache processing on the effective cache data; it should be understood that in the embodiments of the present application, if the first level cache is not the first cache level in the multi-level cache, the previous cache of the first level cache can at least include the first cache level.

[0134] Alternatively, in another implementable manner, if the first level cache is the first cache level in the multi-level cache, the data acquisition request is a request (e.g. the read request) sent by the business client to acquire the target business data, so that in the process of executing step S14, if the first cache existence duration is less than the first cache validity duration, the cloud server determines that the first cache existence duration satisfies the effective cache determination sub-strategy, and then can determine the target cache data corresponding to the first cache existence duration satisfying the effective cache determination sub-strategy as the effective business data; at this time, since the current cache has no previous cache, the cloud server can directly execute the business processing task (e.g. the identity authentication task) for the target business data based on the effective business data to obtain the business processing result of the business processing task; the business processing task is the request task carried in the data acquisition request; further, the cloud server can return the business processing result to the business client.

[0135] Alternatively, as shown in FIG. 5, in the process of executing step S14, if the first cache existence duration is greater than or equal to the first cache validity duration, the cloud server can determine that the first cache existence duration does not satisfy the effective cache determination sub-strategy; further, when the target cache data corresponding to the first cache existence duration not satisfying the effective cache determination sub-strategy is regarded as invalid data (here, the invalid data refers to the target cache data in the invalid state), the cloud server can submit the data acquisition request to the second task deduplicator associated with the first level cache, so that the second task deduplicator can send the data acquisition request to the second level cache when no synchronization refresh task (i.e. the above data synchronization task) associated with the target business data is detected.

[0136] Optionally, as shown in FIG. 5, in the process of performing step S16, if the first cache existing duration is less than or equal to the first cache refreshing duration, the cloud server can determine to end the cache searching task of searching the target cache data in the current cache. This means that the first cache existing duration does not meet the cache refreshing sub-strategy at this time, so there is no need to submit the asynchronous refreshing task in advance, because at this time, the cloud server can maintain the target cache data corresponding to the first cache existing duration which does not meet the cache refreshing sub-strategy as valid data. The valid data here can specifically include any one of the above valid cache data or valid service data.

[0137] Step S105: receiving the cache updating data returned by the second-level cache through the first task deduplicator, and updating the target cache data as the cache updating data in the first-level cache.

[0138] Specifically, the service process corresponding to the first-level cache in the cloud server can receive the cache updating data returned by the first task deduplicator, and then update the cache data to be updated (i.e., the target cache data with validity) as the cache updating data in the first-level cache.

[0139] In the embodiments of the present application, the first task deduplicator can be the same task deduplicator as the second task deduplicator, or can be a different task deduplicator from the second task deduplicator, and the specific type of the task deduplicator will not be limited here, for example, in some implementable scenarios, the filtering processing of the asynchronous refreshing task submitted by the current cache can also be implemented through a Bloom filter.

[0140] The multi-level cache can include a first level cache and a second level cache. It should be understood that the first level cache and the second level cache can be any two adjacent level caches in the multi-level cache. For example, in the embodiment of the present application, the second level cache can be the next level cache of the first level cache, and the search priority of the first level cache can be higher than that of the second level cache. For ease of understanding, the first level cache is taken as the current cache, and the second level cache is taken as the next level cache of the current cache. The current cache can be the first level cache in the multi-level cache, or can be a non-first level cache in the multi-level cache, which will not be limited here. In this way, when the computer device (such as a cloud server in a cloud service scenario) obtains the data acquisition request sent by the business client for acquiring target business data, the target cache data matched with the target business data can be searched in the first level cache (such as the current cache shown in FIG. 5) based on the data acquisition request. Further, if the target cache data is found in the first level cache (such as the current cache), the computer device (such as a cloud server in a cloud service scenario) can obtain an asynchronous cache update strategy associated with the first level cache (such as the current cache), and then determine the first cache existence time length of the target cache data in the first level cache (such as the current cache) based on the cache time length in the asynchronous cache update strategy. Further, if the first cache existence time length meets the valid cache determination sub-strategy in the asynchronous cache update strategy, the computer device (such as a cloud server in a cloud service scenario) can determine the found target cache data as valid to-be-updated cache data, and then generate an asynchronous refresh task for refreshing the to-be-updated cache data in advance when the to-be-updated cache data still has validity, and submit the asynchronous refresh task to the second level cache (such as the next level cache) through the first task deduplicator associated with the first level cache (such as the current cache). It should be understood that the asynchronous refresh task can be used to indicate that when the cache update data for updating the to-be-updated cache data is found in the second level cache (such as the next level cache), the cache update data is returned to the first task deduplicator, so that the computer device (such as a cloud server in a cloud service scenario) can further receive the cache update data returned by the first task deduplicator, so as to update the to-be-updated cache data to the cache update data in the first level cache (such as the current cache).It can be seen that, for any two adjacent caches (i.e., the first level cache and the second level cache) in the multi-level cache, once the target cache data matching the target service data carried in the data acquisition request is found in the first level cache (such as the current cache), the cache existence duration (i.e., the first cache existence duration) of the target cache data in the current cache can be further determined, and then the target cache data still having validity stored in the first level cache can be returned to the upper level cache of the current cache while the target cache data having validity is taken as the to-be-updated cache data, so that the cache update data acquired from the second cache level can be refreshed to the current cache (i.e., the first level cache) in advance before the target cache data is invalid through the new asynchronous refreshing mechanism. In other words, in the embodiment of the present application, the computer device (such as the cloud server in the cloud service scenario) can improve the timeliness and reliability of cache updating through the new asynchronous refreshing mechanism in the process of updating the target cache data cached in the current cache (i.e., the first level cache).

[0141] Further, please refer to FIG. 6, which is a flowchart of another cache updating method based on multi-level cache provided by the present application. In the cloud service scenario, the cache updating method based on multi-level cache can be executed by a cloud server, which can be the cloud server 22a shown in FIG. 2. The multi-level cache can include a first level cache and a second level cache, and the second level cache is the next level cache of the first level cache. In addition, the search priority of the first level cache is higher than that of the second level cache. As shown in FIG. 6, the method can include at least steps S201-S209:

[0142] Step S201, receiving a data write request for target cache data sent by a service client, and sending the target cache data to a service database associated with the multi-level cache based on the data write request, so that the service database generates database write response information for the target cache data when successfully writing the target cache data.

[0143] Step S202, receiving the database write response information returned by the service database, and returning the database write response information to the service client.

[0144] Step S203, generating a cache update message for the target cache data when returning the database write response information to the service client.

[0145] Step S204, sending the cache update message to the message queue system, so that the message queue system updates the target cache data to the second level cache and the first level cache based on the cache update message;

[0146] The update priority of the second cache level is higher than the update priority of the first level cache.

[0147] It should be understood that in the embodiments of the present application, when the business client initiates a data write request for the underlying module (i.e. the above-mentioned business database), the cloud server can write the data (e.g. target cache data) currently required to be written into the underlying module (i.e. the above-mentioned business database) based on the data write request, so as to update the underlying data in the underlying module (i.e. the above-mentioned business database) by the written data (e.g. target cache data) to obtain the updated underlying data. Then, when the cloud server monitors that the underlying data in the underlying module (i.e. the above-mentioned business database) has changed (i.e. there is an update), the cloud server can update the data (e.g. target cache data) currently successfully written into the underlying module (i.e. the above-mentioned business database) to each level cache in the multi-level cache in a sequentially updated manner.

[0148] For ease of understanding, further, please refer to FIG. 7, which is a scene diagram provided by the embodiments of the present application for sequentially updating each level cache in the multi-level cache in a sequentially updated manner. It can be understood that the cache system 7a shown in FIG. 7 can be the cache system 4a shown in FIG. 4. It should be understood that the write request Q2 and the read request Q1 shown in FIG. 7 can be collectively referred to as external business requests sent by the business client.

[0149] In the cache system 7a shown in FIG. 7, the overall architecture of the cache modules corresponding to each level cache in the multi-level cache can include a write data flow W11 for the write request Q2 and a read data flow R11 for the read request Q1.

[0150] The write request Q2 can be a data write request initiated by the service client 71a in FIG. 7 to change data in the underlying module (i.e., the service database). The cloud server can write the data (e.g., target cache data) required to be written at present into the underlying module (i.e., the service database) based on the data write request, update the underlying data in the underlying module (i.e., the service database) by the written data (e.g., target cache data), and obtain updated underlying data. When the cloud server detects that the underlying data in the underlying module (i.e., the service database) has changed (i.e., there is an update), the cloud server can update the data (e.g., target cache data) successfully written into the underlying module (i.e., the service database) in a sequential update manner, update the last level cache (e.g., L N cache) in the multi-level cache first, then update the data (e.g., target cache data) into the last level cache (e.g., L N-1 cache) of the previous level, and so on, until the cloud server updates the data (e.g., target cache data) into the first level cache (e.g., L1 cache) of the multi-level cache, and completes the traversal update of each level cache in the multi-level cache.

[0151] It should be understood that in the process of updating the data (e.g., target cache data) in each level cache in the multi-level cache in a sequential update manner, the target cache data can be updated into the cache data in the corresponding cache through the write-after log record of each level cache, so that the write timestamp of the data (e.g., target cache data) in the L N cache can be quickly determined through the write-after log of each level cache, which is earlier than the write timestamp of the data (e.g., target cache data) in the L N-1 cache, and so on, the write timestamp of the data (e.g., target cache data) in the L2 cache is also earlier than the write timestamp of the data (e.g., target cache data) in the L1 cache.

[0152] It should be understood that the write timestamp here refers to the timestamp recorded when the data (e.g., target cache data) is flushed and written into each level cache in the multi-level cache. This means that for any two adjacent level caches (e.g., a first level cache and a second level cache) in the multi-level cache, the cache existence duration of the target cache data in the first level cache (i.e., the first cache existence duration) is less than the cache existence duration of the target cache data in the second level cache (i.e., the second cache existence duration).

[0153] It should be understood that, as shown in FIG. 7, the embodiment of the present application designs a hierarchical cache scheme based on multi-level cache. The cache system where the hierarchical cache scheme is located is a cache system 7a composed of N levels of cache. It should be understood that in the cache system 7a, the closer to the upper layer cache of the upper layer service, the better the data reading performance, so when the target cache data is acquired based on the acquired data acquisition request (for example, the read request Q1 for the target cache data shown in FIG. 7), the target cache data can be searched in the multi-level cache according to the arrow direction in the read data flow R11 (for example, searching L1 cache first, then searching L2 cache, and so on, which can further search L N- 1 cache first, then searching L2 cache, and so on, which can further search L N cache), and in the case that the target cache data is not hit in the multi-level cache, the target cache data can be read from the bottom module (for example, the bottom module here can be a db database, a storage database, and other micro service databases (i.e., other micro service) and the like).

[0154] As can be seen, the embodiment of the present application can provide efficient reading service through the cache level of the hit target cache data when the target cache data is hit in the corresponding level of the multi-level cache. In addition, it can be understood that in the cache system 7a, the closer to the lower layer cache of the bottom module, the higher the reliability, for example, in the cache system 7a, the last level of cache (for example, L N cache shown in FIG. 7) in the multi-level cache can even use a kv form database such as mongoDB, so when the bottom module shown in FIG. 7 fails, the last level of cache (for example, L N cache shown in FIG. 7) in the multi-level cache can temporarily act as a backup database of the db database in the bottom module, so that the L N cache shown in FIG. 7 can be used to provide partial services in degraded mode when the bottom module fails.

[0155] In the cache system 7a, the access server (i.e., access server) can be an access instance used to provide corresponding cloud services in a cloud service scenario, which can be used to carry the upper layer service. The arrow direction indicated by the read data flow R11 shown in FIG. 7 represents the read request Q1 shown in FIG. 7, in other words, the service processes corresponding to each level of cache in the cloud server can access L1 cache, L2 cache, …, L N-1 cache and L NThe cache is accessed until the underlying database, the storage database or other microservices corresponding to the underlying module is accessed for the last time. As indicated by the arrow pointing to the write request Q2 for the target cache data, the cloud server can directly modify the underlying data in the underlying module through the write request Q2.

[0156] For ease of understanding, further, please refer to FIG. 8, which is a scene diagram of directly modifying underlying data in an underlying module according to an embodiment of the present application. Here, the underlying module can be the customer account database shown in FIG. 8. It can be understood that the access server shown in FIG. 8 is an access instance in the cloud server for carrying an upper-layer service, and the cache corresponding to the access server can be the L1 cache described above.

[0157] As shown in FIG. 8, the service client in the terminal device can send an account information modification request for a target account to the access server in the cloud server when performing step S21. In this way, the local access process in the access server can obtain the target account to be modified and the account data information (i.e., the target cache data) of the target account from the account information modification request (e.g., the write request Q2 shown in FIG. 7) when obtaining the account information modification request, and then can submit the obtained account data information (i.e., the target cache data) of the target account to be modified to the customer account database (i.e., the underlying module shown in FIG. 7) shown in FIG. 8 through step S22, so that the service process corresponding to the underlying module can perform step S23 shown in FIG. 8 to update the customer account database, for example, to perform data update on the underlying data in the underlying module through the target cache data. In other words, the service process corresponding to the underlying module can generate update success information after writing the target cache data into the underlying module, and then can return the update success information to the local access process through step S24. Then, the access server in the cloud server can further return the update success information to the service client through step S25.

[0158] In the multi-level cache, the service process corresponding to the L3 cache and the service process corresponding to the L2 cache can both pre-subscribe the Kafka message published by the message queue system. Further, as shown in FIG. 8, the local access process can push the cache update message to the L3 cache through step S26 to push the cache update message for the L3 cache (e.g., the last level cache in the multi-level cache) to the message queue system (i.e., the distributed stream processing system, for example, the Kafka system shown in FIG. 8), so that when the message queue system (e.g., the Kafka system shown in FIG. 8) receives the cache update message (i.e., the first update message for the second level cache), it can preferentially push the Kafka message associated with the cache update message to which it subscribes to the L3 cache through step S27. This means that the service process corresponding to the L3 cache (e.g., the last level cache in the multi-level cache) that subscribes to the message queue system can obtain the account data information (i.e., the target cache data) in the cache update message from the received Kafka message through step S27, so that the service process corresponding to the L3 cache (e.g., the last level cache in the multi-level cache) can further execute step S28, and can update the account data information (i.e., the target cache data) written in the cache update message in the L3 cache after deleting the target account in the L3 cache (e.g., specifically, deleting the initial cache data of the target account in the second level cache).

[0159] Similarly, in the embodiment of the present application, after step S26 is executed, the local access process can further execute step S29 to wait for the cache update message (i.e., the first update message) sent in step S26, and further execute step S30 to push another cache update message (i.e., the second update message) to the upper level cache (i.e., the L2 cache) of the L3 cache through the message queue system (e.g., the Kafka system shown in FIG. 8) according to the waiting interval (e.g., 5 seconds) indicated by the cache waiting strategy. In this way, when the message queue system (e.g., the Kafka system shown in FIG. 8) receives the cache update message (i.e., the second update message for the first level cache), it means that the service process corresponding to the L2 cache that subscribes to the message queue system can obtain the account data information (i.e., the target cache data) in the other cache update message through step S31, so that the service process corresponding to the L2 cache can further execute step S32, and then can update and write the account data information (i.e., the target cache data) in the cache update message in the L2 cache after deleting the target account in the L2 cache (e.g., specifically, deleting the initial cache data of the target account in the first level cache). In this way, until the local access process shown in FIG. 8 updates and writes the data (e.g., the target cache data) to the first level cache (e.g., the L1 cache) of the multi-level cache through the message queue system, the traversal update of each level cache in the multi-level cache is completed.

[0160] In the embodiment of the present application, the L1 cache can be the first level cache, the business instance is generally embedded in the L1 cache, and the access server corresponding to the L1 cache is usually implemented in the form of local memory (i.e., the local data storage memory). It should be understood that in the embodiment of the present application, the cache validity duration of the L1 cache is the shortest, which can reduce the inconsistency time to some extent during the cache update process.

[0161] In the embodiment of the present application, the L2 cache, …L NThe cache can be the non-first level cache described above, which can be a memcache, redis, or other distributed cache. In the embodiments of the present application, the number of levels of the multi-level cache can be set according to different specific business scenarios. In the asynchronous refreshing mechanism involved in the embodiments of the present application, the cache refreshing time of the cache closest to the upper layer service (for example, the L1 cache described above) needs to be less than the cache refreshing time of the cache next closest to the upper layer service (for example, the L2 cache described above), and the cache effective time of the cache closest to the upper layer service (for example, the L1 cache described above) also needs to be less than the cache effective time of the cache next closest to the upper layer service (for example, the L2 cache described above). In this way, when the target cache data cached in the L1 cache is invalidated, the target cache data with time limit can also be directly obtained from the L2 cache as cache update data to refresh back to the L1 cache. Not only can the performance of the overall system be significantly improved and the bottom layer load be reduced, but also the upper layer service can quickly perceive data changes. Conversely, in the multi-level cache, the priority of refreshing some data with high access frequency stored in the next cache to the current cache can be improved, and the priority of refreshing some data with low access frequency to the current cache can be reduced.

[0162] In the Kafka system, a distributed stream processing system, when the underlying data in the underlying module changes, the local access process can publish a Kafka message based on the received update success message, so that the non-first level cache (that is, the cache other than the L1 cache in the multi-level cache) subscribed to the Kafka system can subscribe to (that is, receive) such cache update messages, and then delete the cache record of the target account previously stored in the cache (that is, the record in the cache for recording the initial cache data) based on the received cache update message, and update the target cache data of the target account in the cache. In this way, the diffusion speed of data update in each level of the multi-level cache can be accelerated. In this way, when the local access process for providing the upper layer service does not find the target cache data in the L1 cache, the target cache data can be quickly found in the next level of the L1 cache.

[0163] Optionally, in another implementation manner, each level of the multi-level cache can subscribe to the published Kafka message, so that the cache writing to each level of the multi-level cache can be implemented in the above-mentioned order-preserving update manner.

[0164] Based on this, in order to improve the efficiency of data searching, the cloud server can first search in the first level cache (for example, L1 cache) of the multi-level cache to check whether there is target cache data matching the target business data when the cloud server obtains the data searching request sent by the business client for searching the target business data. If not, the cloud server can further search in the next level cache (for example, L2 cache) of the first level cache to check whether there is target cache data matching the target business data.

[0165] It should be understood that after successfully modifying / deleting the underlying business data, the local access process can push a cache update message to the Kafka system, and then the L2 cache and the L3 cache or even the L4 cache can update the cache data based on the cache update message. N Each layer of cache in the cache has a corresponding consumer group, which can detect the cache update message. In this way, each layer can process the cache update message through its own independent consumer group.

[0166] Specifically, the message queue system is a distributed stream processing system; the cache update message includes a first update message for the second level cache and a second update message for the first level cache; at this time, the cloud server can obtain a cache waiting strategy associated with the cache update message; further, the cloud server can send the first update message to the second level cache through the distributed stream processing system based on the cache waiting strategy, so that the second level cache deletes the initial cache data associated with the target business data cached in the second level cache based on the first update message, and caches the updated target cache data in the second level cache; further, the cloud server can send the second update message to the first level cache through the distributed stream processing system based on the waiting interval indicated by the cache waiting strategy, so that the first level cache deletes the initial cache data cached in the first level cache based on the second update message, and caches the updated target cache data in the first level cache.

[0167] Optionally, in the embodiment of the present application, the message queue system can also be a message-oriented processing system, for example, a RabbitMQ system, the cache update message includes a third update message for the second level cache and a fourth update message including a fourth update message for the first level cache; at this time, the cloud server can obtain a message confirmation strategy associated with the cache update message; further, the cloud server can send the third update message to the second level cache through the message-oriented processing system based on the message confirmation strategy, so that the second level cache deletes the initial cache data associated with the target business data cached in the second level cache based on the third update message, and generates a first cache confirmation message for the target cache data when the target cache data is cached in the second level cache. Further, the cloud server can receive the first cache confirmation message returned by the second level cache through the message-oriented processing system, and send the fourth update message to the first level cache through the message-oriented processing system based on the first cache confirmation message, so that the first level cache deletes the initial cache data cached in the first level cache based on the fourth update message, and generates a second cache confirmation message for the target cache data when the target cache data is cached in the first level cache. Further, the cloud server can receive the second cache confirmation message returned by the first level cache through the message-oriented processing system.

[0168] Wherein, RabbitMQ system: an open source message queue system, which supports multiple message delivery modes, including request-response mode. RabbitMQ provides a message confirmation mechanism, and each layer of consumer in the multi-level cache can send a confirmation message to the RabbitMQ system to indicate that it has successfully consumed the above cache update message. The producer (i.e. the local access process shown in Figure 8) can wait for the confirmation message returned by the RabbitMQ system (i.e. a packet mechanism for indicating that the cache update message has been consumed) to ensure that the cache update message obtained by the consumer in each layer has been successfully processed.

[0169] For ease of understanding, hereinafter, taking any two adjacent layers of cache (e.g. first level cache and second level cache) in a plurality of level caches as an example, the specific process of pre-refreshing the target cache data existing in the first level cache through the asynchronous refresh task between the any two adjacent layers of cache (e.g. first level cache and second level cache) is described. For ease of understanding, further, please refer to the following steps S205-S209.

[0170] In the embodiments of the present application, the asynchronous refresh task is generated by a thread in a certain fixed thread pool configured by a service process (for example, a local access process) corresponding to the cache (for example, an L1 cache) for the current cache, so that the local access process also needs to pass through the single flight to filter and deduplicate the currently received tasks after submitting the asynchronous refresh task to the first task deduplicator (that is, single flight), so as to reduce the quantity of repeated requests for reading the same data content from the lower layer at the same time as much as possible.

[0171] In step S205, the data acquisition request sent by the service client is acquired, and target cache data matching the target service data carried by the data acquisition request is searched in the first-level cache.

[0172] Specifically, when the cloud server acquires the data acquisition request sent by the service client for acquiring the target service data, the cloud server searches the first-level cache for the target cache data matching the target service data based on the data acquisition request.

[0173] In step S206, if the target cache data is found in the first-level cache, an asynchronous cache update strategy associated with the first-level cache is acquired, and the asynchronous cache update strategy includes a cache duration determination sub-strategy and an effective cache determination sub-strategy.

[0174] In step S207, the first cache duration of the target cache data in the first-level cache is determined based on the cache duration determination sub-strategy.

[0175] It should be understood that the cloud server can determine the first cache duration of the target cache data in the first-level cache based on the cache duration determination sub-strategy in the asynchronous cache update strategy.

[0176] In step S208, if the first cache duration satisfies the effective cache determination sub-strategy, an asynchronous refresh task is generated, and the asynchronous refresh task is submitted to the second-level cache through the first task deduplicator associated with the first-level cache; the asynchronous refresh task is used to indicate that the cache update data for updating the target cache data is searched in the second-level cache.

[0177] Specifically, if the first cache exists for a time length satisfying the asynchronous cache updating strategy (specifically, can satisfy the valid cache determination sub-strategy in the asynchronous cache updating strategy), the cloud server can determine the found target cache data as valid to-be-updated cache data, generate an asynchronous refreshing task for refreshing the to-be-updated cache data, and submit the asynchronous refreshing task to the second level cache through the first task deduplicator associated with the first level cache; the asynchronous refreshing task is used to instruct to return the cache updating data corresponding to the to-be-updated cache data (i.e., the cache updating data for updating the to-be-updated cache data) to the first task deduplicator when the cache updating data is found in the second level cache.

[0178] In step S209, the cache updating data returned by the second level cache through the first task deduplicator is received, and the target cache data is updated as the cache updating data in the first level cache.

[0179] Specifically, the cloud server can receive the cache updating data returned by the first task deduplicator, and update the to-be-updated cache data as the cache updating data in the first level cache.

[0180] Optionally, it can be understood that if the first level cache is not the first level cache in the multi-level cache, the cloud server can further execute the following steps after executing step S205.

[0181] For example, in one implementation, if the target cache data is not found in the first level cache, the data acquisition request is submitted to the second task deduplicator associated with the first level cache, so that the second task deduplicator marks the request task indicated by the data acquisition request as a data synchronization task in the task pool when it is detected that there is no data synchronization task associated with the target business data in the task pool; the data synchronization task is used to instruct to find the target cache data in the second level cache.

[0182] Optionally, it can be understood that if the first level cache is not the first level cache in the multi-level cache; the cloud server can also further jump to execute the following steps after executing the above step S205.

[0183] For example, if the target cache data is not found in the first level cache, the data acquisition request is submitted to a second task deduplicator associated with the first level cache, so that when the second task deduplicator detects that there is a data synchronization task associated with the target business data in the task pool, the request task indicated by the data acquisition request is used as a waiting task in the task pool; the second task deduplicator is used to notify the waiting task in the task pool to reuse the target effective data when the target effective data is acquired from the second level cache by the data synchronization task; the target effective data is the target cache data; further, the cloud server can receive the target cache data returned by the second task deduplicator, and synchronize and refresh the target cache data to the first level cache.

[0184] It can be understood that, in the embodiment of the application, in order to avoid that the second level cache receives a large number of data acquisition requests each time, in the embodiment of the application, one or more task deduplicators can be configured for the first level cache to obtain a plurality of task deduplicators associated with the first level cache. For example, the plurality of task deduplicators configured here can include but are not limited to the first task deduplicator used to implement the asynchronous refresh task and the second task deduplicator used to implement the data synchronization task. In this way, when the cloud server does not find the target cache data in the first level cache based on a large number of concurrently sent data query requests (i.e. data acquisition requests) acquired, the second task deduplicator configured for the first level cache can be used to request to combine a large number of data acquisition requests sent from different business clients, and then the target data acquisition request (i.e. a small number of data acquisition requests, for example, the first data acquisition request in a large number of data acquisition requests and / or a randomly selected data acquisition request in a large number of data acquisition requests) in a large number of data acquisition requests can be allowed to penetrate (or pass through) the second level cache for data query. In this way, for any two adjacent level caches in the multi-level cache, the query amount for data query in the next level cache of the adjacent level cache can be reduced in the process of querying the target cache data between the adjacent level caches.

[0185] Optionally, in the embodiment of the application, in order to ensure the effectiveness of the target cache data cached in the current level cache (i.e. the first level cache), the embodiment of the application further proposes that the expired cache data in the first level cache can be cleared in time based on an expiration cleaning strategy.

[0186] Specifically, the cloud server can obtain the cache expiration parameter and cache validity parameter associated with the first-level cache, and can determine the value of the cache expiration parameter as the first cache expiration duration of the target cache data, and then use the value of the cache validity parameter as the first cache validity duration of the target cache data; furthermore, when the cloud server detects that the first cache validity duration is less than or equal to the first cache expiration duration, it can determine the target cache data stored in the first-level cache as expired cache data to be cleared, thereby clearing the expired cache data in the first-level cache.

[0187] Optionally, it can also be understood that, in this embodiment of the application, to ensure that the caching system where the multi-level cache resides can achieve maximum availability, it is proposed that, within the fault duration of the underlying module (i.e., the business database) associated with the multi-level cache, a disaster recovery and degradation processing strategy can be used to flexibly adjust (e.g., manually or automatically increase) the last level cache (e.g., the aforementioned L) in the multi-level cache. N The cache validity period of the cache (i.e., the adjusted (i.e., increased) L) N The cache validity period shall not exceed this L. N If the cache expires, L can continue to be used. N The cached data for this target target is used to replace the currently failing underlying module (i.e., the business database) to continue providing services. Here, it can be understood that L... N The service provided by caching is specifically a degradation service, for example, the L N To prevent the entire caching system from becoming unavailable when the underlying module fails, the aforementioned disaster recovery and degradation strategy proposes temporarily increasing L. N The cache validity period is set to ensure that the cache existence time of the target cached data can continue to be less than the adjusted L. N The cache validity period is specified, therefore it can continue to be used via L. N The cache provides fallback services instead of the underlying module.

[0188] Specifically, if the cloud server, in the case where the second-level cache is the last level of a multi-level cache, stores target cache data in the second-level cache, and the storage duration of this target cache data in the second-level cache is equal to the cache's existence duration, and the cache validity parameter of the second-level cache is set to the cache's validity duration, and the cache expiration parameter of the second-level cache is set to the cache's expiration duration, then the cloud server (for example, this cloud server could specifically refer to a microservice cluster composed of multiple different servers in a service scenario) can further notify the second-level cache (for example, the aforementioned L) when a business failure event occurs in the business database associated with the multi-level cache.N adjusting the second cache valid duration in length within a fault duration indicated by the service failure event to obtain a cache update valid duration; the cache update valid duration is used to indicate that the target cache data in the second level cache (for example, the L N cache) is used to perform disaster recovery processing on the service database.

[0189] Wherein, the fault duration is less than or equal to the second cache expiration duration, and the cache update valid duration is used to indicate that the target cache data stored in the second level cache (for example, the L N cache) continues to maintain as valid data when the cache update valid duration is greater than the second cache valid duration, and the second cache existence duration is less than the cache update valid duration.

[0190] For example, when the cloud server provides object storage services, it needs to call the underlying module (i.e. identity authentication and management server, for example, IAM, which stands for Identity and Access Management). It should be understood that IAM can be used to confirm whether the request (i.e. the data acquisition request currently obtained by the cloud server) is legal and has the right to access the target resource. For example, in the process of providing object storage services for the customer (e.g. user U1) corresponding to the business client through multi-level cache, if the target cache data matching the target business data requested by user U1 is not found in the multi-level cache, the data acquisition request carrying the target business data (e.g. customer identifier and signature information) needs to be transmitted to the underlying module (i.e. IAM), so that the underlying module (i.e. IAM) can return the target cache data (i.e. authentication and permission information) to the cloud server. In this way, the cloud server can further perform authentication (i.e. identity authentication and permission management) based on the target cache data obtained from the underlying module to determine whether the request is legal.

[0191] Wherein, modifying the permission information of the customer account is a very low-frequency operation. In actual production environment, the account permissions are configured by the administrator in advance, and are rarely modified after going online. Of course, there are exceptions, such as discovering an urgent security vulnerability, and some business scenarios in cloud service scenarios require temporary authentication, which requires the customer to apply for a batch of temporary authentication from IAM every certain period of time and distribute it to the multi-level cache in the cloud server for data reading and use for corresponding business. Therefore, the authentication information is relatively fixed within a certain period of time.

[0192] Furthermore, it is understood that if IAM suddenly fails, and the last level cache in the multi-level cache fails to request target cache data from IAM, and the failure rate exceeds a preset threshold, this application embodiment proposes that the last level cache (e.g., the aforementioned L) can be manually or automatically increased. N The timeEffective threshold for cached data. This ensures that the failure time does not exceed L. N If the cached timeExpires, then it can continue from the last level of cache (i.e., L). N The target cached data is read from the cache.

[0193] In other words, in continuous business scenarios, it is only necessary to use L N Within the cache's timeExpire period, if user U1 has successfully accessed object storage, causing object storage to retrieve the enabled authentication information from IAM, then for example, if the timeExpire of the last tier cache is increased to 1 day, then as long as the user U1 accesses object storage within a 1-day timeframe, then the object storage will be able to retrieve the enabled authentication information from IAM. N The cache has one valid request, so even if the IAM failure lasts for a full day (which is extremely rare in real-world cloud services), the L... N The cache can still provide a one-day fallback service instead of IAM. Similarly, in a multi-level cache, if the failure rate of a certain layer in the cache system is too high and exceeds a preset value, the cache system can also fall back and block calls to this layer (i.e., the current cache), and other layers (e.g., the next level of the current cache) can continue to provide query services for retrieving the target cache data.

[0194] Wherein, it can be understood that assuming that the N-level cache is a 3-level cache (for example, L1 cache, L2 cache and L3 cache), when the above data acquisition request reaches the L1 cache (at this time, the service process corresponding to the L1 cache acquires the data acquisition request), and the target cache data cannot be found (i.e., not found) in the L1 cache, at this time, the access server in the cloud server actually does not know whether the data acquisition request is a cold reading request, therefore, the access process in the access server forwards the data acquisition request to the service process corresponding to the L2 cache, which is the next cache of the L1 cache. Similarly, when the above data acquisition request reaches the L2 cache (at this time, the service process corresponding to the L2 cache acquires the data acquisition request forwarded by the L1 cache), and the target cache data cannot be found (i.e., not found) in the L2 cache, another cache server in the cloud server (for example, the computer device where the service process corresponding to the L2 cache is located) actually also does not know whether the data acquisition request is a cold reading request, therefore, the another cache server in the cloud server (for example, the computer device where the service process corresponding to the L2 cache is located) needs to further submit the data acquisition request to still another cache server in the cloud server (for example, the computer device where the service process corresponding to the L3 cache is located, wherein the L3 cache is the next cache of the L2 cache). In this way, when the target cache data is also not found (i.e., not found) in the L3 cache, the cloud server can determine that the current acquired data acquisition request is a cold reading request, it should be understood that the cold reading request herein refers to that the cloud server first acquires the reading request carrying the business data sent by the business client, therefore, the cloud server cannot find the target cache data matching the business data in each level of the multi-level cache, for example, in the process that the cloud server provides object storage service for the client (for example, the user U1) corresponding to the business client through the multi-level cache, if the target cache data matching the target business data requested by the user U1 is not found in each level of the multi-level cache (i.e., each level of the N-level cache), the cold reading request (i.e., the above data acquisition request) carrying the target business data (for example, client identifier and signature information) needs to be further transmitted to the underlying module (i.e., IAM), so that the underlying module (i.e., IAM) can return the target cache data (i.e., authentication and permission information) to the cloud server.

[0195] In addition, regarding the cache update, in the embodiment of the present application, each level of cache in the multi-level cache flushes into the current layer cache when an effective data (i.e. the above-mentioned effective cache data) is obtained from the next level cache. Therefore, considering the boundary condition as an input quantity, the longest cache delay reading duration (i.e. the maximum delay reading duration for reading the target cache data for the final reading, that is, the duration read after reading in the N multi-level cache one by one) in the continuous service scenario can be calculated:

[0196] wherein, wherein timeRefresh i is the refresh time (i.e. the above-mentioned cache refresh duration) of any i-th level cache in the N-level cache, and N is the number of cache levels of the multi-level cache. According to this formula, if you want to improve the timeliness, you can reduce the number of cache levels, and also shorten the refresh time threshold of each level of cache to speed up the refresh frequency.

[0197] As can be seen, for any two adjacent caches (i.e. the first level cache and the second level cache) in the multi-level cache, once the target cache data matching the target service data carried in the data acquisition request is found in the first level cache (such as the current cache), the cache existence duration (i.e. the first cache existence duration) of the target cache data in the current cache can be further determined, and then the target cache data stored in the first level cache which still has validity can be determined as the valid cache data to be updated, so that the cache update data obtained from the second cache level can be refreshed to the current cache (i.e. the first level cache) in advance before the target cache data expires through the new asynchronous refresh mechanism. In other words, in the embodiment of the present application, the computer device (such as the cloud server in the cloud service scenario) can improve the timeliness and reliability of cache update through the new asynchronous refresh mechanism in the process of cache update of the target cache data cached in the current cache (i.e. the first level cache, for example, the above-mentioned current cache). In addition, the present application also sets an expiration cleaning mechanism (i.e. the above-mentioned expiration cleaning strategy) and a disaster recovery processing mechanism (i.e. the above-mentioned disaster recovery degradation processing strategy) for the target cache data in the current cache, so that the target cache data cached in the current cache for providing data query service can be ensured to be safe and effective target cache data.

[0198] Further, please refer to FIG. 9, which is a structural schematic diagram of a cache updating apparatus based on multi-level cache provided by the embodiment of the present application. The cache updating apparatus based on multi-level cache 1 can run on a cloud server. The cloud server can refer to a server cluster composed of multiple servers associated with the multi-level cache in the cache system (for example, the multiple servers can include cache servers corresponding to L1 cache, cache servers corresponding to L2 cache, and so on, and cache servers corresponding to L N For ease of understanding, the cache updating between any two adjacent caches in the multi-level cache is taken as an example. The any two adjacent caches refer to the first level cache and the second level cache included in the multi-level cache. The second level cache is the next level cache of the first level cache, and the search priority of the first level cache is higher than that of the second level cache.

[0199] As shown in FIG. 9, the cache updating apparatus based on multi-level cache 1 can include a cache searching module 11, an existence duration determining module 12, an asynchronous refreshing module 13, and a cache data updating module 14.

[0200] The cache searching module 11 is configured to search for target cache data matching target service data carried by the data acquisition request in the first level cache when the data acquisition request sent by the service client is acquired.

[0201] The existence duration determining module 12 is configured to acquire an asynchronous cache updating strategy associated with the first level cache if the target cache data is found in the first level cache. The asynchronous cache updating strategy includes a cache duration determining sub-strategy and an effective cache determining sub-strategy.

[0202] The existence duration determining module 12 is further configured to determine a first cache existence duration of the target cache data in the first level cache based on the cache duration determining sub-strategy.

[0203] The asynchronous refreshing module 13 is configured to generate an asynchronous refreshing task if the first cache existence duration meets the effective cache determining sub-strategy, and submit the asynchronous refreshing task to the second level cache through a first task deduplicator associated with the first level cache. The asynchronous refreshing task is used to indicate searching for cache updating data for updating the target cache data in the second level cache.

[0204] The cache data updating module 14 is configured to receive the cache updating data returned by the second level cache through the first task deduplicator, and update the target cache data to the cache updating data in the first level cache.

[0205] The specific implementation of the cache lookup module 11, the existence duration determination module 12, the asynchronous refreshing module 13, and the cache data updating module 14 can be referred to the description of steps S101-S105 in the embodiment corresponding to FIG. 3, and will not be repeated here.

[0206] Optionally, the apparatus 1 (i.e., the cache updating apparatus based on the multi-level cache) further includes a write request receiving module 15 and a response information receiving module 16.

[0207] The write request receiving module 15 is configured to receive a data write request for the target cache data sent by the service client, and send the target cache data to the service database associated with the multi-level cache based on the data write request, so that the service database generates database write response information for the target cache data when successfully writing the target cache data.

[0208] The response information receiving module 16 is configured to receive the database write response information returned by the service database, and return the database write response information to the service client.

[0209] The specific implementation of the write request receiving module 15 and the response information receiving module 16 can be referred to the description of the specific process of writing the target cache data to the service database based on the data write request in the embodiment corresponding to FIG. 6, and will not be repeated here.

[0210] The target cache data is cached in the first level cache and the second level cache; and the second cache existence duration of the target cache data in the second level cache is greater than the first cache existence duration of the target cache data in the first level cache.

[0211] The apparatus 1 further includes an updating message generating module 17 and an updating message sending module 18.

[0212] The updating message generating module 17 is configured to generate a cache updating message for the target cache data when returning the database write response information to the service client.

[0213] The updating message sending module 18 is configured to send the cache updating message to the message queue system, so that the message queue system updates the target cache data to the second level cache and the first level cache based on the cache updating message; and the update priority of the second level cache is higher than that of the first level cache.

[0214] The specific implementation of the updating message generating module 17 and the updating message sending module 18 can be referred to the description of the specific process of updating the target cache data to any two adjacent level caches in the multi-level cache, and will not be repeated here.

[0215] wherein the message queue system is a distributed stream processing system; the cache update message comprises a first update message for the second tier cache and a second update message comprising a second update message for the first tier cache;

[0216] The update message sending module 18 is specifically configured to acquire a cache waiting strategy associated with the cache update message;

[0217] The update message sending module 18 is also specifically configured to send the first update message to the second tier cache through the distributed stream processing system based on the cache waiting strategy, so that the second tier cache deletes the initial cache data associated with the target business data cached in the second tier cache based on the first update message, and caches the updated target cache data in the second tier cache;

[0218] The update message sending module 18 is also specifically configured to send the second update message to the first tier cache through the distributed stream processing system based on the waiting interval indicated by the cache waiting strategy, so that the first tier cache deletes the initial cache data cached in the first tier cache based on the second update message, and caches the updated target cache data in the first tier cache.

[0219] Optionally, the message queue system is a message-oriented processing system; the cache update message comprises a third update message for the second tier cache and a fourth update message comprising a first update message for the first tier cache;

[0220] The update message sending module 18 is also specifically configured to acquire a message confirmation strategy associated with the cache update message;

[0221] The update message sending module 18 is also specifically configured to send the third update message to the second tier cache through the message-oriented processing system based on the message confirmation strategy, so that the second tier cache deletes the initial cache data associated with the target business data cached in the second tier cache based on the third update message, and generates a first cache confirmation message for the target cache data when the second tier cache caches the updated target cache data.

[0222] The update message sending module 18 is also specifically configured to receive the first cache confirmation message returned by the second tier cache through the message-oriented processing system, and send the fourth update message to the first tier cache through the message-oriented processing system based on the first cache confirmation message, so that the first tier cache deletes the initial cache data cached in the first tier cache based on the fourth update message, and generates a second cache confirmation message for the target cache data when the first tier cache caches the updated target cache data.

[0223] The update message sending module 18 is also specifically configured to receive a second cache confirmation message returned by the message-oriented processing system through the first-level cache.

[0224] It can be understood that the update message sending module 18 realizes the specific process of the traversal update of the second-level cache and the first-level cache in the multi-level cache through any one message queue system in the distributed stream processing system or the message-oriented processing system. For details, refer to the description of the specific process of step S204 in the embodiment corresponding to FIG. 6, which will not be repeated here.

[0225] The method is executed by an access server in a cloud server. If the first-level cache includes a first-level cache in the multi-level cache, the access server includes the first-level cache and a local access process associated with the first-level cache. The first-level cache is a local data storage memory.

[0226] The cache searching module 11 is specifically configured to receive a data reading request for reading target service data sent by the service client through the local access process, and take the data reading request as a data acquisition request acquired by the local access process.

[0227] The cache searching module 11 is also specifically configured to read the target service data in the local data storage memory based on the data acquisition request, and search for target cache data matching the target service data in the local data storage memory.

[0228] Optionally, the second-level cache includes a distributed cache associated with the cache service process. The distributed cache is the last-level cache of the multi-level cache. The cache service process is a service process different from the local access process.

[0229] The device 1 further includes an acquisition request submitting module 19.

[0230] The acquisition request submitting module 19 is configured to, if the target cache data is not searched in the local data storage memory, submit the data acquisition request to the cache service process. The data acquisition request is used to instruct the cache service process to determine the data acquisition request as a cold reading request when the target cache data is not searched in the second-level cache, and acquire the target cache data in the service database associated with the multi-level cache based on the cold reading request.

[0231] For details of the specific execution mode of the acquisition request submitting module 19, refer to the description of the specific process of acquiring the target cache data from the service database based on the cold reading request in the embodiment corresponding to FIG. 3, which will not be repeated here.

[0232] Optionally, the device 1 further includes a synchronization request receiving module 20.

[0233] The synchronization request receiving module 20 is configured to receive a data synchronization write request for target cache data sent by the cache service process; the data synchronization write request is generated when the cache service process obtains the target cache data from the business database and writes the target cache data into the distributed cache;

[0234] The synchronization request receiving module 20 is further configured to write the target cache data into the local data storage memory based on the data synchronization write request.

[0235] The specific implementation of the synchronization request receiving module 20 can refer to the description of the specific process of writing the target cache data into the local data storage memory based on the data synchronization request in the embodiment corresponding to FIG. 3, and will not be repeated here.

[0236] The write timestamp of the target cache data in the first-level cache is a first cache write timestamp;

[0237] The existence duration determining module 12 is specifically configured to determine a cache duration determining sub-strategy from the asynchronous cache updating strategy, obtain a cache write parameter and a cache system parameter based on the cache duration determining sub-strategy, determine a parameter value of the cache write parameter as the first cache write timestamp, and determine a parameter value of the cache system parameter as a system timestamp of a cache system where the multi-level cache is located. The cache write parameter refers to a time parameter of inserting the target cache data extracted from the write log of the first-level cache into the first-level cache. The cache system parameter refers to a time parameter currently recorded in real time by the cache system where the multi-level cache is located.

[0238] The existence duration determining module 12 is further configured to determine a time difference between the system timestamp and the first cache write timestamp as the first cache existence duration of the target cache data in the first-level cache.

[0239] The specific implementation of the existence duration determining module 12 can refer to the description of the specific process of obtaining the first cache existence duration in the embodiment corresponding to FIG. 3, and will not be repeated here.

[0240] The asynchronous cache updating strategy further includes a cache refreshing sub-strategy.

[0241] The asynchronous refreshing module 13 is specifically configured to obtain a valid cache determining sub-strategy from the asynchronous cache updating strategy, obtain a cache valid parameter corresponding to the first-level cache based on the valid cache determining sub-strategy, and determine a parameter value of the cache valid parameter as the first cache valid duration of the target cache data. The cache valid parameter refers to a time parameter extracted from a cache configuration log corresponding to the first-level cache.

[0242] The asynchronous refreshing module 13 is also specifically configured to acquire a cache refreshing sub-strategy from the asynchronous cache updating strategy, acquire a cache refreshing parameter corresponding to the first-level cache based on the cache refreshing sub-strategy, and determine a parameter value of the cache refreshing parameter as a first cache refreshing time length corresponding to the target cache data; the cache refreshing parameter refers to a time parameter extracted from the cache configuration log;

[0243] The asynchronous refreshing module 13 is also specifically configured to, if the first cache existing time length is less than the first cache valid time length and the first cache existing time length is greater than the first cache refreshing time length, determine that the first cache existing time length satisfies the asynchronous cache updating strategy.

[0244] The asynchronous refreshing module 13 is also specifically configured to, when the target cache data corresponding to the first cache existing time length satisfying the asynchronous cache updating strategy is determined as the to-be-updated cache data, generate an asynchronous refreshing task; the to-be-updated cache data refers to the target cache data in the valid state.

[0245] The specific implementation of the asynchronous refreshing module 13 can refer to the description of the specific process of generating an asynchronous refreshing task and determining to-be-updated cache data based on the asynchronous cache updating strategy in the embodiment corresponding to FIG. 3, which will not be repeated here.

[0246] If the first-level cache is not the first-level cache in the multi-level cache, the data acquisition request is a request for acquiring the target service data forwarded by the previous-level cache of the first-level cache;

[0247] The apparatus 1 also includes an effective cache determining module 21.

[0248] The effective cache determining module 21 is configured to, if the first cache existing time length is less than the first cache valid time length, determine that the first cache existing time length satisfies the effective cache determining sub-strategy, and determine the target cache data corresponding to the first cache existing time length satisfying the effective cache determining sub-strategy as the effective cache data.

[0249] The effective cache determining module 21 is also configured to return the effective cache data to the previous-level cache of the first-level cache, so that the previous-level cache of the first-level cache performs cache processing on the effective cache data; the previous-level cache of the first-level cache at least includes the first cache level.

[0250] The specific implementation of the effective cache determining module 21 can refer to the description of the specific process of returning the effective cache data to the previous-level cache in the embodiment corresponding to FIG. 3, which will not be repeated here.

[0251] Optionally, if the first-level cache is a first cache level in the multi-level cache, the data acquisition request is a request sent by the service client for acquiring the target service data.

[0252] The apparatus further includes an effective service determination module 22.

[0253] The effective service determination module 22 is configured to determine that the first cache existence duration satisfies the effective cache determination sub-strategy if the first cache existence duration is less than the first cache effective duration, and determine the target cache data corresponding to the first cache existence duration satisfying the effective cache determination sub-strategy as the effective service data.

[0254] The effective service determination module 22 is further configured to perform a service processing task for the target service data based on the effective service data, and obtain a service processing result of the service processing task; the service processing task is a request task carried in the data acquisition request.

[0255] The effective service determination module 22 is further configured to return the service processing result to the service client.

[0256] The specific implementation of the effective service determination module 22 can refer to the description of the specific process of returning the service processing result to the service client, which will not be repeated here.

[0257] Optionally, the apparatus further includes an invalid data determination module 23.

[0258] The invalid data determination module 23 is configured to determine that the first cache existence duration does not satisfy the effective cache determination sub-strategy if the first cache existence duration is greater than or equal to the first cache effective duration.

[0259] The invalid data determination module 23 is further configured to submit the data acquisition request to a second task deduplicator associated with the first-level cache when the target cache data corresponding to the first cache existence duration not satisfying the effective cache determination sub-strategy is determined as invalid data, so that the second task deduplicator sends the data acquisition request to a second-level cache when no synchronization refresh task associated with the target service data is detected.

[0260] The specific implementation of the invalid data determination module 23 can refer to the description of the specific process of submitting the data acquisition request to the second task deduplicator in the embodiments corresponding to FIG. 3 or FIG. 6, which will not be repeated here.

[0261] Optionally, the apparatus further includes an effective data maintenance module 24.

[0262] The effective data maintaining module 24 is configured to determine that the first cache existing duration does not satisfy the cache refreshing sub-strategy if the first cache existing duration is less than or equal to the first cache refreshing duration, and maintain the target cache data corresponding to the first cache existing duration that does not satisfy the cache refreshing sub-strategy as effective data. The effective data includes any one of effective cache data or effective service data.

[0263] The specific implementation of the effective data maintaining module 24 can refer to the description of the specific process of determining effective data in the above-mentioned embodiments of FIG. 3 or FIG. 6, and will not be repeated here.

[0264] Optionally, the first level cache is not the first level cache in the multi-level cache.

[0265] The obtaining request submitting module 19 is further configured to submit the data obtaining request to the second task deduplicator associated with the first level cache if the target cache data is not found in the first level cache, so that the second task deduplicator submits the data obtaining request to the second level cache when it is detected in the task pool that there is no data synchronization task associated with the target service data, and marks the request task indicated by the data obtaining request as a data synchronization task in the task pool. The data synchronization task is used to indicate searching for the target cache data in the second level cache.

[0266] Optionally, the first level cache is not the first level cache in the multi-level cache.

[0267] The obtaining request submitting module 19 is further configured to submit the data obtaining request to the second task deduplicator associated with the first level cache if the target cache data is not found in the first level cache, so that the second task deduplicator submits the request task indicated by the data obtaining request as a waiting task in the task pool when it is detected in the task pool that there is already a data synchronization task associated with the target service data. The second task deduplicator is configured to notify the waiting task in the task pool to reuse the target effective data when the target effective data is obtained from the second level cache through the data synchronization task. The target effective data is the target cache data.

[0268] The obtaining request submitting module 19 is further configured to receive the target cache data returned by the second task deduplicator and synchronize and refresh the target cache data to the first level cache.

[0269] Optionally, the apparatus 1 further includes an expired clearing module 25.

[0270] The expiration clearing module 25 is configured to acquire a cache expiration parameter and a cache validity parameter associated with the first-level cache, determine a parameter value of the cache expiration parameter as a first cache expiration duration of the target cache data, and determine a parameter value of the cache validity parameter as a first cache validity duration of the target cache data.

[0271] The expiration clearing module 25 is further configured to, when detecting that the first cache validity duration is less than or equal to the first cache expiration duration, determine the target cache data stored in the first-level cache as expired cache data to be cleared, and clear the expired cache data in the first-level cache.

[0272] The specific implementation of the expiration clearing module 25 can refer to the description of the specific process of clearing the expired cache data in the embodiment corresponding to FIG. 6, and will not be described here.

[0273] Optionally, the second-level cache stores the target cache data, a storage duration of the target cache data in the second-level cache is a second cache existence duration, and the second-level cache is the last-level cache in the multi-level cache; a parameter value of the cache validity parameter of the second-level cache is a second cache validity duration, and a parameter value of the cache expiration parameter of the second-level cache is a second cache expiration duration.

[0274] The apparatus 1 further includes a disaster recovery processing module 26.

[0275] The disaster recovery processing module 26 is configured to, when a service fault event exists in a service database associated with the multi-level cache, notify the second-level cache to perform duration adjustment on the second cache validity duration within a fault duration indicated by the service fault event, to obtain a cache update validity duration; the cache update validity duration is used to indicate that the service database is subjected to disaster recovery processing by the target cache data in the second-level cache within the fault duration.

[0276] The fault duration is less than or equal to the second cache expiration duration, and the cache update validity duration is used to indicate that the target cache data stored in the second-level cache is maintained as valid data when the cache update validity duration is greater than the second cache validity duration and the second cache existence duration is less than the cache update validity duration.

[0277] The specific implementation of the disaster recovery processing module 26 can refer to the description of the specific process of performing disaster recovery processing on the service database by the valid data cached in the last-level cache in the embodiment corresponding to FIG. 6, and will not be described here.

[0278] It can be seen that, for any two adjacent caches (i.e., the first level cache and the second level cache) in the multi-level cache, once the target cache data matching the target service data carried in the data acquisition request is found in the first level cache (such as the current cache), the cache existence duration (i.e., the first cache existence duration) of the target cache data in the current cache can be further determined, and then the target cache data stored in the first level cache and still having validity can be determined as the to-be-updated cache data having validity, so that the cache update data acquired from the second cache level can be refreshed to the current cache (i.e., the first level cache) in advance before the target cache data is invalid through the new asynchronous refreshing mechanism. In other words, in the embodiment of the application, the computer device (such as the cloud server in the cloud service scenario) can improve the timeliness and reliability of cache updating through the new asynchronous refreshing mechanism in the process of updating the target cache data cached in the current cache (i.e., the first level cache).

[0279] Further, please refer to FIG. 10, which is a structural schematic diagram of a computer device provided in the embodiment of the application. As shown in FIG. 10, the computer device 1000 can be a cloud server, for example, the cloud server 100a in the embodiment corresponding to FIG. 1, which will not be limited here. The computer device 1000 can include a processor 1001, a network interface 1004 and a memory 1005, in addition, the computer device 1000 can further include a user interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to realize the connection and communication between the components. The user interface 1003 can further include a standard wired interface, a wireless interface. The network interface 1004 can optionally include a standard wired interface, a wireless interface (such as a WI-FI interface). The memory 1005 can be a high-speed RAM memory, or a non-volatile memory, for example, at least one disk memory. The memory 1005 can optionally be at least one storage device located away from the aforementioned processor 1001. As shown in FIG. 10, the memory 1005 as a computer readable storage medium can include an operating system, a network communication module, a user interface module and a device control application program.

[0280] The network interface 1004 in the computer device 1000 can also provide network communication functions. In the computer device 1000 shown in FIG. 10, the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an interface for user input; and the processor 1001 can be used to invoke a device control application stored in the memory 1005 to execute the description of the cache update method based on the multi-level cache in the foregoing embodiment corresponding to FIG. 3 or FIG. 6, or execute the description of the cache update apparatus 1 based on the multi-level cache in the foregoing embodiment corresponding to FIG. 9, which will not be described herein again. In addition, the description of the beneficial effects of using the same method will also not be described again.

[0281] In addition, it should be noted that the computer readable storage medium stores the computer program executed by the cache update apparatus 1 based on the multi-level cache mentioned above, and the computer program includes computer instructions. When the processor executes the computer instructions, the description of the cache update method based on the multi-level cache in the foregoing embodiment corresponding to FIG. 3 or FIG. 6 can be executed, and thus the description will not be described herein again. In addition, the description of the beneficial effects of using the same method will also not be described again. For technical details not disclosed in the computer readable storage medium embodiments of the present application, please refer to the description of the method embodiments of the present application. For example, the computer instructions can be deployed on one computer device for execution, or on multiple computer devices located in one place for execution, or on multiple computer devices distributed in multiple places and interconnected through a communication network for execution, and the multiple computer devices distributed in multiple places and interconnected through a communication network can constitute a blockchain system.

[0282] In addition, it should be noted that the computer readable storage medium stores the computer program executed by the cache update apparatus 1 based on the multi-level cache mentioned above, and the computer program includes computer instructions. When the processor executes the computer instructions, the description of the cache update method based on the multi-level cache in the foregoing embodiment corresponding to FIG. 3 or FIG. 6 can be executed, and thus the description will not be described herein again. In addition, the description of the beneficial effects of using the same method will also not be described again. For technical details not disclosed in the computer readable storage medium embodiments of the present application, please refer to the description of the method embodiments of the present application. For example, the computer instructions can be deployed on one computer device for execution, or on multiple computer devices located in one place for execution, or on multiple computer devices distributed in multiple places and interconnected through a communication network for execution, and the multiple computer devices distributed in multiple places and interconnected through a communication network can constitute a blockchain system.

[0283] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined target, and can be implemented entirely or partially by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an integral module or unit that includes the functions of the module or unit.

[0284] The above disclosure is only the preferred embodiments of the present application, and of course cannot limit the scope of the right of the present application, so the equivalent changes made according to the claims of the present application still fall within the scope covered by the present application.

Claims

1. A cache update method based on a multi-level cache, characterized by, The multi-level cache includes a first level cache and a second level cache, the second level cache is a next level cache of the first level cache, a search priority of the first level cache is higher than a search priority of the second level cache, and the method includes: obtaining a data acquisition request sent by a service client, searching for target cache data matching target service data carried by the data acquisition request in the first level cache; if the target cache data is found in the first level cache, obtaining an asynchronous cache update strategy associated with the first level cache; the asynchronous cache update strategy includes a cache duration determination sub-strategy and an effective cache determination sub-strategy; determining a first cache existence duration of the target cache data in the first level cache based on the cache duration determination sub-strategy; if the first cache existence duration meets the effective cache determination sub-strategy, generating an asynchronous refresh task, and submitting the asynchronous refresh task to the second level cache through a first task deduplicator associated with the first level cache; the asynchronous refresh task is used to instruct searching for cache update data for updating the target cache data in the second level cache; receiving the cache update data returned by the second level cache through the first task deduplicator, and updating the target cache data to the cache update data in the first level cache.

2. The method of claim 1, wherein, The method further includes: receiving a data write request for the target cache data sent by the service client, and sending the target cache data to a service database associated with the multi-level cache based on the data write request, so that the service database generates database write response information for the target cache data when successfully writing the target cache data; receiving the database write response information returned by the service database, and returning the database write response information to the service client.

3. The method of claim 2, wherein, The target cache data is cached in the first level cache and the second level cache; a second cache existence duration of the target cache data in the second level cache is greater than a first cache existence duration of the target cache data in the first level cache; The method further includes: generating a cache update message for the target cache data when returning the database write response information to the service client; sending the cache update message to a message queue system, so that the message queue system updates the target cache data to the second level cache and the first level cache based on the cache update message; an update priority of the second level cache is higher than an update priority of the first level cache.

4. The method of claim 3, wherein, The message queue system is a distributed stream processing system; the cache update message includes a first update message for the second level cache and a second update message for the first level cache; The sending of the cache update message to the message queue system includes: obtaining a cache waiting strategy associated with the cache update message; sending the first update message to the second tier cache based on the cache waiting strategy, so that the second tier cache deletes the initial cache data associated with the target business data cached in the second tier cache based on the first update message, and caches the target cache data in the second tier cache; sending the second update message to the first tier cache based on the waiting interval indicated by the cache waiting strategy, so that the first tier cache deletes the initial cache data cached in the first tier cache based on the second update message, and caches the target cache data in the first tier cache.

5. The method of claim 3, wherein, The message queue system is a message-oriented processing system; the cache update message includes a third update message for the second tier cache and a fourth update message for the first tier cache; The sending of the cache update message to the message queue system comprises: obtaining a message confirmation strategy associated with the cache update message; sending the third update message to the second tier cache based on the message confirmation strategy through the message-oriented processing system, so that the second tier cache generates a first cache confirmation message for the target cache data when the second tier cache caches the target cache data based on the third update message; receiving the first cache confirmation message returned by the second tier cache through the message-oriented processing system, and sending the fourth update message to the first tier cache through the message-oriented processing system based on the first cache confirmation message, so that the first tier cache generates a second cache confirmation message for the target cache data when the first tier cache caches the target cache data based on the fourth update message; receiving the second cache confirmation message returned by the first tier cache through the message-oriented processing system.

6. The method of claim 1, wherein, The method is executed by an access server in a cloud server, and if the first tier cache includes a first tier cache in the multi-tier cache, the access server includes the first tier cache and a local access process associated with the first tier cache; The first tier cache is a local data storage memory; The method comprises the following steps: receiving, by the local access process, a data read request sent by the business client for reading target business data, and taking the data read request as the data acquisition request acquired by the local access process; receiving, by the local access process, a data read request sent by the business client for reading target business data, and taking the data read request as the data acquisition request acquired by the local access process; reading the target service data in the local data storage memory based on the data acquisition request, and searching for target cache data matching the target service data in the local data storage memory.

7. The method of claim 6, wherein, The second level cache comprises a distributed cache associated with a cache service process, the distributed cache being the last level cache of the multi-level cache, and the cache service process being a service process different from the local access process; The method further comprises: If the target cache data is not searched for in the local data storage memory, the data acquisition request is submitted to the cache service process, the data acquisition request being used to instruct the cache service process to determine the data acquisition request as a cold read request when the target cache data is not searched for in the second level cache, and acquire the target cache data in a service database associated with the multi-level cache based on the cold read request.

8. The method of claim 7, wherein, The method further comprises: receiving a data synchronization write request for the target cache data sent by the cache service process, the data synchronization write request being generated by the cache service process when the target cache data is acquired from the service database and written into the distributed cache; writing the target cache data into the local data storage memory based on the data synchronization write request.

9. The method of claim 1, wherein, The write timestamp of the target cache data in the first level cache is a first cache write timestamp; The first cache existing duration of the target cache data in the first level cache based on the cache duration determination sub-strategy comprises: determining a cache duration determination sub-strategy from the asynchronous cache update strategy, acquiring a cache write parameter and a cache system parameter based on the cache duration determination sub-strategy, determining a parameter value of the cache write parameter as the first cache write timestamp, and determining a parameter value of the cache system parameter as a system timestamp of a cache system where the multi-level cache is located; the cache write parameter refers to a time parameter of inserting the target cache data extracted from a write log of the first level cache into the first level cache, and the cache system parameter refers to a time parameter currently recorded in real time by the cache system where the multi-level cache is located; determining a time difference value between the system timestamp and the first cache write timestamp as the first cache existing duration of the target cache data in the first level cache.

10. The method of claim 1, wherein, The asynchronous cache update strategy further comprises a cache refresh sub-strategy; If the first cache existing duration satisfies the valid cache determination sub-strategy, an asynchronous refresh task is generated, comprising: acquiring the valid cache determination sub-strategy from the asynchronous cache update strategy, acquiring a cache valid parameter corresponding to the first level cache based on the valid cache determination sub-strategy, and taking a parameter value of the cache valid parameter as a first cache valid duration of the target cache data; the cache valid parameter refers to a time parameter extracted from a cache configuration log corresponding to the first level cache. The cache refresh sub-strategy is obtained from the asynchronous cache update strategy, a cache refresh parameter corresponding to the first level cache is obtained based on the cache refresh sub-strategy, and a parameter value of the cache refresh parameter is determined as a first cache refresh time length corresponding to the target cache data; the cache refresh parameter refers to a time parameter extracted from the cache configuration log; If the first cache existing time length is less than the first cache effective time length, and the first cache existing time length is greater than the first cache refresh time length, it is determined that the first cache existing time length satisfies the asynchronous cache update strategy; When the target cache data corresponding to the first cache existing time length satisfying the asynchronous cache update strategy is determined as to-be-updated cache data, the asynchronous refresh task is generated, and the to-be-updated cache data refers to target cache data in a valid state.

11. The method of claim 10, wherein, If the first level cache is not the first level cache in the multi-level cache, the data acquisition request is a request for acquiring the target service data forwarded by a previous level cache of the first level cache; The method further comprises: If the first cache existing time length is less than the first cache effective time length, it is determined that the first cache existing time length satisfies the valid cache determination sub-strategy, and the target cache data corresponding to the first cache existing time length satisfying the valid cache determination sub-strategy is determined as valid cache data; The valid cache data is returned to the previous level cache of the first level cache, so that the previous level cache of the first level cache performs cache processing on the valid cache data; the previous level cache of the first level cache at least includes the first cache level.

12. The method of claim 10, wherein, If the first level cache is the first cache level in the multi-level cache, the data acquisition request is a request for acquiring the target service data sent by the service client; The method further comprises: If the first cache existing time length is less than the first cache effective time length, it is determined that the first cache existing time length satisfies the valid cache determination sub-strategy, and the target cache data corresponding to the first cache existing time length satisfying the valid cache determination sub-strategy is determined as valid service data; A service processing task for the target service data is performed based on the valid service data, and a service processing result of the service processing task is obtained; the service processing task is a request task carried in the data acquisition request; The service processing result is returned to the service client.

13. The method of claim 10, wherein, The method further comprises: If the first cache existing time length is greater than or equal to the first cache effective time length, it is determined that the first cache existing time length does not satisfy the valid cache determination sub-strategy; When the data of the target cache data corresponding to the first cache existing duration which does not satisfy the effective cache determination sub-strategy is determined as invalid data, the data acquisition request is submitted to a second task deduplicator associated with the first level cache, so that the second task deduplicator sends the data acquisition request to the second level cache when no synchronization refresh task associated with the target service data is detected.

14. The method of claim 1, wherein, The first level cache is not the first level cache in the multi-level cache; The method further comprises: If the target cache data is not found in the first level cache, the data acquisition request is submitted to a second task deduplicator associated with the first level cache, so that the second task deduplicator detects a data synchronization task associated with the target service data in a task pool, and the request task indicated by the data acquisition request is used as a waiting task in the task pool. When the target effective data is obtained from the second level cache by the data synchronization task, the second task deduplicator notifies the waiting task in the task pool to reuse the target effective data. The target effective data is the target cache data. The target cache data returned by the second task deduplicator is received, and the target cache data is synchronized and refreshed to the first level cache.

15. The method of claim 1, wherein, The method further comprises: A cache expiration parameter and a cache validity parameter associated with the first level cache are obtained, a parameter value of the cache expiration parameter is determined as a first cache expiration duration of the target cache data, and a parameter value of the cache validity parameter is used as a first cache validity duration of the target cache data. When it is detected that the first cache validity duration is less than or equal to the first cache expiration duration, the target cache data stored in the first level cache is determined as expired cache data to be cleaned, and the expired cache data is cleaned in the first level cache.

16. The method of claim 1, wherein, The second level cache stores the target cache data, and a storage duration of the target cache data in the second level cache is a second cache existing duration. The second level cache is the last level cache in the multi-level cache. A parameter value of a cache validity parameter of the second level cache is a second cache validity duration, and a parameter value of a cache expiration parameter of the second level cache is a second cache expiration duration. The method further comprises: When a service failure event exists in a service database associated with the multi-level cache, the second level cache is notified to adjust the second cache validity duration to obtain a cache update validity duration within a failure duration indicated by the service failure event. The cache update validity duration is used to indicate that the service database is subjected to disaster recovery processing by the target cache data in the second level cache within the failure duration. The fault duration is less than or equal to the second cache expiration duration. The cache update valid duration is used to indicate that the target cache data stored in the second level cache is maintained as valid data when the cache update valid duration is greater than the second cache valid duration and the second cache existence duration is less than the cache update valid duration.

17. A cache updating apparatus based on a multi-level cache, characterized by comprising: The multi-level cache includes a first level cache and a second level cache. The second level cache is a next level cache of the first level cache. The first level cache has a higher search priority than the second level cache. The apparatus includes: A cache search module is configured to search for target cache data matching target service data carried by a data acquisition request sent by a service client in the first level cache when the data acquisition request is acquired. An existence duration determination module is configured to acquire an asynchronous cache update strategy associated with the first level cache if the target cache data is found in the first level cache. The asynchronous cache update strategy includes a cache duration determination sub-strategy and a valid cache determination sub-strategy. The existence duration determination module is further configured to determine a first cache existence duration of the target cache data in the first level cache based on the cache duration determination sub-strategy. An asynchronous refreshing module is configured to generate an asynchronous refreshing task if the first cache existence duration meets the valid cache determination sub-strategy, and submit the asynchronous refreshing task to the second level cache through a first task deduplicator associated with the first level cache. The asynchronous refreshing task is used to indicate that cache update data for updating the target cache data is searched in the second level cache. A cache data update module is configured to receive the cache update data returned by the second level cache through the first task deduplicator, and update the target cache data to the cache update data in the first level cache.

18. A computer device, comprising: The computer device includes a memory and a processor. The memory is connected to the processor. The memory is configured to store a computer program. The processor is configured to call the computer program to enable the computer device to perform the method in any one of claims 1-16.

19. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program. The computer program is adapted to be loaded and executed by the processor to enable a computer device having the processor to perform the method in any one of claims 1-16.

20. A computer program product, characterised in that, The computer program / instruction is executed by the processor to implement the method in any one of claims 1-16.

Images