Distributed CDN hot content dynamic caching and elimination system based on edge computing

Abstract

The application discloses a distributed CDN hotspot content dynamic caching and elimination system based on edge computing and relates to the technical field of cache management, which comprises a cache responsibility division module, a cumulative transposition construction module, a closed boundary solution module and a transposition token execution module.The cache responsibility division module is used for collecting Range request records and cache directories, dividing byte units and generating an initial responsibility chain.The cumulative transposition construction module is used for generating a hotspot complement sequence, a transfer sequence and a candidate node, and constructing a cumulative transposition frame.The closed boundary solution module is used for calculating a shadow completion timestamp, delivering a closed residual error and a complement amount, and generating a transposition record.The transposition token execution module is used for generating a transposition token and shunting requests, submitting a directory transaction and releasing a transfer cache section when a closed delivery and a source station complement reduction are achieved, and otherwise rolling back a transposition operation.The application solves the problem that the existing distributed CDN is difficult to cooperatively determine a hotspot complement range and a transfer range, resulting in high source station complement pressure and cache transposition damage to request delivery closure.

Description

Technical Field

[0001] This invention relates to the field of cache management technology, specifically to a distributed CDN dynamic caching and eviction system for hot content based on edge computing. Background Technology

[0002] With the development of edge computing, content delivery networks (CDNs), and segmented streaming media transmission technologies, distributed CDNs are increasingly adopting edge node collaborative caching to handle range requests. They adjust the cached content of each edge node through methods such as access popularity analysis, cache partitioning, priority sorting, and consistency maintenance to improve the edge hit rate of popular content and cache resource utilization. Related cache management technologies have evolved from single-node least recently used eviction to multi-node dynamic scoring, partitioned eviction, and transaction synchronization mechanisms tailored to edge computing environments.

[0003] For example, application CN120470036B discloses a method for hot data eviction and maintenance in a distributed caching system, including: obtaining the access frequency, temporal locality score, business weight, and real-time data heat value of the data, and generating a dynamic priority score for the data; determining invalid data based on the dynamic priority score; dividing the data into hot zone data, warm zone data, and cold zone data; when the cache space is insufficient, prioritizing the eviction of data with the lowest dynamic priority score and retention benefit value below a preset threshold in the cold zone data; if the cache space is still insufficient, performing data eviction on the warm zone data according to the most recent access time; encapsulating the evictioned data in the cold zone, the evictioned data in the warm zone, and the invalid data into a final transaction message; broadcasting the final transaction message through a preset protocol, and performing distributed consistency maintenance operations on the final transaction message through receiving nodes.

[0004] For example, application CN116303586B provides a metadata cache eviction method based on a multi-level B+tree, including: triggering cache eviction on Akey-LRU by setting a preset cache threshold; performing forward eviction of the metadata cache at the Akey node level by traversing and identifying Akey nodes on Akey-LRU; and performing multi-level reverse eviction of the metadata cache using reverse pointers. According to this multi-level B+tree-based metadata cache eviction method, multi-level reverse eviction of the metadata cache can be performed using reverse pointers, improving the eviction efficiency of the data cache. The multi-level tree eviction is implemented using an LRU linked list, resulting in low implementation complexity. It can effectively improve the hit rate of hot metadata while timely releasing system resources through cache eviction, thereby improving cluster performance.

[0005] However, existing technologies mainly determine the data to be evicted based on access frequency, popularity score, recent access time, or cache threshold. They usually use complete data objects or cache nodes as adjustment units, making it difficult to combine Range request delivery records, origin server replenishment status, adjacent node cache coverage relationships, and physical cache usage within a continuous replacement cycle to collaboratively determine the hot spot replenishment range and the transfer range. The cache adjustment process also lacks verification of request delivery closure and origin server replenishment changes, which can easily lead to hot bytes not being cached in time, incomplete responsibility transfer of transferred bytes, or inconsistent cache directory status.

[0006] Therefore, in order to address the above issues, there is an urgent need to provide a distributed CDN dynamic caching and eviction system for hot content based on edge computing. Summary of the Invention

[0007] Technical problems to be solved To address the shortcomings of existing technologies, this invention provides a distributed CDN dynamic caching and eviction system for hot content based on edge computing. This system solves the problem that existing distributed CDNs struggle to collaboratively determine the scope of hot content replacement and transfer, leading to high pressure on the origin server for replacement and easy disruption of request delivery closure due to cache swapping.

[0008] Technical solution To achieve the above objectives, this invention provides the following technical solution: a distributed CDN hotspot content dynamic caching and eviction system based on edge computing, comprising: a cache responsibility division module, used to collect Range request records and cache directories of target nodes and adjacent nodes, generate request delivery frames and baseline directory snapshots, divide byte units and mark responsibility status, and generate an initial responsibility chain for two consecutive transposition cycles; and a cumulative transposition construction module, used to generate a hotspot replacement sequence, a transfer sequence and a candidate node set based on the initial responsibility chain, generate mutually inherited cumulative transposition frames according to the replacement occupancy and reclaimable amount, and determine hotspot replacement. The module includes a scope and transfer scope; a closure boundary solution module, used to update the initial responsibility chain based on the cumulative transposition frames, calculate the shadow completion timestamp of the request sub-interval, the delivery closure residual, the baseline padding amount and the shadow padding amount, extract the maximum continuous closure prefix, determine the maximum closure frame and generate a transposition record; and a transposition token execution module, used to generate a transposition token based on the transposition record, lock the transfer scope and verify the hot spot padding bytes, execute Range request splitting and transposition verification, commit the directory transaction when the delivery is closed and the source station padding decreases, write the hot spot padding directory record and the transfer responsibility record and release the transfer cache segment, otherwise roll back the transposition operation.

[0009] Further, the specific steps for collecting Range request records and cache directories of the target node and adjacent nodes, and generating request delivery frames and baseline directory snapshots are as follows: The edge CDN node performing the current transposition process is identified as the target node. The target node number, the numbers of each adjacent node, the origin node number, the content number, the content version number, the Range request number, the request start and end byte position values, the actual delivery start and end byte position values, the actual delivery node number, the request timestamp, and the sending completion timestamp are obtained. The nodes are grouped according to the Range request number, and a request delivery frame is generated for each group. The cache directories of the target node and each adjacent node are obtained. The cache directories include cache byte ranges, responsible node numbers, and directory version numbers. The cache directories corresponding to the transposition cycle start timestamp are copied as baseline directory snapshots.

[0010] Further, the specific steps for dividing byte units and marking responsibility status to generate the initial responsibility chain for two consecutive transposition cycles are as follows: The current transposition cycle and the temporally adjacent preceding transposition cycle are identified as two consecutive transposition cycles; for the same content ID and content version ID, the starting byte position value and the byte position value (plus one) of the request byte interval, actual delivery byte interval, and cached byte interval within the two transposition cycles are extracted, deduplicated, and sorted in ascending order; the byte interval between two adjacent byte position values ​​is identified as a byte unit; byte unit numbers are assigned to each byte unit according to the byte position in ascending order; and the request byte interval, actual delivery byte interval, and cached byte interval in the request delivery frame and the baseline directory snapshot are split based on the start and end byte position values ​​of the byte unit; when the cached byte interval of the target node completely covers the byte unit, local responsibility is written. The system records the status and target node number. If the target node is not fully covered, and the cached byte range of the adjacent responsible nodes registered in the baseline directory snapshot fully covers the byte unit, write the adjacent responsibility status and the registered node number. If no adjacent responsibility status is written, but there are adjacent nodes whose cached byte ranges fully cover the byte unit, select the adjacent node that delivers the most byte units within the corresponding transposition period, and write the adjacent responsibility status and the selected node number. If neither the target node nor the cached byte ranges of any of the adjacent nodes fully cover the byte unit, write the responsibility gap status and the source node number. The system then counts the number of records delivered by the source station for each byte unit within the corresponding transposition period, generating the source station's fill-in count. Finally, it connects the byte units according to their byte positions and writes the content number, content version number, responsibility status, responsible node number, and source station fill-in count to generate the initial responsibility chains for the two transposition periods.

[0011] Furthermore, the specific steps for generating the hotspot replacement sequence, the transfer sequence, and the candidate node set based on the initial responsibility chain are as follows: Read the initial responsibility chain for two consecutive transposition cycles, and connect the consecutive byte units that are in a responsibility gap state and have a source station replacement count greater than zero in both transposition cycles to form a hotspot replacement sequence; Read byte units one by one from both ends of the consecutive byte range of each local responsibility state in the current transposition cycle, stopping when a byte unit overlaps with an incomplete Range request in the target node's request queue; Form the consecutive byte units read before stopping in each reading direction into... The process involves: First, transferring the sequence of bytes. Then, reading each byte unit sequentially along the transfer sequence and searching for adjacent nodes that have the same content ID and content version ID, and whose cache start position value is not greater than the byte unit start position value and cache end position value is not less than the byte unit end position value. The set of adjacent nodes corresponding to the first byte unit is used as the candidate node set. Subsequent units are intersected with the set of adjacent nodes corresponding to the current byte unit. If the intersection is empty, the transfer sequence is terminated at the previous byte unit, and the candidate node set before the intersection is empty is retained. If the set of adjacent nodes corresponding to the first byte unit is empty, the corresponding transfer sequence is discarded.

[0012] Further, the specific steps for generating mutually inherited cumulative transposition frames based on the padding occupancy and reclaimable space, and determining the hotspot padding range and yielding range, are as follows: For each hotspot padding sequence, each yielding sequence, and each candidate node in the candidate node set, add one byte unit each time according to the hotspot padding sequence. Round up the length of the continuous byte range formed by the added byte units according to the minimum allocation unit of the target node cache to generate the padding occupancy. Continuously add byte units along the yielding sequence, accumulating the total content byte range within the physical allocation block occupancy of the increased yielding range to generate the reclaimable space. When the reclaimable space is not less than the padding occupancy, generate a cumulative transposition frame, determine the continuous byte interval covered by the hotspot padding unit number sequence as the hotspot padding range, and then proceed with the yielding... The consecutive byte range covered by the unit number sequence is determined as the transfer range, and the following are written: hot spot padding unit number sequence, transfer unit number sequence, hot spot padding range, transfer range, candidate node number, recyclable amount, target node base directory version number, and candidate node base directory version number. The subsequent cumulative transposition frame retains the candidate node number, target node base directory version number, and candidate node base directory version number of the previous cumulative transposition frame. A hot spot padding unit number is added to the end of the hot spot padding unit number sequence of the previous cumulative transposition frame, and the transfer unit number continues to be added after the last transfer unit of the previous cumulative transposition frame until the recyclable amount is not less than the padding occupancy. When the transfer sequence is completely read and the recyclable amount is still less than the padding occupancy, the generation of subsequent cumulative transposition frames is stopped.

[0013] Furthermore, based on the cumulative transposition frames, the initial responsibility chain is updated, and the specific steps for calculating the shadow completion timestamp, delivery closure residual, baseline padding amount, and shadow padding amount for the requested sub-interval are as follows: The target node copies the initial responsibility chain for the current transposition cycle for each cumulative transposition frame, changes the hotspot padding unit to the local responsibility status and target node number, changes the transfer unit to the adjacent responsibility status and candidate node number, and divides the Range request for the current transposition cycle into requested sub-intervals according to the byte unit boundary; the content read rate value, available sending bandwidth value, pending sending queue byte size, and path round-trip delay value of the node pointed to by the responsibility node number of each requested sub-interval in the updated initial responsibility chain are collected; the request time... The shadow completion timestamp of the request sub-interval is generated by summing the interstamp, the ratio of the request sub-interval byte length value to the content read rate value, the ratio of the sum of the pending queue bytes and the request sub-interval byte length value to the available transmission bandwidth value, and the path round-trip delay value. For Range requests that overlap with hotspot padding ranges or yielding ranges, the length of request sub-interval bytes whose shadow completion timestamps are later than the transmission completion timestamps in the request delivery frame within the overlapping range is accumulated to generate a delivery closure residual. The length of request sub-interval bytes actually delivered by the source station for the same group of Range requests and the length of request sub-interval bytes allocated to the source station node in the updated initial chain of responsibility are accumulated to generate the baseline padding amount and the shadow padding amount.

[0014] Further, the specific steps for extracting the maximum continuous closed prefix, determining the maximum closed frame, and generating the transposition record are as follows: When the delivery closure residual is zero and the shadow padding amount is less than the reference padding amount, a transposition closure mark is written in the cumulative transposition frame; for each cumulative transposition frame that does not inherit other cumulative transposition frames, the cumulative transposition frames with transposition closure marks are read continuously along the corresponding cumulative transposition frame inheritance relationship and in the generation order, and the maximum continuous closed prefixes are generated respectively, and the last cumulative transposition frame in each maximum continuous closed prefix is ​​determined as the corresponding maximum closed frame; according to the difference between the reference padding amount and the shadow padding amount from large to small, the recyclable amount from small to large, and the candidate node number from small to large, the maximum closed frame at the top of the sort is selected to generate the transposition record.

[0015] Further, the specific steps for generating a transposition token and locking the transfer range based on the transposition record are as follows: Generate a transposition token based on the transposition record, and write the target node number, candidate node number, content number, content version number, hotspot filling range, transfer range, target node base directory version number, and candidate node base directory version number into the transposition token; after the candidate node confirms that the cached content version number is consistent with the content version number in the transposition token, the cached byte range completely covers the transfer range, and the current directory version number is consistent with the candidate node base directory version number, it locks the transfer range and generates a responsibility acceptance mark.

[0016] Further, the specific steps for verifying hotspot padding bytes and performing Range request splitting and transposition verification are as follows: The target node retrieves adjacent nodes whose content version number matches the transposition token and whose cached byte range completely covers the hotspot padding range. If multiple adjacent nodes exist, the adjacent node with the smallest path round-trip latency is selected. If the retrieval is successful, the hotspot padding bytes are read from the selected adjacent node; if the retrieval fails, the hotspot padding bytes are read from the origin node and written to the temporary storage area. The digest values ​​are calculated for bytes at the same position in both the read bytes and the temporary storage area. If the digest values ​​are identical, a token activation timestamp is generated; otherwise, the responsibility acceptance mark is canceled, the transfer range lock is released, the temporary storage area is released, and the transposition token is written to the invalidation state. The earlier the request timestamp... Range requests with the token effective timestamp are delivered according to the pre-transfer responsibility status; other Range requests are divided according to byte unit boundaries, with request sub-intervals within the hot spot padding range delivered by the target node, request sub-intervals within the transfer range delivered by the candidate node, and other request sub-intervals delivered according to the pre-transfer responsibility status; from the token effective timestamp to the end timestamp of the transfer cycle in which the token effective timestamp is located, for each Range request, the request byte interval is subtracted from the union of the actual delivered byte intervals of the same Range request, the remaining byte length is accumulated to generate the actual delivery closure residual, and the byte lengths of the request sub-intervals allocated to the source node and actually delivered by the source node before the transfer responsibility status are accumulated respectively to generate the verification baseline padding amount and the actual padding amount.

[0017] Furthermore, when delivery is closed and source site fill is reduced, a directory transaction is committed, writing hotspot fill directory records and responsibility transfer records, and releasing the transfer cache segment; otherwise, the specific steps for rolling back the swap operation are as follows: After the swap period in which the token's effective timestamp ends, when the target node's current directory version number and the candidate node's current directory version number are equal to the target node's baseline directory version number and the candidate node's baseline directory version number in the swap token, respectively; when the responsibility acceptance flag exists and the transfer scope is locked; when the actual delivery closure residual is zero and the actual fill amount is less than the verification baseline fill amount, the target node hotspot is written in the same directory transaction. Replace the directory record and candidate node responsibility transfer record, and delete the target node responsibility transfer cache directory record; after the directory transaction is successfully committed, convert the temporary segment to the cache segment, release the transfer range lock and release the target node responsibility transfer cache segment; if any condition is not met or the directory transaction fails to commit, roll back the directory transaction, restore the Range request whose request timestamp is not earlier than the token effective timestamp and has not yet been delivered to the delivery according to the responsibility status before the swap, and after the candidate node has completed the delivery of the request sub-segment, cancel the responsibility acceptance mark, release the transfer range lock, release the temporary segment and write the swap token to the invalidation status.

[0018] Beneficial effects The present invention has the following beneficial effects: (1) The distributed CDN hot content dynamic caching and eviction system based on edge computing identifies hot content filling sequences that are continuously in a responsibility gap state and are filled by the source station by using request delivery frames, baseline directory snapshots and initial responsibility chains in two consecutive switching cycles. This avoids judging hot content based solely on the whole file access frequency or single-cycle heat, and improves the stability and accuracy of hot content filling range determination.

[0019] (2) The distributed CDN hot content dynamic caching and eviction system based on edge computing calculates the occupancy of the hot content filling sequence, the transfer sequence and the candidate nodes through the association between the hot content filling sequence, the transfer sequence and the candidate nodes, and calculates the reclaimable amount according to the minimum allocation unit of the cache, so that the hot content filling byte writing and the transfer cache segment release form a spatial connection relationship, reducing cache fragmentation and invalid eviction.

[0020] (3) The distributed CDN hot content dynamic caching and eviction system based on edge computing expands the hotspot filling range and transfer range by accumulating the swap frames. It extracts the maximum continuous closed prefix by combining the shadow completion timestamp of the request sub-interval, the delivery closure residual, the baseline filling amount and the shadow filling amount, so that the swap boundary simultaneously meets the conditions of timely delivery of the request and reduction of the source station filling, and avoids the interruption of Range request delivery due to the excessively large swap range.

[0021] (4) The distributed CDN hot content dynamic caching and eviction system based on edge computing locks the transfer range through the transposition token, performs block digest verification on the hot spot filling bytes, and submits the directory transaction when the actual delivery is closed and the source station filling is reduced. It synchronously writes the hot spot filling directory record, the transfer responsibility record and releases the transferred cache segment; when the verification fails, it rolls back the transposition operation to reduce the risk of node directory inconsistency and cache responsibility hanging. Attached Figure Description

[0022] Figure 1 This is a diagram illustrating the architecture of a distributed CDN system for dynamic caching and eviction of hot content based on edge computing. Figure 2 A flowchart for extracting the maximum consecutive closed prefix and generating transposition records; Figure 3 This is a schematic diagram of cumulative transposition frame inheritance and closed boundary. Detailed Implementation

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

[0024] Please see Figures 1-3 This invention provides a technical solution: a distributed CDN hotspot content dynamic caching and eviction system based on edge computing, comprising: The cache responsibility division module is used to collect Range request records and cache directories of target nodes and adjacent nodes, generate request delivery frames and baseline directory snapshots, divide byte units and mark responsibility status, and generate the initial responsibility chain for two consecutive transposition cycles. The cumulative transposition construction module is used to generate hot spot replacement sequence, transfer sequence and candidate node set based on the initial responsibility chain, generate mutually inherited cumulative transposition frames according to the replacement occupancy and reclaimable amount, and determine the hot spot replacement range and transfer range. The closed boundary solution module is used to update the initial chain of responsibility based on the cumulative transposition frames, calculate the shadow completion timestamp of the requested sub-interval, the delivery closure residual, the baseline fill amount and the shadow fill amount, extract the maximum continuous closure prefix, determine the maximum closure frame and generate the transposition record; The transposition token execution module is used to generate transposition tokens based on transposition records and lock the transfer range, verify hot spot padding bytes, and perform Range request routing and transposition verification. When delivery is closed and source site padding is reduced, the directory transaction is committed, hot spot padding directory records and transfer responsibility records are written, and the transfer cache segment is released; otherwise, the transposition operation is rolled back.

[0025] Specifically, the steps for collecting Range request records and cache directories of the target node and adjacent nodes, and generating request delivery frames and baseline directory snapshots are as follows: The edge CDN node performing the current transposition process is identified as the target node. Transposition processing is triggered by the edge node scheduling process according to the transposition cycle. The transposition cycle duration is read from the transposition parameter table. The transposition cycle duration is between 30 and 300 seconds, determined by the 95th percentile of the Range request arrival interval in the last 24 hours and the average update interval of the cache directory. The larger of the two time values ​​is taken and rounded up to the nearest second. The edge node scheduling process generates the start timestamp of the next transposition cycle when the previous transposition cycle ends. The start timestamp of the transposition cycle is recorded by the target node's monotonic clock and converted into a standard timestamp used by all edge CDN nodes through a unified clock service. Edge CDN nodes with region codes consistent with the target node's region code, valid link reachability markers, and valid directory synchronization permission markers are read from the node topology table. These edge CDN nodes are identified as adjacent nodes. The link reachability markers are determined by the target node's monotonic clock. Nodes send heartbeat messages to edge nodes in the same region at detection intervals of 5 to 30 seconds and perform transmission connection detection. A valid value is written when at least two out of three consecutive detections are successful. The directory synchronization permission flag is read from the cache directory synchronization configuration table, thus limiting the set of adjacent nodes to edge CDN nodes in the same region that are currently reachable and within the cache directory synchronization range. The target node number and the numbers of each adjacent node are read from the node topology table, the origin node number is read from the content origin mapping table, and the content number, content version number, Range request number, request start and end byte position values, actual delivery start and end byte position values, actual delivery node number, request timestamp, and sending completion timestamp are obtained from the target node's HTTP access logs, content delivery logs, and sending completion callback records. The content number is obtained by matching the request Uniform Resource Locator (URL) with the content index table; the content version number is read from the version summary field of the content manifest; the Range request number is generated when the target node receives a Range request; and the request start and end byte position values ​​are obtained by parsing the HTTP... The Range request header is obtained, and the actual delivery start and end byte positions are obtained by parsing the HTTP Content-Range response header and combining it with the byte offset of the sending buffer. The actual delivery node number is written by the running instance of the node that performed the byte sending operation. The request timestamp is recorded when the target node receives the complete request header, and the sending completion timestamp is recorded when the last response byte is sent and the sending completion callback is received. Each edge CDN node corrects its node clock through a unified clock service. The allowed deviation of timestamps between nodes is 1 to 5 milliseconds. The specific value is determined based on the maximum offset value in the node clock synchronization log and the path round-trip latency fluctuation range. The allowed timestamp deviation is used to ensure that the request timestamp, actual delivery record, and sending completion timestamp of the same Range request are arranged in the true order.Integrity checks are performed on the request start and end byte positions, actual delivery start and end byte positions, and timestamps. If the request start byte position is greater than the request end byte position, the actual delivery start byte position is greater than the actual delivery end byte position, the actual delivery byte range exceeds the request byte range, or the sending completion timestamp is earlier than the request timestamp, the corresponding record is not written into the request delivery frame. Requests are grouped according to Range request numbers, and request delivery frames are generated for each group. When multiple actual delivery records correspond to the same Range request number, they are arranged in ascending order of actual delivery start byte position values, and the target is written into the request delivery frame. The request delivery frame contains the node ID, neighboring node IDs, origin node ID, content ID, content version ID, Range request ID, request start and end byte position values, actual delivery start and end byte position values, actual delivery node IDs, request timestamp, and transmission completion timestamp, enabling it to represent the byte delivery process of a single Range request from receipt to completion of transmission. It retrieves the cache directories of the target node and its neighboring nodes. The target node's cache directory is read from its local cache metadata table, and the neighboring nodes' cache directories are read through the inter-node directory synchronization interface. Directory records are filtered by content ID and content version ID. The cache directory includes cached byte ranges, responsible node numbers, and directory version numbers. The cached byte range is generated from the start and end byte positions in the cache file index. The responsible node number indicates the edge CDN node currently responsible for delivering the corresponding cached byte range. The directory version number increments each time a cached byte range is added, deleted, or migrated. When the start timestamp of the transposition cycle arrives, the target node sends a snapshot barrier instruction carrying the transposition cycle number and the start timestamp to each neighboring node. The target node and each neighboring node apply read locks to the cache directory metadata, reading data up to the start timestamp of the transposition cycle. Upon arrival, the directory version number and cached directory record are retrieved. The cached directory record is copied to a baseline directory snapshot, and the current directory version number is read again. If the directory version numbers read twice match, the read lock is released and the baseline directory snapshot is confirmed to be valid. If the directory version numbers read twice do not match, the read lock and copy operation are re-executed. Cache directory updates generated after the transposition cycle start timestamp are written to the new directory version, but not to the baseline directory snapshot. This ensures that the baseline directory snapshots of the target node and all adjacent nodes correspond to the same transposition cycle start boundary, and provides a consistent cached directory baseline for subsequent byte unit partitioning and responsibility status marking.

[0026] In this implementation scheme, by uniformly limiting the consistency of the set of adjacent nodes, the transposition cycle boundary, and the baseline directory snapshot in the edge computing environment, the request delivery frame and the baseline directory snapshot are established on the same topological range, the same time base, and the same directory version. This eliminates the interference of node range drift, time boundary misalignment, and concurrent directory updates on cache responsibility determination, improves the traceability, stability, and cross-node consistency of the initial responsibility chain, provides a reliable data foundation for the accurate generation of subsequent hot spot replacement sequences, transfer sequences, cumulative transposition frames, and transposition tokens, and reduces the probability of responsibility mismatch and directory state conflict during cache transposition.

[0027] Specifically, the steps for dividing byte units and marking responsibility status to generate the initial responsibility chain for two consecutive transposition cycles are as follows: The current transposition cycle and the temporally adjacent preceding transposition cycle are identified as two consecutive transposition cycles. In practice, the current transposition cycle number, the current transposition cycle start timestamp, and the current transposition cycle end timestamp are read from the transposition cycle record table. Then, the preceding transposition cycle number, the preceding transposition cycle start timestamp, and the preceding transposition cycle end timestamp, which are consecutive to the current transposition cycle start timestamp, are read. The two transposition cycles use the same transposition cycle duration and the same standard clock. The preceding transposition cycle end timestamp and the current transposition cycle start timestamp are consecutive. The permissible deviation between interpolation stamps is 1 to 5 milliseconds, determined based on the maximum clock offset in the edge node clock synchronization log. Transposition cycle records exceeding the permissible deviation are excluded from initial chain of responsibility generation to prevent time gaps from causing cross-cycle mismatches in request delivery records. For the same content ID and content version ID, the starting and ending byte positions of the request byte range, actual delivery byte range, and cached byte range within two transposition cycles are extracted, deduplicated, and sorted in ascending order. The byte range between two adjacent byte positions is defined as a byte unit. Byte unit numbers are assigned to each byte unit in ascending order of byte position, and further assigned based on the character... The start and end byte position values ​​of the segment unit are split into the request byte range, actual delivery byte range, and cached byte range in the request delivery frame and the base directory snapshot. In specific implementation, the request byte range, actual delivery byte range, and cached byte range uniformly adopt the [start, end] closed interval format, where start represents the starting byte position value and end represents the ending byte position value. The bytes corresponding to the starting and ending byte position values ​​are included in the byte range. Adding one to end forms the right-side split point that does not include the original ending byte. The request byte range and actual delivery byte range are read from the request delivery frame, and the cached byte range is read from the base directory snapshot of the corresponding transposition period. The position values ​​of each byte are recorded using unsigned 64-bit integers. Before incrementing the position value of the terminating byte, it is verified that the position value of the terminating byte is less than the total length of the content in the content index table. The result of incrementing the position value of the terminating byte must not be greater than the total length of the content. Only one boundary record is retained for duplicate byte position values, and boundary numbers are assigned sequentially to the sorted byte position values. The left boundary value corresponding to the adjacent boundary number is used as the starting byte position value of the byte unit, and the right boundary value minus one is used as the ending byte position value of the byte unit. This ensures that each byte unit adopts the closed interval format of [left, right-1], and that adjacent byte units are continuous from beginning to end without any duplicate boundary bytes.A byte unit index is established based on the content number, content version number, and byte unit number. When splitting a request delivery frame, the Range request number, request timestamp, send completion timestamp, actual delivery node number, and the split actual delivery start and end byte positions are written to the corresponding byte unit record. When splitting a baseline directory snapshot, the responsibility node number, directory version number, and the split cache start and end byte positions are written to the corresponding byte unit record. The splitting process only changes the granularity of the byte range and does not change the request delivery relationship or cache responsibility relationship. When the cache byte range of the target node completely covers the byte unit, the local responsibility status and target are written. Node number; In specific implementation, based on the target node's baseline directory snapshot, the system retrieves directory records where the cache start byte position value is not greater than the byte unit start byte position value and the cache end byte position value is not less than the byte unit end byte position value. Upon successful retrieval, the responsibility status field is written to the local responsibility status, and the responsibility node number field is written to the target node number. If the target node is not fully covered, and the cache byte range of the adjacent responsibility nodes registered in the baseline directory snapshot fully covers the byte unit, the adjacent responsibility status and the registered node number are written. In specific implementation, the system first reads the responsibility node number corresponding to the byte unit from the target node's baseline directory snapshot, and then... In the adjacent node baseline directory snapshot of the same transposition period, the complete coverage relationship of the cached byte range corresponding to the registered node number is verified. After verification, the adjacent responsibility status and the registered node number are written. If the adjacent responsibility status is not written and there is an adjacent node with a complete coverage byte unit of the cached byte range, the adjacent node with the most delivery byte units in the corresponding transposition period is selected, and the adjacent responsibility status and the selected node number are written. In specific implementation, for each adjacent node with a complete coverage byte unit, the number of records in the request delivery frame where the actual delivery node number matches the adjacent node number and the split actual delivery byte range completely covers the byte unit is counted. The number of records is used as the number of times byte units are delivered. Records are sorted from largest to smallest according to the number of times byte units are delivered. When the number of records is the same, they are sorted from smallest to largest according to the adjacent node number. The adjacent node at the top of the sort is determined as the selected node. When the cache byte range of the target node and each adjacent node does not completely cover the byte unit, the responsibility gap status and the source node number are written. In specific implementation, the responsibility gap status is written after the local responsibility status and the adjacent responsibility status have not been written, so that each byte unit corresponds to a responsibility status and a responsibility node number. The number of records delivered by the source station in the corresponding transposition cycle for each byte unit is counted to generate the source station's replacement count.In practice, the actual delivery node number in the request delivery frame is used as the identification field for the source station delivery record. When the actual delivery node number matches the source station node number, and the split actual delivery byte range completely covers the current byte unit, the corresponding actual delivery record is counted in the source station padding count for the current byte unit. The source station delivery relationship is not inferred from the request forwarding path, allowing the source station padding count to directly reflect the actual number of byte deliveries undertaken by the source station node. Byte units are connected according to their byte positions, and the content number, content version number, responsibility status, responsibility node number, and source station padding count are written to generate initial responsibility chains for two transposition cycles. In practice, each byte unit is arranged in ascending order of its byte unit number, and the transposition cycle number, transposition cycle start timestamp, content number, and content version number are written to the initial responsibility chain header record. This ensures that the initial responsibility chains for the two transposition cycles are aligned unit by unit according to the same byte position, providing a continuous and non-overlapping responsibility basis for the generation of subsequent hotspot padding sequences and transfer sequences.

[0028] This implementation scheme unifies the byte interval boundary criteria, the order of responsibility status determination, and the statistical criteria for the number of source station fill-in cycles. This ensures that the initial responsibility chains of two consecutive transposition cycles can be stably aligned under the same content number, content version number, and byte unit number. It avoids the breakage of the responsibility chain caused by duplicate inclusion of boundary bytes, cache responsibility conflicts, and misjudgment of source station delivery records. This improves the accuracy and traceability of responsibility status, responsibility node number, and the number of source station fill-in cycles, provides a consistent data foundation for the reliable identification of hotspot fill-in sequences and transfer sequences, and enhances the stability of subsequent cumulative transposition frame generation and closed boundary solution.

[0029] Specifically, the steps for generating the hotspot replacement sequence, transfer sequence, and candidate node set based on the initial responsibility chain are as follows: Read the initial responsibility chains for two consecutive transposition cycles; in practice, align the initial responsibility chain of the previous transposition cycle with the initial responsibility chain of the current transposition cycle unit by unit according to the content number, content version number, and byte unit number. Only read byte unit records with the same content number, content version number, and start and end byte position values; byte units that are not fully aligned are not included in this processing; connect consecutive byte units that are in a responsibility gap state in both transposition cycles and have a source station replacement count greater than zero to form a hotspot replacement sequence; in practice, verify the responsibility of the same byte unit in both transposition cycles. The hotspot padding flag is written only when the responsibility status is in a responsibility gap state for both transposition cycles and both source station padding counts are greater than zero. Then, byte units with hotspot padding flags are read in ascending order of byte unit number. When the number of the next byte unit is consecutive to the number of the previous byte unit, and the position value of the terminating byte of the previous byte unit, incremented by one, matches the position value of the starting byte of the next byte unit, the two byte units are concatenated. Each hotspot padding sequence formed by these concatenations is written with the content number, content version number, first byte unit number, last byte unit number, and the source station padding count for each byte unit. This ensures that the hotspot padding sequence represents the responsibility gap word continuously delivered by the source station within two consecutive transposition cycles. The section range is reduced to minimize interference from short-term request surges within a single transposition cycle on hotspot range determination. Byte units are read sequentially from both ends of the continuous byte range of each local responsibility state in the current transposition cycle, stopping when a byte unit overlaps with an incomplete Range request in the target node's request queue. The consecutive byte units read before stopping in each direction form a transfer sequence. Specifically, byte units with local responsibility states and target node numbers are connected in ascending order of byte unit number to form continuous byte ranges for each local responsibility state. A start and end read cursor are established for each continuous byte range of local responsibility states. The target node request queue starts from the target node's request queue. The node requests the scheduler to read the data. After receiving the complete Range request header, generating the Range request number, and writing the start and end byte positions and timestamp of the request, the target node writes the corresponding Range request to the target node's request queue and sets the request completion flag to an invalid value. When the actual delivered byte range of the same Range request completely covers the request byte range and the transmission completion timestamp has been written to the request delivery frame, the request completion flag is set to a valid value, and the corresponding Range request is removed from the target node's request queue. Range requests with an invalid completion flag are determined to be incomplete Range requests, thus ensuring that the target node's request queue only retains Range requests that have not yet completed the delivery of all bytes.The start-end read cursor moves in ascending order of byte unit number, and the end-end read cursor moves in descending order of byte unit number, reading only byte units that have not yet been included in the transfer sequence each time. When the start byte position value of a byte unit is not greater than the end byte position value of an incomplete Range request, and the end byte position value of a byte unit is not less than the start byte position value of an incomplete Range request, the byte unit is considered to overlap with the incomplete Range request. The current read direction stops before the overlapping byte unit, and the overlapping byte unit is not written into the transfer sequence. If the first byte unit read from the end overlaps with an incomplete Range request, no transfer sequence is generated for the corresponding read direction. The temporary transfer sequence records formed by the corresponding read direction are deleted, so that empty transfer sequences do not participate in candidate node set retrieval, reclaimable quantity calculation, and cumulative transposition frame generation. When two read cursors meet, the center byte unit that has not yet been included in the transfer sequence is written to the first arriving read direction, and the other read direction is terminated, so that the same byte unit is not repeatedly written to two transfer sequences. Using the two ends of the continuous byte range of the local responsibility state as the starting point of the transfer sequence can preferentially form a continuous transfer range that is connected to the boundary of the reserved cache range and reduce the number of segments of the residual cache interval after transfer. Read byte units one by one along the transfer sequence, and search for those with the same content number and content version number, and whose cache start position value is not greater than the word. Adjacent nodes whose starting position value of the byte unit and the ending position value of the cache are not less than the ending position value of the byte unit; in specific implementation, the byte unit numbers are read sequentially according to the reading direction of the transfer sequence, and in the reference directory snapshot of each adjacent node corresponding to the current transposition cycle, the content number and content version number are used as the first-level search conditions, and the cache starting position value and cache ending position value are used as the coverage search conditions. The adjacent node numbers that satisfy the complete coverage relationship are written into the adjacent node set corresponding to the current byte unit; the directory version number in the adjacent node reference directory snapshot remains unchanged during this search, so that the coverage judgment of each byte unit in the same transfer sequence adopts the same directory reference; the adjacent nodes corresponding to the first byte unit are... The set of adjacent nodes is used as the candidate node set. Subsequent units are intersected with the adjacent node set corresponding to the current byte unit. If the intersection is empty, the transfer sequence terminates at the previous byte unit, and the candidate node set before the intersection is empty is retained. Specifically, after the adjacent node set corresponding to the first byte unit is written into the candidate node set, the current candidate node set is saved as the previous round's candidate node set. For each subsequent byte unit read, the candidate node set and the adjacent node set corresponding to the current byte unit are intersected according to the adjacent node number. If the intersection result is not empty, the intersection result is overwritten into the candidate node set, the current candidate node set is saved as the new previous round's candidate node set, and the current byte unit is written into the transfer sequence.When the intersection result is empty, the current byte unit is excluded from the transfer sequence, the previous byte unit is determined as the last byte unit of the transfer sequence, and the candidate node set of the previous round is fixed as the final candidate node set. This ensures that each candidate node in the final candidate node set completely covers all byte units in the final transfer sequence, guaranteeing that subsequent reclaimable quantity calculations use a unique transfer range and candidate node set. When the set of adjacent nodes corresponding to the first byte unit is empty, the corresponding transfer sequence is discarded. In specific implementation, the temporary transfer sequence record formed by the corresponding read direction is also deleted, ensuring that subsequent cumulative transposition frames are generated only based on transfer sequences with complete adjacent cache acceptance relationships.

[0030] In this implementation scheme, by unifying the initial responsibility chain of two consecutive transposition cycles in the edge computing environment, the incomplete Range requests in the target node request queue, and the adjacent node baseline directory snapshot into the same byte unit link constraint, the hot spot filling sequence can reflect the continuous responsibility gap, the transfer sequence avoids the range of request bytes that have not yet been delivered, and the candidate node set and the final transfer range are kept in one-to-one correspondence. This reduces the risk of erroneous transfer caused by short-term traffic fluctuations, in-transit request occupancy, and adjacent cache coverage changes, and ensures that the hot spot filling sequence, transfer sequence, and candidate node set have continuity, uniqueness, and executability, providing a reliable boundary for the stable generation of filling occupancy, reclaimable amount, and cumulative transposition frames.

[0031] Specifically, the steps for generating mutually inherited cumulative transposition frames based on the padding occupancy and reclaimable space, and determining the hotspot padding range and yielding range, are as follows: For each hotspot padding sequence, each yielding sequence, and each candidate node in the candidate node set, one byte unit is added to each hotspot padding sequence. The length of the continuous byte range formed by the added byte units is rounded up according to the minimum allocation unit of the target node's cache to generate the padding occupancy. In specific implementation, a cumulative transposition frame generation index is established using the first and last byte unit numbers of the hotspot padding sequence, the first and last byte unit numbers of the yielding sequence, and the candidate node number, so that each group of hotspot padding sequences and yielding sequences... Each column and candidate node corresponds to a cumulative transposition frame generation chain; the target node's minimum cache allocation unit represents the minimum physical space granularity used when the target node performs cache space allocation and release, in bytes. It is read in real-time from the cache allocation granularity field in the target node's cache allocation configuration table and remains unchanged during the current transposition process; the cache allocation granularity is configured based on the least common multiple of the cache file block size and the cache allocator page size, ranging from 4KiB to 16MiB. For example, when the cache file block size is 4KiB and the cache allocator page size is 64KiB, the target node's minimum cache allocation unit is 64KiB; starting from the first byte of the hotspot padding sequence, according to byte units... The metadata number is incremented by consecutive byte units. The length of the continuous byte range formed by the smallest start byte position and the largest end byte position in the incremented byte unit is divided by the minimum allocation unit of the target node cache, rounded up, and then multiplied by the minimum allocation unit of the target node cache to generate the padding occupancy. The padding occupancy is then used to write the hot padding bytes corresponding to the padding occupancy into the physical space actually requested after the target node cache. Byte units are incremented consecutively along the transfer sequence, accumulating the physical allocation block occupancy where the entire content byte range is within the incremented transfer range, generating the reclaimable space. In specific implementation, a physical allocation block represents a continuous physical cache space that can be independently requested and released in the target node cache allocation table. The start and end positions of the physical allocation block are... Alignment is set according to the minimum allocation unit of the target node's cache; the physical allocation block number, the starting byte position value of the physical allocation block, the ending byte position value of the physical allocation block, the content number, and the content version number are read from the target node's cache allocation table. The number of minimum allocation units contained in the physical allocation block is recorded as the number of physical allocation units, and the physical allocation block occupancy is the product of the number of physical allocation units and the minimum allocation unit of the target node's cache; the physical allocation block occupancy is included in the reclaimable quantity only when the content number and content version number corresponding to the physical allocation block are consistent with the transfer sequence, and the range of content bytes carried by the physical allocation block is entirely within the increased transfer range. The same physical allocation block is accumulated after deduplication according to the physical allocation block number.When each physical allocation block occupies a minimum allocation unit of the target node's cache, the reclaimable amount is the product of the number of physical allocation blocks that completely fall within the increased transfer range and the minimum allocation unit of the target node's cache. Thus, the reclaimable amount represents the physical cache space that can actually be released from the target node after the transfer of responsibility. When the reclaimable amount is not less than the padding occupancy, a cumulative transposition frame is generated, and cumulative transposition frame numbers are assigned according to the generation order within the same transposition cycle. The continuous byte range covered by the hotspot padding unit number sequence is determined as the hotspot padding range, and the continuous byte range covered by the transfer unit number sequence is determined as the transfer range. The hotspot padding unit number sequence, transfer unit number sequence, hotspot padding range, transfer range, candidate node number, and reclaimable amount are then written into the data. The data includes the target node's baseline directory version number and the candidate node's baseline directory version number. In specific implementation, the added hotspot padding unit numbers are arranged according to byte position to form a hotspot padding unit number sequence, and the added transfer unit numbers are arranged according to the transfer sequence reading direction to form a transfer unit number sequence. The hotspot padding range is determined by the start byte position value of the first byte unit and the end byte position value of the last byte unit in the hotspot padding unit number sequence. The transfer range is determined by the minimum start byte position value and the maximum end byte position value covered by the transfer unit number sequence. The target node's baseline directory version number is read from the target node's baseline directory snapshot, and the candidate node's baseline directory version number is read from the candidate node's baseline directory snapshot, ensuring the hotspot padding range in the accumulated transposition frames... The transfer range and recyclable quantity correspond to a fixed directory version. When generating the first cumulative transposition frame, the first byte unit number of the hotspot padding unit number sequence is written into the hotspot padding unit number sequence. Then, starting from the first byte of the transfer sequence, the transfer unit numbers are added one by one. Each time a transfer unit number is added, the recyclable quantity is recalculated. The first cumulative transposition frame is generated when the recyclable quantity is not less than the padding occupancy for the first time. The subsequent cumulative transposition frame retains the candidate node number, target node base directory version number, and candidate node base directory version number of the previous cumulative transposition frame. A hotspot padding unit number is added to the end of the hotspot padding unit number sequence of the previous cumulative transposition frame. The transfer unit number continues to be added after the last transfer unit of the previous cumulative transposition frame until the recyclable quantity is not less than the padding occupancy. Usage; In specific implementation, after each additional hotspot padding unit number, the padding occupancy is recalculated. Then, starting from the next byte unit after the last bit of the previous cumulative transposition frame, the transposition unit number is added one by one. After each additional transposition unit number, the reclaimable amount is recalculated. When the reclaimable amount is not less than the current padding occupancy for the first time, a next cumulative transposition frame is generated. Then, the next hotspot padding unit number is added and the same loop is repeated, so that each hotspot padding unit number corresponds to at most one cumulative transposition frame. The number of cumulative transposition frames generated, the hotspot padding range boundary, and the transposition range boundary are all uniquely determined by the position that first meets the spatial acceptance condition. When the transposition sequence is read and the reclaimable amount is still less than the padding occupancy, the generation of subsequent cumulative transposition frames is stopped.In practice, the current cumulative transposition frame generation chain is terminated, and hotspot filler unit numbers and transfer unit numbers that do not meet the spatial acceptance conditions are not written into the cumulative transposition frame. This ensures that each generated cumulative transposition frame satisfies the requirement that the physical buffer space released by the transfer range can accommodate the physical buffer space occupied by the hotspot filler range.

[0032] In this implementation scheme, by unifying the actual physical space occupied by the hot spot padding range and the releasable physical space corresponding to the transfer range under the minimum allocation unit of the target node cache for closed constraint, the padding occupancy and reclaimable space have a consistent calculation caliber, avoiding space misjudgment caused by inconsistency between byte length and physical cache occupancy. Furthermore, the generation time of each cumulative transposition frame, the boundary of the hot spot padding range, and the boundary of the transfer range can be uniquely determined by the position that first meets the space acceptance condition, thereby improving the data acceptance stability between cumulative transposition frames, reducing the risks of cache fragmentation, excessive transfer, and insufficient padding space, and providing a definite and executable space basis for subsequent extraction of the maximum continuous closed prefix, selection of the maximum closed frame, and generation of transposition records.

[0033] Specifically, the steps for updating the initial responsibility chain based on the cumulative transposition frames and calculating the shadow completion timestamp, delivery closure residual, baseline padding amount, and shadow padding amount for the requested sub-interval are as follows: The target node replicates the initial responsibility chain for the current transposition period for each cumulative transposition frame, changes the hotspot padding unit to the local responsibility status and target node number, changes the transfer unit to the adjacent responsibility status and candidate node number, and divides the Range request for the current transposition period into requested sub-intervals according to the byte unit boundary. In practice, the target node establishes an independent responsibility chain replica according to the cumulative transposition frame number. The responsibility chain replica retains the content number, content version number, byte unit number, byte unit start byte position value, and byte unit value from the initial responsibility chain. The byte position value and source station padding count are terminated. Only the responsibility status and responsibility node number corresponding to the hotspot padding unit and the transfer unit are modified, so that each cumulative transposition frame forms a simulated responsibility allocation result that does not affect the current actual cache responsibility. The byte units in the responsibility chain replica are located item by item according to the hotspot padding unit number sequence. The corresponding responsibility status is changed to the local responsibility status and the responsibility node number is changed to the target node number. The byte units in the responsibility chain replica are located item by item according to the transfer unit number sequence. The corresponding responsibility status is changed to the adjacent responsibility status and the responsibility node number is changed to the candidate node number. Byte units not located in the hotspot padding range and the transfer range continue to retain the responsibility status and responsibility node number in the initial responsibility chain. The current transposition cycle is read. Each request delivery frame contains the Range request number, request start and end byte positions, and request timestamp. The byte unit boundaries falling within the request byte range are used as the segmentation points. The intersections of the request byte range and each byte unit byte range are defined as request sub-ranges. Each request sub-range is written with the Range request number, request sub-range number, request sub-range start byte position, request sub-range end byte position, request sub-range byte length, responsibility status, and responsibility node number. Request sub-ranges use closed-range records. The request sub-range byte length is obtained by subtracting the request sub-range start byte position from the request sub-range end byte position and then adding one. Within the same Range request, request sub-ranges are connected according to their byte positions. The order is arranged so that the same byte is not repeated, so that the requested sub-interval can accurately receive the responsibility node number corresponding to the updated initial responsibility chain; the content read rate value, available sending bandwidth value, number of bytes to be sent queue and path round-trip delay value of the node pointed to by the responsibility node number of each requested sub-interval in the updated initial responsibility chain are collected; in specific implementation, the content read rate value is obtained from the content read sampling record generated by the node monitoring agent of the responsibility node. The node monitoring agent records the content read byte number and read duration value according to the sampling period of 100 milliseconds to 500 milliseconds, and generates the content read rate value based on the ratio of the sum of the content read byte number in the sampling window of the most recent 1 second to 5 seconds before the request timestamp to the sum of the read duration value;Available transmission bandwidth is obtained from link measurement records. These records maintain the same sampling period for both the rated bandwidth and the number of bytes transmitted. The available transmission bandwidth is generated by subtracting the ratio of the number of bytes transmitted within the sampling window to the sampling window duration from the rated bandwidth. The number of bytes in the pending transmission queue is obtained from the responsible node's request queue statistics. When a Range request is written to the transmission queue, the corresponding number of bytes to be transmitted is increased; when a transmission completion callback is written, the corresponding number of bytes already transmitted is decreased. The cumulative number of bytes yet to be transmitted is recorded at the end of each sampling period. Path round-trip delay is obtained from link probe records. Within each sampling period, the target node continuously sends five transmission time packets to the responsible node. For probe messages with a stamp, five round-trip times are calculated based on the timestamp returned by the probe message, and the median of the five round-trip times is determined as the path round-trip delay value. When the responsible node number is the target node number, the path round-trip delay value is written to zero. For each request sub-interval, the content sampling record, link measurement record, request queue statistics record, and link probe record are read when the sampling timestamp is no later than the request timestamp and the time interval is the smallest. The interval between the sampling timestamp and the request timestamp does not exceed 500 milliseconds. The content reading rate value and the available sending bandwidth value are uniformly expressed in bytes per microsecond. The number of bytes to be sent in the queue and the length of the request sub-interval are uniformly expressed in bytes. The path round-trip delay value and the request timestamp are uniformly expressed in microseconds. The process involves adding the request timestamp, the ratio of the requested sub-interval byte length to the content read rate, the ratio of the sum of the pending queue bytes and the requested sub-interval byte length to the available transmission bandwidth, and the path round-trip delay to generate the requested sub-interval shadow completion timestamp. The requested sub-interval shadow completion timestamp is calculated as follows: "Requested sub-interval shadow completion timestamp = Request timestamp + Requested sub-interval byte length ÷ Content read rate + (Pending queue bytes + Requested sub-interval byte length) ÷ Available transmission bandwidth + Path round-trip delay". Here, the ratio of the requested sub-interval byte length to the content read rate represents the estimated read time, and the ratio of the sum of the pending queue bytes and the requested sub-interval byte length to the available transmission bandwidth... The ratio of available transmission bandwidth values ​​represents the expected queuing transmission time, and the path round-trip delay value represents the link transmission time. The unit of all three durations is microseconds. For each request sub-interval, the cumulative transposition frame number, Range request number, request sub-interval number, responsible node number, content read rate value, available transmission bandwidth value, number of bytes to be sent in the queue, path round-trip delay value, and request sub-interval shadow completion timestamp are written, so that the delivery closure residual can be traced back to the specific responsible node and the specific request sub-interval. For Range requests that overlap with hotspot filling ranges or yielding ranges, the cumulative shadow completion timestamp within the overlapping range is later than the transmission completion timestamp of the request delivery frame, generating a delivery closure residual.In practice, the intersection of byte intervals between each request sub-interval and the hotspot padding range and the yielding range is calculated. Request sub-intervals with byte interval intersections are identified as request sub-intervals to be verified, and duplicates are removed according to the Range request number and request sub-interval number. The sending completion timestamp in the corresponding request delivery frame of the request sub-interval to be verified is read. When the shadow completion timestamp of the request sub-interval is later than the sending completion timestamp, the length of the intersection bytes of the request sub-interval falling within the hotspot padding range and the yielding range is accumulated. The same intersection byte is only accumulated once, generating the delivery closure residual of the corresponding accumulated transposition frame. A delivery closure residual of zero indicates that after the responsibility transfer is executed according to the updated initial chain of responsibility, the request sub-intervals involved in the hotspot padding range and the yielding range can complete the simulated delivery no later than the original sending completion timestamp. A delivery closure residual greater than zero indicates that the responsibility transfer corresponding to the accumulated transposition frame causes some request bytes to be later than the original sending completion timestamp. The length of the request sub-interval bytes actually delivered by the source station for the same group of Range requests and the length of the request sub-interval bytes allocated to the source station node in the updated initial chain of responsibility are accumulated to generate the baseline padding amount and Shadow padding quantity; In specific implementation, Range requests that intersect with the hotspot padding range and the transfer range in the same cumulative transposition frame are grouped into the same group of Range requests. The actual source server delivery record is identified based on the actual delivery node number in the request delivery frame. When the actual delivery node number matches the source server node number, the corresponding actual delivery byte range is split according to the request sub-range boundary, and the byte length of the split request sub-range is accumulated to generate the baseline padding quantity. The responsibility node number of each request sub-range in the updated initial responsibility chain is read. When the responsibility node number is the source server node number, the byte length of the corresponding request sub-range is accumulated to generate the shadow padding quantity. Both the baseline padding quantity and the shadow padding quantity are accumulated after deduplication according to the Range request number, the starting byte position value of the request sub-range, and the ending byte position value of the request sub-range. This ensures that the baseline padding quantity reflects the byte delivery volume undertaken by the source server node under the current actual responsibility allocation, and that the shadow padding quantity reflects the expected source server byte delivery volume after the responsibility transfer corresponding to the cumulative transposition frame is completed. This allows for simultaneous verification of the request delivery closure degree and source server padding changes without performing actual cache transposition.

[0034] In this implementation scheme, by evaluating cumulative transposition frames in an edge computing environment using a unified time caliber, a unified byte caliber, and a unified responsibility node caliber, the shadow completion timestamp of the request sub-interval can stably reflect the delivery sequence after the responsibility transfer, the delivery closure residual can accurately reveal the impact of hot spot padding range and transfer range on the request completion boundary, and the baseline padding amount and shadow padding amount have a data basis that can be directly compared. Thus, before the actual execution of cache transposition, cumulative transposition frames that may cause delivery delays and increased source station padding can be identified, reducing the disturbance caused by edge node responsibility adjustment to the continuous delivery of Range requests, and improving the reliability of subsequent maximum continuous closed prefix extraction, maximum closed frame determination, and transposition record generation.

[0035] Specifically, the steps for extracting the maximum continuous closed prefix, determining the maximum closed frame, and generating the transposition record are as follows: Figure 2As shown, when the delivery closure residual is zero and the shadow padding amount is less than the baseline padding amount, a transposition closure marker is written into the cumulative transposition frame. In specific implementation, the delivery closure residual, baseline padding amount, and shadow padding amount are read frame by frame according to the cumulative transposition frame number. Only when the delivery closure residual is zero and the shadow padding amount is less than the baseline padding amount is the transposition closure marker of the corresponding cumulative transposition frame written with a valid value. If any condition is not met, no transposition closure marker is written, ensuring that the transposition closure marker simultaneously indicates that the requested delivery time after the responsibility transfer is not later than the original transmission completion timestamp, and that the expected source station byte delivery amount after the responsibility transfer is lower than the current actual source station byte delivery amount. For each cumulative transposition frame that does not inherit other cumulative transposition frames, along the corresponding... The cumulative transposition frame inheritance relationship is established, and cumulative transposition frames with transposition closure marks are read continuously in the generation order. Maximum consecutive closure prefixes are generated for each frame, and the last cumulative transposition frame in each maximum consecutive closure prefix is ​​determined as the corresponding maximum closure frame. Specifically, a cumulative transposition frame generation index is established based on the hotspot padding sequence, the yielding sequence, and the candidate nodes. The candidate node number, the target node base directory version number, and the candidate node base directory version number are all consistent. Furthermore, the hotspot padding unit number sequence of the subsequent cumulative transposition frame adds a hotspot padding unit number to the end of the hotspot padding unit number sequence of the previous cumulative transposition frame, and the yielding unit number sequence continues to extend from the last yielding unit of the previous cumulative transposition frame. Frames are linked as the same cumulative transpose frame inheritance chain. The cumulative transpose frame in the same inheritance chain without a preceding cumulative transpose frame is determined as the starting point for reading, and then read continuously according to the generation order of the cumulative transpose frames. When the starting point has a transpose closure mark, the starting point is written with the maximum consecutive closure prefix, and the next cumulative transpose frame is read. When the next cumulative transpose frame has a transpose closure mark, the maximum consecutive closure prefix is ​​written again. When a cumulative transpose frame without a transpose closure mark is read, the continuous reading of the current cumulative transpose frame inheritance chain is stopped, and the cumulative transpose frames continuously written before the stop position are determined as the maximum consecutive closure prefix. When the starting point does not have a transpose closure mark, no corresponding maximum consecutive closure prefix is ​​generated. The continuous reading method can maintain the hierarchical expansion relationship between the hot spot filling unit number sequence and the transfer unit number sequence, avoiding skipping the cumulative transposition frames that have not been written with transposition closure marks and directly selecting a larger hot spot filling range and transfer range; the last cumulative transposition frame in each maximum continuous closure prefix is ​​determined as the corresponding maximum closure frame, and the candidate node number, hot spot filling range, transfer range, recyclable amount, base filling amount, shadow filling amount, target node base directory version number, and candidate node base directory version number in the maximum closure frame are read; the maximum closure frame at the top of the sort is selected to generate a transposition record according to the difference between the base filling amount and the shadow filling amount from large to small, the recyclable amount from small to large, and the candidate node number from small to large.In practice, the difference between the baseline padding amount and the shadow padding amount for each maximum closed frame is first calculated, and the frames are arranged from largest to smallest according to the calculation results, prioritizing the maximum closed frames with a larger reduction in source station padding. If the calculation results are consistent, they are arranged from smallest to largest according to the recyclable amount, prioritizing the maximum closed frames with a smaller amount of cache relinquished beyond the padding requirement. If the recyclable amounts are consistent, they are arranged from smallest to largest according to the candidate node number. The candidate node number is only used as a deterministic order field when the first two levels of sorting results are the same, and is not used to evaluate the delivery performance of the candidate nodes. The candidate node number is read from the node topology table and kept unique in the node topology table, thereby avoiding multiple parallel sorting results under the same input conditions and ensuring that the transposition record is unique and can be repeatedly generated. The maximum closed frame number, target node number, candidate node number, content number, content version number, hot spot padding range, relinquished range, recyclable amount, baseline padding amount, shadow padding amount, target node baseline directory version number, and candidate node baseline directory version number are written into the transposition record, providing a unique data basis for transposition token generation and relinquished range locking.

[0036] In this implementation scheme, by constraining the continuous reading boundary of the cumulative transposition frames with transposition closure markers, the maximum continuous closure prefix maintains the hierarchical expansion relationship between the hot spot padding range and the transfer range, avoiding the selection of a larger transposition range beyond the cumulative transposition frames that have not been written with transposition closure markers. At the same time, by combining the difference between the base padding amount and the shadow padding amount, the recyclable amount, and the candidate node number, a unique maximum closure frame is determined, so that the transposition record takes into account the source station padding reduction effect, the cache transfer scale, and the result determinism, thereby improving the stability, repeatability, and actual execution reliability of transposition boundary screening, and providing a clear basis for transposition token generation and transfer range locking.

[0037] In this embodiment, the 64MiB content corresponding to content number C202 and content version number V7 is taken as the processing object. The starting byte position value and the byte position value plus one from the ending byte position value of the requested byte range, the actual delivered byte range, and the cached byte range are extracted to form continuous byte position values ​​from 0MiB, 4MiB, 8MiB to 64MiB. The byte range between two adjacent byte position values ​​is determined as 16 byte units from U1 to U16, and the minimum allocation unit of the target node cache is 8MiB. In the two consecutive transposition cycles P31 and P32, U1 to U4 are in the local responsibility state, U5 to U8 are in the responsibility gap state, U9 to U12 are in the adjacent responsibility state, and U13 to U16 are in the local responsibility state. The number of source station replacements for U5 to U8 in transposition cycle P31 is 4, 4, 4, 3 respectively, and the number of source station replacements in transposition cycle P32 is 5, 5, 5, 4 respectively. The buffer byte range of adjacent node E1 completely covers U13 to U16, and U13 to U16 do not overlap with the incomplete Range requests in the target node's request queue. Based on the hot spot padding sequence U5 to U8, the transfer sequence U13 to U16, and candidate node E1, cumulative transposition frames F1 to F4 are generated, and the delivery closure residual, baseline padding amount, and shadow padding amount of each cumulative transposition frame are calculated respectively.

[0038] like Figure 3 As shown, the horizontal byte position axis represents the content byte range from 0MiB to 64MiB, with a 4MiB byte unit formed between adjacent byte position values; rows P31 and P32 represent the number of source station fill-ins for U5 to U8 in two transposition cycles, indicating that U5 to U8 are in a responsibility gap state in two consecutive transposition cycles and the number of source station fill-ins is greater than zero. The initial responsibility chain includes local responsibilities U1 to U4, responsibility gaps U5 to U8, adjacent responsibilities U9 to U12, and local responsibilities U13 to U16 in sequence, and the candidate node area indicates that adjacent node E1 completely covers U13 to U16. The hotspot padding range of cumulative transpose frame F1 is U5, and the yielding range is U13 to U14. Cumulative transpose frame F2 inherits from cumulative transpose frame F1, with the hotspot padding range expanded to U5 to U6, and the yielding range remaining U13 to U14. Cumulative transpose frame F3 inherits from cumulative transpose frame F2, with the hotspot padding range expanded to U5 to U7, and the yielding range expanded to U13 to U16. Cumulative transpose frame F4 inherits from cumulative transpose frame F3, with the hotspot padding range expanded to U5 to U8, and the yielding range remaining U13 to U16. The delivery closure residuals of cumulative transpose frames F1, F2, and F3 are all zero, and the shadow padding amounts are all less than the reference padding amounts, thus forming the maximum continuous closure prefix F1→F2→F3. Cumulative transpose frame F4 generates a 4MiB delivery closure residual and does not write a transpose closure mark, therefore, cumulative transpose frame F3 is determined as the maximum closure frame, and a transpose record is generated based on cumulative transpose frame F3.

[0039] Specifically, the steps for generating a transposition token and locking the transfer range based on the transposition record are as follows: A transposition token is generated based on the transposition record, and the target node number, candidate node number, content number, content version number, hotspot replacement range, transfer range, target node base directory version number, and candidate node base directory version number are written into the transposition token. In practice, the target node reads the corresponding data according to the largest closed frame number in the transposition record, writes all the data into the same transposition token record, generates a transposition token number according to the target node number, the current transposition cycle number, and the transposition token generation order, writes the transposition token number into the transposition token record, and sends the transposition token to the candidate node, enabling the candidate node to determine the transfer range based on the content number, content version number, and transfer range. The transfer range is defined as the cache byte range to be transferred; the cache content version number is the content version number in the candidate node's current cache directory that corresponds to the transfer range; after the candidate node confirms that the cache content version number matches the content version number in the transfer token, the cache byte range completely covers the transfer range, and the current directory version number matches the candidate node's base directory version number, it locks the transfer range and generates a responsibility acceptance marker; in specific implementation, the candidate node retrieves cache directory records from the current cache directory that match the content number in the transfer token, the content version number matches the content version number in the transfer token, the cache start position value is not greater than the start position value of the transfer range, and the cache end position value is not less than the end position value of the transfer range, and reads the cache directory... The cache segment number in the record is used as the candidate node's cache segment number, and the candidate node's current directory version number is compared with the candidate node's baseline directory version number. After verification, the candidate node atomically updates the directory metadata, writing the cache directory record that completely covers the transfer range into the locked state, and writing the cache segment pointed to by the cache directory record into the reserved state. The locked objects are limited to the cache directory record and cache segment corresponding to the transfer range. While the transfer range is in the locked state, the candidate node is prohibited from deleting, evicting, truncating, overwriting, or version replacing cache bytes within the transfer range, and is prohibited from releasing the physical cache space occupied by the corresponding cache segment, while keeping the cache bytes within the transfer range readable. Locking the transfer range only fixes the cache segment in the candidate node. The cached content and cached directory records do not change the responsibility status in the initial chain of responsibility, and Range request routing is not enabled. Range request routing is executed after the token effective timestamp is generated, and directory responsibility changes take effect after the directory transaction is committed. After the candidate node successfully writes the cached directory record to the locked state and successfully writes the cached segment to the reserved state, a responsibility acceptance mark is generated, and a correspondence between the responsibility acceptance mark and the transposition token is established. If the version number of the content in the current cached directory of the candidate node is inconsistent with the version number of the content in the transposition token, the cached byte range does not completely cover the transfer range, the current directory version number is inconsistent with the candidate node's base directory version number, the cached directory record locking fails, or the cached segment retention fails, a responsibility acceptance mark is not generated.The locked state of the transferred scope persists until the directory transaction is successfully committed. If the directory transaction fails to meet the commit conditions or fails to commit, the locked state is released according to the transposition rollback result, thereby ensuring that candidate nodes continuously retain the same content version and the same cache byte range during the transposition verification period.

[0040] In this implementation scheme, by establishing a stable association between the transposition token, the responsibility acceptance mark, the cache directory record corresponding to the transfer scope, and the cache segment, the candidate node maintains consistency in content version, cache byte range, and physical cache space during the transposition verification period. This avoids the failure of the transfer basis caused by cache eviction, directory updates, and content overwriting, thereby improving the credibility of the responsibility acceptance mark and the executability of the transfer scope. It provides stable data acceptance conditions for hot spot fill byte verification, Range request diversion, and directory transaction commit, and reduces the risk of cache missing, directory conflict, and request delivery interruption during responsibility switching.

[0041] Specifically, the steps for verifying hotspot padding bytes and performing Range request splitting and transposition verification are as follows: The target node retrieves neighboring nodes whose content version number matches the transposition token and whose cached byte range completely covers the hotspot padding range. If multiple neighboring nodes exist, the neighboring node with the smallest path round-trip latency value is selected. If the retrieval is successful, the hotspot padding byte is read from the selected neighboring node; if the retrieval fails, the hotspot padding byte is read from the origin node and written to the temporary storage area. In practice, the target node establishes retrieval conditions from the current cache directory of each neighboring node according to the content number, content version number, cache start position value, and cache end position value. When the content number matches the content number in the transposition token, the content version number matches the content version number in the transposition token, the cache start position value is not greater than the start position value of the hotspot padding range, and the cache end position value is not less than the end position value of the hotspot padding range, the corresponding neighboring node is written to the hotspot padding reading node set. The path round-trip latency value is read from the link probe records between the target node and each neighboring node, using the path round-trip latency value from the most recent valid link probe record before the retrieval time. The interval between the recorded timestamp and the retrieval time shall not exceed 500 milliseconds. If it exceeds 500 milliseconds, the target node shall continuously send five probe messages carrying the sending timestamps, and write the median of the five round-trip times into the path round-trip delay value. When the hotspot padding read node set contains multiple adjacent nodes, they shall be arranged in ascending order of path round-trip delay value, and the adjacent node at the top of the sorted list shall be selected as the read node. When the hotspot padding read node set is empty, the source node shall be determined as the read node. The target node shall request a temporary storage segment according to the byte length of the hotspot padding range, and the starting position of the temporary storage segment shall be determined according to... The target node cache is aligned to the smallest allocation unit. The temporary storage segment occupancy is rounded up according to the target node cache smallest allocation unit, and the temporary storage segment number, content number, content version number, hot spot padding range, and transposition token number are written into it. The temporary storage segment is not written to the cache directory before the transposition verification is completed. The target node reads the hot spot padding bytes from the reading node in segments according to the byte order from the start position value to the end position value of the hot spot padding range, and writes them into the temporary storage segment according to the byte position of the hot spot padding bytes in the content, so that the read bytes correspond one-to-one with the byte positions in the temporary storage segment.The digest values ​​are calculated for bytes at the same position in both the read bytes and the temporary storage segment. If the digest values ​​are identical, a token activation timestamp is generated; otherwise, the responsibility acceptance flag is canceled, the transfer range lock is released, the temporary storage segment is released, and the transposition token is written to the invalidation status. Specifically, the digest block length is read from the cache verification parameter table, with a length ranging from 64 KiB to 1 MiB. The digest value is calculated using the SHA-256 digest algorithm. The starting position of the hotspot padding range is used as the starting point of the first digest block. Hotspot padding bytes are continuously divided according to the digest block length, and the last digest block is determined by the length of the remaining bytes within the hotspot padding range. When the target node completes reading each digest block, it calculates the first digest value for the read byte at the corresponding byte position in the read buffer. After the temporary storage segment is written, temporary bytes with the same start byte position value and the same end byte position value are read from the temporary storage segment, and the second digest value is calculated. Then, the first digest value and the second digest value are compared block by block according to the digest block number. When the first digest value and the second digest value of all digest blocks are consistent, the target node generates a token effective timestamp with the standard timestamp of the last digest block's verification completion and writes the transposition token to the effective status. When the first digest value and the second digest value of any digest block are inconsistent, subsequent digest verification is stopped, and the responsibility acceptance mark is canceled, the transfer range lock is released, the temporary storage segment is released, and the transposition token is written to the invalid status through the same atomic operation to prevent content errors and missing hot filler bytes from participating in the Range request delivery.Range requests with a request timestamp earlier than the token's effective timestamp are delivered according to their pre-transfer responsibility status. Other Range requests are divided according to byte unit boundaries. Request sub-intervals within the hotspot padding range are delivered by the target node, request sub-intervals within the relinquishment range are delivered by candidate nodes, and other request sub-intervals are delivered according to their pre-transfer responsibility status. In practice, the pre-transfer responsibility status is read from the initial responsibility chain that has not been updated in the current transfer cycle. When the request timestamp is earlier than the token's effective timestamp, the responsibility node number and delivery path already used for the corresponding Range request are not changed. When the request timestamp is not earlier than the token's effective timestamp, the byte unit boundaries in the initial responsibility chain of the current transfer cycle are read, and the Range request is divided into request sub-intervals that do not cross byte unit boundaries. An R is written to each request sub-interval. The request number, request sub-range number, request sub-range start byte position value, request sub-range end byte position value, and distribution node number are specified. When all request sub-ranges are within the hotspot padding range, the distribution node number is written to the target node number, and the corresponding hotspot padding byte is read from the temporary storage segment. When all request sub-ranges are within the transfer range, the distribution node number is written to the candidate node number, and the corresponding byte is read from the candidate node's locked cache segment. When the request sub-range is not within the hotspot padding range or the transfer range, delivery is performed according to the responsible node number in the responsibility status before the transfer. When the same Range request contains multiple request sub-ranges, the target node merges the response bytes according to the request sub-range start byte position value in ascending order, so that the change of responsible node does not change the byte order of the Range request.From the token effective timestamp to the end timestamp of the transposition period containing the token effective timestamp, for each Range request, the union of the requested byte range minus the actual delivered byte range of the same Range request is calculated. The remaining byte length is accumulated to generate the actual delivery closure residual. The byte lengths of the request sub-ranges allocated to the source node before transposition and actually delivered by the source node are also accumulated separately to generate the verification baseline padding amount and the actual padding amount. In specific implementation, Range requests with request timestamps no earlier than the token effective timestamp and no later than the end timestamp of the transposition period are read. The actual delivery start and end byte position values, actual delivery node numbers, and transmission completion timestamps in the request delivery frames are collected according to the Range request number. Only those already written to the transmission frame are considered. Delivery records with a completion timestamp and actual delivery start and end byte positions are included in the union of actual delivery byte intervals. Records that have not yet been sent, have not been written with a completion timestamp, or have not formed an actual delivery byte interval are not included in the union of actual delivery byte intervals. For the same Range request, each actual delivery byte interval is first sorted in ascending order of its actual delivery start byte position value. If the start byte position value of the current actual delivery byte interval is not greater than the end byte position value of the previous merged interval plus one, the current actual delivery byte interval is merged into the previous merged interval, and the larger of the two end byte position values ​​is used as the end byte position value of the merged interval. If the start byte position value of the current actual delivery byte interval is greater than the end byte position value of the previous merged interval, the current actual delivery byte interval is merged into the previous merged interval. When the position value is incremented by one, a new merge interval is created. After all actual delivered byte intervals are processed, a union of non-overlapping actual delivered byte intervals arranged according to byte position is formed. The union of actual delivered byte intervals is then subtracted from the request byte intervals. The length of the remaining bytes not covered by the union of actual delivered byte intervals is included in the actual delivery closure residual. The actual delivery closure residual is expressed in bytes and accumulated within the current transposition cycle. A zero actual delivery closure residual indicates that the request byte intervals of each Range request within the verification period have been delivered. When calculating the verification baseline padding amount, the Range requests within the verification period are divided according to the byte unit boundaries. The responsibility node number in the responsibility status before transposition is read. The responsibility node number is the source node number. The cumulative length of the corresponding request sub-interval is calculated. When calculating the actual padding amount, the source station delivery record is identified based on the actual delivery node number in the request delivery frame. When the actual delivery node number is consistent with the source station node number and the sending completion timestamp has been written, the cumulative length of the corresponding request sub-interval is calculated. Both the verification benchmark padding amount and the actual padding amount are cumulatively deduplicated according to the Range request number, the starting byte position value of the request sub-interval, and the ending byte position value of the request sub-interval. This ensures that the verification benchmark padding amount represents the byte delivery amount undertaken by the source station node when maintaining the responsibility state before the swap, and that the actual padding amount represents the byte delivery amount actually completed by the source station node after executing the Range request split. This provides a unified verification standard for subsequent judgment of delivery closure and source station padding reduction.

[0042] In this implementation scheme, by uniformly verifying the hot spot padding bytes, Range request splitting results, and actual delivered byte ranges in the edge computing environment, the responsibility switching boundary before and after the token effective timestamp remains clear, ensuring the integrity and reliability of cached content within the hot spot padding range. It also enables the actual delivery closure residual, verification benchmark padding amount, and actual padding amount to be consistently compared based on the real delivery results, thereby reducing the risk of cached content corruption, missed delivery of request sub-ranges, and source station padding statistics distortion, and improving the accuracy, traceability, and reliability of transposition verification results and directory transaction commits.

[0043] Specifically, when delivery is closed and source node filler is reduced, a directory transaction is committed, writing hotspot filler directory records and responsibility transfer records, and releasing the transfer cache segment. Otherwise, the rollback operation is performed as follows: After the expiration period of the token's effective timestamp ends, when the target node's current directory version number and the candidate node's current directory version number are equal to the target node's baseline directory version number and the candidate node's baseline directory version number in the expiration token, respectively; when the responsibility acceptance flag exists and the transfer scope is locked; when the actual delivery closure residual is zero and the actual filler amount is less than the verification baseline filler amount, the target node's hotspot filler directory record and the candidate node's responsibility transfer record are written in the same directory transaction, and the target node's responsibility transfer record is deleted. The process involves transferring cache directory records. In practice, the target node generates a cache directory record when the content bytes are first written to the local cache and directory registration is completed. This cache directory record includes the target node number, content number, content version number, cache byte range, cache segment number, responsible node number, and directory version number. After the transfer record determines the transfer range, the target node searches for cache directory records whose byte range intersects with the transfer range and whose responsible node number matches the target node number, based on the content number and content version number. When the cache byte range of a cache directory record is completely within the transfer range, the cache directory record is directly identified as the target node's transferred cache directory record. The cache byte range of the cache directory record spans... When crossing the boundary of the transfer range, a directory boundary splitting result is generated in the directory transaction preparation area based on the byte position value obtained by adding one to the start and end positions of the transfer range. The original cached directory record is written into the cached directory record to be replaced. Directory sub-records in the directory boundary splitting result whose cached byte intervals are completely within the transfer range are identified as the target node's transferred cached directory records, while directory sub-records outside the transfer range are identified as the target node's retained cached directory records. The directory boundary splitting result is not written to the target node's current cached directory and does not change the target node's current directory version number before the directory transaction is committed. The cache segment number in the target node's transferred cached directory record points to the target node's transferred cache area. The target node's transferred cache directory record represents the mapping of directories to be deleted within the target node, while the candidate node's transferred responsibility record indicates that the candidate node assumes the responsibility for delivery of the transferred scope after the directory transaction is committed. After the expiration time of the expiration token's effective timestamp arrives, the target node generates a directory transaction number based on the expiration token number, establishes a directory transaction record in the ready state, and writes the target node number, candidate node number, content number, content version number, hotspot filling range, transferred scope, target node base directory version number, candidate node base directory version number, actual delivery closure residual, verification base filling amount, actual filling amount, and the transferred cache segment number of each target node.The target node reads its current directory version number from its local cache directory, and the candidate node reads its current directory version number from its local cache directory. The candidate node synchronously reads the responsibility acceptance flag and transfer scope lock status associated with the swap token. When all verification data meets the directory transaction commit conditions, a transaction write lock is applied to the temporary storage segment metadata record in the target node and the transfer cache directory record for each target node. A transaction write lock is also applied to the cache directory record corresponding to the transfer scope in the candidate node, ensuring that the temporary storage segment status and directory version remain unchanged from the completion of verification to the directory transaction commit. The target node's hotspot replacement directory record is written with the target node number, content number, content version number, hotspot replacement scope, temporary storage segment number, and swap token number. The candidate node's responsibility transfer record is written with the candidate node number, content number, content version number, transfer scope, and candidate section number. The system uses the cache segment number and transposition token number; it registers the deletion operation for the target node's transferred cache directory record when the cache byte range is completely within the transfer range; it registers the deletion operation for the original record for each cache directory record to be replaced, and registers the write operation for the corresponding target node's retained cache directory record. After the directory transaction is committed, the corresponding target node's transferred cache directory record is not written. The target node's hot spot supplement directory record write operation, the candidate node's transfer responsibility record write operation, the target node's transferred cache directory record deletion operation, the replacement cache directory record deletion operation, and the target node's retained cache directory record write operation all use the same directory transaction number and the same commit sequence number. After both the target node and the candidate node write the transaction preparation completion mark, a transaction commit mark is generated, so that the hot spot supplement range directory write, the transfer of responsibility within the transfer range, and the target node's original directory deletion take effect at the same commit boundary. After a directory transaction is successfully committed, the temporary segment is converted to a cache segment, the transfer range is unlocked, and the target node's transferred cache segment is released. In practice, the segment status of the temporary segment is changed from temporary to cache, and the temporary segment number is registered as the cache segment number corresponding to the target node's hotspot padding directory record. The conversion process only changes the segment status and directory association, and does not copy the hotspot padding bytes that have already completed digest verification again. Subsequently, the locking status of the cache directory record corresponding to the candidate node's transfer range and the retention status of the cache segment are released, and the candidate node's transfer responsibility record is retained. The target node reads the transfer cache segment number of each target node from the directory transaction record, and locates the transfer cache segment of each target node according to the transfer cache segment number of each target node. The target node's transfer cache segment is written to the release status. When the cache segment reference count is zero, the corresponding physical allocation block is returned to the target node's cache allocation table. When the cache segment reference count is greater than zero, the release status is maintained until the read operation that has started ends.After the directory transaction is committed, the current directory version number of the target node and the current directory version number of the candidate node are incremented respectively, and the incremented directory version number, directory transaction number, commit timestamp, and transposition token number are written into the transposition commit record. If any condition is not met or the directory transaction commit fails, the directory transaction is rolled back. Range requests whose request timestamp is no earlier than the token's effective timestamp and have not yet been delivered are restored to their pre-transfer responsibility status for delivery. After the candidate node has delivered the requested sub-ranges, the responsibility acceptance flag is canceled, the transfer range lock is released, the temporary segment is released, and the transfer token is written to the invalidation state. In specific implementation, if any directory transaction commit condition is not met, the directory transaction record is changed from the ready state to the rollback state, and the deletion operations of the target node hotspot supplement directory record, the candidate node transfer responsibility record, and the target node transfer cache directory record are revoked. If neither the target node nor the candidate node returns a commit success flag during the directory transaction commit process, the cache directory record and directory version number before the transaction commit are restored according to the directory transaction number, and the transaction write lock is released. Range requests whose request timestamp is no earlier than the token's effective timestamp are read from the target node's request queue. When the requested byte range has not yet been completely covered by the union of the actual delivered byte ranges with the send completion timestamp, the corresponding Range request is determined as a Range request that has not yet been delivered. The delivery path for the undelivered request sub-interval is regenerated based on the responsible node number in the responsibility status before the transposition. Request sub-intervals already received by the candidate node continue delivery. The target node stops allocating new request sub-intervals to candidate nodes that intersect with the byte intervals in the current transposition token's transfer range. The initial delivery timeout value is generated by summing three times the candidate node's path round-trip delay value and the request sub-interval byte length value divided by the available transmission bandwidth value. The 95th percentile of the request sub-interval delivery completion time in the last 24 hours is read, and the initial delivery timeout value is summed with the 95th percentile. The larger of the quintile values ​​is used. If the larger value is less than 1 second, the delivery timeout threshold is set to 1 second. If the larger value is greater than 10 seconds, the delivery timeout threshold is set to 10 seconds. If the larger value is between 1 and 10 seconds, the larger value is used as the delivery timeout threshold. When the candidate node's sending process returns a non-zero status value for the request sub-interval sending operation and has not written a sending completion timestamp, a delivery failure flag is generated. The Range request number, request sub-interval number, the actual delivered byte range that has been delivered, and the failure timestamp are written into the delivery failure record. Then, the delivery failure flag is returned to the target node.When any of the following conditions are met: a candidate node returns a delivery failure flag, the connection interruption duration exceeds the delivery timeout threshold, or the data is not written to the transmission completion timestamp after three consecutive retransmissions, the target node reads the union of the actual delivered byte ranges already delivered by the candidate node. It then subtracts the delivered byte ranges from the corresponding request sub-range and reallocates the remaining byte ranges according to the responsible node number in the pre-transfer responsibility state. If the responsible node number points to the target node, the target node delivers; if it points to the source node, the source node delivers; and if it points to an adjacent node, the corresponding adjacent node delivers. After the union of the actual delivered byte ranges already delivered by the candidate node and the reallocated remaining byte ranges already written to the transmission completion timestamp completely cover the request sub-ranges already received by the candidate node, the responsibility acceptance flag associated with the transposition token is canceled, the locking state of the corresponding cache directory record and the retention state of the cache segment are released, the temporary segment in the target node is released, and the transposition token is written to the invalid state. This ensures that the rollback process does not truncate the delivery of the already started request sub-ranges, while guaranteeing that incomplete bytes can be restored to the pre-transfer responsibility state for continued delivery.

[0044] In this implementation scheme, by incorporating the target node's transferred cache directory record, candidate node's transferred responsibility record, target node's transferred cache segment, temporary storage segment, and transposition token into the same directory transaction boundary in the edge computing environment, the hot spot filling range writing, transferred responsibility transfer of the transferred range, and physical cache release are kept synchronized. In the event of a commit failure, the continuous delivery of received request sub-ranges is maintained, and incomplete bytes can be restored to the responsibility state before transposition. This avoids directory state splitting, cache responsibility dangling, and request byte loss, thereby improving the atomicity, rollback integrity, and distributed cache consistency of the transposition operation.

[0045] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0046] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A distributed CDN dynamic caching and eviction system for hot content based on edge computing, characterized in that, include: The cache responsibility division module is used to collect Range request records and cache directories of target nodes and adjacent nodes, generate request delivery frames and baseline directory snapshots, divide byte units and mark responsibility status, and generate the initial responsibility chain for two consecutive transposition cycles. The cumulative transposition construction module is used to generate hot spot replacement sequence, transfer sequence and candidate node set based on the initial responsibility chain, generate mutually inherited cumulative transposition frames according to the replacement occupancy and reclaimable amount, and determine the hot spot replacement range and transfer range. The closed boundary solution module is used to update the initial chain of responsibility based on the cumulative transposition frames, calculate the shadow completion timestamp of the requested sub-interval, the delivery closure residual, the baseline fill amount and the shadow fill amount, extract the maximum continuous closure prefix, determine the maximum closure frame and generate the transposition record; The transposition token execution module is used to generate transposition tokens based on transposition records and lock the transfer range, verify hot spot padding bytes, and perform Range request routing and transposition verification. When delivery is closed and source site padding is reduced, the directory transaction is committed, hot spot padding directory records and transfer responsibility records are written, and the transfer cache segment is released; otherwise, the transposition operation is rolled back.

2. The distributed CDN hot content dynamic caching and eviction system based on edge computing according to claim 1, characterized in that: The specific steps for collecting the Range request records and cache directory of the target node and adjacent nodes, and generating the request delivery frame and baseline directory snapshot are as follows: The edge CDN node performing the current transposition process is identified as the target node. The target node number, adjacent node number, origin node number, content number, content version number, Range request number, request start and end byte position value, actual delivery start and end byte position value, actual delivery node number, request timestamp, and sending completion timestamp are obtained. The request is grouped according to the Range request number and a request delivery frame is generated for each group. Obtain the cache directories of the target node and each adjacent node. The cache directories include the cache byte range, the responsible node number, and the directory version number. Copy the cache directories corresponding to the start timestamp of the transposition cycle as the base directory snapshots.

3. The distributed CDN hot content dynamic caching and eviction system based on edge computing according to claim 2, characterized in that: The specific steps for dividing byte units, marking responsibility status, and generating the initial responsibility chain for two consecutive transposition cycles are as follows: The current transposition period and the previous transposition period that is adjacent in time are defined as two consecutive transposition periods. For the same content number and content version number, the starting byte position value and the byte position value of the request byte interval, the actual delivery byte interval, and the cached byte interval within the two transposition periods are extracted, deduplicated, and sorted in ascending order. The byte interval between two adjacent byte position values ​​is defined as a byte unit. Byte unit numbers are assigned to each byte unit in ascending order of byte position. The request byte interval, the actual delivery byte interval, and the cached byte interval in the request delivery frame and the base directory snapshot are split according to the start and end byte position values ​​of the byte unit. When the target node's cached byte range completely covers the byte unit, write the local responsibility status and the target node number; when the target node does not completely cover the byte unit, and the cached byte range of the adjacent responsible nodes registered in the baseline directory snapshot completely covers the byte unit, write the adjacent responsibility status and the registered node number; when no adjacent responsibility status is written and there are adjacent nodes whose cached byte range completely covers the byte unit, select the adjacent node that delivers the most byte units in the corresponding transposition cycle, and write the adjacent responsibility status and the selected node number; when the cached byte ranges of the target node and each adjacent node do not completely cover the byte unit, write the responsibility gap status and the source node number. The number of records delivered by the source station for each byte unit within the corresponding transposition cycle is counted, and the source station's replacement count is generated. The byte units are connected according to their byte positions, and the content number, content version number, responsibility status, responsibility node number, and source station replacement count are written in, generating the initial responsibility chain for two transposition cycles respectively.

4. The distributed CDN hot content dynamic caching and eviction system based on edge computing according to claim 3, characterized in that: The specific steps for generating the hotspot replacement sequence, the transfer sequence, and the candidate node set based on the initial chain of responsibility are as follows: Read the initial responsibility chain of two consecutive transposition cycles, and connect the consecutive byte units that are in a responsibility gap state in both transposition cycles and whose source station filling count is greater than zero into a hot spot filling sequence; read byte units one by one from both ends of the consecutive byte range of each local responsibility state in the current transposition cycle, and stop when reading a byte unit that overlaps with the incomplete Range request in the target node's request queue, and form a transfer sequence for the consecutive byte units read before stopping in each reading direction; Read byte units one by one along the transfer sequence, and search for adjacent nodes with the same content number and content version number, and whose cache start position value is not greater than the byte unit start position value and cache end position value is not less than the byte unit end position value; take the set of adjacent nodes corresponding to the first byte unit as the candidate node set, and find the intersection of each subsequent unit with the set of adjacent nodes corresponding to the current byte unit. When the intersection is empty, terminate the transfer sequence at the previous byte unit, and retain the candidate node set before the intersection is empty; when the set of adjacent nodes corresponding to the first byte unit is empty, discard the corresponding transfer sequence.

5. The distributed CDN hot content dynamic caching and eviction system based on edge computing according to claim 4, characterized in that: The specific steps for generating mutually inherited cumulative transposition frames based on the padding occupancy and reclaimable amount, and determining the hotspot padding range and transfer range are as follows: For each hotspot padding sequence, each yielding sequence, and each candidate node in the candidate node set, one byte unit is added each time according to the hotspot padding sequence. The length of the continuous byte range formed by the added byte units is rounded up according to the minimum allocation unit of the target node cache to generate the padding occupancy. Byte units are continuously added along the yielding sequence, and the physical allocation block occupancy of the entire content byte range within the added yielding range is accumulated to generate the reclaimable amount. When the reclaimable amount is not less than the padding occupancy, a cumulative transposition frame is generated. The continuous byte range covered by the hotspot padding unit number sequence is determined as the hotspot padding range, and the continuous byte range covered by the yielding unit number sequence is determined as the yielding range. The hotspot padding unit number sequence, the yielding unit number sequence, the hotspot padding range, the yielding range, the candidate node number, the reclaimable amount, the target node base directory version number, and the candidate node base directory version number are written into the frame. The subsequent cumulative transposition frame retains the candidate node number, target node base directory version number, and candidate node base directory version number of the previous cumulative transposition frame. It adds a hot spot padding unit number to the end of the hot spot padding unit number sequence of the previous cumulative transposition frame, and continues to add the yielding unit number after the last yielding unit of the previous cumulative transposition frame until the reclaimable amount is not less than the padding occupancy. When the yielding sequence is read and the reclaimable amount is still less than the padding occupancy, the generation of subsequent cumulative transposition frames stops.

6. The distributed CDN hot content dynamic caching and eviction system based on edge computing according to claim 5, characterized in that: The specific steps for updating the initial responsibility chain based on the cumulative transposition frames and calculating the shadow completion timestamp, delivery closure residual, baseline padding amount, and shadow padding amount for the requested sub-interval are as follows: For each cumulative transposition frame, the target node copies the initial responsibility chain of the current transposition cycle, changes the hotspot padding unit to the local responsibility status and target node number, changes the transfer unit to the adjacent responsibility status and candidate node number, and divides the Range request of the current transposition cycle into request sub-intervals according to the byte unit boundary. Collect the content read rate, available transmission bandwidth, number of bytes in the pending transmission queue, and path round-trip delay of the node pointed to by the responsibility node number of each requested sub-interval in the updated initial chain of responsibility; add the request timestamp, the ratio of the requested sub-interval byte length to the content read rate, the ratio of the sum of the number of bytes in the pending transmission queue and the requested sub-interval byte length to the available transmission bandwidth, and the path round-trip delay to generate the request sub-interval shadow completion timestamp; For Range requests that overlap with hotspot fill ranges or transfer ranges, accumulate the length of request sub-interval bytes where the shadow completion timestamp within the overlapping range is later than the completion timestamp sent in the request delivery frame, and generate a delivery closure residual; accumulate the length of request sub-interval bytes actually delivered by the source station for the same group of Range requests and the length of request sub-interval bytes allocated to the source station node in the updated initial chain of responsibility, and generate the baseline fill amount and shadow fill amount.

7. The distributed CDN hot content dynamic caching and eviction system based on edge computing according to claim 6, characterized in that: The specific steps for extracting the maximum continuous closed prefix, determining the maximum closed frame, and generating the transposition record are as follows: When the delivery closure residual is zero and the shadow padding amount is less than the reference padding amount, a transposition closure mark is written in the cumulative transposition frame; for each cumulative transposition frame that does not inherit other cumulative transposition frames, the cumulative transposition frames with transposition closure marks are read continuously along the corresponding cumulative transposition frame inheritance relationship and in the order of generation, and the maximum continuous closure prefix is ​​generated respectively, and the last cumulative transposition frame in each maximum continuous closure prefix is ​​determined as the corresponding maximum closure frame; Sort the candidate nodes by the difference between the baseline padding amount and the shadow padding amount from largest to smallest, by the amount of recyclable data from smallest to largest, and by the candidate node number from smallest to largest. Select the largest closed frame at the top of the sorted list to generate the transposition record.

8. The distributed CDN hot content dynamic caching and eviction system based on edge computing according to claim 7, characterized in that: The specific steps for generating a swap token based on the swap record and locking the transfer range are as follows: Generate a swap token based on the swap record, and write the target node number, candidate node number, content number, content version number, hotspot replacement range, transfer range, target node base directory version number and candidate node base directory version number into the swap token; Once the candidate node confirms that the cached content version number matches the content version number in the transposition token, the cached byte range completely covers the transfer range, and the current directory version number matches the candidate node's base directory version number, it locks the transfer range and generates a responsibility acceptance flag.

9. The distributed CDN hot content dynamic caching and eviction system based on edge computing according to claim 8, characterized in that: The specific steps for verifying hot spot padding bytes, performing Range request splitting and transposition verification are as follows: The target node retrieves adjacent nodes whose version number matches the transposition token and whose cached byte range completely covers the hotspot padding range. If multiple adjacent nodes exist, the adjacent node with the smallest path round-trip latency is selected. If the retrieval is successful, the hotspot padding bytes are read from the selected adjacent node. If the retrieval fails, the hotspot padding bytes are read from the source node and written to the temporary storage area. The digest value is calculated for the bytes at the same position in the read bytes and the temporary storage area. If the digest values ​​are the same, a token effective timestamp is generated. Otherwise, the responsibility acceptance mark is canceled, the transfer range lock is released, the temporary storage area is released, and the transposition token is written to the invalidation status. Range requests with a request timestamp earlier than the token effective timestamp are delivered according to the pre-transfer responsibility status; other Range requests are divided according to byte unit boundaries, with request sub-intervals within the hotspot padding range delivered by the target node, request sub-intervals within the relinquishment range delivered by the candidate node, and other request sub-intervals delivered according to the pre-transfer responsibility status; from the token effective timestamp to the end timestamp of the transfer cycle in which the token effective timestamp is located, for each Range request, the request byte interval is subtracted from the union of the actual delivered byte intervals of the same Range request, the remaining byte length is accumulated to generate the actual delivery closure residual, and the byte lengths of the request sub-intervals allocated to the source node and actually delivered by the source node before the transfer responsibility status are accumulated respectively to generate the verification baseline padding amount and the actual padding amount.

10. The distributed CDN hotspot content dynamic caching and eviction system based on edge computing according to claim 9, characterized in that: The specific steps for committing the directory transaction, writing the hotspot fill directory record and the responsibility transfer record, and releasing the transferred cache segment when the delivery is closed and the source station fill is reduced are as follows: Otherwise, the rollback operation is performed. After the expiration period of the token effective timestamp ends, when the target node's current directory version number and the candidate node's current directory version number are equal to the target node's base directory version number and the candidate node's base directory version number in the expiration token, respectively, when the responsibility acceptance mark exists and the transfer scope is locked, when the actual delivery closure residual is zero and the actual fill amount is less than the verification base fill amount, write the target node hotspot fill directory record and the candidate node transfer responsibility record in the same directory transaction, and delete the target node transfer cache directory record. After the directory transaction is successfully committed, the temporary segment is converted into a cache segment, the transfer range is unlocked, and the target node's transfer cache segment is released. If any condition is not met or the directory transaction fails to commit, the directory transaction is rolled back. Range requests whose request timestamp is not earlier than the token effective timestamp and have not yet been delivered are restored to the delivery according to the responsibility status before the transposition. After the request sub-ranges received by the candidate node are delivered, the responsibility acceptance mark is canceled, the transfer range lock is released, the temporary segment is released, and the transposition token is written to the invalidation status.

Images