An asynchronous parallel-based cargo source diagnosis method

Abstract

The application discloses a kind of based on asynchronous parallel's goods source diagnostic method, it is related to network freight big data intelligent matching technical field, including the following steps: response to the goods owner submitted goods source creation request, simultaneously trigger goods source matching main process and goods source diagnostic process;When executing goods source diagnostic process, according to preset rule, diagnostic task is split into several independent subtasks executed in parallel;Based on the output result of each subtask, according to the real-time state of goods source in goods source matching main process, fusion is carried out to diagnose goods source.The present application realizes the whole domain of diagnostic data to front-end customer service, without customer service to repeat verification to investigate goods source problem, significantly reduces the communication link of goods owner, improves customer service efficiency and goods owner experience;Overall effectively solve the technical pain points of traditional scheme, such as low efficiency, high latency, poor accuracy and data fragmentation, meet the logistics platform scale, intelligent, efficient goods source operation and matching business needs.

Description

Technical Field

[0001] This invention relates to the field of intelligent matching technology for big data in online freight transportation, and more specifically, to a freight source diagnosis method based on asynchronous parallelism. Background Technology

[0002] The existing logistics platform's cargo quality management uses a serial processing architecture of manual post-event inspection. Firstly, the timing of diagnosis is severely delayed. Cargo diagnosis is set after a matching failure, requiring a wait of 30 minutes or more before manual inspection can begin. This completely misses the golden window of driver response within 10 minutes of cargo posting, leading to a significant decrease in cargo matching success rate. Furthermore, it fails to utilize the multi-dimensional data already available at the time of cargo creation for pre-emptive prediction. Secondly, the existing diagnosis relies on manual, sequential verification of each dimension, checking price, cargo information, and capacity status in turn. It cannot simultaneously retrieve multi-source data for synchronous judgment, resulting in time-consuming and inefficient single-cargo diagnosis, making it difficult to handle the diagnostic needs of large volumes of cargo during peak periods, and creating a serious bottleneck in manpower concurrency. In addition, this technology… The diagnostic process is independent of the main cargo matching process, lacking status linkage and dynamic perception mechanisms. It can only push diagnostic results once and cannot adapt the push strategy according to different real-time lifecycle states such as cargo being posted, drivers browsing, and transactions being completed. This results in a large number of ineffective and inaccurate diagnostic suggestions. Finally, the existing diagnostic data is only stored in the operations backend, forming an information silo with the front-end customer service system. The diagnostic results from the operations side cannot be synchronously empowered to front-line customer service. This requires customer service to repeatedly verify and investigate cargo issues when dealing with cargo owners, which greatly increases communication costs and reduces service efficiency. All of the above defects result in low matching efficiency and high operational service costs of the existing technology, making it unable to meet the needs of large-scale, intelligent, and high-efficiency cargo matching operations in the logistics industry. Summary of the Invention

[0003] To address the aforementioned issues, the present invention aims to provide an asynchronous parallel-based sourcing diagnosis method, which achieves automated intelligent diagnosis of sourcing in real-time, parallel, status-linked, and omnichannel-enabled ways, thereby improving the success rate of sourcing matching and the efficiency of platform operation and customer service.

[0004] To achieve the above technical objectives, this application provides a source diagnosis method based on asynchronous parallelism, comprising the following steps: In response to the cargo owner's request to create cargo, the main cargo matching process and the cargo diagnosis process are triggered simultaneously. When performing the source diagnosis process, the diagnosis task is divided into several independent sub-tasks that are executed in parallel according to preset rules; Based on the output of each subtask, the results are integrated according to the real-time status of the cargo in the main cargo matching process to diagnose the cargo.

[0005] Preferably, when executing the main cargo matching process, the basic data of the cargo is verified for compliance and integrity, and then written into the capacity matching pool. The matching engine then initiates capacity matching scheduling to execute the main cargo matching process.

[0006] Preferably, when executing the source diagnosis process, an event message is created based on the source, and multiple independent diagnostic rules are triggered synchronously according to the business rule engine.

[0007] Preferably, when executing the source diagnosis process, the source creation event is pushed to the topic, and each diagnosis submodule subscribes to the topic as an independent consumer group, receives messages in parallel, and completes the corresponding dimension diagnosis.

[0008] Preferably, when executing the source diagnosis process, after the main thread receives the source creation event, it submits each diagnosis subtask to the asynchronous thread pool, where multiple worker threads execute them in parallel and continue to advance the main process.

[0009] Preferably, when splitting tasks, each subtask is executed in parallel through any of the following methods: parallel triggering by a rule engine, parallel execution by multiple consumers in a message queue, parallel execution by an asynchronous thread pool, or parallel execution by a combination of manual and tool methods. Each subtask is controlled to independently output diagnostic conclusions based on source data and external data.

[0010] Preferably, when performing task decomposition, the diagnostic task is divided into a price diagnosis subtask, an information completeness diagnosis subtask, and a capacity matching degree diagnosis subtask.

[0011] Preferably, before fusion, the diagnostic results of subtasks are summarized and sorted according to the preset priority of driver bidding-related dimensions > information completeness > price trend > service level, and high-priority diagnostic conclusions are displayed to the cargo owner first.

[0012] Preferably, during the fusion process, the state-aware fusion engine subscribes to domain events in the main process and dynamically determines the timing and presentation of diagnostic results based on the real-time status of the cargo in the cargo matching main process. When no driver has viewed the cargo, the diagnostic results are temporarily stored. When a driver views the cargo but does not place a bid, a partial diagnostic conclusion is pushed. When no transaction is completed within a preset time, a complete diagnostic report is pushed and customer service intervention is triggered.

[0013] Preferably, after diagnosing the source of goods, the client opens a chat window with the cargo owner and automatically extracts the unique UID of the cargo owner. Based on the cargo owner's UID, asynchronously retrieve all cargo information published under their name; and batch retrieve complete diagnostic results for each cargo. Sort the results according to severity and display them in the customer service sidebar.

[0014] Based on the same inventive concept, this invention also discloses a source diagnosis system based on asynchronous parallelism, comprising: The trigger module is used to respond to the cargo creation request submitted by the cargo owner, and at the same time trigger the main cargo matching process and the cargo diagnosis process. The task splitting module is used to split the diagnostic task into several independent sub-tasks that are executed in parallel according to preset rules when performing the source diagnosis process. The diagnostic fusion module is used to diagnose the cargo based on the output results of each subtask and the real-time status of the cargo in the main cargo matching process.

[0015] The present invention discloses the following technical effects: This invention decouples the diagnostic process from the main sourcing process into two parallel links. Predictive diagnostics are initiated within 5–10 seconds of sourcing creation, without increasing the delay of the main process, thus solving the problems of delayed diagnosis and missing the golden window for order acceptance.

[0016] This invention breaks down diagnostic dimensions such as price, capacity, and information integrity into independent asynchronous subtasks, relies on a rule engine for parallel computation, eliminates the time-consuming manual serial verification, and achieves multi-dimensional synchronous diagnosis.

[0017] This invention builds a state-aware fusion engine that subscribes to domain events throughout the entire lifecycle of goods and dynamically matches the timing and strategy for diagnostic pushes based on the real-time circulation status of goods, thus solving the problem of ineffective diagnostic suggestions.

[0018] This invention designs a zero-input context parsing mechanism driven by the cargo owner's identifier, which connects the diagnostic system and the customer service system. When customer service receives a call, the corresponding cargo source diagnostic information is automatically loaded, eliminating the need for repeated queries and empowering frontline customer service staff to communicate efficiently. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of the method described in this invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] like Figure 1 As shown, this invention provides a source diagnosis method based on asynchronous parallelism. This invention achieves significant technical optimization by decoupling and parallelizing the source diagnosis process with the main source matching process, performing asynchronous parallel operations on multiple diagnostic dimensions, constructing a main process status perception linkage mechanism, and connecting the data link between the diagnostic system and the customer service system.

[0023] Step S100 is based on an event-triggered dual-link parallel implementation.

[0024] In one implementation, in response to a cargo creation request submitted by a cargo owner, two operations are performed simultaneously in the same transaction: the main process operation publishes the cargo information to the capacity matching engine, and the diagnostic trigger operation sends a cargo creation event message to the message middleware.

[0025] For example, this invention differs from the existing single-link architecture of serial execution of matching and diagnosis. It constructs a dual-parallel link between the main cargo matching process and the cargo diagnosis process, enabling immediate pre-diagnosis initiation upon cargo creation, thus completely resolving the problem of delayed diagnosis. The specific implementation steps are as follows: After receiving a cargo owner's shipping request, the cargo creation gateway simultaneously executes two operations within the same transaction. The first is the main cargo matching process, where the system verifies the compliance and integrity of the cargo's basic data. Upon successful verification, the cargo is written into the capacity matching pool, and the matching engine initiates capacity matching scheduling. The second is the event-triggered diagnosis process, where the system synchronously generates a cargo creation event message carrying core data such as cargo ID, cargo owner UID, transportation route, cargo name, weight, price, and vehicle type requirements, and pushes it to the message middleware. The message middleware distributes the event message to the diagnosis process consumer. Upon receiving the message, the consumer automatically breaks it down into multiple independent diagnostic subtasks, which are then triggered and executed in parallel.

[0026] For example, the present invention configures four parallel execution alternative implementation schemes that can be used independently or in combination: First, the parallel triggering scheme of the rule engine relies on business rule engines such as Drools and URule to simultaneously trigger multiple independent diagnostic rules after receiving the source creation event. Each rule is calculated and outputs results independently. Second, the message queue multi-consumer solution pushes the source creation event to the topic, and each diagnostic sub-module subscribes to the topic as an independent consumer group, receives messages in parallel and completes the corresponding dimension diagnosis. Thirdly, the asynchronous thread pool solution: after the main thread receives the event, it submits each diagnostic subtask to the asynchronous thread pool, which is then executed in parallel by multiple worker threads. The main thread does not need to wait for the diagnostic results and continues to advance the main process. Fourth, a combination of manual and tool solutions is used to address scenarios not fully covered by the system. Multiple operations personnel are assigned to be responsible for different diagnostic dimensions simultaneously through standardized SOPs, and the diagnostic results are summarized after manual investigation.

[0027] For example, this implementation method shortens the traditional 30-minute to several-hour delay in diagnosis to 5-10 seconds after the cargo source is created. The single-dimensional diagnosis takes only 1-3 seconds, and the overall diagnosis time depends on the slowest sub-task dimension. It eliminates the problem of multiple dimensions accumulating time and accurately captures the golden window period for driver response.

[0028] Step S200: Implementation of the multi-dimensional parallel diagnostic processor.

[0029] In one embodiment, in the diagnostic process triggered by the diagnostic triggering operation, the diagnostic task is divided into N independent subtasks according to preset rules. The subtasks include at least a price diagnosis subtask, an information completeness diagnosis subtask, and a capacity matching degree diagnosis subtask. Each subtask is executed in parallel through any one of the following methods: parallel triggering by the rule engine, parallel execution by multiple consumers in the message queue, parallel execution by the asynchronous thread pool, or parallel execution by a combination of manual and tool methods. Each subtask independently outputs a diagnostic conclusion based on the source data and external data. For example, the present invention abandons the inefficient mode of manual single entry and sequential item-by-item investigation in the prior art, and builds a multi-dimensional diagnostic architecture with multiple entry points, parallel execution and priority summary. It sets five independent diagnostic dimensions: price diagnosis, information completeness diagnosis, capacity matching degree diagnosis, price trend diagnosis and service level diagnosis. The algorithms of each dimension are operated independently and do not interfere with each other, and the diagnostic dimensions can be added or removed as needed.

[0030] For example, the price diagnosis dimension: taking real-time quotes from the source and the historical transaction dataset of the same route over the past 90 days as input, firstly, the historical transaction prices are sorted and the P25, P50, and P75 quantiles are calculated, then the quantile ranking of the source quotes is calculated, and the quotes are judged to be low, reasonable, or high based on the ranking. For quotes that are low, optimized quotes in the P50-P75 range are automatically generated. Finally, the quantile position, judgment conclusion, suggested price range, and confidence level are output.

[0031] For example, the information completeness diagnosis dimension predefines core fields such as loading address, unloading address, tonnage, temperature requirements, vehicle length requirements, and loading time, as well as their corresponding impact weights. The system identifies and determines whether each field has missing, ambiguous, or non-standard issues, prioritizes missing fields according to their weights, and finally outputs a list of missing fields, the impact ranking results, and a cargo completeness score.

[0032] For example, the capacity matching degree diagnosis dimension is as follows: based on the cargo transportation route and vehicle type requirements, the current online matching capacity quantity is queried and compared with the historical average capacity quantity for the same period. The capacity density supply-demand ratio is calculated, and the capacity is judged into three states: tight, slightly tight, and sufficient, based on the density threshold. The capacity density, supply-demand ratio, and capacity matching conclusion are output.

[0033] For example, the price trend diagnosis dimension involves collecting the average daily transaction price series of the same route over the past 14 days, calculating the price slope through linear regression, calculating the week-on-week price change rate, and determining whether the price is stable, rising, or falling with a threshold of ±2%. The output includes the trend direction, the magnitude of change, and suggestions for optimizing the pricing of goods.

[0034] For example, the service level diagnosis dimension is as follows: match the characteristics of the source goods with the current service level, retrieve historical transaction data of the same goods category standard and preferred level, compare the difference in transaction rate between the two levels, and automatically suggest upgrading the service level when the difference exceeds the 10% threshold, and output the recommended service level and the expected improvement in transaction rate.

[0035] For example, after the diagnosis of each dimension is completed, the diagnosis results are summarized and sorted according to the preset priority of "driver bidding related dimensions > information completeness > price trend > service level". The high-priority diagnosis results are presented to the cargo owner first, which effectively improves the reference value and implementation efficiency of the diagnosis information and achieves multi-dimensional full coverage and high-efficiency parallel diagnosis.

[0036] Implementation method for fusing diagnostic results from step S300 with main process status perception.

[0037] In one implementation, the output results of each diagnostic subtask are sorted according to a preset priority to generate a comprehensive diagnostic report; the domain events of the main process are subscribed to through the state-aware fusion engine, and the timing and presentation of the diagnostic results are dynamically determined according to the real-time status of the cargo in the cargo matching main process—the diagnostic results are temporarily stored when no driver has viewed the cargo, partial diagnostic conclusions are pushed when a driver has viewed the cargo but has not placed a bid, and a complete diagnostic report is pushed and customer service intervention is triggered when no transaction is completed after a preset time.

[0038] For example, the present invention breaks through the existing technology's fixed mechanism of one-time forced push after diagnosis without distinguishing the status of the goods, and builds a status perception fusion engine to realize the dynamic linkage and accurate reach of the diagnosis results with the status of the goods throughout the entire life cycle.

[0039] For example, the state-aware fusion engine subscribes to all domain events in the main process of cargo in real time, such as driver browsing, driver bidding, transaction, and cancellation; when a change in state event is detected, the diagnostic results generated for that cargo are immediately retrieved from the cache; and a differentiated fusion and push strategy is matched with the real-time state of the cargo.

[0040] For example, the specific status adaptation rules are as follows: When a cargo listing is first posted and no drivers are browsing it, all diagnostic results are temporarily stored and pushed out later to avoid invalid notifications caused by the cargo owner's offline status; when a cargo listing generates driver browsing records but no bidding behavior, core optimization conclusions such as price and capacity are pushed out to the target audience to accurately intervene in key matching nodes; when a cargo listing has drivers bidding but no transaction is completed, a bid comparison analysis and negotiation optimization suggestions are pushed out to assist the cargo owner in making a quick decision; when a cargo listing has not been completed for more than 30 minutes, a full-dimensional diagnostic report and one-click optimization solution are pushed out; when a cargo listing has not been completed for more than 2 hours, a customer service intervention mechanism is automatically triggered to synchronize the cargo health rating (red, yellow, green) and complete diagnostic conclusions to the customer service end. This implementation method enables diagnostic suggestions to be pushed out on demand, in a timely manner, and accurately, completely eliminating the problem of invalid pushes and significantly improving the effectiveness of diagnostic results.

[0041] Step S400: Zero-input context parsing customer service empowerment implementation method.

[0042] In one implementation, the client interface automatically queries the diagnostic status of all cargoes in transit by the cargo owner and displays them in sorted order by severity, without requiring manual input of query criteria.

[0043] For example, the present invention breaks down the data barriers between the diagnostic system and the customer service system, solving the problem that existing technologies limit diagnostic data to internal operations and create blind spots in customer service information. It enables front-line customer service staff to receive full-domain support through a zero-input context parsing mechanism.

[0044] For example, after the customer service opens a chat window with the cargo owner, the unique UID of the corresponding cargo owner is automatically extracted; based on the cargo owner's UID, all cargo information published under their name is retrieved asynchronously; complete diagnostic results of each cargo are retrieved in batches from the system cache; sorted according to severity priority (red serious issues > yellow optimizable issues > green normal status) and automatically displayed in the customer service sidebar. Among them, red status corresponds to serious issues that affect matching, such as low price and missing core information; yellow status corresponds to optimizable issues such as slightly abnormal price and information that needs to be improved; and green status corresponds to normal cargo with compliant cargo parameters and excellent matching conditions.

[0045] For example, the present invention also supports multiple extended query schemes, enabling functions such as manual query of cargo ID, batch query based on route dimension, and query of cargo within a specified time range as needed. Through this implementation, customer service representatives no longer need to manually query or repeatedly verify cargo issues; they can simply open a chat window to intuitively grasp the health status and diagnostic conclusions of all cargo sources owned by the cargo owner, significantly shortening service response time and improving customer service quality.

[0046] In summary, addressing the shortcomings of existing technologies such as delayed diagnostic timing, low diagnostic efficiency, inaccurate push notification timing, and inability of data to empower customer service, this invention can complete pre-judgment diagnosis within 5-10 seconds after cargo listing is created. This effectively captures the golden window of driver response after cargo listing is published, curbing the decline in cargo matching success rate over time and significantly increasing the overall probability of cargo transactions. By executing multi-dimensional diagnostic tasks in parallel, it abandons the traditional manual serial screening mode, eliminates the minute-level diagnostic time for a single cargo listing, breaks through the bottleneck of concurrent manual processing, and can efficiently process the massive cargo diagnostic needs during peak platform periods, greatly improving the efficiency of cargo problem investigation. Meanwhile, this invention can perceive the dynamic status of the entire lifecycle of goods in real time, and adaptively adjust the timing and strategy of pushing diagnostic results according to different stages of goods circulation, accurately matching the optimal reach scenario, effectively eliminating the problem of invalid pushes, and greatly improving the effectiveness of diagnostic suggestions. In addition, this invention enables diagnostic data to empower front-end customer service across the entire domain, eliminating the need for customer service to repeatedly verify and investigate goods issues, significantly reducing the communication links for cargo owners, improving customer service efficiency and cargo owner experience. Overall, it effectively solves the technical pain points of traditional solutions such as low efficiency, high latency, poor accuracy, and data fragmentation, meeting the needs of logistics platforms for large-scale, intelligent, and efficient goods operation and matching business.

[0047] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A source diagnosis method based on asynchronous parallelism, characterized in that, Includes the following steps: In response to the cargo owner's request to create cargo, the main cargo matching process and the cargo diagnosis process are triggered simultaneously. When performing the source diagnosis process, the diagnosis task is divided into several independent sub-tasks that are executed in parallel according to preset rules; Based on the output of each subtask, the results are fused according to the real-time status of the goods in the main goods matching process to diagnose the goods.

2. The asynchronous parallel-based source diagnosis method according to claim 1, characterized in that: During the main process of cargo matching, the basic data of the cargo is verified for compliance and integrity, and then written into the capacity matching pool. The matching engine then initiates capacity matching scheduling to execute the main process of cargo matching.

3. The asynchronous parallel-based source diagnosis method according to claim 1, characterized in that: When executing the source diagnosis process, an event message is created based on the source of goods, and multiple independent diagnostic rules are triggered synchronously according to the business rule engine.

4. The asynchronous parallel-based source diagnosis method according to claim 1, characterized in that: When performing the sourcing diagnostic process, the sourcing creation event is pushed to the topic, and each diagnostic submodule subscribes to the topic as an independent consumer group, receiving messages in parallel and completing the corresponding dimension diagnostics.

5. The asynchronous parallel-based source diagnosis method according to claim 1, characterized in that: When executing the source diagnosis process, after the main thread receives the source creation event, it submits each diagnosis subtask to the asynchronous thread pool, where multiple worker threads execute them in parallel and continue to advance the main process.

6. The asynchronous parallel-based source diagnosis method according to claim 1, characterized in that: When splitting tasks, each subtask is executed in parallel using any of the following methods: parallel triggering by the rule engine, parallel execution by multiple consumers in the message queue, parallel execution by the asynchronous thread pool, or parallel execution by a combination of manual and tool methods. Each subtask is controlled to independently output diagnostic conclusions based on source data and external data.

7. The asynchronous parallel-based source diagnosis method according to claim 1, characterized in that: When performing task breakdown, the diagnostic task is divided into price diagnosis subtask, information completeness diagnosis subtask, and capacity matching degree diagnosis subtask.

8. The asynchronous parallel-based source diagnosis method according to claim 1, characterized in that: Before integration, the diagnostic results of subtasks are summarized and sorted according to the preset priority of driver bidding-related dimensions > information completeness > price trend > service level, and high-priority diagnostic conclusions are presented to cargo owners first.

9. The asynchronous parallel-based source diagnosis method according to claim 1, characterized in that: During the fusion process, the state-aware fusion engine subscribes to domain events in the main process. Based on the real-time status of the cargo in the cargo matching main process, it dynamically determines the timing and presentation of the diagnostic results. When no driver has viewed the cargo, the diagnostic results are temporarily stored. When a driver views the cargo but does not place a bid, a partial diagnostic conclusion is pushed. When no transaction is completed within a preset time, a complete diagnostic report is pushed and customer service intervention is triggered.

10. The asynchronous parallel-based source diagnosis method according to claim 1, characterized in that: After diagnosing the source of goods, the system responds by opening a chat window with the cargo owner on the customer side and automatically extracting the corresponding cargo owner's unique UID. Based on the cargo owner's UID, asynchronously retrieve all cargo information published under their name; and batch retrieve complete diagnostic results for each cargo. Sort the results according to severity and display them in the customer service sidebar.

Images