Multi-level caching method, device and medium for distributed database

Abstract

The embodiments of this specification disclose a multi-level caching method, device and medium for a distributed database, which relates to the field of database management technology and is used to solve the problem of poor dynamic collaborative management effect. The method includes: monitoring the configuration change events of the configuration center based on a long polling mechanism to obtain configuration update data; issuing the configuration rule parameters corresponding to the configuration update data to determine the current cache strategy, switching the cache level based on the current cache strategy, and realizing the caching of the current change data; monitoring the cache to determine whether the current microservice cluster has received a cache invalidation instruction; if so, receiving the operating indicators of the distributed relational database in real time to determine whether there is a database anomaly, so as to facilitate the retroactive update of the current cache strategy; based on the retroactively updated cache strategy, asynchronously synchronizing the current change data to the distributed cache database.

Description

Technical Field

[0001] This specification relates to the field of data caching technology, and in particular to a multi-level caching method, device, and medium for a distributed database. Background Art

[0002] Large-scale microservice cluster architectures are widely used in various complex application scenarios to meet growing business demands and high-concurrency access. At the same time, distributed databases, as the core of data storage and management, face significant challenges. First, under a microservice architecture, different service modules frequently access the database. The large number of read and write operations places heavy load on the database, impacting the overall system performance and responsiveness, making it difficult to meet the needs of business scenarios with high real-time requirements. Second, the complexity and variability of business logic make dynamic adjustments to database configurations a common practice. Therefore, dynamic configuration management of databases and cache systems, and rapid optimization of data caching strategies to achieve data cache synchronization, are crucial.

[0003] Traditional solutions rely on static configuration files or manual operations. When database connection parameters or Redis cache policies need to be adjusted, a service restart is often required for the adjustments to take effect. This mechanism increases the risk of business interruption in high-concurrency scenarios, and service restarts may directly lead to transaction failures or data loss. At the same time, configuration switching in multiple environments lacks unified management, and manual operations are prone to configuration errors or omissions, increasing the complexity of operations and maintenance. In terms of cache management, a single cache layer design with a fixed strategy is difficult to cope with dynamic business needs. Cache penetration problems are prone to occur in high-frequency access scenarios. A large number of requests directly impact the database, resulting in a significant increase in response latency. In addition, the lack of a real-time failure synchronization mechanism makes data consistency difficult to ensure. In addition, existing technologies for monitoring database anomalies mostly stay at the log recording level, lacking automated threshold alarms and rapid backtracking capabilities. When connection pool blocking or slow queries occur, operations and maintenance personnel need to manually check historical logs, and the fault recovery time can be as long as several hours, directly affecting system availability. Summary of the Invention

[0004] In order to solve the above technical problems, one or more embodiments of this specification provide a multi-level caching method, device and medium for a distributed database.

[0005] One or more embodiments of this specification adopt the following technical solutions:

[0006] One or more embodiments of this specification provide a multi-level caching method for a distributed database, the method comprising:

[0007] Based on the long polling mechanism of the current microservice cluster, the configuration change events of the configuration center are monitored to obtain the configuration update data corresponding to the configuration change events;

[0008] Based on the business scenario corresponding to the configuration update data, the configuration rule parameters of the configuration center are matched and issued to determine the current cache strategy, so as to switch the cache level based on the current cache strategy to achieve caching of the current changed data;

[0009] Monitoring the cache to determine whether the current microservice cluster receives a cache invalidation instruction;

[0010] If so, the operating indicators of the distributed relational database are received in real time to determine whether there is a database anomaly, so as to retroactively update the current cache strategy;

[0011] Based on the cache strategy after backtracking the update, the current changed data is asynchronously synchronized to the distributed cache database.

[0012] Optionally, in one or more embodiments of this specification, before monitoring the configuration change event of the configuration center based on the long polling mechanism of the current microservice cluster to obtain the configuration update data corresponding to the configuration change event, the method further includes:

[0013] Based on the initial configuration set of the configuration center, the connection parameters of the distributed relational database and the cache policy of the distributed cache database are loaded to obtain loaded data;

[0014] Initialize the configuration of the current environment based on the namespace parameters and grouping parameters corresponding to the loaded data;

[0015] Execute the predefined warm-up SQL rules in the configuration center to synchronously load the query results into the distributed relational database and distributed cache database for caching, completing the initialization and population.

[0016] Optionally, in one or more embodiments of this specification, monitoring configuration change events of the configuration center based on the long polling mechanism of the current microservice cluster to obtain configuration update data corresponding to the configuration change event specifically includes:

[0017] Obtaining a configuration query request initiated by the current microservice cluster to the configuration center to determine whether a target configuration corresponding to the configuration query request has changed within a timeout parameter corresponding to the configuration query request;

[0018] If not, return an empty response and re-initiate the configuration query request;

[0019] If so, obtain the configuration change event corresponding to the change, and return the configuration update data corresponding to the configuration change event to trigger the restart-free hot update process of the configuration update data; wherein the configuration update data includes: updated configuration value and version number.

[0020] Optionally, in one or more embodiments of this specification, based on the business scenario corresponding to the configuration update data, matching the configuration rule parameters of the configuration center, issuing to determine the current cache strategy, switching the cache level based on the cache strategy, and implementing the caching of the configuration update data, specifically includes:

[0021] Determining a business scenario corresponding to the configuration update data based on data characteristics corresponding to the configuration update data; wherein the business scenario includes: a static data scenario and a dynamic data scenario;

[0022] Based on the existing cache strategy and cache data, determine whether the configuration update data in the business scenario meets the preset layer switching trigger conditions, and if so, obtain the corresponding configuration rule parameters;

[0023] The current cache strategy is enabled according to the configuration rule parameters issued by the configuration center, so as to switch the cache level based on the current cache strategy and realize the caching of the configuration update data.

[0024] Optionally, in one or more embodiments of the present specification, receiving the operating indicators of the distributed relational database in real time and determining whether there is a database anomaly so as to retroactively update the current cache strategy specifically includes:

[0025] receiving, in real time, operating indicators of the distributed relational database to compare the operating indicators with corresponding preset indicators; wherein the operating indicators include: connection pool blocking rate, slow query frequency, and transaction commit delay;

[0026] Based on the comparison result, determining whether there is a database anomaly in the distributed relational database;

[0027] If so, obtaining a preset number of historical version configurations adjacent to the version number in the distributed relational database;

[0028] Obtaining historical database exception data corresponding to each historical version configuration within the preset number of historical version configurations, so as to determine the most stable historical version configuration based on the historical database exception data;

[0029] Roll back to the most stable historical version configuration based on the interface of the configuration center, and synchronously update the current cache strategy.

[0030] Optionally, in one or more embodiments of this specification, asynchronously synchronizing the current changed data to the distributed cache database based on the cache policy after retroactive update specifically includes:

[0031] Monitor the WAL log of the distributed relational database through logical decoding to capture data change events in real time, perform structured conversion on the data change events, obtain change messages and send them to the MQ message queue;

[0032] The change messages in the MQ message queue are sequentially obtained, and based on the business rules corresponding to the change messages, the change messages are converted into operation instructions of the distributed cache database, and synchronization of the distributed cache database is achieved based on the operation instructions.

[0033] Optionally, in one or more embodiments of this specification, after receiving the operating indicators of the distributed relational database in real time and determining whether there is a database anomaly so as to retroactively update the current cache strategy, the method includes:

[0034] Obtaining transaction requests corresponding to the distributed relational database, and sequentially writing the transaction requests into a cache queue of the distributed cache database;

[0035] Obtain a distributed lock using the RedLock algorithm to lock the resources corresponding to the transaction request, so as to execute the transaction requests of the cache queue in sequence;

[0036] If the execution is completed, an update message is sent based on the MQ message queue, and the cache data of the distributed cache database is asynchronously refreshed to achieve synchronous caching of the distributed cache database and release the distributed lock.

[0037] Optionally, in one or more embodiments of this specification, after asynchronously synchronizing the current changed data to the distributed cache database based on the cache policy after retroactive update, the method further includes:

[0038] Determine whether there is a data conflict between the distributed cache database and the distributed relational database, and if so, obtain the last modification timestamp of the distributed relational database;

[0039] The data in the distributed cache database and the distributed relational database are aligned using the last modified timestamp as a time reference.

[0040] One or more embodiments of this specification provide a multi-level cache device for a distributed database, the device comprising:

[0041] at least one processor; and,

[0042] a memory communicatively connected to the at least one processor; wherein,

[0043] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: perform any of the above methods.

[0044] One or more embodiments of this specification provide a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured to execute any of the above-described methods.

[0045] At least one of the above technical solutions adopted in the embodiments of this specification can achieve the following beneficial effects:

[0046] By monitoring configuration changes in the configuration center through long polling, configuration updates take effect without restarting the service, avoiding business interruptions caused by traditional static configuration requiring a restart and improving business continuity. By configuring rule parameters and dynamically switching cache strategies, the response speed of high-frequency queries is improved. At the same time, the multi-layered, hierarchical caching mechanism reduces cache penetration and database load, reducing network latency and database pressure. When a cache invalidation instruction is detected, the relevant cache is immediately refreshed to ensure data consistency. Database operation indicators are continuously collected and compared with preset thresholds. Database anomalies are located in seconds and intelligent rollbacks are performed, ensuring configuration stability while balancing business determinism and system adaptability. Asynchronously synchronizing changed data to the distributed cache database enables efficient concurrent processing in this concurrent scenario. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for the embodiments or the description of the prior art. Obviously, the drawings described below are only some of the embodiments described in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without inventive work. In the drawings:

[0048] Figure 1 A schematic diagram of a method flow of a multi-level caching method for a distributed database provided in an embodiment of this specification;

[0049] Figure 2 This is a schematic diagram of data synchronization in a distributed database provided in an embodiment of this specification;

[0050] Figure 3 A detailed flowchart of a multi-level cache of a distributed database provided in an embodiment of this specification;

[0051] Figure 4 A schematic diagram of the structure of a multi-level cache device for a distributed database provided in an embodiment of this specification;

[0052] Figure 5 A schematic diagram of the structure of a non-volatile storage medium provided in an embodiment of this specification. DETAILED DESCRIPTION

[0053] The embodiments of this specification provide a multi-level caching method, device, and medium for a distributed database.

[0054] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this specification without creative work should fall within the scope of protection of this specification.

[0055] like Figure 1 As shown, the embodiment of this specification provides a flow chart of a multi-level cache method for a distributed database. Figure 1 It can be seen that in one or more embodiments of this specification, a multi-level caching method for a distributed database specifically includes:

[0056] S101: Monitoring configuration change events of a configuration center based on a long polling mechanism of the current microservice cluster to obtain configuration update data corresponding to the configuration change event.

[0057] In order to solve the problem that traditional solutions rely on static configuration files or manual operations, when database connection parameters or Redis cache strategies need to be adjusted, it is often necessary to restart the service to take effect, which leads to the problem of relying on server restart. In this embodiment, the configuration change events of the configuration center will be monitored according to the long polling mechanism of the current server, so as to obtain the configuration update data corresponding to the configuration change event. In one embodiment, the configuration center is the Nacos configuration center, and before the configuration change events of the configuration center are monitored based on the long polling mechanism, such as Figure 2 As shown, the configuration center will also be used to implement dynamic hot updates of databases and cache strategies, centrally managing the connection parameters of the distributed relational database, namely HGDB connection parameters, and the cache rules of the distributed cache database, namely Redis cache rules.

[0058] Furthermore, in one or more embodiments of this specification, before monitoring the configuration change events of the configuration center based on the long polling mechanism of the current microservice cluster to obtain the configuration update data corresponding to the configuration change events, the method further includes the following process:

[0059] First, based on the initial configuration set from the configuration center, the connection parameters for the distributed relational database and the caching policy for the distributed cache database are loaded to obtain the load data. Then, the current environment configuration is initialized based on the namespace parameters and grouping parameters corresponding to the loaded data. By executing the predefined warmup SQL rules from the configuration center, the query results are synchronously loaded into the distributed relational database and the distributed cache database for caching, completing the initial population.

[0060] like Figure 3 As shown, in one embodiment of this specification, the Nacos configuration center loads database HGDB connection parameters such as connection pool configuration, read-write separation strategy, etc., as well as Redis cache strategies such as expiration time and elimination mechanism, and then isolates the configurations of development, test, and production environments according to namespace Namespace and group Group.

[0061] This process loads the distributed relational database connection parameters and distributed cache database caching policies based on the initial configuration set from the configuration center. This ensures that the microservice cluster receives consistent and accurate basic configuration information during startup, preventing service anomalies and data corruption caused by inconsistent configurations and laying a stable configuration foundation for subsequent business operations. Environment configuration initialization utilizes namespace and group parameters from the loaded data to clearly differentiate between development, test, and production environments, preventing cross-configuration interference between them. This isolation mechanism not only improves the standardization of configuration management but also enables independent configuration debugging and verification within each environment, reducing the risk of online failures caused by misconfiguration. Furthermore, predefined warmup SQL rules from the configuration center are executed to synchronously load query results into the distributed relational database and distributed cache database, completing the initial population. This ensures that hotspot data is already cached at service startup. When user requests arrive, data can be directly retrieved from the cache, reducing database query pressure and significantly improving data access speed.

[0062] Specifically, in one or more embodiments of this specification, the configuration change events of the configuration center are monitored based on the long polling mechanism of the current microservice cluster to obtain the configuration update data corresponding to the configuration change event, specifically including:

[0063] The configuration query request initiated by the current microservice cluster to the configuration center is retrieved to determine whether the target configuration corresponding to the query request has changed within the timeout parameters specified in the query request. If not, an empty response is returned and the query request is re-initiated. If a change has occurred, the corresponding configuration change event is retrieved and the corresponding configuration update data is returned to trigger a restartless hot update process for the configuration update data; the configuration update data includes the updated configuration value and version number.

[0064] In a certain application scenario, a microservice cluster uses a long polling mechanism to monitor configuration changes in the configuration center. After a client initiates a configuration query request, the configuration center server maintains an open connection, for example, with a 30-second timeout. If the configuration changes during this period, the server immediately returns the new data. If the configuration remains unchanged, the server blocks until the timeout expires and returns an empty response, at which point the client re-initiates the long polling request. Upon detecting a configuration change event, the client triggers configuration parsing, compares old and new values, and performs a local configuration hot update. It also notifies the relevant listeners to execute callback logic, ultimately achieving dynamic configuration refresh without restarting the service. This mechanism reduces the number of invalid polls, ensuring real-time performance while also reducing server-side pressure. Nacos centrally manages database and cache configurations, eliminating service restart dependencies and reducing configuration take-effect time from minutes to seconds. For example, the response time for connection pool expansion is ≤3 seconds.

[0065] S102: Based on the business scenario corresponding to the configuration update data, the configuration rule parameters of the configuration center are matched and issued to determine the current cache strategy, so as to switch the cache level based on the current cache strategy to achieve caching of the current changed data.

[0066] Currently, in terms of cache management, a single cache level design with a fixed strategy is difficult to cope with dynamic business needs. Cache penetration problems are prone to occur in high-frequency access scenarios, and a large number of requests directly impact the database, resulting in a significant increase in response delays. In order to avoid the problem that a single cache level design is difficult to cope with dynamic business needs. In the embodiments of this specification, the configuration rule parameters of the configuration center will be matched according to the business scenario corresponding to the configuration update data, and the current cache strategy will be determined. The cache level will be switched according to the current cache strategy to achieve caching of the current changed data.

[0067] Specifically, in one or more embodiments of the present specification, based on the business scenario corresponding to the configuration update data, the configuration rule parameters of the configuration center are matched and issued to determine the current cache strategy, so as to switch the cache level based on the cache strategy and implement the caching of the configuration update data. The specific process includes the following: First, based on the data characteristics corresponding to the configuration update data, such as access frequency, data update frequency, and data size, the business scenario corresponding to the configuration update data is determined. Among them, business scenarios include: static data scenarios with low update frequency and high access volume, such as basic product information and dictionary table data, and dynamic data scenarios with frequent updates and strong timeliness, such as real-time inventory and order status. Then, based on the existing cache strategy and cached data, it is determined whether the configuration update data in the business scenario meets the preset level switching trigger conditions. If so, the corresponding configuration rule parameters are obtained. For example, when indicators such as data access frequency and network latency meet the preset level switching trigger conditions, the cache level weight will be dynamically adjusted to obtain the configuration rule parameters. Then, based on the configuration rule parameters issued by the configuration center, the current cache strategy is enabled, and the cache level is switched according to the current cache strategy to implement the caching of the configuration update data.

[0068] In the multi-level cache tiering process described above, cache levels are intelligently switched based on data characteristics and business scenarios, avoiding the limitations of traditional fixed strategies. Real-time monitoring of indicators and triggering of policy adjustments reduces cache penetration, effectively avoiding the deterioration of responses caused by a large number of requests going directly to the database. Allocating cache resources for different scenarios and switching cache strategies on demand can avoid over-caching or under-caching issues and improve resource utilization. Furthermore, manual intervention in cache strategy adjustments is unnecessary during this process. Automated level switching is achieved through preset rules and dynamic monitoring, reducing the high error rate caused by manual configuration.

[0069] In an application scenario, Figure 3 The multi-level cache layered loading process shown is as follows: Based on the cache_level rules configured by Nacos in the configuration center, such as local and Redis, a hybrid management model of static fallback and dynamic optimization is adopted. Basic rules are manually preset, such as forcing a multi-level cache strategy for steady-state businesses like product details. At the same time, cache layer weights are dynamically adjusted by real-time monitoring of indicators such as data access frequency and network latency. For example, when traffic surges, the cache layer is automatically downgraded to pure Redis mode. Ultimately, the configuration center implements policy hot updates and exception rollbacks within seconds, balancing business determinism and system adaptability. In the process of dynamic configuration hot updates and multi-level cache synergy, through the combination of local cache and Redis's layered design, high-frequency query response speeds are improved by 80% from 500ms to within 100ms, and database load is reduced by over 70%.

[0070] S103: Monitor the cache to determine whether the current microservice cluster receives a cache invalidation instruction.

[0071] During the process of switching the cache level based on the current cache strategy determined in step S102 to implement the cache of the updated data, the embodiments of this specification monitor the cache to determine whether the current microservice cluster has received a cache invalidation instruction. Specifically, when data is updated in the distributed relational database, a cache invalidation instruction is sent to all microservice nodes via the Redis publish-subscribe function.

[0072] S104: If yes, receive the operating indicators of the distributed relational database in real time to determine whether there is a database anomaly, so as to retroactively update the current cache strategy.

[0073] If there is an invalid instruction, then the operating indicators of the distributed relational database are received in real time to determine whether there is a database anomaly, so as to facilitate retroactive updating of the current cache strategy determined in step S102. Specifically, in one or more embodiments of this specification, the operating indicators of the distributed relational database are received in real time to determine whether there is a database anomaly, so as to facilitate retroactive updating of the current cache strategy, specifically including the following process:

[0074] First, the operating indicators of the distributed relational database are received in real time, and the operating indicators are compared with the corresponding preset indicators. Among them, it should be noted that the operating indicators include: connection pool blocking rate, slow query frequency, transaction submission delay, etc. Based on the determined comparison results, determine whether there is a database anomaly in the distributed relational database. If there is an abnormality problem, then obtain a preset number of historical version configurations adjacent to the version number in the distributed relational database. Then, obtain the historical database abnormality data corresponding to each historical version configuration in the preset number of historical version configurations to determine the most stable historical version configuration based on the historical database abnormality data. Thereby rolling back to the most stable historical version configuration based on the interface of the configuration center, and synchronously updating the current cache strategy.

[0075] During this process, by real-time monitoring of core indicators such as the connection pool blocking rate, slow query frequency, and transaction submission delay, database anomalies can be discovered within seconds compared to traditional log analysis methods, thus preventing the spread of faults. Furthermore, by comparing with preset indicator thresholds, automatic determination of anomalies is achieved, eliminating the subjectivity of manual judgment and ensuring the accuracy and timeliness of fault location. Adjacent versions, such as the 10 most recent versions, are retrieved from the database's historical version configuration. This is combined with historical anomaly data, such as the connection pool status and slow query records under each version, to automatically match the most stable historical configuration, which can match the configuration version with the highest success rate. Then, through second-level rollbacks and synchronous updates of cache policies, cache penetration or data inconsistency problems caused by inconsistencies between the database and cache policies are avoided. Through the collaborative optimization of cache and database, the stability and response efficiency of the system in high-concurrency scenarios are significantly improved.

[0076] In one application scenario, the rollback process involves retrieving the 10 most recent configuration versions from the HGDB config_history table when an indicator exceeds a limit. The stable version is then rolled back via the Nacos interface, and the Redis policy is updated simultaneously. Threshold alarms trigger configuration rollbacks (recovery time is reduced from hours to under 5 minutes). Combined with the atomic binding of RedLock distributed locks and HGDB transactions, this increases the success rate of high-concurrency transactions to 99.9%, preventing data inconsistencies such as oversold inventory and achieving 99.99% system availability.

[0077] S105: Based on the cache strategy after retroactive update, asynchronously synchronize the current changed data to the distributed cache database.

[0078] After obtaining the updated cache strategy in the above steps, the current changed data will be asynchronously synchronized to the distributed cache database. This process can asynchronously synchronize incremental data to Redis via MQ, reducing the write pressure on the master database by 50%. At the same time, Nacos dynamically adjusts message queue parameters such as the number of consumers and batch size to achieve on-demand resource allocation, increasing the system throughput by 3 times in scenarios such as e-commerce promotions and reducing manual operation and maintenance intervention by 80%.

[0079] Specifically, in one or more embodiments of this specification, asynchronously synchronizing the current changed data to the distributed cache database based on the cache policy after retroactive update specifically includes:

[0080] Logical decoding is used to monitor the WAL logs of a distributed relational database to capture data change events in real time. These data change events are then structured and converted into change messages, which are then sent to an MQ message queue. Change messages within the MQ message queue are then sequentially retrieved and, based on the business rules corresponding to the change messages, converted into distributed cache database operation instructions. Synchronization of the distributed cache database is achieved based on these operation instructions. Specifically, in a specific application scenario, the distributed relational database HGDB in this embodiment captures data change events through logical decoding, transmits them through the MQ message queue, and is converted by the consumer into Redis operation instructions such as HSET and EXPIRE. This process is primarily divided into three stages: First, HGDB continuously monitors the database's WAL logs using logical decoding, capturing data change events such as add, delete, and modify operations and converting them into structured change messages. These messages contain key information such as the operation type, table name, primary key, and the data content before and after the change. Second, these structured change messages are sent to a message queue such as Kafka or RabbitMQ for reliable transmission. The message queue acts as a buffer and persistence mechanism, ensuring that change messages are not lost even in the event of system failures or network fluctuations. Third, the consumer service retrieves these change messages from the message queue and converts them into corresponding Redis operation instructions based on business rules. For example, update operations are converted into HSET commands to modify the Redis hash table, and delete operations are converted into DEL commands to remove cached data. Appropriate expiration times are also set to manage the cache lifecycle. This entire process enables automated, real-time synchronization between the database and cache, ensuring data consistency and improving system responsiveness.

[0081] Furthermore, in one or more embodiments of the present specification, after receiving the operating indicators of the distributed relational database in real time and determining whether there is a database anomaly so as to retroactively update the current cache strategy, the method further includes:

[0082] Transaction requests corresponding to the distributed relational database are obtained and written sequentially into the cache queue of the distributed cache database. A distributed lock is obtained using the RedLock algorithm to lock the resources corresponding to the transaction requests, allowing the transaction requests in the cache queue to be executed sequentially. If execution is complete, an update message is sent via the MQ message queue, asynchronously refreshing the cached data in the distributed cache database to achieve synchronous caching of the distributed cache database and releasing the distributed lock. This process is a high-concurrency scenario, where all transaction requests are first written to the Redis queue (or cache queue) for buffering, shaving peaks and filling valleys and smoothing system load. Subsequently, the consumer process retrieves the request from the queue and attempts to obtain a distributed lock using the RedLock algorithm to ensure mutually exclusive access to shared resources. Once the lock is successfully acquired, the consumer executes transaction operations related to the HGDB to ensure data consistency and integrity. After the transaction is successfully committed, the system sends an update message via the MQ message queue to asynchronously refresh the relevant cached data in Redis to maintain cache consistency with the database. Eventually, after all critical operations are completed, the distributed lock RedLock will be safely released so that other waiting consumers can continue to process subsequent requests, thus achieving an efficient, reliable, and scalable concurrent processing process.

[0083] Furthermore, in one or more embodiments of the present specification, after asynchronously synchronizing the current changed data to the distributed cache database based on the cache policy after retroactive update, the method further includes:

[0084] Determine whether there are data conflicts between the distributed cache database and the distributed relational database. If so, obtain the last modified timestamp of the distributed relational database. Use this last modified timestamp as the time reference to align the data between the distributed cache database and the distributed relational database. That is, when Redis and HGDB data conflict, overwrite the old value using the HGDB's last_modified timestamp as the reference. After data alignment is complete, record the synchronization status in the sync_audit log table.

[0085] Furthermore, in one feasible implementation, a scheduled task is run every morning to clean up historical configuration records from config_history 30 days ago and archive the synchronized MQ message logs. By continuously executing these steps, a closed-loop management process is achieved, including dynamic configuration validation, coordinated cache updates, and automatic exception handling.

[0086] In this solution, the Nacos Configuration Center enables dynamic, hot updates of the database and cache policies. HGDB connection parameters, such as read-write splitting policies, and Redis cache rules, such as expiration times and eviction algorithms, are centrally managed. Clients monitor configuration changes in real time through a long polling mechanism, ensuring they take effect within seconds and completely eliminating service restart dependencies. A dynamic tiering mechanism is built by combining local Caffeine cache with distributed Redis cache, automatically switching cache tiers based on business scenarios. High-frequency static data, such as basic information, is preferentially read from the local cache, while dynamic data, such as real-time inventory, is accessed through Redis to ensure global consistency. Cache invalidation instructions are broadcast in real time through Pub / Sub, reducing cache penetration to below 5% and database load by 70%. For exception handling, the system collects HGDB database performance metrics in real time. When Nacos exceeds preset thresholds, it automatically retrieves the most recent stable configuration from the HGDB version log, triggering a rollback within seconds and simultaneously updating the Redis policy, reducing fault recovery time from hours to under 5 minutes. At the same time, through the deep collaboration between RedLock distributed locks and Hangao database transactions, the atomicity of high-concurrency operations is ensured, and the MQ asynchronous message queue is combined to achieve real-time synchronization of incremental data. In the event of a conflict, the old value is overwritten based on the last_modified timestamp of HGDB, which reduces the write pressure of the main database by 50%, and the final data consistency delay is controlled within 200ms. This technical solution significantly improves the elasticity and stability of the system through dynamic configuration management, intelligent cache optimization and automated operation and maintenance closed loop. In scenarios such as e-commerce flash sales and financial transactions, the system availability reaches 99.99%, manual intervention in operation and maintenance is reduced by 80%, and the response time is stabilized below 50ms, providing reliable technical support for high-concurrency businesses.

[0087] like Figure 4 As shown in FIG, the embodiment of this specification provides a structural diagram of a multi-level cache device for a distributed database. Figure 4 It can be seen that in one or more embodiments of this specification, a multi-level cache device for a distributed database includes:

[0088] at least one processor; and,

[0089] a memory communicatively connected to the at least one processor; wherein,

[0090] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: perform any of the above methods.

[0091] like Figure 5 As shown in FIG, the embodiment of this specification provides a structural diagram of a non-volatile storage medium. Figure 5It can be seen that in one or more embodiments of this specification, a non-volatile storage medium stores computer-executable instructions 501, and the computer-executable instructions 501 can: execute any of the methods described above.

[0092] The various embodiments in this specification are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the device, apparatus, and non-volatile computer storage medium embodiments are generally similar to the method embodiments, so their descriptions are relatively simplified. For relevant details, refer to the descriptions of the method embodiments.

[0093] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0094] The foregoing description is merely one or more embodiments of this specification and is not intended to limit this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of one or more embodiments of this specification are intended to be within the scope of the claims of this specification.

Claims

1. A multi-level caching method for a distributed database, characterized in that: The method comprises: Based on the long polling mechanism of the current microservice cluster, the configuration change events of the configuration center are monitored to obtain the configuration update data corresponding to the configuration change events; Based on the business scenario corresponding to the configuration update data, the configuration rule parameters of the configuration center are matched and issued to determine the current cache strategy, so as to switch the cache level based on the current cache strategy to achieve caching of the current changed data; Monitoring the cache to determine whether the current microservice cluster receives a cache invalidation instruction; If so, the operating indicators of the distributed relational database are received in real time to determine whether there is a database anomaly, so as to retroactively update the current cache strategy; Based on the cache strategy after backtracking the update, the current changed data is asynchronously synchronized to the distributed cache database; Receiving the operating indicators of the distributed relational database in real time and determining whether there is a database anomaly so as to retroactively update the current cache strategy, specifically including: receiving, in real time, operating indicators of the distributed relational database to compare the operating indicators with corresponding preset indicators; wherein the operating indicators include: connection pool blocking rate, slow query frequency, and transaction commit delay; Based on the comparison result, determining whether there is a database anomaly in the distributed relational database; If so, obtaining a preset number of historical version configurations adjacent to the version number in the distributed relational database; Obtaining historical database exception data corresponding to each historical version configuration within the preset number of historical version configurations, so as to determine the most stable historical version configuration based on the historical database exception data; Rolling back to the most stable historical version configuration based on the interface of the configuration center, and synchronously updating the current cache strategy; Based on the cache policy after backtracking the update, the current changed data is asynchronously synchronized to the distributed cache database, specifically including: Monitor the WAL log of the distributed relational database through logical decoding to capture data change events in real time, perform structured conversion on the data change events, obtain change messages and send them to the MQ message queue; The change messages in the MQ message queue are sequentially obtained, and based on the business rules corresponding to the change messages, the change messages are converted into operation instructions of the distributed cache database, and synchronization of the distributed cache database is achieved based on the operation instructions.

2. A distributed database multi-level caching method according to claim 1, characterized in that: Before monitoring configuration change events of the configuration center based on the long polling mechanism of the current microservice cluster to obtain configuration update data corresponding to the configuration change event, the method further includes: Based on the initial configuration set of the configuration center, the connection parameters of the distributed relational database and the cache policy of the distributed cache database are loaded to obtain loaded data; Initialize the configuration of the current environment based on the namespace parameters and grouping parameters corresponding to the loaded data; Execute the predefined warm-up SQL rules in the configuration center to synchronously load the query results into the distributed relational database and distributed cache database for caching, completing the initialization and population.

3. The multi-level cache method for a distributed database according to claim 1, characterized in that: Based on the long polling mechanism of the current microservice cluster, the configuration change events of the configuration center are monitored to obtain the configuration update data corresponding to the configuration change events, specifically including: Obtaining a configuration query request initiated by the current microservice cluster to the configuration center to determine whether a target configuration corresponding to the configuration query request has changed within a timeout parameter corresponding to the configuration query request; If not, return an empty response and re-initiate the configuration query request; If so, obtain the configuration change event corresponding to the change, and return the configuration update data corresponding to the configuration change event to trigger the restart-free hot update process of the configuration update data; wherein the configuration update data includes: updated configuration value and version number.

4. The multi-level cache method for a distributed database according to claim 1, characterized in that: Based on the business scenario corresponding to the configuration update data, matching the configuration rule parameters of the configuration center, issuing to determine the current cache strategy, switching the cache level based on the cache strategy, and implementing the cache of the configuration update data, specifically including: Determining a business scenario corresponding to the configuration update data based on data characteristics corresponding to the configuration update data; wherein the business scenario includes: a static data scenario and a dynamic data scenario; Based on the existing cache strategy and cache data, determine whether the configuration update data in the business scenario meets the preset layer switching trigger conditions, and if so, obtain the corresponding configuration rule parameters; The current cache strategy is enabled according to the configuration rule parameters issued by the configuration center, so as to switch the cache level based on the current cache strategy and realize the caching of the configuration update data.

5. The multi-level cache method for a distributed database according to claim 1, characterized in that: After receiving the operating indicators of the distributed relational database in real time and determining whether there is a database anomaly so as to retroactively update the current cache strategy, the method includes: Obtaining transaction requests corresponding to the distributed relational database, and sequentially writing the transaction requests into a cache queue of the distributed cache database; Obtain a distributed lock using the RedLock algorithm to lock the resources corresponding to the transaction request, so as to execute the transaction requests of the cache queue in sequence; If the execution is completed, an update message is sent based on the MQ message queue, and the cache data of the distributed cache database is asynchronously refreshed to achieve synchronous caching of the distributed cache database and release the distributed lock.

6. The multi-level cache method for a distributed database according to claim 1, characterized in that: After asynchronously synchronizing the current changed data to the distributed cache database based on the cache strategy after backtracking the update, the method further includes: Determine whether there is a data conflict between the distributed cache database and the distributed relational database, and if so, obtain the last modification timestamp of the distributed relational database; The data in the distributed cache database and the distributed relational database are aligned using the last modified timestamp as a time reference.

7. A multi-level cache device for a distributed database, characterized in that: The device comprises: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: execute the method according to any one of claims 1 to 6.

8. A non-volatile storage medium storing computer-executable instructions, characterized in that: The computer executable instructions can execute the method according to any one of claims 1 to 6.

Images