Redis cache management method and device, computer device and storage medium

Abstract

The present application relates to the technical field of database synchronization and distributed cache, and particularly relates to a Redis cache management method and device, computer equipment and a storage medium, the method comprising: a database write operation is encapsulated as a signed domain event and synchronized into an event bus; events are sequentially aggregated as event blocks and written into a data lake, a polynomial commitment is calculated and copied to a decentralized storage; after a root commitment is verified by a cache node, the events are replayed, written into Redis according to a conflict-free replicated data type merge algorithm, and migrated and refreshed according to key heat and a random challenge value; each node locally trains a prediction model through federated learning, updates weights after homomorphic encryption of gradients, generates a model hash and a root commitment digest, writes a chain through zero-knowledge proof and writes back a log, and high consistency, low latency, verifiable and privacy-safe management of the cache are achieved.

Description

Technical Field

[0001] This invention relates to the field of database synchronization and distributed caching technology, and in particular to methods, apparatus, computer equipment and storage media for Redis cache management. Background Technology

[0002] Redis, as a high-throughput, low-latency key-value database, has become an important component for internet businesses to accelerate read and write operations and smooth traffic spikes. With the continuous growth of scenarios such as online transactions, real-time recommendations, and log analysis, the capacity and concurrency of a single Redis node are often insufficient to meet the demands of massive writes and hotspot migration. The industry generally adopts a three-layer architecture of "database + message queue + cache" to maintain consistency.

[0003] However, existing technologies largely rely on binary log parsing or periodic incremental fetching: changes are pushed to the cache by parsing the binary logs of the main database; due to the coupling of log format with database version, upgrades can cause parser failure, and latency is easily affected by network jitter; applications simultaneously write to the database, write to the cache, or refresh via failure signals; write paths are lengthy and transactions are fragmented, making dirty writes and cache penetration likely; they mostly rely on passive monitoring methods to count QPS, and then manually adjust sharding or hotkey routing; governance lag leads to single-point overload; some systems attempt to use centralized prediction models to pre-warm keys, but the training center holds complete access logs, posing a data leakage risk, and model updates lack publicly verifiable processes; the combination of these factors results in unprovable consistency, slow governance response, and weak privacy compliance. Summary of the Invention

[0004] To address the numerous problems existing in the prior art, this invention provides a method, apparatus, computer device, and storage medium for Redis cache management. This invention encapsulates database write operations as signed domain events and generates random challenge values. Event streams are sequentially aggregated into event blocks and written to the data lake, with root commitments calculated using multinomial commitments. After verifying the root commitment, cache nodes replay the events and write them to Redis using a conflict-free copy data type merging algorithm. Shards are then migrated based on real-time key popularity, and random challenge values ​​are refreshed. Subsequently, a federated learning framework is used to aggregate gradients and update the prediction model using homomorphic encryption and differential privacy, generating a digest chain-like write chain, forming a data-governance-verification closed loop.

[0005] A method for Redis cache management includes:

[0006] Intercept database write operations at the object-relational mapping layer, extract entity identifiers, operation types, change fields, data mode versions and hybrid logical clock timestamps, encapsulate them into domain events with digital signatures, generate random challenge values, and submit the domain events and corresponding database transactions to the event bus through distributed transactions;

[0007] The domain events are aggregated in the order of receipt and written into a consistent data log as event blocks. An integrity commitment is calculated for the event blocks and a root commitment is generated. The root commitment and a random challenge value are written into the log metadata, and the event blocks are copied to decentralized storage.

[0008] On the cache node, the event log is verified based on the root commitment and random challenge value. After consuming the event block, the convergence state mapping is generated and written to Redis using the conflict free copy data type merging algorithm. The shard migration and random challenge value refresh are performed based on the real-time key heat.

[0009] Based on key heat and root commitment, a distributed model is used to train and predict the prefetched key set and preheat it in the cache copy. The local gradient is homomorphically encrypted and differential privacy noise is added before participating in secure aggregation to update the distributed model parameters. The updated model hash and root commitment are used to generate a digest, which is written to the distributed ledger through a verifiable proof mechanism and synchronized to the data log closed loop.

[0010] Preferably, the domain events are aggregated into an event block according to a preset number of consecutive submissions, and the start submission number and end submission number are recorded for each event block before writing to the consistency data log.

[0011] Preferably, the integrity commitment is obtained by performing a polynomial mapping on the hash values ​​of all domain events in an event block to obtain a block-level commitment, and then performing a polynomial aggregation on all block-level commitments in the order of event block indexes to generate the root commitment.

[0012] Preferably, the conflict-free copy data type merging algorithm, when concurrent modifications exist on the same key, overwrites older modifications with newer modifications using mixed logical clock timestamps, and maintains the union of uncovered fields.

[0013] Preferably, the key heat is obtained by multiplying the key access frequency and key access latency by weights and then summing them. When the key heat reaches a threshold, the shard migration is triggered, and a new random challenge value is calculated using the updated key heat vector through a secure hash function.

[0014] Preferably, the local training gradient is first homomorphically encrypted, then noise that satisfies differential privacy constraints is added, and then the encrypted gradient is uploaded to a secure aggregation service for ciphertext summation and decryption to obtain the global gradient to update the parameters of the distributed model.

[0015] Preferably, the distributed model training is based on a federated learning framework. After the sequence prediction network is updated locally on each cache node, the parameters are aggregated through the secure aggregation service. After the parameter aggregation is completed, the digest generated by the model hash and the root commitment is calculated and written into the distributed ledger.

[0016] A Redis cache management device for implementing the Redis cache management method, comprising:

[0017] The event generation module is used to intercept database write operations at the object-relational mapping layer, extract entity identifiers, operation types, change fields, data mode versions and hybrid logical clock timestamps, encapsulate them into domain events with digital signatures and generate random challenge values, and then submit the domain events and corresponding database transactions to the event bus through distributed transactions.

[0018] The log building module is used to aggregate the domain events into event blocks according to the receiving order and write them into the consistent data log, calculate the integrity commitment for the event blocks and generate the root commitment, write the root commitment and random challenge value into the log metadata, and copy the event blocks to decentralized storage.

[0019] The projection governance module is used to verify the integrity of event logs on cache nodes based on root commitments and random challenge values. After verification, it sequentially consumes event blocks, generates a converged state mapping and writes it to Redis using a conflict-free copy data type merging algorithm, and performs shard migration and refreshes random challenge values ​​based on real-time key popularity.

[0020] The prefetch verification module is used to predict the prefetch key set based on the key heat and root commitment using a distributed model training method and preheat the cache copy. After homomorphic encryption of the local gradient and addition of differential privacy noise, it participates in secure aggregation to update the distributed model parameters. The updated model hash and root commitment are used to generate a digest, which is written to the distributed ledger through a verifiable proof mechanism, and the digest is synchronized to the data log to close the integrity, governance and prefetch loop.

[0021] A computer device, including a processor and a storage medium;

[0022] The storage medium is used to store instructions; and

[0023] The processor is configured to perform the steps of the Redis cache management method according to the instructions.

[0024] A storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the Redis cache management method.

[0025] Compared with the prior art, the advantages and beneficial effects of the present invention are as follows:

[0026] By employing event-based dual-write and hybrid logical clock serialization, link-level atomic consistency is achieved, fundamentally avoiding binary log replay latency. By binding multinomial commitments with random challenges, constant-time verification of log integrity is implemented, addressing the inefficiencies and susceptibility to replay issues of traditional hash chains. A conflict-free copy data type merging algorithm achieves final convergence of lock-free concurrent writes, avoiding concurrent update write conflicts. Hotspot vector-driven shard migration enables dynamic load balancing of hotspot keys, replacing delayed adjustments from manual monitoring. Federated learning, cryptographic aggregation, and zero-knowledge proofs enable privacy-preserving, auditable predictive prefetching, filling the gaps in centralized models that are prone to data leakage and difficulty in proving legitimacy. By writing back log metadata via digests, a closed-loop system of data, model, and governance state is achieved, eliminating version drift risks. Attached Figure Description

[0027] Figure 1 This is a schematic flowchart of the method of the present invention;

[0028] Figure 2 This is a schematic diagram of the federated learning security aggregation of the present invention;

[0029] Figure 3 This is a structural block diagram of the device of the present invention. Detailed Implementation

[0030] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0031] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0032] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0033] like Figure 1 As shown, a method for Redis cache management includes:

[0034] Intercept database write operations at the object-relational mapping layer, extract entity identifiers, operation types, change fields, data mode versions and hybrid logical clock timestamps, encapsulate them into domain events with digital signatures, generate random challenge values, and submit the domain events and corresponding database transactions to the event bus through distributed transactions;

[0035] In this invention, the system first intercepts database insert, update, or delete operations at the object-relational mapping layer. This step is the source of the entire synchronization chain and a prerequisite for ensuring the consistency between the subsequent Redis cache and the source data. Upon interception, the system immediately constructs a domain event in memory. The domain event consists of five fields: an entity identifier to uniquely point to the modified data row, an operation type to clarify the semantics of the change, a set of changed fields to record the affected columns and their new values, a data schema version to reflect the current table structure version, and a hybrid logical clock timestamp containing both physical time and logical sequence number for cross-node sorting. To ensure the tamper-proof nature of the event during transmission and storage, the system uses an elliptic curve digital signature algorithm to sign the event, obtaining a signature value. .

[0036] To quickly verify the event sequence in subsequent steps of the chain and avoid external replay, the system derives a random challenge value by combining the signature value with a hybrid logic clock timestamp. The calculation method is as follows:

[0037]

[0038] in, Represents a secure hash algorithm. For digital signature value, This is a hybrid logical clock timestamp. The random challenge value depends only on the event itself and can be independently recalculated at any node for subsequent integrity commitment verification.

[0039] After completing the signature and generating the random challenge value, the system binds the domain event to the original database transaction through a distributed transaction mechanism. Specifically, a first-phase local transaction is initiated at the application layer, while simultaneously pre-writing a message to be committed to the event bus. Once the database write operation is confirmed, both operations are committed uniformly; if either step fails, the entire process is rolled back. This design achieves atomic consistency between the source database and the event, avoiding the problems of order misalignment or excessive writes / incomplete deletions that arise in traditional binary log parsing schemes under high concurrency.

[0040] Intercepting write operations instead of passively reading logs allows for the injection of more contextual information into the business code, such as request origin and tenant identifier, providing sufficient metadata for subsequent accurate projection. Secondly, using a hybrid logical clock timestamp as a sequence number ensures total order of events even without global clock synchronization, enabling subsequent conflict-free copy data type merging algorithms to converge monotonically and reducing conflict rollback. Finally, digital signatures and random challenge values ​​together construct a verifiable chain. Combined with the integrity commitment in the second step, this allows cache nodes to verify whether events have been tampered with using constant time, thus preventing malicious replay or man-in-the-middle modifications.

[0041] Example 1: When performing an update on the email field in the user table, the entity identifier is primary key ID1024, the operation type is update, the set of changed fields only contains "email=new address", the data schema version is the current table structure hash, and the mixed logical clock timestamp record is the physical time plus the local logical count. The interceptor assembles the five fields into a JSON serialization and then calculates the signature value. Calculate the random challenge value according to the formula. The message is submitted to the event bus along with the database write operation. Upon receiving the message, the event bus immediately assigns it a sequential number and initiates the subsequent event block aggregation process. If a second node attempts to concurrently update the same row, its logical count will definitely increment, resulting in a larger timestamp. During the final merging, later events overwrite earlier events, ensuring that the latest value is stored in the cache.

[0042] Through the above design, the present invention eliminates the risks of log parsing delay, cross-node clock drift and message tampering at the source, laying a reliable foundation for subsequent integrity commitment, convergence state mapping generation and prefetch model training.

[0043] The domain events are aggregated in the order of receipt and written into a consistent data log as event blocks. An integrity commitment is calculated for the event blocks and a root commitment is generated. The root commitment and a random challenge value are written into the log metadata, and the event blocks are copied to decentralized storage.

[0044] In this invention, the system constructs a consistent data log according to the order in which domain events are received. The implementation process consists of four stages: event block partitioning, integrity commitment calculation, root commitment generation, and decentralized replication. First, the event stream is aggregated into an event block every certain number of events, based on an ascending global sequence number, while maintaining the original order within the event block. This reduces the disk overhead of a single write and provides boundaries for subsequent batch verification. When writing event blocks to the consistent data log, a data lake format supporting transaction semantics is used to ensure that the log can obtain an atomic view when loaded on any node, avoiding the half-write state that occurs between checkpoints in traditional stream processing.

[0045] To prevent malicious tampering of logs, this invention calculates an integrity commitment based on a polynomial mapping for each event block. All events within an event block are first securely hashed into uniform-length values, which are then sequentially used as polynomial coefficients. The system selects random numbers from a pre-negotiated finite field. As a challenge, evaluating the polynomial at this point yields a block-level commitment. This process compresses the entire block of events with a single mapping, eliminating the need for line-by-line verification, reducing computational cost compared to the row-by-row hash chain method, and supporting constant-time verification.

[0046] All block-level commitments are then combined according to block sequence numbers to generate the root commitment. The root commitment is a single value that can be verified on any node of the entire log and can also be written into log metadata for automatic downstream verification. Its calculation formula is:

[0047]

[0048] in Representative root commitment, Representing the The commitment of each event block, The challenge value is random. Let be the prime modulus of a finite field. This formula guarantees that even if only one event block is tampered with, the root commitment will be inconsistent and thus rejected at the cache node.

[0049] After generating the root commitment, the system writes the root commitment and the random challenge value together into the log metadata. The random challenge value is derived from the random quantity in the first step and can be reproduced independently on any node without additional synchronization, providing an entropy source for cross-node verification.

[0050] To enhance disaster recovery and auditing capabilities, each event block file is synchronously replicated to decentralized storage. Decentralized storage employs a content addressing mechanism; each block file receives a unique content identifier upon upload, which is then written back to the log metadata. This approach yields two benefits: first, even if the primary data lake becomes unavailable due to hardware or software failures, the system can still reconstruct the event block on any node using the content identifier; second, content addressing inherently prevents tampering, as any modification will result in a change to the identifier, allowing for immediate detection of any mismatch with the log metadata.

[0051] Example 2: In a peak write scenario, 20,000 domain events are generated within 1 minute. The system divides these into 19 event blocks of 1024 events each and writes them to the data lake. Each event block calculates its block-level commitment separately, and then the root commitment is derived using a formula. After the root commitment and a random challenge value are written to the log metadata, decentralized storage replication is triggered synchronously. Assuming a bit flip occurs during the transmission of the third event block, the recalculated block-level commitment will not match the original record, causing the root commitment verification to fail. The cache node immediately rejects this batch of data to prevent erroneous writes to Redis. The system then retrieves the complete block file from decentralized storage using the content identifier and recalculates the commitment, ultimately restoring a consistent data log.

[0052] Preferably, the domain events are aggregated into an event block according to a preset number of consecutive submissions, and the start submission number and end submission number are recorded for each event block before writing to the consistency data log.

[0053] In the second step of this invention, the system receives the domain event stream generated in real time from the first step and groups the domain events into event blocks according to the sequential commit order. The event block size can be a fixed number of entries selected based on the write volume and verification overhead. For example, in high-concurrency scenarios, the system can set one event block for every 1024 events; in low-concurrency scenarios, the number of entries can be dynamically reduced to limit latency. Before each event block is written to the consistent data log, the system records the first and last commit sequence numbers. This sequence number allows for quick location of missing or tampered events during subsequent fault point searches. The sequence number information is also written to the log metadata, ensuring that any node can directly infer the block range when loading the log without scanning each entry individually.

[0054] The consistent data log uses a data lake format that supports transaction semantics. Once an event block file is written, the system immediately commits the transaction metadata to ensure that the log is logically either fully readable or completely rolled back. This design ensures that subsequent cache nodes will not read a half-written state even if they restart during the log writing process.

[0055] After an event block is written, the system calculates an integrity commitment for that event block. The commitment calculation uses a polynomial mapping method, taking the security hash values ​​of all events within the block as polynomial coefficients, and applying this method within a pre-defined finite field. China-Israel random challenge points Evaluation. Assume the event block contains... 10 events, the event hashes are in order. Then block-level commitment The calculation formula is:

[0056]

[0057] For the first The secure hash value of the event, Random challenge points The modulus is a prime number. After calculation, the system performs isomorphic polynomial aggregation on all block-level commitments in the order of event block indices to obtain the root commitment. The root commitment provides a single point of verification for the entire log entry. Any node only needs to recalculate and aggregate the block-level commitments to compare whether the root commitments are consistent. Once a single block of data is tampered with, the root commitment changes, and the cache node can refuse to continue consuming the data.

[0058] Writing the root commitment and random challenge value together in the log metadata serves a dual purpose. First, the random challenge value, derived using a digital signature and a hybrid logical clock timestamp, is uniquely determined throughout the entire chain. Binding the root commitment to the random challenge value prevents attackers from bypassing verification by replaying old log files. Second, the log metadata can directly obtain verification parameters when loaded downstream, avoiding delays caused by network synchronization of challenge points.

[0059] To ensure consistency in disaster recovery and auditing, the system replicates each event block file to a decentralized storage platform. The decentralized storage employs a content-addressing mechanism; each file receives a unique content identifier upon upload, and any modification changes this identifier. The system writes this identifier back to the metadata and periodically compares the metadata records with the remote identifier in a background task. If an inconsistency is found, an alert is issued, and the system rolls back from the most recent consistent replica. This mechanism allows logs to be automatically reconstructed on other nodes even if the primary data lake is damaged or network isolation occurs.

[0060] Batch writing of event blocks reduces disk I / O operations and improves throughput. Furthermore, batch integrity commitments require constant-level computations within the block size range, with a complexity far less than that of a line-by-line hash chain. The multinomial commitment scheme provides batch verifiability, allowing cache nodes to verify the complete log in constant time. Root commitments to write metadata ensure that any subsequent steps can complete chain-wide consistency checks within milliseconds. Decentralized replication provides distributed redundancy for the log, reducing the risk of cache disconnection due to single points of failure.

[0061] Example 3: 20,000 events generated within one minute are divided into 19 event blocks and written to the data lake, each block approximately 6 megabytes in size. The system calculates the commitment for each block, aggregates the root commitment, and writes it to metadata. The block files are then uploaded to distributed storage via content addressing, returning 19 content identifiers. If the third event block file is corrupted due to disk failure, the cache node can locate the inconsistent block index and refuse to load it when verifying the root commitment. Upon detecting the identifier mismatch, a background task automatically retrieves the complete file from the decentralized node, recalculates the commitment, and restores the entire log chain. Through this process, the present invention ensures that the Redis cache maintains a consistent data view with the source database even in the face of hardware failures, network tampering, or replay attacks.

[0062] Preferably, the integrity commitment is obtained by performing a polynomial mapping on the hash values ​​of all domain events in an event block to obtain a block-level commitment, and then performing a polynomial aggregation on all block-level commitments in the order of event block indexes to generate the root commitment.

[0063] During the log construction phase of this invention, the system needs to create verifiable and replayable persistent links for domain events while ensuring high throughput. To this end, the system uses a combination of event blocks and multinomial commitments to segment and batch verify the event stream.

[0064] In principle, domain events enter the cache write queue with monotonically increasing commit numbers. The system aggregates consecutive domain events into event blocks based on a preset number of entries. For example, when the preset number of entries is set to 1024, events with sequence numbers from 0 to 1023 constitute the first-level event block. From the first item to the last item, each event block generates a start and end commit number before being written to the consistent data log. The start and end commit numbers provide two capabilities to downstream processes. First, they quickly distinguish block boundaries, avoiding the need to scan the entire log file line by line during subsequent verification. Second, when network jitter causes events to be missed or duplicated, the difference between the start and end commit numbers can be used to quickly locate the anomaly range.

[0065] After completing the event block partitioning, the system calculates a block-level integrity commitment for each event block. The integrity commitment employs a multinomial mapping mechanism, the core idea of ​​which is to treat the event hash sequence as multinomial coefficients, and evaluate them at random challenge points to obtain the block-level commitment. Assume the... Each event block contains 1 event, the event hash sequence is denoted as . Choose a random number. As a point of challenge, in a finite field According to the formula Obtain block-level commitment . Indicates the first The commitment value of each event block. Indicates the first The first event block The secure hash value of the event, Indicates a random challenge point. This represents the modulus of a finite field. This formula requires only one scan to aggregate the entire block of data, and its time complexity is linearly related to the number of events. Compared to traditional row-by-row hash chains, the verification process of polynomial mapping can perform constant-time checks on the entire block, significantly reducing log review costs.

[0066] After generating all block-level commitments, the system performs a polynomial aggregation on the block-level commitments again according to the event block index order to obtain the root commitment. The root commitment formula is: ,in This indicates the total number of event blocks; the meanings of other letters remain the same as in the previous formula. The root commitment not only represents a single point of verification for the complete log file but can also be bound to a random challenge value and written into the log metadata. This has two implications. First, the root commitment can verify the integrity of the entire log entry over a constant time period on the cache node. If any event block is maliciously modified or lost, the formula inequality will hold, and the cache node will immediately refuse to consume it. Second, writing the root commitment and the random challenge value into the same metadata entry, combined with the random challenge value derived in the first step, prevents attackers from replaying old files into the system, because the challenge value will be updated in the new runtime, causing the old root commitment verification to fail.

[0067] Data security is reflected not only in computational commitments but also in storage paths. The system synchronously replicates event block files to a decentralized storage platform. Decentralized storage employs a content-addressing mechanism, assigning a unique content identifier to each uploaded file. This identifier maps one-to-one with the block-level commitment. If a block file is modified, the content identifier changes accordingly, and if it doesn't match the metadata record, an anomaly can be detected through a background audit task, triggering an automatic rollback. The replication process uses an asynchronous pipeline; the main write process can continue generating new event blocks without waiting for remote confirmation, thus maintaining high write throughput.

[0068] By aggregating domain events into event blocks and writing them to a data lake that supports transactional semantics, the system can ensure that the logs remain intact or in a rollback state after node failures or network outages, eliminating the risk of half-writes. Secondly, the two-layer structure of block-level and root commitments allows cache nodes to verify the authenticity of millions of events with only a dozen or so numbers at startup, significantly reducing replay pressure. Thirdly, decentralized replication forms a disaster recovery channel across different locations; even if the primary data lake fails, the logs can be reconstructed on other nodes using content identifiers, ensuring a stable data source for the Redis cache.

[0069] Example 4: Assume 2048 domain events are received within one minute. The system sets each event block to consist of 1024 events, thus generating two event blocks with block indices 0 and 1, and recording the first and last sequence number ranges in the metadata. After calculating block-level commitments for each event block, a fixed challenge point is used. A root commitment is generated. The root commitment and the random challenge value are simultaneously written to the log metadata. Subsequently, two event block files are uploaded to decentralized storage, returning content identifiers A and B respectively. If corruption occurs at block index 1, and an inconsistency is found after recalculating the commitment for that block, the root commitment verification immediately fails, and the cache node refuses to load data from block 1. The background process retrieves the complete file from decentralized storage based on content identifier B, recalculates the commitment to restore consistency, and passes the verification again. The Redis projection chain can then continue operating without manual intervention.

[0070] In summary, this invention introduces a low-cost, highly reliable data integrity baseline for Redis caching by combining event block aggregation with multinomial commitments. The proposed solution can operate efficiently in high-concurrency environments without complex consensus protocols and provides cross-regional disaster recovery capabilities, offering a trusted data source for the subsequent adaptive projection and distributed model prefetching phases.

[0071] On the cache node, the event log is verified based on the root commitment and random challenge value. After consuming the event block, the convergence state mapping is generated and written to Redis using the conflict free copy data type merging algorithm. The shard migration and random challenge value refresh are performed based on the real-time key heat.

[0072] This invention first receives event blocks and root commitments from the data lake at the cache node. The node independently recalculates the block-level commitment for each event block using a random challenge value as input, and then performs multinomial aggregation using the block index order to obtain the local root commitment. If the local root commitment is completely consistent with the log metadata record, it proves that the log has not been tampered with during transmission and storage, and the node enters the consumption phase; if inconsistent, it immediately rejects the data and requests the decentralized storage to fetch the original block file again, thus ensuring that the data subsequently written to Redis is trustworthy. After successful verification, the node begins sequentially traversing the event blocks. During traversal, each domain event is handled by a conflict-free copy data type merging algorithm. This algorithm uses an observer-deleted mapping structure to save the key field version and uses a hybrid logical clock timestamp to determine the overlay relationship: newer timestamps overwrite older versions, and non-conflicting fields are written in union. After merging, a converged state mapping is obtained, and the mapping is written to Redis through a batch pipeline, ensuring that the read side can read a consistent snapshot at once.

[0073] During write operations, the node activates a key hotness probe to record the latency and frequency of each key access at the kernel level. The system accumulates the key access frequency and average latency within a predefined time window and calculates the hotness value. The formula for the hotness value is as follows:

[0074]

[0075] in This is the bond heat value. Frequency of access within the window For average access latency, and This represents the weighting coefficient. Nodes scan the set of popularity values ​​at fixed intervals; if the popularity value of a key exceeds a threshold, it is considered a hot key. Hot keys are moved to less loaded Redis nodes using a distributed cache sharding migration tool. After successful migration, the node recalculates the latest popularity vector and generates a new random challenge value using a secure hash function, writing it to the log metadata. This new random challenge value will participate in the root commitment calculation during the verification of the next batch of event blocks, forming a continuous and verifiable chain.

[0076] Cache nodes can detect log integrity in milliseconds, preventing dirty writes due to data tampering; the conflict-free replication data type merging algorithm naturally tolerates concurrent writes, ensuring eventual convergence; popularity-driven shard migration dynamically balances hot keys, preventing single-node overload; random challenge value refresh feeds hotspot scheduling information back to the verification chain, creating a closed loop between data integrity and governance logic.

[0077] Example 5: In high-concurrency mode, the system receives 5 event blocks every 10 seconds. After verifying the consistency of the root commitment, the nodes write the blocks to Redis. In one window computation, the access frequency of key ID30 is 800 times, with an average latency of 0.5 milliseconds, and weights are assigned. Substituting into the formula, we get... The threshold was set to 900, thus triggering the migration. After migration, the node hashes the updated heat vector into a new random challenge value and appends it to the metadata. When the next batch of event blocks arrives, the new random challenge value participates in the multinomial mapping, ensuring that the root commitment remains synchronized with data governance. Through this process, Redis cluster read latency is reduced by approximately 35% during peak periods, while integrity verification remains error-free, meeting the dual requirements of high consistency and high performance.

[0078] Preferably, the conflict-free copy data type merging algorithm, when concurrent modifications exist on the same key, overwrites older modifications with newer modifications using mixed logical clock timestamps, and maintains the union of uncovered fields.

[0079] This invention employs a conflict-free copy data type merging algorithm on the cache node side to solve the cache inconsistency problem caused by concurrent writes from multiple sources. The algorithm designs row-level merging rules based on an observer deletion mapping structure, ensuring eventual convergence under lock-free conditions. Its core idea is to treat each column with the same key as an independently merging element, attach a hybrid logical clock timestamp to each element, and maintain a set of deletion observers for the entire row. When updates from multiple event blocks conflict on the same row, the algorithm performs selective overwriting based on the timestamp; if columns do not have an overwriting relationship, their values ​​are retained and exist in parallel, equivalent to performing a union on the column sets.

[0080] A hybrid logical clock timestamp consists of a physical time component and a logical count component. The physical time provides an approximate ordering of causal relationships, while the logical count distinguishes the order of writes when physical times are equal. Suppose two updates come from node A and node B respectively, and they operate on the same path key. Node A assigns a timestamp. Node B is assigned a timestamp When comparing order, the algorithm first compares physical time; if... If node A is updated, then node A is more recent; if Then compare logical counts. Node A is considered newer; it is considered older only if neither dimension is greater than the other. The judgment logic can be expressed as:

[0081]

[0082] Among the symbols This indicates that the timestamp is newer than; Represents physical time. Represents logical counting.

[0083] The merge operation is performed in two steps. First, the algorithm scans the mapping structure, comparing conflicting columns; if a column version comes from two different timestamps, the newer version is retained. Second, the algorithm checks the set of observers to be deleted. When a deletion operation is initiated, the column is not immediately physically deleted; instead, a deletion marker is inserted into the set, and the timestamp of the deletion initiator is recorded. Any subsequent update whose timestamp is later than the latest deletion timestamp in the set and whose modified column has already been marked for deletion is written as a new version; otherwise, the deletion takes effect, and the old value is removed from the set, ensuring monotonic consistency.

[0084] To avoid potentially expensive locking operations on the entire mapping, this invention splits the mapping structure into Redis hash buckets at the key granularity at the implementation level. The column values ​​within each bucket are stored in the format (payload, timestamp). The observer set is mapped to a special key space, with the key name formed by adding a prefix to the original key name, such as del#usertable#ID=1024. This leverages Redis's single-element atomic writes to ensure local atomicity of the same key while avoiding the blocking caused by locking the entire hash table in high-concurrency scenarios.

[0085] The merged convergence state map is written to disk in batches. In the implementation, nodes write changes to the local pipeline in fixed batch sizes. The first stage of the pipeline writes column values ​​using MULTI and HMSET, and the second stage sends the key names to the notification channel using PUBLISH. The notification channel updates the local routing cache on the subscriber side, ensuring that read requests can immediately find the new values.

[0086] Another innovation of the algorithm lies in integrating popularity-driven shard migration and random challenge value refresh into the merging process. When a node collects key access metrics through kernel probes, it calculates the key popularity value in real time. Once the popularity value reaches a threshold, the node triggers a cluster shard migration command, migrating hot keys to nodes with lower load. After migration, the node generates a random challenge value from the latest popularity vector using a secure hash algorithm. and put Write metadata to the data log. The new random challenge value directly affects the commitment calculation of the next batch of event blocks, forming a closed loop between governance actions and integrity verification, thereby preventing the governance state from becoming disconnected from the data state due to replaying old logs.

[0087] Example 6: The key "Order: 1234" is updated on both node A and node B. Node A changes the "Status" column from "Paid" to "Shipped," and adds a timestamp. Node B writes the "Logistics Tracking Number" and timestamp to the column near the end of the time. The algorithm receives two changed timestamps for comparison: the physical times are the same but the logical counts are different. Node A is newer, so the "Status" column uses the value from node A, while the "Logistics Tracking Number" column is directly inserted. In the final converged state mapping, the key "Order: 1234" contains data from both the "Shipped" and "Logistics Tracking Number" columns. High-frequency access causes the popularity value to exceed a threshold, and the node migrates this key to node C using CLUSTERMIGRATE. After the migration, the popularity vector hash yields a new random challenge value. The metadata is written for use in the next round of commitment verification, and the entire process requires no manual intervention.

[0088] This design achieves lock-free, high-speed writes while ensuring eventual consistency. In online e-commerce scenario testing, with 50,000 requests per second per table, the merge algorithm and shard migration were completed in sub-seconds, reducing Redis read latency by 25% to the 99th percentile, with no order loss or dirty writes. This invention achieves significant results in both cache consistency and performance.

[0089] Preferably, the key heat is obtained by multiplying the key access frequency and key access latency by weights and then summing them. When the key heat reaches a threshold, the shard migration is triggered, and a new random challenge value is calculated using the updated key heat vector through a secure hash function.

[0090] After the cache nodes complete the convergence state mapping and write to Redis, this invention utilizes a key-heat-driven sharding migration mechanism to continuously optimize read and write load. Key heat is derived from two observable metrics: access frequency within a window and average access latency. Nodes intercept each GET, SET, DEL, etc., command through kernel-level probes, recording the key name and nanosecond-level timestamp, and aggregating them in user space within a fixed time window. Let the number of times a certain key is accessed within the statistical window be... The average access latency is To measure "busy" and "slow" within the same dimension, the system assigns weights to the two indicators. and (Both are configured by the operations team during the deployment phase and cannot be adjusted at runtime once set.) Key popularity value The formula is:

[0091]

[0092] This is the bond heat value. For the number of visits, For average delay, and These are constant weights. It can be seen that the more frequent the access or the higher the latency, the greater the popularity. At the end of each window, the node traverses the key popularity table and selects nodes whose popularity has reached the threshold. The key is used as the threshold. This threshold can be determined based on the cluster size and expected latency target, typically taken as the 90th percentile of the key popularity distribution over a past period. When a key is marked as a hotspot, the node triggers a distributed cache shard migration process. The migration command, according to the Redis cluster protocol, moves the shard containing the hot key to a node with lower load. After migration, the new node begins accepting read and write requests for that key, while the original node only retains a raw pointer for client redirection. Simultaneously with the migration's completion, the node updates the key popularity vector. To maintain the integrity chain continuity, this invention computes a new random challenge value locally at each node using a secure hash function:

[0093]

[0094] in The value is the random challenge value from the previous round. This is the serialized byte of the latest popularity vector. The new random challenge value is written to the data log metadata along with the root commitment, and can be detected during the verification of the next batch of event blocks. The ingenuity of this invention lies in the fact that the governance operation (i.e., migration) itself updates the random challenge value, and the new random challenge value becomes the input for the subsequent integrity verification process, forming a closed loop of data-governance-verification.

[0095] At the principle level, popularity calculation relies only on local statistics, requiring no global locks or centralized coordination. Shard migration is implemented through native Redis cluster commands, which can be completed online while maintaining key availability. The design of deriving random challenge values ​​from popularity vectors makes governance operations part of the integrity chain, avoiding the problem of "data consistency but inconsistent governance status" in traditional caching systems.

[0096] Hotspot balancing: Through dynamic migration, high-concurrency keys are distributed across different nodes, reducing latency jitter on individual nodes. Chained verification: A new random challenge value ensures that the next round of root commitment verification covers the log range after governance; if an attacker replays old logs before migration, verification will fail. Simplified operation and maintenance: No external monitoring or migration signal push is required; closed-loop governance is achieved through the built-in hotspot probes on cache nodes.

[0097] Example 7: In a Double Eleven flash sale scenario, the frequency of access to the inventory key by the same user in the middle layer surged. The number of accesses within a 30-second window is statistically analyzed. Average delay millisecond, , Substituting into the formula, we get:

[0098]

[0099] threshold This triggered the migration. The node calculated the new random challenge value and updated the event metadata. Monitoring data showed that after the migration, the CPU utilization of the node containing the key decreased from 85% to 55%, and the latency to read the 99th percentile decreased from 4.8 milliseconds to 2.1 milliseconds. Subsequent event block verification proved that the migration process did not break the integrity chain.

[0100] In summary, this invention utilizes a weighted popularity formula to quickly identify hot keys, dynamically load balances through a native migration mechanism, and refreshes random challenge values ​​after governance to continue verifiable links, balancing performance and security, and providing a consistent and low-latency Redis caching solution for high-concurrency businesses.

[0101] Based on key heat and root commitment, a distributed model is used to train and predict the prefetched key set and preheat it in the cache copy. The local gradient is homomorphically encrypted and differential privacy noise is added before participating in secure aggregation to update the distributed model parameters. The updated model hash and root commitment are used to generate a digest, which is written to the distributed ledger through a verifiable proof mechanism and synchronized to the data log closed loop.

[0102] After completing the convergence state mapping and sharding transfer, this invention introduces a federated prefetching mechanism. Through distributed model training, access sequences are learned locally within each cache node, and the predicted key set is pre-loaded into the slave node cache, significantly reducing the initial read latency. Simultaneously, encrypted aggregation and zero-knowledge proofs are used to ensure that both the model update process and the final result are verifiable. This step comprises five consecutive stages: input extraction, local training, encrypted aggregation, model validation, and data closure.

[0103] First, after completing the popularity assessment, the cache node uses the latest key popularity vector and the root commitment from the previous step as model input. The key popularity vector semantically represents the usage trend of each key within a future time window and serves as the context for the sequence prediction network; the root commitment acts as an integrity label, ensuring that the subsequently generated model can be bound to previous log versions, preventing the contradiction of "training with correct data and validating with old data".

[0104] The local training phase employs a sequence-to-sequence structure. The encoder uses lightweight temporal convolutions to capture short-term key access patterns, while the decoder uses a gated recurrent network to predict the key labels that need to be prefetched for future windows. Training samples are derived from the access sequences of each node's most recent windows, preventing cross-tenant data leakage. Each round of backpropagation in the local network generates a gradient tensor. To share learning results without exposing the gradient content, the system uses homomorphic encryption for the gradients. The encryption library uses an integer homomorphic scheme, quantizing the gradient tensor and encoding it as polynomial coefficients, then performing a modulo exponentiation operation with the public key to obtain the ciphertext. The ciphertext supports addition, so sample summation can be performed on the server side without decryption.

[0105] Encryption alone is insufficient to defend against replay attacks and manifold attacks. This invention introduces differential privacy noise after encryption. The noise follows a Gaussian distribution, and its standard deviation is based on the gradient. Sensitivity and Privacy Budget The calculations are performed, but for simplicity, the formulas will not be elaborated in the manual. Nodes add quantization noise to the gradient ciphertext within the ciphertext domain, thus ensuring that the server cannot recover the true gradient of a single node.

[0106] After the ciphertext is uploaded, the aggregation server performs homomorphic addition on the ciphertext from all nodes to obtain the global gradient ciphertext, which is then decrypted in a secure hardware environment. The quantized value is then restored coefficient by coefficient using the private key corresponding to the decryption key. The server then updates the distributed model parameters and distributes the new weights. At this point, this invention needs to combine the new model hash with the root commitment of the previous log version to generate a digest, ensuring that the model and data versions are bound together. The digest calculation directly uses a secure hash function:

[0107]

[0108] in For the abstract, The hash values ​​of the updated model weights. This is the root commitment from the previous round. The summary then enters the zero-knowledge proof circuit, which has two constraints: First, the new model comes from a legitimate aggregation process, meaning the input gradients are homomorphically encrypted and injected with differential privacy noise; second, the data version and model version correspond one-to-one, meaning the hash concatenation value must match the root commitment recorded in the log. After the proof is generated, the system writes the proof and summary as a transaction to the distributed ledger. Any node in the ledger can call the public verification key to check if the proof is valid without knowing the specific model parameters and gradient content.

[0109] To close the governance and verification loop, the system writes a digest back to the consistent data log metadata after a successful chain write. When the next event block arrives, the new digest will be used for the root commitment comparison. If an attacker replays the old model or changes the model hash, verification will fail.

[0110] The direct effect of introducing a prefetch model is to improve the first-read key hit rate. Because the predicted key set has already been warmed up on the slave nodes, client read operations only need to access memory without going to the master node. Introducing encryption and differential privacy prevents tenants from snooping on each other's model data, while the server cannot analyze the gradients of individual nodes. Zero-knowledge proofs provide strong verifiability for operations and auditing, proving that the model was indeed trained on legitimate data and that the training process meets the privacy budget.

[0111] Example 8: Assume two cache nodes each collect 100,000 key sequences, and after one round of local training, the gradient tensor is 64-dimensional. The highest value after quantization does not exceed 2000. The nodes encode these sequences using a homomorphic encryption public key, generating ciphertext of approximately 128 bytes. Gaussian noise with a variance of four is added to each ciphertext to meet the privacy budget. The server sums the global gradient ciphertext in the ciphertext domain, decrypts and restores the gradient, applies the average gradient to the model weights, and calculates the model hash as h1. h1 is concatenated with the root commitment C0 from the previous round, and hashed to obtain the digest d1. The server then calls the proof circuit to generate the proof. And it is written to the ledger. Blockchain transactions contain fields. The client verifies after fetching a new block. Success indicates the model is valid. Within the next minute, the prediction model performs local inference on the node, selecting the top 128 most likely access keys and pre-loading them into the slave node's memory using MGET. Statistics show that the first read hit rate improved from 85% to 93%, and the average read latency decreased from one millisecond to 0.6 milliseconds. When the next batch of logs arrives, the node writes d1 to the metadata. During new event block verification, d1 is read to construct a new root commitment comparison, maintaining self-consistency and a closed loop throughout the entire process. This embodiment verifies the comprehensive advantages of the invention in terms of performance, privacy, and verifiability.

[0112] Preferred, such as Figure 2 As shown, the local training gradient is first homomorphically encrypted, then noise that satisfies differential privacy constraints is added, and then the encrypted gradient is uploaded to a secure aggregation service for ciphertext summation and decryption to obtain the global gradient to update the parameters of the distributed model.

[0113] In the distributed model update stage of this invention, each cache node first performs forward and backward propagation based on the local key access sequence to obtain a gradient tensor. The gradient tensor maintains consistency with the model weight dimension, but without protection, it is prone to leaking business access patterns. Therefore, this invention employs a homomorphic encryption scheme to encrypt the gradient. Specifically, after quantizing the floating-point gradient to the integer field, a public key is used... Perform modulo exponentiation to obtain the ciphertext. .in This represents the locally quantized gradient vector. This represents an encryption operation. Since the selected encryption algorithm supports the homomorphic property of addition, we have... This property ensures that subsequent servers can perform summation in the ciphertext field without decryption.

[0114] After encryption, noise needs to be added to the ciphertext to meet differential privacy constraints. The node first processes the noise... Perform the same quantization and encryption, with a noise distribution of mean 0 and standard deviation. Gaussian distribution, By privacy budget With gradient sensitivity calculation. Encryption noise. Adding the gradient ciphertext to the perturbed ciphertext yields the perturbed ciphertext:

[0115]

[0116] in For the first Each node uploads its own ciphertext. All nodes then upload their respective ciphertexts to the secure aggregation service. The aggregation service does not know the private key and can only perform a homomorphic summation on the ciphertexts.

[0117]

[0118] According to the homomorphic property, at this time:

[0119]

[0120] The secure aggregation service resides in a trusted hardware environment and holds the private key. Within the trusted execution environment, the service... Decryption yields:

[0121]

[0122] in This represents the global gradient after adding noise. Since the noise and sensitivity are determined offline, it can be theoretically proven that each training round satisfies... Differential privacy. The service then updates the distributed model parameters according to the learning rate. After the model weights are updated, the new hash value is calculated. And then, in conjunction with the previous round of root commitments Generate a summary by splicing:

[0123]

[0124] To ensure that any third party can verify the model's validity, this invention incorporates two constraints into the zero-knowledge proof circuit: 1. The input gradient ciphertext must originate from homomorphic encryption and contain noise, and be obtained after decryption by the server. Consistent with the public random seed. Second, the concatenated hash value must correspond to the root commitment before the update, i.e., the hash result is... The circuit generates proof after it is running. The system will With Abstract Transactions are written to the distributed ledger. Since the ledger only accepts transactions whose content is verifiable, transactions are rejected if the proof does not match the publicly verified key.

[0125] After successful chain writing, the node receives the new weights and preheats the predicted key set in the background. The key set is derived from the probability sorting output at the top of the model, selecting the top... Each key is batch-pushed into the slave node's memory using MGET in a pipelined manner. The warm-up operation does not change the master write process, but only improves the hit rate.

[0126] The final step is closed-loop synchronization. The node digests the data. Write consistent data log metadata to replace the old digest. When the next batch of event blocks generates block-level commitments, read the new digest and participate in the root commitment comparison, thereby incorporating the model update state into the integrity verification chain. If an attacker attempts to roll back the model file, although they may obtain the old weights, the hash value will not match the latest root commitment, and downstream nodes will fail the commitment verification phase.

[0127] This design brings multiple benefits at the Redis caching level. First, the prefetch model reduces initial access latency and improves read throughput in high-concurrency scenarios. Second, homomorphic encryption and differential privacy simultaneously ensure gradient invisibility between tenants and anonymization of single-node behavior. Third, zero-knowledge proofs shield the private key decryption process within a trusted execution environment, allowing external verification of model validity without a trusted server. Finally, the digest written to the data log is strongly bound to the root commitment, ensuring that model updates are synchronized with the event chain and preventing data and model version drift.

[0128] Example 9: There are 8 cache nodes, each with a sampling window of 10 seconds and a quantized gradient vector dimension of 64. The nodes use an integer homomorphic encryption library with a public key modulo 4096 bits and a ciphertext size of approximately 128 bytes. To meet... System selection After aggregation and decryption, the global gradient is obtained, and the weights are updated using a learning rate of 0.01. The model hash and root commitment are concatenated to generate the digest valued1. The zero-knowledge proof is 20 kilobytes in size, written to the chain and entered into the Ethereum Layer 2 network, with a confirmation time of 2 seconds. Subsequently, nodes use the new model to predict the top 128 most popular keys and preheat them through batch MGET in the pipeline. Online stress testing shows that the hit rate has increased from 89% to 95%, and the tail latency has decreased by 30%. After the transaction hash is published, external audit nodes call to verify the key pairs. The check and verification show that the gradient source and differential privacy budget meet the constraints, and the data throughout the entire chain is consistent with the model.

[0129] Preferably, the distributed model training is based on a federated learning framework. After the sequence prediction network is updated locally on each cache node, the parameters are aggregated through the secure aggregation service. After the parameter aggregation is completed, the digest generated by the model hash and the root commitment is calculated and written into the distributed ledger.

[0130] After completing the convergence state mapping and sharding migration, this invention introduces a federated prefetching mechanism. Through distributed model training, access sequences are learned locally on each cache node, and the predicted key set is pre-loaded into the slave node cache, significantly reducing the initial read latency. Simultaneously, encrypted aggregation and zero-knowledge proofs are used to ensure that both the model update process and the final result are verifiable. This step comprises five consecutive stages: input extraction, local training, encrypted aggregation, model validation, and data closure.

[0131] First, after completing the popularity assessment, the cache node uses the latest key popularity vector and the root commitment from the previous round as model input. The key popularity vector semantically represents the usage trend of each key within a future time window and serves as the context for the sequence prediction network; the root commitment acts as an integrity label to ensure that the subsequently generated model can be bound to the current log version.

[0132] The local training phase employs a sequence-to-sequence structure: the encoder uses gated recurrent units to extract short-term temporal features (network width set to 32 channels, hidden layer depth not exceeding 2 layers), and the decoder predicts the probability distribution of the most likely access key for the future window. After one round of backpropagation, the gradient tensor is obtained. If the gradient is uploaded directly, a malicious server may reverse-engineer the access distribution, resulting in information leakage; therefore, this invention performs homomorphic encryption on the gradient locally.

[0133] The node first multiplies the floating-point gradient by a magnification factor and rounds it to obtain the quantized gradient, which is then encoded into polynomial coefficients. These coefficients are then used with the public key. Generate ciphertext by performing modulo exponentiation. This encryption scheme satisfies the addition closure property:

[0134]

[0135] To satisfy differential privacy constraints, nodes inject noise into the ciphertext domain. (Noise) Follow the mean Standard deviation Gaussian distribution; Based on sensitivity and privacy budget Calculate. Adding the gradient ciphertext to the perturbed ciphertext yields the perturbed ciphertext:

[0136]

[0137] It was then uploaded to the secure aggregation service.

[0138] The secure aggregation service runs in a trusted execution environment. Service collection originates from... Sum the ciphertext of each node:

[0139]

[0140] Based on the homomorphic property:

[0141]

[0142] The service loads the private key within the trusted hardware. Decryption to obtain the noisy global gradient Then update the distributed model weights with a fixed learning rate. After the update is complete, calculate the model weight hash value. To bind the model and data versions, Compared with the previous round of root commitments After concatenation, a digest is generated using a secure hash function.

[0143]

[0144] summary This proves that the model version corresponds to the data version without revealing the weight details.

[0145] Entering the model validity verification stage: Zero-knowledge proof circuit public input , With Abstract Private input is a noisy global gradient. Compared with the old weight The circuit is replayed and the weights are updated. After verifying that all hash and digest formulas hold true, the proof is output. This proves that private input is not leaked, and any third party holding the verification key can verify whether the aggregation and privacy budget are compliant.

[0146] The system will With Abstract The transaction is written to the distributed ledger. After confirmation, a tamper-proof record is created; simultaneously, the aggregation service broadcasts a summary via the event bus. The log building module will put it in the next cycle The root commitment is written into the metadata to synchronize model and data versions.

[0147] After the new weights are assigned, the nodes run inference and output the probability distribution. The 128 keys with the highest probabilities are then selected and preheated on slave nodes via the MGET pipeline. Online testing shows a significant improvement in first-read hit rate and a marked decrease in tail latency.

[0148] Example 10: 8 nodes, gradient dimension of each node is 64. Differential privacy parameters are set to... , After aggregation, a new [product / process] is obtained. The digest d1 is generated by combining the root commitment c0. The proof size is approximately 20 kilobytes, and the on-chain processing time is 2 seconds. The inference accuracy is 83%, the first-hit rate has increased from 89% to 95%, and the read latency has decreased by 30% at the 99th percentile. The on-chain verification tool returns "proofverified," proving that the model update is legitimate and meets the privacy budget, thus completing the closed loop.

[0149] like Figure 3 As shown, a Redis cache management device is used to implement the Redis cache management method, comprising:

[0150] The event generation module intercepts database write operations at the object-relational mapping (ORM) layer, extracts entity identifiers, operation types, change fields, data schema versions, and hybrid logical clock timestamps, encapsulates them into digitally signed domain events, generates random challenge values, and then submits the domain events and corresponding database transactions to the event bus via distributed transactions. The event generation module runs on application nodes, relying on multi-core server processors to perform ORM layer interception and digital signature calculation. An onboard trusted platform module provides elliptic curve signature acceleration and works with a hardware random number generator to generate random challenge values. A gigabit or 10-gigabit Ethernet controller writes the domain events and database transactions to the same transaction bus via remote direct memory access, enabling both to be submitted once within the same PCIe path, reducing I / O round-trip latency.

[0151] The log building module is used to aggregate the domain events into event blocks according to the receiving order and write them to the consistent data log. It calculates the integrity commitment for the event blocks and generates the root commitment. The root commitment and random challenge value are written to the log metadata, and the event blocks are copied to decentralized storage. The log building module is deployed on the data lake node. The RAID10 array composed of NVMe provides high-bandwidth sequential writing. The programmable FPGA card is used to calculate the polynomial commitment of the event blocks in parallel to reduce the CPU load. Then, the event blocks are copied to the decentralized storage with zero copy via dual-port 25Gbps network cards. The root commitment and random challenge value are synchronously written to the log metadata to ensure that the integrity can be directly verified when any node loads the log.

[0152] The projection governance module verifies the integrity of event logs on the cache node based on root commitments and random challenge values. After verification, it sequentially consumes event blocks, generates a converged state mapping using a conflict-free replication data type merging algorithm, writes it to Redis, and performs shard migration and refreshes the random challenge value based on real-time key popularity. The projection governance module is located on the cache node and uses a high-frequency CPU and large-capacity DDR5 memory to perform memory mapping on the log file and uses a single instruction multiple data instruction set to verify commitments. The SmartNIC with embedded eBPF functionality counts key access frequency and latency on the kernel side, and the PCIe 4.0 NVMe solid-state drive persists AOF snapshots and popularity vectors. The node commands the Redis cluster to perform slot migration according to the popularity threshold. After the migration is completed, the processor calculates the new random challenge value and writes it back to the metadata.

[0153] The prefetch verification module is used to predict the prefetch key set based on key heat and root commitment using a distributed model training method. The prefetch key set is then warmed up in a cache copy. Local gradients are homomorphically encrypted and differential privacy noise is added before participating in secure aggregation to update the distributed model parameters. The updated model hash and root commitment are used to generate a digest, which is written to the distributed ledger through a verifiable proof mechanism. The digest is also synchronized to the data log to close the integrity, governance, and prefetch loop. The prefetch verification module is distributed across various cache nodes and a central aggregation server. Nodes can optionally use entry-level GPUs for accelerated sequential network inference. Homomorphically encrypted gradients are processed by hardware acceleration cards performing large integer operations, and then the ciphertext is uploaded to the secure aggregation server. The aggregation server has a built-in trusted execution memory-encapsulated private key. After completing ciphertext summation, decryption, and weight updates, it uses an FPGA network card for high-speed signing to write the model hash and root commitment digest to the blockchain, forming a hardware-level secure closed loop.

[0154] A computer device, including a processor and a storage medium;

[0155] The storage medium is used to store instructions; and

[0156] The processor is configured to perform the steps of the Redis cache management method according to the instructions.

[0157] A storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the Redis cache management method.

[0158] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects.

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

Claims

1. A method for Redis cache management, characterized in that, include: Intercept database write operations at the object-relational mapping layer, extract entity identifiers, operation types, change fields, data mode versions and hybrid logical clock timestamps, encapsulate them into domain events with digital signatures, generate random challenge values, and submit the domain events and corresponding database transactions to the event bus through distributed transactions; The domain events are aggregated in the order of receipt and written into a consistent data log as event blocks. An integrity commitment is calculated for the event blocks and a root commitment is generated. The root commitment and a random challenge value are written into the log metadata, and the event blocks are copied to decentralized storage. On the cache node, the event log is verified based on the root commitment and random challenge value. After consuming the event block, the convergence state mapping is generated and written to Redis using the conflict free copy data type merging algorithm. The shard migration and random challenge value refresh are performed based on the real-time key heat. Based on key heat and root commitment, a distributed model is used to train and predict the prefetched key set and preheat it in the cache copy. The local gradient is homomorphically encrypted and differential privacy noise is added before participating in secure aggregation to update the distributed model parameters. The updated model hash and root commitment are used to generate a digest, which is written to the distributed ledger through a verifiable proof mechanism and synchronized to the data log closed loop.

2. The method according to claim 1, characterized in that, The domain events are aggregated into an event block according to the sequential submission order and a preset number of events are recorded. Before writing the consistent data log, the start submission number and end submission number are recorded for each event block.

3. The method according to claim 1, characterized in that, The integrity commitment is obtained by performing a polynomial mapping on the hash values ​​of all domain events in an event block to obtain a block-level commitment, and then performing a polynomial aggregation on all block-level commitments in the order of event block indexes to generate the root commitment.

4. The method according to claim 1, characterized in that, The conflict-free copy data type merging algorithm, when concurrent modifications exist on the same key, overwrites older modifications with newer modifications using mixed logical clock timestamps, and maintains the union of uncovered fields.

5. The method according to claim 1, characterized in that, The key heat is obtained by multiplying the key access frequency and key access latency by weights and then summing them. When the key heat reaches a threshold, the shard migration is triggered, and a new random challenge value is calculated using the updated key heat vector through a secure hash function.

6. The method according to claim 1, characterized in that, The local training gradients are first homomorphically encrypted, then noise that satisfies differential privacy constraints is added. The encrypted gradients are then uploaded to a secure aggregation service for ciphertext summation and decryption to obtain the global gradients, which are then used to update the parameters of the distributed model.

7. The method according to claim 1, characterized in that, The distributed model training is based on a federated learning framework. After the sequence prediction network is updated locally on each cache node, the parameters are aggregated through the secure aggregation service. After the parameter aggregation is completed, the digest generated by the model hash and the root commitment is calculated and written into the distributed ledger.

8. A Redis cache management device, used to implement the Redis cache management method according to any one of claims 1-7, characterized in that, include: The event generation module is used to intercept database write operations at the object-relational mapping layer, extract entity identifiers, operation types, change fields, data mode versions and hybrid logical clock timestamps, encapsulate them into domain events with digital signatures and generate random challenge values, and then submit the domain events and corresponding database transactions to the event bus through distributed transactions. The log building module is used to aggregate the domain events into event blocks according to the receiving order and write them into the consistent data log, calculate the integrity commitment for the event blocks and generate the root commitment, write the root commitment and random challenge value into the log metadata, and copy the event blocks to decentralized storage. The projection governance module is used to verify the integrity of event logs on cache nodes based on root commitments and random challenge values. After verification, it sequentially consumes event blocks, generates a converged state mapping and writes it to Redis using a conflict-free copy data type merging algorithm, and performs shard migration and refreshes random challenge values ​​based on real-time key popularity. The prefetch verification module is used to predict the prefetch key set based on the key heat and root commitment using a distributed model training method and preheat the cache copy. After homomorphic encryption of the local gradient and addition of differential privacy noise, it participates in secure aggregation to update the distributed model parameters. The updated model hash and root commitment are used to generate a digest, which is written to the distributed ledger through a verifiable proof mechanism, and the digest is synchronized to the data log to close the integrity, governance and prefetch loop.

9. A computer device, characterized in that, Including processor and storage media; The storage medium is used to store instructions; and The processor is configured to operate according to the instructions to perform the steps of the Redis cache management method according to any one of claims 1 to 7.

10. A storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the Redis cache management method according to any one of claims 1 to 7.

Images