Distributed cache management method based on dynamic strategy engine

Abstract

The invention provides a distributed cache management method based on a dynamic strategy engine, and relates to the technical field of computer software, and the method comprises the steps: configuring a cache strategy for each tenant through an intelligent cache strategy configuration center, the cache strategy comprises a cache granularity, a cache updating opportunity, a cache life cycle, a cache replacement strategy, a cache updating mode and a cache medium; receiving a cache strategy configuration change through a cache strategy dynamic engine, and performing hot update of the cache strategy based on the tenant identifier; generating cache strategy recommendation based on system runtime indexes and a machine learning algorithm through an intelligent strategy recommendation system; caching strategy gray release is carried out through a multi-dimensional gray release manager based on the user ID range, the regional distribution, the equipment type, the access time and the multi-dimensional configuration of the service module; and the final consistency of the cache and the database is realized based on the message queue through the cache consistency guarantee module.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computer software, and particularly relates to a distributed cache management method based on a dynamic strategy engine. BACKGROUND

[0002] In enterprise-level software systems, especially business platforms such as ERP and CRM with a multi-tenant architecture, cache technology is widely used to improve system performance and response speed. Traditional cache solutions usually use static configuration methods, hard-coding cache logic in business code or setting it once through a configuration file. Such solutions have obvious limitations in actual application: on the one hand, once the cache strategy is set, it is difficult to dynamically adjust it according to system load changes, business scenario evolution or tenant individual needs; on the other hand, the cache logic is highly coupled with the business code, resulting in the need for re-development, testing and deployment for strategy changes, which is high in operation and maintenance cost and long in cycle. In addition, in a multi-tenant environment, the data characteristics, access patterns and performance requirements of different tenants are significantly different, but existing technologies lack the ability to isolate and customize cache strategies for tenants, which can easily cause cache pollution, resource contention and even data leakage risks. Although some systems have introduced basic cache configuration functions, they still cannot achieve key capabilities such as hot update, intelligent recommendation, gray verification and consistency guarantee of the strategy, which seriously restricts the performance optimization efficiency and stability of the system in complex business scenarios. SUMMARY

[0003] The application provides a distributed cache management method based on a dynamic strategy engine to solve one of the above technical problems.

[0004] The technical solution adopted by the application is as follows: The application embodiment provides a distributed cache management method based on a dynamic strategy engine, which comprises: An intelligent cache strategy configuration center configures cache strategies for each tenant, and the cache strategies include cache granularity, cache update timing, cache life cycle, cache replacement strategy, cache update method and cache medium; A cache strategy dynamic engine receives cache strategy configuration changes and performs hot update of the cache strategy based on a tenant identifier; An intelligent strategy recommendation system generates cache strategy recommendations based on system runtime indicators and machine learning algorithms; A multi-dimensional gray release manager performs gray release of the cache strategy based on multi-dimensional configurations of user ID range, geographical distribution, device type, access time and business module; A cache consistency guarantee module implements the eventual consistency of cache and database based on a message queue.

[0005] According to an embodiment of the present application, the cache strategy configuration includes: cache granularity is full table or partial field, cache update timing is synchronous, asynchronous or delayed, cache lifetime is with server or fixed duration, cache replacement strategy is LRU, FIFO or custom, cache update mode is incremental or full, and cache medium is application memory, Redis or distributed cache. According to an embodiment of the present application, the hot update of the cache strategy includes: real-time pushing of cache strategy configuration changes through WebSocket, automatic refreshing of cache strategy configuration by the application node after receiving the changes, adoption of a version control mechanism to ensure atomicity and consistency of the configuration changes, and provision of a configuration version rollback function.

[0006] According to an embodiment of the present application, the system runtime indicators include cache hit rate, database QPS, response time, CPU usage and memory usage, and the machine learning algorithm is an integrated algorithm of random forest and gradient boosting tree.

[0007] According to an embodiment of the present application, the dimensions supported by the multi-dimensional gray release manager include user ID range, geographical distribution, device type, access time and business module, the gray scale is 10%, 20%, 50% or 100%, and the gray release time window is a specified time period.

[0008] According to an embodiment of the present application, the cache consistency guarantee module includes: sending a message to a message queue after successful database update, consuming the message by a cache update service to perform cache update, ensuring transaction consistency across services by using a SAGA mode, and providing a cache rollback mechanism.

[0009] According to an embodiment of the present application, the cache strategy recommendation system provides an A / B testing function, allows two strategies to run simultaneously, compares indicators such as cache hit rate, response time and resource consumption, and displays the strategy effect comparison through a visual interface. The cache strategy configuration center provides a configuration inheritance mechanism for tenants, allowing tenants to inherit basic configurations and make individual adjustments.

[0010] According to an embodiment of the present application, the cache strategy dynamic engine is designed based on a cache proxy layer, and a business method declares a cache strategy through a custom annotation, and the cache proxy layer determines a cache processing mode according to the configured cache strategy.

[0011] The second aspect embodiment of the present application provides a computer readable storage medium having a program stored thereon, and the program is executed by a processor to implement the steps in the method.

[0012] The third aspect of the application provides an electronic device, comprising a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor implements the steps in the method when executing the program.

[0013] As the above technical solutions are adopted, the application has the following beneficial effects: The application configures the cache strategy for each tenant through the intelligent cache strategy configuration center, realizes tenant-level strategy isolation and individual customization, effectively avoids cache pollution and resource contention, and meets differentiated performance requirements in a multi-tenant environment. The cache strategy dynamic engine receives cache strategy configuration changes and performs hot update of the cache strategy based on the tenant identifier, so that the cache strategy can take effect in real time without interrupting service and restarting the application, greatly shortening the strategy adjustment period from several days to minutes. The intelligent strategy recommendation system generates cache strategy recommendations based on system runtime indicators and machine learning algorithms, eliminating the dependence on manual experience, realizing scientific and automated optimization of the cache strategy, and significantly improving the cache hit rate and overall system performance. The multi-dimensional gray release manager performs cache strategy gray release based on multi-dimensional configurations of user ID range, geographical distribution, device type, access time, and business module, supports safe and gradual online of the cache strategy, verifies the strategy effect in a real business environment, and reduces system risks caused by strategy changes. The cache consistency guarantee module realizes the eventual consistency of the cache and the database based on the message queue, effectively solves the inconsistency between the cache and the database data while ensuring high concurrency performance, and improves the reliability and business continuity of system data. BRIEF DESCRIPTION OF DRAWINGS

[0014] The accompanying drawings described herein are used to provide further understanding of the application, form a part of the application, and the illustrative embodiments of the application and their descriptions are used to explain the application, and do not constitute an improper limitation on the application. In the drawings: Figure 1 A flowchart of a distributed cache management method based on a dynamic strategy engine is provided for the embodiments of the application. Figure 2 A structural diagram of an electronic device is provided for the embodiments of the application.

[0015] Reference signs: 810, processor; 820, communication interface; 830, memory; 840, communication bus. DETAILED DESCRIPTION

[0016] In order to make the overall concept of the present application clearer, the following will be described in detail with reference to the accompanying drawings.

[0017] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. However, the present application can be practiced without the specific details. In other instances, well-known methods have not been described in detail in order not to unnecessarily obscure aspects of the present application. It is to be understood that this application is not limited to particular

[0018] In the present application, unless specifically stated and limited otherwise, the first feature is "on" or "under" the second feature can be that the first and second features are in direct contact, or the first and second features are indirectly in contact through an intermediate medium. In the description of the present application, the description referring to the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples.

[0019] Embodiment 1 As shown in the figure, a distributed cache management method based on a dynamic policy engine includes: Figure 1 A cache policy is configured for each tenant through an intelligent cache policy configuration center, and the cache policy includes cache granularity, cache update timing, cache life cycle, cache replacement policy, cache update mode, and cache medium.

[0020] ​As described above, the cache strategy is configured for each tenant by the intelligent cache strategy configuration center, and the cache strategy includes the cache granularity, the cache update timing, the cache life cycle, the cache replacement strategy, the cache update mode and the cache medium. Specifically, a centralized and visual configuration management platform is constructed in the system, which faces the multi-tenant architecture and allows each tenant to independently define the cache behavior rules suitable for its business scenario. Among them, the cache granularity is used to specify the data range of the cache, for example, the whole business table can be selected for full table caching, or only the high-frequency access key field can be cached, so as to balance the memory occupation and query efficiency; the cache update timing is used to control the trigger mode of the synchronization of the cache data and the source data, including immediate synchronization update (synchronization) when the database changes, delayed update through asynchronous task (asynchronous), or preferentially writing to the cache and then asynchronously persisting to the database (delayed), to adapt to the trade-off demand of consistency and performance of different businesses; the cache life cycle is used to set the effective duration of the cache data, which can be selected to be always valid (with the server) during system operation, or only to be retained for a fixed time (such as 300 seconds) after the first access, suitable for temporary high-frequency query scenarios; the cache replacement strategy is used to decide which cache items to eliminate when the memory resources are limited, supporting classic algorithms such as least recently used (LRU) and first in first out (FIFO), and custom elimination logic can also be defined according to business characteristics; the cache update mode is used to define how to refresh the cache content after data changes, which can be selected to update only the change record (incremental update) to reduce overhead, or reload the whole table data (full update) after each change to simplify the logic; the cache medium is used to specify the physical storage location of the cache data, including the application process internal memory (local cache), external high-performance memory database (such as Redis) or distributed cache cluster, to meet different size and performance requirements. For example, in a multi-tenant ERP system for manufacturing enterprises, tenant A may configure the cache granularity of the "order table" as "order number, customer name, status" three fields, the cache update timing as "synchronization", the cache life cycle as "with server", the cache replacement strategy as "LRU", the cache update mode as "incremental update", and the cache medium as "Redis"; while tenant B may select "full table cache", "asynchronous update", "fixed time 300 seconds", "FIFO replacement", "full update" and "local memory" for the same table to adapt to its batch-intensive business characteristics.Within the overall protection scope of the present application, the configuration mechanism can be further extended as follows: support policy templates based on business module or data table classification, allow tenants to inherit and fine-tune the templates; support version management and rollback of cache policies; support hierarchical control of policy configuration permissions, such as setting default policies by system administrators, and tenants only adjusting part of the parameters; support linkage of policy configuration and tenant service level agreement (SLA), high-priority tenants can be allocated higher cache resource quotas; and initial policy configuration can also be automatically recommended based on the historical access behavior of the tenant, thereby reducing the configuration threshold while ensuring flexibility.

[0021] The cache policy configuration changes are received by the cache policy dynamic engine, and the cache policy is hot-updated based on the tenant identifier.

[0022] As mentioned above, the technical step of "receiving cache policy configuration changes by the cache policy dynamic engine, and hot-updating the cache policy based on the tenant identifier" specifically refers to responding to the adjustment of the cache policy in real time without restarting the application service or interrupting the business request during system operation, and ensuring that the policy change precisely affects the corresponding tenant environment. The cache policy dynamic engine, as the core runtime component of the system, continuously monitors policy change events from the intelligent cache policy configuration center. Once it detects that the cache policy of any tenant has been modified (such as adjusting the cache lifetime, replacing the cache medium, or switching the update method), the engine immediately parses the change content and binds the new policy to the cache context or data access path corresponding to the tenant based on the tenant identifier (such as tenant ID or tenant unique code) carried in the change information, thereby realizing the instant effect of the policy. For example, when tenant C on a SaaS platform modifies the cache update method of its "customer information table" from "full update" to "incremental update" on the management interface, the configuration center pushes the change along with the identifier of tenant C to the cache policy dynamic engine. After the engine identifies the identity of tenant C, it only applies the new incremental update logic to the tenant's subsequent customer information query and update operations, while the cache behavior of other tenants is completely unaffected. The entire process is completed within milliseconds, and the user has no perception and the service is uninterrupted. Within the overall protection scope of the present application, the hot-updating mechanism can be further extended as follows: support atomic application of policy changes to ensure that the same tenant does not mix new and old policies during policy switching; support pre-verification mechanism before policy change to prevent illegal or conflicting configurations from being loaded; support batch policy hot-updating based on tenant grouping, such as pushing optimized cache templates to multiple tenants of the same industry type simultaneously; support state snapshot and rollback capability during hot-updating process, which can automatically or manually revert to the previous stable version when the new policy causes an exception; and the execution time of hot-updating can also be dynamically determined based on the runtime context (such as current load and active session number) to avoid introducing additional overhead during business peak periods.

[0023] The intelligent strategy recommendation system generates cache strategy recommendations based on system runtime indicators and machine learning algorithms.

[0024] As described above, the technical step of "the intelligent strategy recommendation system generates cache strategy recommendations based on system runtime indicators and machine learning algorithms" specifically refers to automatically collecting multi-dimensional runtime indicators closely related to cache performance during the continuous operation of the system, and using these indicators as input data to analyze and learn by the built-in machine learning model, thereby dynamically outputting cache strategy optimization recommendations for specific tenants or business scenarios, and realizing the transition from "manual experience-driven" to "data-intelligent-driven" cache management. The intelligent strategy recommendation system first collects real-time key runtime indicators including cache hit rate, database query per second request number (QPS), interface average response time, CPU and memory usage, cache read and write frequency, data change frequency, etc., and performs structured aggregation according to tenant, business module, data table, etc. dimensions; then, the system uses pre-trained machine learning algorithms (such as integrated learning models combining random forests and gradient boosting trees) to model the correlation between historical indicators and the effects of corresponding cache strategies, and identify the most effective cache parameter combination under different load characteristics and access patterns; finally, the system predicts the performance benefits that different cache strategies (such as adjusting cache granularity, switching update timing, or changing the life cycle) may bring based on the current running state, and generates one or more executable cache strategy recommendations. For example, when the order query interface of a tenant experiences a sharp drop in cache hit rate and a surge in database load during a promotion period, the intelligent strategy recommendation system analyzes its historical access patterns and finds that the tenant frequently queries orders within the last 24 hours, but the current cache strategy is "full table caching + fixed time period of 600 seconds", resulting in a large amount of cold data occupying memory; accordingly, the system recommends "cache only the last 24 hours of order data + cache life cycle of 300 seconds + LRU replacement strategy", and estimates that this strategy can increase cache hit rate by 25% and reduce database QPS by 30%. Within the overall scope of protection of the present invention, the recommendation mechanism can be further expanded to support confidence evaluation and risk warning of recommended strategies, such as marking high-risk strategies and suggesting gray verification first; support multi-objective optimization recommendations, such as considering response time, resource consumption, and consistency requirements simultaneously; support online strategy optimization based on reinforcement learning, the system continuously collects feedback and iteratively optimizes the recommendation model in A / B testing; support using business semantic information (such as whether it is a key transaction or involves sensitive information) as a recommendation constraint condition to ensure that the strategy meets compliance or business priority requirements; and can also combine tenant historical adoption behavior to build a personalized recommendation preference model to improve the acceptance rate and practicality of recommendations.

[0025] The multi-dimensional gray release manager releases the cache strategy grayly based on multi-dimensional configurations of user ID range, regional distribution, device type, access time and business module.

[0026] As described above, the technical step of “releasing the cache strategy grayly based on multi-dimensional configurations of user ID range, regional distribution, device type, access time and business module by the multi-dimensional gray release manager” specifically refers to, in the process of adjusting the cache strategy, in order to reduce the risk of system stability caused by strategy change, a fine and combinable gray control mechanism is introduced, so that the new cache strategy can be tested in a limited user group or business scenario first, and then gradually expand the application range after being verified to be effective, and finally realize full online. The multi-dimensional gray release manager allows operation and maintenance personnel or system automatic decision module to accurately circumscribe the target traffic based on the combination conditions of one or more dimensions, for example: users with user ID between 10000 and 20000, access requests located in East China, clients from iOS mobile devices, access initiated during working hours from 9:00 to 18:00, or only for the interface call of the “order management” business module. When the new cache strategy is configured, the system will not take effect for all requests immediately, but only apply the new strategy to the requests that meet the above gray conditions, and the rest of the requests will still follow the original strategy, thereby realizing controllable verification of the strategy effect in the real production environment. For example, an e-commerce platform plans to adjust the cache update mode of the product detail page from “synchronous update” to “asynchronous update” to improve the write performance, but is worried that it may cause temporary data inconsistency. At this time, the gray release manager can be configured to enable the new strategy only for users with user ID ending in “00”, using Android devices, accessing the “product detail” module during off-peak hours (22:00-6:00); the system continuously monitors indicators such as cache hit rate, page loading delay and user complaint rate within the gray range, and if the performance is stable within 72 hours, the gray ratio is gradually expanded from 1% to 5%, 20% and finally to 100%, realizing smooth transition. Within the overall protection scope of the present application, the gray release mechanism can be further expanded to support dynamic weight allocation of gray strategies, such as shunting according to traffic proportion instead of fixed user ID range; support real-time dynamic adjustment of gray conditions without the need for redeployment to modify the gray dimension combination; support automatic evaluation and decision of gray effect, automatically advancing or rolling back the gray stage when the monitored indicators reach the preset threshold; support reuse of gray strategies across tenants, such as quickly copying the strategy verified successfully by a high-value tenant to similar tenants and starting gray; and user behavior portraits (such as activity level, payment level) can also be used as gray dimensions to prioritize high-risk strategies in low-risk user groups.

[0027] The cache consistency guarantee module realizes the eventual consistency of the cache and the database based on the message queue.

[0028] As described above, the technical step of "ensuring the cache and database consistency based on the message queue by the cache consistency guarantee module" specifically refers to establishing a reliable, decoupled and traceable synchronization mechanism between the cache data and the database source data, to ensure that in a high-concurrency and distributed environment, even if there is a time difference between the cache and the database operation, the system can still achieve data state consistency within a reasonable time, thereby avoiding business logic errors caused by cache dirty reading or data lag. After the database completes the write operation (such as adding, modifying or deleting), the cache consistency guarantee module does not directly synchronize or delete the cache, but encapsulates the data change event as a structured message and publishes it to a highly available message queue; then, an independent cache update consumer service asynchronously listens to the message queue, consumes messages in order, and accurately executes the corresponding cache invalidation, update or reconstruction operation according to the message content. Since the message queue has the persistence, sequential delivery and retry mechanism, even in the case of temporary unavailability of the cache service or network jitter, the change message will not be lost, and the system can continue processing after the fault is recovered, thereby ensuring that the cache is ultimately consistent with the database. For example, when a tenant modifies the customer address information in the order system, the database transaction is successfully committed, and the system immediately sends an event message to the message queue that "the customer address of order ID 12345 has been updated". After the cache update service receives the message, it automatically locates the cache namespace corresponding to the tenant and deletes or refreshes the cache entries related to the order. During this period, if other requests read the order, they may temporarily read the old cache data, but since the message processing delay is usually in milliseconds to seconds, the business can accept this short window, and ultimately all subsequent requests can obtain the latest data, achieving "eventual consistency". Within the overall protection scope of the present application, the consistency mechanism can be further expanded to: support version number or timestamp verification of message content to prevent the cache from being overwritten by old data due to message out-of-order; support message routing based on tenant identification to ensure that the cache updates of each tenant in a multi-tenant environment do not interfere with each other; support alarm and manual intervention interface when cache update fails, and provide message replay capability; support a hybrid mode of local strong consistency and eventual consistency in key business scenarios by combining lightweight distributed locks or read-write markers; and further link the message queue with the transaction log (such as the database binlog) to automatically generate cache update events by listening to the log, further reducing the business code invasiveness.

[0029] According to an embodiment of the present application, the cache strategy configuration includes: cache granularity is full table or partial field, cache update timing is synchronous, asynchronous or delayed, cache lifetime is server-dependent or fixed duration, cache replacement strategy is LRU, FIFO or custom, cache update mode is incremental or full, and cache medium is application memory, Redis or distributed cache. As described above, the cache strategy configuration includes specific settings of the following parameters: cache granularity is used to specify the range of cached data, and the whole table can be selected for full table caching, or only part of the fields in the table can be cached to adapt to the trade-off between data integrity and memory occupation in different query scenarios; cache update timing is used to control the triggering mode of synchronizing cache data with database source data, including the synchronization mode of updating cache immediately after database write operation is completed, the asynchronous mode of updating in the background through asynchronous tasks, and the delay mode of updating cache first and then writing to database asynchronously; cache lifetime is used to define the effective duration of cache data, which can be configured to be valid during the server running period, or only for a fixed period after the first access; cache replacement strategy is used to decide which cache items to eliminate when the cache space reaches the upper limit, supporting standard strategies such as least recently used (LRU) and first in first out (FIFO), and allowing custom replacement logic according to business needs; cache update mode is used to determine how to refresh cache content after data changes, which can choose incremental update mode of updating only the changed data records, or full update mode of reloading the whole table data after each change; cache medium is used to specify the physical storage location of cache data, which can be stored in the local memory of the application process, or use external Redis memory database, or be deployed in a distributed cache cluster to meet different performance, capacity and high availability requirements.

[0030] According to an embodiment of the present application, the hot update of the cache strategy includes: pushing the cache strategy configuration changes in real time through WebSocket, and the application nodes automatically refresh the cache strategy configuration after receiving the changes, using version control mechanism to ensure the atomicity and consistency of configuration changes, and providing configuration version rollback function.

[0031] As described above, the hot update of the cache strategy includes: when the cache strategy configuration changes, the system pushes the changes to all related application nodes in real time through WebSocket connection; each application node can automatically load and apply the new cache strategy configuration without restarting the service after receiving the pushed configuration changes, so that the strategy takes effect immediately; during the pushing and applying process, the system uses version control mechanism to uniquely identify and manage the state of each configuration change, ensuring that multiple nodes use the same version of configuration during the update process, thereby guaranteeing the atomicity and consistency of configuration changes; at the same time, the system retains historical configuration versions and provides configuration version rollback function, which can quickly switch back to any historical stable version when the new strategy causes exceptions or performance degradation, and restore the original cache behavior.

[0032] According to one embodiment of the present application, the system runtime indicators include cache hit rate, database QPS, response time, CPU usage and memory usage, and the machine learning algorithm is an integrated algorithm of random forest and gradient boosting tree.

[0033] As described above, the system runtime indicators include cache hit rate, database queries per second (QPS), response time of interfaces or services, central processing unit (CPU) usage and memory usage, which are used to reflect the performance and resource consumption of the system under different cache strategies in real time; the machine learning algorithm adopts an integrated algorithm combining random forest and gradient boosting tree, which improves the accuracy and robustness of cache strategy recommendation by fusing the prediction results of multiple decision tree models, and can effectively identify the nonlinear relationship between runtime indicators and cache strategy effects, thereby generating a more optimal cache strategy suggestion.

[0034] According to one embodiment of the present application, the dimensions supported by the multi-dimensional gray release manager include user ID range, geographical distribution, device type, access time and business module, the gray scale is 10%, 20%, 50% or 100%, and the gray release time window is a specified time period.

[0035] As described above, the dimensions supported by the multi-dimensional gray release manager include user ID range, geographical distribution, device type, access time and business module, which are used to accurately limit the applicable objects of cache strategy gray release; wherein, the user ID range refers to filtering target users according to the numerical interval of user identification, the geographical distribution refers to dividing according to the geographical location of user request sources, the device type refers to distinguishing Web, mobile or other terminal types, the access time refers to limiting the daily or weekly time period of strategy taking effect, and the business module refers to applying the strategy to specific function modules (such as order, inventory, customer management) in the system; the gray scale is 10%, 20%, 50% or 100%, which means that in the traffic meeting the gray dimension conditions, the new cache strategy is gradually applied according to the specified percentage; the gray release time window is a specified time period, which is used to control the gray strategy to take effect only within the preset start and end time range, avoiding introducing strategy change risk during business peak period or unexpected time period.

[0036] According to one embodiment of the present application, the cache consistency guarantee module includes: sending a message to a message queue after the database is successfully updated, consuming the message by the cache update service to execute cache update, using SAGA mode to ensure transaction consistency across services, and providing a cache rollback mechanism.

[0037] As described above, the cache consistency guarantee module includes: after the database completes the write operation and successfully commits the transaction, the system encapsulates the data change event into a message and sends it to the message queue; the cache update service, as an independent consumer, pulls the message from the message queue and performs corresponding cache invalidation, update, or reconstruction operations according to the message content; to ensure transaction consistency across database services and cache services in a distributed environment, the system adopts the SAGA pattern to coordinate the entire update process, splitting the cache update into multiple compensable sub-steps, and triggering corresponding compensation operations when any step fails; at the same time, the module provides a cache rollback mechanism, which can restore the cache to the state before the change when database rollback, message processing anomalies, or policy verification failures are detected, thereby ensuring that the cache and the database can still maintain data logic consistency in abnormal scenarios.

[0038] According to one embodiment of this application, the caching strategy recommendation system provides an A / B testing function, which allows two strategies to be run simultaneously to compare indicators such as cache hit rate, response time and resource consumption, and displays the comparison of strategy effects through a visual interface; The caching policy configuration center provides a configuration inheritance mechanism for tenants, allowing them to inherit basic configurations and make personalized adjustments.

[0039] As described above, the caching strategy recommendation system provides A / B testing functionality, allowing two different caching strategies to run simultaneously in the same business scenario. One part requests strategy A, and the other part requests strategy B. During operation, the system continuously collects and compares the performance differences of the two strategies in key performance indicators such as cache hit rate, interface response time, and CPU and memory resource consumption. The system then uses a visualization interface to intuitively display the strategy effect comparison results in the form of charts or reports, assisting operations and maintenance personnel or the system's automatic decision-making module in selecting the better strategy.

[0040] The cache policy configuration center provides a configuration inheritance mechanism for tenants, allowing each tenant to inherit from the system's preset global basic cache policy template. Based on this inherited configuration, tenants can make personalized adjustments to parameters such as cache granularity, update timing, lifecycle, replacement policy, update method, or cache medium. This mechanism ensures the standardization and manageability of the overall system policy while meeting the differentiated requirements of different tenants in terms of business characteristics, data scale, and performance needs, avoiding the repetitive work of configuring policies from scratch for each tenant.

[0041] According to one embodiment of this application, the dynamic caching strategy engine is designed based on a caching proxy layer. The business method declares the caching strategy through custom annotations, and the caching proxy layer determines the caching processing method according to the configured caching strategy.

[0042] As described above, the dynamic caching strategy engine is designed based on a cache proxy layer. This cache proxy layer acts as an intermediary between business logic and caching operations, intercepting requests and handling cache-related logic before and after the execution of business methods. Business methods explicitly specify their associated cache strategy identifiers or strategy parameters by adding custom annotations in their method declarations. When a business method is called, the cache proxy layer first parses the annotation and retrieves the latest corresponding cache strategy configuration from the dynamic caching strategy engine based on the current tenant context. Subsequently, the cache proxy layer dynamically determines whether to read from the cache, how to write to the cache, what update mechanism to use, and what cache medium to use based on the configuration, and then returns control to the business method or returns the result after completing the caching operation. Through this mechanism, the caching logic and business code are completely decoupled, and the caching behavior can be adjusted in real time with hot updates of the strategy configuration without modifying or recompiling the business code.

[0043] A second aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in any of the embodiments of the first aspect above.

[0044] Figure 2 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 2 As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 may call logical instructions in the memory 830 to execute the method in any of the embodiments of the first aspect described above, the method including: The intelligent caching strategy configuration center configures caching strategies for each tenant. The caching strategies include cache granularity, cache update timing, cache lifecycle, cache replacement strategy, cache update method, and cache medium. The cache policy dynamic engine receives cache policy configuration changes and performs hot updates of the cache policy based on the tenant identifier. The intelligent strategy recommendation system generates caching strategy recommendations based on system runtime metrics and machine learning algorithms. The multi-dimensional canary release manager enables canary release of caching strategies based on multi-dimensional configurations of user ID range, geographic distribution, device type, access time, and business module. The cache consistency guarantee module achieves eventual consistency between the cache and the database based on message queues.

[0045] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0046] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program, the computer program being able to be stored on a non-transitory computer-readable storage medium, and when the computer program is executed by a processor, the computer being able to perform the methods provided by the above methods, the method comprising: The intelligent caching strategy configuration center configures caching strategies for each tenant. The caching strategies include cache granularity, cache update timing, cache lifecycle, cache replacement strategy, cache update method, and cache medium. The cache policy dynamic engine receives cache policy configuration changes and performs hot updates of the cache policy based on the tenant identifier. The intelligent strategy recommendation system generates caching strategy recommendations based on system runtime metrics and machine learning algorithms. The multi-dimensional canary release manager enables canary release of caching strategies based on multi-dimensional configurations of user ID range, geographic distribution, device type, access time, and business module. The cache consistency guarantee module achieves eventual consistency between the cache and the database based on message queues.

[0047] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the methods provided by the above methods, the method comprising: The intelligent caching strategy configuration center configures caching strategies for each tenant. The caching strategies include cache granularity, cache update timing, cache lifecycle, cache replacement strategy, cache update method, and cache medium. The cache policy dynamic engine receives cache policy configuration changes and performs hot updates of the cache policy based on the tenant identifier. The intelligent strategy recommendation system generates caching strategy recommendations based on system runtime metrics and machine learning algorithms. The multi-dimensional canary release manager enables canary release of caching strategies based on multi-dimensional configurations of user ID range, geographic distribution, device type, access time, and business module. The cache consistency guarantee module achieves eventual consistency between the cache and the database based on message queues.

[0048] For any parts not mentioned in this application, existing technologies may be used or referenced.

[0049] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0050] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A distributed cache management method based on a dynamic policy engine, characterized in that, include: The intelligent caching strategy configuration center configures caching strategies for each tenant. The caching strategies include cache granularity, cache update timing, cache lifecycle, cache replacement strategy, cache update method, and cache medium. The cache policy dynamic engine receives cache policy configuration changes and performs hot updates of the cache policy based on the tenant identifier. The intelligent strategy recommendation system generates caching strategy recommendations based on system runtime metrics and machine learning algorithms. The multi-dimensional canary release manager enables canary release of caching strategies based on multi-dimensional configurations of user ID range, geographic distribution, device type, access time, and business module. The cache consistency guarantee module achieves eventual consistency between the cache and the database based on message queues.

2. The method according to claim 1, characterized in that, The caching strategy configuration includes: caching granularity of the entire table or partial fields, cache update timing of synchronous, asynchronous or delayed, cache lifecycle of accompanying the server or fixed duration, cache replacement strategy of LRU, FIFO or custom, cache update method of incremental or full, and cache medium of application memory, Redis or distributed cache.

3. The method according to claim 1, characterized in that, The hot update of the caching strategy includes: pushing caching strategy configuration changes in real time via WebSocket; automatically refreshing the caching strategy configuration after the application node receives the changes; using a version control mechanism to ensure the atomicity and consistency of configuration changes; and providing a configuration version rollback function.

4. The method according to claim 1, characterized in that, The system runtime metrics include cache hit rate, database QPS, response time, CPU utilization, and memory utilization. The machine learning algorithm is an ensemble of random forest and gradient boosting tree.

5. The method according to claim 1, characterized in that, The multi-dimensional grayscale release manager supports dimensions including user ID range, geographic distribution, device type, access time, and business module. The grayscale ratio is 10%, 20%, 50%, or 100%, and the grayscale release time window is a specified time period.

6. The method according to claim 1, characterized in that, The cache consistency guarantee module includes: sending a message to a message queue after a successful database update, the cache update service consuming the message to perform the cache update, using the SAGA pattern to ensure cross-service transaction consistency, and providing a cache rollback mechanism.

7. The method according to claim 1, characterized in that, The caching strategy recommendation system provides A / B testing functionality, allowing two strategies to be run simultaneously to compare metrics such as cache hit rate, response time, and resource consumption, and to display the strategy performance comparison through a visual interface. The caching policy configuration center provides a configuration inheritance mechanism for tenants, allowing them to inherit basic configurations and make personalized adjustments.

8. The method according to claim 1, characterized in that, The dynamic caching strategy engine is designed based on a caching proxy layer. Business methods declare caching strategies through custom annotations, and the caching proxy layer determines the caching processing method according to the configured caching strategy.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1-8.

10. An electronic device comprising a memory, a processor, and a program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1-8.

Images