A configuration class data caching ORM system

Abstract

The application discloses a kind of configuration class data's cache ORM systems, specifically relates to software application technical field, including cache structure definition module, for by Groovy script configuration class data in relational database is converted into Redis specific data structure;Cache synchronization control module is coupled with the data of cache structure definition module.The application is systematically solved through Vickrey auction mechanism and reverse index incremental update the consistency problem of distributed multi-node concurrent modification cache, eliminates cache surprise group effect;Through alliance chain storage and zero-knowledge proof audit, realize the full-process tamper-proof traceability and privacy protection compliance verification of cache operation;Through the construction of immune network antibody library and complement cascade response, realize the active perception and dynamic defense of cache penetration attack, three big mechanisms work together, reduce development and operation cost, improve the security, credibility and management efficiency of cache system.

Description

Technical Field

[0001] This invention relates to the field of software application technology, and more specifically, to a caching ORM system for configuration data. Background Technology

[0002] In software systems, there is a large amount of configuration data that is read-heavy and write-light, such as permission configurations and process definitions. Cache middleware such as Redis is usually used to improve access performance. Existing technologies have proposed a solution to synchronize database configuration data to Redis and set expiration time according to the update frequency, which simplifies cache management to some extent.

[0003] However, in current technologies, when multiple nodes concurrently modify the same configuration data in a distributed environment, each node simultaneously detects cache invalidation and attempts to update, resulting in the cache thundering herd effect. Existing solutions lack an effective multi-node update arbitration mechanism. Relying on distributed locks or timestamp arbitration will introduce deadlock risks and clock drift problems, and developers need to manually code implementations, making it difficult to guarantee strong cache consistency. The lack of tamper-proof audit and traceability means for cache operations makes it impossible to verify the true consistency with the source database when the cache structure changes, such as adding fields or modifying indexes. It is also difficult to prove the compliance of the operation to third parties without exposing business data, which is especially problematic in multi-organizational collaboration scenarios. The caching layer is vulnerable to penetration attacks. Attackers can use the configuration data key name pattern to make a large number of requests for non-existent data IDs, bypassing the cache and directly attacking the database. Existing technologies do not provide proactive defense mechanisms. Static rate limiting or Bloom filters are difficult to deal with new types of attacks such as variants and low-frequency slow attacks, and cannot achieve attack trapping and evidence preservation. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, the present invention provides a caching ORM system for configuration data to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a caching ORM system for configuration data, comprising: The cache structure definition module is used to convert configuration data in a relational database into a Redis-specific data structure using Groovy scripts. The data structure includes: a data index hash structure with data ID as the key, field encoding as hashKey, and field value as value; a unique index string structure with unique index key as the key and data ID as the value; a normal index set structure with normal index key as the key and data ID set as the value; and a reverse index hash structure with data ID as the key, index name as hashKey, and index value as value. The cache synchronization control module is data-coupled with the cache structure definition module. It is used to achieve automatic synchronization between the cache and the database by listening to the database change log and SQL interceptor, and provides three synchronization modes: pre-caching, on-demand caching, and hybrid strategy. The cache query interface module is connected to the cache structure definition module and the cache synchronization control module. It is used to provide an annotation-based entity definition method, as well as three standard interfaces: primary key query, unique index query, and ordinary index query. It also supports the assembly of multi-object related data through association query annotations and query result optimization mechanisms. The local cache management module is connected to the cache query interface module. It is used to build a three-layer local cache corresponding to the Redis structure, namely, a data content cache, a unique index cache, and a normal index cache, and to realize the synchronous deletion of local caches on multiple nodes through a broadcast mechanism. The cache consistency auction arbitration module, connected to the cache synchronization control module and the local cache management module, is used to encapsulate the cache update requests of each node into auction items when multiple nodes concurrently modify the same configuration data in a distributed manner. Based on the Vickrey auction mechanism, a unique winning node is determined to execute the cache update, while the remaining nodes receive an invalidation notification. The valuation function of the auction item is jointly constructed by four-dimensional parameters: node load weight, network latency, data change priority, and transaction commit timestamp. The blockchain traceability and evidence storage module is connected to the cache consistency auction arbitration module. It is used to write the Groovy script version number, change operation type, operation timestamp, execution node identifier and auction winning result of each cache structure change into the private data set of the lightweight consortium chain, and automatically trigger the cache structure consistency verification across organizational nodes through smart contracts. An immune network defense module, connected to the cache query interface module, is used to simulate the antigen recognition mechanism of a biological immune system to detect anomalies in cache query requests. The immune network defense module includes: an antibody library built based on normal query patterns; an affinity calculation unit for calculating the affinity between the query request and each pattern in the antibody library; and an immune response unit that marks the query request as a suspected cache penetration attack and activates a complement cascade response when the affinity is lower than a preset threshold. The complement cascade response includes: dynamically generating fake data bait and injecting it into Redis; triggering the cache consistency auction arbitration module to isolate and vote on the attack source node; and submitting attack evidence hashes to the blockchain traceability and evidence storage module.

[0006] Preferably, the execution flow of the Vickrey auction mechanism in the cache consistency auction arbitration module includes: When each competing node detects a local cache invalidation event for the same data ID, it submits a sealed bid to the auction coordinator. The sealed bid contains the node's private cost estimate for performing this cache update operation. After all bids have been received, the auction coordinator publicly announces the second lowest bid as the uniform liquidation price and grants the cache update execution right to the node with the lowest bid, while requiring that node to execute the update at the resource cost corresponding to the second lowest bid. After the winning node performs the cache update, it submits an update completion certificate to the auction coordinator. After the auction coordinator verifies the certificate, it broadcasts a cache invalidation instruction with a digital signature to the other bidding nodes. The digital signature is asymmetrically encrypted using the node public key certificate maintained by the blockchain traceability and evidence storage module.

[0007] Preferably, the smart contract of the blockchain traceability and evidence storage module includes: The structural version consistency verification contract is used to automatically compare the Merkle root hash of the changeset recorded on the consortium blockchain with the locally calculated value when any organization node loads a new Groovy script changeset. If they are inconsistent, the loading will be refused and an alarm will be triggered. The cache operation audit contract is used to record each auction result and corresponding data change content of the cache consistency auction arbitration module, generate an immutable operation log tree, and support cross-organization audit queries based on zero-knowledge proofs, enabling auditors to verify operation compliance without exposing specific configuration data content.

[0008] Preferably, the method for constructing the antibody library of the immune network defense module includes: During the system cold start phase, normal cached query request samples within a preset period are collected, and query frequency patterns, key name space distribution features, related query depth, and result set size distribution are extracted as antigen feature vectors. The antigen feature vector is trained for affinity maturation using a clonal selection algorithm to generate antibody memory cell populations covering different query scenarios. The receptor editing operation of the antibody memory cell populations adopts a simulated annealing strategy to optimize the matching and generalization ability of antibodies and antigens. The antibody library supports online incremental learning: when the affinity calculation unit determines that a query is a normal request but its affinity is lower than the average affinity of the existing antibody population, it triggers a somatic high-frequency mutation mechanism, using the feature vector of the query as a neoantigen to stimulate the evolution of the antibody library.

[0009] Preferably, when data changes, the cache synchronization control module performs incremental index updates based on the reverse index hash structure, including: Based on the data ID of the changed data, the relevant index name and corresponding old index value are retrieved from the reverse index hash structure; Based on the old index value, delete the data ID from the corresponding unique index string structure or ordinary index set structure; A new index value is generated based on the new content of the changed data, and the data ID is inserted into the index structure corresponding to the new index value; The incremental update operation must pass the auction admission verification of the cache consistency auction arbitration module before execution. The deletion and insertion operations can only be executed when the auction coordinator confirms that the current node has the right to update the cache shard corresponding to the data ID.

[0010] Preferably, the Groovy script supports dynamic management of the cache structure, including: When the service starts, a cache structure is built into memory. The changeset that has not been updated is detected by the version number. An incremental update interface for adding fields and indexes is provided. During a full refresh, only the newly added fields or indexes are updated locally, without affecting historical data nodes. During the version number detection process, the blockchain traceability and evidence storage module performs digital signature verification on each release of the changeset. After successful verification, the metadata and signature result of the changeset are written into the consortium blockchain. Each node must obtain and verify the digital signature from the consortium blockchain before loading the changeset.

[0011] Preferably, the pre-caching mode specifically includes: When the service starts, all configuration data is loaded into Redis without setting an expiration time. Incremental changes are obtained by subscribing to the database change log. Depending on the type of the changed field, the data index hash key-value pair update is performed, or the corresponding index structure is located and updated based on the reverse index. After the full load is completed, the immune network defense module performs baseline learning on the query requests during the loading process to generate the initial population of the antibody library. At the same time, the cache consistency auction arbitration module auctions and arbitrates concurrent full load requests caused by multiple nodes starting simultaneously, allowing only a single node to perform a full load and broadcast the snapshot hash of the completed load to the other nodes.

[0012] Preferably, the on-demand caching mode specifically includes: Only the cache structure is built into memory when the service starts; When querying, first access Redis; if no match is found, query the database and write the result to Redis, while setting a default expiration time of 10 minutes. When data changes, the cache is deleted by the SQL interceptor in the post-transaction commit phase, and a second deletion is performed by subscribing to the database change log to avoid inconsistency between the cache and the database; When the SQL interceptor intercepts an SQL operation to delete the cache, it simultaneously submits the operation fingerprint to the immune network defense module. The immune response unit determines whether the deletion operation belongs to an abnormally high-frequency deletion mode based on the matching result of the operation fingerprint and the antibody library. If so, it suppresses the deletion operation and triggers the complement cascade response.

[0013] Preferably, the cache query interface module employs a query result optimization mechanism when performing related queries. When multiple rows of data in the batch query results need to be associated with the same target object and the associated field values ​​are the same, the query result optimization mechanism is configured to: obtain the complete data of the target object only during the first query and generate a reference identifier pointing to the complete data for subsequent rows; the application end assembles the results directly from the obtained complete data based on the reference identifier, thereby reducing the amount of data transmitted over the network and the number of accesses to Redis. The generation rules of the reference identifier are uniformly managed by the global reference identifier allocation contract maintained by the blockchain traceability and evidence storage module, ensuring that there are no conflicts in the reference identifiers generated by each node in the distributed environment; and the validity period of the reference identifier is bound to the auction cycle of the most recent data shard to which the target object belongs by the cache consistency auction arbitration module, and it automatically expires after the auction cycle ends.

[0014] Preferably, the cache synchronization mechanism of the local cache management module includes: When data changes occur at any service node, all service nodes are notified via message broadcast, and the three-layer structure of data content cache, unique index cache and ordinary index cache corresponding to the changed data in their local cache is deleted synchronously to maintain strong cache consistency among multiple nodes. Among them, objects allowed to be stored in the local cache are restricted through a whitelist mechanism, and pre-conversion methods are provided for these objects to cache pre-computation results; The message broadcast uses the digital signature of the winning node in the cache consistency auction arbitration module as the message authentication code. Before deleting the local cache, the receiving node must verify the validity of the digital signature and the node's identity as the winner in the current auction period through the blockchain traceability and evidence storage module. If the verification fails, the broadcast message is submitted to the immune network defense module for abnormal behavior analysis and triggers the cross-node cache state consistency repair process.

[0015] The technical effects and advantages of this invention are as follows: By combining the Vickrey auction mechanism with incremental updates using reverse indexes, the cache consistency problem when multiple nodes concurrently modify the same configuration data in a distributed environment is fundamentally solved. This eliminates the performance bottlenecks and deadlock risks associated with traditional solutions that rely on distributed locks or timestamp arbitration. By introducing the Vickrey auction mechanism from economics into the competition for cache update rights, each node calculates its private cost estimate based on four parameters: its own load weight, network latency, data change priority, and transaction commit timestamp, and then submits a sealed bid. The auction coordinator uses the second-lowest bid as the unified liquidation price to determine the only winning node to execute the update, while the remaining nodes passively receive failure notifications. This not only ensures the atomicity and consistency of cache updates but also incentivizes each node to bid truthfully through the second-lowest bid, naturally suppressing malicious price gouging or low-price preemption. At the same time, when data changes, the affected index is accurately located based on the reverse index hash structure, and incremental updates are executed. Before the update, an auction admission verification must be passed to ensure that only the winning node has the right to modify the corresponding cache shard. This transforms distributed cache consistency maintenance from manual coding to automatic arbitration, completely avoiding the risk of data inconsistency and significantly reducing system development and maintenance costs. By deeply integrating consortium blockchain notarization with zero-knowledge proof auditing, this system achieves, for the first time, end-to-end immutable traceability and privacy-protected compliance verification of configuration data caching operations. This fills a technological gap in the auditing and tracing field of caching systems. By writing each Groovy script version change, auction winning result, node identifier, and operation timestamp into the private data set of a lightweight consortium blockchain, and automatically comparing the Merkle root hash before and after the change through a structure version consistency verification contract, loading is immediately rejected and an alarm is triggered if an inconsistency is found. The caching operation audit contract generates an immutable operation log tree, supporting cross-organizational audit queries based on zero-knowledge proofs. Auditors can verify operation compliance without obtaining specific configuration data content. The system links the settlement price of the auction module with the gas fee mechanism and uses attack evidence from the immune module as the basis for penalties, forming a closed-loop trusted governance system of consensus, notarization, auditing, and punishment. This gives the caching system anti-tampering and privacy protection capabilities that traditional database audit logs cannot match. By constructing an antibody library and complement cascade response mechanism that simulates a biological immune system, this invention achieves proactive perception, accurate identification, and dynamic defense against cache penetration attacks, significantly improving the security resilience of the cache layer. During the cold start phase, multidimensional features of normal query requests are collected as antigen feature vectors. A clonal selection algorithm and simulated annealing strategy are used to train antibody memory cell populations covering different query scenarios. The antibody library is continuously evolved through online incremental learning and a somatic cell high-frequency mutation mechanism. An affinity calculation unit evaluates the matching degree between each query request and the antibody library in real time. Once the affinity falls below a preset threshold, it is identified as a suspected cache penetration attack, and the complement cascade response is immediately activated: a fake decoy with the same format as real data is dynamically generated and injected into Redis to consume attack resources; an isolation vote is sent to the auction arbitration module to disqualify the attacking node from subsequent auctions; and the attack evidence is hashed and stored on the blockchain for legal prosecution. This invention also extends this defense mechanism to cache deletion operations. By comparing operation fingerprints, abnormal high-frequency deletion patterns are identified and suppressed. This effectively resists unknown attack patterns without harming normal queries, significantly reducing the risk of database overload caused by malicious penetration of the cache system. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the system structure of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] I. System Overall Architecture This system includes a cache structure definition module, a cache synchronization control module, a cache query interface module, a local cache management module, a cache consistency auction arbitration module, a blockchain traceability and evidence storage module, and an immune network defense module. The first four modules realize basic data structure transformation, synchronization, query, and local acceleration, while the latter three modules together constitute a trusted cache governance mechanism.

[0019] II. Implementation of the Cache Structure Definition Module The cache structure definition module uses Groovy scripts to convert configuration data from relational databases into four specific data structures in Redis.

[0020] The data structure includes: a data index hash structure with data ID as key, field code as hashKey, and field value as value, used to store the complete content of the record; a unique index string structure with unique index key as key and data ID as value, used to support fast querying with unique constraints; a normal index set structure with normal index key as key and data ID set as value, used to support batch querying with non-unique conditions; and a reverse index hash structure with data ID as key, index name as hashKey, and index value as value, used to quickly locate and clean up all indexes associated with the record when data changes.

[0021] When generating a Redis key, the module uses preset abbreviation rules to convert table names, index names, and field names into single-byte characters, concatenating them with uppercase letters, lowercase letters, or numbers to reduce the storage space occupied by the cache key. These abbreviation rules can be defined through a configuration file.

[0022] III. Implementation of the Cache Synchronization Control Module The cache synchronization control module achieves automatic synchronization between the cache and the database by listening to database change logs such as MySQL Binlog and SQL interceptors, and provides three synchronization modes: pre-caching, on-demand caching, and hybrid strategy.

[0023] Pre-caching mode: When the service starts, all configuration data is loaded into Redis without setting an expiration time; incremental changes are obtained by subscribing to the database change log, and the hash key-value pair update of the data index is performed according to the type of the changed field, or the corresponding unique index or ordinary index structure is located and updated according to the reverse index; this mode is suitable for configuration data that is frequently queried and rarely updated.

[0024] On-demand caching mode: When the service starts, only the cache structure is built into memory; when querying, Redis is accessed first, and if no match is found, the database is queried and the result is written to Redis, while a default expiration time of 10 minutes is set; when data changes, the cache is deleted in the post-transaction commit phase through an SQL interceptor, and a second deletion is performed by subscribing to the database change log to avoid inconsistency between the cache and the database.

[0025] Hybrid strategy mode: Data is marked as hot data by attributes added in Groovy scripts; pre-caching mode is used for data marked as hot data, while on-demand caching mode is used for other data not marked as hot data. The system can dynamically adjust the hot data marking based on runtime access frequency.

[0026] Incremental index update: When data changes, the following steps are performed based on the reverse index hash structure: Query the relevant index name and corresponding old index value from the reverse index according to the data ID of the changed data; delete the data ID from the corresponding unique index string structure or ordinary index set structure according to the old index value; generate a new index value according to the new content of the changed data, and insert the data ID into the index structure corresponding to the new index value.

[0027] IV. Implementation of the Cache Query Interface Module The cache query interface module provides an annotation-based entity definition method, as well as three standard interfaces: primary key query, unique index query, and ordinary index query. It also supports the assembly of multi-object related data through association query annotations and query result optimization mechanisms.

[0028] Optimized join queries: When multiple rows of data in the batch query results need to be associated with the same target object and the values ​​of the associated fields are the same, the complete data of the target object is only obtained in the first query, and a reference identifier pointing to the complete data is generated for subsequent rows; the application end assembles the results directly from the obtained complete data according to the reference identifier, thereby reducing the amount of data transmitted over the network and the number of accesses to Redis.

[0029] Multi-deployment mode adaptation: When Redis is deployed as a Sentinel or master-slave architecture, queries are executed using Lua scripts pre-loaded onto the Redis server. These Lua scripts encode query conditions, result columns, and related object information into a parameter set according to fixed rules, completing multi-level index queries and related data assembly on the server in a single request. When Redis is deployed in cluster mode, a combination of Pipeline and batch operations is used, executing multiple queries step-by-step to complete data assembly.

[0030] V. Implementation of the Local Cache Management Module The local cache management module constructs a three-layer local cache corresponding to the Redis structure: a data content cache, a unique index cache, and a regular index cache. Queries prioritize accessing the local cache; if a match is found, the query is returned directly.

[0031] Cache synchronization mechanism: When data changes occur on any service node, all service nodes are notified via message broadcast. Simultaneously, the three layers of cache corresponding to the changed data—data content cache, unique index cache, and ordinary index cache—are deleted from their local caches to maintain strong cache consistency across multiple nodes. Objects allowed to be stored in the local cache are restricted through a whitelist mechanism, and pre-transformation methods are provided for these objects to cache pre-computed results.

[0032] VI. Implementation of the Cache Consistency Auction Arbitration Module The cache consistency auction arbitration module is used to encapsulate the cache update requests of each node as auction targets when multiple nodes in a distributed system concurrently modify the same configuration data. Based on the Vickrey auction mechanism, a unique winning node is determined to execute the cache update, and the remaining nodes receive the invalidation notification.

[0033] The valuation function for the auctioned item is jointly constructed by four parameters: node load weight, network latency, data change priority, and transaction commit timestamp. Specifically, each competing node calculates a private cost valuation based on its current CPU load, network round-trip latency, the business priority of the data to be changed, and the order of transaction commits, and submits it as a sealed bid.

[0034] The execution process of the Vickrey auction mechanism is as follows: When each competing node detects a local cache invalidation event with the same data ID, it submits a sealed bid to the auction coordinator. After all bids have been received, the auction coordinator publicly announces the second lowest bid as the unified liquidation price and grants the cache update execution right to the node with the lowest bid, while requiring that node to execute the update at the resource cost corresponding to the second lowest bid. After executing the cache update, the winning node submits an update completion certificate to the auction coordinator. After the auction coordinator verifies the certificate, it broadcasts a cache invalidation instruction with a digital signature to the remaining bidding nodes. The digital signature is asymmetrically encrypted using the node public key certificate maintained by the blockchain traceability and evidence storage module.

[0035] Before the incremental index update operation is executed, the auction admission verification of the cache consistency auction arbitration module must be passed. The deletion and insertion operations can only be executed when the auction coordinator confirms that the current node has the right to update the cache shard corresponding to the data ID.

[0036] VII. Implementation of the Blockchain Traceability and Evidence Preservation Module The blockchain traceability and evidence storage module writes the Groovy script version number, change operation type, operation timestamp, execution node identifier, and auction winning result of each cache structure change into the private data set of the lightweight consortium blockchain; the private data set adopts a channel isolation mechanism, and only grants query permissions to cache management nodes that have passed identity authentication.

[0037] The smart contracts for this module include a structure version consistency verification contract and a cache operation audit contract. The structure version consistency verification contract is used to automatically compare the Merkle root hash of the new Groovy script changeset recorded on the consortium blockchain with the locally calculated value when any organization node loads the changeset. If they are inconsistent, the loading will be rejected and an alarm will be triggered. The cache operation audit contract is used to record the auction results and corresponding data changes of the cache consistency auction arbitration module, generate an immutable operation log tree, and support cross-organization audit queries based on zero-knowledge proofs, enabling auditors to verify operational compliance without exposing specific configuration data content.

[0038] Groovy scripts support dynamic management of cache structures: when the service starts, the cache structure is built into memory, and the version number is used to detect unupdated changesets. Incremental update interfaces for adding fields and indexes are provided, and during a full refresh, only the newly added fields or indexes are partially updated without affecting historical data nodes. During the version number detection process, the blockchain traceability and evidence storage module performs digital signature verification on each release of the changeset. After successful verification, the metadata and signature results of the changeset are written to the consortium blockchain. Each node must obtain and verify the digital signature from the consortium blockchain before loading the changeset.

[0039] VIII. Implementation of the Immune Network Defense Module The immune network defense module simulates the antigen recognition mechanism of the biological immune system to detect anomalies in cached query requests. This module includes an antibody library built based on normal query patterns, an affinity calculation unit for calculating the affinity between the query request and each pattern in the antibody library, and an immune response unit that marks the query request as a suspected cache penetration attack and activates the complement cascade response when the affinity is lower than a preset threshold.

[0040] The antibody library construction method is as follows: During the system cold start phase, normal cached query request samples within a preset period are collected, and query frequency patterns, key name space distribution features, associated query depth, and result set size distribution are extracted as antigen feature vectors. The antigen feature vectors are then trained for affinity maturation using a clonal selection algorithm to generate antibody memory cell populations covering different query scenarios. The receptor editing operation of the antibody memory cell populations uses a simulated annealing strategy to optimize the matching and generalization ability between antibodies and antigens. The antibody library supports online incremental learning: when the affinity calculation unit determines that a query is a normal request but its affinity is lower than the average affinity of the existing antibody population, a somatic high-frequency mutation mechanism is triggered, and the feature vector of the query is used as a new antigen to stimulate the evolution of the antibody library.

[0041] The complement cascade response includes: dynamically generating fake data bait and injecting it into Redis, triggering the cache consistency auction arbitration module to isolate and vote on the attack source node, and submitting the attack evidence hash to the blockchain traceability and evidence storage module.

[0042] In the on-demand caching mode, when the SQL interceptor intercepts an SQL operation to delete the cache, it simultaneously submits the operation fingerprint to the immune network defense module, including the hash value of the SQL statement, the execution timestamp, and the current auction round number. The immune response unit determines whether the deletion operation belongs to an abnormally high-frequency deletion mode based on the matching result of the operation fingerprint and the antibody library. If so, it suppresses the deletion operation and triggers the complement cascade response.

[0043] IX. Further Collaboration Between Related Queries and Local Caching In the related query, the generation rules of the reference identifier are uniformly managed by the global reference identifier allocation contract maintained by the blockchain traceability and evidence storage module, ensuring that there are no conflicts in the reference identifiers generated by each node in the distributed environment; and the validity period of the reference identifier is bound to the auction period of the data shard to which the target object belongs in the most recent auction by the cache consistency auction arbitration module, and it automatically expires after the auction period ends.

[0044] The message broadcast of the local cache management module uses the digital signature of the winning node in the cache consistency auction arbitration module as the message authentication code. Before deleting the local cache, the receiving node must verify the validity of the digital signature and the identity of the winning node in the current auction period through the blockchain traceability and evidence storage module. If the verification fails, the broadcast message is submitted to the immune network defense module for abnormal behavior analysis and triggers the cross-node cache state consistency repair process.

[0045] 10. Example of the overall system workflow When configuration data changes, the cache synchronization control module first detects the change event. Multiple service nodes concurrently detect local cache invalidation, triggering the cache consistency auction arbitration module to execute a Vickrey auction to determine a single winning node. The winning node performs an incremental update based on the reverse index hash structure, writes the update result to Redis, and submits the change record and auction result to the blockchain traceability and evidence storage module for on-chain storage. Subsequently, the winning node broadcasts a cache invalidation command, and other nodes delete their local cache after verifying the digital signature. During this process, if a malicious node initiates a large number of invalid key queries, the immune network defense module identifies the anomaly through affinity detection, activates the complement cascade response, generates false decoys, isolates attacking nodes, and stores the results on the blockchain. The entire operation chain can be audited using zero-knowledge proofs to ensure the consistency and trustworthiness of cached data.

[0046] Through the above implementation methods, those skilled in the art can implement the configuration data caching ORM system protected by this invention and understand its technical effects: simplifying distributed cache consistency maintenance, providing tamper-proof audit traceability, proactively defending against cache layer attacks, and improving the overall efficiency and security of configuration data caching.

[0047] Finally, it should be noted that the accompanying drawings of the embodiments disclosed in this invention only involve the structures involved in the embodiments disclosed in this invention. Other structures can refer to the general design. In the absence of conflict, the same embodiment and different embodiments of this invention can be combined with each other. In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A caching ORM system for configuration data, characterized in that, include: The cache structure definition module is used to convert configuration data in a relational database into a Redis-specific data structure using Groovy scripts. The data structure includes: a data index hash structure with data ID as the key, field encoding as hashKey, and field value as value; a unique index string structure with unique index key as the key and data ID as the value; a normal index set structure with normal index key as the key and data ID set as the value; and a reverse index hash structure with data ID as the key, index name as hashKey, and index value as value. The cache synchronization control module is data-coupled with the cache structure definition module. It is used to achieve automatic synchronization between the cache and the database by listening to the database change log and SQL interceptor, and provides three synchronization modes: pre-caching, on-demand caching, and hybrid strategy. The cache query interface module is connected to the cache structure definition module and the cache synchronization control module. It is used to provide an annotation-based entity definition method, as well as three standard interfaces: primary key query, unique index query, and ordinary index query. It also supports the assembly of multi-object related data through association query annotations and query result optimization mechanisms. The local cache management module is connected to the cache query interface module. It is used to build a three-layer local cache corresponding to the Redis structure, namely, a data content cache, a unique index cache, and a normal index cache, and to realize the synchronous deletion of local caches on multiple nodes through a broadcast mechanism. The cache consistency auction arbitration module, connected to the cache synchronization control module and the local cache management module, is used to encapsulate the cache update requests of each node into auction items when multiple nodes concurrently modify the same configuration data in a distributed manner. Based on the Vickrey auction mechanism, a unique winning node is determined to execute the cache update, while the remaining nodes receive an invalidation notification. The valuation function of the auction item is jointly constructed by four-dimensional parameters: node load weight, network latency, data change priority, and transaction commit timestamp. The blockchain traceability and evidence storage module is connected to the cache consistency auction arbitration module. It is used to write the Groovy script version number, change operation type, operation timestamp, execution node identifier and auction winning result of each cache structure change into the private data set of the lightweight consortium chain, and automatically trigger the cache structure consistency verification across organizational nodes through smart contracts. An immune network defense module, connected to the cache query interface module, is used to simulate the antigen recognition mechanism of a biological immune system to detect anomalies in cache query requests. The immune network defense module includes: an antibody library built based on normal query patterns; an affinity calculation unit for calculating the affinity between the query request and each pattern in the antibody library; and an immune response unit that marks the query request as a suspected cache penetration attack and activates a complement cascade response when the affinity is lower than a preset threshold. The complement cascade response includes: dynamically generating fake data bait and injecting it into Redis; triggering the cache consistency auction arbitration module to isolate and vote on the attack source node; and submitting attack evidence hashes to the blockchain traceability and evidence storage module.

2. The ORM system for caching configuration data according to claim 1, characterized in that, The execution flow of the Vickrey auction mechanism in the cache consistency auction arbitration module includes: When each competing node detects a local cache invalidation event for the same data ID, it submits a sealed bid to the auction coordinator. The sealed bid contains the node's private cost estimate for performing this cache update operation. After all bids have been received, the auction coordinator publicly announces the second lowest bid as the uniform liquidation price and grants the cache update execution right to the node with the lowest bid, while requiring that node to execute the update at the resource cost corresponding to the second lowest bid. After the winning node performs the cache update, it submits an update completion certificate to the auction coordinator. After the auction coordinator verifies the certificate, it broadcasts a cache invalidation instruction with a digital signature to the other bidding nodes. The digital signature is asymmetrically encrypted using the node public key certificate maintained by the blockchain traceability and evidence storage module.

3. The ORM system for caching configuration data according to claim 1, characterized in that, The smart contract of the blockchain traceability and evidence storage module includes: The structural version consistency verification contract is used to automatically compare the Merkle root hash of the changeset recorded on the consortium blockchain with the locally calculated value when any organization node loads a new Groovy script changeset. If they are inconsistent, the loading will be refused and an alarm will be triggered. The cache operation audit contract is used to record each auction result and corresponding data change content of the cache consistency auction arbitration module, generate an immutable operation log tree, and support cross-organization audit queries based on zero-knowledge proofs, enabling auditors to verify operation compliance without exposing specific configuration data content.

4. The ORM system for caching configuration data according to claim 1, characterized in that, The method for constructing the antibody library of the immune network defense module includes: During the system cold start phase, normal cached query request samples within a preset period are collected, and query frequency patterns, key name space distribution features, related query depth, and result set size distribution are extracted as antigen feature vectors. The antigen feature vector is trained for affinity maturation using a clonal selection algorithm to generate antibody memory cell populations covering different query scenarios. The receptor editing operation of the antibody memory cell populations adopts a simulated annealing strategy to optimize the matching and generalization ability of antibodies and antigens. The antibody library supports online incremental learning: when the affinity calculation unit determines that a query is a normal request but its affinity is lower than the average affinity of the existing antibody population, it triggers a somatic high-frequency mutation mechanism, using the feature vector of the query as a neoantigen to stimulate the evolution of the antibody library.

5. A caching ORM system for configuration data according to claim 1, characterized in that, When data changes, the cache synchronization control module performs incremental index updates based on the reverse index hash structure, including: Based on the data ID of the changed data, the relevant index name and corresponding old index value are retrieved from the reverse index hash structure; Based on the old index value, delete the data ID from the corresponding unique index string structure or ordinary index set structure; A new index value is generated based on the new content of the changed data, and the data ID is inserted into the index structure corresponding to the new index value; The incremental update operation must pass the auction admission verification of the cache consistency auction arbitration module before execution. The deletion and insertion operations can only be executed when the auction coordinator confirms that the current node has the right to update the cache shard corresponding to the data ID.

6. A caching ORM system for configuration data according to claim 1, characterized in that, The Groovy script supports dynamic management of cache structures, including: When the service starts, a cache structure is built into memory. The changeset that has not been updated is detected by the version number. An incremental update interface for adding fields and indexes is provided. During a full refresh, only the newly added fields or indexes are updated locally, without affecting historical data nodes. During the version number detection process, the blockchain traceability and evidence storage module performs digital signature verification on each release of the changeset. After successful verification, the metadata and signature result of the changeset are written into the consortium blockchain. Each node must obtain and verify the digital signature from the consortium blockchain before loading the changeset.

7. A configuration data caching ORM system according to claim 1, characterized in that, The pre-caching mode specifically includes: When the service starts, all configuration data is loaded into Redis without setting an expiration time. Incremental changes are obtained by subscribing to the database change log. Depending on the type of the changed field, the data index hash key-value pair update is performed, or the corresponding index structure is located and updated based on the reverse index. After the full load is completed, the immune network defense module performs baseline learning on the query requests during the loading process to generate the initial population of the antibody library. At the same time, the cache consistency auction arbitration module auctions and arbitrates concurrent full load requests caused by multiple nodes starting simultaneously, allowing only a single node to perform a full load and broadcast the snapshot hash of the completed load to the other nodes.

8. A configuration data caching ORM system according to claim 1, characterized in that, The on-demand caching mode specifically includes: The service only builds the cache structure into memory when it starts up; When querying, first access Redis; if no match is found, query the database and write the result to Redis, while setting a default expiration time of 10 minutes. When data changes, the cache is deleted by the SQL interceptor in the post-transaction commit phase, and a second deletion is performed by subscribing to the database change log to avoid inconsistency between the cache and the database; When the SQL interceptor intercepts an SQL operation to delete the cache, it simultaneously submits the operation fingerprint to the immune network defense module. The immune response unit determines whether the deletion operation belongs to an abnormally high-frequency deletion mode based on the matching result of the operation fingerprint and the antibody library. If so, it suppresses the deletion operation and triggers the complement cascade response.

9. A configuration data caching ORM system according to claim 1, characterized in that, When performing related queries, the cache query interface module employs a query result optimization mechanism. When multiple rows of data in the batch query results need to be associated with the same target object and the associated field values ​​are the same, the query result optimization mechanism is configured to: obtain the complete data of the target object only during the first query and generate a reference identifier pointing to the complete data for subsequent rows; the application end assembles the results directly from the obtained complete data based on the reference identifier, thereby reducing the amount of data transmitted over the network and the number of accesses to Redis. The generation rules of the reference identifier are uniformly managed by the global reference identifier allocation contract maintained by the blockchain traceability and evidence storage module, ensuring that there are no conflicts in the reference identifiers generated by each node in the distributed environment; and the validity period of the reference identifier is bound to the auction cycle of the most recent data shard to which the target object belongs by the cache consistency auction arbitration module, and it automatically expires after the auction cycle ends.

10. A caching ORM system for configuration data according to claim 1, characterized in that, The cache synchronization mechanism of the local cache management module includes: When data changes occur at any service node, all service nodes are notified via message broadcast, and the three-layer structure of data content cache, unique index cache and ordinary index cache corresponding to the changed data in their local cache is deleted synchronously to maintain strong cache consistency among multiple nodes. Among them, objects allowed to be stored in the local cache are restricted through a whitelist mechanism, and pre-conversion methods are provided for these objects to cache pre-computation results; The message broadcast uses the digital signature of the winning node in the cache consistency auction arbitration module as the message authentication code. Before deleting the local cache, the receiving node must verify the validity of the digital signature and the node's identity as the winner in the current auction period through the blockchain traceability and evidence storage module. If the verification fails, the broadcast message is submitted to the immune network defense module for abnormal behavior analysis and triggers the cross-node cache state consistency repair process.

Images