A breakpoint continuation method based on edge cache and cloud two-way confirmation

Abstract

The present application relates to the technical field of computer data synchronization, and particularly relates to a breakpoint resume transmission method based on edge cache and cloud bidirectional confirmation. The method comprises the following steps: when communication is interrupted, a data sequence number is allocated for business data record and written into a persistent cache area, and a local synchronization state record is generated; after communication is restored, a cloud server compares a received state record and an archived state record, determines a data range to be supplemented and a received data range to be archived, and generates a differential synchronization instruction; an edge terminal supplements the missing data, the cloud server writes and merges the received data to be archived according to an idempotent key, and forms an archived candidate range; an archived confirmation record is generated after target storage completes archiving and submission, and the edge terminal releases the local cache according to the continuous archiving range and advances the cache release pointer. The present application distinguishes the processing paths of the unreceived data and the received unarchived data, reduces repeated transmission and repeated writing, and makes the cache release consistent with the continuous archiving state.

Description

Technical Field

[0001] This invention relates to the field of computer data synchronization and database interface technology, and in particular to a breakpoint resume method based on edge caching and cloud bidirectional confirmation. Background Technology

[0002] In the field of computer data synchronization and database interface technology, edge terminals typically upload continuously generated business data records to a cloud server, where the cloud server performs integrity verification and storage on the received data packets. When communication is interrupted, existing solutions generally write the unuploaded business data records to a local cache. After communication is restored, the interrupted transmission is resumed based on the uploaded location, data sequence number, timestamp, or the range of missing data returned by the cloud. After completing data reception or integrity verification, the cloud server typically sends a reception confirmation to the edge terminal, which then updates its local cache state based on the confirmation.

[0003] Existing solutions often use whether data packets have arrived at the cloud server, whether integrity checks have passed, or whether temporary storage operations have been completed as the criteria for determining synchronization status, without clearly distinguishing between the reception status and the archiving status after business data records are written to the target storage. When the cloud server has received the data packets, but the target storage has not completed archiving due to write interruption, archive submission failure, or changes in service status, the edge terminal finds it difficult to identify the actual archiving status of the corresponding business data record based on a normal reception confirmation. If it continues to retransmit the already received data, it is easy to cause duplicate transmission and duplicate writing. If the local cache is released directly based on the reception confirmation, it may cause inconsistency between the edge cache status and the cloud archiving status.

[0004] Furthermore, existing buffer release methods often rely on the reception result of a single data packet, a fixed buffer period, or the buffer capacity. When subsequent data has been received or archived, while preceding data is still in a state of not being received, pending verification, or failed archiving, a single acknowledgment result is difficult to represent the actual archiving boundary of a continuous data sequence. Edge terminals are prone to releasing subsequent buffers across preceding unarchived data. When archiving acknowledgment is delayed or acknowledgment messages are lost, edge terminals also find it difficult to determine the corresponding processing path between retransmission, continuing to wait for archiving, and releasing the local buffer.

[0005] Therefore, it is necessary to address the issue of how to identify the continuous archiving range based on the cloud receiving status and archiving status, and how to enable edge terminals to release local cache according to the continuous archiving status, in the process of synchronizing business data records after communication interruption recovery. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a method for resuming interrupted downloads based on edge caching and bidirectional confirmation with the cloud, comprising:

[0007] S100. When communication is interrupted, the synchronization cycle identifier is determined according to the terminal identifier, the data sequence number is assigned to the business data record and written to the persistent cache, and a local synchronization status record including the local available sequence range, the local confirmed archive position and the cache release pointer is generated.

[0008] S200: After communication is restored, the local synchronization status record is sent; the cloud server compares the received status record and the archived status record, determines the range of data to be retransmitted and the range of received data to be archived within the local available sequence range, and generates a differential synchronization instruction.

[0009] S300, the edge terminal retransmits the data packet of the data range to be retransmitted according to the differential synchronization instruction; the cloud server writes the data packet with the terminal identifier, synchronization cycle identifier and data sequence number as idempotent keys, merges it with the received data range to be archived, and generates an archive candidate range starting from the next data sequence number of the locally confirmed archive position.

[0010] S400: The cloud server writes the archive candidate range to the target storage and executes the archive submission, updates the archive status record, and generates an archive confirmation record including the continuous archive range and the archive status version; When the archive confirmation record matches the synchronization cycle identifier and the continuous archive range is continuous with the cache release pointer, the edge terminal releases the local cache and advances the cache release pointer.

[0011] Furthermore, the edge terminal monitors the communication status, which includes normal status, network fluctuation status, network interruption status, and synchronization recovery status.

[0012] The network fluctuation state is determined when the continuous request timeout reaches the first condition; the network interruption state is determined when the continuous request timeout reaches the second condition; and the synchronization recovery state is determined when the continuous receipt of valid responses reaches the recovery condition.

[0013] Furthermore, the data packet includes a terminal identifier, a data stream identifier, a synchronization period identifier, a data sequence number, a collection timestamp, a data payload, and an integrity check value;

[0014] The cache index record includes the data sequence number, cache location, and cache status;

[0015] The persistent cache retains business data records whose archived status is not submitted, and does not overwrite the business data records with newly added business data records.

[0016] Furthermore, the receiving status record includes not received, received but pending verification, and verified but pending archiving;

[0017] The archiving status record includes unsubmitted, submitting, submitted, and submitted failed; the cloud server includes data sequences with a received status of unreceived into the range of data to be retransmitted, data sequences with a received status of verified and awaiting archiving and an archiving status of unsubmitted or submitted failed into the range of received and awaiting archiving data, and data sequences with an archiving status of submitted and continuous data sequences starting from the next data sequence number of the locally confirmed archiving position are determined as the continuous range of archived data.

[0018] Furthermore, the differential synchronization instruction includes a synchronization session identifier, a synchronization period identifier, an instruction version, the range of data to be retransmitted, the range of received data to be archived, the range of archived data, and the instruction validity status.

[0019] The edge terminal matches the synchronization cycle identifier with the local synchronization status record, compares the instruction version with the processed instruction version, and generates an expired instruction rejection record for differential synchronization instructions that do not match the synchronization cycle, have an instruction version lower than the processed instruction version, or have an invalid instruction validity status.

[0020] Furthermore, the cloud server queries existing receiving status records based on the idempotent key;

[0021] When the idempotent key matches and the integrity check value is consistent, the existing reception status record is retained.

[0022] When the idempotent keys match but the integrity check values ​​are inconsistent, a data conflict record is generated, and the corresponding data sequence is excluded from the archive candidate range.

[0023] When the idempotent key does not match, the data packet is written to a temporary storage location, and the receiving status record is updated to "verified and awaiting archiving".

[0024] Furthermore, the archiving candidate range consists of consecutive data packets starting from the next data sequence number of the locally confirmed archiving location, which have passed integrity verification, have not generated data conflict records, and whose reception status is verified and awaiting archiving.

[0025] The cloud server writes the candidate archiving range into the target storage. When the archiving submission is completed, the corresponding archiving status is updated to "submitted". When the archiving submission fails, the corresponding archiving status is updated to "submission failed" and an archiving failure record is generated. Data sequences with an archiving status of "submission failed" do not enter the continuous archiving range.

[0026] Furthermore, the archiving confirmation record also includes terminal identifier, data stream identifier, synchronization cycle identifier, continuous archiving termination sequence number, and archiving confirmation status;

[0027] The edge terminal compares the archived state version with the locally stored archived state version, and releases the local cache corresponding to the continuous archived range when the continuous archived range starts from the next data sequence number corresponding to the cache release pointer;

[0028] When the continuous archiving range is not contiguous with the cache release pointer, the corresponding local cache is retained and the cache release pointer is not advanced.

[0029] Furthermore, after the archiving confirmation wait timeout, the edge terminal generates an archiving status query record, which includes a synchronization cycle identifier and a local release range.

[0030] The cloud server reads the archive status record, returns the current continuous archive range when the corresponding data sequence has been submitted, executes archive submission when the corresponding data sequence has been verified and is waiting to be archived, and regenerates the data range that needs to be supplemented when the corresponding data sequence has not been received.

[0031] Furthermore, if the transmission is interrupted again during the retransmission process, the edge terminal saves the retransmission batch record, synchronization session identifier, and instruction version;

[0032] After communication is restored or the edge terminal restarts, the local synchronization status record and cache index record are read, the synchronization cycle identifier, the local available sequence range, the local confirmed archive position and the cache release pointer are restored, and a synchronization request record is sent based on the restored local synchronization status record.

[0033] The key innovations of this invention include:

[0034] (1) The cloud server compares the receiving status record and the archiving status record within the local available sequence range, divides the data sequence into the range of data to be retransmitted, the range of received data to be archived, and the range of archived continuous data, and associates the data retransmission processing of the edge terminal with the subsequent archiving processing of the cloud server through differential synchronization instructions.

[0035] (2) The cloud server writes the retransmission data packet with the terminal identifier, synchronization cycle identifier and data sequence number as idempotent keys, merges the written data packet with the range of received data to be archived, and forms the archiving candidate range from the next data sequence number of the locally confirmed archiving position according to the integrity verification status, data conflict record and sequence continuity.

[0036] (3) After the cloud server writes the candidate range of archives to the target storage and completes the archive submission, it generates an archive confirmation record including the continuous archive range and the archive status version; the edge terminal releases the corresponding local cache and advances the cache release pointer according to the synchronization cycle identifier, the archive status version and the continuous relationship between the continuous archive range and the cache release pointer.

[0037] The following are its main beneficial effects:

[0038] (1) To address the problem that existing breakpoint resume transmission schemes cannot distinguish between unreceived data and received but unarchived data, by jointly comparing the receiving status record and the archiving status record, unreceived data is allowed to enter the edge retransmission path, and received but unarchived data is allowed to continue to enter the cloud archiving path, thus avoiding data that has been temporarily stored in the cloud being repeatedly included in the retransmission scope.

[0039] (2) To address the issues of duplicate data transmission, data conflicts in the same sequence, and missing preceding data causing discontinuous archiving boundaries, idempotent key matching, merging of transmitted data with received data to be archived, and continuous sequence filtering are used to ensure that duplicate data with consistent content is not written repeatedly, that data sequences with missing or conflicting data do not enter the archiving candidate range, and to form an archiving processing range that is continuous with the locally confirmed archiving location.

[0040] (3) To address the issues of inconsistency between normal reception confirmation and the actual archiving status of the target storage, as well as the problem of local cache release across sequences caused by non-continuous confirmation, the continuous archiving confirmation after the target storage archive submission is matched with the cache release pointer, so that data that has not yet completed the archiving submission continues to be retained in the local cache, and expired archiving confirmation or non-continuous archiving range does not change the current cache release position. Attached Figure Description

[0041] Figure 1 A flowchart illustrating a breakpoint resume method based on edge caching and cloud bidirectional confirmation provided in an embodiment of this application;

[0042] Figure 2 This is a structural block diagram of a breakpoint resume method based on edge caching and cloud bidirectional confirmation provided in an embodiment of this application. Detailed Implementation

[0043] Example 1: Refer to Figure 1 This is a flowchart illustrating a breakpoint resumption method based on edge caching and cloud bidirectional confirmation provided by an embodiment of the present invention. The process may include at least steps S100-S400:

[0044] S100. When communication is interrupted, the synchronization cycle identifier is determined according to the terminal identifier, the data sequence number is assigned to the business data record and written to the persistent cache, and a local synchronization status record including the local available sequence range, the local confirmed archive position and the cache release pointer is generated.

[0045] S200: After communication is restored, the local synchronization status record is sent; the cloud server compares the received status record and the archived status record, determines the range of data to be retransmitted and the range of received data to be archived within the local available sequence range, and generates a differential synchronization instruction.

[0046] S300, the edge terminal retransmits the data packet of the data range to be retransmitted according to the differential synchronization instruction; the cloud server writes the data packet with the terminal identifier, synchronization cycle identifier and data sequence number as idempotent keys, merges it with the received data range to be archived, and generates an archive candidate range starting from the next data sequence number of the locally confirmed archive position.

[0047] S400: The cloud server writes the archive candidate range to the target storage and executes the archive submission, updates the archive status record, and generates an archive confirmation record including the continuous archive range and the archive status version; When the archive confirmation record matches the synchronization cycle identifier and the continuous archive range is continuous with the cache release pointer, the edge terminal releases the local cache and advances the cache release pointer.

[0048] S100. When communication is interrupted, the synchronization cycle identifier is determined according to the terminal identifier, the data sequence number is assigned to the business data record and written to the persistent cache, and a local synchronization status record is generated, including the local available sequence range, the local confirmed archive position and the cache release pointer.

[0049] This step is executed by an edge terminal, which includes a network status management module, a local storage unit, and a cache index management module. The network status management module receives request sending status, response receiving status, and response time information output by the communication interface to form a communication status. The local storage unit receives business data records generated by the business application and saves the business data records in a persistent cache. The cache index management module maintains the correspondence between the data sequence number, cache location, and cache status of the business data records. The business data records are data records formed by the edge terminal during business operation and awaiting writing to the target storage of the cloud server. In one embodiment, the business data records are one of the following: sales order records, inventory records, receiving records, or return records. Different types of business data records are distinguished by data stream identifiers.

[0050] The communication states include normal state, network fluctuation state, network interruption state, and synchronization recovery state. The edge terminal sends communication requests to the cloud server according to a preset period, and records the sending time, response status, and response time of each communication request. When consecutive request timeouts reach a first condition, the network state management module updates the communication state from normal state to network fluctuation state; when consecutive request timeouts reach a second condition, the communication state is updated to network interruption state; when valid responses are received consecutively in the network interruption state, reaching the recovery condition, the communication state is updated to synchronization recovery state. In one embodiment, the communication request sending period is 5 seconds, the first condition is 3 consecutive communication request timeouts, the second condition is 6 consecutive communication request timeouts, and the recovery condition is 3 consecutive valid responses received from the cloud server. These values ​​are a configuration method, and the actual configuration record is stored in the edge terminal's communication state configuration.

[0051] When the communication status changes from normal or network fluctuation to network interruption, the network status management module generates a cache trigger status. The cache trigger status includes the trigger time, terminal identifier, data stream identifier, and the communication status before triggering. The edge terminal queries whether there is an unfinished synchronization period based on the terminal identifier and the current local synchronization status record. If no unfinished synchronization period exists, a new synchronization period identifier is determined according to the terminal identifier, cache trigger time, and local status version. If an unfinished synchronization period exists, the existing synchronization period identifier is used, and the current data sequence number is read from the local synchronization status record. In this embodiment, the synchronization period identifier distinguishes data sequences between different cache periods or before and after a terminal restart. Under the same terminal identifier and the same data stream identifier, different synchronization period identifiers correspond to independent data sequences.

[0052] For each business data record generated by a business application, the cache index management module assigns a data sequence number to that record within the corresponding synchronization period. The data sequence number increments according to the order in which the business data records enter the persistent cache. When an edge terminal simultaneously receives business data records generated by multiple business threads, the cache index management module first determines the write order based on the order in which write requests arrive at the local storage unit, and then assigns data sequence numbers according to this write order. The data sequence number and the collection timestamp are recorded separately; the collection timestamp indicates the time when the business data record was generated, and the data sequence number indicates the write order of the business data record within the current synchronization period. The edge terminal does not use the collection timestamp to replace the data sequence number.

[0053] The edge terminal encapsulates business data records into data packets, which include a terminal identifier, a data stream identifier, a synchronization period identifier, a data sequence number, a collection timestamp, a data payload, and an integrity check value. The data payload is the content of the business data record encoded according to a preset field order; the integrity check value is calculated by the edge terminal using the terminal identifier, data stream identifier, synchronization period identifier, data sequence number, and data payload. In one implementation, the integrity check value is calculated using a 32-bit cyclic redundancy check algorithm; in another implementation, it is calculated using a hash algorithm. The integrity check value and the data packet are written together to a persistent cache, and subsequently recalculated and compared by the cloud server.

[0054] The persistent cache is located in a non-volatile storage medium on the edge terminal; the non-volatile storage medium can be Flash, an embedded multimedia card, or a local database. The cache index management module establishes a cache index record after a data packet is successfully written. This cache index record includes the data sequence number, cache location, and cache status. The cache location represents the address of the data packet in the persistent cache or the primary key of the record. The cache status includes pending transmission, transmitted but awaiting confirmation, received but awaiting archiving, archived but awaiting release, and released. When a data packet is formed in this step, the cache status record is pending transmission; after subsequent steps return a received status or an archive confirmation record, the cache index management module updates the cache status based on the returned content.

[0055] In one implementation, the persistent cache adopts a circular storage structure; the circular storage structure includes a write position and a cache release pointer. The write position points to the write position of the next data packet, and the cache release pointer points to the first data packet that has not yet been released; before the write position moves to the cache area corresponding to the cache release pointer, the cache index management module queries the archiving status of the corresponding business data record in the cache area. When the archiving status is not committed, it is prohibited to overwrite the business data record in the cache area with a new business data record; when the archiving status is committed and the corresponding data sequence is already included in a valid archiving confirmation record, the cache area is updated to a writable state. When the remaining space of the persistent cache reaches a preset capacity condition and there are no releasable business data records, the edge terminal generates a cache capacity warning record and keeps the unarchived business data records and their cache index records unchanged; in one implementation, the edge terminal writes subsequent business data records to a backup persistent cache.

[0056] Each time a data packet is written to the local storage unit, the local synchronization status record is updated. The local synchronization status record includes a terminal identifier, data stream identifier, synchronization period identifier, local available sequence range, locally confirmed archive location, cache release pointer, and local status version. The local available sequence range consists of data sequences in the persistent cache that have not yet been released and can be read according to the cache index record. The locally confirmed archive location indicates the maximum consecutive data sequence number that the edge terminal has released from the local cache based on the archive confirmation record. The cache release pointer indicates the cache location of the next pending business data record in the persistent cache. The local status version increments when the local synchronization status record changes.

[0057] When a business data record has missing fields, the edge terminal retains the original data payload and records the field missing status in the data packet; the field missing status does not change the allocation order of the data sequence number. When writing a data packet to the persistent cache fails, the local storage unit does not update the local available sequence range and generates a cache write failure record; when writing a cache index record fails but the data packet has already been written, the local storage unit re-establishes the cache index record based on the synchronization period identifier and data sequence number in the data packet. After the edge terminal restarts, it reads the persistently saved local synchronization status record and cache index record; when the synchronization period identifiers in the two are consistent, it restores the local available sequence range, the locally confirmed archive position, and the cache release pointer; when the synchronization period identifiers in the two are inconsistent, it retains the original business data record and regenerates the local synchronization status record based on the cache index record.

[0058] In one implementation, the terminal identifier of the store's handheld terminal is T01, and the data stream identifier corresponding to the sales order is SALE. When the network is interrupted, the handheld terminal generates 10 sales order records, with the current synchronization period identifier being P20260715001. The cache index management module assigns data sequence numbers 101 to 110 to the 10 sales order records sequentially. Each sales order record is encapsulated as a data packet containing the terminal identifier T01, the data stream identifier SALE, the synchronization period identifier P20260715001, the corresponding data sequence number, the collection timestamp, the sales order data payload, and an integrity check value. After the data packet is written to the persistent cache, the locally available sequence range is updated to 101 to 110. Since data before data sequence number 100 has been released according to the previous archive confirmation record, the locally confirmed archive position record is 100, and the cache release pointer points to the cache position corresponding to data sequence number 101.

[0059] This step ultimately generates an edge cache record, a cache index record, and a local synchronization status record. Among them, the terminal identifier, data stream identifier, synchronization cycle identifier, local available sequence range, and local confirmed archive location in the local synchronization status record are called by S200 after communication is restored. The data sequence number and cache location in the cache index record are called by S300. The cache release pointer participates in the local cache release process after S400 receives the archive confirmation record.

[0060] S200. After communication is restored, the local synchronization status record is sent; the cloud server compares the received status record and the archived status record, determines the range of data to be retransmitted and the range of received data to be archived within the local available sequence range, and generates a differential synchronization instruction.

[0061] This step receives the local synchronization status record generated by S100 and is jointly executed by the edge terminal's synchronization request generation module and the cloud server's message receiving and processing module, receiving status management module, archiving status management module, and missing range generation module. The synchronization request generation module reads the terminal identifier, data stream identifier, synchronization cycle identifier, local available sequence range, locally confirmed archiving location, and local status version from the local synchronization status record; the cloud server reads the receiving status record and archiving status record corresponding to the terminal identifier, data stream identifier, and synchronization cycle identifier.

[0062] When the network status management module updates the communication status to synchronized recovery status, the synchronization request generation module generates a synchronization request record and sends it to the cloud server. The synchronization request record includes a terminal identifier, data stream identifier, synchronization period identifier, locally available sequence range, locally confirmed archive location, local status version, and request generation time. In one embodiment, the synchronization request record also includes the data sequence number corresponding to the cache release pointer. After sending the synchronization request record, the edge terminal does not directly upload all data packets within the locally available sequence range, but instead waits for the cloud server to return a differential synchronization instruction.

[0063] After receiving a synchronization request record, the cloud server first queries the established synchronization status according to the terminal identifier and data stream identifier; then it matches the synchronization period identifier in the synchronization request record with the synchronization period identifier stored on the cloud server. If the synchronization period identifier matches, the cloud server reads the corresponding receive status record and archive status record; if the synchronization period identifier does not exist, the cloud server creates a receive status record and archive status record for that synchronization period, and marks data sequences within the local available sequence range that have no receive records as not received; if the synchronization period identifier does not match the synchronization period currently being processed by the cloud server, the cloud server retains the original status record and returns a synchronization period mismatch status, and the edge terminal rereads the local synchronization status record accordingly.

[0064] The reception status record indicates the cloud server's reception, integrity verification, and temporary storage status of data packets, including not received, received but pending verification, and verified but pending archiving. A reception status of "not received" indicates that the cloud server has no data packet matching the corresponding data sequence number. A reception status of "received but pending verification" indicates that the data packet has arrived at the cloud server, but integrity verification has not yet been completed. A reception status of "verified but pending archiving" indicates that the data packet has passed integrity verification and is stored in the temporary storage location, but archiving and submission to the target storage have not yet been completed. The reception status record is also associated with the terminal identifier, data stream identifier, synchronization cycle identifier, data sequence number, integrity verification value, and reception status version.

[0065] The archive status record indicates the status of business data records being written to the target storage and the archive commit, including uncommitted, committing, committed, and commit failed. An uncommitted archive status indicates that the corresponding business data record has not yet started being written to the target storage; a committing archive status indicates that the target storage write operation has started but has not yet returned a commit result; a committed archive status indicates that the business data record has been written to the target storage and the archive commit has been completed; a commit failed archive status indicates that the target storage returned a write failure, transaction rollback, or commit interruption. The archive status record is associated with the terminal identifier, data stream identifier, synchronization cycle identifier, data sequence number, archive status version, and archive result time.

[0066] The cloud server uses the next data sequence number of the locally confirmed archived location as the starting position for this comparison and the ending data sequence number of the locally available sequence range as the ending position for the comparison, querying the data sequences within the range one by one. Data sequences in the received state that have not been received are included in the data range that needs to be retransmitted; data sequences in the received state that have been received but are awaiting verification are first subjected to integrity verification by the data verification module, and are not included in the archived continuous range until the verification is completed; data sequences in the received state that have been verified but are awaiting archiving, and whose archiving state is unsubmitted or failed to be submitted, are included in the received data awaiting archiving range; data sequences in the archived state that have been submitted are checked for continuity according to the data sequence number order.

[0067] The archived contiguous range begins with the next data sequence number after the locally confirmed archived location. When a subsequent data sequence number is consecutive to the preceding data sequence number and both have a submitted archive status, the archived contiguous range extends forward. Extension stops when encountering a data sequence with a received status of "not received," an archive status other than "submitted," or a data conflict record. Even if a subsequent sequence is already in a submitted state, it is not merged into the current archived contiguous range; instead, its archive status record is retained and recalculated after the preceding data has been archived.

[0068] The missing range generation module encapsulates the range of data to be retransmitted, the range of received data to be archived, and the range of archived contiguous data into a differential synchronization instruction. The differential synchronization instruction includes a synchronization session identifier, a synchronization cycle identifier, an instruction version, the range of data to be retransmitted, the range of received data to be archived, the range of archived contiguous data, and the instruction validity status. The synchronization session identifier is associated with a synchronization request and its subsequent retransmission batches. The instruction version increments each time a differential synchronization instruction is regenerated within the same synchronization session. The instruction validity status includes valid and invalid. The range of data to be retransmitted is represented using a list of data sequence numbers or a continuous data sequence range; the range of received data to be archived and the range of archived contiguous data use the same representation.

[0069] When the cloud server generates a new differential synchronization command, it updates the previous command in the same synchronization session to invalid. After receiving the differential synchronization command, the edge terminal matches the synchronization period identifier in it with the local synchronization status record and compares the command version with the locally processed command version. If the synchronization period does not match, the command version is lower than the processed command version, or the command validity status is invalid, the edge terminal does not extract data packets according to the differential synchronization command and generates an expired command rejection record. The expired command rejection record includes the synchronization session identifier, command version, rejection time, and rejection status. If the command version is higher than the locally processed command version and the synchronization period matches, the edge terminal saves the command version and hands the differential synchronization command over to S300 for execution.

[0070] When a synchronization request record arrives repeatedly at the cloud server, the cloud server compares it according to the terminal identifier, synchronization cycle identifier, and local status version. If the local status version of the repeated synchronization request record has not changed, the cloud server returns the currently valid differential synchronization instruction. If the local status version increases, the cloud server rereads the received status record and the archived status record and generates a new differential synchronization instruction. When the cloud server fails to read a status record, it does not directly mark the corresponding data sequence as not received, but generates a synchronization status read failure record and keeps the previous valid differential synchronization instruction unchanged.

[0071] In one implementation, the locally available sequence range formed in S100 is 101 to 110, and the locally confirmed archiving location is 100. The status record of the cloud server indicates that the archiving status of data sequences 101 to 103 is submitted, the reception status of data sequences 104, 105, 107, 108, and 109 is verified and awaiting archiving, and the reception status of data sequences 106 and 110 is not received. The missing range generation module classifies 106 and 110 into the range of data that needs to be retransmitted, classifies 104, 105, 107, 108, and 109 into the range of received data awaiting archiving, and determines 101 to 103 as the continuous range of archived data. The generated differential synchronization instruction includes the above range, the synchronization session identifier C01, and the instruction version V1.

[0072] This step ultimately generates a differential synchronization instruction and updates the synchronization session record in the cloud server. The range of data to be retransmitted in the differential synchronization instruction is invoked by the edge terminal of the S300, and the range of received data to be archived is invoked by the cloud server of the S300. The synchronization session identifier, synchronization cycle identifier, and instruction version continue to be carried during the data packet retransmission process of the S300. The archived continuous range is stored in the cloud server and used as the status basis when the continuous archive range is recalculated in the future.

[0073] S300, the edge terminal retransmits the data packet of the data range to be retransmitted according to the differential synchronization instruction; the cloud server writes the data packet with the terminal identifier, synchronization cycle identifier and data sequence number as idempotent keys, merges it with the received data range to be archived, and generates an archive candidate range starting from the next data sequence number of the locally confirmed archive position.

[0074] This step receives the differential synchronization command generated by S200 and calls the cached index record and local synchronization status record formed by S100; the data extraction module of the edge terminal is responsible for verifying the differential synchronization command, extracting data packets, and forming a retransmission batch record; the data verification module, receiving status management module, and idempotent writing module of the cloud server are responsible for data packet verification, duplicate data identification, temporary storage writing, and receiving status update; the archiving processing module forms an archiving candidate range based on the updated receiving status record and the range of received data to be archived.

[0075] After receiving the differential synchronization command, the edge terminal first compares the synchronization period identifier in the differential synchronization command with the synchronization period identifier in the local synchronization status record; then it compares the command version in the differential synchronization command with the locally stored processed command version. If the synchronization period matches, the command version is not lower than the processed command version, and the command validity status is valid, the data extraction module reads the range of data to be retransmitted. For each data sequence number in the range of data to be retransmitted, the data extraction module queries the cache index record to obtain the corresponding cache location and cache status; if the cache status is pending transmission or sent pending confirmation, the corresponding data packet is read from the persistent cache area; if the cache status is released or the cache location does not exist, a data extraction failure record is generated, and the data sequence number is written to the local non-retransmission record.

[0076] The data extraction module recalculates the integrity check value of the read data packet and compares it with the integrity check value stored in the data packet. If they match, the data packet is added to the retransmission batch; if they do not match, a local data verification failure record is generated, and the data packet is not added to the current retransmission batch. The retransmission batch record includes the synchronization session identifier, instruction version, synchronization cycle identifier, batch identifier, data sequence range within the batch, and transmission status. In one implementation, the range of data to be retransmitted is divided into multiple consecutive intervals, and each consecutive interval forms a retransmission batch; in another implementation, multiple data packets are encapsulated into a retransmission batch according to the length of a single communication message.

[0077] When an edge terminal sends a retransmission batch, it carries the terminal identifier, data stream identifier, synchronization cycle identifier, data sequence number, acquisition timestamp, data payload, and integrity check value in each data packet, and the synchronization session identifier, instruction version, and batch identifier in the batch message. After the retransmission batch is sent, the cache status of the corresponding cache index record is updated to "sent but awaiting confirmation." If communication is interrupted again during transmission, the edge terminal saves the retransmission batch record, synchronization session identifier, and instruction version, and keeps data packets that have not received a response from the cloud server in the "sent but awaiting confirmation" state. After communication is restored, the edge terminal reads the local synchronization status record and cache index record, retransmits the synchronization request record, and does not directly assume that the entire retransmission batch was not received.

[0078] After receiving the retransmitted data packet, the cloud server performs integrity verification based on the integrity check value carried in the data packet. The data verification module recalculates the integrity check value for the terminal identifier, data stream identifier, synchronization cycle identifier, data sequence number, and data payload in the same field order as the edge terminal. If the recalculated result matches the integrity check value in the data packet, the data packet is handed over to the idempotent writing module. If the two do not match, the corresponding reception status is updated to "not received" or "received but pending verification," a data verification failure record is generated, and the data sequence is included in the range of data to be retransmitted in the next differential synchronization instruction.

[0079] The idempotent write module uses the terminal identifier, synchronization period identifier, and data sequence number as idempotent keys to query existing reception status records. In one embodiment, the idempotent key is also associated with a data stream identifier to distinguish different data streams generated by the same terminal within the same synchronization period. When the idempotent key matches an existing reception status record and the integrity check value is consistent, the idempotent write module does not write data packets repeatedly, retains the existing reception status record, and marks the data sequence as received. When the idempotent key matches but the integrity check value is inconsistent, a data conflict record is generated. The data conflict record includes the idempotent key, the original integrity check value, the new integrity check value, the original reception time, and the new reception time. Data sequences with data conflict records are not included in the archiving candidate range.

[0080] When the idempotent key does not match an existing receive status record, the cloud server writes the data packet to a temporary storage location. This temporary storage location is where data packets are saved before the business data record is archived and submitted. In one implementation, it is a temporary storage table in the cloud database; in another, it is a persistent message storage partitioned by terminal identifier and synchronization cycle identifier. After the data packet is written to the temporary storage location, the receive status management module updates the corresponding receive status to "verified and awaiting archiving" and records the integrity check value, temporary storage location, receive time, and receive status version. If writing to the temporary storage location fails, the receive status remains "received and awaiting verification," and a temporary storage write failure record is generated.

[0081] After the cloud server completes the update of the reception status of the retransmitted data, it merges the updated reception status record with the range of received data awaiting archiving formed by S200. This merging does not modify the data sequence number, but rather unifies two types of data sequences as the data source for forming the candidate archiving range: one type is the data sequence whose reception status has been updated to "verified and awaiting archiving" after this retransmission, and the other type is the data sequence that was already in the "verified and awaiting archiving" state before the differential synchronization instruction was generated. Starting from the next data sequence number after the locally confirmed archiving position, the archiving processing module queries the reception status, integrity verification status, and data conflict records of each data sequence in ascending order of data sequence number.

[0082] When the current data sequence is in the received state of verified and awaiting archiving, has passed integrity verification, and has no data conflict records, the data sequence is added to the archiving candidate range, and the search continues for the next data sequence. When the current data sequence is in the received state of not received, received and awaiting verification, or has data conflict records, the extension of the current archiving candidate range stops. Data following the interrupted data sequence, even if it is already in the verified and awaiting archiving state, is not included in the current archiving candidate range, but continues to be stored in a temporary location, waiting for the preceding data to meet the sequence continuity condition before participating in the next archiving candidate range calculation.

[0083] In one implementation, the locally confirmed archiving location is 100; the range of received data to be archived in the differential synchronization command is 104, 105, 107 to 109, and the range of data to be supplemented is 106 and 110; after the edge terminal supplements 106 and 110, the cloud server completes integrity verification and idempotent writing for both. Since 101 to 103 are already in the committed state, and 104 to 110 are all in the verified pending archiving state and there are no data conflict records, the archiving processing module starts the status verification from 101 and forms the unarchived 104 to 110 into the archiving candidate range. If the integrity verification at 106 fails, the archiving candidate range only extends to 105, and 107 to 110 are retained in the temporary storage location.

[0084] When the same retransmission batch arrives repeatedly, the cloud server retains the existing reception status record based on the idempotency key and integrity check value, and does not write it repeatedly to the temporary storage location. When the edge terminal restarts and resends the synchronization request record, the cloud server, based on the updated reception status record, will no longer include the already received data sequence in the range of data to be retransmitted. This processing result is stored in the reception status record and the retransmission batch record, and enters the subsequent synchronization rounds.

[0085] This step ultimately generates an updated receive status record, retransmission batch record, data conflict record, and archive candidate range; the data sequence, temporary storage location, and integrity verification status in the archive candidate range are invoked by S400; the data conflict record and temporary storage write failure record serve as inputs for S400 to determine the archive submission conditions; the retransmission batch record, synchronization session identifier, and instruction version are invoked by subsequent synchronization requests if the retransmission process is interrupted again or the edge terminal restarts.

[0086] S400: The cloud server writes the archive candidate range to the target storage and executes the archive submission, updates the archive status record, and generates an archive confirmation record including the continuous archive range and the archive status version; When the archive confirmation record matches the synchronization cycle identifier and the continuous archive range is continuous with the cache release pointer, the edge terminal releases the local cache and advances the cache release pointer.

[0087] This step receives the archive candidate range, updated receive status record, and data conflict record formed by S300, and reads the current archive status record; the cloud server's archive processing module is responsible for writing the business data record corresponding to the archive candidate range into the target storage, the archive status management module is responsible for recording the archive submission result, and the archive confirmation generation module is responsible for generating the archive confirmation record; the edge terminal's archive confirmation processing module and cache release control module are responsible for verifying the archive confirmation record, releasing the local cache, and updating the local synchronization status record.

[0088] The target storage is a database or persistent data storage in a cloud server that stores business data records. The target storage and temporary storage location each record the data status. Writing a data packet to the temporary storage location does not indicate that the corresponding business data record has been archived and submitted. The archiving processing module reads the data payload from the temporary storage location based on the data sequence number in the archiving candidate range, and re-verifies the terminal identifier, data stream identifier, synchronization cycle identifier, data sequence number, and integrity verification status. When the data sequence in the archiving candidate range is continuous, the integrity verification passes, and there are no data conflict records, the corresponding archiving status is updated from unsubmitted or failed to submit to submitting.

[0089] In one implementation, the archiving module writes business data records in batches to the target database according to the data sequence order of the archiving candidate range, and performs archiving commit within a single database transaction. In another implementation, the archiving module writes business data records one by one, updates the archiving status record after each write is completed, and then forms a continuous archiving range based on the consecutively committed data sequence. When using batch archiving, if any business data record in the batch write returns a write failure, the archiving module rolls back the current batch write and updates the corresponding archiving status to commit failure. When using record-by-record archiving, the data sequence that failed to write and the subsequent data sequence are not included in the current continuous archiving range.

[0090] When the target storage returns an archive commit complete status, the archive status management module updates the archive status of the corresponding data sequence in the archive candidate range to "committed" and increments the archive status version. When the target storage returns a write failure, transaction rollback, or commit interruption status, the corresponding archive status is updated to "commit failed," and an archive failure record is generated. The archive failure record includes the terminal identifier, data stream identifier, synchronization cycle identifier, data sequence range, failure time, and target storage return status. Data sequences with an archive failure status do not enter the continuous archive range, but the corresponding data packets in the temporary storage location are retained.

[0091] The archiving status management module queries the archiving status starting from the next data sequence number of the currently archived consecutive position, in ascending order of data sequence numbers. When the archiving status is continuously "committed," the corresponding data sequence is added to the continuous archiving range. When a data sequence with an archiving status of "uncommitted," "committing," or "committed but failed" is encountered, the extension of the continuous archiving range is stopped. The starting data sequence number of the continuous archiving range corresponds to the next data sequence number of the locally confirmed archiving position on the edge terminal; the ending data sequence number of the continuous archiving range represents the maximum data sequence number that the edge terminal is allowed to continuously release from its local cache in this instance.

[0092] The archive confirmation generation module encapsulates the terminal identifier, data stream identifier, synchronization cycle identifier, synchronization session identifier, continuous archive range, continuous archive termination sequence number, archive status version, and archive confirmation status into an archive confirmation record. The archive confirmation status includes valid and invalid. When the corresponding archive status record changes due to status correction after the archive confirmation record is generated, the cloud server generates a new archive status version and updates the old archive confirmation record to invalid. If there is no continuously added sequence of committed data, the cloud server does not generate a new archive confirmation record to advance the cache release pointer.

[0093] After receiving the archiving confirmation record, the edge terminal matches the terminal identifier and data stream identifier with the local synchronization status record, then matches the synchronization period identifier with the current synchronization period identifier, and compares the archived status version with the locally stored archived status version. If the terminal identifier, data stream identifier, or synchronization period identifier does not match, an expired confirmation rejection record is generated; if the archived status version is lower than the locally processed archived status version, the cache status is not changed based on the archiving confirmation record; if the archived status version is not lower than the locally processed archived status version and the archiving confirmation status is valid, the cache release control module continues to check the continuous archiving range.

[0094] The cache release control module reads the data sequence number corresponding to the cache release pointer and compares the starting data sequence number of the continuous archiving range with the next data sequence number corresponding to the cache release pointer. If the two are consecutive, the cache status of the cache index record corresponding to the continuous archiving range is updated to archived and awaiting release. Then, the corresponding local cache is released in the order of the data sequence numbers, and the cache status is updated to released. After the release is completed, the cache release pointer advances to the next cache position after the continuous archiving termination sequence number, the locally confirmed archiving position is updated to the continuous archiving termination sequence number, and the local status version is incremented.

[0095] When the continuous archiving range and the cache release pointer are not continuous, the edge terminal retains the local cache corresponding to the continuous archiving range and does not advance the cache release pointer. In one implementation, the corresponding cache index record is marked as archived and awaiting release. After the preceding data obtains archiving confirmation, the cache release control module re-checks the continuous archived and awaiting-release records starting from the current cache release pointer. Thus, when the subsequent data has been archived but the preceding data has not been archived, the edge terminal still maintains the local caches of both the preceding and subsequent data, and does not directly release the subsequent cache across the preceding data.

[0096] After the archiving confirmation wait times out, the edge terminal generates an archiving status query record. This record includes the terminal identifier, data stream identifier, synchronization cycle identifier, local range to be released, and locally stored archiving status version. Upon receiving the archiving status query record, the cloud server reads the corresponding archiving status record. If the corresponding data sequence has been submitted, it returns the current continuous archiving range and archiving status version. If the reception status of the corresponding data sequence is "verified and awaiting archiving," it re-invokes the archiving processing module to execute the archiving submission. If the reception status of the corresponding data sequence is "not received," it regenerates the range of data to be supplemented and returns it to the edge terminal via a differential synchronization command. The edge terminal continues to retain its local cache during the archiving status query period.

[0097] When the persistent cache reaches its capacity, the cache release control module prioritizes querying cache records that have received valid archiving confirmation and are consecutive to the cache release pointer. If such cache records exist, they are released in order of data sequence number. If no such cache records exist, unarchived data is prevented from being overwritten by newly added business data records, and a cache capacity warning record is generated. Business data records whose archiving status is "committed" but whose archiving confirmation record has not yet arrived remain in the persistent cache until the edge terminal obtains a valid archiving confirmation record or the archiving status query result.

[0098] In one implementation, the edge terminal's cache release pointer corresponds to data sequence 101. The cloud server has completed the archiving submission of data from 101 to 110 and generated an archiving confirmation record for the continuous archiving range of 101 to 110 and archiving status version V5. The edge terminal verifies that the synchronization cycle identifier matches, and the archiving status version V5 is higher than the locally stored V4. The starting data sequence 101 of the continuous archiving range is consistent with the data sequence corresponding to the cache release pointer. The edge terminal releases the local cache corresponding to 101 to 110 sequentially and updates the locally confirmed archiving position to 110. In another implementation, the cloud server only confirms that data from 103 to 110 has been archived, while data from 101 to 102 has not yet been archived. The edge terminal records the archiving status of data from 103 to 110 but does not advance the cache release pointer. It releases the cache corresponding to data from 101 to 110 sequentially after data from 101 to 102 has been archived.

[0099] If the data transmission is interrupted again during the retransmission process or the edge terminal restarts, the edge terminal restores the synchronization cycle identifier, the range of locally available sequences, the locally confirmed archive location, the cache release pointer, and the local status version from the persistently stored local synchronization status record; it also restores the synchronization session identifier and instruction version from the retransmission batch record; and resends the synchronization request record after restoration. The cloud server regenerates the differential synchronization instruction based on the received status record and the archived status record; data sequences that have been archived and submitted enter the archived continuous range, data sequences that have been received but not archived enter the received data to be archived range, and data sequences that have not been received enter the data to be retransmitted range.

[0100] After this step is completed, the edge terminal updates its local synchronization status record and cache index record; the cloud server retains the receive status record, archive status record, archive confirmation record, archive failure record, and archive status query record. The locally confirmed archive location and cache release pointer serve as inputs for the next S100 write to the persistent cache and the next S200 generation of synchronization request records; business data records not covered by the archive confirmation record continue to be stored in the persistent cache and will re-enter S200 in subsequent synchronization recovery states.

[0101] Example 2: Figure 2This diagram illustrates a structural block diagram of a breakpoint resumption method based on edge caching and cloud-based bidirectional confirmation according to an embodiment of the present invention. Figure 2 As shown, the structure may include:

[0102] The network status and cache module 01 is used to determine the synchronization cycle identifier according to the terminal identifier when communication is interrupted, allocate data sequence numbers to service data records and write them into the persistent cache, and generate a local synchronization status record including the locally available sequence range, the locally confirmed archived position, and the cache release pointer. Specifically, the network status and cache module receives service data records, terminal identifiers, and communication statuses generated by edge terminals. When the communication status changes from normal communication to communication interruption, it reads the local synchronization status record corresponding to the terminal identifier. If there is no synchronization cycle identifier that has not yet ended, a new synchronization cycle identifier is formed according to the terminal identifier and the communication interruption time. If there is a synchronization cycle identifier that has not yet ended, the existing synchronization cycle identifier is used. The network status and cache module allocates data sequence numbers according to the order in which service data records enter the persistent cache, and associates the terminal identifier, the synchronization cycle identifier, the data sequence number, and the service data record into the persistent cache. After writing, it updates the locally available sequence range according to the correspondence between the data sequence number and the cache position. The locally confirmed archive location record records the maximum consecutive data sequence number for which local cache release has been completed based on the archive confirmation record; the cache release pointer points to the cache location of the next business data record to be released in the persistent cache. When a business data record write fails, the network status and cache module retains the local available sequence range and cache release pointer before the write, and does not record the corresponding data sequence number in the local available sequence range; when the local synchronization status record write fails, the local synchronization status record is reconstructed based on the existing synchronization cycle identifier and data sequence number in the persistent cache. The network status and cache module provides the local synchronization status record to the synchronization request generation module and retains the cache location of the business data record in the persistent cache for the data retransmission and reception status management module to call according to the data sequence number.

[0103] The synchronization request generation module 02, connected to the network status and caching module, is used to send the local synchronization status record after communication is restored. Specifically, the synchronization request generation module receives the local synchronization status record output by the network status and caching module and reads the communication status of the edge terminal. When the communication status changes from communication interruption to communication restoration, the module extracts the terminal identifier, synchronization cycle identifier, local available sequence range, local confirmed archive position, and cache release pointer from the local synchronization status record. The synchronization request generation module maintains the correspondence between the terminal identifier and the synchronization cycle identifier, sends the local synchronization status record to the cloud server, and records the local available sequence range corresponding to the sending time. If communication is interrupted again during the sending process, the synchronization request generation module retains the local synchronization status record without changing the local confirmed archive position and the cache release pointer. After communication is restored, the module reads the current local synchronization status record and resends it. After the local synchronization status record is sent, the differential range generation module calls the terminal identifier, synchronization period identifier, local available sequence range, and local confirmed archive position. The synchronization request generation module continues to retain the local synchronization status record at the time of sending, so as to match the synchronization period identifier when receiving differential synchronization instructions later.

[0104] The differential range generation module 03, connected to the synchronization request generation module, is used by the cloud server to compare the receive status record and the archive status record, determine the range of data to be retransmitted and the range of received data to be archived within the local available sequence range, and generate a differential synchronization instruction. Specifically, the differential range generation module receives the local synchronization status record sent by the synchronization request generation module, and reads the receive status record and the archive status record stored on the cloud server according to the terminal identifier and the synchronization cycle identifier. The receive status record indicates whether the corresponding data sequence has been received by the cloud server; the archive status record indicates whether the corresponding business data record has been written to the target storage and completed the archiving submission. The differential range generation module uses the next data sequence number of the locally confirmed archive position as the comparison start position and the end data sequence number of the local available sequence range as the comparison end position; it matches the receive status record and the archive status record one by one for multiple data sequences within the comparison range. When no matching receive status record exists, the corresponding data sequence is included in the data to be retransmitted range. When a receive status record exists but no submitted archive status record exists, the corresponding data sequence is included in the received data to be archived range. When a submitted archive status record exists, the archive status of the corresponding data sequence is retained, but it is not included in the data to be retransmitted range. When the synchronization period identifier corresponding to the receive status record and the archive status record is inconsistent, the differential synchronization instruction is not generated using this status record, and the status record is reread according to the terminal identifier and the synchronization period identifier. The differential range generation module encapsulates the data to be retransmitted range, the received data to be archived range, and the synchronization period identifier into a differential synchronization instruction, and provides the differential synchronization instruction to the data retransmission and receive status management module. The data to be retransmitted range serves as the input for the edge terminal to extract data packets, and the received data to be archived range serves as the input for the cloud server to form the archive candidate range.

[0105] The data retransmission and reception status management module 04, connected to the differential range generation module, is used for edge terminals to retransmit data packets of the data range to be retransmitted according to the differential synchronization instruction. The cloud server writes the data packets using the terminal identifier, the synchronization period identifier, and the data sequence number as idempotent keys. The written data packets are then merged with the received data range to be archived, generating an archiving candidate range starting from the next data sequence number of the locally confirmed archiving position. Specifically, the data retransmission and reception status management module receives the differential synchronization instruction output by the differential range generation module and matches the synchronization period identifier in the differential synchronization instruction with the local synchronization status record stored by the edge terminal. When the synchronization period identifier matches, the edge terminal reads the data packets in the persistent buffer according to the data sequence number in the data range to be retransmitted and sends the terminal identifier, the synchronization period identifier, and the data sequence number along with the data packets to the cloud server. When the synchronization period identifier does not match, the corresponding data packets are not read, and the synchronization request generation module retransmits the current local synchronization status record. After receiving a data packet, the cloud server uses the terminal identifier, the synchronization cycle identifier, and the data sequence number to form an idempotent key and queries an existing reception status record. If the idempotent key does not exist, the data packet is written to the cloud server and a reception status record is established. If the idempotent key already exists, an existing reception status record is retrieved, and the same data packet is not written repeatedly. When a data packet writing fails, the corresponding data sequence remains in a state requiring retransmission, and the differential range generation module re-includes it in the data range requiring retransmission in the next comparison. The data retransmission and reception status management module merges the data packet written this time with the data packet corresponding to the range of received data to be archived, and reads the data sequence number in ascending order, starting from the next data sequence number of the locally confirmed archiving position. When the data sequence is continuous and a reception status record exists, the corresponding data sequence is included in the archiving candidate range. When an unreceived data sequence appears, the extension of the archiving candidate range is stopped, and data packets following that data sequence continue to be retained in the range of received data to be archived. The data retransmission and reception status management module provides the generated archive candidate range and its corresponding data packets to the archive confirmation generation module, and provides the updated reception status record to the differential range generation module for subsequent synchronization status comparison calls.

[0106] The archive confirmation generation module 05, connected to the data retransmission and reception status management module, is used to have the cloud server write the archive candidate range into the target storage and execute archive submission, update the archive status record, and generate an archive confirmation record including a continuous archive range and an archive status version. Specifically, the archive confirmation generation module receives the archive candidate range and corresponding data packets output by the data retransmission and reception status management module, and writes the business data records into the target storage according to the data sequence number order in the archive candidate range. When the target storage returns an archive submission completion status, the archive confirmation generation module updates the archive status record of the corresponding data sequence to submitted; when the target storage returns an archive submission failure status, it updates the archive status record of the corresponding data sequence to submission failure, and does not include this data sequence and subsequent data sequences in the current continuous archive range. The archive confirmation generation module reads the updated archive status record starting from the next data sequence number of the locally confirmed archive position; when the archive status of multiple consecutive data sequences is submitted, a continuous archive range is formed; when a data sequence with an archive status other than submitted is encountered, the extension of the continuous archive range is stopped. The archive status record is updated each time the archive submission result changes. The archive confirmation generation module encapsulates the terminal identifier, the synchronization cycle identifier, the continuous archive range, and the archive status version into an archive confirmation record. If no new continuous archive range is added, the current archive status record is retained, and no new archive confirmation record is generated to advance the cache release pointer. The archive confirmation generation module provides the archive confirmation record to the cache release control module and the updated archive status record to the differential range generation module for comparison with the next received status record.

[0107] The cache release control module 06, connected to the archive confirmation generation module, is used by the edge terminal to match the archive confirmation record with the synchronization period identifier, and compare the continuity relationship between the continuous archive range and the cache release pointer. When they match and are continuous, the corresponding local cache in the persistent cache area is released and the cache release pointer is advanced. Specifically, the cache release control module receives the archive confirmation record output by the archive confirmation generation module and reads the network status and the local synchronization status record saved by the cache module. The cache release control module first matches the synchronization period identifier in the archive confirmation record with the synchronization period identifier in the local synchronization status record; when the synchronization period identifier does not match, the business data record in the persistent cache area and the current cache release pointer are retained, and the local synchronization status record is not updated according to the archive confirmation record. When the synchronization period identifier matches, the continuous archive range and archive status version in the archive confirmation record are read, and the starting data sequence number of the continuous archive range is compared with the data sequence number corresponding to the cache release pointer. When the two are consecutive, the local cache corresponding to the consecutive archiving range is released in order of data sequence number, the cache release pointer is advanced to the next cache position after the consecutive archiving range, and the locally confirmed archiving position is updated to the termination data sequence number of the consecutive archiving range; when the two are not consecutive, the local cache corresponding to the consecutive archiving range is retained, and the cache release pointer is not advanced. When the archived state version is lower than the archived state version already saved in the local synchronization state record, the local cache state is not updated using the archived confirmation record; when the archived state version is not lower than the already saved archived state version, the archived state version is written to the local synchronization state record. The cache release control module returns the updated local available sequence range, the local confirmed archiving position, and the cache release pointer to the network state and cache module; the network state and cache module writes subsequent business data records according to the updated cache release pointer, and the synchronization request generation module calls the updated local synchronization state record to send the next synchronization request when there are still unreleased business data records.

Claims

1. A method for resuming interrupted downloads based on edge caching and bidirectional confirmation from the cloud, characterized in that, include: S100. When communication is interrupted, the synchronization cycle identifier is determined according to the terminal identifier, the data sequence number is assigned to the business data record and written to the persistent cache, and a local synchronization status record including the local available sequence range, the local confirmed archive position and the cache release pointer is generated. S200. After communication is restored, the local synchronization status record is sent. The cloud server compares the received status record and the archived status record, determines the range of data to be retransmitted and the range of received data to be archived within the local available sequence range, and generates a differential synchronization instruction. S300, the edge terminal retransmits the data packet of the data range to be retransmitted according to the differential synchronization instruction; the cloud server writes the data packet with the terminal identifier, synchronization cycle identifier and data sequence number as idempotent keys, merges it with the received data range to be archived, and generates an archive candidate range starting from the next data sequence number of the locally confirmed archive position. S400: The cloud server writes the archive candidate range to the target storage and executes the archive submission, updates the archive status record, and generates an archive confirmation record including the continuous archive range and the archive status version. When the edge terminal releases the local cache and advances the cache release pointer, the archive confirmation record matches the synchronization cycle identifier and the continuous archive range is continuous with the cache release pointer.

2. The breakpoint resumption method based on edge caching and cloud bidirectional confirmation according to claim 1, characterized in that, The edge terminal monitors the communication status, which includes normal status, network fluctuation status, network interruption status, and synchronization recovery status. The network fluctuation state is determined when the continuous request timeout reaches the first condition; the network interruption state is determined when the continuous request timeout reaches the second condition; and the synchronization recovery state is determined when the continuous receipt of valid responses reaches the recovery condition.

3. The breakpoint resumption method based on edge caching and cloud bidirectional confirmation according to claim 1, characterized in that, The data packet includes a terminal identifier, a data stream identifier, a synchronization period identifier, a data sequence number, a collection timestamp, a data payload, and an integrity check value; The cache index record includes the data sequence number, cache location, and cache status; The persistent cache retains business data records whose archived status is not submitted, and does not overwrite the business data records with newly added business data records.

4. The breakpoint resumption method based on edge caching and cloud bidirectional confirmation according to claim 1, characterized in that, The reception status record includes not received, received but pending verification, and verified but pending archiving; The archiving status record includes unsubmitted, submitting, submitted, and submitted failed; the cloud server includes data sequences with a received status of unreceived into the range of data to be retransmitted, data sequences with a received status of verified and awaiting archiving and an archiving status of unsubmitted or submitted failed into the range of received and awaiting archiving data, and data sequences with an archiving status of submitted and continuous data sequences starting from the next data sequence number of the locally confirmed archiving position are determined as the continuous range of archived data.

5. The breakpoint resumption method based on edge caching and cloud bidirectional confirmation according to claim 1, characterized in that, The differential synchronization instruction includes a synchronization session identifier, a synchronization period identifier, an instruction version, the range of data to be retransmitted, the range of received data to be archived, the continuous range of archived data, and the instruction validity status. The edge terminal matches the synchronization cycle identifier with the local synchronization status record, compares the instruction version with the processed instruction version, and generates an expired instruction rejection record for differential synchronization instructions that do not match the synchronization cycle, have an instruction version lower than the processed instruction version, or have an invalid instruction validity status.

6. The breakpoint resumption method based on edge caching and cloud bidirectional confirmation according to claim 3, characterized in that, The cloud server queries existing receiving status records based on the idempotent key; When the idempotent key matches and the integrity check value is consistent, the existing reception status record is retained. When the idempotent keys match but the integrity check values ​​are inconsistent, a data conflict record is generated, and the corresponding data sequence is excluded from the archive candidate range. When the idempotent key does not match, the data packet is written to a temporary storage location, and the receiving status record is updated to "verified and awaiting archiving".

7. The breakpoint resumption method based on edge caching and cloud bidirectional confirmation according to claim 6, characterized in that, The archiving candidate range consists of consecutive data packets starting from the next data sequence number of the locally confirmed archiving location, which have passed integrity verification, have not generated data conflict records, and whose reception status is verified and awaiting archiving. The cloud server writes the candidate archiving range into the target storage. When the archiving submission is completed, the corresponding archiving status is updated to "submitted". When the archiving submission fails, the corresponding archiving status is updated to "submission failed" and an archiving failure record is generated. Data sequences with an archiving status of "submission failed" do not enter the continuous archiving range.

8. The breakpoint resumption method based on edge caching and cloud bidirectional confirmation according to claim 7, characterized in that, The archiving confirmation record also includes terminal identifier, data stream identifier, synchronization cycle identifier, continuous archiving termination sequence number, and archiving confirmation status; The edge terminal compares the archived state version with the locally stored archived state version, and releases the local cache corresponding to the continuous archived range when the continuous archived range starts from the next data sequence number corresponding to the cache release pointer; When the continuous archiving range is not contiguous with the cache release pointer, the corresponding local cache is retained and the cache release pointer is not advanced.

9. The breakpoint resumption method based on edge caching and cloud bidirectional confirmation according to claim 8, characterized in that, After the archive confirmation wait timeout, the edge terminal generates an archive status query record, which includes a synchronization cycle identifier and a local range to be released. The cloud server reads the archive status record, returns the current continuous archive range when the corresponding data sequence has been submitted, executes archive submission when the corresponding data sequence has been verified and is waiting to be archived, and regenerates the data range that needs to be supplemented when the corresponding data sequence has not been received.

10. The breakpoint resumption method based on edge caching and cloud bidirectional confirmation according to claim 5, characterized in that, If the transmission is interrupted again during the retransmission process, the edge terminal saves the retransmission batch record, synchronization session identifier and instruction version; After communication is restored or the edge terminal restarts, the local synchronization status record and cache index record are read, the synchronization cycle identifier, the local available sequence range, the local confirmed archive position and the cache release pointer are restored, and a synchronization request record is sent based on the restored local synchronization status record.

Images