Driver and route intelligent switching method and system under pre-transport emergency burst reduction

Abstract

This application discloses a method and system for intelligent driver and route swapping in the event of a sudden reduction in pre-booked transportation capacity. The method triggers swapping when there is a sudden reduction in capacity at the loading point. It sorts registered but unloaded drivers using multi-dimensional weighted scoring and divides them into primary candidates and multi-level waiting queues, forming a replacement chain. For each candidate driver, a recommendation list is generated based on historical data and currently available routes. After locking the slots, a notification is sent and the system listens for decision-making. Upon acceptance, the original route is cancelled and the new route is confirmed atomically through distributed transactions. If rejected or timed out, the lock is released and the replacement loop continues until N drivers are successfully swapped. This application solves the technical problems of low efficiency, inaccurate matching, resource conflicts, and lack of data consistency guarantees in pre-booked transportation scenarios with sudden capacity reductions. It achieves full automation of the swapping process and strong data consistency, effectively improving the efficiency and reliability of capacity scheduling in scenarios with sudden capacity reductions.

Description

Technical Field

[0001] This invention relates to the field of logistics monitoring and information technology, and in particular to a method and system for intelligent driver and route switching in the event of a sudden reduction in scheduled transportation. Background Technology

[0002] In pre-booked transportation scenarios, drivers register in advance for specific transportation routes based on their loading status, location information, and schedule. The platform then coordinates capacity and allocates routes according to the registration information, a common operating model in the logistics and transportation industry. With the continuous expansion of logistics and transportation scale and the dynamic changes in transportation demand, how to achieve efficient scheduling and rational allocation of transportation resources has become a pressing technical problem to be solved in this field.

[0003] Currently, several technical solutions address driver dispatching and route optimization in transportation scenarios. For example, some solutions analyze historical orders to identify order hotspots and, based on the driver's current location and / or historical order data, select matching areas from these hotspots to facilitate driver deployment. Other solutions match orders within a preset threshold for the difficulty level of different transportation routes to address time differences among drivers on the same route. Furthermore, some solutions involve dynamic optimization of logistics routes by selecting original routes with excess capacity less than a first threshold and alternative routes with physically connected cargo deficits exceeding a second threshold, allocating excess capacity on the original routes to the alternative routes. Still other solutions propose assigning route numbers to each route in the logistics network, predicting future road usage based on historical and current road usage information, identifying drivers needing route changes, calculating reachability scores based on cargo attributes, and selecting appropriate routes for drivers.

[0004] However, the aforementioned existing technical solutions have the following main shortcomings: First, existing technologies lack specific solutions for the particular scenario of a sudden reduction in transport capacity at the loading point in a pre-booked transportation scenario. In pre-booked transportation scenarios, drivers register in advance before undertaking a transport task. When a sudden reduction in transport capacity occurs at the loading point due to reasons such as cargo volume adjustments or warehousing anomalies, drivers who have registered for that route face the practical need to be reassigned to other routes due to excess capacity. Existing technologies mainly focus on capacity scheduling and route optimization under normal conditions, and fail to provide effective technical means for the batch reassignment of "registered but not yet loaded" drivers in the event of a sudden reduction in capacity.

[0005] Second, existing technologies rely on limited methods for driver screening and prioritization. Existing solutions often screen drivers based on a single dimension (such as driver location or historical order data), lacking a weighted scoring mechanism that comprehensively considers multiple factors such as loading status, distance from loading location, and registration time. This makes it difficult to accurately select the most suitable replacement candidates and their backup sequences from the registered drivers when sudden reductions occur.

[0006] Third, existing technologies lack personalized consideration in driver-route matching recommendations. Existing solutions mainly consider route attributes or cargo attributes when recommending routes, without fully integrating the driver's historical transport data (such as historical route familiarity, transport timeliness, etc.) to calculate the comprehensive matching degree between drivers and routes, resulting in insufficient suitability between recommended alternative routes and drivers' actual needs.

[0007] Fourth, existing technologies have shortcomings in terms of quota locking and transaction consistency. In scenarios where multiple drivers simultaneously switch routes, resource conflicts may arise due to simultaneous competition for quotas on multiple routes, and existing solutions lack a mechanism to temporarily lock quotas for recommended routes. Furthermore, after a driver accepts the switch, the cancellation of the original route registration and the confirmation of the new route registration involve multiple data operations requiring atomicity; existing technologies lack a distributed transaction coordination mechanism to guarantee strong consistency in the switch operation.

[0008] Fifth, existing technologies lack systematic queue management for replacement processing. When a candidate driver refuses to be replaced or fails to process within the time limit, existing solutions fail to establish a complete mechanism for automatically selecting the next-priority driver from the queue for replacement based on the priority link, resulting in low replacement efficiency.

[0009] In summary, existing technologies urgently need a method for intelligently switching drivers and routes that can accurately select drivers, match personalized routes, reliably lock quotas, ensure transaction consistency, and automatically replenish drivers in the context of sudden reductions in transportation capacity at loading points in pre-booked transportation scenarios. Summary of the Invention

[0010] This invention aims to at least solve one of the technical problems existing in the prior art. To this end, this invention proposes an intelligent driver and route switching system for sudden reductions in pre-booked transportation capacity, thereby addressing the technical problems existing in the prior art.

[0011] In a first aspect, the present invention provides a method for intelligent driver and route switching under sudden reductions in pre-booked transportation, the method comprising: In response to a sudden reduction in transport capacity at the loading site, obtain the target route and the number N of drivers that need to be replaced; Based on a multi-dimensional weighted score that includes at least the loading status, distance from the loading point, and registration time, the registered but unloaded drivers for the target route are prioritized. The top N drivers are assigned to the main candidate queue as candidate drivers, and the remaining drivers are assigned to at least one level of the waiting queue according to a preset ratio. The waiting queues at each level form a priority replacement link. According to the priority order of the candidate drivers, for each candidate driver, based on historical transportation data and currently available registration routes, the comprehensive matching degree between each candidate driver and each currently available registration route is calculated, and an alternative route recommendation list is generated. The number of available registration route slots ranked at the top of the recommendation list is temporarily locked. Send a change notification containing the recommendation list and decision time limit to the currently processed candidate driver, and listen for its decision response; If, during the validity period of the temporary lock, a decision is received that the candidate driver accepts the change and selects any available route from the recommended list, the distributed transaction coordinator is activated to atomically execute the cancellation of the original route registration and the confirmation of the new route registration. After the transaction is committed, all locked slots for the candidate driver are released. If a decision to refuse the change is received, the process is temporarily suspended, or the timeout occurs, or the lock validity period expires, all locked slots for the candidate driver are released. The next-ranked driver is selected from the waiting queue according to the replacement priority link as a new candidate driver. The process then returns to the comprehensive matching degree calculation, temporary slot locking, and replacement notification push, until the cumulative number of successfully replaced drivers reaches N.

[0012] In some embodiments, calculating the overall matching degree between each candidate driver and each currently available registration route based on historical transport data and currently available registration routes includes: The familiarity with historical routes is determined based on the number of times the candidate drivers have carried passengers on the available registration routes and their on-time rate within a preset historical time period. The vehicle type suitability is determined based on the degree of matching between the candidate driver's vehicle type and the vehicle type required for the available registration routes; The timeliness satisfaction is determined based on the degree of deviation between the candidate driver’s historical average transport time and the timeliness requirements specified for the available registration routes. The current load balance is determined based on the ratio of the number of currently registered drivers to the rated capacity demand for the available registration routes; The overall matching degree is obtained by weighting the familiarity with the historical route, the vehicle model compatibility, the timeliness satisfaction, and the current load balancing degree.

[0013] In some embodiments, calculating the overall matching degree between each candidate driver and each currently available registration route based on historical transport data and currently available registration routes further includes: The system obtains real-time dynamic change information for each available registration route, including real-time changes in the remaining slots for the route, dynamic adjustments to the route timeliness requirements, and real-time updates on road congestion levels. In response to the change in the dynamic information exceeding a preset threshold, the overall matching degree between the candidate driver and the relevant available registration routes is recalculated, and the alternative route recommendation list is updated.

[0014] In some embodiments, temporarily locking a preset number of routes ranked high in the recommendation list using available registration slots includes: For each of the top-ranked, pre-defined number of available routes in the recommended list, a unique locking token is generated. The locking token includes a locked route identifier, a locked driver identifier, a locked timestamp, and a validity period. The locking token is stored in a distributed cache, and an expiration time corresponding to the decision time limit is set. During the validity period of the lock token, other drivers' registration or lock requests for the same route will be rejected.

[0015] In some embodiments, the preset quantity is dynamically determined based on the scale of the sudden reduction event, including: When the number of drivers N to be replaced is greater than a first threshold, the preset number is a first value; when N is less than or equal to the first threshold, the preset number is a second value, and the first value is greater than the second value.

[0016] In some embodiments, after sending a change notification containing the recommendation list and decision time limit to the currently processed candidate drivers, the method further includes: Within the decision-making time limit, the decision response status of the candidate drivers is monitored at preset time intervals; If no decision response is received within the first half of the decision timeframe, a first reminder notification is sent to the candidate driver. If no decision response is received within the latter half of the decision time limit, a second reminder notification is sent to the candidate driver. The second reminder notification has a higher priority than the first reminder notification, and the second reminder notification includes a reminder of the remaining valid time of the temporary lock. If no decision response is received by the deadline, it is determined that the decision will not be processed or has timed out.

[0017] In some embodiments, the step of activating the distributed transaction coordinator and atomically executing the cancellation of the original route registration and the confirmation of the new route registration includes: To start a global transaction by enabling the distributed transaction coordinator, perform the following operations in sequence: First verification operation: Verify whether the candidate driver's registration status on the target route is still valid; The second verification operation is to verify whether the temporary lock-in slots for the available registration routes selected by the candidate drivers are still valid and have not been taken up by other transactions. If both the first verification operation and the second verification operation pass the verification, then cancel the candidate driver's registration on the target route and confirm the candidate driver's registration on the available registration routes, and submit the global transaction; If either the first verification operation or the second verification operation fails, the global transaction is rolled back, all locked slots for the candidate drivers are released, and the next driver is selected according to the supplementary priority link.

[0018] In some embodiments, selecting the next-ranked driver from the candidate queue as a new candidate driver according to the replacement priority link includes: Determine the original position k of the candidate driver currently being processed in the main candidate queue; The highest-priority candidate driver in the candidate queue is moved to the kth position in the main candidate queue as a new candidate driver. The processing order of the new candidate drivers does not change the original processing order of the (k+1)th and subsequent candidate drivers in the main candidate queue. Record the source and number of times the new candidate driver is added. When the same candidate driver is added but is rejected more than a preset number of times, the candidate driver is removed from the candidate queue.

[0019] In some embodiments, before obtaining the target route and the number N of drivers to be replaced in response to a sudden reduction in transport capacity at the loading location, the method further includes: Real-time monitoring of the reserved capacity data of each loading point; when the actual available capacity of any loading point decreases more than the reserved capacity by a preset reduction threshold, the sudden reduction event is triggered. The level of the sudden reduction event is determined based on the magnitude of the decrease, and the level includes at least a first-level reduction and a second-level reduction; When the sudden reduction event is a Level 1 reduction, the number of drivers N to be replaced is determined to be equal to the difference between the total number of registered but unloaded drivers on the target route and the actual number of drivers needed after the reduction. When the sudden reduction event is a level 2 reduction, the number N of drivers to be replaced is determined as a preset percentage of the difference between the total number of registered but unloaded drivers on the target route and the actual number of drivers needed after the reduction.

[0020] In a second aspect, the present invention provides a driver and route intelligent switching system for sudden reductions in pre-booked transportation, the system being used to implement the method described in any of the first aspects.

[0021] In a third aspect, the present invention provides a computer device including a memory and a processor, wherein the memory stores a computer program executable on the processor, and when the computer program is executed by the processor, implements the driver and route intelligent switching method under sudden reduction in scheduled transportation as described in any of the first aspects.

[0022] In a fourth aspect, the present invention provides a computer-readable storage medium storing a computer program, wherein, when the computer program is executed, it implements the driver and route intelligent switching method under sudden reduction in scheduled transportation as described in any of the first aspects.

[0023] The above-described technical solutions of the present invention have at least one or more of the following beneficial effects: In implementing the technical solution of this application, a replacement process is triggered in response to a sudden reduction in transport capacity at the loading location. Drivers who have registered but not yet loaded are prioritized based on a multi-dimensional weighted score, including at least loading status, distance from the loading location, and registration time. A main candidate queue and multi-level waiting queues are then formed, creating a priority replacement chain. This achieves accurate screening and orderly replacement of candidate drivers in the event of a sudden reduction in transport capacity. Furthermore, according to the priority order of the candidate drivers, the comprehensive matching degree between each candidate driver and each currently available registration route is calculated based on historical transport data and currently available registration routes, generating a personalized recommendation list. Simultaneously, a preset number of available registration route slots at the top of this list are temporarily locked. While ensuring that slots are not taken by other drivers, a replacement notification is sent to the currently processed candidate driver, and the decision response is monitored. This effectively improves the driver-to-driver matching process. The system enhances the personalization and accuracy of route matching. When a driver accepts a change and selects a route, a distributed transaction coordinator atomically executes the cancellation of the original route registration and the confirmation of the new route registration, ensuring strong consistency of data operations during the changeover process. When a driver refuses, times out, or the lock validity period expires, all locked slots are automatically released, and the next-ranked driver is selected from the waiting queue according to the replacement priority link, repeating the process until the cumulative number of successful changes reaches N. This constructs a complete closed loop from event triggering, precise screening, personalized matching, slot locking, decision monitoring, transaction guarantee to automatic replacement, significantly improving the automation level, matching accuracy, resource consistency guarantee capability, and overall processing efficiency of batch driver and route changes in sudden capacity reduction scenarios. It effectively solves the technical problem of being unable to timely, accurately, and reliably change registered drivers due to a sudden reduction in capacity at the loading point in the pre-booked transportation scenario.

[0024] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0025] The disclosure of this invention will become more readily understood with reference to the accompanying drawings. It will be readily understood by those skilled in the art that these drawings are for illustrative purposes only and are not intended to limit the scope of protection of this invention. Furthermore, similar numbers in the drawings are used to denote similar components, wherein: Figure 1 This is a flowchart of the intelligent driver and route switching method under sudden reduction in pre-booked transportation provided in Embodiment 1 of this application; Figure 2 This is a schematic diagram of the structure of the computer device provided in Embodiment 3 of this application. Detailed Implementation

[0026] Some embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0027] As described in the background section, existing capacity scheduling solutions for on-demand transportation scenarios generally suffer from technical defects when dealing with sudden reductions in the loading area, such as a single driver selection dimension, a lack of personalized route recommendations, resource conflicts caused by competition for slots when multiple drivers are switched concurrently, a lack of atomicity guarantee between the cancellation of the original route and the confirmation of the new route during the switching process, and a lack of automated replacement processing after a candidate driver refuses. Specifically, existing dispatching schemes struggle to accurately select the most suitable driver group and its waiting list from registered drivers when sudden capacity reduction events occur, taking into account multiple factors such as loading status, location proximity, and registration time. Regarding route recommendation, they fail to conduct personalized matching assessments based on drivers' historical transport data and actual route demands, resulting in insufficient route and driver suitability. In batch replacement scenarios, multiple available route slots may be contested simultaneously, leading to frequent resource conflicts due to the lack of a pre-locking mechanism. Furthermore, canceling registration for the original route and confirming registration for the new route involve multiple data operations, lacking distributed transaction coordination guarantees, easily resulting in data inconsistencies where some succeed and some fail. When a candidate driver refuses or times out, there is no closed-loop mechanism for automatic sequential replacement from the waiting list, making the overall replacement efficiency insufficient for practical application needs. These combined deficiencies severely restrict the automation level, processing efficiency, and data reliability of emergency response to sudden capacity reduction events in pre-booked transportation scenarios.

[0028] To address one or more of the aforementioned issues, this application provides a method and system for intelligent driver and route swapping in the event of a sudden reduction in pre-booked transportation capacity. By responding to a sudden reduction in capacity at the loading point and triggering a swapping process, and constructing a multi-dimensional weighted scoring mechanism that includes at least loading status, distance from the loading point, and registration time, registered but unloaded drivers are accurately ranked. The top N drivers are divided into a main candidate queue, and the rest are divided into multi-level waiting queues according to a preset ratio, forming a priority replacement chain, thus achieving scientific screening and orderly replacement of candidate drivers. Based on this, a comprehensive matching degree is calculated for each candidate driver based on historical transport data and currently available registration routes, generating a personalized recommendation list. Simultaneously, a preset number of available registration route slots at the top of this list are temporarily allocated. The system locks the recommended routes to ensure they are available to drivers within the decision-making timeframe and are not preempted by others. When a driver accepts the change and selects a route, a distributed transaction coordinator is activated to atomically cancel the original route registration and confirm the new route registration, ensuring strong consistency of data operations during the change process. When a driver refuses, the timeout expires, or the lock expires, all locked slots are automatically released, and the next driver in the waiting queue is selected according to the replacement priority link and executed repeatedly until the cumulative number of successful changes reaches N. This constructs a complete closed loop from event triggering, precise screening, personalized matching, slot locking, decision monitoring, transaction protection to automatic replacement. Therefore, this application significantly improves the automation level, matching accuracy, and overall processing efficiency of batch driver and route swapping in sudden capacity reduction scenarios. It effectively avoids quota conflicts and resource competition caused by multiple drivers competing for routes concurrently, eliminates the problem of inconsistency between capacity status and quota data due to partial operation failures, and ensures the complete achievement of swapping goals without manual intervention through a replacement mechanism. While ensuring strong data consistency, it greatly reduces the workload of dispatchers. It can be widely applied to emergency dispatching of sudden capacity fluctuations, optimization of capacity resource allocation, and intelligent transportation management in various on-demand transportation scenarios, providing reliable technical support for the intelligent upgrading of logistics transportation dispatching systems.

[0029] The solution of this application will now be described in detail with reference to the accompanying drawings and various embodiments.

[0030] Example 1 Figure 1This is a flowchart of the intelligent driver and route switching method for sudden reductions in scheduled transportation provided in Embodiment 1 of this application. This method is applicable to various logistics and transportation application scenarios, such as express delivery, cold chain logistics, hazardous materials transportation, pharmaceutical logistics, bulk commodity transportation, and urban distribution. Under different business scenarios, the system can flexibly configure differentiated multi-dimensional weighted scoring parameters, comprehensive matching degree weight coefficients, and waitlist division ratios according to the characteristics of the transported goods and management requirements. This provides logistics companies, fleet managers, capacity dispatch centers, and drivers with accurate emergency response to sudden reduction events and intelligent driver route switching services. It meets the differentiated needs of various transportation scenarios for switching response speed, driver selection accuracy, route matching personalization, and data consistency, and has broad industry applicability and significant socio-economic benefits.

[0031] Reference Figure 1 As shown, the method includes the following steps: S100: In response to a sudden reduction in transport capacity at the loading site, obtain the target route and the number N of drivers that need to be replaced.

[0032] The "sudden reduction in loading capacity" event refers to a situation in a pre-booked transportation scenario where, due to temporary adjustments in cargo volume, changes in storage capacity, malfunctions of loading and unloading equipment, delays in the upstream supply chain, or other unforeseen factors, the actual available transportation capacity at a loading location suddenly decreases relative to the pre-booked demand. This event is the triggering condition for the driver and route intelligent switching method described in this application.

[0033] In practical applications, the occurrence of a sudden reduction in capacity can be determined by monitoring the reserved capacity data of each loading point in real time. When a sudden reduction in capacity is triggered, the target route involved in the event and the number of drivers N that need to be replaced are first obtained. The target route refers to the transportation route corresponding to the loading point where the sudden reduction in capacity occurs, and it includes route attribute information such as loading point identifier, unloading point identifier, route mileage, and planned transportation time. The number of drivers N that need to be replaced is the number of drivers who are surplus due to the reduction in capacity at that loading point.

[0034] Therefore, this step, by establishing a real-time monitoring and automatic triggering mechanism for sudden capacity reduction events in the reservation transportation scenario, enables the rapid initiation of the replacement process. It provides accurate event information, target route information, and the number of drivers to be replaced for subsequent steps, ensuring that the entire replacement method can accurately respond to emergencies and laying a data foundation for efficient emergency handling of sudden capacity reduction events in the reservation transportation scenario.

[0035] S200: Based on a multi-dimensional weighted score that includes at least shipment status, distance from loading point, and registration time, the registered but unloaded drivers for the target route are prioritized. The top N drivers are assigned to the main candidate queue as candidate drivers, and the remaining drivers are assigned to at least one level of the waiting queue according to a preset ratio. The waiting queues at each level form a priority replacement link.

[0036] Among them, "registered but not loaded drivers" refers to drivers who successfully registered for the target route before the sudden reduction in capacity occurred, but have not yet started their transportation tasks (i.e., they have not completed loading operations or the transportation operation has not yet started). This group represents the potential group facing excess capacity and needing to be reassigned to other routes in this sudden reduction in capacity event.

[0037] In this embodiment of the application, in order to accurately select the most suitable candidate drivers and their backup sequence from the aforementioned registered but unloaded drivers, a weighted scoring mechanism was constructed that includes at least three dimensions: loading status, distance from loading location, and registration time. Specifically: 1. Loading Status: This reflects the driver's current progress on the target route and includes at least the following status levels: Not yet arrived at the loading point, arrived at the loading point and waiting to load, loading in progress, and loading completed and waiting to depart. Different loading statuses correspond to different swap priorities. Generally speaking, the earlier the progress (e.g., not yet arrived at the loading point), the lower the cost of swapping and the higher the priority score; the later the progress (e.g., loading completed), the higher the cost of swapping and the lower the priority score.

[0038] 2. Distance to the loading point reflects the spatial proximity between the driver's current location and the loading point. This distance can be calculated based on real-time location data from the driver's terminal device and the geographical coordinates of the loading point. Optionally, it can also be further combined with real-time traffic information to calculate the dynamic driving distance or estimated arrival time. Generally speaking, drivers closer to the loading point suffer less empty-running loss after canceling their current route registration and can switch to other routes more quickly, thus receiving a higher priority score; drivers farther from the loading point receive a correspondingly lower priority score.

[0039] 3. Registration time reflects the order in which drivers register for the target route. The earlier the registration time, the stronger the driver's willingness to participate in the route and the more certain the plan is. Changing the driver may cause greater disruption to the plan. Therefore, under the same conditions, priority should be given to protecting drivers who registered earlier from being changed. That is, the later the driver registers, the higher the priority score for changing the route; the earlier the driver registers, the lower the priority score for changing the route.

[0040] The scores for each of the three dimensions mentioned above can be set with different scoring ranges and rules according to actual business needs. In actual calculations, the scores of the three dimensions can be weighted and summed to obtain the comprehensive score S for each registered but unloaded driver. The calculation formula is as follows: S = α × A + β × D + γ × T Where A represents the shipment status score, D represents the distance from the loading point score, T represents the registration time score, and α, β, and γ are the corresponding weight coefficients, with α + β + γ = 1. The specific values ​​of α, β, and γ can be flexibly configured according to the importance of the three dimensions in different business scenarios. For example, in high-time-sensitivity scenarios such as cold chain logistics, the weight of distance from the loading point (β) can be appropriately increased, while in scenarios with extremely tight transportation capacity, the weight of shipment status (α) can be appropriately increased.

[0041] After calculating the overall score of each registered but unloaded driver, all registered but unloaded drivers are prioritized according to their scores from highest to lowest. The higher the score, the higher the ranking, indicating that the driver is more suitable for being replaced.

[0042] Subsequently, queues were divided based on the ranking results. Specifically, the top N drivers in the ranking results were selected as candidate drivers and placed into the main candidate queue. The N drivers in the main candidate queue constituted the first group of drivers recommended for route changes in this sudden reduction event. They received route recommendations and changes in order of their comprehensive scores from highest to lowest.

[0043] All remaining drivers ranked after N are assigned to at least one level of waiting queues according to a preset ratio. This preset ratio can be pre-set by the system based on actual business needs; for example, the first waiting queue can be set to carry 50% of the remaining drivers, the second waiting queue 30%, and the third waiting queue 20%. The order of the waiting queues at each level forms a priority replacement chain: when a candidate driver in the main waiting queue refuses to be replaced, fails to process the request within the time limit, or cannot be replaced for other reasons, the next-ranked driver is selected from the first waiting queue according to priority. If all drivers in the first waiting queue have been replaced but the cumulative successful replacement count N has not been reached, then a driver is selected from the second waiting queue; and so on, until all waiting queues are exhausted or the cumulative successful replacement count N is reached.

[0044] Through the aforementioned multi-dimensional weighted scoring mechanism, this application can comprehensively consider multiple factors such as the driver's real-time loading status, spatial location, and registration time, avoiding the unfairness or inefficiency caused by relying on a single dimension for screening. Simultaneously, by dividing the waiting list drivers into multi-level waiting queues according to a preset ratio and forming a priority chain for replacement, an orderly replacement relationship is established between candidate drivers and waiting list drivers. When a candidate driver refuses or exceeds the time limit, a new candidate driver can be automatically and orderly added from the waiting queue without re-sorting and screening all drivers, effectively reducing computational overhead and improving the overall execution efficiency of the replacement process.

[0045] S300: According to the priority order of the candidate drivers, for each candidate driver, based on historical transportation data and currently available registration routes, calculate the comprehensive matching degree between each candidate driver and each currently available registration route, generate a list of alternative routes, and temporarily lock the number of available registration routes ranked at the top of the list.

[0046] The priority order of candidate drivers refers to the processing order determined by the comprehensive scores of the N candidate drivers in the main candidate queue, ranked from highest to lowest, after being sorted by multi-dimensional weighted scores in step S200. Route recommendations and reassignments are performed on each candidate driver in this order, with higher-scoring candidates being processed first. This ensures that the driver with the highest reassignment suitability has priority in route selection and maintains the orderly processing order in subsequent replacement processes.

[0047] The core of this step is to select the most suitable routes for the candidate driver from the currently available registration routes and generate a personalized recommendation list. Specifically, based on the candidate driver's historical transport data and the currently available registration routes, the overall matching degree between the candidate driver and each currently available registration route is calculated. Historical transport data includes, but is not limited to: the number of trips the driver has taken on each route (or similar routes) within a preset historical time period, on-time transport rate, historical average transport time, historical transport mileage, transport anomaly records (such as delays, cargo damage, cancellations, etc.), driver ratings and evaluation data, etc. Currently available registration routes refer to the set of transport routes that still have available registration slots at the current time and are not locked or occupied. It should be noted that the currently available registration routes do not include the target routes that have experienced a sudden reduction in capacity, because the target routes have already experienced a reduction in capacity and do not need to be recommended to drivers for registration.

[0048] Based on the calculated overall matching degree, the matching results between the current candidate driver and all available registration routes are sorted from highest to lowest. A preset number of routes with the highest matching degree are selected to generate a personalized alternative route recommendation list for the candidate driver. The preset number can be pre-set according to actual business needs (e.g., 3 or 5 routes). Its significance is twofold: firstly, to provide drivers with multiple alternative routes, increasing the likelihood of a successful change; and secondly, to avoid overburdening drivers with decision-making burdens and prolonging decision-making time by recommending too many routes.

[0049] After generating the recommendation list, the available registration slots for the top-ranked routes in the list are temporarily locked. Temporary locking means that for each route in the recommendation list, a corresponding number (usually one) of its available registration slots are temporarily reserved and allocated to the current candidate driver. This gives them exclusive registration rights for these routes within the decision-making timeframe, ensuring that the recommended route slots seen by the current candidate driver are truly available within the decision-making timeframe and avoiding slot contention and resource conflicts caused by multiple drivers processing concurrently.

[0050] Through the detailed calculation of the comprehensive matching degree and the temporary quota locking mechanism, this application embodiment can generate a personalized recommended route list for each candidate driver that is highly matched with their personal ability characteristics, vehicle conditions and transportation history, which significantly improves the accuracy of route recommendation and drivers' willingness to accept it; at the same time, by temporarily locking the route quotas in the recommended list before the notification is sent, the resource conflict problem in the multi-driver concurrent scenario is effectively solved, ensuring the reliability and fairness of the replacement process, and laying a solid data foundation for subsequent notification push and decision response.

[0051] S400: Send a change notification containing the recommendation list and decision time limit to the currently processed candidate driver, and listen to its decision response.

[0052] Here, the currently processed candidate driver refers to the candidate driver being processed in step S300 according to their priority order. Since the main candidate queue typically contains N candidate drivers, they are processed sequentially from highest to lowest priority, rather than in batches or in parallel. Therefore, it is necessary to clearly define the target driver being processed to ensure accurate notification targeting, clear allocation of locked slots, and accurate transitions in subsequent replacement processes. This step is executed after step S300 completes the generation of the personalized recommendation list and temporary slot locking for that candidate driver.

[0053] Sending a replacement notification refers to sending a replacement notification to the terminal device of the currently processed candidate driver (including but not limited to smartphone APP, vehicle terminal, SMS gateway, WeChat mini program, etc.).

[0054] In some embodiments, the replacement notice includes, but is not limited to, the following: 1. The recommended list, generated in step S300, contains a preset number of available routes sorted from highest to lowest overall match rate. For each route in the recommended list, the notification may also include: basic route information (such as loading and unloading locations, mileage, and estimated transit time), the driver's overall match rate score for the route (optionally displaying match rate levels such as "highly matched," "moderately matched," and "generally matched"), the remaining slots for the route, and the route's transportation requirements (such as vehicle type restrictions and time requirements). By providing sufficient route information, drivers can make informed and reasonable switching decisions.

[0055] 2. Decision time limit refers to the time limit set for the current candidate driver to confirm their selection of a route from the recommended list. This decision time limit corresponds to the validity period of the temporary lock on each route slot in the recommended list in step S300; that is, the validity period of the lock token is the decision time limit. The length of the decision time limit can be preset according to business needs, for example, it can be set to 15 minutes, 30 minutes, or 60 minutes. The setting of the decision time limit takes into account the balance between the time required for the driver to make a reasonable decision and the overall efficiency of the system's switching: if the time limit is too short, the driver may not have enough time to respond; if the time limit is too long, the route slots will be occupied for a long time, reducing the overall switching efficiency.

[0056] 3. Decision-making operation guide, which guides drivers on how to select and confirm routes in the recommended list on their terminal devices, including accepting changes and selecting a route, refusing changes, and prompts that failure to process within the time limit will result in the automatic release of the recommended route slot.

[0057] Optionally, the changeover notice may also include background information on the sudden reduction in the target route, so that drivers can understand the reasons and necessity for the changeover, thereby increasing their understanding of the changeover process and their willingness to cooperate.

[0058] After the replacement notification is sent, the system enters a decision monitoring state, monitoring the candidate driver's decision response to the notification in real time. Monitoring methods include, but are not limited to: maintaining real-time communication with the driver's terminal via long connections, message queues, WebSockets, etc., to receive decision instructions submitted by the driver; or periodically querying decision records in the decision data storage via polling. The system continues to monitor within the decision time limit until a clear decision response is received or the decision time limit expires.

[0059] Specifically, the decision response of the system monitoring includes the following scenarios: 1. Accepting the change and selecting a route indicates that after reviewing the recommendation list, the driver accepts the route change and selects one of the available routes from the list as their new target transportation route. In this case, the driver's decision includes an "Accept" flag and the route identifier of the selected route. After receiving this decision, the system proceeds to the transaction processing flow in step S500.

[0060] It should be noted that drivers can only select available routes from the recommended list, not routes outside the recommended list. This is because routes outside the recommended list may already be reserved by other drivers, full, or have a low match rate with drivers. Allowing drivers to choose routes outside the recommended list would undermine the fairness of the reservation mechanism and the orderly allocation of resources.

[0061] 2. Refusal to Change: This indicates that the driver, after reviewing the recommended routes, explicitly refuses to change routes. In this case, the driver's decision includes a "Refuse" flag. Reasons for refusal may include: the driver is dissatisfied with all routes in the recommended routes, the driver cannot accept the change due to personal reasons (such as having other subsequent transportation plans arranged), or the driver believes the compensation for the change is insufficient. After receiving the refusal decision, the system proceeds to the release lock and replacement processing flow in step S500.

[0062] 3. "Not processed" or "No response after timeout" indicates that the driver did not take any effective action regarding the swap notification within the decision-making time limit, including neither accepting nor rejecting it. This may be due to the driver not checking the notification in time, the terminal device being offline, the driver being unable to operate while driving, or other reasons. In this case, the system determines "Not processed" or "Timeout" when the decision-making time limit expires, and then proceeds to the release lock and replacement processing procedure in step S500.

[0063] Through the precise push of the aforementioned swap notification and the real-time monitoring of the decision response, this embodiment of the application achieves efficient interaction between the system and the driver, enabling the driver to make swap decisions autonomously with full knowledge. It balances the automated advancement of the swap process with respect for the individual wishes of the driver. At the same time, through clear decision time limits and monitoring mechanisms, it ensures that the swap process will not be blocked for a long time due to waiting for a driver's decision, thus providing a reliable guarantee for the efficient advancement of the swap process.

[0064] S500: If, within the validity period of the temporary lock, a decision is received that the candidate driver accepts the change and selects any available registration route in the recommended list, then the distributed transaction coordinator is started to atomically execute the cancellation of the original route registration and the confirmation of the new route registration, and releases all locked slots of the candidate driver after the transaction is committed; if a decision to refuse the change is received, is not processed temporarily, or expires, or the lock validity period expires, then all locked slots of the candidate driver are released, and the next-ranked driver is selected from the waiting queue as a new candidate driver according to the supplementary priority link, and the comprehensive matching degree calculation, temporary lock of slots and replacement notification push are returned to be executed until the cumulative number of successfully replaced drivers reaches N.

[0065] This step is the decision-making and cyclical replacement stage of the driver and route intelligent switching method. It follows the candidate driver decision response monitored in step S400 and performs switching transaction submission or lock release and replacement processing according to the decision result.

[0066] When the decision is received within the temporary lock period that the current candidate driver accepts the change and selects any available route from the recommended list, the distributed transaction coordinator is activated to atomically execute the cancellation of the original route registration and the confirmation of the new route registration. The distributed transaction coordinator is a coordination component used to ensure that multiple data operations in cross-data source and cross-service call scenarios either all succeed or all fail. Since in the actual application scenario of this application, the original route registration data and the new route registration data may be stored in different database tables, different data shards, or even different microservices (e.g., the registration service and the route management service are independent of each other), a distributed transaction mechanism is needed to guarantee the atomicity and consistency of data operations.

[0067] After the global transaction is successfully committed, all locked slots for the candidate driver are released. "All locked slots" refers to all available route slots temporarily locked for the candidate driver during step S300, not just the route the driver ultimately selected. Since the driver has already selected a specific route and confirmed the new route registration, other unselected route slots in their recommendation list no longer need to be reserved for them and should be released for other candidate drivers or subsequent replacement drivers. The specific operation for releasing locked slots includes: deleting all lock tokens corresponding to the candidate driver from the distributed cache, restoring these route slots to an available state, allowing other drivers to register for or lock them.

[0068] When the system receives a decision to refuse replacement from the current candidate driver, determines that the driver will not be processed for the time being and the timeout has expired, or discovers that the temporary lock validity period set in step S300 has expired, the system executes the lock release and replacement process as follows: First, release all locked slots for the candidate driver, restoring all slots on the recommended routes to an available state where they can be locked or registered by other drivers. This release operation serves both as a one-time cleanup and reclamation of temporarily locked resources, preventing slots from being occupied ineffectively for extended periods and reducing the efficiency of global swapping, and as a way to free up resource space for the generation of subsequent replacement driver recommendation lists and slot locking.

[0069] Secondly, the next-priority driver is selected according to the replacement priority link. After the locked slots are released, the next-priority driver is selected from the waiting queues at each level as a new candidate driver according to the replacement priority link established in step S200.

[0070] Finally, after selecting a new candidate driver, the process returns to step S300 (comprehensive matching calculation, recommendation list generation, and temporary quota locking) and the subsequent step S400 (notification push and decision monitoring). This involves re-personalizing route matching recommendations, quota locking, and notification pushes for the newly added candidate driver. The reason for this recalculation is that the status of currently available routes (such as remaining quotas, capacity demand, and road conditions) may have changed during the time period handled by the previous candidate driver, and the new driver's historical transport data is completely different from the previous driver. Therefore, it is necessary to recalculate the matching degree for the new driver and generate their own personalized recommendation list.

[0071] The above-described replacement cycle is repeated until the cumulative number of successfully replaced drivers reaches N. At this point, the entire replacement process terminates, indicating that all N drivers on the target route requiring replacement due to sudden capacity reduction have been replaced. If the waiting list is empty during the cycle (i.e., all waiting drivers have been replaced), but the cumulative number of successfully replaced drivers has not yet reached N, a manual intervention warning can be triggered, allowing dispatchers to manually address the remaining excess capacity.

[0072] In some embodiments, calculating the overall matching degree between each candidate driver and each currently available registration route based on historical transport data and currently available registration routes includes: The familiarity with historical routes is determined based on the number of times the candidate drivers have carried passengers on the available registration routes and their on-time rate within a preset historical time period. The vehicle type suitability is determined based on the degree of matching between the candidate driver's vehicle type and the vehicle type required for the available registration routes; The timeliness satisfaction is determined based on the degree of deviation between the candidate driver’s historical average transport time and the timeliness requirements specified for the available registration routes. The current load balance is determined based on the ratio of the number of currently registered drivers to the rated capacity demand for the available registration routes; The overall matching degree is obtained by weighting the familiarity with the historical route, the vehicle model compatibility, the timeliness satisfaction, and the current load balancing degree.

[0073] The historical route familiarity metric measures a candidate driver's familiarity with a given available route. It is determined by the number of trips taken and the on-time rate on that route within a preset historical timeframe. This preset historical timeframe can be pre-set based on actual business needs, such as the past 30 days, 90 days, or 180 days. The number of trips taken reflects the driver's accumulated driving experience on that route. A higher number of trips indicates greater familiarity with the route's road conditions, traffic patterns, roadside service facilities (such as gas stations and rest areas), loading and unloading procedures, and potential risks (such as congested or accident-prone sections), enabling the driver to handle various situations more calmly and efficiently during actual transport. The on-time rate reflects the stability of the driver's transport efficiency on that route. A higher on-time rate indicates that the driver can reliably complete transport tasks within the stipulated time limit, demonstrating higher reliability. The scoring rules can be designed so that drivers with a high number of trips and a high on-time rate receive the highest historical route familiarity score; drivers with fewer trips or a low on-time rate receive a correspondingly lower score. By combining the number of trips and on-time performance in the evaluation, both the driver's route experience and their transportation quality are considered, avoiding the situation where a high score is given simply because of a high number of trips but a low on-time rate. If a candidate driver has no trip records for a certain available route within a preset historical period, their historical route familiarity score for that route will be zero or the lowest base score. Vehicle type compatibility measures the degree of match between a candidate driver's vehicle type and the vehicle type required for the available registration routes. In the transportation business, different routes often have different hardware requirements for transport vehicles. For example, some routes require transport vehicles to be box trucks to ensure the airtightness and safety of goods; some routes involve cold chain transportation, requiring vehicles to be equipped with refrigeration units; some routes pass through weight-restricted bridges or height-restricted sections, with strict upper and lower limits on the total weight or total height of the vehicles; some routes require vehicles with specific cargo box volumes due to the large volume of goods; and some routes may only allow vehicles with specific emission standards to pass in order to meet environmental protection requirements. If a candidate driver's vehicle type is exactly the same as or fully meets the requirements of an available route, the vehicle type suitability score is the highest. If there are some differences between the candidate driver's vehicle type and the route's required vehicle type, but these differences do not affect basic transportation needs, the suitability score is medium. If there is a fundamental mismatch between the candidate driver's vehicle type and the route's required vehicle type (e.g., a refrigerated truck cannot handle the special loading and unloading requirements of ordinary bulk cargo transportation, or an ordinary truck cannot meet the temperature control requirements of cold chain transportation), then the candidate driver is not qualified to match that route, and the vehicle type suitability score for that route is zero. By setting a vehicle type suitability dimension, candidate drivers whose vehicle hardware conditions meet the route requirements can be effectively screened, avoiding ineffective replacements where drivers "have the willingness but cannot execute" due to recommended routes with mismatched vehicle types, thus improving the feasibility of the recommendation results and the actual conversion rate.

[0074] Timeliness satisfaction measures the deviation between a candidate driver's historical average transport time and the timeliness requirements stipulated for the available routes, assessing the driver's ability to complete the transport task within the specified timeframe. Each available route has corresponding transport timeliness requirements, such as the maximum permissible transport time from loading to unloading (e.g., 8 hours, 12 hours, 24 hours), which may be determined based on factors such as route mileage, road conditions, cargo preservation requirements, or customer time constraints. Based on the candidate driver's historical transport data, their historical average transport time within a preset historical time period is calculated. If a candidate driver's historical average transport time is less than or equal to the timeliness requirement of an available route, it indicates that the driver has sufficient time leeway and can reliably complete transport within the specified time limit, resulting in the highest timeliness satisfaction score. If the historical average transport time is greater than the timeliness requirement but by a small margin (e.g., less than 10%), it indicates that the driver may be slightly late under normal circumstances, but is still likely to meet the timeliness requirement under good road conditions, resulting in a medium timeliness satisfaction score. If the historical average transport time is significantly greater than the timeliness requirement (e.g., more than 20%), it indicates that the driver will have difficulty meeting the timeliness constraints on that route, resulting in a low timeliness satisfaction score or disqualification from matching. By setting a timeliness satisfaction dimension, the system can prioritize recommending time-sensitive routes to drivers with high transport efficiency and a good historical punctuality rate, ensuring the quality of transport services while reducing the risk of customer complaints and economic losses due to timeliness breaches.

[0075] The current load balancing level measures the current capacity saturation of each available registration route. It is determined based on the ratio of the number of currently registered drivers to the rated capacity demand for each available registration route. For a given available registration route, the rated capacity demand is the upper limit of the number of drivers that the route can effectively absorb per unit of time, determined by factors such as the route's total freight volume, transport frequency, and vehicle loading capacity. The closer the number of currently registered drivers is to or exceeds the rated capacity demand, the more saturated or even surplus the route is. Directing more drivers to this route could lead to uneven distribution of capacity resources and a new round of overcapacity problems. Conversely, if the number of currently registered drivers is significantly lower than the rated capacity demand, it indicates that the route has considerable capacity absorption capacity and is suitable for accepting drivers transferred from the target route.

[0076] Specifically, the current load balancing can be measured by the load factor R, calculated using the following formula: R = Number of currently registered drivers / Rated capacity demand × 100% When R is below the first load threshold (e.g., R < 60%), it indicates strong demand and ample availability for the route, resulting in the highest load balance score. When R is between the first and second load thresholds (e.g., 60% ≤ R ≤ 85%), it indicates relatively balanced capacity for the route, with a moderate load balance score. When R is above the second load threshold (e.g., R > 85%), it indicates the route is approaching saturation, resulting in a lower load balance score, and drivers will be prioritized to avoid being recommended to this route. By incorporating the current load balance into the matching calculation, the capacity load of each available registration route can be dynamically perceived and intelligently allocated from a global perspective. This prioritizes guiding candidate drivers to routes where capacity demand is not yet saturated, achieving a balanced distribution of capacity resources throughout the transportation network and preventing new capacity surplus problems caused by local overheating.

[0077] After calculating the scores for the four dimensions mentioned above, the scores for historical route familiarity, vehicle type suitability, timeliness satisfaction, and current load balancing are weighted and summed according to their respective weight coefficients to obtain the comprehensive matching score between the candidate driver and a certain available registration route. The weight coefficients for each dimension can be flexibly configured according to the actual needs of different business scenarios. For example, in conventional logistics scenarios, historical route familiarity and vehicle type suitability can be given higher weights to reflect the importance of experience matching and hardware matching; in high-time-sensitivity transportation scenarios such as fresh food cold chain, the weight of timeliness satisfaction can be appropriately increased to prioritize ensuring the reliability of transportation timeliness; in scenarios with abundant transportation resources, the weight of current load balancing can be appropriately increased to strengthen the optimization goal of global transportation capacity balance. Through the above-mentioned flexibly configurable multi-dimensional weighted evaluation mechanism, this application embodiment can not only realize personalized route recommendations for each candidate driver, but also achieve overall optimization of transportation capacity scheduling at the global level, significantly improving the accuracy of recommendation results and practical application effects.

[0078] In some embodiments, calculating the overall matching degree between each candidate driver and each currently available registration route based on historical transport data and currently available registration routes further includes: The system obtains real-time dynamic change information for each available registration route, including real-time changes in the remaining slots for the route, dynamic adjustments to the route timeliness requirements, and real-time updates on road congestion levels. In response to the change in the dynamic information exceeding a preset threshold, the overall matching degree between the candidate driver and the relevant available registration routes is recalculated, and the alternative route recommendation list is updated.

[0079] In pre-booked transportation scenarios, the status of available routes is not static but dynamically changes over time and with business progress. If route status information is only obtained once during the initial calculation of the overall matching degree, the generated list of alternative routes may deviate from the actual situation after a period of time, resulting in inaccurate route information recommended to candidate drivers (e.g., the slots for a certain route in the recommendation list have already been filled by other drivers when the driver makes the decision, the route's timeliness requirements tighten due to changes in freight volume, or road congestion causes the actual transportation time to exceed expectations). To address this, this application's embodiment further introduces a real-time update mechanism on top of the basic matching degree calculation to ensure that the recommendation list remains consistent with the actual route status throughout the entire switching process.

[0080] Specifically, the real-time update mechanism includes the following: The system continuously monitors and acquires dynamic changes in all available registration routes during operation, rather than performing data collection only once during the matching calculation in step S300. The dynamic change information includes at least the following three categories: 1. Real-time changes in remaining slots for each route. The remaining slots for each available route are not fixed. As other drivers register, cancel, or lock their routes, the remaining slots will increase or decrease in real time. For example, during the time a candidate driver receives the recommendation list and makes a decision, a route in the recommendation list may be locked or officially registered by other drivers in the dispatch process, causing its remaining slots to decrease or even reach zero; or, a route may release more available slots due to a temporary increase in capacity demand. The system dynamically obtains the latest remaining slot data for each available route by synchronizing with the real-time data of the registration service module.

[0081] 2. Dynamic Adjustment of Route Delivery Time Requirements. Route delivery time requirements are not static and may be dynamically adjusted due to changes in cargo type (e.g., temporarily changing to perishable goods, increasing delivery time requirements), changes in customer needs (e.g., downstream factories requiring earlier delivery), weather, or traffic control, and other external factors. The system obtains real-time updates on changes in delivery time requirements for each route by connecting with the order management module, customer relationship management module, and external information sources (e.g., weather forecasts, traffic control notices).

[0082] 3. Real-time updates of traffic congestion levels. Traffic conditions are one of the key dynamic factors affecting transportation timeliness. A route may have good traffic and smooth flow during the matching calculation, but during the driver's decision-making process, factors such as traffic accidents, temporary construction, severe weather, or rush hour may cause the congestion level to increase and the travel time to be extended. Conversely, routes that were originally congested may become smooth again after accidents are cleared or traffic control is lifted. The system connects with third-party map service providers (such as Gaode Maps, Baidu Maps, etc.) or traffic information service platforms through data interfaces to obtain the latest traffic congestion levels and estimated travel times for each available registration route in real time.

[0083] The methods for obtaining the aforementioned dynamic change information include, but are not limited to: subscribing to change events of relevant data sources (such as registration status change events, order information change events) through message queues, periodically pulling the latest status data through timed polling, or receiving real-time traffic update data pushed by third-party services through long-connection methods such as WebSocket.

[0084] After obtaining the aforementioned dynamic change information, recalculation is not triggered for every minor change. Instead, the current change is compared with a preset threshold, and recalculation is only triggered when the change exceeds the preset threshold. Different judgment criteria can be set for different change types. Regarding the real-time changes in the remaining slots for a route, when the number of remaining slots for an available registration route decreases by more than a first preset threshold (e.g., a decrease of ≥1 slot indicates that the route's slots have been occupied by other drivers), it indicates that the availability of the route has substantially changed. If the route exists in a candidate driver's recommendation list, its recommendation value needs to be reassessed. If the remaining slots are zero, the route should be removed from the recommendation list; if the remaining slots have decreased but are still available, they can be retained, but the slot display information needs to be updated.

[0085] Regarding the dynamic adjustment of route timeliness requirements, when the timeliness requirements of an available registration route are tightened by more than the second preset threshold (such as the maximum allowable transportation time being shortened by more than 10% or more than 1 hour), it indicates that the route places higher demands on the transportation efficiency of drivers. Drivers who previously had a high degree of matching may no longer meet the timeliness constraints under the new timeliness requirements, and it is necessary to recalculate the timeliness satisfaction and overall matching degree of relevant drivers with the route.

[0086] For real-time updates of traffic congestion levels, when the congestion level of an available registration route rises above the third preset threshold (e.g., from "smooth" to "congested" or from "lightly congested" to "severely congested"), it indicates that the actual traffic conditions of the route have deteriorated significantly. The estimated transport time for drivers on this route will increase significantly, and it is necessary to recalculate the timeliness satisfaction and overall matching degree, and feed the updated matching degree back into the ranking of the recommendation list.

[0087] When the change in any of the aforementioned types of dynamic information exceeds the corresponding preset threshold, a recalculation process is triggered. The object of the recalculation is the "comprehensive matching degree between the candidate driver and the relevant available registration routes," where "relevant available registration routes" refers to those available registration routes involved in the dynamic change information, not all available registration routes. For example, if only the congestion level of route A changes, only the comprehensive matching degree between the current candidate driver and route A is recalculated; there is no need to recalculate the matching degree between the driver and other routes such as route B and route C, thereby controlling computational overhead and improving response efficiency.

[0088] After recalculating the updated overall match rate, the list of alternative routes for current candidate drivers is updated based on the new match rate score. This includes: adjusting the order of routes in the recommendation list (routes with improved match rate are ranked higher, and routes with decreased match rate are ranked lower); removing routes that are no longer available due to full capacity from the recommendation list; removing routes whose match rate has significantly decreased due to time constraints or changes in road conditions and has fallen below the recommended threshold from the recommendation list; and adding routes with significantly improved match rate due to newly released slots or relaxed time constraints to the recommendation list (if necessary). The updated recommendation list will replace the original recommendation list and will be used to send alternative route notifications to candidate drivers.

[0089] It should be noted that the recalculation and recommendation list update are triggered throughout the entire time window, from the initial generation of the recommendation list in step S300, through the notification and decision-making process in step S400, until step S500 completes the replacement or enters the supplementary stage. If the recommendation list is updated before a candidate driver makes a final decision, the system can choose to immediately push the updated recommendation list back to the driver, or load the latest version when the driver opens the decision-making interface, to ensure that the recommendation information seen by the driver is always up-to-date.

[0090] Through the aforementioned real-time update mechanism, this application embodiment enables the comprehensive matching degree and recommendation list to have dynamic response capabilities. It can automatically adjust according to changes in key parameters such as the remaining quota of routes, time requirements, and road congestion status, effectively avoiding the problem of recommendation failure caused by outdated route status information, ensuring the timeliness, accuracy, and reliability of recommendation information, and improving the acceptance rate of recommended routes by candidate drivers and the overall success rate of the switching process.

[0091] In some embodiments, temporarily locking a preset number of routes ranked high in the recommendation list using available registration slots includes: For each of the top-ranked, pre-defined number of available routes in the recommended list, a unique locking token is generated. The locking token includes a locked route identifier, a locked driver identifier, a locked timestamp, and a validity period. The locking token is stored in a distributed cache, and an expiration time corresponding to the decision time limit is set. During the validity period of the lock token, other drivers' registration or lock requests for the same route will be rejected.

[0092] This application embodiment introduces a distributed locking mechanism based on lock tokens to provide exclusive temporary locking protection for each available registration route slot in the recommendation list. In scenarios with multiple drivers concurrently switching routes, if the route slots recommended to each candidate driver are not pre-locked, the following resource conflict may occur: Candidate driver A receives the recommendation list and is considering whether to choose route R1. During their decision-making period, candidate driver B (or another driver who comes in to fill the vacancy) also receives the recommendation list containing route R1 and completes the registration confirmation first. As a result, when candidate driver A makes their decision and chooses route R1, they find that the slot has already been occupied, causing the switch to fail. Therefore, this application embodiment exclusively locks the route slots in the recommendation list before sending notifications to drivers, ensuring that the slots for the recommended routes are not preempted by other concurrent processes throughout the driver's entire decision-making cycle, thereby ensuring the reliability and fairness of the switch process.

[0093] Specifically, temporary lockouts include the following: First, a unique lock token is generated for each of the top-ranked available routes in the recommended list. The lock token uniquely identifies a single slot locking operation and includes, but is not limited to, the following information fields: Route ID, used to uniquely identify the specific locked route; Driver ID, used to identify which candidate driver has locked the slot, clarifying the ownership of the lock; Timestamp, recording the time the lock occurred, used for tracking the timing of the lock and subsequent auditing; and Validity Period, specifying the validity period of the lock token, i.e., the period during which the slot is exclusively reserved by the current candidate driver. Each recommended route corresponds to a unique lock token, and multiple lock tokens are decoupled from each other and do not affect each other. Even if a lock token for one route is released due to timeout, lock tokens for other routes remain valid, and candidate drivers can still choose from the remaining routes. By generating independent locking tokens for each route, the quota locking status can be managed in a fine-grained manner. Compared with the solution of uniformly locking the entire recommendation list, the design of independent locking tokens greatly improves the flexibility and fineness of lock management, and avoids the extreme situation where the lock failure of a single route affects all recommended routes.

[0094] Secondly, the generated lock tokens are stored in a distributed cache, and the length of the decision-making time limit is used as the expiration time of the lock tokens. For example, if the system sets the decision-making time limit to 30 minutes, then the expiration time (TTL) of the lock token is set to 30 minutes. When 30 minutes have elapsed, the distributed cache will automatically delete the lock token, thus automatically releasing the locked slots. By associating the expiration time of the lock tokens with the decision-making time limit, the timely and automatic reclamation of locked slots can be achieved without additional scheduled tasks or manual intervention, avoiding the problem of permanent slot occupation due to driver non-response, and improving the system's automation level and resource utilization efficiency.

[0095] Finally, during the validity period of the lock token, any registration or lock request for the same route will be rejected. Specifically, when any driver (including other candidate drivers or standby drivers) attempts to register or lock a certain available registration route, the system first checks the distributed cache to see if a valid lock token exists for that route. If a valid lock token exists, it further checks whether the lock driver identifier in the lock token matches the identifier of the currently requesting driver. If they match, it indicates that the lock slot belongs to the currently requesting driver (e.g., the driver viewed the recommendation list multiple times or made duplicate requests during the decision-making process), and the driver is allowed to continue. If they do not match (i.e., the lock token is held by another driver), the system returns a "slot already locked" response to the current requester, rejecting their registration or lock request for that route, until the lock token expires automatically due to timeout or is actively released by the system.

[0096] In some embodiments, the lock tokens can be proactively released in the following two situations: (1) If a candidate driver accepts the change and selects a route, after the global transaction is successfully committed, all lock tokens corresponding to the candidate driver (including the selected route and other unselected recommended routes) can be proactively deleted to release the quota for other drivers; (2) If a candidate driver refuses the change, fails to respond within the timeout period, or the lock validity period expires, all lock tokens corresponding to the candidate driver can also be proactively deleted. It should be noted that the reason for releasing "all" locked quotas rather than just the selected route is that the quotas for multiple routes in the recommended list are temporarily reserved for the candidate driver. When the driver no longer needs to process the request (whether due to acceptance or rejection), the quotas for other unselected routes should be promptly returned to the available quota pool for other drivers to use, avoiding unnecessary resource waste.

[0097] Through the aforementioned distributed caching-based locking token mechanism, this application embodiment achieves temporary exclusive locking of recommended route slots in a lightweight and highly concurrent manner, effectively avoiding slot contention conflicts in multi-driver concurrent scenarios, ensuring the route selection right of candidate drivers within the decision-making time limit, and ensuring the timely release of locked slots and efficient recycling of resources through a dual recycling mechanism of automatic expiration and active release, providing solid technical support for the reliability and fairness of the swap process.

[0098] In some embodiments, the preset quantity is dynamically determined based on the scale of the sudden reduction event, including: When the number of drivers N to be replaced is greater than a first threshold, the preset number is a first value; when N is less than or equal to the first threshold, the preset number is a second value, and the first value is greater than the second value.

[0099] As mentioned earlier, the preset quantity refers to the number of available registration slots temporarily locked from the top-ranked routes in the recommended list of alternative routes generated for the current candidate driver. The setting of this preset quantity directly relates to a balance between two aspects: Firstly, a larger preset quantity gives drivers more alternative route options, increasing the likelihood of a successful switch, but it also means more route slots are temporarily occupied, increasing system resource consumption and waiting time for other drivers on these routes. Secondly, a smaller preset quantity results in lower system resource consumption and higher slot utilization efficiency, but it narrows the driver's choices. If the few recommended routes do not meet the driver's expectations, it may lead to drivers refusing to switch, triggering a replacement process, which in turn reduces overall switching efficiency. Therefore, the preset quantity should not be set to a fixed value, but rather dynamically adjusted according to the scale of sudden reduction events to achieve the optimal balance between switching success rate and resource utilization efficiency.

[0100] Specifically, in this embodiment, the preset quantity is determined based on the number of drivers N to be replaced (i.e., the core indicator of the scale of the sudden reduction event). When the number of drivers N to be replaced is greater than a first threshold, it indicates that the sudden reduction event is large in scale, the number of drivers to be replaced is large, and the overall replacement task is difficult. In this case, more alternative route options should be provided for each candidate driver to maximize the success rate of a single replacement. Therefore, the preset quantity is set to a larger first value. Conversely, when N is less than or equal to the first threshold, it indicates that the event is small in scale and the replacement pressure is relatively low. In this case, there is no need to excessively lock route slots. The preset quantity can be set to a smaller second value to reduce system overhead and improve slot turnover efficiency, wherein the first value is greater than the second value.

[0101] For example, a first threshold can be preset to 10. When the number of drivers N to be replaced is greater than 10, it indicates that the sudden reduction event involves more than 10 drivers needing to be replaced, which is a large-scale dispatching event. Setting the preset number to a larger first value (e.g., 5 routes) means locking the 5 available registration routes with the highest overall matching degree in the recommendation list for each candidate driver, giving drivers ample choice and achieving replacements in one recommendation as much as possible, avoiding a large number of drivers entering the replacement process and prolonging the overall processing time. When the number of drivers N to be replaced is less than or equal to 10, it indicates that the event is small-scale. The system sets the preset number to a smaller second value (e.g., 3 routes), meaning that locking the 3 available registration routes with the highest overall matching degree in the recommendation list for each candidate driver. While ensuring that drivers have basic choice, it reduces the number of locked slots, allowing other route slots to be used by other drivers more quickly, improving the concurrency efficiency of the overall replacement process.

[0102] It should be noted that the specific values ​​of the first threshold, the first value, and the second value mentioned above can be flexibly configured according to the actual situation of the business scenario. For example, in scenarios with abundant transportation resources and many alternative routes, the first and second values ​​can be appropriately increased to fully guarantee the driver's freedom of choice; in scenarios with scarce transportation resources and limited alternative routes, the first and second values ​​can be appropriately decreased to carefully control the occupation of quotas and avoid resource waste caused by excessive locking.

[0103] In some embodiments, the dynamic determination mechanism for the preset quantity can be further refined. For example, multiple threshold ranges can be set to divide the preset quantity into three or more levels: when N is greater than a first threshold, the preset quantity is the first value; when N is between a second threshold and the first threshold (the second threshold is less than the first threshold), the preset quantity is the second value; when N is less than or equal to the second threshold, the preset quantity is the third value, where the first value > the second value > the third value. Through this fine division of multiple levels, the system can more accurately adapt the preset quantity according to the scale gradient of sudden reduction events, achieving a more flexible resource allocation strategy.

[0104] Furthermore, the dynamic determination of the preset number can be linked to the total number of currently available registration routes. If the total number of currently available registration routes is small (e.g., only 5), then even if N is large, the preset number should not exceed the total number of available registration routes. That is, the smaller value between the preset number and the actual total number of available routes should be taken to avoid attempting to lock non-existent route slots and causing anomalies. For example, if the preset number is calculated to be 5 based on N > the first threshold, but the total number of currently available registration routes is only 3, then the actual preset number should be 3, that is, all available registration route slots should be locked.

[0105] Through the aforementioned dynamic determination mechanism, this embodiment of the application can flexibly adjust the number of locked slots in the recommended list according to the scale of the sudden reduction event: in large-scale reduction events, it provides drivers with a wider range of alternative routes, improving the success rate of a single swap and reducing the frequency of replacements; in small-scale events, it appropriately controls the number of locked slots, reducing resource consumption and improving overall swap efficiency. This achieves an adaptive match between the preset number and the event scale, achieving a good dynamic balance between swap success rate and system resource consumption, further optimizing the overall execution efficiency of the swap process.

[0106] In some embodiments, after sending a change notification containing the recommendation list and decision time limit to the currently processed candidate drivers, the method further includes: Within the decision-making time limit, the decision response status of the candidate drivers is monitored at preset time intervals; If no decision response is received within the first half of the decision timeframe, a first reminder notification is sent to the candidate driver. If no decision response is received within the latter half of the decision time limit, a second reminder notification is sent to the candidate driver. The second reminder notification has a higher priority than the first reminder notification, and the second reminder notification includes a reminder of the remaining valid time of the temporary lock. If no decision response is received by the deadline, it is determined that the decision will not be processed or has timed out.

[0107] In real-world swap scenarios, candidate drivers are not always able to check and make a decision promptly after receiving a swap notification. Due to the nature of the transportation industry, drivers may be en route and unable to operate their devices, be too busy with loading and unloading operations to check notifications, have poor network signals and fail to receive notifications in real time, or simply forget to process them due to negligence. If a passive wait for driver response is initiated after sending the notification, and drivers fail to make a decision for the aforementioned reasons, the route slots in the recommended list may be ineffectively occupied within the decision-making time limit, only being released and triggering replacements after the time limit expires. This significantly prolongs the overall swap process and reduces the efficiency of emergency response to sudden capacity reduction events. To address this, this application's embodiment further introduces a tiered, progressive intelligent reminder mechanism after sending the swap notification. By proactively reaching drivers and providing reminders at different times, it improves the driver's decision-making response rate and avoids ineffective waiting due to driver negligence. Specifically, the reminder mechanism includes the following: 1. Monitor the decision response status at preset time intervals.

[0108] After sending a switch notification to the currently processing candidate driver, the decision response status monitoring process is initiated within the decision time limit. The monitoring method is integrated with the decision monitoring mechanism in step S400. Within the decision time limit, it actively queries or passively receives driver decision status change information at preset time intervals (e.g., every 30 seconds, 1 minute, or 2 minutes), continuously tracking whether the driver has viewed the notification and made an acceptance or rejection decision. The preset time interval can be pre-set according to actual business needs, and its value must balance the timeliness of monitoring with the conservation of system resources. Too short a time interval will lead to frequent system queries and increased unnecessary computational overhead; too long a time interval may prevent the system from timely detecting driver timeout risks and delaying the triggering of reminders. For example, the preset time interval can be set to 1 minute. With a decision time limit of 30 minutes, a maximum of 30 status monitoring polls will be performed within the decision time limit.

[0109] 2. If no response is received within the first half of the decision-making timeframe, a first reminder notification will be sent.

[0110] If no valid decision response (including neither acceptance nor rejection) is received from the current candidate driver within the first half of the decision-making timeframe, a first reminder notification is sent to the candidate driver. The "first half of the decision-making timeframe" refers to the time interval from the moment the swap notification is sent to the midpoint of the decision-making timeframe. For example, if the decision-making timeframe is set at 30 minutes, the first 15 minutes constitute the first half; if the decision-making timeframe is set at 60 minutes, the first 30 minutes constitute the first half. If no decision response is detected throughout the entire first half, it indicates that the driver may not have noticed the swap notification or is too busy to handle it. In this case, a first reminder notification is sent to the driver to gently remind them to check the swap notification and make a decision. The first reminder notification can be sent via in-app push notifications, SMS alerts, or WeChat service account messages, focusing on reminding the driver of the pending swap task and guiding them to open their device to view the notification details. The tone and frequency should be relatively gentle to avoid unnecessary interference to drivers who are driving or working.

[0111] 3. If no response is received by the latter half of the decision-making deadline, a second reminder notification will be sent.

[0112] If no decision response is received from the candidate driver after the first reminder notification is sent, and by the latter half of the decision-making timeframe, a second reminder notification will be sent to the candidate driver. The "second half of the decision-making timeframe" refers to the time interval from the midpoint of the decision-making timeframe to its expiration. The second reminder notification has a higher priority than the first reminder notification, specifically in the following ways: Regarding the sending channel, the second reminder notification can use a higher-priority push method, such as telephone voice reminders, strong reminder push notifications, or a combination of SMS and in-app push notifications, to ensure maximum reach to drivers; regarding the content, in addition to basic reminder information about task switching, the second reminder notification can also include a reminder of the remaining valid time after temporary locking, clearly informing drivers of the urgency of the timeframe and the consequences of the upcoming release of slots, enhancing their sense of urgency and willingness to act, and prompting them to make a decision as soon as possible. Compared to the first reminder notification, the second reminder notification significantly improves both reach intensity and information urgency, forming a hierarchical reminder strategy.

[0113] 4. If no response is received by the deadline for making a decision, it is considered a timeout.

[0114] If, after sending the first and second reminder notifications within the decision-making time limit, no decision response is received from the candidate driver by the very last moment of the decision-making time limit, the candidate driver is determined to be either temporarily not processed or has timed out. Upon determining a timeout, following the "temporarily not processed and timed out" branch processing logic in step S500, all locked slots for the candidate driver are released, and the next-ranked driver is selected from the waiting queue as a new candidate driver according to the replacement priority link, thus entering the replacement processing procedure.

[0115] It should be noted that the triggering conditions for both the first and second reminder notifications are based on the premise of "no decision response received," meaning the reminder mechanism only targets drivers who have not taken any action. If the driver has clearly decided to refuse the change within the decision-making time limit, there is no need to send a reminder notification, and the process directly proceeds to the rejection branch of step S500. Similarly, if the driver has decided to accept the change and selected a route, there is also no need for a reminder, and the process directly proceeds to the transaction processing branch of step S500. Furthermore, if the driver has viewed the notification but has not yet made a final decision (e.g., still considering) in the first half of the decision-making time limit, the system can adjust the reminder strategy accordingly. For example, the first reminder notification may use a relatively mild tone to distinguish it from the case where the notification has not been viewed at all, making the reminder mechanism more intelligent and user-friendly.

[0116] Through the aforementioned hierarchical and progressive intelligent reminder mechanism, this embodiment of the application no longer passively waits for the driver's response after sending the replacement notification. Instead, it actively reminds drivers in different time periods and with different priorities, providing timely prompts and a moderate sense of urgency when drivers are negligent or busy. This effectively reduces the ineffective waiting and wasted slots caused by drivers not checking the notification in time, significantly improves the decision response rate and the overall timeliness of the replacement process, and makes the emergency handling of sudden reduction events more efficient and smooth.

[0117] In some embodiments, the step of activating the distributed transaction coordinator and atomically executing the cancellation of the original route registration and the confirmation of the new route registration includes: To start a global transaction by enabling the distributed transaction coordinator, perform the following operations in sequence: First verification operation: Verify whether the candidate driver's registration status on the target route is still valid; The second verification operation is to verify whether the temporary lock-in slots for the available registration routes selected by the candidate drivers are still valid and have not been taken up by other transactions. If both the first verification operation and the second verification operation pass the verification, then cancel the candidate driver's registration on the target route and confirm the candidate driver's registration on the available registration routes, and submit the global transaction; If either the first verification operation or the second verification operation fails, the global transaction is rolled back, all locked slots for the candidate drivers are released, and the next driver is selected according to the supplementary priority link.

[0118] After a driver accepts the change and selects an available route from the recommended list, two core data operations need to be performed: first, cancel the driver's registration record on the target route (i.e., the original route where the sudden reduction in capacity occurred); second, create a new registration confirmation record on the driver's selected available route. These two operations involve different data objects (target route registration data and selected route registration data), which may belong to different database tables, different data shards, or even different microservices (such as registration service, route management service, capacity statistics service, etc.) in a distributed system architecture. If these two operations are executed sequentially using ordinary transaction methods without introducing a distributed transaction coordination mechanism, the following risks of data inconsistency exist: If the original route registration is successfully cancelled but the new route registration fails to be confirmed (e.g., due to network timeout, database write anomalies, etc.), the driver will simultaneously lose the registration eligibility for the target route and the confirmation for the new route registration, resulting in the driver's capacity status being "lost" in the system. This means the driver cannot execute either the original or new route tasks, leading to unnecessary loss of capacity resources. Conversely, if the original route registration fails to be cancelled but the new route registration is successfully confirmed, the driver will have valid registrations for two routes simultaneously. This may lead to duplicate counting in capacity statistics, and the driver can only actually execute one route, resulting in the other route's slot being occupied and resources wasted due to no one actually showing up. Therefore, this application's embodiment introduces a distributed transaction coordinator to manage the two operations within a single global transaction, ensuring that both either succeed or fail completely, fundamentally eliminating data inconsistency.

[0119] Specifically, the execution process of a distributed transaction includes the following: Upon receiving the decision that a candidate driver has accepted the change and selected any available route from the recommended list, the distributed transaction coordinator is immediately activated. The distributed transaction coordinator is a core component of the distributed system, responsible for coordinating operation sequences across multiple data sources and microservices, ensuring these operations satisfy ACID (Atomicity, Consistency, Isolation, Durability) transaction properties. The distributed transaction coordinator first generates a globally unique transaction ID (TXID) to associate and track all operations within the lifecycle of that global transaction. Then, it opens a global transaction context, preparing to execute the subsequent sequence of transaction operations.

[0120] After initiating a global transaction, the distributed transaction coordinator performs the first verification operation to verify whether the candidate driver's registration status on the target route is still valid. This verification is necessary because a considerable amount of time may have passed between the generation of the recommendation list and the locking of slots in step S300, the sending of the replacement notification and waiting for the driver's decision in step S400, and the current moment when the driver makes the acceptance decision. Within this time window, the candidate driver's registration status on the target route may have changed. For example, the driver may have actively or passively cancelled their registration for the target route for other reasons; the driver's loading status may have progressed from "not loaded" to "loading in progress" or even "loading completed," causing them to no longer meet the replacement condition of "registered but not loaded driver"; the target route may have cancelled the current reduction event due to changes in circumstances (such as cargo volume recovery), no longer requiring driver replacement; or the driver's registration record may have been modified by other processes due to system anomalies. If a cancellation request is executed directly without first verifying the validity of the registration status, invalid operations or even erroneous operations may be performed on expired registration records. Specifically, the first verification operation can be performed by querying the registration record status field in the registration database to determine whether the driver's registration record on the target route exists, whether the status is "registered but not loaded" and has not been cancelled, and whether it is still valid. If the verification passes (i.e., the registration status is still valid), the subsequent operations continue; if the verification fails (i.e., the registration status has expired, been cancelled, or has progressed to an irreversible stage of the operation), the first verification operation fails.

[0121] After the first verification operation passes, the distributed transaction coordinator performs a second verification operation to verify whether the temporarily locked slots for the available registration routes selected by the candidate driver are still valid and have not been preempted by other transactions. Similar to the first verification operation, there is also a time window between slot locking and driver decision. Within this time window, the locked status of the selected route slots may have changed. For example, the lock token for the route may be about to expire due to the decision deadline (or may have already expired and been automatically deleted from the cache); the locked slots for the route may be released prematurely by abnormal system processes; most seriously, the slots for the route may be preempted by other concurrent transactions during the current driver's decision-making period. If the new route registration confirmation is executed directly without verifying the validity of the locked slots, slot over-occupancy may occur. That is, when the current driver confirms the registration, there are actually no slots left for the route, resulting in registration confirmation failure, but the cancellation operation of the target route may have already been executed, causing the serious consequence that the driver has no route to travel. Specifically, the second verification operation verifies whether all of the following conditions are met by querying the lock token stored in the distributed cache corresponding to the selected route: the lock token exists and has not expired; the lock route identifier in the lock token matches the route selected by the driver; the lock driver identifier in the lock token matches the currently processed candidate driver; and there are still available slots on the route. If all the above conditions are met, the second verification operation passes; if any condition is not met (such as the lock token has expired, the lock ownership does not match, or there are zero remaining slots), the second verification operation fails.

[0122] If both the first and second verification operations pass, the current state is confirmed to be consistent and operable. The driver's registration on the target route is genuine and valid, and the locked slots for the selected route still belong to the driver and are available. Subsequently, the distributed transaction coordinator executes the following core data operations sequentially according to a predefined execution sequence: First, cancel the candidate driver's registration on the target route, i.e., update the registration record status to "cancelled" or delete the registration record, and release the capacity statistics count corresponding to the route (e.g., decrement the number of registered drivers for the route by 1); Second, confirm the candidate driver's registration on the selected available registration route, i.e., create a new registration record or activate a pre-created record, set the status to "confirmed" or "registered", and increment the number of registered drivers for the route by 1 and decrement the remaining slots by 1. The above two operations are executed in the same global transaction context and can share the same transaction identifier TXID. Failure of either operation will cause the entire global transaction to be rolled back. When both operations are successfully executed, the distributed transaction coordinator commits the global transaction, permanently writing all data changes to the database, making the above cancellation and confirmation operations effective externally. After the global transaction is committed, release all locked slots for the candidate driver (including the selected route and other unselected recommended routes), so that the released route slots can be used by other drivers.

[0123] It should be noted that the submission of the global transaction means that the replacement has been finally completed. The driver no longer registers for the target route, but has successfully registered for the selected new route. The driver's replacement status changes from "pending replacement" to "replaced", and the cumulative number of successfully replaced drivers is increased by 1.

[0124] If either the first or second verification operation fails, it indicates that the preconditions were not met before the actual operation was executed. Continuing to perform the cancellation and confirmation operations would lead to data inconsistency or business anomalies. In this case, the distributed transaction coordinator rolls back the global transaction, undoing all executed operations (if any) within the global transaction to ensure that the database does not generate any partially updated dirty data. Simultaneously, it releases all locked slots for the candidate driver (including the selected route and other routes in the recommendation list) and selects the next-ranked driver from the waiting queue as the new candidate driver according to the replacement priority link, returning to execute step S300 and its subsequent processes. The rollback operation is equivalent to the swap attempt never occurring; system resources are completely reclaimed, and the replacement driver can restart the matching and swapping process in a clean state.

[0125] If an exception occurs during the data operations of canceling or confirming registration after both the first and second verification operations have passed (such as database connection timeout, write failure, network partition, etc.), the distributed transaction coordinator will also perform a rollback operation to ensure that any part of the operation is undone, leaving no unfinished data traces. This rollback mechanism is the last line of defense for ensuring the atomicity of distributed transactions, ensuring that the system data remains consistent under various abnormal scenarios.

[0126] Through the atomic execution mechanism based on the distributed transaction coordinator described above, this embodiment incorporates the two tightly coupled operations of canceling registration for the target route and confirming registration for the selected route into a unified global transaction management system. Utilizing the atomicity of global transactions, it ensures that the two operations always succeed together in a distributed environment—either both succeed (the driver successfully migrates from the original route to the new route), or both fail and the data is completely rolled back (the driver's registration status is restored to its original state before the switch, and the quota resources are fully released). This mechanism effectively avoids serious data anomalies such as data inconsistency, capacity loss, or quota over-occupancy caused by partial operation failures, providing a solid technical guarantee for the reliability and data integrity of the switch process. It also allows the replacement process in case of verification failure to restart on the basis of data consistency, ensuring the robustness and self-healing capability of the entire switch method under abnormal scenarios.

[0127] In some embodiments, selecting the next-ranked driver from the candidate queue as a new candidate driver according to the replacement priority link includes: Determine the original position k of the candidate driver currently being processed in the main candidate queue; The highest-priority candidate driver in the candidate queue is moved to the kth position in the main candidate queue as a new candidate driver. The processing order of the new candidate drivers does not change the original processing order of the (k+1)th and subsequent candidate drivers in the main candidate queue. Record the source and number of times the new candidate driver is added. When the same candidate driver is added but is rejected more than a preset number of times, the candidate driver is removed from the candidate queue.

[0128] Specifically, when a candidate driver in the main candidate queue fails to be replaced, the original position k of the failed driver in the main candidate queue is first determined. Then, according to the priority chain established in step S200, the candidate driver with the highest priority (i.e., the highest overall score and highest ranking) is selected from each level of the candidate queue and moved to position k in the main candidate queue, becoming the new candidate driver. Simultaneously, the original candidate driver is removed from its original candidate queue. After the replacement is completed, the new candidate driver occupies position k and continues to execute steps S300 and subsequent steps. The processing order of all candidate drivers from position k+1 onwards in the main candidate queue remains unaffected and is still processed sequentially according to their original positions.

[0129] During the replacement process, the source (from which level of the waiting queue) and the number of replacements for each new candidate driver are recorded simultaneously. If the same candidate driver refuses to be replaced more than a preset number of times (e.g., 3 times) after being replaced, it is determined that the driver does not have the willingness or condition to accept the replacement, and the driver is permanently removed from the waiting queue. This avoids the driver being repeatedly replaced and repeatedly rejected, thus preventing an invalid cycle and ensuring the termination of the replacement process and the overall execution efficiency. If the waiting queue cannot continue to provide replacement drivers due to removal operations or natural exhaustion, but the cumulative number of successfully replaced drivers has not yet reached N, the system triggers a manual intervention warning, and the remaining replacement requests are handled manually.

[0130] In some embodiments, before obtaining the target route and the number N of drivers to be replaced in response to a sudden reduction in transport capacity at the loading location, the method further includes: Real-time monitoring of the reserved capacity data of each loading point; when the actual available capacity of any loading point decreases more than the reserved capacity by a preset reduction threshold, the sudden reduction event is triggered. The level of the sudden reduction event is determined based on the magnitude of the decrease, and the level includes at least a first-level reduction and a second-level reduction; When the sudden reduction event is a Level 1 reduction, the number of drivers N to be replaced is determined to be equal to the difference between the total number of registered but unloaded drivers on the target route and the actual number of drivers needed after the reduction. When the sudden reduction event is a level 2 reduction, the number N of drivers to be replaced is determined as a preset percentage of the difference between the total number of registered but unloaded drivers on the target route and the actual number of drivers needed after the reduction.

[0131] Specifically, the system monitors the reserved capacity data of each loading point in real time. This data includes the total number of reserved transport tasks, the number of registered drivers, the estimated cargo throughput, and loading capacity for each loading point within the current time period. The system also acquires real-time data on the actual available capacity of each loading point, dynamically determined based on factors such as real-time cargo inflow, warehouse occupancy status, loading and unloading equipment operation status, and personnel availability. A reduction threshold is pre-set for each loading point (e.g., a preset reduction threshold of 20%). When the actual available capacity at any loading point decreases beyond this preset threshold relative to the reserved capacity, a sudden reduction event is automatically triggered. The formula for calculating the reduction rate is: Decrease Rate = (Reserved Capacity - Actual Available Capacity) / Reserved Capacity × 100% For example, if a loading point has 100 scheduled transport trips, and the actual available capacity drops to 70 trips, the decrease is 30%. If the preset reduction threshold is 20%, then 30% > 20%, triggering a sudden reduction event. This real-time monitoring and automatic triggering mechanism can detect and initiate the replacement process in the shortest possible time after a capacity reduction occurs, without manual reporting or triggering, significantly improving the response speed to emergencies.

[0132] Furthermore, the severity of sudden capacity reduction events is determined based on the magnitude of the decrease, with at least two levels: Level 1 and Level 2. Different levels correspond to different swapping strategies and N-value calculation methods. For example, capacity reduction events can be classified into the following levels: when the decrease is in the first range (e.g., greater than 20% and less than or equal to 50%), it is classified as a Level 1 capacity reduction event, indicating that capacity reduction has occurred but is still within a controllable range; when the decrease is in the second range (e.g., greater than 50%), it is classified as a Level 2 capacity reduction event, indicating a larger capacity reduction and a more serious situation. By setting up a tiered mechanism, swapping strategies can be differentiated according to the severity of the event, allowing for moderate swapping when the decrease is small and increased swapping intensity when the decrease is large, achieving more refined and flexible capacity scheduling management.

[0133] When a sudden reduction in capacity is classified as a Level 1 reduction, the number N required for replacement is determined to be the difference between the total number of registered but unloaded drivers on the target route and the actual number of drivers needed after the reduction. In other words, all drivers surplus due to capacity reduction must be replaced. Using the above data as an example, if the original total number of registered but unloaded drivers on the target route was 100, and the actual number of drivers needed after the reduction is 70, then N = 100 - 70 = 30 (drivers), meaning all 30 surplus drivers need to be transferred to other routes. In a Level 1 reduction event, N is the full value of the difference, aiming to completely eliminate excess capacity on the target route and ensure a perfect match between the actual number of registered drivers and the actual demand after the reduction.

[0134] When a sudden reduction in capacity is classified as a Level 2 reduction, the system determines the number of drivers N to be replaced as a preset percentage (e.g., 80%) of the difference between the total number of registered but unloaded drivers on the target route and the actual number of drivers needed after the reduction. For example, if the total number of registered but unloaded drivers is 100, and the actual number of drivers needed after the reduction is 60, the difference is 40, and the preset percentage is 80%, then N = 40 × 80% = 32 (drivers). That is, only 32 surplus drivers are replaced, and 8 drivers are retained as a capacity buffer. In the case of a Level 2 reduction (a larger reduction), only some surplus drivers are replaced, rather than all of them. The business consideration is that the larger the reduction, the more drastic the fluctuation in actual capacity demand at the loading point, and the greater the possibility of future capacity recovery. If all surplus drivers are replaced to other routes, once the capacity demand at the loading point recovers rapidly, there will be a shortage of drivers available, requiring re-recruitment and registration, which incurs high time and economic costs. Therefore, in the event of a level 2 reduction, a certain proportion of drivers are retained in the registration pool for the target route (although there is currently a surplus, they have not been replaced). This not only alleviates the scheduling pressure at the loading point by diverting most of the surplus capacity during a sudden reduction, but also reserves the loading point with flexibility for capacity recovery. This avoids the passive situation of having no drivers available when capacity demand recovers due to excessive replacement, thus achieving a balance between emergency response and capacity reserves.

[0135] Example 2 Corresponding to Embodiment 1 above, this application also provides a driver and route intelligent switching system under sudden reduction in pre-booked transportation. This system is used to implement the driver and route intelligent switching method under sudden reduction in pre-booked transportation provided in any one of Embodiment 1. In this embodiment, the content that is the same as or similar to Embodiment 1 above can be referred to the above description and will not be repeated hereafter.

[0136] In some implementations of this application, the driver and route intelligent switching system under sudden reduction in pre-booked transportation can also perform other steps corresponding to the method described in Embodiment 1. For details, please refer to the detailed description in Embodiment 1, which will not be repeated here.

[0137] Example 3 Corresponding to Embodiment 1 above, this application also provides a computer device, including: a processor and a memory, wherein the memory stores a computer program that can run on the processor, and when the computer program is executed by the processor, it executes the driver and route intelligent switching method provided in any of the above embodiments under sudden reduction in scheduled transportation.

[0138] in, Figure 2 An exemplary computer device 1500 is shown, which may specifically include a processor 1510, a video display adapter 1511, a disk drive 1512, an input / output interface 1513, a network interface 1514, and a memory 1520. The processor 1510, video display adapter 1511, disk drive 1512, input / output interface 1513, network interface 1514, and memory 1520 can communicate with each other via a communication bus 1530.

[0139] The processor 1510 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solution provided by the present invention.

[0140] The memory 1520 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1520 can store the operating system 1521 for controlling the operation of the electronic device, and the basic input / output system (BIOS) 1522 for controlling the low-level operations of the electronic device. Additionally, it can store a web browser 1523, a data storage management system 1524, and an icon font processing system 1525, etc. The aforementioned icon font processing system 1525 can be the application program that specifically implements the aforementioned steps in this embodiment of the invention. In summary, when implementing the technical solution provided by this invention through software or firmware, the relevant program code is stored in the memory 1520 and is called and executed by the processor 1510.

[0141] Input / output interface 1513 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touch screens, microphones, various sensors, etc., and output devices may include displays, speakers, vibrators, indicator lights, etc.

[0142] Network interface 1514 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0143] The bus includes a pathway for transmitting information between various components of the device, such as processor 1510, video display adapter 1511, disk drive 1512, input / output interface 1513, network interface 1514, and memory 1520.

[0144] In addition, the electronic device can also obtain information on specific claim conditions from the virtual resource object claim condition information database for condition judgment, and so on.

[0145] It should be noted that although the above-described device only shows the processor 1510, video display adapter 1511, disk drive 1512, input / output interface 1513, network interface 1514, memory 1520, bus, etc., in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the present invention, and not necessarily all the components shown in the figures.

[0146] Example 4 Corresponding to Embodiment 1 above, this application also provides a computer-readable storage medium. In this embodiment, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description and will not be repeated hereafter.

[0147] The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the driver and route intelligent switching method described above under sudden reductions in scheduled transportation.

[0148] In some implementations of this application, when the computer program is executed by a processor, it can also implement the steps corresponding to the method described in Embodiment 1. Please refer to the detailed description in Embodiment 1, which will not be repeated here.

[0149] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of the present invention.

[0150] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the descriptions in the method embodiments. The systems and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0151] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0152] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0153] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0154] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for intelligent driver and route switching in the event of a sudden reduction in pre-booked transportation capacity, characterized in that, The method includes: In response to a sudden reduction in transport capacity at the loading site, obtain the target route and the number N of drivers that need to be replaced; Based on a multi-dimensional weighted score that includes at least the loading status, distance from the loading point, and registration time, the registered but unloaded drivers for the target route are prioritized. The top N drivers are assigned to the main candidate queue as candidate drivers, and the remaining drivers are assigned to at least one level of the waiting queue according to a preset ratio. The waiting queues at each level form a priority replacement link. According to the priority order of the candidate drivers, for each candidate driver, based on historical transportation data and currently available registration routes, the comprehensive matching degree between each candidate driver and each currently available registration route is calculated, and an alternative route recommendation list is generated. The number of available registration route slots ranked at the top of the recommendation list is temporarily locked. Send a change notification containing the recommendation list and decision time limit to the currently processed candidate driver, and listen for its decision response; If, during the validity period of the temporary lock, a decision is received that the candidate driver accepts the change and selects any available route from the recommended list, the distributed transaction coordinator is activated to atomically execute the cancellation of the original route registration and the confirmation of the new route registration. After the transaction is committed, all locked slots for the candidate driver are released. If a decision to refuse the change is received, the process is temporarily suspended, or the timeout occurs, or the lock validity period expires, all locked slots for the candidate driver are released. The next-ranked driver is selected from the waiting queue according to the replacement priority link as a new candidate driver. The process then returns to the comprehensive matching degree calculation, temporary slot locking, and replacement notification push, until the cumulative number of successfully replaced drivers reaches N.

2. The method for intelligent driver and route switching under sudden reduction in pre-booked transportation as described in claim 1, characterized in that, The calculation of the comprehensive matching degree between each candidate driver and each currently available registration route based on historical transportation data and currently available registration routes includes: Familiarity with historical routes is determined based on the number of times the candidate drivers have carried passengers on the available registration routes and their on-time rate within a preset historical time period. The vehicle type suitability is determined based on the degree of matching between the candidate driver's vehicle type and the vehicle type required for the available registration routes; The timeliness satisfaction is determined based on the degree of deviation between the candidate driver’s historical average transport time and the timeliness requirements specified for the available registration routes. The current load balance is determined based on the ratio of the number of currently registered drivers to the rated capacity demand for the available registration routes; The overall matching degree is obtained by weighting the familiarity with the historical route, the vehicle model compatibility, the timeliness satisfaction, and the current load balancing degree.

3. The method for intelligent driver and route switching under sudden reduction in pre-booked transportation according to claim 1 or 2, characterized in that, The calculation of the comprehensive matching degree between each candidate driver and each currently available registration route based on historical transportation data and currently available registration routes also includes: The system obtains real-time dynamic change information for each available registration route, including real-time changes in the remaining slots for the route, dynamic adjustments to the route timeliness requirements, and real-time updates on road congestion levels. In response to the change in the dynamic information exceeding a preset threshold, the overall matching degree between the candidate driver and the relevant available registration routes is recalculated, and the alternative route recommendation list is updated.

4. The method for intelligent driver and route switching under sudden reduction in pre-booked transportation according to claim 1 or 2, characterized in that, The provision to temporarily lock a preset number of routes with available registration slots in the top-ranked list of recommendations includes: For each of the top-ranked, pre-defined number of available routes in the recommended list, a unique locking token is generated. The locking token includes a locked route identifier, a locked driver identifier, a locked timestamp, and a validity period. The locking token is stored in a distributed cache, and an expiration time corresponding to the decision time limit is set. During the validity period of the lock token, other drivers' registration or lock requests for the same route will be rejected.

5. The method for intelligent driver and route switching under sudden reduction in pre-booked transportation as described in claim 4, characterized in that, The preset quantity is dynamically determined based on the scale of the sudden reduction event, including: When the number of drivers N to be replaced is greater than a first threshold, the preset number is a first value; when N is less than or equal to the first threshold, the preset number is a second value, and the first value is greater than the second value.

6. The method for intelligent driver and route switching under sudden reduction in pre-booked transportation according to claim 1 or 2, characterized in that, After sending a change notification containing the recommendation list and decision time limit to the currently processed candidate drivers, the method further includes: Within the decision-making time limit, the decision response status of the candidate drivers is monitored at preset time intervals; If no decision response is received within the first half of the decision timeframe, a first reminder notification is sent to the candidate driver. If no decision response is received within the latter half of the decision time limit, a second reminder notification is sent to the candidate driver. The second reminder notification has a higher priority than the first reminder notification, and the second reminder notification includes a reminder of the remaining valid time of the temporary lock. If no decision response is received by the deadline, it is determined that the decision will not be processed or has timed out.

7. The method for intelligent driver and route switching under sudden reduction in pre-booked transportation according to claim 1 or 2, characterized in that, The process of activating the distributed transaction coordinator and atomically executing the cancellation of the original route registration and the confirmation of the new route registration includes: To start a global transaction by enabling the distributed transaction coordinator, perform the following operations in sequence: First verification operation: Verify whether the candidate driver's registration status on the target route is still valid; The second verification operation is to verify whether the temporary lock-in slots for the available registration routes selected by the candidate drivers are still valid and have not been taken up by other transactions. If both the first verification operation and the second verification operation pass the verification, then cancel the candidate driver's registration on the target route and confirm the candidate driver's registration on the available registration routes, and submit the global transaction; If either the first verification operation or the second verification operation fails, the global transaction is rolled back, all locked slots for the candidate drivers are released, and the next driver in the order of priority is selected according to the supplementary priority link.

8. The method for intelligent driver and route switching under sudden reduction in pre-booked transportation according to claim 1 or 2, characterized in that, Selecting the next-ranked driver from the candidate queue as a new candidate driver according to the aforementioned priority chain includes: Determine the original position k of the candidate driver currently being processed in the main candidate queue; The highest-priority candidate driver in the candidate queue is moved to the kth position in the main candidate queue as a new candidate driver. The processing order of the new candidate drivers does not change the original processing order of the (k+1)th and subsequent candidate drivers in the main candidate queue. Record the source and number of times the new candidate driver is added. When the same candidate driver is added but is rejected more than a preset number of times, the candidate driver is removed from the candidate queue.

9. The method for intelligent driver and route switching under sudden reduction in pre-booked transportation according to claim 1 or 2, characterized in that, In response to a sudden reduction in transport capacity at the loading site, before obtaining the target route and the number N of drivers N to be reassigned, the method further includes: Real-time monitoring of the reserved capacity data of each loading point; when the actual available capacity of any loading point decreases more than the reserved capacity by a preset reduction threshold, the sudden reduction event is triggered. The level of the sudden reduction event is determined based on the magnitude of the decrease, and the level includes at least a first-level reduction and a second-level reduction; When the sudden reduction event is a Level 1 reduction, the number of drivers N to be replaced is determined to be equal to the difference between the total number of registered but unloaded drivers on the target route and the actual number of drivers needed after the reduction. When the sudden reduction event is a level 2 reduction, the number N of drivers to be replaced is determined as a preset percentage of the difference between the total number of registered but unloaded drivers on the target route and the actual number of drivers needed after the reduction.

10. A driver and route intelligent switching system for sudden reductions in pre-booked transportation, characterized in that, The system is used to implement the method as described in any one of claims 1 to 9.

Images