A method and system for elastic scaling of a distributed cache pool

Abstract

This application provides a method and system for elastic scaling of a distributed cache pool, including: obtaining the amount of free memory on a node, and determining regions to be contributed or reclaimed based on a comparison with high-water mark or low-water mark thresholds; performing handle operations through a handle pool interface to obtain pre-allocated fast-registered memory handles for regions to be contributed and update their mappings, and clearing the mappings of regions to be reclaimed and returning them; when a region to be contributed is only used for remote read cache data, selecting handles with at least remote read permissions and immediately pushing them into the pool, setting a recalculation tolerance window for regions to be reclaimed, adjusting the aging period and the number of fixed-retain handles according to the reclamation step size; and updating the global address mapping table to complete vertical scaling. This application utilizes cache recalculation to relax handle attribute matching conditions, replaces RDMA silent waiting with a recalculation tolerance window, and links the aging period with the reclamation step size to achieve fine-grained high-frequency elastic scaling.

Description

Technical Field

[0001] This invention belongs to the field of operating system technology, and in particular relates to an elastic scaling method and system for distributed cache pools. Background Technology

[0002] In a distributed cache pool built using an RDMA network, nodes contribute their local free memory as remotely accessible cache regions and elastically scale based on changes in local service memory load. This scaling process involves RDMA memory registration operations during memory contribution and deregistration operations during memory reclamation. A single registration requires sequentially completing physical page locking, address traversal, memory translation table construction, and IOMMU mapping establishment, with latency reaching tens of microseconds. To achieve fine-grained, high-frequency scaling, the above registration overhead needs to be reduced to an extremely low level. A fast-registration memory region handle pool provides the foundation for this. By pre-allocating and reusing handles, it simplifies the registration operation to address mapping updates, thus enabling sub-second scaling. However, handle reuse faces three constraints under high-frequency scaling: First, the handle pool is divided according to immutable attributes, and the access permissions and vendor key attributes of different cache blocks differ. Relaxing attribute matching may lead to security risks of unauthorized access from remote ends. Second, handles need to be fixed in the pool to ensure stable pop latency, and idle handles need to be reclaimed through aging to control resource expansion. Under high-frequency scaling, the handle pop return rate is highly coupled with the aging cycle, which can easily cause resource management oscillations. That is, handles are needed immediately after being aged and released, or the pool is empty, causing the pop to fall back to the complete creation path. Third, if the RDMA operation in transit is completely silent before the mapping is cleared when reclaiming memory, the waiting time will offset the latency benefits brought by handle reuse, making it difficult to maintain high-frequency scaling. Summary of the Invention

[0003] To address how to achieve fine-grained, high-frequency elastic scaling of node memory while ensuring the security of remote memory access and the stability and controllability of memory management resources during the construction of a distributed cache pool using RDMA networks.

[0004] This application first provides a method for elastic scaling of a distributed cache pool, including: Obtain the amount of free memory in a node, and determine the memory region to be contributed or the memory region to be reclaimed based on the comparison result between the amount of free memory and the high watermark threshold or the low watermark threshold. Through the handle pool interface, handle operations are performed: a pre-allocated fast-register memory handle is obtained for the memory region to be contributed, and the physical address mapping of the handle is updated; or for the memory region to be reclaimed, the physical address mapping of the corresponding handle is cleared and the handle is returned. When the memory region to be contributed is only used for remote read cache data, handles with access permission flags that at least include remote read permissions are selected, and the handles are immediately pushed into the handle pool after being returned. A recalculation tolerance window is set for the memory region to be reclaimed. The aging period of the handle pool and the number of handles to be retained are adjusted according to the reclamation step size. Update the global address mapping table of the distributed cache pool to provide the memory region to be contributed to remote nodes for access, or remove the memory region to be reclaimed from the distributed cache pool to complete elastic scaling; The recalculation tolerance window is the period of time during which data recalculation is still allowed to be triggered by returning an error after the memory area has been reclaimed.

[0005] Optionally, the selected access permission flag includes at least a handle with remote read permission, including: When redundant copies of cached data exist in the memory region to be contributed, the access permission flag is selected to include only handles with remote read permissions; when no redundant copies exist, the access permission flag is selected to include handles with both remote read and local write permissions.

[0006] Optionally, the selection access permission flag, which includes at least a handle with remote read permission, further includes: If the subpool that fully matches the immutable properties is empty, select a handle from another writable subpool using the vendor key.

[0007] Optionally, adjusting the aging cycle of the handle pool and the number of handles to be retained based on the recycling step size includes: The number of handles to be returned within a predetermined time is predicted based on the recycling step size; the aging cycle is shortened to release the returned handles within the predetermined time; when the frequency of historical handle pop-ups exceeds the frequency threshold, the number of handles to be fixedly retained is increased.

[0008] Optionally, setting the recalculation tolerance window includes: Start a recalculation tolerance window timer; before the recalculation tolerance window timer expires, return an error response to remote read requests accessing the memory region to be reclaimed; after the recalculation tolerance window timer expires, allow local services to write to the memory region to be reclaimed.

[0009] Optionally, determining the memory region to be reclaimed includes: Cache blocks containing cold data and with redundant copies are prioritized for reclamation.

[0010] Optionally, updating the global address mapping table of the distributed cache pool includes: Send the memory region information of the memory region to be contributed to the distributed storage service, the memory region information including node identifier, offset, capacity and remote access key; or send the removal information of the memory region to be reclaimed to the distributed storage service.

[0011] Optionally, the high water level threshold and low water level threshold are set through the following steps: Obtain historical memory usage fluctuation data of the node; set the difference between the high water level threshold and the low water level threshold based on the fluctuation data, such that the difference is less than five percent of the total memory capacity.

[0012] Optional, also includes: After completing elastic scaling, the amount of free memory of the node is obtained again after one sampling period to trigger the next scaling.

[0013] This application also provides an elastic scaling system for a distributed cache pool, including a memory monitoring module, a handle management module, and a global mapping update module, wherein the memory monitoring module, the handle management module, and the global mapping update module are respectively used to perform the corresponding steps in the method described above.

[0014] After obtaining the amount of free memory on the node and determining the memory regions to be contributed or reclaimed, during the handle operation process, the distributed cache data is used for caching only and is recalculated. When the memory region to be contributed only carries remote read cache data, handles with access permission flags that at least include remote read permissions and are writable with the vendor key are selected to update the address mapping. This relaxed attribute matching approach allows more pre-allocated handles to be reused, reducing pool fragmentation. At the same time, even if the remote end initiates a write operation with redundant permissions, it only destroys the recalculated cache data, eliminating the security risks brought about by relaxed matching from the source. In the reclamation direction, based on the reclamation step size, the number of handles to be returned within a predetermined time is predicted, and the aging period is proactively shortened to be synchronized with the return rhythm. This ensures that handles returned in batches are released after a short period of idle time, avoiding handle resource expansion caused by return operations. When a large number of handles are predicted to pop up, the number of handles fixed in the pool is increased in advance to ensure that there are always available handles on the pop path. This eliminates pool emptiness and vicious fluctuations caused by changes in the scaling rhythm, thereby ensuring stable and controllable resources at the handle lifecycle management level. When returning a handle, the physical address mapping is cleared and the handle is immediately pushed into the handle pool. A recalculation tolerance window is set for the memory region to be reclaimed. Within the window, an error indication is returned to the remote read request to trigger data recalculation. This data recalculation mechanism under cache semantics replaces the silent process of waiting for RDMA operations in transit, decoupling the handle reclamation completion time from the remote access safety point, thereby eliminating latency in the reclamation path. Finally, the global address mapping table is updated to complete this round of scaling. The above process unifies the three stages of handle attribute selection, lifecycle control, and memory cleanup under the premise of cache recalculation. The security risks of relaxed matching are mitigated by cache recalculation, the oscillations in resource management are absorbed by the aging and pre-retention mechanism linked to the step size, and the reclamation latency is replaced by the recalculation tolerance window. Each method takes the output of the previous method as its own operating premise, and together they achieve fine-grained high-frequency elastic scaling of node memory while ensuring the security of remote memory access and the stability and controllability of memory management resources. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart of the steps of the elastic scaling method for a distributed cache pool in the embodiments of this application; Figure 2 This is one of the flowcharts of the elastic scaling method for a distributed cache pool in the embodiments of this application; Figure 3 This is the second step flowchart of the elastic scaling method for a distributed cache pool in the embodiments of this application; Figure 4 This is a structural block diagram of an elastic scaling system for a distributed cache pool according to an embodiment of this application. Detailed Implementation

[0017] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not limiting, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may be practiced in other instances without such specific details. In other instances, detailed descriptions of well-known methods, systems, apparatuses, or operations have been omitted to avoid unnecessary ambiguity in this application.

[0018] In this embodiment, the application operates on distributed cache pool nodes interconnected via a remote direct memory access network. Each node pre-deploys a fast-register memory region pooling infrastructure. It should be noted that the fast-register memory region pool is organized into multiple sub-pools using a red-black tree based on immutable attributes, including access permission flags, address translation service capabilities, vendor keys, and direct memory access block size. Each sub-pool maintains a fixed-reservation handle linked list and a regular handle linked list, and provides handle pop and push interfaces. The node's elastic scaling monitoring coroutine collects the amount of free memory at configurable intervals and makes contribution or reclamation decisions based on high-water level and low-water level thresholds.

[0019] In this embodiment, the initialization process of the fast-register memory region pool is executed when the node starts. The system first reads the configuration file to obtain pooling parameters, including the initial number of handles, maximum number of handles, fixed-reservation number of handles, default aging period, and handle creation timeout for each sub-pool. Then, it creates corresponding sub-pools based on the supported immutable attribute combinations. During the initialization of each sub-pool, a specified number of fast-register memory handles are pre-created. The pre-creation process includes steps such as calling the driver interface to allocate handle objects, locking physical memory pages, constructing a memory translation table, and establishing input / output memory management unit mappings. After pre-creation, these handles are added to the ordinary handle list, waiting to be allocated. Handles in the fixed-reservation handle list are marked as non-aging and will not be released even if they are not used for a long time, ensuring that available handles can still be quickly obtained under high load conditions.

[0020] In this embodiment, each node of the red-black tree corresponds to an immutable attribute combination, and the node stores a pointer to the corresponding sub-pool. The keys of the red-black tree are formed by concatenating immutable attributes in a predetermined order, ensuring that handles with the same attribute combination are organized into the same sub-pool. When it is necessary to search for a sub-pool matching a specific attribute, the system generates the corresponding key based on the requested attribute and then searches in the red-black tree. The self-balancing property of the red-black tree ensures that the time complexity of the search operation is always logarithmic, maintaining high search efficiency even when the number of sub-pools is large.

[0021] It should be noted that the following will be a detailed explanation of the method and process of this application step by step. The implementation of each step can be adjusted according to the actual application scenario, and this application is not limited to this.

[0022] like Figure 1 As shown in the figure, this application provides an elastic scaling method for a distributed cache pool, including: S101: Obtain the amount of free memory of the node, and determine the memory region to be contributed or the memory region to be reclaimed based on the comparison result of the amount of free memory with the high watermark threshold or the low watermark threshold. S102: Through the handle pool interface, perform handle operations: obtain a pre-allocated fast-register memory handle for the memory region to be contributed, and update the physical address mapping of the handle; or for the memory region to be reclaimed, clear the physical address mapping of the corresponding handle and return the handle; when the memory region to be contributed is only used for remote read cache data, select handles whose access permission flags at least include remote read permissions, and push them into the handle pool immediately after returning the handles; set a recalculation tolerance window for the memory region to be reclaimed; adjust the aging cycle of the handle pool and the number of handles to be retained according to the reclamation step size. S103: Update the global address mapping table of the distributed cache pool to provide the memory region to be contributed to remote nodes for access, or remove the memory region to be reclaimed from the distributed cache pool to complete elastic scaling; The recalculation tolerance window is the period of time during which data recalculation is still allowed to be triggered by returning an error after the memory area has been reclaimed.

[0023] In this embodiment, the amount of free memory of a node can be obtained by reading a system memory information file. A monitoring coroutine reads the system memory information file at a configurable period to obtain the current free physical memory capacity of the node. The default value for the configurable period is 1 second, but it can be adjusted to other values, such as 0.5 seconds or 2 seconds, depending on the fluctuations in the node's memory load. The system memory information file can be read directly from the memory statistics interface provided by the operating system, or it can be obtained through system calls to obtain memory usage information.

[0024] In this embodiment, the system memory information file contains multiple memory statistics fields. The main fields used to calculate available memory include total memory, used memory, free memory, buffer memory, page cache memory, and reclaimable slab memory. When calculating available memory, the system adds free memory to the quickly reclaimable buffer memory, page cache memory, and reclaimable slab memory to obtain the total amount of memory that the system can immediately allocate to new processes. Using available memory, rather than simply free memory, as the criterion more accurately reflects the actual memory usage of the system and avoids misjudgments caused by the operating system using free memory as a cache.

[0025] In this embodiment, the system memory information file format may differ between different kernel versions. The system detects the current kernel version during initialization and selects the corresponding memory statistics field parsing method based on the kernel version. For newer kernel versions, the system can directly read the available memory field; for older kernel versions, the system calculates the available memory using a combination of the aforementioned fields. Furthermore, the system handles the statistics of large page memory, including allocated but unused large page memory in the total available memory to ensure that the use of large page memory does not affect the accuracy of elastic scaling decisions.

[0026] In this embodiment, to avoid misjudgments caused by instantaneous memory fluctuations, the system performs smoothing processing on the collected memory data. The system maintains a configurable sliding window to store memory data from the most recent sampling periods. Each time available memory is calculated, the average of all data within the sliding window is taken as the current available memory value. The default length of the sliding window is set to 5 sampling periods, but it can be adjusted to other values ​​according to actual needs. Smoothing processing effectively filters out instantaneous fluctuations caused by temporary memory allocation and release, improving the stability of elastic scaling decisions.

[0027] In this embodiment, a memory region to be contributed or a memory region to be reclaimed is determined based on a comparison between the amount of free memory and a high-watermark threshold or a low-watermark threshold. The high-watermark threshold and low-watermark threshold are proportional values ​​relative to the total memory capacity of the node, used to trigger memory contribution or reclamation operations. When the amount of free memory is greater than the high-watermark threshold, the node needs to contribute a portion of its free memory to the distributed cache pool; when the amount of free memory is less than the low-watermark threshold, the node needs to reclaim a portion of the contributed memory from the distributed cache pool.

[0028] In this embodiment, the setting of the high-water mark threshold and the low-water mark threshold needs to comprehensively consider the system's memory usage characteristics and business requirements. Setting the high-water mark threshold too high will result in insufficient memory contribution from nodes, failing to fully utilize idle memory resources; setting it too low will lead to insufficient available memory for local business operations, impacting business performance. Setting the low-water mark threshold too high will cause frequent memory reclamation operations, increasing system overhead; setting it too low will prevent nodes from timely reclamation of memory when memory is insufficient, potentially leading to memory exhaustion. The system provides default high-water mark thresholds and low-water mark thresholds, while also allowing users to adjust them according to actual business needs.

[0029] Specifically, if the amount of free memory exceeds the high-water mark threshold, the excess is calculated, which equals the amount of free memory minus the high-water mark threshold. The smaller of the excess and the preset contribution step size is taken as the contribution amount for this operation. A contiguous physical memory region of the corresponding size is allocated in the node's local free memory and marked as the memory region to be contributed. The remaining excess is processed in subsequent cycles. The preset contribution step size can be set according to the node's memory capacity and scaling requirements, for example, it can be set to 512 kilobytes, 1 megabyte, or 2 megabytes. Using a small contribution step size can avoid insufficient local business memory due to contributing too much memory in a single operation, and can also make the capacity growth of the distributed cache pool smoother.

[0030] In this embodiment, the allocation of contiguous physical memory regions is implemented based on the operating system's buddy system. The system first attempts to allocate a contiguous physical memory block of the specified size, prioritizing the free block that best matches the requested size. If a free block of the corresponding size does not exist, the system splits a larger free block into two equal buddy blocks until a block meeting the requirements is obtained. After allocation, the system marks the memory region as allocated and prevents the operating system from using it for other purposes. To improve the success rate of memory allocation, the system reserves a certain proportion of contiguous physical memory during initialization, specifically for contributing memory to the distributed cache pool.

[0031] In this embodiment, the alignment requirements for memory regions depend on the size of the memory pages used. If using standard 4KB pages, the memory region needs to be aligned to 4KB; if using 2MB transparent big pages, the memory region needs to be aligned to 2MB; and if using 1GB giant pages, the memory region needs to be aligned to 1GB. Alignment improves memory access efficiency and avoids performance degradation caused by cross-page access. The system automatically satisfies the alignment requirements when allocating memory. If it cannot allocate contiguous memory that meets the alignment requirements, the system will attempt to allocate smaller blocks or wait for memory reclamation before attempting allocation again.

[0032] In this embodiment, the use of large page memory can significantly improve the performance of remote direct memory access. The system supports two large page modes: transparent large pages and giant pages. For transparent large pages, the system automatically merges consecutive 4KB pages into 2MB large pages without user intervention; for giant pages, the user needs to pre-allocate a specified number of 1GB giant pages at system startup. When allocating memory regions to be contributed, the system will prioritize the use of large page memory to improve cache access performance. If large page memory is insufficient, the system will fall back to using ordinary 4KB pages.

[0033] In this embodiment, when contiguous memory allocation fails, the system takes a series of degradation measures. First, the system attempts to allocate smaller memory blocks, for example, by halving the contribution step size and then trying again. If this still fails, the system triggers a memory reclamation operation, reclaiming some reclaimable cache memory, and then attempts to allocate again. If contiguous memory cannot be allocated after multiple attempts, the system temporarily stops the memory contribution operation and records an error log. Simultaneously, the system notifies the distributed storage service that the node is temporarily unable to contribute memory, so that the distributed storage service can adjust its cache scheduling strategy.

[0034] Specifically, if the amount of free memory is less than the low watermark threshold, the insufficient amount is calculated, which equals the low watermark threshold minus the amount of free memory. From the memory regions already contributed to the distributed cache pool by nodes, one or more regions with a total size not less than the insufficient amount are selected and marked as memory regions to be reclaimed. The selection strategy prioritizes cache blocks storing cold data with redundant replicas, followed by cache blocks storing cold data without redundant replicas, and finally free cache blocks. Cold data is determined by comparing the access timestamp with a preset hot / cold threshold; cache data with access timestamps earlier than the preset hot / cold threshold is considered cold data. The preset hot / cold threshold can be set according to the access characteristics of the cached data, for example, it can be set to 60 seconds, 300 seconds, or 600 seconds. Redundant replicas are determined by the consistency of the hash fingerprints of cache blocks; cache blocks with the same hash fingerprint are considered redundant replicas. Prioritizing the reclamation of cold data and cache blocks with redundant replicas can minimize the impact on the cache hit rate, because cold data is accessed less frequently, and the existence of redundant replicas means that even if one replica is reclaimed, other nodes still have the same data.

[0035] In this embodiment, each cache block corresponds to a metadata structure, which stores information such as the cache block's key, value length, access timestamp, hash fingerprint, number of replicas, replica node list, creation time, and last modification time. The metadata structure is stored in the node's local memory and is periodically synchronized to the distributed storage service to ensure metadata consistency. When a cache block needs to be accessed, the system first searches the local metadata to obtain the cache block's address and access permissions, and then performs a remote direct memory access operation.

[0036] In this embodiment, the access timestamp update employs an approximate Least Recently Used (LRU) algorithm to reduce the overhead of update operations. The system does not update the access timestamp immediately every time a cache block is accessed. Instead, it maintains an access counter, and only updates the access timestamps of a batch of cache blocks when the access counter reaches a preset threshold. The preset threshold is set to 1000 accesses by default, but can be adjusted according to actual needs. This approach significantly reduces the impact of timestamp update operations on system performance while still accurately reflecting the access frequency of cache blocks.

[0037] In this embodiment, a secure hash algorithm is used to calculate the hash fingerprint, with the calculation granularity being the entire cache block. When data is written to a cache block, the system calculates the hash fingerprint of that cache block and stores it in the metadata structure. When it is necessary to determine whether two cache blocks are redundant copies, the system compares their hash fingerprints. If the hash fingerprints are the same, the two cache blocks are considered to store the same data and are redundant copies of each other. To avoid misjudgments caused by hash collisions, the system also compares the length of the cache blocks and some key data to ensure the accuracy of the redundant copy determination.

[0038] In this embodiment, the management of redundant replicas is uniformly handled by the distributed storage service. When a cache block is written to the distributed cache pool, the distributed storage service determines how many redundant replicas to create based on the cache block's popularity and importance, and distributes the replicas to different nodes. The replica creation process is asynchronous and does not block the main write operation. When the cache block data is updated, the distributed storage service notifies all replica nodes to update the replica data, ensuring consistency between replicas. When a cache block is deleted, the distributed storage service notifies all replica nodes to delete the corresponding replica.

[0039] In this embodiment, the reclamation priority is calculated using a quantitative method, comprehensively considering factors such as the access frequency, number of replicas, data size, and data importance of the cache block. The formula for calculating the reclamation priority is: Reclamation Priority = Access Frequency × Weight 1 + Number of Replicas × Weight 2 + Data Size × Weight 3 + Data Importance × Weight 4. Wherein, cache blocks with higher access frequency, fewer replicas, smaller data size, and higher data importance have lower reclamation priority and are less likely to be reclaimed; conversely, those with higher reclamation priority are more likely to be reclaimed. The weight values ​​can be adjusted according to actual business needs. By default, the weight for access frequency is 0.6, the weight for the number of replicas is 0.3, the weight for data size is 0.1, and the weight for data importance is 0.0.

[0040] In this embodiment, batch reclamation can significantly improve the efficiency of memory reclamation. When multiple cache blocks need to be reclaimed, the system sorts these cache blocks by address order and then performs reclamation operations sequentially. Reclaiming by address order can improve the efficiency of memory merging because adjacent memory blocks can be merged into larger contiguous memory blocks after reclamation. At the same time, the system merges multiple handle return operations into a single batch operation, reducing the number of accesses to the handle pool and lowering the overhead of lock contention.

[0041] In this embodiment, for hot data cache blocks that need to be reclaimed, the system first migrates the data to other nodes before reclaiming it. The data migration process is coordinated by the distributed storage service. The distributed storage service first selects one or more suitable target nodes, and then notifies the source node to transfer the cache block data to the target nodes. After the data transfer is completed, the distributed storage service updates the global address mapping table, pointing the original address to the new target node. Finally, the source node reclaims the memory area corresponding to the cache block. During the data migration process, the system limits the migration bandwidth to avoid affecting normal business traffic.

[0042] In this embodiment, the system takes appropriate measures when reclamation fails. If reclamation fails because the memory region is in use, the system marks the cache block as pending reclamation and attempts to reclaim it again later. If reclamation fails because data migration fails, the system selects another target node to remigrate again, or abandons reclamation of the cache block and reclaims other cache blocks instead. If multiple reclamation attempts still fail, the system records an error log and notifies the distributed storage service that the node's memory reclamation capability is limited.

[0043] In this embodiment, handle operations are performed through a handle pool interface. The handle pool interface includes a handle pop-up interface and a handle push-in interface. The handle pop-up interface is used to obtain an available fast-register memory handle from the handle pool, and the handle push-in interface is used to return an unused fast-register memory handle to the handle pool.

[0044] In this embodiment, the function prototype of the handle popping interface includes parameters such as a handle pool pointer, the requested attribute combination, and a timeout period. The return value is a pointer to a quickly registered memory handle. When the handle popping interface is called, the system first searches for the corresponding sub-pool in a red-black tree based on the requested attribute combination. If a matching sub-pool is found, the system attempts to pop a usable handle from that sub-pool. If a usable handle exists in the sub-pool, the system removes the handle from the linked list and returns it to the caller; if no usable handle exists in the sub-pool, the system attempts to create a new handle. The process of creating a new handle includes steps such as calling the driver interface to allocate a handle object, locking physical memory pages, constructing a memory translation table, and establishing an input / output memory management unit mapping. If creation is successful, the system returns the new handle to the caller; if creation fails, the system returns a null pointer and sets an error code.

[0045] In this embodiment, the function prototype of the handle push interface includes parameters such as a handle pool pointer and a pointer to a fast-registered memory handle, and returns an integer error code. When the handle push interface is called, the system first searches for the corresponding sub-pool in the red-black tree based on the handle's immutable attribute. If a matching sub-pool is found, the system adds the handle to the head of the ordinary handle linked list and updates the sub-pool's statistics. If the number of ordinary handles in the sub-pool exceeds the maximum handle limit, the system triggers an aging operation, releasing some handles that have not been used for a long time. If no matching sub-pool is found, the system creates a new sub-pool and adds the handle to the new sub-pool's ordinary handle linked list.

[0046] In this embodiment, concurrent access to the handle pool in a multi-threaded environment is protected using spinlocks. Each sub-pool has an independent spinlock. When multiple threads access the same sub-pool simultaneously, they must first acquire the spinlock of that sub-pool before performing handle popping or pushing operations. The spinlock holding time is very short, typically only a few instruction cycles, therefore it does not significantly impact system performance. For high-concurrency scenarios, the system also supports using lock-free data structures to implement the handle pool, further improving concurrent access performance.

[0047] Specifically, a pre-allocated fast-register memory handle is obtained for the memory region to be contributed, and the physical address mapping of this handle is updated. The fast-register memory handle is a pre-created and initialized memory registration handle containing information such as physical page locking, address translation table construction, and I / O memory management unit mapping. By reusing the pre-allocated fast-register memory handle, the complete initialization process can be avoided every time memory registration occurs, thus significantly reducing memory registration latency. After obtaining the handle, a driver-layer callback function is called to update the physical address range pointed to by the underlying hardware object of the handle to the address range of the memory region to be contributed. This operation only modifies the address mapping and does not involve physical page locking or unlocking, because the memory region to be contributed already resides in physical memory. After the update is complete, the memory region becomes visible to the remote direct memory access network card, and the memory translation table and I / O memory management unit mapping framework allocated when the handle was created are reused.

[0048] In this embodiment, the driver-layer callback function serves as the interface for interaction with the specific network interface card (NIC) driver. Different NIC drivers from different manufacturers may provide different callback function interfaces. The system detects the NIC type during initialization and loads the corresponding driver-layer callback function. The main function of the callback function is to update the physical address range of the fast-registered memory handle to the specified address range. The update process includes modifying entries in the hardware memory translation table and updating the mapping relationships in the input / output memory management unit (I / O memory). After the callback function completes execution, it returns a status code indicating whether the update operation was successful.

[0049] In this embodiment, the address mapping update operation is guaranteed to be atomic. The system uses hardware-provided atomic operations to update memory translation table entries, ensuring that partial updates do not occur during the update process. If a hardware error or other abnormal situation occurs during the update process, the system will roll back all modifications made, restoring the handle to its state before the update. This atomicity guarantee avoids remote direct memory access errors caused by inconsistent address mappings.

[0050] In this embodiment, when handle acquisition fails, the system takes corresponding measures. If handle acquisition fails because the sub-pool is empty and creating a new handle fails, the system will attempt to acquire a handle from another sub-pool with compatible attributes. If a handle still cannot be acquired, the system will temporarily suspend memory contribution operations and record an error log. Simultaneously, the system will notify the distributed storage service that the node is temporarily unable to contribute memory so that the distributed storage service can adjust its cache scheduling strategy. The system will periodically retry acquiring handles, and once a usable handle is available in the handle pool, it will resume memory contribution operations.

[0051] In this embodiment, when an address update fails, the system takes corresponding measures. If the address update fails due to an invalid memory region or insufficient permissions, the system releases the handle and attempts to acquire a new handle. If the address update fails due to a hardware error, the system logs the error and attempts to reset the network card. If multiple update attempts still fail, the system temporarily suspends memory contribution operations and notifies the administrator to investigate.

[0052] Specifically, for memory regions to be reclaimed, the physical address mapping of the corresponding handle is cleared before the handle is returned. When memory needs to be reclaimed, the driver layer callback function is first called to clear the physical address mapping in the fast-registered memory handle corresponding to that region, so that the remote direct memory access network card can no longer access that memory region through that handle. Then, the handle push interface is immediately called to push the handle into the sub-pool corresponding to its attribute, without waiting for remote direct memory access operations in transit to be silent.

[0053] In this embodiment, the operation of clearing the physical address mapping is also implemented through a driver layer callback function. The callback function marks the corresponding entry in the hardware memory translation table as invalid and updates the mapping relationship in the input / output memory management unit. After clearing, the remote direct memory access network card will no longer be able to access the memory region through this handle, and any attempt to access this address will return an error.

[0054] In this embodiment, handle state management includes states such as idle, allocated, in use, and being reclaimed. When a handle is waiting to be allocated in the sub-pool's linked list, it is in the idle state; when a handle is returned to the caller by the pop interface, it is in the allocated state; when a handle is used to access a memory region, it is in the in use state; and when a handle is pushed back to the sub-pool by the push interface, it is in the reclaiming state. The system tracks the state of each handle and performs corresponding processing based on the state. For example, a handle in the reclaiming state will not be immediately reassigned and must wait until the recalculation tolerance window ends before it can be used again.

[0055] In this embodiment, when the memory region to be contributed is only used for remote read cache data, the access permission flag is selected to include handles with at least remote read permissions. Remote read cache data refers to data in this memory region that is only accessed by remote nodes through remote direct memory access (RDA) one-sided read operations; neither the local node nor the remote node performs write operations on this region. For this type of memory region, the attribute matching conditions for the handle can be relaxed, selecting handles with at least remote read permissions instead of strictly matching all immutable attributes.

[0056] Specifically, when the memory region to be contributed is only used for remote read cache data, the first step is to locate the sub-pool in the red-black tree where the immutable attributes completely match the requested attributes. If there is a usable handle in this sub-pool, it is popped directly, prioritizing the popping of fixed-reservation handles, followed by ordinary handles. Fixed-reservation handles are a certain number of handles pre-reserved in the handle pool and will not be aged out to ensure that usable handles can still be quickly obtained when the handle pool is under high load. If the completely matching sub-pool is empty, the search continues for other sub-pools where the access permission flag in the immutable attributes at least includes remote read permissions and the vendor key is writable. The handle is popped from the matching sub-pool. At this point, the handle's permissions may exceed the minimum permissions actually required for the memory region, but security is still guaranteed by the recomputability of the cache. If there is still no usable handle, pool expansion is triggered, and a new handle is created according to the characteristic parameters of the most lenient matching sub-pool. The new handle is popped after completing full initialization such as physical page locking and input / output memory management unit mapping.

[0057] In this embodiment, the matching priority of different attribute combinations is arranged in descending order as follows: exact match, access permission includes and vendor key exactly matches, access permission includes and vendor key is writable, and access permission includes and vendor key does not match. The system will search for matching sub-pools in this priority order until a usable handle is found. This priority setting can maximize the handle reuse rate while ensuring security.

[0058] In this embodiment, the degradation strategy is configurable. The system allows users to adjust degradation rules according to security requirements, such as prohibiting the use of handles with mismatched vendor keys, or restricting degradation to only specific types of cached data. Users can adjust the degradation strategy through configuration files or a dynamic configuration interface, and the system will automatically adjust the handle matching logic according to the new strategy.

[0059] In this embodiment, quantitative analysis of security boundaries is used to assess the security risk level corresponding to different degrees of degradation. The system categorizes security risks into three levels: low, medium, and high. A handle with a perfect match corresponds to a low-risk level; a handle with access permissions that include the vendor key and a perfect match corresponds to a medium-risk level; and a handle with access permissions that include the vendor key and a writable vendor key corresponds to a high-risk level. Users can set the maximum allowed risk level according to the security requirements of their business. If the risk level corresponding to the currently matched sub-pool exceeds the maximum allowed risk level, the system will abandon the use of the sub-pool's handle and instead create a new handle.

[0060] In the embodiments of this application, the degradation rules differ for different scenarios. For read-only cache scenarios, since the data will not be modified, even if a handle with higher privileges is used, it will not cause data corruption, so a more lenient degradation rule can be adopted. For read-write cache scenarios, since the data may be modified, a stricter degradation rule is required to avoid data inconsistency caused by mismatched privileges. For temporary cache scenarios, since the data lifecycle is short, even if data corruption occurs, the impact is small, so the most lenient degradation rule can be adopted.

[0061] In this embodiment, a supplementary permission check mechanism is used to further reduce the security risks associated with downgrades. The system periodically checks permissions during handle usage to ensure that the handle's permissions match the actual needs of the memory region. Simultaneously, the system restricts the scope of remote write operations, allowing write operations only within specified memory regions. For memory regions using downgraded handles, the system prohibits remote atomic operations to prevent data corruption due to atomic operation failures.

[0062] It's important to note that for non-remote read scenarios—where cached data needs to be written locally before being read remotely—a handle with access permission flags that include both remote read and local write permissions and whose vendor keys match exactly must be selected; attribute downgrading should not be performed. This is because in these scenarios, the local node needs to perform write operations on the memory region, and using a handle with mismatched permissions could lead to write failures or data corruption.

[0063] In this embodiment, the handle is immediately pushed into the handle pool after being returned, and a recalculation tolerance window is set for the memory region to be reclaimed. The recalculation tolerance window is a period of time during which data recalculation is still allowed by returning an error after the memory region has been reclaimed. During the recalculation tolerance window, although the memory region has been removed from the global address mapping table, its physical pages have not yet been reassigned to local services or rewritten. When the distributed storage service receives a remote read request for this memory region, it returns an error indication that the data is unavailable, triggering the requester to recalculate and generate data from the original data source using the recalculation capability of the cached data. During the window, local services are prohibited from writing to this memory region. After the recalculation tolerance window timer expires, the window closes, and the memory region is officially returned to the node operating system, allowing local services to use it freely.

[0064] In this embodiment, the recalculation tolerance window duration employs a dynamic adjustment mechanism. The system monitors factors such as network latency, system load, and data importance in real time, and dynamically adjusts the window duration accordingly. When network latency is high, the system appropriately extends the window duration to ensure that all pending requests can be processed within the window period; when system load is high, the system appropriately shortens the window duration to accelerate memory reclamation; for highly important data, the system appropriately extends the window duration to reduce the probability of recalculation. The default adjustment range for the window duration is set to 50 milliseconds to 200 milliseconds, but it can also be adjusted according to actual needs.

[0065] In this embodiment, a memory protection mechanism during the window period is used to prevent local business operations from writing to the memory region. The system uses memory protection key technology to set the page table permissions of the memory region to be reclaimed to read-only. Any local operation attempting to write to this memory region will trigger a memory protection exception, which the system will catch and reject the write operation. Memory protection key technology can quickly switch access permissions for memory regions without modifying the page table, and is highly efficient.

[0066] In this embodiment, error responses are categorized into several types, including data not found, data expired, and node failure. Different types of error responses correspond to different processing logic. For a data not found error, the client will directly recalculate the data from the original data source. For a data expired error, the client will first attempt to retrieve the data from other replica nodes; if that fails, it will then recalculate. For a node failure error, the client will wait for a period of time and then retry; if the retry still fails, it will then recalculate. The error response format includes an error code, error description, and suggested handling methods, allowing the client to take appropriate actions based on this information.

[0067] In this embodiment, the recalculation process includes steps such as retrieving data from the original data source, recalculating the result, and updating the cache. When the client receives an error response indicating that the data is unavailable, it first checks if there is a backup of the data locally. If there is a backup, the client will directly use the backup data; otherwise, the client will retrieve the original data from the original data source and then recalculate the result according to the predetermined calculation logic. After the calculation is completed, the client will write the result to a distributed cache pool for subsequent access. During the recalculation process, the client will use a request merging mechanism to combine multiple identical recalculation requests into one, avoiding resource waste caused by duplicate calculations.

[0068] In this embodiment, the synchronization mechanism between the window and the global mapping update ensures that the global mapping update is completed before the window begins. When a node decides to reclaim a memory region, it first notifies the distributed storage service to delete the mapping entry for that memory region. After completing the deletion operation, the distributed storage service returns a confirmation message to the node. Only after receiving the confirmation message will the node start the recalculation tolerance window timer. This synchronization mechanism ensures that when the window begins, all new requests will no longer be routed to that memory region; only requests already in transit may access that address.

[0069] In this embodiment, memory access monitoring during the window period is used to count the number of requests in transit and assess whether the window duration is appropriate. The system records the number and time of all requests accessing the memory region during the window period. If a large number of requests still access the address before the window ends, it indicates that the window duration is set too short, and the system will appropriately extend the next window duration; if no requests access the address during the window period, it indicates that the window duration is set too long, and the system will appropriately shorten the next window duration. Through this adaptive adjustment mechanism, memory reclamation time can be minimized while ensuring safety.

[0070] In this embodiment, the memory cleanup mechanism after timeout is used to formally return the memory region to the node operating system. When the recalculation tolerance window timer expires, the system first removes the memory protection of the memory region and restores the page table permissions to read and write. Then, the system adds the memory region to the local free memory list and attempts to merge it with adjacent free memory blocks to form a larger contiguous memory block. Finally, the system notifies the operating system that the memory region has been released and can be reallocated to other processes.

[0071] In this embodiment, the aging period of the handle pool and the fixed number of handles retained are adjusted according to the recycling step size. The recycling step size refers to the total memory capacity to be recycled this time. The number of handles to be returned to the handle pool in this recycling can be estimated based on the recycling step size. By adjusting the aging period of the handle pool and the fixed number of handles retained, a large number of handles can be avoided from accumulating in the pool for a long time, causing resource bloat. At the same time, it can also prevent the handle pool from being empty, causing the pop operation to roll back to the complete creation path.

[0072] Specifically, based on the current recycling step size and the average size of a single cache block, the number of handles to be returned to the handle pool in this recycling is estimated. The return duration is calculated, which equals the number of handles to be returned multiplied by the time taken for a single push operation and address clearing operation. The aging period of the handle pool is temporarily adjusted via the configuration interface to the return duration minus a preset offset, ensuring that the batch of returned handles are aged and released precisely after a short idle period, avoiding a large accumulation of handles in the pool and causing resource bloat. The preset offset can be set according to the actual performance of the system, for example, it can be set to 100 milliseconds. At the same time, the monitoring coroutine queries the recent handle popping frequency. If the popping frequency has consistently exceeded the threshold for several periods in the past, the number of fixed-reservation handles in the pool is increased by the preset number via the configuration interface before recycling begins, reserving available handles for possible concentrated contributions after recycling and preventing the pool from becoming empty.

[0073] In this embodiment, the average size of a single cache block is obtained by statistically analyzing the sizes of cache blocks reclaimed in historical reclamation operations. The system maintains a statistics window to store the sizes of cache blocks reclaimed in the most recent reclamation operations. Each time the average size is calculated, the average of all data within the statistics window is taken. The default length of the statistics window is set to 100 reclamation operations, but it can be adjusted according to actual needs. As the system runs, the average size is continuously updated to reflect the changing trend of cache block sizes.

[0074] In this embodiment, the time taken for a single push operation and address clear operation is obtained through benchmark testing. During system initialization, a series of benchmark tests are performed to measure the time taken for a single push operation and address clear operation under different hardware configurations. Simultaneously, the system periodically re-executes the benchmark tests during operation to update the time taken data. The time taken data is stored in a configuration file for use in calculating the return duration.

[0075] In this embodiment, the setting of the preset offset needs to take into account factors such as system scheduling latency and interrupt handling time. Setting the offset too large will cause handles to age and be released prematurely, increasing the latency of subsequent handle acquisition; setting the offset too small will cause handles to accumulate in the pool for a long time, resulting in resource waste. The system provides a default offset value and allows users to adjust it according to actual system performance.

[0076] In this embodiment, the statistical window for handle pop-up frequency is set to the past 10 sampling periods by default, but can be adjusted according to actual needs. The system calculates the average frequency of all pop-up operations within the statistical window as the current handle pop-up frequency. To avoid misjudgments caused by sudden peaks, the system uses an exponential moving average algorithm to smooth the pop-up frequency. The exponential moving average algorithm assigns higher weight to recent data, which can more accurately reflect the current handle demand trend.

[0077] In this embodiment, the increase in the fixed number of reserved handles is adjusted according to the pop-up frequency. When the pop-up frequency exceeds a threshold, the system will increase the fixed number of reserved handles by a certain percentage, such as 20%. The increased fixed number of reserved handles cannot exceed a preset maximum value to avoid wasting resources by retaining too many handles. The preset maximum value is set to 20% of the maximum number of handles in the sub-pool by default, but can also be adjusted according to actual needs.

[0078] In this embodiment, a smooth transition mechanism for aging period adjustment is used to avoid system instability caused by sudden, large adjustments. When the aging period needs to be adjusted, the system does not immediately set the aging period to the target value, but adjusts it gradually, by a certain percentage each time, until the target value is reached. For example, the system can adjust the aging period to 80% of the current value each time until the target value is reached. A smooth transition can avoid a large release or accumulation of handles due to sudden changes in the aging period.

[0079] In this embodiment, the adjusted recovery mechanism restores the aging period and the number of fixed-reservation handles to their default values ​​after recycling is complete. The system starts a recovery recalculation tolerance window timer after the recycling operation is completed; the default duration of the recalculation tolerance window timer is 5 minutes. When the recalculation tolerance window timer expires, the system gradually restores the aging period and the number of fixed-reservation handles to their default values. If a new recycling operation is triggered during the recovery process, the system resets the recovery recalculation tolerance window timer and continues to use the adjusted parameters.

[0080] In this embodiment, the independent adjustment mechanism in the multi-subpool scenario allows each subpool to adjust its parameters independently based on its own usage. Subpools with different attribute combinations may have different usage frequencies and load characteristics, thus requiring different aging periods and fixed reserved handle counts. The system maintains independent statistical data and parameters for each subpool, and independently adjusts its aging period and fixed reserved handle count based on each subpool's recycling step size and pop frequency.

[0081] In this embodiment, the resource usage threshold is set to prevent the handle pool from consuming excessive system resources. When the memory occupied by the handle pool exceeds a preset proportion of the total memory, the system will force the aging out of some handles, even if the aging period of these handles has not yet ended. The preset proportion is set to 5% by default, but can be adjusted according to actual needs. The forced aging out operation will prioritize releasing the handles that have not been used for the longest time to minimize the impact on system performance.

[0082] In this embodiment, the global address mapping table of the distributed cache pool is updated to provide memory regions to be contributed to remote nodes for access, or to remove memory regions to be reclaimed from the distributed cache pool, thus achieving elastic scaling. The global address mapping table is a global data structure maintained by the distributed storage service to record information about all memory regions in the distributed cache pool, including node identifier, offset, capacity, and remote access key.

[0083] Specifically, during a contribution operation, the memory region information of the memory region to be contributed is registered in the global address mapping table of the distributed storage service. The memory region information includes a node identifier, offset, capacity, and remote access key. The node identifier uniquely identifies the node contributing the memory, the offset indicates the starting address of the memory region in the node's local memory, the capacity indicates the size of the memory region, and the remote access key is used for authentication when remote nodes access the memory region.

[0084] Specifically, during the reclamation operation, the entry for the memory region to be reclaimed is removed from the global address mapping table. After deletion, the distributed storage service broadcasts this capacity change event to other nodes in the cluster, enabling clients and nodes on other nodes to be aware of the cache pool capacity update. After the contribution operation is completed, remote nodes can access the newly contributed memory region through remote direct memory access one-sided read operations; after the reclamation operation is completed, remote nodes will no longer send requests to the reclaimed address, or trigger a recalculation after receiving an error indication during the recalculation tolerance window.

[0085] In this embodiment, the consistency guarantee of the distributed storage service is implemented using a consensus algorithm. The system uses a three-replica mechanism to store the global address mapping table, with each replica stored on a different node. When the global address mapping table needs to be updated, the system first sends an update request to the primary replica node. The primary replica node writes the update operation to its log and then synchronizes the log to the other two replica nodes. Once at least two replica nodes confirm receipt of the log, the primary replica node commits the update operation and returns a success response to the client. This consensus mechanism ensures that the global address mapping table remains consistent and available even in the event of a few node failures.

[0086] In this embodiment, the broadcast mechanism is implemented using a publish-subscribe pattern. The distributed storage service maintains an event topic, which all nodes subscribe to. When the global address mapping table changes, the distributed storage service publishes the change event to this topic. All nodes subscribed to this topic receive the change event and update their locally cached global address mapping information. The publish-subscribe pattern enables one-to-many broadcasting of events, offering high efficiency and scalability.

[0087] In this embodiment, the local cache is updated incrementally. When a node receives a change event, it only updates the changed entries in the local cache, without reloading the entire global address mapping table. Incremental updates significantly reduce the overhead of update operations and improve update efficiency. Simultaneously, the system periodically performs a full update to synchronize the local cache with the global address mapping table in the distributed storage service, ensuring the consistency of the local cache.

[0088] In this embodiment, the global address mapping table employs a fragmented management approach to improve concurrency performance. The system divides the global address space into multiple contiguous fragments, each managed by an independent service node. When access to a memory region is required, the system first calculates the corresponding fragment based on the address of that memory region, and then sends the request to the service node responsible for that fragment. Fragmented management distributes the load across multiple service nodes, avoiding single points of failure and improving the system's concurrent processing capabilities.

[0089] In this embodiment, concurrent update conflict handling employs an optimistic locking mechanism. Each entry in the global address mapping table has a version number. When an entry needs to be updated, the system first reads the current version number of the entry and then includes this version number in the update request. When processing the update request, the service node checks whether the version number in the request matches the version number of the current entry. If they match, the service node updates the entry content and increments the version number by 1; if they do not match, it means that the entry has been modified by other update operations, and the service node rejects the update and returns a conflict error. Upon receiving the conflict error, the client rereads the latest version number of the entry and then attempts to update again.

[0090] In this embodiment, the persistence mechanism of the global address mapping table includes periodic snapshots and incremental logs. The system periodically generates snapshots of the global address mapping table and stores them in a persistent storage device. Simultaneously, the system records incremental logs of all update operations. When a system failure occurs and recovery is needed, the system first loads the latest snapshot, then replays all incremental logs after the snapshot, restoring the global address mapping table to its pre-failure state. The default frequency of periodic snapshots is once per hour, but this can be adjusted according to actual needs.

[0091] In this embodiment, the mapping reconstruction mechanism after a node failure is used to recover mapping information from other nodes. When a service node fails, the system automatically migrates the shards it is responsible for to other normal service nodes. The new responsible node obtains the latest data for the shard from other replica nodes and then rebuilds the global address mapping table for the shard. After the mapping reconstruction is complete, the system notifies all clients to update the shard routing information and sends the request to the new responsible node.

[0092] In this embodiment, selecting a handle with access permission flags that at least include remote read permissions includes selecting a handle with access permission flags that only include remote read permissions when redundant copies of cached data exist in the memory region to be contributed. The existence of redundant copies of cached data means that even if the data in the memory region is corrupted, it can be recovered from redundant copies on other nodes. Therefore, the handle with the lowest permissions, containing only remote read permissions, can be selected to maximize security.

[0093] In this embodiment, the redundant replica detection mechanism includes hash fingerprint comparison and replica node list checking. When it is necessary to determine whether a redundant replica of a certain cached data exists, the system first calculates the hash fingerprint of the cached data, and then queries the distributed storage service to obtain information on all cache blocks with the same hash fingerprint. If the number of cache blocks with the same hash fingerprint is greater than 1, it indicates that a redundant replica of the cached data exists. Simultaneously, the system checks whether the nodes containing these cache blocks are running normally. Only when at least one replica node is running normally is the system considered to have a usable redundant replica of the cached data.

[0094] In this embodiment, the relationship between the number of replicas and the selection of permissions is as follows: when the number of cached data replicas is greater than or equal to 3, a handle containing only remote read permissions can be selected; when the number of cached data replicas is equal to 2, a handle containing both remote read permissions and local write permissions can be selected; when the number of cached data replicas is equal to 1, a handle containing remote read permissions, local write permissions, and remote write permissions must be selected. This relationship is determined based on the data reliability requirements; the more replicas there are, the higher the data reliability, therefore a handle with lower permissions can be used.

[0095] In this application embodiment, the use cases for local write permissions include cache updates and writing pre-computation results. When a local node needs to update cached data, it needs to use a handle containing local write permissions to write the updated data to the memory area. When a local node completes a computation task and needs to write the pre-computation results to the distributed cache pool, it also needs to use a handle containing local write permissions. In these scenarios, local write permissions are mandatory; otherwise, the data writing operation cannot be completed.

[0096] In this embodiment, the data consistency guarantee method includes a version number mechanism and a timestamp mechanism. The system maintains a version number for each cache block, which is automatically incremented by 1 when the data in the cache block is updated. When a remote node reads a cache block, it simultaneously obtains the cache block's version number. If the remote node needs to update the cache block after reading, it sends the obtained version number along with the cache block to the write operation. When processing a write operation, the service node checks whether the version number in the request matches the version number of the current cache block. If they match, the service node updates the cache block content and increments the version number; if they do not match, it indicates that the cache block has been modified by other update operations, and the service node rejects the write operation and returns a conflict error. The version number mechanism can avoid data inconsistency problems caused by concurrent write operations.

[0097] In this embodiment, when there are no redundant copies of the cached data in the memory region to be contributed, a handle with access permission flags including remote read permission and local write permission is selected. The absence of redundant copies of the cached data means that the data in this memory region is unique, and if corrupted, it cannot be recovered from other nodes. Therefore, a handle with local write permission needs to be selected so that the local node can update the data in this memory region when needed, ensuring data consistency.

[0098] In this embodiment, selecting handles whose access permission flags at least include remote read permissions further includes selecting handles from other sub-pools with writable vendor keys when the sub-pools with completely matching immutable attributes are empty. Vendor keys are keys used to verify the legitimacy of remote direct memory access operations. In distributed caching scenarios, cached data is recomputable; even if certain high-level atomic operations fail due to vendor key mismatch, the data can be recovered through recomputation. Therefore, accepting handles from other sub-pools with writable vendor keys can expand the range of reusable handles and reduce pool fragmentation.

[0099] In this embodiment, vendor keys are categorized into three types: hardware vendor keys, software vendor keys, and user-defined keys. Hardware vendor keys are provided by the network interface card (NIC) manufacturer and are used to verify the legitimacy of hardware-level operations; software vendor keys are provided by the software provider and are used to verify the legitimacy of software-level operations; user-defined keys are set by the user and are used to verify the legitimacy of user-level operations. Different types of keys have different permission ranges and security levels.

[0100] In this embodiment, the security risk assessment of writable keys includes risk type analysis and impact scope assessment. Potential risks associated with writable keys include unauthorized write operations, data tampering, and information leakage. Impact scope assessment includes evaluating the probability of the risk occurring and the potential losses. In distributed caching scenarios, because cached data is recomputable, even if data tampering occurs, the data can be recovered through recomputation; therefore, the security risk of writable keys is relatively low.

[0101] In this embodiment, compatibility between keys from different vendors varies. Different network interface card (NIC) vendors may use different key formats and verification methods; therefore, using keys from other vendors may cause certain advanced operations to fail. For example, atomic operations from some NIC vendors require specific vendor keys to execute; using keys from other vendors will result in errors. The system detects the NIC type during initialization and records compatibility information for keys from different vendors for reference when selecting a handle.

[0102] In this embodiment, the key verification process includes two steps: local verification and remote verification. Local verification is performed during handle allocation, where the system checks whether the handle's vendor key is compatible with the requested key. If incompatible, the system refuses to allocate the handle. Remote verification is performed during remote direct memory access operations, where the network interface card (NIC) checks whether the key in the remote request matches the handle's vendor key. If they do not match, the NIC refuses to perform the operation and returns an error.

[0103] In this embodiment, the downgraded access restrictions include prohibiting remote atomic operations, limiting the maximum transmission length, and limiting the access frequency. Prohibiting remote atomic operations can prevent atomic operation failures due to key mismatches; limiting the maximum transmission length can reduce the scope of data corruption that may be caused by a single operation; and limiting the access frequency can prevent system overload caused by malicious attacks. These restrictions can further reduce the security risks brought about by downgrading.

[0104] It should be noted that selecting a writable handle from another sub-pool using the vendor key is only applicable to scenarios where the contributed memory region is used solely for remote read cache data. For non-remote read scenarios, strict matching of the vendor key is still required to ensure data security and consistency.

[0105] In some embodiments, such as Figure 2 As shown, adjusting the aging cycle of the handle pool and the number of handles to be retained based on the recycling step size includes: S201: Predict the number of handles to be returned within a predetermined time based on the said recycling step size; S202: Shorten the aging cycle to the predetermined time and release the returned handle; S203: When the frequency of historical handle pop-ups exceeds the frequency threshold, increase the number of handles that are fixed and reserved.

[0106] The scheduled time refers to the time required to complete this garbage collection operation. Based on the garbage collection step size and the average size of a single cache block, the number of handles to be returned in this garbage collection can be calculated. The average size of a single cache block can be obtained by statistically analyzing the sizes of cache blocks collected in historical garbage collection operations.

[0107] In this embodiment, the error handling mechanism for handle quantity prediction is used to handle the deviation between the predicted and actual values. The system records the error of each prediction and adjusts the prediction model based on historical errors. When the deviation between the predicted and actual values ​​exceeds a preset threshold, the system automatically adjusts the average size of individual cache blocks to improve the accuracy of subsequent predictions. The preset threshold is set to 20% by default, but can also be adjusted according to actual needs.

[0108] In this embodiment, the aging period is shortened to release the returned handles within a predetermined time. By temporarily shortening the aging period to synchronize with the return rhythm, the handles returned in batches can be released immediately after the buffer period is completed, avoiding prolonged occupation of memory translation tables and I / O memory management unit mapping entries, which could cause kernel memory bloat. The adjustment of the aging period is temporary; after this recycling operation is completed, the aging period will revert to its original default value.

[0109] In this embodiment, when the historical handle popping frequency exceeds a frequency threshold, the number of fixed-reservation handles is increased. The historical handle popping frequency refers to the average frequency of handle popping operations over a number of past periods. The frequency threshold can be set according to the handle pool capacity and system load. When the historical handle popping frequency exceeds the frequency threshold, it indicates a high demand for handles in the near future, necessitating an increase in the number of fixed-reservation handles to reserve available handles for upcoming contribution demands and prevent the pool from becoming empty. The increase in the number of fixed-reservation handles can be adjusted based on the historical popping frequency; for example, it can be increased by 2, 4, or 8 handles.

[0110] In this embodiment, the outlier handling mechanism for pop-up frequency is used to eliminate the impact of sudden peak values ​​on frequency calculation. The system uses the median instead of the average to calculate the pop-up frequency, or uses the interquartile range (IMR) to exclude extreme values. The median is not sensitive to outliers and can more accurately reflect the normal level of the pop-up frequency. The IMR divides the data into four parts, excludes extreme values ​​below the first quartile and above the third quartile, and then calculates the average of the remaining data.

[0111] In this embodiment, the dynamic adjustment algorithm for the fixed retention handle adopts the exponential moving average algorithm. The formula for the algorithm is: New fixed retention quantity = Old fixed retention quantity × (1-α) + Current pop-up frequency × α. Here, α is a smoothing coefficient, ranging from 0 to 1. The larger the smoothing coefficient, the higher the algorithm's sensitivity to recent data; the smaller the smoothing coefficient, the higher the algorithm's sensitivity to historical data. By default, the smoothing coefficient is set to 0.3, but it can also be adjusted according to actual needs.

[0112] In some embodiments, such as Figure 3 As shown, the setting of the recalculation tolerance window includes: S301: Start the recalculation tolerance window timer; S302: Before the recalculation tolerance window timer expires, return an error response to the remote read request accessing the memory region to be reclaimed; after the recalculation tolerance window timer expires, allow local services to write to the memory region to be reclaimed.

[0113] In this embodiment, the duration of the recalculation tolerance window timer is set to be slightly greater than the maximum possible message latency on the remote direct memory access network. The maximum possible message latency can be obtained by statistically analyzing network latency data, for example, it can be set to 100 milliseconds.

[0114] In this embodiment, the recalculation tolerance window timer is implemented using a high-precision kernel recalculation tolerance window timer. This high-precision kernel recalculation tolerance window timer can provide microsecond-level timing accuracy, meeting the timing requirements of the recalculation tolerance window. The system specifies a callback function for the recalculation tolerance window timer when it is started. When the recalculation tolerance window timer times out, the kernel automatically calls this callback function. The main function of the callback function is to close the recalculation tolerance window and return the memory area to the operating system.

[0115] In this embodiment, before the recalculation tolerance window timer expires, an error response is returned to the remote read request accessing the memory region to be reclaimed. When the distributed storage service receives a remote read request for a reclaimed memory region, it checks whether the memory region is within the recalculation tolerance window. If it is, an error response indicating that the data is unavailable is returned. After receiving the error response, the requesting party automatically reloads the corresponding data block from the original data source according to the error type to complete the recalculation.

[0116] In this embodiment, after the recalculation tolerance window timer expires, local services are allowed to write to the memory area to be reclaimed. After the recalculation tolerance window timer expires, the recalculation tolerance window closes, and the memory area is officially returned to the node operating system. At this time, local services can freely allocate and use the memory area without affecting the access security of the remote node, because all possible in-transit requests have been processed during the window period.

[0117] In this embodiment, determining the memory region to be reclaimed includes filtering cache blocks containing cold data and having redundant copies as priority memory regions to be reclaimed. Cold data refers to cache data with low access frequency, and the existence of redundant copies means that the data is also stored on other nodes. Prioritizing the reclamation of such cache blocks can minimize the impact on cache hit rate, because even if these cache blocks are reclaimed, remote nodes can still obtain data from redundant copies on other nodes, or recalculate and generate data when needed.

[0118] In this embodiment, the multi-dimensional criteria for determining cold data include access frequency, access time, data size, and data importance. Access frequency refers to the number of times a cache block is accessed per unit time; access time refers to the time when a cache block was last accessed; data size refers to the number of bytes of data stored in the cache block; and data importance refers to the degree of importance of the cache block to the business, which is marked by the user according to business needs. The system comprehensively considers these dimensions to score the coldness of the cache blocks, and cache blocks with scores below a preset threshold are judged as cold data.

[0119] In this embodiment, the consistency check mechanism for redundant replicas is used to ensure data consistency among replicas. The system periodically performs consistency checks on redundant replicas, comparing the hash fingerprints of different replicas. If inconsistent hash fingerprints are found, the system will use the latest replica as the standard and update the data on other replicas. The frequency of consistency checks is set to once a day by default, but can be adjusted according to actual needs. For data of higher importance, the frequency of consistency checks can be appropriately increased.

[0120] It's important to note that the strategy for selecting memory regions to be reclaimed can be adjusted based on the specific application scenario. For example, in some scenarios, free cache blocks can be reclaimed first, since they don't store any data and their reclamation won't affect the cache hit rate. In other scenarios, the selection can be based on the importance of the cached data, prioritizing the reclamation of less important cached data.

[0121] In this embodiment, updating the global address mapping table of the distributed cache pool includes sending memory region information of the memory region to be contributed to the distributed storage service. The memory region information includes a node identifier, offset, capacity, and remote access key. The node identifier uniquely identifies the node contributing the memory, the offset indicates the starting address of the memory region in the node's local memory, the capacity indicates the size of the memory region, and the remote access key is used for authentication when a remote node accesses the memory region.

[0122] In this embodiment, the remote access key is generated using a random number generation algorithm. The system generates a 32-bit random number as the remote access key. The key's lifespan is the same as the memory region's lifespan; when the memory region is reclaimed, the corresponding key is also destroyed. The system periodically rotates the remote access key to improve security. The default key rotation frequency is once a week, but it can be adjusted according to actual needs.

[0123] In this embodiment, updating the global address mapping table of the distributed cache pool further includes sending removal information of the memory region to be reclaimed to the distributed storage service. The removal information includes the node identifier and offset of the memory region to be reclaimed, used to uniquely identify the memory region that needs to be removed. After receiving the removal information, the distributed storage service will delete the entry for that memory region from the global address mapping table and broadcast a capacity change event to other nodes in the cluster.

[0124] In this embodiment, the high-water level threshold and low-water level threshold are set through the following steps to obtain historical memory usage fluctuation data of the node. Historical memory usage fluctuation data can be obtained by monitoring the node's memory usage over a past period, such as memory usage data for the past 7 days, 30 days, or 90 days.

[0125] In this embodiment, the default collection frequency of historical memory usage data is set to once per minute, but this can be adjusted according to actual needs. The collected data is stored in a local database, with a default retention period of 90 days. The system periodically analyzes the historical data, calculating statistical indicators such as the average, standard deviation, and peak value of memory usage to guide the setting of high-water mark and low-water mark thresholds.

[0126] In this embodiment, a difference between a high-water mark threshold and a low-water mark threshold is set based on fluctuation data, such that the difference is less than 5% of the total memory capacity. The difference between the high-water mark threshold and the low-water mark threshold is called the buffer space. The size of the buffer space determines the frequency of elastic scaling. A smaller buffer space results in a higher frequency of elastic scaling and higher memory resource utilization, but also increases system overhead. A larger buffer space results in a lower frequency of elastic scaling and lower system overhead, but also decreases memory resource utilization. Setting the difference to less than 5% of the total memory capacity can improve memory resource utilization while ensuring system stability.

[0127] In this embodiment, the adaptive adjustment mechanism between buffers is used to automatically adjust the size of the buffers based on historical fluctuation data. The system calculates the standard deviation of memory usage over a period of time. A larger standard deviation indicates greater fluctuation in memory usage, requiring a larger buffer; a smaller standard deviation indicates less fluctuation in memory usage, allowing for a smaller buffer. This adaptive adjustment ensures that the buffer size always matches the system's memory usage characteristics, maximizing memory resource utilization while maintaining stability.

[0128] It should be noted that the specific values ​​of the high-water mark threshold and the low-water mark threshold can be adjusted according to the node's service type and memory load characteristics. For example, for nodes with large fluctuations in memory load, the buffer space can be appropriately increased to reduce the frequency of elastic scaling; for nodes with small fluctuations in memory load, the buffer space can be appropriately decreased to improve the utilization of memory resources.

[0129] In this embodiment, the method further includes, after completing elastic scaling, obtaining the amount of free memory of the node again after a sampling period to trigger the next scaling. The sampling period is the running period of the elastic scaling monitoring coroutine, with a default value of 1 second. By periodically obtaining the amount of free memory of the node and making scaling decisions, the capacity of the distributed cache pool can always match the memory load of the node, ensuring the normal operation of local services and the efficient utilization of the distributed cache pool.

[0130] In this embodiment, the adaptive adjustment mechanism for the sampling period is used to automatically adjust the sampling period based on fluctuations in memory load. When memory usage fluctuates significantly, the system will appropriately shorten the sampling period to improve the response speed of elastic scaling; when memory usage fluctuates less, the system will appropriately extend the sampling period to reduce system overhead. The default adjustment range for the sampling period is set to 0.5 seconds to 5 seconds, but it can also be adjusted according to actual needs.

[0131] In this embodiment, a debouncing mechanism for scaling decisions is used to avoid frequent triggering of scaling operations. The system records the results of the most recent scaling decisions, and only executes the corresponding scaling operation if the results of multiple consecutive decisions are the same. For example, the system can be configured to execute a memory contribution operation only when three consecutive samples detect that the free memory is greater than the high-water mark threshold. The debouncing mechanism can effectively avoid frequent scaling caused by instantaneous memory fluctuations, thus improving system stability.

[0132] It should be noted that the sampling period can be adjusted based on the memory load fluctuations of the nodes. For nodes with large memory load fluctuations, the sampling period can be shortened to improve the response speed of elastic scaling; for nodes with small memory load fluctuations, the sampling period can be lengthened to reduce system overhead.

[0133] like Figure 4 As shown in the illustration, this application also provides an elastic scaling system for a distributed cache pool, comprising: The memory monitoring module 1 is used to obtain the amount of free memory of the node, and determine the memory area to be contributed or the memory area to be reclaimed based on the comparison result of the amount of free memory with the high watermark threshold or the low watermark threshold. Handle management module 2 is used to perform handle operations through the handle pool interface: obtaining pre-allocated fast-register memory handles for the memory region to be contributed and updating the physical address mapping of the handle, or clearing the physical address mapping of the corresponding handle and returning the handle for the memory region to be reclaimed; when the memory region to be contributed is only used for remote read cache data, selecting handles whose access permission flags at least include remote read permissions, and immediately pushing the handle into the handle pool after returning the handle, setting a recalculation tolerance window for the memory region to be reclaimed; adjusting the aging cycle of the handle pool and the number of handles to be retained according to the reclamation step size; The global mapping update module 3 is used to update the global address mapping table of the distributed cache pool to provide the memory region to be contributed to remote nodes for access, or to remove the memory region to be reclaimed from the distributed cache pool, thereby completing elastic scaling.

[0134] In this embodiment, the elastic scaling system for the distributed cache pool includes a memory monitoring module, a handle management module, and a global mapping update module. Each module can be implemented through software, hardware, or a combination thereof.

[0135] For example, a distributed cache pool cluster comprises multiple compute nodes, each equipped with a remote direct memory access network card and a physical memory capacity of 128 gigabytes. Nodes join the cross-node distributed cache pool, contributing idle memory as cache while running local computing services. The high-water mark threshold is 96 gigabytes, the low-water mark threshold is 93.44 gigabytes, the single scaling step is 512 kilobytes, and the monitoring cycle is 1 second. In the fast-register memory region pool, four fixed handles are reserved for the remote read-permitted writable key sub-pool, with an initial aging period of 60 seconds.

[0136] Initially, local computing services used 30 gigabytes of memory, with 98 gigabytes of free memory, exceeding the high-water mark threshold. The node had not previously contributed any cache memory.

[0137] In the first second, the monitoring coroutine calculation exceeds the limit by 2 gigabytes, and the contribution amount is determined by a step size of 512 kilobytes. A 512-kilobyte block of free physical memory is extracted and marked as a region to be contributed. This region will be used as a cache for remote nodes to read intermediate computation results, requiring only remote read permissions. The system searches for a sub-pool in the fast-register memory region pool with remote read access permissions and a writable vendor key. Since the exact matching sub-pool has an available fixed reserved handle, it is popped directly. The driver interface is called to update the handle address mapping to this 512-kilobyte region, and the distributed storage service is notified to register the memory region information, including the newly generated remote access key. After the global address mapping table is updated, other nodes can access this cache region via remote direct memory access one-way read. In the second second, the next 512 kilobytes are contributed, and the same applies to the third and fourth seconds, for a total of 2 gigabytes contributed in 4 seconds. The free memory returns to 96 gigabytes, and the contribution pauses.

[0138] Subsequently, the local computing service suddenly launched a batch of new tasks, causing memory demand to surge to 92 gigabytes and free memory to plummet to 36 gigabytes, far below the low watermark threshold. The monitoring coroutine computation required the reclamation of at least 57.44 gigabytes, but the node only contributed 2 gigabytes of cache memory; therefore, the first reclamation target was these 2 gigabytes. Of the 2 gigabytes of contributed cache data, the system identified 512 kilobytes of cache blocks that had not received any remote read requests in the past 60 seconds, classifying them as cold data, and another node in the cluster held a copy with the same hash fingerprint. This 512 kilobyte block was selected as the area to be reclaimed. The monitoring coroutine estimated that this reclamation would return one handle, corresponding to 512 kilobytes, and calculated the return duration to be approximately a few microseconds. Therefore, the aging period was temporarily adjusted to the return duration minus the offset. Due to the extremely short return duration, the aging period was set to a very small positive value, meaning the handle would be aged out almost immediately after being pushed in. Simultaneously, the system detected that the handle popping frequency was normal over the past 10 cycles, and the fixed retention quantity was not increased. The recycling process begins by calling the driver interface to clear the handle address mapping, followed immediately by calling the push interface to push the handle into the pool, and initiating a 100ms recalculation tolerance window. During this window, the distributed storage service removes the cache entry. If a remote node still initiates a read request to this address due to update latency, it will receive a data unavailable error. The node will automatically reload the corresponding data block from the model storage volume based on the error type, completing the recalculation. After the 100ms window ends, the 512 kilobytes of physical memory are merged into the local free memory pool for computing services. This round of recycling is complete. Since the 2 gigabytes already contributed are still far from meeting the 57.44 gigabyte demand after recycling, the node subsequently initiates capacity rebalancing through the global management mechanism of the distributed cache pool, requesting other free nodes to contribute more cache memory.

[0139] In this embodiment, all cached data in the distributed cache pool is recalcible, meaning it can be recalculated and generated from the preceding data source if lost. This feature allows for the adoption of strategies different from traditional business memory management during memory management. Traditional business memory management requires strict guarantees of data security and consistency; any data loss or corruption can lead to business interruption. However, in a distributed caching scenario, the loss of cached data only results in a decrease in cache hit rate; the requester can recover the data through recalculation, without causing business interruption.

[0140] In this embodiment, the attribute matching conditions for fast-registered memory handles are relaxed by leveraging the recomputability of cached data. Traditional fast-registered memory pools strictly match handles based on immutable attributes to avoid data corruption or security vulnerabilities caused by mismatched permission keys. In a distributed caching scenario, the data carried by the contributed memory area is recomputable data used only for caching, not core business data. This boundary provides a condition for attribute degradation. Even if the selected handle has more permissions than the minimum required, such as remote write permissions, if a remote node uses these extra permissions to initiate a write operation, it only damages the cached data copy, which can be regenerated from the original data source without causing irrecoverable data loss. Similarly, if the vendor key does not match completely, although it may cause some advanced atomic operations to fail, the caching business itself relies on the recomputability of the underlying data to ensure eventual consistency. Operation failure will trigger a retry or recomputation path on the client side. Therefore, in the restricted scenario of reading cached data remotely, the access permission matching condition can be relaxed from complete equality to at least include remote read permission, and the vendor key can be accepted as writable, which significantly expands the range of reusable handles and reduces pool fragmentation.

[0141] In this embodiment, a recalculation-tolerant window mechanism is implemented by leveraging the recalculation capability of cached data. Traditional remote direct memory access (RDA) memory reclamation requires waiting for all in-transit operations related to the memory region to complete before deregistering the memory. Otherwise, the remote node might read arbitrary data from memory that has been reclaimed and reassigned to local business use, leading to data logic errors. This silent waiting typically relies on polling the RDA completion queue, and the introduced latency is sufficient to offset the latency advantage of handle reuse. This application utilizes the recalculation capability of cached data, pushing the handle immediately after clearing the mapping and setting a short-lived recalculation-tolerant window. During this window, although the memory region has been removed from the global mapping table, its physical pages are not temporarily allocated for other uses, and the content is not corrupted. When a remote node attempts to access the address due to routing table update delays or ongoing read requests in the network, it receives an error response. This error is interpreted as a cache miss, and the client automatically recalculates the data from the original data source without generating data errors. Only after the window ends is the memory safely reclaimed to the local machine. This mechanism shifts the safe timing of the recycling operation from being completely silent via remote direct memory access network to a protection period where cached data can be recalculated, achieving a balance between security and low latency.

[0142] In this embodiment, the resource management oscillation problem under high-frequency scaling is solved by linking the aging period with the recycling step size. High-frequency elastic scaling deeply couples the handle lifecycle with the scaling rhythm. If the fixed number of retained handles and the aging period are static values, the following situation may occur: batch recycling leads to a large number of handles flooding into the pool and becoming idle. Before experiencing the fixed aging period, these handles continuously occupy the memory translation table and I / O memory management unit mapping entries, causing resource bloat; when a large number of contributions are suddenly needed later, if the idle handles in the pool have been aged out and released, the pop operation will fall back to the complete creation path, causing a sharp increase in scaling latency. This application predicts the number of handles to be returned by monitoring the recycling step size and proactively shortens the aging period to be synchronized with the return rhythm, so that batches of idle handles are released immediately after the buffer period is completed, avoiding long-term accumulation. At the same time, the fixed number of retained handles is replenished in advance according to the pop frequency to provide spare handles for the upcoming contribution needs and eliminate the risk of an empty pool. This adjustment mechanism, which uses the recycling step size as a feedforward signal and the historical pop-up frequency as a feedback signal, ensures that the resource usage of the handle pool always matches the actual rhythm of the scaling activity.

[0143] In this embodiment, the various technical means cooperate to achieve fine-grained, high-frequency elastic scaling of node memory while ensuring the security of remote memory access and the stability and controllability of memory management resources. Attribute compatibility degradation binding reduces pool fragmentation and improves handle reuse rate, making high-frequency scaling possible. The aging and debugging mechanism suppresses resource management oscillations and ensures stable system operation. The recalculation tolerance window mechanism eliminates latency waiting on the reclamation path, further improving the scaling response speed. These three technical means are all based on the premise of recalculation of cached data and form a complete whole. For example, without attribute compatibility degradation binding, the handle pool would be divided into a large number of fragmented sub-pools, the number of reusable handles would drop sharply, pop operations would frequently trigger the full creation path, and increase scaling latency. Even with the recalculation tolerance window mechanism, it is impossible to compensate for the latency caused by handle creation. Without the aging and debugging mechanism, a large number of handles returned in a concentrated manner would accumulate in the pool for a long time, causing kernel memory expansion and affecting system stability. Without a recalculation tolerance window mechanism, the reclamation operation must wait for remote direct memory access to be silent. The introduced latency will offset the latency benefits of handle reuse, making it difficult to maintain high-frequency scaling.

[0144] Those skilled in the art will understand that the embodiments of this application are not limited to the above-described embodiments. For example, the organization structure of the fast registration memory region pool can use other data structures instead of red-black trees, such as skip lists or hash tables. The attribute matching strategy for handles can be adjusted according to the actual application scenario; for example, more attribute dimensions can be introduced for matching. The duration of the recalculation tolerance window can be dynamically adjusted according to changes in network latency. The adjustment strategies for the aging period and the fixed number of retained handles can employ more complex prediction algorithms, such as machine learning-based prediction algorithms.

[0145] Furthermore, the technical solution of this application is not only applicable to distributed cache pool scenarios, but also to other distributed memory systems with similar data recomputability characteristics. For example, in distributed computing systems, intermediate computation results are usually recomputable, and the technical solution of this application can be used to achieve elastic scaling of memory.

[0146] It should be noted that the above embodiments are merely preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for elastic scaling of a distributed cache pool, characterized in that, include: Obtain the amount of free memory in a node, and determine the memory region to be contributed or the memory region to be reclaimed based on the comparison result between the amount of free memory and the high watermark threshold or the low watermark threshold. Through the handle pool interface, handle operations are performed: a pre-allocated fast-register memory handle is obtained for the memory region to be contributed, and the physical address mapping of the handle is updated; or for the memory region to be reclaimed, the physical address mapping of the corresponding handle is cleared and the handle is returned. When the memory region to be contributed is only used for remote read cache data, handles with access permission flags that at least include remote read permissions are selected, and the handles are immediately pushed into the handle pool after being returned. A recalculation tolerance window is set for the memory region to be reclaimed. The aging period of the handle pool and the number of handles to be retained are adjusted according to the reclamation step size. Update the global address mapping table of the distributed cache pool to provide the memory region to be contributed to remote nodes for access, or remove the memory region to be reclaimed from the distributed cache pool to complete elastic scaling; The recalculation tolerance window is the period of time during which data recalculation is still allowed to be triggered by returning an error after the memory area has been reclaimed.

2. The method according to claim 1, characterized in that, The selection access permission flag that includes at least a handle with remote read permission includes: when there are redundant copies of cached data in the memory region to be contributed, the selection access permission flag includes only a handle with remote read permission; when there are no redundant copies, the selection access permission flag includes handles with both remote read permission and local write permission.

3. The method according to claim 1, characterized in that, The selection access permission flag, which includes handles with remote read permissions, also includes: when the sub-pool with completely matching immutable attributes is empty, selecting a handle from another sub-pool with writable vendor keys.

4. The method according to claim 1, characterized in that, The adjustment of the aging cycle of the handle pool and the number of handles to be retained based on the recycling step size includes: The number of handles to be returned within a predetermined time is predicted based on the said recycling step size; Shorten the aging cycle to release the returned handle within the predetermined time; When the frequency of popping historical handles exceeds the frequency threshold, the number of handles that are fixed and reserved is increased.

5. The method according to claim 1, characterized in that, The setting of the recalculation tolerance window includes: starting a recalculation tolerance window timer; returning an error response to remote read requests accessing the memory region to be reclaimed before the recalculation tolerance window timer expires; and allowing local services to write to the memory region to be reclaimed after the recalculation tolerance window timer expires.

6. The method according to claim 1, characterized in that, The process of determining the memory region to be reclaimed includes: selecting cache blocks containing cold data and having redundant copies as priority memory regions to be reclaimed.

7. The method according to claim 1, characterized in that, The process of updating the global address mapping table of the distributed cache pool includes: sending the memory region information of the memory region to be contributed to the distributed storage service, wherein the memory region information includes node identifier, offset, capacity and remote access key; or sending the removal information of the memory region to be reclaimed to the distributed storage service.

8. The method according to claim 1, characterized in that, The high water level threshold and low water level threshold are set by the following steps: obtaining historical memory usage fluctuation data of the node; setting the difference between the high water level threshold and the low water level threshold based on the fluctuation data, such that the difference is less than five percent of the total memory capacity.

9. The method according to claim 1, characterized in that, Also includes: After completing elastic scaling, the amount of free memory of the node is obtained again after one sampling period to trigger the next scaling.

10. An elastic scaling system for a distributed cache pool, characterized in that, include: The memory monitoring module is used to obtain the amount of free memory in a node, and based on the comparison result of the amount of free memory with the high watermark threshold or the low watermark threshold, to determine the memory area to be contributed or the memory area to be reclaimed. The handle management module is used to perform handle operations through the handle pool interface: obtaining pre-allocated fast-register memory handles for the memory region to be contributed and updating the physical address mapping of the handle, or clearing the physical address mapping of the corresponding handle and returning the handle for the memory region to be reclaimed; when the memory region to be contributed is only used for remote read cache data, selecting handles whose access permission flags at least include remote read permissions, and immediately pushing the handle into the handle pool after returning the handle, setting a recalculation tolerance window for the memory region to be reclaimed; adjusting the aging cycle of the handle pool and the number of handles to be retained according to the reclamation step size; The global mapping update module is used to update the global address mapping table of the distributed cache pool to provide the memory region to be contributed to remote nodes for access, or to remove the memory region to be reclaimed from the distributed cache pool, thereby completing elastic scaling.

Images