A method, system, and storage medium for fast application cache refresh targeting important content.

Abstract

This invention discloses a method, system, and storage medium for fast refresh of application cache for important content. First, all URIs associated with the navigation ID corresponding to the fast refresh interface for important content are collected and stored in Redis. Content update notifications are received asynchronously, and the content detail cache is updated synchronously. Based on the many-to-many association between catalog ID and navigation ID, all associated navigation IDs are queried, and the corresponding URI set is obtained from Redis. The request requiring refresh and the fast refresh interface are determined and sent to an independent fast refresh queue in the facade cache management middleware, where the cache refresh operation is executed asynchronously. This invention adds a fast channel for important content caching to the existing caching architecture, realizing asynchronous refresh of important and ordinary content.

Description

Technical Field

[0001] This invention belongs to the technical field of application caching, specifically relating to a method, system, and storage medium for fast refresh of application cache for important content. Background Technology

[0002] Currently, mobile application (APP) list and detail interfaces generally adopt a caching architecture using the HTTP caching server Varlish and the cache management middleware Facade. The Facade caching mechanism works by deduplicating all request URLs, placing them in a message queue, and then asynchronously updating the corresponding cached content. While this architecture enables batch updates and reduces database access pressure, it has significant drawbacks in practical applications. For critical content in mobile applications, such as the homepage and main navigation list, the timeliness of updates is crucial. However, the existing Facade caching uses a uniform asynchronous queue update logic without differentiating content importance, leading to unstable update times for important content, excessive update delays, and ultimately impacting user experience.

[0003] Secondly, existing cache update strategies mainly include: (1) Cache-Aside, Read-Through and other strategies mainly solve the consistency problem between cache and database, but do not design for differentiated refresh of important content and ordinary content; (2) The method of refreshing the cache by tag can achieve batch refresh of related resources, but it does not combine the relationship between navigation and column to achieve precise targeted refresh, and it is not compatible with the Varlish+facade cache architecture. (3) The asynchronous update scheme based on message queue focuses on the coordination of data writing and cache loading, and does not design a dedicated optimization scheme for the timeliness requirements of important content.

[0004] In summary, there is an urgent need for a technical solution that can adapt to the existing Varlish+facade caching architecture and enable fast refresh of important content, in order to address the shortcomings of existing technologies. Summary of the Invention

[0005] The purpose of this invention is to provide a method, system, and storage medium for fast refresh of application cache for important content, in order to solve the above-mentioned problems.

[0006] This invention is mainly achieved through the following technical solutions: A method for quickly refreshing application cache for important content includes the following steps: Step S1: Collect all URIs associated with the navigation ID of the fast refresh interface corresponding to important content, and store them in Redis after preprocessing; Step S2: Asynchronously receive content update notifications from the publishing system, the content update notifications including article_id and catalog Id; then, synchronously update the content details cache based on article_id; Step S3: Based on the many-to-many relationship between catalog ID and navigate ID, query all associated navigate IDs; then, based on the navigate ID, retrieve the corresponding URI set from Redis, and thus determine the request that needs to be refreshed and the fast refresh interface; Step S4: Send the refresh requests and fast refresh interfaces identified in Step S3 to the independent fast refresh queue of the facade cache management middleware, and perform the cache refresh operation asynchronously. Finally, the Varlish cache server obtains the updated content and completes the fast refresh of important content.

[0007] To better implement the present invention, in step S1, all URIs are hashed to remove duplicates and filtered for null values ​​to obtain a set of URIs; then, the set of URIs is stored in Redis with the navigate ID as the key and the set of URIs as the value.

[0008] To better implement the present invention, in step S1, the fast refresh interface corresponding to the important content includes the homepage interface and the interface corresponding to the main navigation list, and the cache refresh timeliness requirement of the interface is ≤10 seconds.

[0009] To better implement the present invention, in step S2, a message queue subscription method is used to asynchronously receive content update notifications from the publishing system. The message structure of the content update notification includes three core fields: article_id, catalog Id, and update timestamp.

[0010] To better implement the present invention, in step S3, a database association table is used to store the many-to-many association relationship between catalog ID and navigation ID. When querying the associated navigation ID through catalog ID, a join table query logic is used to obtain all associated navigation IDs.

[0011] This invention is mainly achieved through the following technical solutions: A fast refresh system for application cache targeting important content includes a URI pre-storage module, a notification receiving module, a details cache update module, a navigation positioning module, a refresh request positioning module, and a fast refresh triggering module; The URI pre-storage module is used to obtain all URIs associated with the navigate ID corresponding to the fast refresh interface and store them in Redis; The output of the notification receiving module is connected to the details cache update module and the navigation positioning module respectively, and is used to send the asynchronously received and parsed article_id and catalog Id to the details cache update module and the navigation positioning module respectively; The details cache update module is used to update the details cache of the corresponding content based on the article_id and by calling the Varlish cache server; The navigation and positioning module is used to query all associated navigation IDs pre-stored in Redis based on the catalog ID and pass them to the refresh request positioning module; The refresh request location module is used to retrieve the set of associated URIs from Redis based on all associated navigate IDs, determine the list of requests and interfaces that need to be refreshed, and pass it to the fast refresh trigger module. The fast refresh trigger module is used to send the determined refresh request and interface information to the independent fast refresh queue of the facade cache management middleware and execute the cache refresh operation asynchronously.

[0012] To better implement the present invention, the facade cache management middleware further adopts a dual-queue design, including a fast refresh queue and a normal cache update queue. The fast refresh queue has a higher priority than the normal cache update queue to ensure that refresh requests for important content are executed first.

[0013] A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the above-described method for fast refresh of application cache for important content.

[0014] The beneficial effects of this invention are as follows: (1) This invention implements differentiated cache refresh for important content based on the Varlish+facade caching architecture. It adds a fast cache channel for important content on top of the existing caching architecture, enabling asynchronous refresh of important and ordinary content. This solves the technical pain points of insufficient timeliness and excessive latency of important content caused by the existing unified queue update. This design differs from the existing undifferentiated cache update strategy. This invention achieves accurate and fast refresh of important content, improving the user experience of mobile applications. Practical application verification shows that this invention can reduce the cache refresh latency of important content from the original 30-60 seconds to 5-10 seconds, improving refresh timeliness by more than 60%, cache update stability by 80%, and reducing the lag rate of mobile application users loading important content by 70%, significantly improving the user experience.

[0015] (2) This invention avoids the delay of real-time traversal and querying of associated URIs during updates, which is present in existing solutions, by pre-storing the URIs associated with the navigation ID to Redis. This enables rapid location of important content updates and significantly improves update efficiency. Specifically, at the interfaces of mobile applications that require rapid updates, this invention collects all URIs associated with the navigation ID, performs hash deduplication and null value filtering, and stores them in Redis in the form of "navigation ID as key and URI set as value". Pre-storing avoids the delay of real-time querying during updates.

[0016] (3) This invention utilizes the many-to-many relationship between catalog ID and navigation ID to achieve precise linkage between "column update → associated navigation → associated interface", avoiding resource waste caused by missed refreshes, accidental refreshes, and excessive refresh range, and improving the accuracy of cache refresh. Specifically, this invention utilizes the many-to-many relationship between the publishing system catalog ID and the mobile application navigation ID, reverse queries the associated navigation ID through catalog ID, and then combines it with the URI set pre-stored in Redis to accurately locate the requests and interfaces that need to be refreshed.

[0017] (4) This invention uses a facade independent fast refresh queue to ensure that refresh requests for important content are executed first, while being compatible with existing caching architectures. It does not require large-scale modification of the original caching logic and can be quickly implemented. Specifically, a dual-queue collaborative refresh mechanism is set up under the facade caching architecture, and a new independent fast refresh queue is added. Its priority is higher than the existing ordinary cache update queue, and it is specially used to handle cache refresh requests for important content. This ensures that important content is refreshed first, is compatible with existing caching architectures, and does not require large-scale modification of the original logic, thus having strong practicality.

[0018] (5) Based on the definition criteria for protecting important content and the corresponding refresh time control, this invention clarifies that the interfaces that need to be refreshed quickly are the interfaces corresponding to the homepage and the main navigation list, limits their navigation ID range and refresh time requirement of ≤10 seconds, which is different from the time requirement of ≤60 seconds for ordinary interfaces, thus improving the accuracy of processing. Attached Figure Description

[0019] Figure 1 This is a flowchart of the application cache fast refresh method for important content according to the present invention; Figure 2 This is a schematic diagram of the structure of the application cache fast refresh system for important content according to the present invention. Detailed Implementation

[0020] Example 1: A fast refresh method for application cache targeting important content, such as Figure 1 As shown, it mainly includes four core stages: Step S1: Important Content URI Pre-storage Stage: Collect all URIs associated with the navigation ID corresponding to the fast refresh interface in advance. After hash deduplication and null value filtering, store them in Redis with the navigation ID as the key and the URI set as the value to provide data support for subsequent fast location. Specifically, for interfaces in mobile applications that require rapid refresh, all URIs associated with the corresponding navigation ID are collected. The collected URIs are deduplicated and filtered for null values. The processed URIs are then stored in Redis, where the navigation ID is used as the key and the associated set of URIs is used as the value.

[0021] Preferably, the interfaces that need to be refreshed quickly are the interfaces corresponding to important content of the mobile application, defined as the homepage interface and the interface corresponding to the main navigation list. The corresponding navigation ID range is a preset fixed range, and the cache refresh timeliness requirement for this type of interface is ≤10 seconds, while the cache refresh timeliness requirement for ordinary interfaces is ≤60 seconds.

[0022] The URI deduplication process uses a hash-based method. The criteria for filtering null values ​​are: when the URI is an empty string, null, or contains only spaces, it is considered a null value and filtered.

[0023] Step S2: Update Trigger Phase: Asynchronously receive content update notifications (including article_id and catalog Id) sent by the publishing system, and complete the synchronous update of the content details cache based on article_id; Specifically, the system asynchronously receives content update notifications from the publishing system. These notifications contain the article ID (article_id) and corresponding catalog ID (catalog ID) of the updated content. Based on the article_id in the content update notification, the details cache of the corresponding content in the mobile application is updated.

[0024] Preferably, the content update notifications of the publishing system are received asynchronously using a message queue subscription method. The message structure of the content update notification includes three core fields: article_id, catalog Id, and update timestamp.

[0025] Step S3: Precise Positioning Stage: Through the many-to-many relationship between catalog ID and navigation ID, query all associated navigation IDs, then retrieve the corresponding URI set from Redis based on the navigation ID, and finally determine the request and interface that needs to be refreshed; Specifically, navigation ID positioning: Based on the many-to-many association between the catalog ID of the publishing system and the navigation ID of the mobile application, all associated navigation IDs are obtained by querying the catalog ID in the content update notification.

[0026] Refresh request location: Based on the navigate ID obtained from the query, retrieve the corresponding URI set from Redis to determine the refresh request and the corresponding interface for the column.

[0027] Preferably, the many-to-many relationship between catalog ID and navigate ID is stored in a database join table. When querying the associated navigate ID through catalog ID, a join table query logic is used to quickly obtain all associated navigate IDs.

[0028] Step S4: Fast refresh execution phase: The determined refresh request and interface information are sent to the facade's independent fast refresh queue. This high-priority queue asynchronously executes the cache refresh operation, and finally the Varlish cache server obtains the updated content, completing the fast refresh of important content.

[0029] Specifically, the determined refresh request and interface information are sent to the facade's independent fast refresh queue, and the cache refresh operation is executed asynchronously through this independent queue to achieve fast refresh of important content.

[0030] Preferably, the facade's independent fast refresh queue has a higher priority than the existing ordinary cache update queue, ensuring that refresh requests for important content are executed first and avoiding conflicts with ordinary content refreshes.

[0031] This invention adds a fast channel for caching important content on the basis of the existing caching architecture, realizing the asynchronous refresh of important content and ordinary content, which solves the technical pain point of insufficient timeliness of important content caused by the existing unified queue update. This design is different from the existing undifferentiated cache update strategy.

[0032] Example 2: A fast refresh system for application caching of important content, applicable to mobile applications using a Varlish+facade caching architecture, such as... Figure 2 As shown, the system mainly consists of a URI pre-storage module, a notification receiving module, a details cache update module, a navigation positioning module, a refresh request positioning module, and a fast refresh triggering module. It seamlessly integrates with existing publishing systems, facade cache management middleware, Varlish cache servers, and mobile application interfaces, without requiring large-scale modifications to the original system. Details are as follows: Mobile application (APP): The homepage and main navigation list interfaces provide all request URIs associated with the navigation ID to the URI pre-storage module of this system; at the same time, when APP users request cached content, they directly obtain data from the Varlish cache server.

[0033] URI Pre-store Module: Collects all URIs associated with the navigation ID from the important content interfaces of the mobile application in advance. After hash deduplication and null value filtering, it stores them in Redis in the format of navigation ID as key and URI set as value, providing pre-stored data support for subsequent fast location of refresh requests.

[0034] Publishing System: The content publishing module generates content update events and asynchronously pushes content update notifications containing article_id (article ID) and catalog ID (category ID) to the notification receiving module of this system.

[0035] Notification receiving module: As the entry point of this system, it asynchronously receives content update notifications pushed by the publishing system, parses out the article_id and catalog Id, forwards the article_id to the details cache update module, and forwards the catalog Id to the navigation and positioning module.

[0036] Details cache update module: After receiving article_id, it directly calls the Varlish cache server to update the details cache of the corresponding content, ensuring the real-time availability of content details.

[0037] Navigation and positioning module: After receiving the catalog ID, it queries the many-to-many association mapping relationship between the catalog ID and the navigation ID stored in Redis, obtains all associated navigation IDs, and passes them to the refresh request positioning module.

[0038] Refresh Request Location Module: After receiving the associated navigate ID, it retrieves the set of all URIs associated with the corresponding navigate ID from Redis, and combines it with the mapping rules of important content interfaces to accurately determine the list of requests and interfaces that need to be refreshed, and then passes it to the fast refresh trigger module.

[0039] Fast refresh trigger module: Sends the determined refresh request and interface information to the independent fast refresh queue of the facade cache management middleware.

[0040] Existing caching architectures include: The facade cache management middleware adopts a dual-queue design. The fast refresh queue has a higher priority than the normal cache update queue and is dedicated to handling cache refresh requests for important content. The normal cache update queue retains its original logic and handles cache updates for non-important content. The Varlish caching server receives refresh commands from two queues, updates cached content, and provides cached data services to mobile applications.

[0041] This invention adds an independent fast refresh link for important content cache based on the existing Varlish+facade caching architecture. Through the collaborative design of pre-stored URI mapping, many-to-many association positioning, and high-priority independent queues, it achieves differentiated, accurate, and fast cache refresh for important content and ordinary content, solving the problem of insufficient timeliness of important content caused by the original unified queue update.

[0042] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Any simple modifications or equivalent changes made to the above embodiments based on the technical essence of the present invention shall fall within the protection scope of the present invention.

Claims

1. A method for fast refresh of application cache for important content, characterized in that, Includes the following steps: Step S1: Collect all URIs associated with the navigation ID of the fast refresh interface corresponding to important content, and store them in Redis after preprocessing; Step S2: Asynchronously receive content update notifications from the publishing system, wherein the content update notifications include article_id and catalog Id; Then, the content details cache is updated synchronously based on article_id; Step S3: Based on the many-to-many relationship between catalog ID and navigate ID, query all associated navigate IDs; then, based on the navigate ID, retrieve the corresponding URI set from Redis, and thus determine the request that needs to be refreshed and the fast refresh interface; Step S4: Send the refresh requests and fast refresh interfaces identified in Step S3 to the independent fast refresh queue of the facade cache management middleware, and perform the cache refresh operation asynchronously. Finally, the Varlish cache server obtains the updated content and completes the fast refresh of important content.

2. The method for fast refresh of application cache for important content according to claim 1, characterized in that, In step S1, all URIs are hashed to remove duplicates and filtered for null values ​​to obtain a set of URIs; then, the URI set is stored in Redis with the navigate ID as the key and the set of URIs as the value.

3. A method for fast refresh of application cache for important content according to claim 1 or 2, characterized in that, In step S1, the fast refresh interface corresponding to the important content includes the homepage interface and the interface corresponding to the main navigation list, and the cache refresh timeliness requirement of the interface is ≤10 seconds.

4. The method for fast refresh of application cache for important content according to claim 1, characterized in that, In step S2, the content update notification from the publishing system is received asynchronously using a message queue subscription method. The message structure of the content update notification includes three core fields: article_id, catalog Id, and update timestamp.

5. The method for fast refresh of application cache for important content according to claim 1, characterized in that, In step S3, a database association table is used to store the many-to-many association between catalog ID and navigate ID. When querying the associated navigate ID through catalog ID, the join table query logic is used to obtain all associated navigate IDs.

6. A fast refresh system for application cache targeting important content, characterized in that, It includes a URI pre-storage module, a notification receiving module, a details cache update module, a navigation positioning module, a refresh request positioning module, and a fast refresh trigger module; The URI pre-storage module is used to obtain all URIs associated with the navigate ID corresponding to the fast refresh interface and store them in Redis; The output of the notification receiving module is connected to the details cache update module and the navigation positioning module respectively, and is used to send the asynchronously received and parsed article_id and catalog Id to the details cache update module and the navigation positioning module respectively; The details cache update module is used to update the details cache of the corresponding content based on the article_id and by calling the Varlish cache server; The navigation and positioning module is used to query all associated navigation IDs pre-stored in Redis based on the catalog ID, and then pass them to the refresh request positioning module. The refresh request location module is used to retrieve the set of associated URIs from Redis based on all associated navigate IDs, determine the list of requests and interfaces that need to be refreshed, and pass it to the fast refresh trigger module. The fast refresh trigger module is used to send the determined refresh request and interface information to the independent fast refresh queue of the facade cache management middleware and execute the cache refresh operation asynchronously.

7. A fast refresh system for application cache targeting important content as described in claim 6, characterized in that, The facade cache management middleware adopts a dual-queue design, including a fast refresh queue and a normal cache update queue. The fast refresh queue has a higher priority than the normal cache update queue to ensure that refresh requests for important content are executed first.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the fast refresh method for application cache targeting important content as described in any one of claims 1-5.

Images