Management system data caching and batch synchronization method and system based on multi-level cache

Abstract

The invention belongs to the technical field of data caching and batch synchronization, and discloses a management system data caching and batch synchronization method and system.The method comprises the steps that caching processing is conducted on pre-obtained data through a caching strategy based on a pre-constructed caching architecture, operation data are extracted through the cached data, and the operation data are stored in a database; carrying out local operation processing and operation type judgment by combining a transaction engine and an operation classifier; acquiring storage state data of the cache architecture in real time, performing synchronization strategy optimization on a preset synchronization strategy by using a decision tree algorithm, and performing batch synchronization processing in combination with a chained version number mechanism; and acquiring operation state data of the cache architecture, constructing a cache performance index system by using the operation state data, and performing data storage alarm processing by combining an autoregression integral moving average model and an association rule. According to the method, the high-frequency operation response speed is obviously optimized, the load of a back-end server is effectively reduced, and efficient utilization of hardware resources is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of data caching and batch synchronization, and in particular to a management system data caching and batch synchronization method and system based on multi-level cache. Background Art

[0002] Currently known management system data caching and batch synchronization technologies are divided into the following four categories: 1) Pure front-end caching solutions, which primarily rely on local storage technologies such as LocalStorage and IndexedDB, are commonly used for caching static pages. This solution only supports data read operations and cannot handle data addition, deletion, and modification. For data synchronization, a full data pull strategy is often adopted upon page refresh, a common practice in news and information applications. However, this approach suffers from poor real-time performance, with data update intervals measured in minutes and a lack of transactional guarantees. Without a version control mechanism, data writes follow the principle of "last write, first write overwrites" and, when operating simultaneously on multiple devices, the probability of data conflicts exceeds 10%. 2) Back-end centralized caching solutions, which utilize a single-level cache architecture from the database to Redis, are widely used in systems such as e-commerce flash sales and order centers. However, the front-end still requires frequent requests, resulting in network overhead accounting for up to 80%. Data synchronization is achieved through a combination of timed invalidations and active updates using message queues. However, in high-concurrency scenarios, cache invalidation strategies can easily lead to cache breakdown. Furthermore, this solution lacks local data autonomy, rendering the system completely unusable in edge scenarios if the network is disrupted. 3) Distributed cache synchronization solutions, exemplified by Redis Cluster with Sentinel mode, can support massive terabyte-scale data storage. Its asynchronous replication mechanism enables throughput of up to 100,000 queries per second (QPS), making it suitable for scenarios with high eventual consistency requirements, such as financial transfers. However, this solution has significant limitations: cross-shard transaction processing logic is complex, making ACID implementation expensive; data replication latency between master and slave nodes can reach up to 50ms, potentially leading to corrupted data. In transaction scenarios requiring strong consistency, additional technical measures are required to ensure data accuracy. 4) The currently optimal hybrid architecture combines client-side and server-side caching, exemplified by a three-tier architecture combining Redis and a database for progressive web apps (PWAs), which performs well in mobile office apps. However, this architecture's caching strategy configuration is complex and requires manual handling of version conflicts. Data synchronization utilizes a combination of polling, long polling, and WebSocket technologies, commonly used in instant messaging systems. However, in fluctuating network environments (such as 2G networks), synchronization failure rates can reach as high as 30%. Furthermore, its offline capabilities only support caching of static resources and cannot meet the offline needs of dynamic data operations (such as form submissions).

[0003] From the four solutions described above, we can summarize the following three issues with traditional solutions, ranging from performance bottlenecks to architectural innovation: 1) Computing power contradictions in digital transformation. This refers to the increasing conflict between business system computing power requirements and the performance bottlenecks of traditional architectures as enterprises accelerate their digitalization. With the profound evolution of enterprise ERP systems and industrial MES, high-frequency business scenarios such as real-time e-commerce order processing and industrial production line monitoring have pushed system response performance requirements to sub-second or even millisecond levels. In traditional architectures, front-end requests must directly reach the database via network links. When the server's query per second (QPS) rate approaches a threshold, response latency increases exponentially. For example, in financial transactions, a 100-millisecond delay can result in tens of millions of yuan in economic losses. Furthermore, edge computing scenarios enabled by 5G and IoT technologies (such as smart inspection terminals and mobile medical devices) require systems to support temporary data storage and offline processing in weak network environments (such as underground mining areas and remote areas), with automatic synchronization upon network restoration, further exacerbating computing power pressures. 2) Technical bottlenecks in traditional architectures. This refers to the significant limitations of traditional technology architectures in meeting modern business demands. While single-level caching solutions (such as Redis) can alleviate some of this pressure, the frontend still requires frequent network requests, resulting in a large number of invalid requests bypassing the cache layer and directly accessing the database, which can easily exhaust the relational database's connection pool resources. If a Redis cluster fails, all requests are instantly directed to the database, triggering a system-wide service avalanche. Furthermore, in a frontend-to-backend separation architecture, the data transmission path (frontend → API gateway → service layer → database) presents significant flaws. The frontend lacks local data autonomy, rendering the system paralyzed in offline environments. The lack of effective version coordination between multi-level caches leads to data conflict rates as high as 3%-5%, severely impacting data consistency and business continuity. Thirdly, the need for technological evolution: Traditional capacity expansion solutions address traffic peaks by horizontally scaling server nodes, but this leads to significant resource waste. Data shows that the annual growth rate of single-server O&M costs is as high as 20%, while average CPU utilization remains at only 30%-40%. In cloud service architectures, database call costs account for over 60% of total system costs. This imbalance between hardware cost and efficiency urgently requires more optimized technical solutions to achieve a balance between performance improvement and cost control.

[0004] In summary, the pain points faced by traditional management systems include: performance bottlenecks, resource waste, offline unavailability, poor scalability, inability to support dynamic operations, lack of a collaborative architecture with the front-end, and high data conflict rates. Performance bottlenecks refer to high server loads caused by real-time requests, with response delays reaching 300-500ms. Resource waste refers to repeated database requests for high-frequency operations (such as list queries), which consumes large amounts of computing resources. Offline unavailability refers to complete system failure in the event of a network outage, impacting business continuity. Poor scalability refers to the high cost of horizontal server expansion as data volume grows. Inability to support dynamic operations refers to the front-end cache only caching static data and not dynamic operations (such as additions, deletions, and modifications). Lack of a collaborative architecture with the front-end refers to the back-end cache Redis serving only as a database acceleration layer and lacking a collaborative architecture with the front-end. High data conflict rates refer to the offline solution's lack of complete transaction consistency guarantees, resulting in a high data conflict rate (3%-5%).

[0005] Therefore, how to provide a management system data caching and batch synchronization method and system based on multi-level cache is a problem that needs to be solved urgently. Summary of the Invention

[0006] The embodiments of the present invention provide a method and system for managing data cache and batch synchronization of a multi-level cache-based management system to solve the above-mentioned technical problems in the prior art.

[0007] To provide a basic understanding of some aspects of the disclosed embodiments, the following is a brief summary. This summary is not intended to be an extensive review, identify key or critical elements, or delineate the scope of these embodiments. Its sole purpose is to present some concepts in a simplified form as a prelude to the detailed description that follows.

[0008] According to a first aspect of an embodiment of the present invention, a method for managing system data cache and batch synchronization based on a multi-level cache is provided.

[0009] In one embodiment, a method for managing system data caching and batch synchronization based on a multi-level cache includes: Based on the pre-built cache architecture, the cache strategy is used to cache the pre-acquired data. Operation data is extracted from the cached data. Local operation processing and operation type determination are performed based on the operation data in combination with the transaction engine and operation classifier. Acquire the storage status data of the cache architecture in real time, optimize the preset synchronization strategy using a decision tree algorithm based on the storage status data and operation type, and perform batch synchronization of data processed by local operations based on the optimized synchronization strategy combined with a chained version number mechanism; Obtain the operating status data of the cache architecture and use the operating status data to build a cache performance indicator system. Based on the cache performance indicator system, combine the autoregressive integral moving average model and association rules to perform storage anomaly detection, and perform data storage alarm processing based on the storage anomaly detection results.

[0010] According to a second aspect of an embodiment of the present invention, a management system data cache and batch synchronization system based on multi-level cache is provided.

[0011] In one embodiment, a management system data cache and batch synchronization system based on multi-level cache includes: a cache processing module, a synchronization processing module and a storage alarm module; The cache processing module is used to cache the pre-acquired data based on the pre-built cache architecture and cache strategy, extract the operation data based on the cached data, and determine the operation type of the operation data through the transaction engine and operation classifier; The synchronization processing module is used to obtain the storage status data of the cache architecture in real time, optimize the preset synchronization strategy using the decision tree algorithm based on the storage status data and operation type, and perform batch synchronization of cached data based on the optimized synchronization strategy combined with the chain version number mechanism; The storage alarm module is used to obtain the operating status data of the cache architecture and use the operating status data to build a cache performance indicator system. Based on the cache performance indicator system combined with the autoregressive integral moving average model and association rules, storage anomaly detection is performed, and data storage alarm processing is performed according to the storage anomaly detection results.

[0012] According to a third aspect of embodiments of the present invention, a computer device is provided.

[0013] In some embodiments, the computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the steps of the above-mentioned multi-level cache-based management system data caching and batch synchronization method when executing the computer program.

[0014] According to a fourth aspect of embodiments of the present invention, a computer-readable storage medium is provided.

[0015] In one embodiment, a computer readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned method for managing system data cache and batch synchronization based on multi-level cache are implemented.

[0016] The technical solution provided by the embodiment of the present invention may have the following beneficial effects: 1. The present invention significantly optimizes the response speed of high-frequency operations through front-end local caching and transaction logs, making it reach the response level of local applications; through an efficient transaction processing mechanism, it greatly improves the efficiency of complex transaction processing and effectively reduces the back-end server load; at the same time, it optimizes the key-value storage database caching strategy, significantly improves the cache hit rate, reduces server CPU resource usage, and achieves efficient utilization of hardware resources; at the same time, through deep optimization and resource integration of the cache architecture, it greatly reduces the number of back-end server deployments, significantly reduces network bandwidth consumption and data center energy consumption, achieves PUE value optimization, and effectively controls operating costs.

[0017] 2. The present invention further guarantees offline operation processing through transaction logs, supports long-term offline operations, and ensures data consistency; after the network is restored, data synchronization is automatically performed without manual intervention to ensure business continuity; it enhances adaptability in offline and weak network environments, significantly improves data transmission reliability and multi-terminal data synchronization efficiency, greatly reduces business interruption time, and provides users with a smooth and stable user experience; at the same time, through the efficient expansion characteristics of the key-value storage database, compared with traditional database expansion, it significantly reduces the horizontal expansion cost; at the same time, it supports multi-cloud flexible deployment architecture, and further optimizes network resource usage through front-end local caching to reduce cloud service costs; and combines the chain version number mechanism with the transaction log mechanism to effectively solve the problem of distributed data conflicts.

[0018] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0020] Figure 1 This is a flow chart of a method for managing data cache and batch synchronization in a multi-level cache-based management system according to an exemplary embodiment; Figure 2 is a structural diagram of a system according to an exemplary embodiment; Figure 3 is a structural diagram of a computer device according to an exemplary embodiment; Figure 4 This is a diagram of a full-link technical architecture from the terminal to the backend in actual application of a multi-level cache-based management system data caching and batch synchronization method according to an exemplary embodiment; Figure 5 This is a cache layer design diagram of a cache architecture in a data cache and batch synchronization method of a management system based on a multi-level cache according to an exemplary embodiment; Figure 6 This is a data synchronization flow diagram of a cache architecture in a data cache and batch synchronization method of a management system based on a multi-level cache according to an exemplary embodiment; Figure 7 This is a diagram showing the deployment of collection components in a practical application of a data cache and batch synchronization method for a management system based on a multi-level cache according to an exemplary embodiment; Figure 8 This is a dynamic synchronization decision tree logic diagram of a data cache and batch synchronization method of a management system based on a multi-level cache in actual application according to an exemplary embodiment; Figure 9 The present invention is a data caching and batch synchronization architecture diagram showing a data caching and batch synchronization method of a management system based on a multi-level cache according to an exemplary embodiment.

[0021] Reference numerals: 201, cache processing module; 202, synchronization processing module; 203, storage alarm module. DETAILED DESCRIPTION

[0022] Figure 1 An embodiment of the multi-level cache-based management system data cache and batch synchronization method of the present invention is shown.

[0023] In this optional embodiment, the method for managing system data cache and batch synchronization based on multi-level cache includes: Step S101: Cache the pre-acquired data using a cache strategy based on a pre-built cache architecture, extract operation data from the cached data, and perform local operation processing and operation type determination based on the operation data in conjunction with the transaction engine and operation classifier. Step S102: Acquire the storage status data of the cache architecture in real time, optimize the preset synchronization strategy using a decision tree algorithm based on the storage status data and the operation type, and perform batch synchronization on the data processed by the local operation based on the optimized synchronization strategy in combination with the chained version number mechanism; Step S103: Obtain the operating status data of the cache architecture, and use the operating status data to build a cache performance indicator system. Based on the cache performance indicator system, combine the autoregressive integral moving average model and association rules to perform storage anomaly detection, and perform data storage alarm processing according to the storage anomaly detection results.

[0024] In this optional embodiment, the pre-acquired data is cached using a cache strategy based on a pre-built cache architecture, operation data is extracted from the cached data, and local operation processing and operation type judgment are performed based on the operation data in combination with a transaction engine and an operation classifier, including: based on a pre-built cache architecture combined with a cache strategy, the pre-acquired data is cached in sequence in the database, key-value storage database and front-end cache of the cache architecture; operation data is extracted based on the front-end cached data, and local operation processing and operation type judgment are performed based on the operation data in combination with a transaction engine and an operation classifier to obtain a local transaction log and operation type.

[0025] In this optional embodiment, based on a pre-built cache architecture combined with a cache strategy, the pre-acquired data is cached in sequence in the database of the cache architecture, the key-value storage database and the front-end cache, including: according to the pre-built cache architecture, the pre-acquired data is stored in the database of the cache architecture, and the database data is copied to the standby database through master-slave replication; based on change data capture, the storage data of the standby database is synchronously stored in the key-value storage database of the cache architecture, and the data shards stored in the key-value storage database are cached in real time at the front end of the cache architecture by pushing real-time changes.

[0026] In this optional embodiment, operation data is extracted based on the data cached on the front end, and local operation processing and operation type judgment are performed based on the operation data in combination with the transaction engine and the operation classifier to obtain the local transaction log and operation type, including: extracting operation data based on the data cached on the front end, and performing local operation processing based on the operation data, and recording the local operation processing through the transaction engine to obtain a local transaction log; and using the operation classifier to judge the operation type of the operation data based on the local transaction log and pre-set operation classification rules.

[0027] In this optional embodiment, the storage status data of the cache architecture is obtained in real time, the preset synchronization strategy is optimized by using a decision tree algorithm according to the storage status data and the operation type, and batch synchronization processing is performed on the data processed by local operations based on the optimized synchronization strategy combined with the chain version number mechanism, including: obtaining the storage status data of the cache architecture in real time, and calculating the synchronization optimization period by using a linear weighted method according to the storage status data and the operation type; extracting operation feature data based on the storage status data and the operation type, and using a decision tree algorithm combined with the operation feature data to optimally screen the preset synchronization strategy to obtain the optimal synchronization strategy; integrating the synchronization optimization period and the optimal synchronization strategy to obtain the optimized synchronization strategy, and batch synchronization processing is performed on the data processed by local operations based on the optimized synchronization strategy combined with the chain version number mechanism.

[0028] In this optional embodiment, the operation characteristic data includes: operation type characteristic data, data activity characteristic data, network quality characteristic data, data sensitivity characteristic data, operation data volume characteristic data and synchronization time characteristic data.

[0029] In this optional embodiment, batch synchronization processing of data processed by local operations based on the optimized synchronization strategy combined with the chain version number mechanism includes: batch synchronization and storage of data processed by local operations to a key-value storage database based on the optimized synchronization strategy combined with the chain version number mechanism; and persistent storage of batch synchronized data in the key-value storage database to the database using the optimized synchronization strategy.

[0030] In this optional embodiment, the operating status data of the cache architecture is obtained, and a cache performance indicator system is constructed using the operating status data. Storage anomaly detection is performed based on the cache performance indicator system in combination with an autoregressive integral sliding average model and association rules. Data storage alarm processing is performed according to the storage anomaly detection results, including: obtaining the operating status data of the cache architecture, and constructing a cache performance indicator system using the operating status data; obtaining a normal fluctuation range of the cache performance indicator based on the cache performance indicator system in combination with an autoregressive integral sliding average model, and obtaining an alarm threshold of the cache performance indicator based on the normal fluctuation range of the cache performance indicator; performing storage anomaly detection on the cache architecture using association rules in combination with the alarm threshold of the cache performance indicator, and performing data storage alarm processing according to the storage anomaly detection results.

[0031] In this optional embodiment, the cache performance indicator system includes: cache performance indicators, transaction processing indicators, synchronization operation indicators and resource utilization indicators; cache performance indicators include: key-value storage database hit rate, memory fragmentation rate, number of connections, front-end read and write time and cache hit rate; transaction processing indicators include: transaction success rate, average time, rollback rate and offline transaction backlog; synchronization operation indicators include: synchronization cycle deviation, data transmission volume, conflict resolution times and push real-time change connection status; resource utilization indicators include: server or memory utilization, disk utilization, network bandwidth and packet loss rate.

[0032] Figure 2 An embodiment of the management system data cache and batch synchronization system based on multi-level cache of the present invention is shown.

[0033] In this optional embodiment, the management system data cache and batch synchronization system based on multi-level cache includes: a cache processing module 201, a synchronization processing module 202 and a storage alarm module 203; The cache processing module 201 is used to cache the pre-acquired data based on the pre-built cache architecture and cache strategy, extract operation data based on the cached data, and determine the operation type of the operation data through the transaction engine and operation classifier; Synchronization processing module 202 is used to obtain storage status data of the cache architecture in real time, optimize the preset synchronization strategy using a decision tree algorithm based on the storage status data and operation type, and perform batch synchronization of cached data based on the optimized synchronization strategy combined with a chained version number mechanism; The storage alarm module 203 is used to obtain the operating status data of the cache architecture and use the operating status data to build a cache performance indicator system. Based on the cache performance indicator system combined with the autoregressive integral moving average model and association rules, storage anomaly detection is performed, and data storage alarm processing is performed according to the storage anomaly detection results.

[0034] It should be noted that the key abbreviations and key terms used in this disclosure are explained as follows: ERP system stands for Enterprise ERP Management System. Industrial MES refers to manufacturing enterprise production process execution management software. QPS stands for Queries per Second, which refers to the number of request data processed (generating inference results) per unit time and computing resources. Redis (Remote Dictionary Server), a remote dictionary service (i.e., a key-value store), is an open-source, log-based, key-value database written in ANSI C, supporting networking, memory-based, and persistent storage. RedisCluster is a distributed solution for Redis, designed to address the limited capacity and single point of failure of a single Redis server. By distributing data across multiple nodes, it enables distributed storage, access, and failover, thereby building a highly available and scalable Redis cluster system. MySQL is a relational database management system. LocalStorage is part of the Web Storage API, which allows developers to store key-value data in the user's browser. IndexedDB is a browser-side data storage method. WebSocket (i.e., push real-time changes) is a protocol for full-duplex communication over a single TCP connection. JWT (JSON Web Token) is a JSON-formatted token used for authentication and information exchange in distributed web applications. JWT protects documents from unauthorized access. AES-256, the Advanced Encryption Standard, is the longest and strongest encryption level provided. The TLS 1.3 protocol, also known as the Transport Layer Security (TLS) protocol, and its predecessor, the Secure Sockets Layer (SSL), are security protocols designed to provide security and data integrity for internet communications. TLS 1.3 is the latest version of the TLS encryption protocol.

[0035] It should be noted that the technological breakthrough of the present invention is the multi-level cache collaborative architecture (i.e., cache architecture). The core differences between the present invention and the pure front-end cache solution, the back-end centralized cache solution, the distributed cache synchronization solution, and the currently optimal hybrid architecture solution are shown in Table 1.

[0036] Table 1 Core differences between the present invention and existing solutions ; The essence of this invention is to address the triple challenges of "explosive data growth + increasing real-time requirements + widespread edge scenarios." By restructuring the cache hierarchy, innovating the synchronization mechanism, and strengthening offline capabilities, it fills the technical gaps in existing solutions between high performance, strong consistency, and offline autonomy, representing the evolution of management system architecture from "server-centric" to "end-edge-cloud collaboration." The innovations in this invention's technical principles include: a three-level cache collaboration architecture, a chained version number mechanism, a dynamic synchronization decision tree, and transaction log atomicity guarantees. The three-level cache collaboration architecture breaks the traditional "frontend → server" one-way request model and the performance bottleneck of the traditional front-end and back-end separation architecture. It establishes a new model of "database → Redis → front-end local cache → user operation," forming a closed-loop data flow and implementing "front-end priority processing + asynchronous batch synchronization." 90% of high-frequency operations are completed locally, resolving the contradiction between real-time performance and offline capabilities in traditional solutions. The chained version number mechanism, in which each data object maintains a version chain, accurately records the order and type of operations, resolves multi-level cache conflicts, and enables cross-level cache operation sequence tracing, improving conflict resolution efficiency by 40% compared to traditional timestamp solutions. A dynamic synchronization decision tree adaptively adjusts synchronization strategies based on multiple operational characteristics, including operation type, data activity, and network status. It calculates the optimal synchronization period in real time, balancing real-time performance with resource consumption, and triples bandwidth utilization in industrial scenarios. Transaction log atomicity guarantees ensure that offline operations are encapsulated as transactions and automatically retried upon network recovery.

[0037] It should be noted that the full-link technical architecture from the terminal to the backend, such as Figure 4The architecture diagram shows the complete flow from user terminals to the data layer, including the integration of the monitoring system. At the application layer, user terminals communicate with the load balancer via HTTPS, which distributes requests to front-end application servers. The front-end application servers also maintain a real-time connection to the load balancer via WebSocket. The service layer receives REST API requests from the front-end application servers. These requests are first processed by the back-end API gateway and then routed to the microservice cluster through service discovery. The microservice cluster processes the business logic and returns the results to the change capture service. The change capture service then writes the data to the database cluster's master database and the Redis master node. The microservice cluster writes to the Redis cluster via the Redis protocol and synchronizes data changes using CDC (Change Data Capture) technology. At the data layer, the Redis cluster uses a master-slave replication model, with Redis slave nodes 1 and 2. The Redis master node handles write operations, while multiple Redis slave nodes handle read operations, improving read performance and data redundancy. The database cluster also uses a master-slave replication model, with slaves 1 and 2, ensuring data consistency and high availability.The entire system also integrates a monitoring system to perform performance monitoring, error detection, and indicator collection at each level to ensure the stable operation of the system. The figure is a deployment architecture diagram, which adopts a multi-layer decoupling design and is divided into 5 major layers from user access to data storage. Each component works together through standardized protocols; among them, the user access layer is the user request entrance, and the user terminal communicates with the back-end through the HTTPS protocol. The load balancer uses Nginx / Apache to achieve traffic distribution and SSL unloading, supporting 100,000 request forwarding per second. The two work together to distribute user requests to different servers to realize data entry diversion; the application service layer is the business logic carrier, and the front-end application server deploys Vue / React front-end applications, maintains a long connection with the Redis cluster through WebSocket, and receives data change push in real time. The back-end API gateway is based on SpringCloud The Gateway / APISIX implements request routing, permission verification, and flow control, centrally managing access to microservices. The microservice cluster uses Kubernetes to deploy Java / Python microservices. Each microservice is responsible for a specific function and automatically registers routes, enabling functional decomposition. The data cache layer delivers high-performance read and write acceleration. The Redis master-slave cluster adopts a 3-master-6-slave architecture, acting as a temporary data storage container for frequently accessed data. The master node handles write operations, while the slave nodes handle read requests, with automatic failover in sentinel mode. The data persistence layer provides core data persistence. The database cluster uses a MySQL cluster (master-slave replication) and a distributed database to store all data. The master handles write operations, while the slaves handle queries. The monitoring and operations layer provides full-link observability and serves as a monitoring center, tracking the health of each link, enabling early detection of faults and timely operational response. Through layered decoupling, protocol standardization, and component redundancy, a high-performance, highly available, and secure three-level cache architecture is achieved. This architecture, like a "highway + intelligent logistics network," offers fast user access, easy business expansion, and robust fault recovery, making it particularly suitable for supporting large-scale online businesses. Its three core designs include cache + database, microservice decomposition, and full-link monitoring. The "cache + database" dual-layer storage achieves separation of fast and slow data. High-frequency data is stored in Redis (a temporary storage), while low-frequency data is stored in the database (a large warehouse). "Microservice splitting" decouples business operations, allowing each service to be independently developed, deployed, and scaled. "Full-link monitoring" enables early fault detection, monitoring every link from user request to database. "Cache acceleration + microservice splitting + full-link monitoring" supports high-concurrency business, making the management system faster, more stable, and easier to expand. The three-level cache architecture, namely the construction of a database, a Redis cache cluster, and a front-end local cache, breaks the traditional one-way request model between the front-end and back-end. The database → Redis → front-end local cache forms a closed data flow loop, with each cache layer assuming different responsibilities. The database layer serves as the core of data persistence storage.The Redis cache cluster layer handles high-speed data reads and temporary storage. The front-end local cache localizes user operations, reducing back-end reliance. Data exchange and synchronization between the three layers is achieved through specific protocols and policies, implementing "front-end priority processing + asynchronous batch synchronization." This allows 90% of high-frequency operations (such as list queries and form edits) to be completed locally, significantly reducing pressure on back-end servers. The cache layer design is as follows. Figure 5 As shown in the figure, the database layer performs master-slave replication to the standby database. The standby database is then captured and stored in the Redis cache layer via CDC changes. The Redis cache layer performs sharded storage, resulting in data shards 1, 2, and 3. These shards are pushed to the front-end via WebSocket for real-time caching, and the front-end persists them to obtain local transaction logs via IndexedD. The data caching and batch synchronization process is mainly divided into the data storage process, cache synchronization process, transaction processing process, conflict resolution process, synchronization strategy engine process, and monitoring process. Each process has a clear division of labor and works closely together to ensure the efficient operation and data consistency of data caching and batch synchronization. The data storage process is responsible for managing the database, Redis cache, and front-end local cache, providing basic operation interfaces such as data storage, reading, updating, and deleting, while maintaining data metadata such as data version and storage location. The cache synchronization process implements data synchronization between caches at all levels, including initial synchronization from the database to the Redis cache, initial loading from the Redis cache to the front-end local cache, and real-time and periodic synchronization between the front-end local cache and the Redis cache. The data synchronization flow is as follows: Figure 6 As shown, the database CDC captures changes and synchronizes them to the Redis cache. The Redis cache performs initial data loading into the front-end local cache. Local operations (additions, deletions, and modifications) are performed in the front-end local cache, and the operations (including chained version numbers) are recorded. A local transaction log is generated, and periodic batch synchronization is performed into the Redis cache based on the local transaction log. The Redis cache is persisted to the database through time. The database synchronizes changes to other nodes to the Redis cache, and the Redis cache pushes real-time changes (WebSocket) to the front-end local cache.

[0038] The transaction processing process is to encapsulate the user's add, delete, and modify operations into transactions to ensure the atomicity, consistency, isolation, and durability (ACID characteristics) of the operations. In offline scenarios, transaction logs are recorded, and transactions are automatically committed or rolled back after the network is restored. The conflict resolution process is based on the chain version number mechanism to detect and resolve data conflicts between caches at all levels to ensure data consistency. The synchronization strategy engine process is to dynamically calculate the optimal synchronization cycle and synchronization method based on factors such as data activity, network quality, and sensitivity level to achieve efficient data synchronization. The monitoring process is to monitor the operating status of the system in real time, collect data such as performance indicators, transaction processing status, and synchronization operation records of caches at all levels, and analyze them to provide a basis for system optimization and troubleshooting. Through the complete link of "collection-processing-storage-analysis", early fault prediction, performance optimization, and cost control are achieved, and a closed-loop management system from indicator collection to decision support is established. Such as Figure 7 The figure below shows the deployment of the collection components. Client-side tracking uses a front-end collector to collect JavaScript performance data and send the data to a data aggregator via HTTP. Redis collects information using INFO commands, which is processed by the Redis exporter and transmitted to the data aggregator via gRPC. The application server interacts with the Java agent via the JMX interface, which then sends the data to the data aggregator via TCP. The database's slow query log is also sent to the data aggregator after file parsing by the SQL monitor. This entire process ensures that data from the client, Redis, application server, and database is effectively collected and aggregated for further analysis and monitoring. Data is collected from every module in the deployment architecture. The data collection metric classification (i.e., cache performance metric system) is shown in Table 2 below.

[0039] Table 2 Classification of indicators for data collection ; By cleaning and aggregating the indicator data, storing the processed indicator data in a hierarchical manner, and analyzing the indicator data, a visual dashboard is generated. When the indicator exceeds the alarm threshold, the operation and maintenance unit will be notified to increase fault tolerance and security. Among them, the chain version number mechanism in the present invention maintains a version chain for each data object. Each node in the version chain represents a data operation and adopts the format of "v{version number}-{operation type identifier}", such as "v1-c" represents the first creation operation, "v3-u" represents the third update operation, and "v7-d" represents the seventh deletion operation. In this way, the operation history and sequence of the data are accurately recorded. In the process of data synchronization and conflict detection, the version chain is used to trace the operation sequence and resolve conflicts. Compared with the traditional timestamp solution, this mechanism improves the conflict resolution efficiency by 40%, effectively ensuring the consistency of data between multi-level caches. The dynamic synchronization decision tree, that is, the synchronization strategy engine module integrates operations research and machine learning technology, and calculates the optimal synchronization period in real time through the following formula: ;in, f The frequency of data changes is calculated by counting the number of additions, deletions, and modifications of data within a unit of time; q The network quality score ranges from 0 to 1 and can be comprehensively evaluated through indicators such as network delay and packet loss rate; s The data sensitivity coefficient is set according to the importance and confidentiality of the data, such as 0.1 for normal data and 0.9 for sensitive data; α 、 β 、 γ The weight coefficient can be adjusted according to the actual business scenario. At the same time, the decision tree algorithm automatically selects the optimal synchronization method (real-time synchronization, periodic synchronization, or offline temporary storage) based on the following multi-dimensional characteristics (i.e., operation feature data) such as operation type, data activity, and network status (as shown in Table 3 below).

[0040] Table 3 Operating characteristic data and their quantification ; It can be understood as a "smart butler for data synchronization". It determines whether to "process urgently", "process regularly" or "store offline and process again when the network is good" according to the steps. The value of this process is to make data synchronization "smart and flexible": urgent operations are processed immediately, non-urgent operations are processed according to the frequency and time, data is stored first when there is no network, and conflicts can be automatically coordinated, ultimately ensuring that the data is accurate and fast. Figure 8The figure shows a dynamic synchronization decision tree logic diagram. The diagram determines whether the operation request has high real-time requirements. If so, a real-time synchronization channel is performed. If not, the data activity level is assessed. If the data activity level is high, the short synchronization period is set to 1 minute; if the data activity level is medium, the medium synchronization period is set to 5 minutes; if the data activity level is low, the long synchronization period is set to 30 minutes. A pre-synchronization check then checks whether the network is available. If so, a batch synchronization is performed to Redis. If not, a local transaction log is generated and batch synchronization is performed to Redis via network recovery. Finally, Redis processes the data to determine if there are conflicts. If so, conflict resolution is performed. After the conflict is resolved, a chained version number merge is performed until the synchronization is successful. If not, the synchronization is successful. The transaction log ensures atomicity: the transaction processing process encapsulates user operations on the front end into transactions and records them in a transaction log. The transaction log contains information such as the transaction ID, operation type (create, update, delete), operation object (table name, record ID), operation data, and version number. In offline scenarios, transactions are temporarily stored in the front-end local cache, ensuring atomicity even during network outages. When the network is restored, the transaction processing process automatically commits the transaction based on the transaction log. During the commit process, the transaction operations are first synchronized to the Redis cache cluster, which then asynchronously synchronizes them to the database. If an error occurs during synchronization, the transaction processing module rolls back the operation based on the error type to ensure data consistency and integrity. For example, when submitting a transaction containing multiple operations, if one operation fails, the entire transaction is rolled back, avoiding data inconsistencies caused by the success of some operations. The front-end local caching technology combines LocalStorage and IndexedDB. LocalStorage is used to store small amounts of frequently accessed data, such as user profiles and recent access history. Its advantages are simplicity, data storage as key-value pairs, and direct access via JavaScript. IndexedDB is used to store large amounts of structured data, such as business form data and list data. It supports transaction operations, indexed queries, and has a large data storage capacity, meeting the data storage needs of complex business scenarios. During data storage, sensitive data is encrypted with AES-256 to ensure local data security. Data indexing is also implemented to improve query efficiency. For example, for order data, indexes can be created based on fields such as order ID, user ID, and order time, enabling quick query of order data with specific criteria. Redis cache cluster configuration and optimization, namely, Redis cache clusters use Cluster mode, enabling horizontal data scalability through sharded storage, supporting terabyte-level data storage.Each shard consists of a master node and multiple slave nodes. The master node handles write operations and some read operations, while the slave nodes are used for data backup and read load sharing, improving system availability and performance. To improve cache hit rates, the following optimization strategies are employed: reasonable key-value design, cache eviction policy, and cache pre-warming. Reasonable key-value design involves following naming conventions and grouping the key values ​​of related data for easier management and querying. For example, for user-related data, the key values ​​are named in the format "user:{user_id}:{data_type}". Cache eviction policy involves selecting an appropriate cache eviction policy based on business needs, such as LRU (least recently used) or LFU (least frequently used), to ensure that popular data is always cached. Cache pre-warming involves pre-loading popular data into the Redis cache upon storage startup to reduce latency on first access. Data synchronization between the database and the Redis cache uses a combination of Change Data Capture (CDC) technology and message queues. CDC technology monitors database changes (such as inserts, updates, and deletes) in real time, extracts the changed data, and sends it to a message queue. The Redis cache cluster subscribes to the message queue, retrieves the changed data, and performs appropriate processing based on the data type and operation type, such as updating cached data or deleting expired cached data. To ensure accurate and consistent data synchronization, a transactional message mechanism is introduced. When a database transaction is executed, a transaction message is simultaneously sent to the message queue. The message queue only sends the message to the Redis cache cluster after confirming that the database transaction has been successfully committed. If the database transaction is rolled back, the message queue automatically deletes the corresponding transaction message, preventing inconsistencies between the Redis cache and the database data. Data exchange between the front-end and the Redis cache occurs via WebSocket and HTTP protocols. For operations requiring high real-time performance (such as real-time message push and status updates), WebSocket is used to establish a persistent connection, enabling real-time, bidirectional data transmission. For non-real-time operations (such as batch data synchronization and query requests), HTTP is used. Furthermore, JWT (JSON Web Token) is used for authentication and authorization, ensuring that only legitimate front-end applications can access Redis cache data, thus ensuring data security. Performance optimization measures include improving cache hit rates, reducing network requests, and implementing asynchronous processing and batch operations. Security mechanisms include data encryption, identity authentication and authorization, and monitoring and alerting. Improving cache hit rates involves increasing the hit rates of Redis cache and the front-end local cache through appropriate cache strategy design and data prefetching mechanisms.For example, for hot data, an active cache update strategy is implemented to promptly update caches at all levels when data changes. For infrequently accessed data, a lazy loading approach is used to reduce cache resource usage. Network requests are reduced: the front-end local cache handles user requests as much as possible, interacting with the back-end only when necessary. For repetitive queries, data is retrieved directly from the local cache, avoiding frequent requests to the back-end. Asynchronous processing and batch operations are implemented: time-consuming operations (such as data synchronization and complex calculations) are processed asynchronously without blocking the user interface. Furthermore, batch operations are implemented to consolidate multiple small requests into a single large request for processing, reducing network overhead. For example, during data synchronization, multiple operations within a certain period are consolidated into a single batch request and sent to the Redis cache cluster. Data encryption is implemented: data in transit and sensitive data stored in the local cache, Redis cache, and database are encrypted. The transport layer uses TLS 1.3 to ensure data security during network transmission; the storage layer uses high-strength encryption algorithms such as AES-256 to encrypt and store data to prevent data leakage. Identity authentication and authorization utilize multi-factor authentication to ensure only authorized users have access. Furthermore, a role-based access control (RBAC) model provides fine-grained user permission management, ensuring that users with different roles can only access data and functions within their authorized scope. Monitoring and alerting: The monitoring process records and audits all operations, including user login, data access, and data modification. Log analysis enables timely identification of potential security risks and abnormal behavior, allowing appropriate measures to be taken. A top-down analytical model architecture is established, extracting features through historical data, training a baseline model, and using the trained model for real-time predictions. Deviation calculation is then performed, and root cause analysis is conducted based on the deviation results. Optimization recommendations are then made based on the analysis results. An ARIMA (Autoregressive Integrated Moving Average) model is used to establish a normal fluctuation range for each indicator. Association rule mining is used to locate the source of problems, such as discovering a strong correlation between "Redis out of memory" and "increased synchronization failure rate."

[0041] Together, they complete multi-dimensional analysis and anomaly detection. The deployment architecture utilizes a distributed deployment architecture, supporting multi-node and multi-region deployment. The database utilizes a master-slave replication architecture, with the master database responsible for write operations and the slave database for read operations and data backup, improving system availability and performance. The Redis cache cluster utilizes Cluster mode, distributed across multiple nodes, enabling sharded data storage and load balancing. Front-end applications are deployed on edge nodes or user terminals, using a CDN (Content Delivery Network) to accelerate the loading of static resources and improve user access speed. During deployment, flexible configuration options, such as cache capacity, synchronization period, and number of concurrent connections, are provided to meet the needs of different business scenarios, allowing users to adjust them based on their needs. Operations and maintenance management involves establishing a comprehensive operations and maintenance management system, including monitoring and alerting, log analysis, performance tuning, and troubleshooting. The monitoring system collects real-time performance metrics (such as CPU utilization, memory usage, network bandwidth, and cache hit rate) for caches, databases, and servers at all levels. When metrics exceed thresholds, alerts are sent (e.g., SMS, email, WeChat notifications, etc.) to facilitate prompt action by operations and maintenance personnel. The log analysis system centrally manages and analyzes various system logs (such as operation logs, error logs, and synchronization logs). Through log mining, it identifies potential system issues and performance bottlenecks. Based on monitoring data and log analysis results, operations and maintenance personnel perform performance tuning for data caching and batch synchronization, such as adjusting caching strategies, optimizing database queries, and adjusting server resource allocation. Furthermore, they establish troubleshooting processes and knowledge bases to improve troubleshooting efficiency and ensure stable system operation.

[0042] like Figure 9As shown in the figure, this is an architectural diagram. Data changes at the data source layer are synchronized to the Redis cache cluster in real time via the cache synchronization layer. The conflict resolution module also performs version comparisons to resolve potential conflicts. The front-end local cache retrieves data from the Redis cache cluster during initial loading. During user operations, data is tracked through monitoring and categorized by the transaction engine. The synchronization strategy engine dynamically adjusts synchronization. The classification and dynamic synchronization results are passed to the operation classifier for real-time, periodic, and offline operations. Real-time operations are prioritized for synchronization to the Redis cache cluster via a WebSocket channel. Periodic operations are triggered to the Redis cache cluster via a batch synchronization queue. Offline operations are synchronized to the Redis cache cluster via the local transaction log after network recovery. This architectural diagram can be understood as a "command process for data flow and collaboration between caches at different levels." The core problem it addresses is how to efficiently synchronize data between the data source, Redis, and the front-end local cache, while also resolving conflicts and monitoring status. The following section breaks down the role and coordination logic of each process, as shown in Table 4. The overall architecture is divided into five layers, from "data source" to "front-end user operation," with each layer responsible for a different aspect.

[0043] Table 4 Core layers and roles ; Consider the hierarchical collaboration process (taking "user modifying data" as an example). Assuming a user modifies a piece of data on the front-end, the entire process is as follows: A. Front-end local cache → Transaction engine → Operation classifier. When a user modifies data on the front-end page, the data is first stored in the front-end local cache (like a draft box, ensuring offline access). The transaction engine records this operation (generating an operation log to ensure traceability). The operation classifier determines the type of operation: if it's a "real-time operation" (such as a transfer or order submission) → it uses the WebSocket channel (prioritized synchronization to ensure instantaneous effect); if it's a "periodic operation" (such as batch modification of product information) → it enters the batch synchronization queue (scheduled triggering, for example, every 5 minutes); if it's an "offline operation" (modifications made during poor network conditions) → it stores the local transaction log (synchronizes after the network is restored). B. Synchronization strategy engine → Redis cache cluster. The synchronization strategy engine determines when and how to synchronize to Redis based on the operation type and data activity (dynamically adjusting the synchronization cycle): Real-time operations → Immediate synchronization to Redis via WebSocket; Periodic operations → Batch synchronization to Redis upon scheduled time; Offline operations → After the network is restored, data is retrieved from the local transaction log and synchronized to Redis in batches. C. Redis Cache Cluster → Cache Synchronization Layer + Conflict Resolution. After Redis receives data synchronized by the frontend, the cache synchronization layer synchronizes back to the data source (e.g., a database) to ensure consistency between the data source and cached data. If the data in Redis conflicts with data from the data source or other endpoints (e.g., simultaneous modifications to the same record), the conflict resolution process uses "version comparison" (e.g., chained version numbers) to determine which modification is more recent. After resolving the conflict, the data is merged. D. Monitoring → Full-Process Tracking. Monitoring tracks the entire data flow: recording who modified the data and when (transaction engine logs); monitoring the success of Redis synchronization and the effectiveness of conflict resolution; and providing data to operations and maintenance personnel for troubleshooting and optimizing synchronization strategies. The core of this architecture is to allow data to flow intelligently between caches at different levels, front-end local cache → ensure smooth user operations (can be used offline), Redis cluster → accelerate data reading and writing, reduce data source pressure, classification synchronization + policy engine → balance "real-time" and "resource consumption", conflict resolution + monitoring alarm → ensure data consistency, and quickly locate problems. It can be understood as a "data logistics system", the data source is the factory, Redis is the logistics center, the front-end local cache is the express station, the operation classifier is the courier (determines whether it is urgent or slow), the synchronization policy engine is logistics scheduling (determines when to send the vehicle), conflict resolution is customer service (handles delivery conflicts), and monitoring is logistics tracking (see where the package is). The beneficial effects of the present invention include core performance improvement, resource cost optimization, offline capability, enhanced user experience, scalability upgrade, data reliability guarantee and technology ecosystem foresight.Core performance improvements utilize front-end local caching and transaction log preprocessing technologies to significantly optimize the response speed of high-frequency operations, achieving native-like responsiveness. Efficient transaction processing significantly improves the efficiency of complex transaction processing and effectively reduces back-end server load. Furthermore, optimized Redis cache strategies significantly increase cache hit rates, reduce server CPU usage, and achieve efficient utilization of hardware resources. Resource cost optimization significantly reduces the number of deployed back-end servers through deep architectural optimization and resource consolidation, significantly reducing network bandwidth consumption and data center energy consumption, optimizing Power Use Effectiveness (PUE), and effectively controlling operating costs. Offline capabilities include a comprehensive offline operation system that supports long-term offline operations and ensures data consistency. Upon network restoration, the system automatically synchronizes data without manual intervention, ensuring business continuity. User experience enhancements enhance the system's adaptability to offline and weak network environments, significantly improving data transmission reliability and multi-terminal data synchronization efficiency, significantly reducing service interruptions and providing users with a smooth and stable user experience. Scalability upgrades leverage the efficient scalability of Redis clusters to significantly reduce horizontal expansion costs compared to traditional database expansion. At the same time, it supports flexible multi-cloud deployment architecture and further optimizes network resource usage through front-end local caching, reducing cloud service costs. Data reliability is ensured by using the AES-256 high-strength encryption algorithm to store and protect front-end data to prevent data tampering. Combining chained version numbers with transaction log mechanisms effectively resolves distributed data conflict issues. During data transmission, the TLS 1.3 protocol is used to ensure secure and reliable data transmission. A forward-looking technological ecosystem means the system architecture is highly open and compatible, enabling seamless integration with cutting-edge technology scenarios such as edge computing, AI stream computing, and the metaverse, providing solid underlying technical support for innovative applications such as 5G+ Industrial Internet, real-time decision analysis, and high-concurrency virtual interaction.

[0044] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 3 As shown. The computer device includes a processor, a memory and a network interface connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store static information and dynamic information data. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, the steps in the embodiment of the management system data caching and batch synchronization method based on multi-level cache are implemented.

[0045] Those skilled in the art will understand that Figure 3 The structure shown in the figure is merely a block diagram of a portion of the structure related to the solution of the present invention and does not constitute a limitation on the computer device to which the solution of the present invention is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0046] In addition, the present invention also provides a computer device including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the steps in the embodiment of the above-mentioned multi-level cache-based management system data caching and batch synchronization method.

[0047] In addition, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the above-mentioned embodiment of the method for managing system data cache and batch synchronization based on multi-level cache.

[0048] The present invention is not limited to the structures described above and shown in the drawings, and various modifications and changes can be made without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A management system data cache and batch synchronization method based on multi-level cache, characterized in that: include: Based on the pre-built cache architecture, the cache strategy is used to cache the pre-acquired data. Operation data is extracted from the cached data. Local operation processing and operation type determination are performed based on the operation data in combination with the transaction engine and operation classifier. Acquire the storage status data of the cache architecture in real time, optimize the preset synchronization strategy using a decision tree algorithm based on the storage status data and operation type, and perform batch synchronization of data processed by local operations based on the optimized synchronization strategy combined with a chained version number mechanism; Obtain the operating status data of the cache architecture and use the operating status data to build a cache performance indicator system. Based on the cache performance indicator system, combine the autoregressive integral moving average model and association rules to perform storage anomaly detection, and perform data storage alarm processing based on the storage anomaly detection results.

2. The method for managing data cache and batch synchronization based on multi-level cache according to claim 1, characterized in that: The pre-built cache architecture utilizes a cache strategy to cache pre-acquired data, extracts operation data from the cached data, and performs local operation processing and operation type determination based on the operation data in combination with a transaction engine and an operation classifier, including: Based on the pre-built cache architecture and cache strategy, the pre-acquired data is cached in the cache architecture database, key-value storage database and front-end cache in sequence; The operation data is extracted based on the data cached by the front end, and local operation processing and operation type judgment are performed based on the operation data in combination with the transaction engine and operation classifier to obtain the local transaction log and operation type.

3. The method for managing data cache and batch synchronization based on multi-level cache according to claim 2, characterized in that: The pre-built cache architecture combined with the cache strategy sequentially caches the pre-acquired data into the database, key-value storage database, and front-end cache of the cache architecture, including: Based on the pre-built cache architecture, the pre-acquired data is stored in the cache architecture's database, and the database data is replicated to the standby database through master-slave replication. Based on change data capture, the storage data of the standby database is synchronized and stored in the key-value storage database of the cache architecture, and the data shards stored in the key-value storage database are cached in real time at the front end of the cache architecture by pushing real-time changes.

4. The method for managing data cache and batch synchronization based on multi-level cache according to claim 2, characterized in that: The operation data is extracted from the front-end cached data, and local operation processing and operation type judgment are performed based on the operation data in combination with the transaction engine and operation classifier to obtain local transaction logs and operation types including: Extract operation data based on the front-end cached data, perform local operation processing based on the operation data, and record the local operation processing through the transaction engine to obtain a local transaction log; Based on the local transaction log and pre-set operation classification rules, the operation classifier is used to determine the operation type of the operation data.

5. The method for managing data cache and batch synchronization based on multi-level cache according to claim 1, characterized in that: The real-time acquisition of storage status data of the cache architecture, optimization of the preset synchronization strategy using a decision tree algorithm according to the storage status data and the operation type, and batch synchronization of the data processed by the local operation based on the optimized synchronization strategy in combination with the chain version number mechanism include: Acquire the storage status data of the cache architecture in real time, and calculate the synchronization optimization cycle using a linear weighted method based on the storage status data and operation type; Extracting operation feature data based on storage status data and operation type, and using decision tree algorithm combined with operation feature data to optimally screen preset synchronization strategies to obtain the optimal synchronization strategy; The synchronization optimization cycle and the optimal synchronization strategy are integrated to obtain the optimized synchronization strategy. Based on the optimized synchronization strategy and the chain version number mechanism, batch synchronization is performed on the data processed by local operations.

6. The method for managing data cache and batch synchronization based on multi-level cache according to claim 5, characterized in that: The operation characteristic data includes: operation type characteristic data, data activity characteristic data, network quality characteristic data, data sensitivity characteristic data, operation data volume characteristic data and synchronization time characteristic data.

7. The method for managing data cache and batch synchronization based on multi-level cache according to claim 5, characterized in that: The batch synchronization of data processed by local operations based on the optimized synchronization strategy combined with the chain version number mechanism includes: Based on the optimized synchronization strategy and the chain version number mechanism, the data processed by local operations is synchronized and stored in batches to the key-value storage database; Use the optimized synchronization strategy to persist the data stored in batches after synchronization in the key-value storage database to the database.

8. The method for managing data cache and batch synchronization based on multi-level cache according to claim 1, characterized in that: The acquisition of the operating status data of the cache architecture and the use of the operating status data to construct a cache performance indicator system, performing storage anomaly detection based on the cache performance indicator system in combination with an autoregressive integral moving average model and association rules, and performing data storage alarm processing based on the storage anomaly detection results include: Obtain the operational status data of the cache architecture and use it to build a cache performance indicator system; Based on the cache performance indicator system and the autoregressive integral moving average model, the normal fluctuation range of the cache performance indicator is obtained, and the alarm threshold of the cache performance indicator is obtained based on the normal fluctuation range of the cache performance indicator; Use association rules combined with the alarm thresholds of cache performance indicators to detect storage anomalies in the cache architecture, and perform data storage alarm processing based on the storage anomaly detection results.

9. The method for managing data cache and batch synchronization based on multi-level cache according to claim 8, characterized in that: The cache performance indicator system includes: cache performance indicators, transaction processing indicators, synchronization operation indicators and resource utilization indicators; The cache performance indicators include: key-value storage database hit rate, memory fragmentation rate, number of connections, front-end read and write time and cache hit rate; The transaction processing indicators include: transaction success rate, average transaction time, rollback rate and offline transaction backlog; The synchronization operation indicators include: synchronization cycle deviation, data transmission volume, conflict resolution times and push real-time change connection status; The resource utilization indicators include: server or memory utilization, disk utilization, network bandwidth and packet loss rate.

10. A management system data cache and batch synchronization system based on multi-level cache, characterized in that: The management system data cache and batch synchronization system based on multi-level cache includes: a cache processing module, a synchronization processing module and a storage alarm module; The cache processing module is used to cache the pre-acquired data based on the pre-built cache architecture combined with the cache strategy, extract the operation data based on the cached data, and determine the operation type of the operation data through the transaction engine and the operation classifier; The synchronization processing module is used to obtain the storage status data of the cache architecture in real time, optimize the preset synchronization strategy using a decision tree algorithm according to the storage status data and the operation type, and perform batch synchronization processing on the cached data based on the optimized synchronization strategy combined with the chain version number mechanism; The storage alarm module is used to obtain the operating status data of the cache architecture, and use the operating status data to build a cache performance indicator system, perform storage anomaly detection based on the cache performance indicator system combined with the autoregressive integral moving average model and association rules, and perform data storage alarm processing based on the storage anomaly detection results.

Images