A driver intelligent order-grabbing method and system based on a smart logistics system

Abstract

This application discloses a driver intelligent order-grabbing method and system based on a smart logistics system. The method includes: a server sending freight order information associated with a dynamic verification type to the driver's terminal; receiving the registration request with vehicle identification submitted by the driver after verification and performing multi-dimensional verification; after the registration deadline, calculating the order-grabbing success probability of each registered driver based on the number of times they have failed to match in the past; and automatically determining the winning vehicle and sending dispatch instructions based on the success probabilities corresponding to all registration requests using a weighted random lottery algorithm. This invention replaces the traditional manual selection or pure speed-first mode with an automated decision-making process of "dynamic verification - probabilistic weight calculation - random lottery," effectively solving problems such as cheating, unfair allocation, low efficiency, and insufficient stability under high concurrency, and achieving fair, safe, and efficient intelligent order-grabbing allocation.

Description

Technical Field

[0001] This application relates to the field of smart logistics technology, and in particular to an intelligent order-grabbing method and system. Background Technology

[0002] In the field of smart logistics, especially in the transportation of bulk commodities such as steel, how to efficiently and fairly allocate freight orders to carrier drivers or fleets is a key technical issue. Traditional offline matching models are inefficient and have been largely replaced by online order-grabbing models. However, existing online order-grabbing solutions still have many shortcomings, affecting the system's fairness, security, and operational efficiency.

[0003] Currently, a common solution is to establish an online platform for direct communication between shippers and drivers. For example, the method described in publicly available document CN113723880A allows drivers to view available cargo and submit quotes, with shippers ultimately manually reviewing driver information and selecting a carrier. While this method reduces information intermediaries, the allocation decision relies entirely on the shipper's manual judgment and operation. This model suffers from the following problems: First, decision-making efficiency is low, as shippers need to review driver quotes and qualifications one by one, becoming a bottleneck in the process when there are many orders. Second, it lacks transparent and consistent fairness criteria, making the selection results susceptible to the shipper's subjective preferences and failing to guarantee equal competitive opportunities for all compliant drivers. More importantly, this model does not design any technical anti-cheating mechanisms for the "order-grabbing" process itself, and due to the long decision-making cycle, it actually weakens the real-time competitive nature of the "grabbing," failing to address the core needs of rapid allocation scenarios.

[0004] Another technological approach focuses on intelligent scheduling and process management of vehicles with accepted orders. For example, the system described in publicly available document CN119671217A emphasizes vehicle authentication, queuing for entry, route planning, and on-the-way monitoring to achieve orderly scheduling and congestion warnings at the depot. In this system, the "order grabbing" function is merely one of the initial entry points for triggering transportation task allocation. However, this system does not delve into the core algorithm for order grabbing and allocation. It lacks specific technical solutions for the inherent technical pain points in the order grabbing process, such as how to handle high-concurrency requests during the order grabbing process, how to design allocation rules to ensure fairness among drivers, and how to prevent cheating using automated scripts (plugins). Its focus is on optimizing logistics execution after task allocation, rather than the fairness and security of the allocation process itself.

[0005] In summary, existing solutions share the following common and unique problems: either they delegate allocation decisions to humans, making it difficult to balance efficiency and fairness, and failing to address the risk of cheating in real-time order-grabbing scenarios (e.g., CN113723880A); or while achieving information management, the order-grabbing module is functionally weak, merely functioning as a simple trigger switch, failing to address key technical challenges such as fairness in the allocation algorithm, anti-cheating measures, and high-concurrency data consistency (e.g., CN119671217A). Specifically, current logistics order-grabbing systems generally face the following pressing technical problems:

[0006] Lack of fairness: The model that uses "click or response speed" as the sole basis for allocation gives drivers with faster networks or who use automated tools an absolute advantage, harming the interests of the majority of compliant drivers and dampening the platform's enthusiasm for participation in the long run.

[0007] Cheating by plug-ins is rampant: Due to the single verification method and fixed business process, the order-grabbing process is easily cracked and simulated by automated scripts or plug-ins, which damages the healthy competitive environment.

[0008] Insufficient system efficiency and stability: In high-concurrency order-grabbing scenarios, the simple "first-come, first-served" logic and direct database operations are prone to resource competition and data conflicts, resulting in system response delays, success rate fluctuations, and even system crashes.

[0009] Rigid operating model: The existing scheme is difficult to flexibly adapt to the operational needs of carriers managing multiple vehicles, and it also fails to reflect reasonable compensation for drivers who have participated for a long time or have repeatedly failed to win the bid in the allocation mechanism, resulting in insufficient policy inclusiveness. Summary of the Invention

[0010] This application provides a driver intelligent order-grabbing method and system based on a smart logistics system, aiming to solve the problems of low allocation efficiency and insufficient fairness in existing technologies, as well as weak anti-fraud capabilities, poor system stability in high-concurrency scenarios, and rigid operation models caused by the lack of targeted design.

[0011] Firstly, a driver-based intelligent order-grabbing method based on a smart logistics system is provided, including:

[0012] Send a batch of freight order information to one or more driver terminals, wherein the batch of freight orders is associated with dynamically assigned verification types;

[0013] Receive a registration request for a target freight order from the driver terminal. The registration request is issued by the driver terminal after verification through the dynamically assigned verification type and includes the selected vehicle identifier.

[0014] In response to the registration request, perform multi-dimensional verification;

[0015] After the deadline for registration of the target cargo order is reached, the probability of successfully grabbing an order in the current allocation is determined based on the number of times the driver or carrier corresponding to each registration request has failed to match in the past.

[0016] Based on the weight values ​​corresponding to all registration requests, a weighted random lottery algorithm is used to determine the winning vehicles for the target cargo order.

[0017] Send dispatch instructions to the driver's terminal corresponding to the winning vehicle.

[0018] Optionally, in the above scheme, the verification types include graphic slider verification and digital calculation verification. The same verification type is used for the same batch of goods orders, and the verification type is randomly switched between different batches of goods orders.

[0019] Optionally, in the above scheme, the step of determining the probability of successfully grabbing an order includes:

[0020] For each valid registration request, calculate the corresponding probability P of successfully grabbing the order according to the formula P = P0 + (N×K);

[0021] Where P0 represents the base probability, P0=1 / V; V represents the total number of applicants for this shipment in the current batch; N represents the number of times the driver or carrier has failed to match a registration in the past; and K represents the preset weighting coefficient.

[0022] Optionally, in the above scheme, determining the winning vehicles for the target cargo order through a weighted random lottery algorithm includes:

[0023] Based on the calculated probability P of each registered user successfully grabbing an order, construct a probability distribution;

[0024] Based on the probability distribution, a random selection is performed using a random number generator to determine a unique winning user.

[0025] Optionally, in the above scheme, the multi-dimensional verification includes:

[0026] Verify whether the user account associated with the registration request is in the approved status;

[0027] The cache is queried to verify whether the vehicle identifier contained in the registration request corresponds to an "empty" status and is not locked in the registration of other freight orders;

[0028] Verify whether the status of the target order is valid and eligible for registration.

[0029] Optionally, in the above scheme, after receiving the registration request and before performing multi-dimensional verification, the method further includes: querying the cache to determine whether the vehicle identifier already has a registration record for the target cargo order; if it does, then rejecting the registration request.

[0030] Optionally, the above solution further includes: during the driver registration process, forcibly verifying the version number of the mobile terminal APP; if the version number is lower than the minimum version required by the system, then preventing the submission of the registration request.

[0031] Optionally, in the above scheme, the method allows carriers to register multiple empty vehicles under their name for the same freight order at the same time. The system locks each registered vehicle through cache records to prevent the same vehicle from being submitted repeatedly.

[0032] Secondly, a driver intelligent order-grabbing system based on a smart logistics system is provided, including:

[0033] The sourcing management module is used to publish sourcing orders in batches and dynamically assign verification types to each batch of sourcing orders;

[0034] The registration interface module is deployed on a mobile terminal APP, which is used for drivers or carriers to select vehicles, complete verification, and submit registration requests.

[0035] The verification engine module is used to perform multi-dimensional status verification on registration requests;

[0036] The weight calculation module is used to calculate the weight value of each registered driver based on the number of times they have failed to match their registration after the registration deadline.

[0037] The automatic allocation module is used to automatically match the winning vehicles based on the weight values ​​of all registered drivers through a weighted random lottery algorithm. This allocation process does not require manual selection.

[0038] The status update and notification module is used to update the vehicle status and push the results to the winning users.

[0039] Optionally, the above scheme may also include:

[0040] The anti-cheat execution module is used to perform at least one of the following anti-cheat measures:

[0041] (a) Registration requests are restricted to be submitted only via mobile app;

[0042] (b) Randomly assign different verification types to different batches of goods orders;

[0043] (c) Prevent duplicate registration requests for the same vehicle within a short period of time by using a cache lock mechanism;

[0044] The data consistency assurance module employs a combination of Redis caching and database transactions to ensure data consistency during the registration and matching process. Specifically, it includes:

[0045] When registering, the registration record is first written to the Redis cache, and then persisted to the database;

[0046] During matching, the relevant database records are locked, and the locks are released after the state update is completed.

[0047] Compared with the prior art, this application has at least the following beneficial effects:

[0048] Based on further analysis and research of existing technical problems, this application recognizes that existing technologies suffer from low allocation efficiency, insufficient fairness, weak anti-cheating capabilities due to a lack of targeted design, poor system stability in high-concurrency scenarios, and rigid operating models. By introducing a fully automated decision-making mechanism of "dynamic verification - registration deadline - probabilistic weight calculation - random lottery," this application replaces inefficient manual screening and a single quick-grab mode. It achieves comprehensive technical effects, including intelligently suppressing cheating behavior, significantly improving the fairness of allocation results, and flexibly adapting to complex operating scenarios, while ensuring high-concurrency stability of the system. Attached Figure Description

[0049] Figure 1 This is a flowchart illustrating a driver intelligent order-grabbing method based on a smart logistics system, provided as an embodiment of this application. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] In the description of this application: unless otherwise stated, "multiple" means two or more. Expressions such as "including", "comprising", and "having" also mean "not limited to" (certain units, components, materials, steps, etc.).

[0052] This invention addresses the problems of cheating, unfair allocation, and limited verification in the traditional steel logistics order-grabbing model. It constructs an intelligent order-grabbing technology solution with "fair allocation as the core, anti-cheating as the guarantee, and efficient matching as the goal." The core logic transforms the "speed-first" order-grabbing model into a "weight accumulation + random lottery" registration and allocation model. Combined with a dynamic verification mechanism, tiered registration, and aggregated matching logic, it achieves fair and efficient allocation of steel logistics freight orders. Simultaneously, it adapts to the multi-vehicle operation needs of drivers / carriers and supports only APP operation to further mitigate the risk of cheating.

[0053] The solution covers the entire process of "user registration - backend verification - weight calculation - random matching - result feedback". It ensures data consistency through Redis caching and database persistence, and ensures operational compliance through multi-dimensional status verification (user, vehicle, permission). Ultimately, it solves the pain points of fairness and security in the traditional order-grabbing model.

[0054] In one embodiment, a driver intelligent order-grabbing method based on a smart logistics system is provided, including:

[0055] Send a batch of freight order information to one or more driver terminals, wherein the batch of freight orders is associated with dynamically assigned verification types;

[0056] Receive a registration request for a target freight order from the driver terminal. The registration request is issued by the driver terminal after verification through the dynamically assigned verification type and includes the selected vehicle identifier.

[0057] In response to the registration request, perform multi-dimensional verification;

[0058] After the deadline for registration of the target cargo order is reached, the probability of successfully grabbing an order in the current allocation is determined based on the number of times the driver or carrier corresponding to each registration request has failed to match in the past.

[0059] Based on the weight values ​​corresponding to all registration requests, a weighted random lottery algorithm is used to determine the winning vehicles for the target cargo order.

[0060] Send dispatch instructions to the driver's terminal corresponding to the winning vehicle.

[0061] The traditional order-grabbing model uses "order-grabbing speed" as the sole criterion, leading to the proliferation of plug-in tools and a low success rate for compliant drivers. The verification method is too simple and easily cracked, and the registration and matching logic is fragmented, making it impossible to meet the multi-vehicle operation needs of carriers.

[0062] The main principles of the technical solution in this embodiment are as follows:

[0063] Fair allocation principle: Introducing a "cumulative weighting of registration times" mechanism, historical registration records that have not been successfully matched are transformed into weights for the next match. Combined with a random lottery algorithm, this achieves a fair allocation where "the longer you participate, the higher your success rate," thus eliminating the advantage of speed cheats from the root.

[0064] Anti-cheating verification principle: Based on the batch order dimension, the verification method is dynamically allocated. The same batch of goods orders uses the same verification type, while different batches are randomly switched, increasing the difficulty of cracking by automated scripts.

[0065] Efficient matching principle: First, the freight orders are summarized and grouped. Drivers / carriers register based on the summarized data. The background system matches orders uniformly according to the number of summarized orders, reducing the resource consumption of scattered matching and improving allocation efficiency.

[0066] Multi-vehicle adaptation principle: Carriers are allowed to register multiple times for "empty and unregistered" vehicles, while the registered vehicles are locked through Redis caching to avoid duplicate registration conflicts.

[0067] In one embodiment, the complete flow of this solution is described as follows:

[0068] (1) Order of Goods Release: The system releases orders of goods in batches, randomly assigns verification type (graphic slider / numerical calculation), and stores them in the T_GOODS_ORDER table (the VALID_CODE_TYPE field identifies the verification type).

[0069] (2) User registration: Drivers / carriers can view the summary freight list through the APP, select "empty and unregistered" vehicles, complete the corresponding type verification, and submit the registration.

[0070] (3) Backend verification: The system verifies the user status (approved), vehicle status (empty), operation permissions (order grabbing permissions), and duplicate registration (Redis cache verification);

[0071] (4) Registration storage: After the verification is passed, the registration information is written to the database (GoodsOrderEnrollPO) and stored in the Redis cache (ENROLL_goods order number, ENROLL_CAR_goods order number prefix key).

[0072] (5) Matching and allocation: After the registration deadline, the system calculates the weight of each registration based on "historical number of unsuccessful attempts × weight coefficient + basic probability", selects and matches vehicles through a random lottery algorithm, and generates transport orders and dispatch orders;

[0073] (6) Results feedback: The system updates the vehicle / driver status (full load / busy), pushes dispatch order information to the APP, and clears the registration records in the Redis cache.

[0074] The Redis cache design in this embodiment:

[0075] Registered User Cache: KEY=ENROLL_+freight order number, VALUE=user code_vehicle code set (to prevent duplicate registration of user-vehicle combinations);

[0076] Vehicle registration cache: KEY=ENROLL_CAR_+freight order number, VALUE=set of license plate numbers (to prevent duplicate vehicle registrations);

[0077] Registration Cache: KEY=GOODS_ORDER_ENROLL_SIZE_+Order Number, VALUE=Number of Registrations (Quick Statistics);

[0078] APP version cache: KEY=app_version, VALUE=supported version number (used for version verification);

[0079] Data consistency guarantee: When registering, write to Redis cache first and then to the database. When matching, lock the database row first (add row lock in selectGoodsOrder method) and then update the status. In case of an exception, roll back the transaction (TransactionStatus.rollback()).

[0080] In one embodiment, the verification types include graphic slider verification and numerical calculation verification. The same verification type is used for the same batch of goods orders, and the verification type is randomly switched between different batches of goods orders.

[0081] In one embodiment, the step of determining the probability of successfully grabbing an order includes:

[0082] For each valid registration request, calculate the corresponding probability P of successfully grabbing the order according to the formula P = P0 + (N×K);

[0083] Where P0 represents the base probability, P0=1 / V; V represents the total number of applicants for this shipment in the current batch; N represents the number of times the driver or carrier has failed to match a registration in the past; and K represents the preset weighting coefficient.

[0084] Formula for calculating the probability of successfully grabbing an order: P = P0 + (N × K);

[0085] Explanation: P is the probability that a user will successfully bid for an order, P0 is the base probability (P0 = 1 / total number of applicants in the current batch); N is the number of times the user has failed to register in the past, and K is the weighting coefficient (configurable, default K = 0.1, range 0.05~0.2).

[0086] This application abandons the "speed priority" judgment logic and adopts a "weight accumulation + random lottery" mechanism:

[0087] Base probability: All registered users have the same initial base probability (e.g., P0=1 / total number of registered users).

[0088] Weight accumulation: The number of unsuccessful registrations in history is recorded as N, and the cumulative weight coefficient for each unsuccessful registration is K (configurable, such as K=0.1). The user's final probability is P=P0 + (N×K).

[0089] Lottery execution: The registration list is stored in a Redis Set collection, and a random number generator (Random) is used to select matching objects with weights to avoid the extreme unfairness of a single random selection.

[0090] Only supports APP operation: The order grabbing function is disabled on the PC version to reduce the adaptation scenarios of plug-in tools, and version verification is added to the APP version (to prevent old cracked clients).

[0091] This embodiment utilizes aggregated matching to reduce the number of times individual freight orders need to be matched, thereby improving backend processing efficiency. Caching is prioritized: frequently queried data such as registration status, vehicle status, and user permissions are stored in Redis to reduce database pressure. Asynchronous processing: dispatch order pushes use asynchronous threads (DDDSPush) to avoid blocking the matching process.

[0092] In one embodiment, determining the winning vehicles for the target cargo order using a weighted random lottery algorithm includes:

[0093] Based on the calculated probability P of each registered user successfully grabbing an order, construct a probability distribution;

[0094] Based on the probability distribution, a random selection is performed using a random number generator to determine a unique winning user.

[0095] The steps of the random lottery selection algorithm are as follows:

[0096] Step 1: Calculate the probability of all registered users and sort them from largest to smallest.

[0097] Step 2: Generate a random number R between 0 and 10 (generated using Java's Random class). If R > N, then determine that R = 0, meaning that the one with the highest probability of registration is selected as the successful bidder. If R <= N, then match the index value of the probability from step 1 according to the value of R.

[0098] In one embodiment, the multi-dimensional verification includes:

[0099] Verify whether the user account associated with the registration request is in the approved status;

[0100] The cache is queried to verify whether the vehicle identifier contained in the registration request corresponds to an "empty" status and is not locked in the registration of other freight orders;

[0101] Verify whether the status of the target order is valid and eligible for registration.

[0102] Multi-dimensional verification includes:

[0103] (1) User verification: The user must have been verified (user.getCorp().getStatus()=="1") and have valid unit information (user.getCorp()≠null).

[0104] (2) Permission verification: Verify whether the user has the permission to grab orders by using resCode(OPT_RACE=btn022) (isHaveAuthForDoing method).

[0105] (3) Vehicle verification: The vehicle status is "empty" and has not participated in other registrations (Redis cache verification);

[0106] (4) Verification of the source order: The source order is not expired, the status is valid (not revoked or sold out), and the detachable status meets the registration rules (the registered weight of the non-detachable source order must be equal to the weight of the source order).

[0107] In one embodiment, after receiving the registration request and before performing multi-dimensional verification, the method further includes:

[0108] The cache is queried to determine whether the vehicle identifier already has a registration record for the target cargo order;

[0109] If such a request exists, then the registration request will be rejected.

[0110] In this embodiment, there are also compliance assurance technical measures:

[0111] (1) Status verification closed loop: The vehicle / driver status is strongly bound to the registration, matching and transportation process to avoid "fully loaded vehicles registering repeatedly" and "busy drivers grabbing orders again".

[0112] (2) Transaction management: Core operations such as registration, matching, and status update are managed by Spring Transaction to ensure atomicity (rollbackFor=Exception.class).

[0113] (3) Targeted resource protection: Targeted cargo orders are verified through the corpCode whitelist and only designated carriers are allowed to participate.

[0114] In one embodiment, the method further includes:

[0115] During the driver registration process, the version number of the mobile terminal APP is forcibly verified. If the version number is lower than the minimum version required by the system, the registration request will be blocked.

[0116] This embodiment also includes client-side restrictions: only the APP client is allowed to grab orders, and the PC client is disabled to reduce the adaptation scenarios of plug-in tools; dynamic verification: the verification type is fixed for the same batch, and randomly switched for different batches, which increases the cost of cracking; version verification: the version number is verified when registering on the APP client (it needs to match the app_version stored in Redis), and the old version is forced to be updated; behavior verification: the registration record is locked through Redis cache to prevent the same user / vehicle from submitting registration requests multiple times in a short period of time.

[0117] In one embodiment, the method allows a carrier to simultaneously register multiple empty vehicles under its name for the same freight order. The system locks each registered vehicle through cache records to prevent the same vehicle from being submitted repeatedly.

[0118] Compared with the traditional order-grabbing method, this application has the following advantages, as shown in Table 1.

[0119] ;

[0120] In one embodiment, a driver intelligent order-grabbing system based on a smart logistics system is provided, comprising:

[0121] The sourcing management module is used to publish sourcing orders in batches and dynamically assign verification types to each batch of sourcing orders;

[0122] The registration interface module is deployed on a mobile terminal APP, which is used for drivers or carriers to select vehicles, complete verification, and submit registration requests.

[0123] The verification engine module is used to perform multi-dimensional status verification on registration requests;

[0124] The weight calculation module is used to calculate the weight value of each registered driver based on the number of times they have failed to match their registration after the registration deadline.

[0125] The automatic allocation module is used to automatically match the winning vehicles based on the weight values ​​of all registered drivers through a weighted random lottery algorithm. This allocation process does not require manual selection.

[0126] The status update and notification module is used to update the vehicle status and push the results to the winning users.

[0127] In one embodiment, it also includes:

[0128] The anti-cheat execution module is used to perform at least one of the following anti-cheat measures:

[0129] (a) Registration requests are restricted to be submitted only via mobile app;

[0130] (b) Randomly assign different verification types to different batches of goods orders;

[0131] (c) Prevent duplicate registration requests for the same vehicle within a short period of time by using a cache lock mechanism;

[0132] The data consistency assurance module employs a combination of Redis caching and database transactions to ensure data consistency during the registration and matching process. Specifically, it includes:

[0133] When registering, the registration record is first written to the Redis cache, and then persisted to the database;

[0134] During matching, the relevant database records are locked, and the locks are released after the state update is completed.

[0135] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. A driver intelligent order-picking method based on a smart logistics system, characterized in that, include: Send a batch of freight order information to one or more driver terminals, wherein the batch of freight orders is associated with dynamically assigned verification types; Receive a registration request for a target freight order from the driver terminal. The registration request is issued by the driver terminal after verification through the dynamically assigned verification type and includes the selected vehicle identifier. In response to the registration request, perform multi-dimensional verification; After the deadline for registration of the target cargo order is reached, the probability of successfully grabbing an order in the current allocation is determined based on the number of times the driver or carrier corresponding to each registration request has failed to match in the past. Based on the weight values ​​corresponding to all registration requests, a weighted random lottery algorithm is used to determine the winning vehicles for the target cargo order. Send dispatch instructions to the driver's terminal corresponding to the winning vehicle.

2. The method of claim 1, wherein, The verification types include graphic slider verification and numerical calculation verification. The same verification type is used for the same batch of goods orders, while the verification type is randomly switched between different batches of goods orders.

3. The method of claim 1, wherein, The steps for determining the probability of successfully grabbing an order include: For each valid registration request, calculate the corresponding probability P of successfully grabbing the order according to the formula P = P0 + (N×K); Where P0 represents the base probability, P0=1 / V; V represents the total number of applicants for this shipment in the current batch; N represents the number of times the driver or carrier has failed to match a registration in the past; and K represents the preset weighting coefficient.

4. The method according to claim 3, characterized in that, The process of determining the winning vehicles for the target cargo order using a weighted random lottery algorithm includes: Based on the calculated probability P of each registered user successfully grabbing an order, construct a probability distribution; Based on the probability distribution, a random selection is performed using a random number generator to determine a unique winning user.

5. The method according to claim 1, characterized in that, The multi-dimensional verification includes: Verify whether the user account associated with the registration request is in the approved status; The cache is queried to verify whether the vehicle identifier contained in the registration request corresponds to an "empty" status and is not locked in the registration of other freight orders; Verify whether the status of the target order is valid and eligible for registration.

6. The method according to claim 1 or 5, characterized in that, After receiving the registration request and before performing multi-dimensional verification, the following is also included: The cache is queried to determine whether the vehicle identifier already has a registration record for the target cargo order; If such a request exists, then the registration request will be rejected.

7. The method according to claim 1, characterized in that, The method further includes: During the driver registration process, the version number of the mobile terminal APP is forcibly verified. If the version number is lower than the minimum version required by the system, the registration request will be blocked.

8. The method according to claim 1, characterized in that, The method allows carriers to register multiple empty vehicles under their name for the same freight order at the same time. The system locks each registered vehicle through cache records to prevent the same vehicle from being submitted repeatedly.

9. A driver intelligent order-grabbing system based on a smart logistics system, characterized in that, include: The sourcing management module is used to publish sourcing orders in batches and dynamically assign verification types to each batch of sourcing orders; The registration interface module is deployed on a mobile terminal APP, which is used for drivers or carriers to select vehicles, complete verification, and submit registration requests. The verification engine module is used to perform multi-dimensional status verification on registration requests; The weight calculation module is used to calculate the weight value of each registered driver based on the number of times they have failed to match their registration after the registration deadline. The automatic allocation module is used to automatically match the winning vehicles based on the weight values ​​of all registered drivers through a weighted random lottery algorithm. This allocation process does not require manual selection. The status update and notification module is used to update the vehicle status and push the results to the winning users.

10. The system according to claim 9, characterized in that, Also includes: The anti-cheat execution module is used to perform at least one of the following anti-cheat measures: (a) Registration requests are restricted to be submitted only via mobile app; (b) Randomly assign different verification types to different batches of goods orders; (c) Prevent duplicate registration requests for the same vehicle within a short period of time by using a cache lock mechanism; The data consistency assurance module employs a combination of Redis caching and database transactions to ensure data consistency during the registration and matching process. Specifically, it includes: When registering, the registration record is first written to the Redis cache, and then persisted to the database; During matching, the relevant database records are locked, and the locks are released after the state update is completed.

Images