Freight event scheduling method and system based on blockchain and multi-cloud cooperation

Abstract

The application provides a freight event scheduling method and system based on blockchain and multi-cloud cooperation, relating to the technical field of data processing. The received freight key event is converted into a standard event object and written into a cache queue for deduplication and recovery processing, and a corresponding valid recovery event chain is generated. Based on the valid recovery event chain, the key performance status of the target waybill is identified, the summary information of the key performance status is written into the blockchain network, and the corresponding on-chain trusted anchor point of the target waybill is generated. When the waybill trusted state is triggered, a supplementary event chain is generated based on the on-chain trusted anchor point, the waybill performance status of each multi-cloud node is consistent according to the on-chain trusted anchor point and the supplementary event chain, the trusted performance status of the target waybill is determined, and the target waybill enters the next performance stage or triggers the abnormal processing process according to the trusted performance status. The precise recovery of the waybill performance status can be realized when the multi-cloud freight platform performs disaster recovery switching.

Description

Technical Field

[0001] This invention relates to data processing technology, and more particularly to a freight event scheduling method and system based on blockchain and multi-cloud collaboration. Background Technology

[0002] With the rapid development of smart logistics, network freight and regional collaborative transportation systems, freight platforms have gradually evolved from single-center deployment mode to dual-cloud disaster recovery and cross-regional multi-cloud deployment mode. In order to meet the requirements of cross-regional access, off-site disaster recovery, business continuity and high availability, more and more freight platforms adopt multi-cloud collaborative architecture, deploying different regional businesses on different cloud nodes and achieving disaster recovery switching through primary and backup mechanisms.

[0003] In existing technologies, during the actual operation of multi-cloud freight platforms, due to differences in network latency, synchronization strategies, and the risk of local failures among different cloud nodes, the fulfillment status of the same waybill may be inconsistent across different cloud nodes. For example, one cloud node may have confirmed dispatch, while another cloud node may still be in the loading state. This could lead to the backup cloud node only being able to recover to a certain delayed fulfillment status after the primary cloud node fails, making it impossible to accurately determine the actual fulfillment stage of the target waybill before the failure. Such problems can affect subsequent scheduling control, receipt confirmation, anomaly detection, and settlement processing, reducing the reliability of the platform.

[0004] Therefore, how to accurately restore the fulfillment status of waybills during disaster recovery switching on a multi-cloud freight platform has become an urgent problem to be solved. Summary of the Invention

[0005] This invention provides a freight event scheduling method and system based on blockchain and multi-cloud collaboration, which can achieve accurate recovery of waybill fulfillment status when a multi-cloud freight platform is switching to disaster recovery.

[0006] A first aspect of the present invention provides a freight event scheduling method based on blockchain and multi-cloud collaboration, comprising: The received critical freight events from multiple cloud nodes and multiple source terminals are converted into standard event objects and written into a cache queue. The standard event objects in the cache queue are deduplicated and restored to generate a valid recovery event chain corresponding to the target waybill. Based on the effective recovery event chain, the key performance status of the target waybill is identified, and the summary information of the key performance status is written into the blockchain network to generate the corresponding on-chain trusted anchor point for the target waybill. When the trust status determination of the waybill is triggered, a supplementary event chain is generated based on the on-chain trust anchor point. The consistency of the waybill fulfillment status of each multi-cloud node is verified according to the on-chain trust anchor point and the supplementary event chain to determine the trust fulfillment status of the target waybill. Based on the trusted fulfillment status, the target waybill is controlled to enter the next fulfillment stage or trigger an exception handling process.

[0007] Optionally, in one possible implementation of the first aspect, the step of converting the received freight critical events from multiple cloud nodes and multiple source terminals into standard event objects and writing them into a cache queue, performing deduplication and recovery processing on the standard event objects in the cache queue, and generating a valid recovery event chain corresponding to the target waybill includes: Extract the waybill identifier, event type, event time, and event content summary from each key freight event, and reorganize the extracted data based on a preset data structure to obtain a standard event object. Then, write the standard event object into the corresponding cache queue based on the waybill identifier. Based on the event type and event content summary under the same waybill identifier, the standard event objects in the cache queue are deduplicated to obtain valid event objects; The valid event objects are sorted according to the chronological order of the events to obtain a valid event sequence; From the valid event sequence, valid event objects that conform to the preset state transition order are extracted in sequence to form the valid recovery event chain of the target waybill.

[0008] Optionally, in one possible implementation of the first aspect, the step of sequentially extracting valid event objects conforming to a preset state transition order from the valid event sequence to form a valid recovery event chain for the target waybill includes: Obtain the event type of the currently valid event object in the valid event sequence; When the event type does not have a corresponding preceding event type in the preset state transition order, the currently valid event object is added to the valid recovery event chain; When the event type has a corresponding preceding event type in the preset state transition order, and the valid event object corresponding to the preceding event type already exists in the valid recovery event chain, the current valid event object is added to the valid recovery event chain.

[0009] Optionally, in one possible implementation of the first aspect, when performing deduplication and recovery processing on the standard event objects in the cache queue, the method further includes: When a synchronization link between multi-cloud nodes and multi-source terminals, or between different multi-cloud nodes, is interrupted, the event sequence number of the standard event object that has completed deduplication and recovery processing at the time of the interruption is recorded. After the synchronization link is restored, standard event objects that have not undergone deduplication and recovery processing are read from the event sequence number onwards, and the deduplication and recovery processing is performed again on the read standard event objects.

[0010] Optionally, in one possible implementation of the first aspect, the step of identifying the key performance status of the target waybill based on the effective recovery event chain, writing the summary information of the key performance status into the blockchain network, and generating an on-chain trusted anchor point corresponding to the target waybill includes: From the effective recovery event chain, standard event objects whose event types belong to the preset key performance stages are extracted as target event objects. The preset key performance stages include at least receipt and settlement. Calculate the status summary value based on the event type, event time, and event content summary of the target event object; The status summary value, the waybill identifier of the target waybill, the event type, and the identifier of the existing on-chain trusted anchor of the target waybill are used to construct an anchor record and submit it to the blockchain network for evidence storage, thereby generating the on-chain trusted anchor of the target waybill.

[0011] Optionally, in one possible implementation of the first aspect, calculating the status summary value based on the event type, event time, and event content summary of the target event object includes: Based on a preset order, the event type, the event time, the event content summary, and the identifier of the existing trusted on-chain anchor point of the target waybill are concatenated to obtain a summary string; Perform a hash operation on the digest string and use the resulting hash value as the state digest value.

[0012] Optionally, in one possible implementation of the first aspect, when the trust status determination of the waybill is triggered, generating a supplementary event chain based on the on-chain trust anchor, and performing consistency verification on the waybill fulfillment status of each multi-cloud node according to the on-chain trust anchor and the supplementary event chain to determine the trust fulfillment status of the target waybill, includes: Obtain the nearest on-chain trusted anchor point corresponding to the target waybill as the target trusted anchor point, extract and deduplicate the standard event objects in the cache queue based on the event time of the target trusted anchor point, and generate the supplementary event chain; Obtain the fulfillment status of the target waybill recorded by each multi-cloud node, compare the fulfillment stage corresponding to the target trusted anchor point and the fulfillment stage corresponding to each event object in the supplementary event chain with the fulfillment status of each waybill, and determine the fulfillment status of the waybill that matches the comparison as the trusted fulfillment status of the target waybill.

[0013] Optionally, in one possible implementation of the first aspect, controlling the target waybill to enter the next fulfillment stage or triggering an exception handling process based on the trusted fulfillment status includes: Obtain the trusted number corresponding to the trusted performance status in the preset state transition sequence, and the current number corresponding to the current performance stage of the target waybill in the preset state transition sequence; When the trusted number is greater than the current number, the fulfillment stage of the target waybill is updated to the trusted fulfillment status, and the automatic scheduling operation for the next fulfillment stage is executed. When the trusted number is less than the current number, the target waybill triggers an exception handling process.

[0014] Optionally, in one possible implementation of the first aspect, the triggering of the exception handling process includes: Add an abnormal status marker to the target waybill and suspend the automatic scheduling operation of the target waybill; Obtain the number difference between the current number and the trusted number. When the number difference is less than a preset threshold, perform a synchronization operation on the waybill status between each multi-cloud node. When the difference is greater than or equal to the preset threshold, a manual review process is triggered; When the target waybill is in the receipt or settlement stage, the target waybill is prohibited from entering the receipt confirmation process or settlement initiation process.

[0015] A second aspect of the present invention provides a freight event scheduling system based on blockchain and multi-cloud collaboration, comprising: The conversion module is used to convert the received freight key events from multiple cloud nodes and multiple source terminals into standard event objects and write them into a cache queue. The standard event objects in the cache queue are deduplicated and restored to generate a valid recovery event chain corresponding to the target waybill. The generation module is used to identify the key performance status of the target waybill based on the effective recovery event chain, write the summary information of the key performance status into the blockchain network, and generate the corresponding on-chain trusted anchor point for the target waybill. The verification module is used to generate a supplementary event chain based on the on-chain trusted anchor point when the trust status determination of the waybill is triggered, and to perform consistency verification on the waybill fulfillment status of each multi-cloud node according to the on-chain trusted anchor point and the supplementary event chain to determine the trust fulfillment status of the target waybill. The control module is used to control the target waybill to enter the next fulfillment stage or trigger an exception handling process based on the trusted fulfillment status.

[0016] The beneficial effects of this invention are as follows: 1. This invention can form on-chain anchors by writing summary information of key performance status into the blockchain. During disaster recovery switching, the on-chain anchors are used as the recovery starting point. Incremental events are extracted from the cache queue to generate a supplementary event chain and perform consistency verification. This enables the backup cloud node to accurately determine the current performance status of the waybill based on the immutable on-chain anchors and the supplementary event chain that has been deduplicated and recovered, thereby ensuring the accuracy of scheduling control.

[0017] 2. This invention standardizes the processing of key events such as order placement, loading, dispatch, tracking, receipt, and settlement. Combined with caching, duplicate filtering, breakpoint resume, and sequential recovery mechanisms, it can effectively reduce the inconsistency of the same waybill in different cloud nodes in dual-cloud disaster recovery and cross-regional multi-cloud scenarios, thereby improving the consistency of freight fulfillment status.

[0018] 3. This invention compares the trusted fulfillment status with the sequence number of the current fulfillment stage recorded locally by the current processing node in the preset state transition sequence. When the trusted number is greater than the current number, the status is determined to advance and the automatic scheduling operation of the next fulfillment stage is executed. When the trusted number is less than the current number, the status is determined to revert and an exception handling process is triggered. This enables the multi-cloud freight platform to perform differentiated scheduling control on the target waybill based on the trusted fulfillment status, which can improve the accuracy of fulfillment scheduling control and the security of freight operations. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating a freight event scheduling method based on blockchain and multi-cloud collaboration provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of a process for generating an effective recovery event chain provided by an embodiment of the present invention; Figure 3 This is a schematic diagram of the overall structure of a freight event scheduling system based on blockchain and multi-cloud collaboration provided by an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a freight event scheduling system based on blockchain and multi-cloud collaboration provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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.

[0021] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0022] See Figure 1 This is a flowchart illustrating a freight event scheduling method based on blockchain and multi-cloud collaboration provided in an embodiment of the present invention. Figure 1 The execution entity of the method shown can be a software and / or hardware device. The execution entity of this application can include, but is not limited to, at least one of the following: user equipment, network equipment, etc. User equipment can include, but is not limited to, computers, smartphones, personal digital assistants (PDAs), and the aforementioned electronic devices. Network equipment can include, but is not limited to, a single network server, a server group consisting of multiple network servers, or a cloud based on cloud computing consisting of a large number of computers or network servers. Cloud computing is a type of distributed computing, consisting of a super virtual computer composed of a group of loosely coupled computers. This embodiment does not limit this. Steps S1 to S4 are detailed as follows: S1, convert the received freight key events from multiple cloud nodes and multiple source terminals into standard event objects and write them into a cache queue, perform deduplication and recovery processing on the standard event objects in the cache queue, and generate a valid recovery event chain corresponding to the target waybill.

[0023] In dual-cloud disaster recovery and cross-regional multi-cloud scenarios, existing solutions rely on database master-slave synchronization or log replay for state recovery during disaster recovery switching of multi-cloud freight platforms. Due to synchronization delays and the possibility that backup snapshots may not cover events that occurred after the snapshot time, the backup cloud node cannot accurately determine the actual fulfillment stage of the waybill before the failure after taking over, directly affecting the accuracy of subsequent scheduling control and settlement processing. This solution writes the summary information of key fulfillment status into the blockchain to form on-chain anchors. During disaster recovery switching, the on-chain anchors are used as the recovery starting point. Incremental events are extracted from the cache queue to generate a supplementary event chain and perform consistency verification. This allows the backup cloud node to accurately determine the current fulfillment status of the waybill based on the immutable on-chain anchors and the deduplicated and recovered supplementary event chain, thereby ensuring the accuracy of scheduling control.

[0024] Among them, multi-cloud nodes refer to cloud computing nodes deployed by the freight platform in different regions, including primary cloud nodes and backup cloud nodes. Each cloud node independently undertakes the access and processing tasks of local freight business. Multi-source terminals refer to various terminal devices that generate events in freight business, including driver handheld terminals, dispatch terminals, station terminals, and vehicle trajectory collection devices. Freight critical events refer to business events that play a decisive role in the status flow during waybill fulfillment, including order acceptance events, loading events, departure events, trajectory events, receipt events, and settlement events. Standard event objects refer to event data structures with unified field formats obtained after uniformly transforming freight critical events from different sources and in different formats. The cache queue refers to the storage area used to temporarily store standard event objects. Deduplication and recovery processing refers to the duplicate event filtering and event sorting recovery operations performed sequentially on the standard event objects of the same waybill in the cache queue. The target waybill refers to the freight waybill currently undergoing event processing. The effective recovery event chain refers to the ordered sequence of events that conforms to the freight fulfillment business logic after duplicate filtering and sequential recovery processing. Dual-cloud disaster recovery refers to the deployment mode in which the business system is deployed on both the primary cloud node and the backup cloud node. When the primary cloud node fails, the backup cloud node takes over the business processing. Cross-regional multi-cloud refers to the deployment of the business system on multiple cloud nodes according to the region. Different cloud nodes respectively carry the freight business access and processing tasks in their respective regions.

[0025] Understandably, in the actual operation of a multi-cloud freight platform, critical freight events for the same waybill may originate from different cloud nodes and different terminals. These events have different data formats. Furthermore, due to mobile network signal fluctuations and automatic retry mechanisms on terminals, the same business action may be reported multiple times. The actual order in which different events arrive at the processing node may also differ from the actual order in which the business occurs. For example, if a driver clicks "confirm departure" on a mountainous road with weak signal, the terminal may automatically retry three times due to network fluctuations, resulting in the same departure event being reported three times. If the waybill's fulfillment status is updated immediately after each event arrives, repeated events will trigger the status to be repeatedly modified. Since out-of-order events may cause state transitions, after receiving critical freight events from various cloud nodes and terminals, the raw events of different formats can be uniformly converted into standard event objects and written into a cache queue. At this time, the current fulfillment status of the waybill is not modified. Deduplication and recovery processing is performed on the standard event objects of the same waybill in the cache queue. The deduplication and recovery processing first identifies multiple identical events that are reported repeatedly, retains only one of them, and then sorts and organizes the deduplicated events according to the logic of the order of business occurrence. The sorted and organized events are arranged in order to obtain the effective recovery event chain of the target waybill.

[0026] In some embodiments, step S1 can be implemented as follows: S11, extract the waybill identifier, event type, event time and event content summary from each key freight event, and reorganize the extracted data based on the preset data structure to obtain a standard event object, and write the standard event object into the corresponding cache queue based on the waybill identifier.

[0027] Here, waybill identifier refers to the number that identifies a freight waybill; event type refers to the business classification of key freight events, including order acceptance, loading, dispatch, trajectory, receipt, and settlement; event time refers to the actual business time when the key freight event occurs; event content summary refers to a fixed-length string obtained by hashing the original content of the key freight event, used to represent the content of the event; and data structure refers to the organization of each field in the standard event object.

[0028] Specifically, for each received critical freight event, four fields can be extracted from the raw data: waybill identifier, event type, event time, and event content summary. The extracted fields are then reorganized according to a preset data structure to form a standard event object. After reorganization, the standard event object is written into the cache queue corresponding to the waybill based on the waybill identifier in the standard event object.

[0029] S12, based on the event type and event content summary under the same waybill identifier, the standard event objects in the cache queue are deduplicated to obtain valid event objects.

[0030] Among them, the valid event object refers to the standard event object that is retained for subsequent sorting after repeated filtering.

[0031] Understandably, in freight scenarios, the main reasons for duplicate event reporting include terminal network timeout retries and duplicate delivery by message middleware. For example, when a driver confirms loading, if the terminal sends an event but does not receive timely confirmation from the server, the automatic retry mechanism triggers a resend, resulting in the same loading event being reported twice. These two reported events have the same waybill identifier, event type, and event content summary, essentially describing the same business action. If these duplicate events are not filtered, subsequent state transition processing will execute the same action twice, potentially leading to state anomalies. Therefore, in the cache queue, for multiple standard event objects with the same event type and event content summary under the same waybill, only one can be retained as a valid event object, while the remaining duplicate events are discarded, ensuring that the same business action is processed only once in subsequent processing.

[0032] S13, Sort the valid event objects according to the chronological order of the events to obtain a valid event sequence.

[0033] Among them, the effective event sequence refers to the sequence obtained by arranging the deduplicated effective event objects in order of event time from earliest to latest.

[0034] It is understandable that the order in which events arrive at the cache queue is not the same as the actual order in which events occur at the freight site. Due to differences in network conditions, loading events that occur earlier may arrive later due to network delays, while departure events that occur later may arrive earlier due to smooth network conditions. If the events are processed directly according to the arrival order, the judgment criteria for state transitions may not match the actual business situation. Therefore, it is necessary to sort the events according to the actual order of occurrence based on the event time recorded in each valid event object, and arrange the deduplicated valid event objects into a time-ordered valid event sequence.

[0035] S14, extract valid event objects that conform to the preset state transition order from the valid event sequence to form the valid recovery event chain of the target waybill.

[0036] Among them, the preset state transition sequence refers to the fixed order of each business stage in the freight fulfillment process, which stipulates the legal order of occurrence of each event type.

[0037] Understandably, even after sorting by event time, some events in the valid event sequence may still not conform to the normal logic of freight fulfillment due to timestamp errors or business anomalies. For example, if the time of a certain receipt event is earlier than the departure event time of the waybill, although the receipt event will be ranked first after sorting by time, from a business logic perspective, receipt cannot occur before departure. If the sorted event sequence is directly used as a valid recovery event chain, events with abnormal timestamps will be included in subsequent status determinations, affecting the accuracy of the status. Therefore, based on the sorting, the event sequence can be checked one by one according to the fixed chronological order of each stage of freight fulfillment. Only events that conform to the business logic can be extracted and constitute a valid recovery event chain.

[0038] Based on the above embodiments, step S14 can be implemented in the following ways: S141, Obtain the event type of the currently valid event object in the valid event sequence.

[0039] The currently valid event object refers to the valid event object that is being processed in the valid event sequence.

[0040] Understandably, it is necessary to check the state transition of each event in the valid event sequence to determine whether each event conforms to the preset state transition order. The premise for performing this check is to first obtain the type of the event currently being processed. Different types of events occupy different positions in the preset state transition order, and the check rules are also different.

[0041] S142, when the event type does not have a corresponding preceding event type in the preset state transition sequence, the currently valid event object is added to the valid recovery event chain.

[0042] Among them, the preceding event type refers to the previous event type that must have occurred before a certain event type in the preset state transition sequence.

[0043] It is understandable that there are dependencies between event types in the preset state transition sequence. For example, the prerequisite for departure is loading, and the prerequisite for receipt is en route. However, the first event type in the transition sequence, such as order acceptance, has no prior dependencies and no corresponding preceding event type. For this type of event, there is no need to wait for any preceding event to occur. It can be directly added to the effective recovery event chain as the starting point of the entire event chain.

[0044] S143, when the event type has a corresponding preceding event type in the preset state transition order, and the valid event object corresponding to the preceding event type already exists in the valid recovery event chain, the current valid event object is added to the valid recovery event chain.

[0045] Understandably, for event types with prior dependencies, an event can only be considered legitimate after its preceding event has occurred and been added to a valid recovery event chain. For example, the preceding event to a departure event is a loading event. Only when the loading event has been added to a valid recovery event chain does it mean that loading has indeed been completed, and only then does the received departure event conform to the business logic. If the preceding event has not yet appeared in the valid recovery event chain, it means that the event could not have occurred in the business logic, and the event cannot be added to the valid recovery event chain.

[0046] Specifically, after obtaining the event type of the current valid event object, it checks whether there is a corresponding preceding event type in the preset state transition order. If there is a corresponding preceding event type, it further checks whether the valid event object corresponding to the preceding event type has been added to the valid recovery event chain. When it is confirmed that the valid event object corresponding to the preceding event type already exists in the valid recovery event chain, the current valid event object is added to the valid recovery event chain. If the valid event object corresponding to the preceding event type does not exist in the valid recovery event chain, the current valid event object is not added to the valid recovery event chain.

[0047] Based on the above steps, when performing deduplication and recovery processing on the standard event objects in the cache queue, this scheme also includes the following embodiments: A1, in response to the interruption of the synchronization link between multi-cloud nodes and multi-source terminals, or between different multi-cloud nodes, records the event sequence number of the standard event object that has completed deduplication and recovery processing at the time of the interruption.

[0048] Among them, the synchronous link refers to the data communication connection between multi-cloud nodes and multi-source terminals, or between different multi-cloud nodes, used to transmit key freight events. The interruption time refers to the point in time when the synchronous link is broken and data cannot be transmitted normally. The event sequence number refers to the sequential number assigned to the standard event object when it is generated, which is used to identify the order position of the event in the event stream. For example, a waybill generates the order acceptance event, loading event, dispatch event, trajectory event and receipt event in sequence during the freight process. These five events are assigned the sequence numbers 1, 2, 3, 4 and 5 in sequence when they are generated. The processing node receives and processes these events in sequence according to the sequence number. If the synchronous link is interrupted after the processing node has successfully processed events 1 to 3, the event sequence number of the last standard event object that has completed deduplication and recovery processing at the time of interruption is 3. After the link is restored, the processing node resumes transmission from event 4 and obtains the 4th trajectory event and the 5th receipt event generated during the interruption.

[0049] Understandably, communication links are not always stable during the operation of a multi-cloud freight platform. For example, when a driver's terminal enters a tunnel or remote mountainous area, the network connection between the driver's terminal and the cloud node may be temporarily interrupted. Between two cloud nodes deployed across regions, the synchronization link may be interrupted due to network equipment failure or line cutover. During the link interruption, events generated by the terminal or cloud node cannot be transmitted to the processing node in a timely manner, causing events to accumulate at the sending end. After the link is restored, if the processing node does not know which event was processed before the interruption, it can only choose to fully synchronize all historical events from the beginning, or directly start receiving new events from the current moment and discard the events generated during the interruption. Full synchronization will cause a lot of duplicate transmission and processing overhead, while direct discarding will result in event loss. Therefore, when a link interruption is detected, the event sequence number of the last event that has been processed at the time of the interruption can be recorded, so that after the link is restored, it can be accurately known where to continue processing.

[0050] A2, after the synchronization link is restored, continue reading standard event objects that have not undergone deduplication and recovery processing from the event sequence number, and re-perform the deduplication and recovery processing on the read standard event objects.

[0051] Understandably, after the link is restored, the sending end may have accumulated many untransmitted events during the interruption. If the processing node starts from the beginning to retrieve all historical events, the already processed events will be repeatedly transmitted and processed, consuming additional computing and network resources. However, the recorded event sequence number indicates the processing progress. The processing node only needs to request events after the event sequence number from the sending end. The sending end only transmits the events newly generated during the interruption. The processing node re-executes deduplication and recovery processing on these incremental events, which avoids reprocessing historical events and ensures that no events generated during the interruption are missed. For example, the processing node has successfully processed events 1 to 3. During the link interruption, the driver terminal generated the 4th trajectory event and the 5th receipt event. After the vehicle leaves the tunnel and the link is restored, the processing node requests the 4th and subsequent events from the driver terminal based on the recorded event sequence number 3. The driver terminal uploads the 4th and 5th events in sequence. The processing node re-executes deduplication and recovery processing on these two events and integrates them into the effective restored event chain.

[0052] Specifically, after the synchronization link is restored, the recorded event sequence number is read, and the standard event objects following that event sequence number are obtained. The standard event objects generated after that event sequence number but not yet transmitted are sent to the processing node in sequence. After receiving these standard event objects, the processing node writes these events into the cache queue and re-executes deduplication and recovery processing on these events, including duplicate event filtering and event sorting recovery operations based on business order. After processing is completed, the generated valid recovery event chain is added to the existing event chain. The reason for re-performing deduplication and recovery processing is that the batch of events retrieved after the breakpoint resume transmission may have been partially processed before the interruption. For example, they may have been deduplicated but not sorted, or sorted but not generated into a valid chain. However, since the system state is lost when the interruption occurs, it is impossible to know exactly which step this batch of events was processed before the interruption. In order to ensure the integrity and correctness of the event chain, the most reliable way is to completely process this batch of events again through the deduplication and sorting process.

[0053] See Figure 2 This is a schematic diagram of a process for generating an effective recovery event chain, provided by an embodiment of the present invention. Figure 2As shown, by converting received critical freight events from multiple cloud nodes and multiple source terminals into standard event objects with a unified field format, and writing them into the corresponding cache queue based on the waybill identifier, the problem of state jump caused by the original event directly modifying the waybill status is avoided. Then, it is determined whether there are duplicate events in the cache queue. If so, duplicate events with the same event type and the same event content digest under the same waybill identifier are deduplicated, and only one valid event object is retained. Redundant data caused by terminal network timeout retries or duplicate delivery by message middleware is filtered out. Finally, it is determined whether there is a synchronization interruption caused by the interruption of the synchronization link. If a point exists, the unprocessed event is resumed from the sequence number of the processed event at the time of the interruption. The incremental event of the resumed event is re-processed to ensure that the events generated during the link interruption are not lost or processed repeatedly. Then, all valid event objects are sorted according to the event occurrence time to obtain a time-ordered valid event sequence. Then, valid event objects that conform to the preset state transition order, such as order acceptance, loading, dispatch, in transit, receipt, and settlement, are extracted from the valid event sequence. Abnormal events with logical conflicts, such as receipt events with timestamps earlier than the dispatch event, are removed. Finally, a valid recovery event chain corresponding to the target waybill is formed.

[0054] The above implementation methods can improve the reliability of event processing and data consistency of multi-cloud freight platforms under complex network conditions.

[0055] S2, based on the effective recovery event chain, identify the key performance status of the target waybill, write the summary information of the key performance status into the blockchain network, and generate the corresponding on-chain trusted anchor point for the target waybill.

[0056] Among them, the key performance status refers to the performance stage that plays a key role in the definition of responsibility and the triggering of settlement in the entire process of freight performance, including at least the receipt confirmation status and the settlement confirmation status. The summary information refers to the fixed-length hash value obtained by hashing the key fields of the event corresponding to the key performance status. The blockchain network refers to the distributed ledger network jointly maintained by multiple participating nodes, which has the characteristics of being immutable and traceable. The on-chain trusted anchor refers to the immutable status storage record generated on the blockchain after the summary information of the key performance status is submitted to the blockchain network for storage.

[0057] Understandably, the effective recovery event chain fully records all events of the waybill from its initial stage to the current stage. However, not every event in the chain needs to be stored on the blockchain. If all events were written to the blockchain, it would occupy a lot of storage space. Furthermore, key performance stages such as receipt and settlement are directly related to the transfer of ownership and fund settlement. In case of disputes, strong evidence is required. Therefore, events belonging to key performance stages can be identified from the effective recovery event chain, their summary information can be calculated, and then written to the blockchain to form a trusted anchor on the chain, which can reduce the amount of data on the chain.

[0058] Specifically, after generating a valid recovery event chain for the target waybill, the valid recovery event chain can be checked to identify events belonging to the key performance stage. The key performance stage includes at least receipt confirmation and settlement confirmation. The event content corresponding to the identified key performance stage is hashed to obtain the event summary information. The summary information is written into the blockchain network for notarization. After notarization is completed, a trusted on-chain anchor point corresponding to the target waybill is generated on the blockchain.

[0059] Based on the above embodiments, step S2 can be implemented in the following ways: S21, extract standard event objects whose event types belong to preset key performance stages from the effective recovery event chain as target event objects. The preset key performance stages include at least receipt and settlement.

[0060] Among them, the preset key performance stage refers to the set of performance stages that are of critical significance to the freight business, including at least the receipt stage and the settlement stage. The target event object refers to the standard event object that needs to be screened from the effective recovery event chain and needs to be anchored on the chain.

[0061] Understandably, an effective recovery event chain may contain various event types, such as order acceptance, loading, dispatch, tracking, receipt, and settlement. Different event types have different levels of importance to the business. Receipt and settlement are key nodes for liability definition and fund settlement in freight fulfillment, and need to form tamper-proof and trustworthy records. By pre-setting key fulfillment stages, key events such as receipt and settlement are selected from the event chain as target event objects. Subsequently, only these target event objects are processed on the chain, rather than all events in the event chain are processed on the chain.

[0062] Specifically, after generating a valid recovery event chain, each standard event object in the valid recovery event chain is traversed, the event type field of each standard event object is read, and the event type of each standard event object is compared with the preset key performance stages. The preset key performance stages include at least receipt and settlement. When the event type of a certain standard event object belongs to the preset key performance stages, the standard event object is extracted as the target event object.

[0063] S22, Calculate the status summary value based on the event type, event time, and event content summary of the target event object.

[0064] The status digest value is a fixed-length string obtained by hashing the key fields of the target event object, which is used to represent the fulfillment status of the event at a specific moment.

[0065] Understandably, blockchain notarization requires converting key information of an event into a fixed-length digest value. This ensures the immutability of the notarized content while controlling the size of the data uploaded to the chain. The event type identifies which performance stage it is, the event time records the specific moment the state occurred, and the event content digest contains the specific content fingerprint of the event. These three fields together determine the uniqueness of the state event.

[0066] Specifically, after extracting the target event object, the three fields of event type, event time, and event content summary are read from the target event object. These three fields are combined according to preset rules, and a hash operation is performed on the combined data to calculate the status summary value corresponding to the target event object.

[0067] Based on the above embodiments, step S22 can be implemented in the following ways: S221, based on a preset order, the event type, the event time, the event content summary, and the identifier of the existing trusted anchor point on the target waybill are concatenated to obtain a summary string.

[0068] The preset order refers to the fixed arrangement of the fields when concatenating strings, and the summary string refers to the string obtained by concatenating multiple fields in the preset order and used as input for hash operation.

[0069] Understandably, before performing hash operations, multiple fields need to be combined into a complete input. Since hash operations are sensitive to every character in the input, concatenating the same field content in different orders will produce completely different hash values. Therefore, a preset concatenation order needs to be agreed upon to ensure that the same result can be obtained when calculating the same event. In addition, the identifier of the existing on-chain trusted anchor point of the target waybill is added during concatenation. This allows the newly generated anchor point to form a reference relationship with the historical anchor point, linking multiple anchor points of the same waybill together.

[0070] Specifically, when calculating the state summary value, the event type, event time, and event content summary of the target event object are obtained. At the same time, it is queried whether the target waybill already has an on-chain trusted anchor. If it does, the identifier of the existing on-chain trusted anchor is obtained. The event type, event time, event content summary, and the identifier of the existing on-chain trusted anchor of the target waybill are concatenated in a preset order to obtain the summary string.

[0071] S222, Perform a hash operation on the digest string and use the resulting hash value as the state digest value.

[0072] Hash operation refers to the one-way operation process that maps input data of arbitrary length to a fixed-length output value through a hash function.

[0073] It is understandable that hash operations have two important characteristics: first, the same input always produces the same output; second, any slight change in the input will lead to a completely different output. The hash value obtained through hash operations can serve as a digital fingerprint of the event content. It can uniquely represent the original data, but the original content cannot be deduced from the hash value. The hash value is determined as the state digest value. After it is written into the blockchain, any party can verify the integrity and authenticity of the data by recalculating the hash value.

[0074] Specifically, after concatenating the digest string, a hash operation can be performed on the digest string. The hash operation can use algorithms such as SHA-256. After the operation is completed, a hash value of fixed length is obtained, and this hash value is determined as the state digest value of the target event object.

[0075] S23, construct an anchor record by taking the status summary value, the waybill identifier of the target waybill, the event type, and the identifier of the existing on-chain trusted anchor of the target waybill, and submit it to the blockchain network for evidence storage to generate the on-chain trusted anchor of the target waybill.

[0076] Anchor records refer to data records that are submitted to the blockchain network for evidence storage, consisting of a status summary value, waybill identifier, event type, and preceding anchor identifier.

[0077] Understandably, after calculating the state digest value, the digest value alone is not enough. The evidence record on the blockchain needs to contain sufficient location information so that subsequent queryers can know which waybill and which performance stage this record corresponds to. Therefore, the state digest value, the waybill identifier of the target waybill, the event type, and the identifier of the existing on-chain trusted anchor can be used to construct an anchor record, which is then submitted to the blockchain network for evidence storage. The waybill identifier and event type are used for location and retrieval, the preceding anchor identifier is used to form the anchor chain, and the state digest value is used to verify data integrity.

[0078] Specifically, after calculating the state summary value, the waybill identifier of the target waybill, the event type of the target event object, and the identifier of the existing on-chain trusted anchor of the target waybill can be obtained. These four pieces of data are used to construct an anchor record. The constructed anchor record is submitted to the blockchain network. After the nodes in the blockchain network verify the anchor record through consensus, they write it into a block. After the writing is completed, the anchor record generates an immutable evidence record on the blockchain, which is the on-chain trusted anchor of the target waybill. This anchor obtains a unique anchor identifier on the blockchain. Subsequent anchor records can reference this anchor identifier as the preceding anchor identifier, thereby forming the anchor chain of the target waybill on the blockchain.

[0079] The above implementation methods can reduce the storage pressure and data processing volume of the blockchain network and improve the integrity of the performance status evidence.

[0080] S3, when the trust status determination of the waybill is triggered, a supplementary event chain is generated based on the on-chain trust anchor point, and the consistency verification of the waybill fulfillment status of each multi-cloud node is performed according to the on-chain trust anchor point and the supplementary event chain to determine the trust fulfillment status of the target waybill.

[0081] Among them, the waybill trust status determination refers to the process initiated to determine the true fulfillment status of a waybill when a primary cloud node fails and a backup cloud node takes over, or when inconsistencies are detected in the fulfillment status of the same waybill recorded by different cloud nodes. The supplementary event chain refers to the event sequence generated after extracting the standard event object received after the trusted anchor point on the chain from the cache queue and performing deduplication and recovery processing again. The waybill fulfillment status refers to the current fulfillment stage of the waybill recorded by each multi-cloud node in its local database. The consistency verification refers to the process of comparing the fulfillment status deduced by the trusted anchor point on the chain and the supplementary event chain with the waybill fulfillment status recorded by each cloud node. The trustworthy fulfillment status refers to the waybill fulfillment stage that is confirmed as true and trustworthy after consistency verification.

[0082] It is understandable that when the primary cloud node fails, the fulfillment status of waybills in the local database of the backup cloud node may lag behind the actual status before the primary cloud failure due to synchronization delays. If the processing continues directly based on this lagging status, it may lead to status rollback or duplicate operations. At the same time, when the status of the same waybill recorded by different cloud nodes is inconsistent, it is impossible to directly determine which cloud node's record is correct. Therefore, a waybill trusted status determination process can be initiated. Using an immutable on-chain trusted anchor point on the blockchain as the starting point for recovery, incremental events arriving after the anchor point are extracted from the cache queue to generate a supplementary event chain. The anchor point and the supplementary event chain are combined to deduce the actual fulfillment stage of the waybill. Then, the status is compared and verified with the status recorded by each cloud node to determine the trusted fulfillment status, rather than simply accepting the database record of a certain cloud node.

[0083] Based on the above embodiments, step S3 can be implemented in the following ways: S31, obtain the nearest on-chain trusted anchor point corresponding to the target waybill as the target trusted anchor point, extract and deduplicate the standard event objects in the cache queue based on the event time of the target trusted anchor point, and generate the supplementary event chain.

[0084] Among them, the target trusted anchor point refers to the latest on-chain trusted anchor point of the target waybill found from the blockchain network, which can be used as the starting benchmark for this state recovery. The supplementary event chain refers to the ordered event sequence obtained after performing deduplication and recovery processing on the incremental standard event objects extracted from the cache queue, which is used to supplement the business events that occur after the target trusted anchor point.

[0085] Understandably, the same waybill may write the anchor point to the blockchain multiple times during the fulfillment process, such as once when the vehicle is dispatched and once when it is signed for. When the trust status of the waybill is triggered, it is necessary to find the anchor point that was most recently written, because the most recent anchor point corresponds to the trust status closest to the time of failure. Using the event time of the most recent anchor point as the boundary, standard event objects received after that time are extracted from the cache queue. These events are the incremental events that have occurred after the anchor point but may not have been confirmed yet, and can be used to generate supplementary event chains in the future.

[0086] Specifically, when the trust status determination of a waybill is triggered, all on-chain trust anchors of the target waybill are queried from the blockchain network. The anchors are sorted by their write time, and the one with the most recent write time is selected as the target trust anchor. The event time corresponding to the target trust anchor is read, and the event time is used as the extraction boundary. Standard event objects with event times later than the boundary under the target waybill are filtered from the cache queue and extracted. For example, if a waybill has two anchors on the blockchain, the first is the departure anchor with an event time of 10:30 and the second is the receipt anchor with an event time of 14:00, then the target trust anchor is the receipt anchor. Using 14:00 as the boundary, standard event objects with event times later than 14:00 are extracted from the cache queue, such as the settlement event with an event time of 14:10.

[0087] Understandably, the standard event objects extracted from the cache queue are incremental events received after the anchor point. These events may also have issues with duplicate reporting and out-of-order arrival. For example, the extracted events may include duplicate departure events reported by the driver terminal during retry, or receipt events that arrive before the trajectory events. If these incremental events are used directly for status determination, duplication and out-of-order will affect the accuracy of the determination results. Therefore, deduplication and recovery processing can be re-executed on these incremental events to filter duplicate events and sort them according to business logic, generating a clean and orderly supplementary event chain.

[0088] Specifically, after extracting the standard event objects, these standard event objects can be used as input to re-execute the deduplication and recovery process. The deduplication process identifies multiple identical events that are reported repeatedly and retains only one. The recovery process sorts and organizes the deduplicated events according to the order of business occurrence. After the processing is completed, a supplementary event chain is obtained. For example, continuing the example above, there is only one settlement event extracted. The supplementary event chain generated after the deduplication and recovery process only contains the settlement event.

[0089] S32, obtain the fulfillment status of the target waybill recorded by each multi-cloud node, compare the fulfillment stage corresponding to the target trusted anchor point and the fulfillment stage corresponding to each event object in the supplementary event chain with the fulfillment status of each waybill, and determine the fulfillment status of the waybill that matches the comparison as the trusted fulfillment status of the target waybill.

[0090] The fulfillment stage refers to the business stage of a freight bill of lading during the fulfillment process, including order acceptance, loading, dispatch, en route, receipt, and settlement.

[0091] Understandably, the fulfillment stage corresponding to the target trusted anchor point is a stage that has been confirmed as completed on the blockchain, while the fulfillment stage corresponding to the event in the supplementary event chain is a new stage that occurs after the anchor point. Together, they constitute a complete fulfillment path from the nearest trusted point to the current moment. Each multi-cloud node records the fulfillment status of the waybill in its local database. These records may differ due to synchronization delays. For example, the primary cloud node may have recorded it as settled before the failure, the backup cloud node may still record it as signed for due to synchronization delays, and another regional cloud node may record it as en route. The fulfillment path derived from the anchor point and the supplementary event chain is used as a judgment benchmark and compared with the records of each cloud node one by one. The node records that match the benchmark are considered trusted and are determined as trusted fulfillment status. The purpose of this is to use the immutable on-chain anchor point and the processed incremental events to verify the local records of each cloud node, rather than simply accepting the database status of a certain cloud node.

[0092] Specifically, after generating the supplementary event chain, the fulfillment status of the target waybill recorded in the local database of each multi-cloud node can be retrieved. The fulfillment stage corresponding to the target trusted anchor point and the fulfillment stage corresponding to each event object in the supplementary event chain are read. The fulfillment stages corresponding to the anchor point and the fulfillment stages corresponding to each event in the supplementary event chain are combined sequentially as a judgment benchmark. The fulfillment status of the waybill recorded by each multi-cloud node is compared with this judgment benchmark one by one. When the fulfillment status of a waybill recorded by a multi-cloud node is consistent with the judgment benchmark, the waybill is... The fulfillment status of a waybill is determined as the credible fulfillment status of the target waybill. For example, continuing the example above, the target credible anchor point is the receipt anchor point, and its corresponding fulfillment stage is receipt. The supplementary event chain is the settlement event, and its corresponding fulfillment stage is settlement. The fulfillment path obtained by combining the two in sequence is receipt and settlement. The judgment benchmark is settlement. Assuming that the main cloud node record is settlement and the backup cloud node record is receipt, the main cloud record is compared with the judgment benchmark. The settlement in the main cloud record is consistent with the judgment benchmark. Therefore, settlement can be determined as the credible fulfillment status of the target waybill.

[0093] The above implementation methods can improve the accuracy and reliability of state recovery of multi-cloud freight platforms in fault scenarios.

[0094] S4, based on the trusted fulfillment status, control the target waybill to enter the next fulfillment stage or trigger the exception handling process.

[0095] The next fulfillment stage refers to the next fulfillment stage after the trusted fulfillment state in the preset state transition sequence. The exception handling process refers to the handling measures executed on the target waybill when the trusted fulfillment state does not meet the normal progress conditions, including status marking, suspension of scheduling, and notification for manual review.

[0096] Understandably, the identified reliable fulfillment status represents the current actual fulfillment stage of the waybill. However, simply knowing the actual status is not enough. It is also necessary to determine how to proceed based on this status. If the reliable status is progressing normally, the waybill should be controlled to enter the next fulfillment stage to continue the business process. If the reliable status shows abnormalities such as rollback or stagnation, it indicates that there is a problem in the data processing or synchronization process. Continuing directly may lead to incorrect receipt or incorrect settlement. Therefore, it is necessary to trigger the abnormal handling process to intervene.

[0097] Based on the above embodiments, step S4 can be implemented in the following ways: S41, obtain the trusted number corresponding to the trusted performance status in the preset state transition sequence, and the current number corresponding to the current performance stage of the target waybill in the preset state transition sequence.

[0098] Among them, the trusted number refers to the sequential number of the trusted performance status in the preset state transition sequence, the current performance stage refers to the performance stage recorded in the local database of the target waybill in the current processing node, and the current number refers to the sequential number of the current performance stage in the preset state transition sequence.

[0099] It is understandable that the various stages of freight fulfillment have a fixed sequence, such as order acceptance, loading, dispatch, en route, receipt, and settlement. To facilitate comparison of which state comes first, each stage can be assigned a sequentially increasing number. For example, order acceptance is number 1, loading is number 2, dispatch is number 3, en route is number 4, receipt is number 5, and settlement is number 6. By comparing the reliable number with the current number, it can be determined whether the reliable state has progressed forward or backward.

[0100] Specifically, after determining the reliable fulfillment status, the number corresponding to the reliable fulfillment status is found from the number mapping of the preset status transition sequence as the reliable number. At the same time, the current fulfillment stage recorded in the local database of the current processing node of the target waybill is read, and the number corresponding to the current fulfillment stage is found as the current number.

[0101] S42, when the trusted number is greater than the current number, update the fulfillment stage of the target waybill to the trusted fulfillment status, and execute the automatic scheduling operation for the next fulfillment stage.

[0102] Automatic scheduling operations refer to business process operations that are automatically triggered by processing nodes to advance waybills to the next fulfillment stage, such as notifying the settlement system to initiate settlement or notifying the driver's terminal to confirm receipt.

[0103] Understandably, if the trusted number is greater than the current number, it means that the trusted fulfillment status is later than the status of the local record. This situation usually occurs because the local record is lagging behind due to synchronization delays. The trusted status represents the actual progress. For example, the local record is "departure" with number 3, while the confirmed trusted status is "receipt" with number 5. Since 5 is greater than 3, it means that the waybill has actually been signed for. In this case, the trusted status should be used to update the local record, and the next stage of scheduling after receipt should be automatically executed to ensure that the business continues to move forward without being blocked due to the lag in the local record.

[0104] Specifically, when the acquired trusted number is greater than the current number, the fulfillment stage recorded in the local database of the current processing node for the target waybill is updated to a trusted fulfillment status. After the update is completed, the next fulfillment stage of the trusted fulfillment status is determined according to the preset state transition order, and the automatic scheduling operation corresponding to the next fulfillment stage is triggered.

[0105] S43, when the trusted number is less than the current number, the target waybill triggers an exception handling process.

[0106] Understandably, if the trusted number is less than the current number, it means that the trusted fulfillment status is ahead of the status recorded locally, indicating a status rollback. For example, if the local record is "received" with number 5, while the trusted status is "departed" with number 3, and 3 is less than 5, this usually means that the previously recorded receipt status may have been updated prematurely due to receiving out-of-order or erroneous events, and the actual business has not progressed to receipt. If the process continues in this state, it may lead to incorrect settlement or duplicate operations. Therefore, when a status rollback is detected, an exception handling process must be triggered to prevent automatic scheduling and require manual intervention to investigate the cause.

[0107] In some embodiments, the "triggering exception handling process" in step S43 includes the following steps: S431, Add an abnormal status marker to the target waybill and suspend the automatic scheduling operation of the target waybill.

[0108] Among them, the anomaly marker refers to the label added to the target waybill to indicate that the waybill is currently in an abnormal state and requires manual attention.

[0109] Understandably, upon detecting a rollback, the first step is to prevent the anomaly from spreading further. By adding an anomaly status flag, the dispatching system can identify that the waybill cannot be processed automatically and suspend all automatic dispatching operations. This prevents the system from automatically triggering critical actions such as receipt confirmation or settlement initiation under erroneous conditions, thus avoiding financial losses or liability disputes.

[0110] S432, obtain the number difference between the current number and the trusted number, and when the number difference is less than a preset threshold, perform a synchronization operation on the waybill status between each multi-cloud node.

[0111] Among them, the number difference refers to the value obtained by subtracting the trusted number from the current number, which can reflect the extent of the status rollback. The preset threshold is a pre-set critical value for the number difference used to distinguish the severity of the anomaly. The synchronization operation refers to triggering each multi-cloud node to resynchronize the fulfillment status of the waybill in order to eliminate data differences between nodes.

[0112] Understandably, the magnitude of state rollback varies. For example, if the local record shows "Received No. 5" and the trusted status shows "In Transit No. 4," the difference in numbers is 1, which is very small. This is usually not a serious data error, but may be due to a brief delay in data synchronization between cloud nodes. The local record has taken one more step than the trusted status. In this case, re-performing state synchronization between multiple cloud nodes can often automatically correct the inconsistency. However, if the difference is large, it indicates that multiple stages may have been skipped, which is a more serious problem and requires manual intervention. Differentiating the handling method by the size of the difference can avoid triggering alarms for all anomalies and reduce unnecessary manual intervention.

[0113] Specifically, the difference between the current number and the trusted number is calculated, and the difference is compared with a preset threshold. When the difference is less than the preset threshold, each multi-cloud node is triggered to re-execute the waybill status synchronization operation for the target waybill, obtain the latest fulfillment status, and update their respective local records.

[0114] S433, when the difference is greater than or equal to the preset threshold, a manual review process is triggered.

[0115] The manual review process refers to the process of pushing abnormal waybill information to a designated manual processing terminal, where operations personnel will manually check and correct the status.

[0116] Understandably, when the difference in the order number is large, it indicates that the state rollback exceeds the range that normal synchronization delay can explain. This may involve issues such as missing events, severe out-of-order delivery, or data writing errors. Such problems are difficult to repair safely through automatic synchronization and require manual intervention. Operations personnel need to check the complete event records and anchor information of the waybill to determine the true state and make manual corrections. For example, if the local record shows that the order number is 6 and the trusted state is that the order number is 3 and the state is 3, the difference is 3. This means that the two stages of transit and receipt were skipped. This situation is likely due to an erroneous event or system failure causing the state jump, and manual verification is necessary.

[0117] Specifically, when the difference in the number is greater than or equal to a preset threshold, the waybill identifier, current performance stage, reliable performance status, number difference, and related event records and anchor information of the target waybill are packaged into an abnormal review notification and pushed to the designated manual processing terminal, whereby the operations personnel manually check and correct the waybill status.

[0118] S434, when the target waybill is in the receipt stage or settlement stage, the target waybill is prohibited from entering the receipt confirmation process or settlement initiation process.

[0119] The signing stage refers to the waybill fulfillment status being signed, the settlement stage refers to the waybill fulfillment status being settled, the signing confirmation process refers to the business process of sending a signing confirmation notice to the shipper or consignee and completing the transfer of ownership of the goods, and the settlement initiation process refers to the business process of triggering freight settlement and initiating a settlement request to the payment system.

[0120] Understandably, signing for goods and settlement are two critical steps in freight operations. Signing for goods signifies the transfer of ownership, and initiating settlement signifies the allocation of funds. If signing for goods or settlement is mistakenly completed under abnormal conditions, the resulting losses are difficult to recover. Therefore, regardless of the size of the discrepancy in the order number, as long as the target waybill is currently in the signing for goods or settlement stage, the automatic execution of these two processes must be prohibited first to buy time for manual review and ensure that critical operations are not triggered under abnormal conditions.

[0121] Specifically, after the exception handling process is triggered, it checks whether the current fulfillment stage or trusted fulfillment stage of the target waybill involves receipt or settlement. If so, it sends a prohibition instruction to the receipt confirmation module and the settlement initiation module to prevent the target waybill from entering the receipt confirmation process and the settlement initiation process until manual review is completed and the exception status is lifted.

[0122] Through the above implementation methods, the multi-cloud freight platform can perform differentiated scheduling and control of target waybills based on the trusted fulfillment status, which can improve the accuracy of fulfillment scheduling and control and the security of freight operations.

[0123] See Figure 3 This is a schematic diagram of the overall structure of a freight event scheduling system based on blockchain and multi-cloud collaboration, provided by an embodiment of the present invention. Figure 3 As shown, this system consists of, from top to bottom, the terminal and service source layer, the multi-cloud service access layer, the event reliable processing layer, the blockchain trusted anchoring layer, the multi-cloud state consistency verification layer, and the state recovery and fulfillment scheduling control layer. Each layer completes data interaction and processing in sequence. The terminal and business source layer generates and reports key freight events throughout the entire process, including order acceptance, loading, dispatch, and receipt. The multi-cloud business access layer receives all events uniformly through the main cloud, backup cloud, and regional cloud nodes without directly modifying the waybill status. The event reliable processing layer sequentially completes event standardization, caching, deduplication, breakpoint resumption, and sequential recovery, generating an effective recovery event chain that conforms to business logic. The blockchain trusted anchoring layer extracts key performance status summaries and uploads them to the chain, forming an immutable trusted anchor chain. The multi-cloud state consistency verification layer combines the on-chain anchors and the off-chain event chain to compare the status of each cloud node and determine the trusted performance status. The state recovery and performance scheduling control layer completes disaster recovery switching and recovery, and performs scheduling control or anomaly handling based on the trusted status.

[0124] See Figure 4 This is a schematic diagram of a freight event scheduling system based on blockchain and multi-cloud collaboration provided by an embodiment of the present invention. The data processing system of this freight event scheduling system based on blockchain and multi-cloud collaboration includes: The conversion module is used to convert the received freight key events from multiple cloud nodes and multiple source terminals into standard event objects and write them into a cache queue. The standard event objects in the cache queue are deduplicated and restored to generate a valid recovery event chain corresponding to the target waybill. The generation module is used to identify the key performance status of the target waybill based on the effective recovery event chain, write the summary information of the key performance status into the blockchain network, and generate the corresponding on-chain trusted anchor point for the target waybill. The verification module is used to generate a supplementary event chain based on the on-chain trusted anchor point when the trust status determination of the waybill is triggered, and to perform consistency verification on the waybill fulfillment status of each multi-cloud node according to the on-chain trusted anchor point and the supplementary event chain to determine the trust fulfillment status of the target waybill. The control module is used to control the target waybill to enter the next fulfillment stage or trigger an exception handling process based on the trusted fulfillment status.

[0125] Figure 4 The apparatus of the illustrated embodiment can be used to perform corresponding actions. Figure 1 The steps in the method embodiments shown are implemented in a similar manner and have similar technical effects, and will not be repeated here.

[0126] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A freight event scheduling method based on blockchain and multi-cloud collaboration, characterized in that, include: The received critical freight events from multiple cloud nodes and multiple source terminals are converted into standard event objects and written into a cache queue. The standard event objects in the cache queue are deduplicated and restored to generate a valid recovery event chain corresponding to the target waybill. Based on the effective recovery event chain, the key performance status of the target waybill is identified, and the summary information of the key performance status is written into the blockchain network to generate the corresponding on-chain trusted anchor point for the target waybill. When the trust status determination of the waybill is triggered, a supplementary event chain is generated based on the on-chain trust anchor point. The consistency of the waybill fulfillment status of each multi-cloud node is verified according to the on-chain trust anchor point and the supplementary event chain to determine the trust fulfillment status of the target waybill. Based on the trusted fulfillment status, the target waybill is controlled to enter the next fulfillment stage or trigger an exception handling process.

2. The method according to claim 1, characterized in that, The process of converting received critical freight events from multiple cloud nodes and multiple source terminals into standard event objects and writing them into a cache queue, performing deduplication and recovery processing on the standard event objects in the cache queue, and generating a valid recovery event chain corresponding to the target waybill includes: Extract the waybill identifier, event type, event time, and event content summary from each key freight event, and reorganize the extracted data based on a preset data structure to obtain a standard event object. Then, write the standard event object into the corresponding cache queue based on the waybill identifier. Based on the event type and event content summary under the same waybill identifier, the standard event objects in the cache queue are deduplicated to obtain valid event objects; The valid event objects are sorted according to the chronological order of the events to obtain a valid event sequence; From the valid event sequence, valid event objects that conform to the preset state transition order are extracted in sequence to form the valid recovery event chain of the target waybill.

3. The method according to claim 2, characterized in that, The step of sequentially extracting valid event objects that conform to a preset state transition order from the valid event sequence to form a valid recovery event chain for the target waybill includes: Obtain the event type of the currently valid event object in the valid event sequence; When the event type does not have a corresponding preceding event type in the preset state transition order, the currently valid event object is added to the valid recovery event chain; When the event type has a corresponding preceding event type in the preset state transition order, and the valid event object corresponding to the preceding event type already exists in the valid recovery event chain, the current valid event object is added to the valid recovery event chain.

4. The method according to claim 1, characterized in that, The deduplication and recovery process for standard event objects in the cache queue also includes: When a synchronization link between multi-cloud nodes and multi-source terminals, or between different multi-cloud nodes, is interrupted, the event sequence number of the standard event object that has completed deduplication and recovery processing at the time of the interruption is recorded. After the synchronization link is restored, standard event objects that have not undergone deduplication and recovery processing are read from the event sequence number onwards, and the deduplication and recovery processing is performed again on the read standard event objects.

5. The method according to claim 1, characterized in that, The process of identifying the key performance status of the target waybill based on the effective recovery event chain, writing the summary information of the key performance status into the blockchain network, and generating a corresponding on-chain trusted anchor for the target waybill includes: From the effective recovery event chain, standard event objects whose event types belong to the preset key performance stages are extracted as target event objects. The preset key performance stages include at least receipt and settlement. Calculate the status summary value based on the event type, event time, and event content summary of the target event object; The status summary value, the waybill identifier of the target waybill, the event type, and the identifier of the existing on-chain trusted anchor of the target waybill are used to construct an anchor record and submit it to the blockchain network for evidence storage, thereby generating the on-chain trusted anchor of the target waybill.

6. The method according to claim 5, characterized in that, The step of calculating the status summary value based on the event type, event time, and event content summary of the target event object includes: Based on a preset order, the event type, the event time, the event content summary, and the identifier of the existing trusted on-chain anchor point of the target waybill are concatenated to obtain a summary string; Perform a hash operation on the digest string to obtain a hash value as the state digest value.

7. The method according to claim 1, characterized in that, When the trust status determination of a waybill is triggered, a supplementary event chain is generated based on the on-chain trust anchor point. The consistency of the waybill fulfillment status of each multi-cloud node is verified according to the on-chain trust anchor point and the supplementary event chain to determine the trust fulfillment status of the target waybill, including: Obtain the nearest on-chain trusted anchor point corresponding to the target waybill as the target trusted anchor point, extract and deduplicate the standard event objects in the cache queue based on the event time of the target trusted anchor point, and generate the supplementary event chain; Obtain the fulfillment status of the target waybill recorded by each multi-cloud node, compare the fulfillment stage corresponding to the target trusted anchor point and the fulfillment stage corresponding to each event object in the supplementary event chain with the fulfillment status of each waybill, and determine the fulfillment status of the waybill that matches the comparison as the trusted fulfillment status of the target waybill.

8. The method according to claim 1, characterized in that, The step of controlling the target waybill to enter the next fulfillment stage or triggering an exception handling process based on the trusted fulfillment status includes: Obtain the trusted number corresponding to the trusted performance status in the preset state transition sequence, and the current number corresponding to the current performance stage of the target waybill in the preset state transition sequence; When the trusted number is greater than the current number, the fulfillment stage of the target waybill is updated to the trusted fulfillment status, and the automatic scheduling operation for the next fulfillment stage is executed. When the trusted number is less than the current number, the target waybill triggers an exception handling process.

9. The method according to claim 8, characterized in that, The exception handling process includes: Add an abnormal status marker to the target waybill and suspend the automatic scheduling operation of the target waybill; Obtain the number difference between the current number and the trusted number. When the number difference is less than a preset threshold, perform a synchronization operation on the waybill status between each multi-cloud node. When the difference is greater than or equal to the preset threshold, a manual review process is triggered; When the target waybill is in the receipt or settlement stage, the target waybill is prohibited from entering the receipt confirmation process or settlement initiation process.

10. A freight event scheduling system based on blockchain and multi-cloud collaboration, characterized in that, include: The conversion module is used to convert the received freight key events from multiple cloud nodes and multiple source terminals into standard event objects and write them into a cache queue. The standard event objects in the cache queue are deduplicated and restored to generate a valid recovery event chain corresponding to the target waybill. The generation module is used to identify the key performance status of the target waybill based on the effective recovery event chain, write the summary information of the key performance status into the blockchain network, and generate the corresponding on-chain trusted anchor point for the target waybill. The verification module is used to generate a supplementary event chain based on the on-chain trusted anchor point when the trust status determination of the waybill is triggered, and to perform consistency verification on the waybill fulfillment status of each multi-cloud node according to the on-chain trusted anchor point and the supplementary event chain to determine the trust fulfillment status of the target waybill. The control module is used to control the target waybill to enter the next fulfillment stage or trigger an exception handling process based on the trusted fulfillment status.

Images