Waybill processing, waybill dispatching method and equipment

Abstract

The present application discloses a waybill processing, waybill dispatching method, system, electronic device and storage medium. The waybill processing method comprises: obtaining the waybill to be dispatched, the candidate distribution resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate distribution resources, generating resource-waybill-pricing relationship data of the distribution resources stored based on Redis; batch acquiring the candidate waybill of the target distribution resource from the resource-waybill-pricing relationship data according to the location information of the target distribution resource; sending the candidate waybill of the target distribution resource to the target client corresponding to the target distribution resource, so that the target client displays the candidate waybill. The method solves the problem of improving the efficiency of waybill dispatching in high concurrency scenarios.

Description

Technical Field

[0001] The present application relates to the field of computer processing technology, and more particularly to a waybill processing method, electronic device and storage medium. The present application also relates to a waybill dispatching method, electronic device and storage medium. The present application also relates to a waybill dispatching system. Background Art

[0002] With the development of e-commerce, more and more merchants or service providers provide goods or services to users through the Internet, such as online ordering, online purchase of daily necessities, errand services, home delivery services, etc., which has promoted the development of the logistics field, which to a certain extent puts higher requirements on the waybill dispatching in the logistics field. It has gradually become an important waybill dispatching mode for distribution resources to pull candidate waybills through client applications and select the delivery task of the target waybill. Therefore, how to improve the performance of pulling candidate waybills is particularly important.

[0003] In the prior art, the dispatch results of the waybills to be dispatched are generally stored in a persistent database. When the distribution resources pull candidate waybills through the client application, they query the dispatch results in the persistent database to obtain the candidate waybills. However, during the peak of waybill production or pulling, there may be a large amount of concurrent traffic. It is difficult to ensure a high-speed pull effect for waybill dispatch by accessing the persistent database. In addition, the maintenance cost of the persistent database is also high.

[0004] Therefore, how to improve the efficiency of waybill dispatching in high-concurrency scenarios is a problem that needs to be solved. Summary of the invention

[0005] The waybill processing method provided in the embodiment of the present application solves the problem of improving the efficiency of waybill dispatching in high concurrency scenarios.

[0006] An embodiment of the present application provides a waybill processing method, including: obtaining waybills to be dispatched, candidate delivery resources corresponding to the waybills to be dispatched, and pricing information of the waybills to be dispatched that match the candidate delivery resources, and generating resource-waybill-pricing relationship data of the delivery resources stored based on Redis; batch acquiring candidate waybills of the target delivery resources from the resource-waybill-pricing relationship data according to the location information of the target delivery resources; and sending the candidate waybills of the target delivery resources to a target client corresponding to the target delivery resource, so that the target client displays the candidate waybills.

[0007] Optionally, the resource-waybill-pricing relationship data of the distribution resource is hash mode data corresponding to the distribution resource, which is composed of a hash key and a storage object corresponding to the hash key; the generation of the resource-waybill-pricing relationship data of the distribution resource based on Redis storage includes: determining a first prefix, and generating a key value of the hash key according to the first prefix and the distribution resource identifier of the distribution resource; generating a key value of the subkey according to the waybill identifier of the waybill to be dispatched, generating a storage value corresponding to the subkey according to the pricing information of the waybill to be dispatched that matches the distribution resource, and assembling the subkey and the storage value into a storage object corresponding to the hash key; storing the hash key and the storage object corresponding to the hash key in the Redis database to form the resource-waybill-pricing relationship data of the distribution resource.

[0008] Optionally, the hash key and the storage object corresponding to the hash key are stored in a Redis database to form resource-waybill-pricing relationship data of the distribution resource, including: serializing the hash key and the storage object corresponding to the hash key based on a data serialization protocol, and storing the serialized data obtained after the serialization as the resource-waybill-pricing relationship data of the distribution resource in the Redis database.

[0009] Optionally, the pricing information includes: basic pricing information and scheduling information; wherein the scheduling information is used to determine the display order of the candidate waybills.

[0010] Optionally, it also includes: obtaining the scheduling round of waybills to be dispatched; obtaining the preset storage length of the distribution resources; deleting some waybills to be dispatched of the distribution resources according to the scheduling round and the preset storage length, so that the resource-waybill-pricing relationship data of the distribution resources stored based on Redis conforms to the preset storage length.

[0011] Optionally, deleting some of the waybills to be dispatched of the distribution resource according to the scheduling round and the preset storage length so that the resource-waybill-pricing relationship data of the distribution resource stored based on Redis meets the preset storage length, including: taking the existing waybills to be dispatched of the specific distribution resource stored based on Redis as the first waybills to be dispatched of the specific distribution resource; obtaining the waybills to be dispatched of the specific distribution resource in this round of scheduling as the second waybills to be dispatched of the specific distribution resource; determining the number of waybills to be dispatched corresponding to the specific distribution resource that exceeds the preset storage length according to the first waybills to be dispatched and the second waybills to be dispatched of the specific distribution resource, as the number of waybills to be deleted that need to be deleted of the specific distribution resource in this round of scheduling; determining the first deleted waybills that can be deleted in the first waybills to be dispatched according to the dispatch type and scheduling round of the first waybills to be dispatched, and deleting at least part of the waybill data of the first deleted waybills from the resource-waybill-pricing relationship data of the specific distribution resource according to the number to be deleted.

[0012] Optionally, after deleting the first deleted waybill, determine whether the number of deleted first deleted waybill meets the number to be deleted; if not, determine the second deleted waybill that can be deleted in the second waybill to be dispatched based on the scheduling score ranking and dispatch type of the second waybill to be dispatched, and delete at least part of the second deleted waybill and its pricing information that matches the specific delivery resources.

[0013] Optionally, the first deleted waybill and the second deleted waybill are waybills to be dispatched whose scheduling round is greater than a preset scheduling number threshold and whose dispatch type is a diffusion type.

[0014] Optionally, it also includes: after deleting at least part of the second deleted waybill, determining whether the number of deleted first deleted waybill and second deleted waybill meets the number to be deleted; if not, determining the first to-be-dispatched waybill whose scheduling round indicates the first round of scheduling and whose dispatch type is the diffusion type as the third deleted waybill, and deleting at least part of the third deleted waybill.

[0015] Optionally, the acquisition of the waybill to be dispatched, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate delivery resources includes: obtaining the waybill to be dispatched that is in an order receiving state according to the waybill status; obtaining the candidate delivery resources corresponding to the waybill to be dispatched according to the delivery area associated with the waybill to be dispatched; and determining the pricing information that matches the candidate delivery resources for the waybill to be dispatched according to the pricing factors.

[0016] Optionally, it also includes: creating an assignment thread pool and a diffusion thread pool; receiving information about waybills to be dispatched with assigned delivery resources sent by the scheduling server through the threads in the assignment thread pool, and returning assignment success to the scheduling server; receiving information about waybills to be dispatched without assigned delivery resources sent by the scheduling server through the threads in the diffusion thread pool, and returning diffusion success to the scheduling server.

[0017] Optionally, the method of batch acquiring candidate waybills for the target delivery resources from the resource-waybill-pricing relationship data based on the location information of the target delivery resources includes: receiving a waybill pull request sent by the target client for pulling candidate waybills for the target delivery resources; parsing out the order acceptance range conditions selected for the target delivery resource from the waybill pull request; and, for the target delivery resource, querying from the resource-waybill-pricing relationship data to obtain waybills whose distance from the location information of the target delivery resource meets the order acceptance range conditions, as candidate waybills for the target delivery resource.

[0018] Optionally, it also includes: receiving an order acceptance request from the target client for the target delivery resource to undertake the delivery of a target waybill among the candidate waybills; sending a successful order acceptance response to the order acceptance request to the target client, and adding the target waybill to the delivery task of the target delivery resource; and updating the status of the target waybill to an accepted status.

[0019] An embodiment of the present application also provides a waybill dispatching method, comprising: sending a waybill pull request to a fulfillment server based on location information of a target delivery resource and an order acceptance range condition; obtaining candidate waybills of the target delivery resource returned by the fulfillment server in response to the waybill pull request, and displaying the candidate waybills; wherein the candidate waybills are waybill data corresponding to the target delivery resource obtained in batches from resource-waybill-pricing relationship data stored based on Redis.

[0020] Optionally, it also includes: detecting that the target delivery resource selects to undertake the target waybill from the candidate waybills, and sending an order acceptance request to the fulfillment service end for the target delivery resource to undertake the delivery of the target waybill; obtaining a successful order acceptance response to the order acceptance request, and adding the target waybill to the delivery task of the delivery resource.

[0021] Optionally, the candidate waybill is the first waybill assigned to the delivery resource, or the second waybill diffused to the delivery resource.

[0022] Optionally, the candidate waybill includes scheduling and sorting information of the candidate waybill; the method further includes: determining a display position of the candidate waybill on the candidate waybill display interface according to the scheduling and sorting information.

[0023] Optionally, it also includes: detecting that the delivery resource triggers the refresh of the waybill or the client triggers the refresh of the waybill periodically, sending a waybill refresh request to the fulfillment server to request the current candidate waybill; obtaining the current candidate waybill returned by the fulfillment server in response to the waybill refresh request, and using the current candidate waybill to refresh the candidate waybill display interface.

[0024] The embodiment of the present application also provides a waybill dispatching system, including: a client, a fulfillment server, and a scheduling server; the client is used to send a waybill pull request to the fulfillment server according to the location information of the target delivery resource and the order acceptance range conditions; obtain the candidate waybill of the target delivery resource returned by the fulfillment server in response to the waybill pull request; display the candidate waybill on the candidate waybill display interface of the client; the fulfillment server is used to obtain the waybill to be dispatched provided by the scheduling server, the candidate delivery resource corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate delivery resource, generate resource-waybill-pricing relationship data of the delivery resource stored based on Redis; receive the A waybill pull request is used to batch-acquire waybill data that matches the location information and order acceptance scope conditions of the target delivery resource from the resource-waybill-pricing relationship data stored based on Redis according to the waybill pull request, and send the waybill data as candidate waybill of the target delivery resource to the client; the scheduling service end is used to obtain the waybill to be dispatched that is in the order acceptance state according to the waybill status, obtain the candidate delivery resources corresponding to the waybill to be dispatched according to the delivery area associated with the waybill to be dispatched, and determine the pricing information that matches the candidate delivery resources for the waybill to be dispatched according to the pricing factor; and provide the waybill to be dispatched, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information that matches the candidate delivery resources to the fulfillment service end.

[0025] An embodiment of the present application further provides an electronic device, comprising: a memory, and a processor; the memory is used to store a computer program, and after the computer program is run by the processor, the method provided in the embodiment of the present application is executed.

[0026] The embodiment of the present application also provides a computer storage medium storing computer execution instructions, which are used to implement the method provided in the embodiment of the present application when executed by a processor.

[0027] Compared with the prior art, this application has the following advantages:

[0028] The embodiments of the present application provide a waybill processing method, device, electronic device and storage medium, which generates resource-waybill-pricing relationship data of the distribution resources stored based on Redis by acquiring the waybill to be dispatched, the candidate distribution resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate distribution resources; batches of candidate waybills of the target distribution resources are acquired from the resource-waybill-pricing relationship data according to the location information of the target distribution resources; and the candidate waybills of the target distribution resources are sent to the target client corresponding to the target distribution resource, so that the target client displays the candidate waybills. The solution of storing resource-waybill-pricing relationship data based on Redis has high availability and can support high-concurrency scenarios, thereby solving the problem of improving the efficiency of waybill dispatch in high-concurrency scenarios.

[0029] The embodiments of the present application provide a waybill dispatching method, device, electronic device and storage medium, which sends a waybill pull request to the fulfillment service end according to the location information of the target delivery resource and the order acceptance range conditions; obtains the candidate waybill of the target delivery resource returned by the fulfillment service end in response to the waybill pull request; wherein the candidate waybill is the waybill data corresponding to the target delivery resource obtained in batches from the resource-waybill-pricing relationship data stored based on Redis; and displays the candidate waybill on the candidate waybill display interface of the client. The resource-waybill-pricing relationship data stored based on Redis can support high-concurrency waybill pull processing, thereby solving the problem of improving the efficiency of waybill dispatching in high-concurrency scenarios.

[0030] A waybill dispatching system provided in an embodiment of the present application includes a client, a fulfillment server, and a scheduling server; through the fulfillment server, the waybill to be dispatched provided by the scheduling server, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate delivery resources are obtained, and resource-waybill-pricing relationship data of the delivery resources stored based on Redis is generated; the waybill pull request sent by the client is received, and the waybill data that matches the location information and order acceptance range conditions of the target delivery resource are batch acquired from the resource-waybill-pricing relationship data stored based on Redis according to the waybill pull request, and is sent to the client as a candidate waybill of the target delivery resource. The dispatching server obtains the waybill to be dispatched in the order acceptance state according to the waybill status, obtains the candidate delivery resources corresponding to the waybill to be dispatched according to the delivery area associated with the waybill to be dispatched, and determines the pricing information matching the candidate delivery resources for the waybill to be dispatched according to the pricing factor; provides the waybill to be dispatched, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information matching the candidate delivery resources to the fulfillment server. The client sends a waybill pull request to the fulfillment server according to the location information of the target delivery resource and the order acceptance scope conditions; obtains the candidate waybill of the target delivery resource returned by the fulfillment server in response to the waybill pull request; and displays the candidate waybill on the candidate waybill display interface of the client. This provides a highly available waybill dispatching solution in high-concurrency scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 It is a processing flow chart of a waybill processing method provided in the first embodiment of the present application;

[0032] Figure 2 This is a schematic diagram of the timing of waybill processing provided in the first embodiment of the present application;

[0033] Figure 3 This is a flowchart of deleting a waybill provided in the first embodiment of the present application;

[0034] Figure 4 is a processing flow chart of a waybill dispatching method provided in the second embodiment of the present application;

[0035] Figure 5 This is a schematic diagram of a waybill dispatching system provided in the third embodiment of the present application;

[0036] Figure 6 It is a schematic diagram of a waybill processing device provided in the fourth embodiment of the present application;

[0037] Figure 7 is a schematic diagram of a waybill dispatching device provided in the fifth embodiment of the present application;

[0038] Figure 8 It is a schematic diagram of an electronic device provided by this application. DETAILED DESCRIPTION

[0039] Many specific details are described in the following description to facilitate a full understanding of the present application. However, the present application can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of the present application, so the present application is not limited by the specific implementation disclosed below.

[0040] The embodiments of the present application provide a waybill processing method, device, electronic device and storage medium. The embodiments of the present application also provide a waybill dispatching method, device, electronic device and storage medium. The embodiments of the present application provide a waybill dispatching system. The following embodiments will describe them one by one.

[0041] For ease of understanding, the application scenarios and some concepts of the waybill processing method provided by the embodiment of the present application are first given. In the actual logistics field, an important waybill dispatching mode is the grab order mode. The so-called grab order mode refers to the waybill dispatching mode in which the distribution resource pulls the candidate waybill from the fulfillment service end through the client application and selects to undertake the delivery task of the target waybill. The pulled candidate waybill can be displayed in the grab order pool so that the distribution resource can actively select the waybill to undertake from it. The so-called grab order pool can be implemented as a candidate waybill page containing one or more candidate waybills that the distribution resource can actively choose to undertake, and the candidate waybill page can contain multiple pages. The so-called waybill refers to the delivery information generated in the logistics distribution, for example, it can be the delivery information of multiple orders aggregated based on the delivery path, or it can be the delivery information of one order. The so-called delivery resource refers to the resource that executes the delivery of the waybill, for example, it can be a rider, or it can be a delivery robot that performs the delivery. The process of a waybill from the delivery resource to the user corresponding to the waybill is the waybill fulfillment process. An example of the order grabbing model is the crowdsourcing service in the food delivery industry. Its core feature is that the rider uses the client application to view the candidate orders corresponding to the rider in the order grabbing pool, and selects the appropriate target order from the candidate orders to grab. If the grabbing is successful, the target order will be delivered by the rider.

[0042] Due to the different processes of assigning waybills to delivery resources, waybill assignment can be divided into two forms: waybill assignment and waybill diffusion. Waybill assignment refers to the process of assigning a waybill to a delivery resource, and the delivery resource can confirm to accept the order or confirm not to accept the order. Waybill diffusion refers to the process of assigning a waybill to multiple delivery resources, each of which can initiate an order. The server selects the appropriate delivery resource based on the order of initiation time and / or other scheduling information, and assigns the waybill to the selected delivery resource for delivery.

[0043] It should be noted that the application scenario is merely an embodiment of the application scenario. The purpose of providing this application scenario embodiment is to facilitate the understanding of the waybill processing and dispatching method of the present application, and is not used to limit the waybill processing and dispatching method of the present application.

[0044] The following combination Figures 1 to 3 The waybill processing method provided in the first embodiment of the present application is described. Figure 1 The waybill processing method shown includes: steps S101 to S103.

[0045] Step S101, obtaining the waybill to be dispatched, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate delivery resources, and generating resource-waybill-pricing relationship data of the delivery resources stored based on Redis.

[0046] The waybill processing method provided in the embodiment of the present application can be applied to the server. The server obtains the waybill to be dispatched, matches each waybill to be dispatched with the distribution resource, and determines the pricing information of each distribution resource matched with each waybill to be dispatched. At least part of the waybill to be dispatched that matches the target distribution resource in the waybill to be dispatched is the candidate waybill of the target distribution resource. The target distribution resource uses the client application to request the server to pull the candidate waybill, and displays it on the target client corresponding to the target distribution resource. In actual applications, a large number of waybill to be dispatched will be generated during the peak period of waybill production, and a large number of distribution resources may pull their respective candidate waybills during the peak period of waybill pulling. Therefore, the amount of data of waybill to be dispatched that needs to be processed during these periods is large, and the concurrent traffic is large. In order to ensure the high-speed processing of waybill and waybill pulling effect during peak periods, the method provided in this embodiment is based on Redis to store data related to candidate waybills. The high concurrency performance of Redis helps to achieve the millisecond-level order pulling effect, and the master-slave replication and keepalive mechanism (keepalive) in the Redis mechanism help to ensure high availability.

[0047] This step is to obtain the waybill to be dispatched, the candidate distribution resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate distribution resources, and generate the resource-waybill-pricing relationship data of the distribution resources stored based on Redis. The generated relationship data is stored in the Redis database. Among them, the acquisition of the waybill to be dispatched, the candidate distribution resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate distribution resources includes: obtaining the waybill to be dispatched in the order acceptance state according to the waybill status; obtaining the candidate distribution resources corresponding to the waybill to be dispatched according to the distribution area associated with the waybill to be dispatched; and determining the pricing information matching the candidate distribution resources for the waybill to be dispatched according to the pricing factor. During implementation, the function of the server applying the method can be decoupled into a scheduling function and a fulfillment function. The scheduling function and the fulfillment function can be implemented as an independent scheduling server and a fulfillment server, respectively, or as a scheduling function module and a fulfillment function module, which is not limited in this application. Taking the decoupling of the server into a scheduling server and a fulfillment server as an example, the scheduling server matches the waybills to be dispatched, the distribution resources and the pricing information, generates the matching results and pushes them to the fulfillment server. The pricing information includes at least the basic pricing information, and may further include extended information. The extended information may be scheduling information, which may be specifically scheduling sorting information for determining the display order of the waybills to be dispatched as candidate waybills, or may be waybills’ assignment priority information or order grabbing recommendation priority information for waybills. The extended information may also be distribution prompt information of the recommended distribution path displayed to the distribution resources. The extended information may help the distribution resources make order grabbing decisions. Based on the matching results, the fulfillment server generates the waybill-resource-pricing relationship data based on Redis storage according to the pre-designed Redis storage mode. Specifically in this step, the dispatching service end can obtain the waybill to be dispatched that is in the order acceptance state according to the waybill status, obtain the candidate delivery resources corresponding to the waybill to be dispatched according to the delivery area associated with the waybill to be dispatched, determine the pricing information matching the candidate delivery resources for the waybill to be dispatched according to the pricing factor, generate the matching result between the waybill to be dispatched, the delivery resources and the pricing information, and push it to the fulfillment service end. The fulfillment service end obtains the matching result between the waybill to be dispatched, the delivery resources and the pricing information pushed by the dispatching service end, obtains the waybill to be dispatched, the candidate delivery resources corresponding to the waybill to be dispatched and the pricing information matching the candidate delivery resources of the waybill to be dispatched from the matching result, and generates the resource-waybill-pricing relationship data of the delivery resources based on Redis storage according to the pre-designed Redis storage mode.

[0048] In this embodiment, the pre-designed Redis storage mode includes: a storage mode for resource-waybill-pricing relationship data and a storage mode for waybill-resource relationship data. Among them, the resource-waybill-pricing relationship data is preferably stored in hash mode. The so-called hash mode consists of three parts: key, field, and value. Field can also be understood as sub-key. Preferably, the resource-waybill-pricing relationship data of the distribution resource is hash mode data corresponding to the distribution resource composed of a hash key and a storage object corresponding to the hash key; the generation of the resource-waybill-pricing relationship data of the distribution resource based on Redis storage includes: determining a first prefix, generating a key value of the hash key according to the first prefix and the distribution resource identifier of the distribution resource; generating a key value of the subkey according to the waybill identifier of the waybill to be dispatched, generating a storage value corresponding to the subkey according to the pricing information of the waybill to be dispatched that matches the distribution resource, and assembling the subkey and the storage value into a storage object corresponding to the hash key; storing the hash key and the storage object corresponding to the hash key in the Redis database to form the resource-waybill-pricing relationship data of the distribution resource. For example, taking the delivery area as the first prefix, based on the resource-way order-pricing relationship data stored in Redis, the key value composed of each rider (i.e., delivery resource) and the delivery area corresponds to a hash table. The data objects stored in the hash table are the candidate way order identifier of the rider and the pricing information of the candidate way order identified by each candidate way order identifier corresponding to the rider.

[0049] In this embodiment, the waybill-resource relationship data is preferably stored in set mode. The so-called set mode consists of two parts: key and value. Specifically, it includes: determining the second prefix, generating the key value of the set key according to the second prefix and the waybill identifier of the waybill to be dispatched, using one or more distribution resources corresponding to the waybill to be dispatched as the storage value corresponding to the set key, storing the set key and the corresponding storage value in the Redis database to form the waybill-resource relationship data of the waybill to be dispatched. The waybill-resource relationship data can be used to delete the resource-waybill-pricing information relationship data related to the waybill after the waybill user (i.e., the consumer) cancels the waybill; it can also provide a basis for problem analysis in operation and maintenance scenarios.

[0050] Furthermore, considering that the query bandwidth for querying resource-waybill-pricing relationship data during waybill pulling is relatively large, in order to reduce bandwidth and increase throughput, the resource-waybill-pricing relationship data that needs to be stored in Redis is serialized and stored, and deserialized after obtaining the query results. Preferably, the protobuf serialization protocol is used for serialization and deserialization. In this embodiment, the hash key and the storage object corresponding to the hash key are stored in the Redis database to form the resource-waybill-pricing relationship data of the distribution resource, including: serializing the hash key and the storage object corresponding to the hash key based on the data serialization protocol, and storing the serialized data obtained after the serialization as the resource-waybill-pricing relationship data of the distribution resource in the Redis database. Of course, other algorithms such as the hessian protocol can also be used for serialization to compress bandwidth.

[0051] In actual implementation, the dispatching server can be triggered regularly by a timed task trigger, for example, the dispatching task of the dispatching server is triggered every 30 seconds to match the waybill to be dispatched, the distribution resources and the pricing information. Since the dispatching is triggered regularly, the efficiency of waybill processing is improved, and asynchronous processing can be performed between the dispatching server and the fulfillment server. The specific asynchronous processing is that when the dispatching server dispatches the waybill to be dispatched and assigns or diffuses the waybill to be dispatched, it is called in an asynchronous manner, that is, the waybill assignment result or waybill diffusion result of the waybill to be dispatched is not judged. Even if the waybill assignment or waybill diffusion of a waybill to be dispatched is unsuccessful, the waybill to be dispatched will still be dispatched to the waybill to be dispatched for re-dispatching during the next scheduled dispatching. For the fulfillment server, the dispatching result is directly returned to the dispatching server as successful, and then the waybill assignment and waybill diffusion are processed asynchronously through the thread pool. Specifically, the server or the fulfillment server performs the following processing: creates an assignment thread pool and a diffusion thread pool; receives information about waybills to be dispatched with assigned delivery resources sent by the scheduling server through the threads in the assignment thread pool, and returns assignment success to the scheduling server; receives information about waybills to be dispatched without assigned delivery resources sent by the scheduling server through the threads in the diffusion thread pool, and returns diffusion success to the scheduling server.

[0052] In addition, Redis provides a persistence mechanism and can support data synchronization in multiple computer rooms, so that the method has high availability after deployment. For example, if the Redis in a computer room fails, it will be switched to the Redis in another computer room; if the Redis storage in two computer rooms fails at the same time, the Redis cluster can also be restarted, and the resource-waybill-pricing relationship data of the waybill to be dispatched will be written into the new Redis after the scheduled scheduling trigger triggers the next round of scheduling.

[0053] Step S102: batch-acquire candidate waybills of the target delivery resources from the resource-waybill-pricing relationship data according to the location information of the target delivery resources.

[0054] In fact, the waybill to be dispatched can correspond to one or more candidate delivery resources, and each candidate delivery resource is preferably a delivery resource in operation. Each candidate delivery resource can actively initiate a request to grab an order to the server. Delivery resources that are not in operation can also request the server to obtain information about the waybill to be dispatched, so as to encourage the delivery resources to increase their willingness to start work. The target delivery resource is any delivery resource. The so-called candidate waybill refers to the waybill to be dispatched provided for the target delivery resource.

[0055] This step is to obtain candidate waybills of the target distribution resource. The step of batch-acquiring candidate waybills of the target distribution resource from the resource-waybill-pricing relationship data according to the location information of the target distribution resource includes: receiving a waybill pull request sent by the target client for pulling candidate waybills of the target distribution resource; parsing the order range condition selected by the target distribution resource from the waybill pull request; and querying the resource-waybill-pricing relationship data for the target distribution resource, and obtaining the waybill whose distance from the location information of the target distribution resource meets the order range condition, as the candidate waybill of the target distribution resource. The so-called waybill pull refers to the process of obtaining and displaying candidate waybills actively initiated by the client. During implementation, the target distribution resource uses the target client to initiate a waybill pull request to the server (or fulfillment server), and the server batch-acquires the waybill data matching the location information and order range condition of the target distribution resource from the resource-waybill-pricing relationship data stored based on Redis in response to the waybill pull request, and returns it to the target client as the candidate waybill of the target distribution resource. Preferably, the distribution resource pulls the waybills to be dispatched within a certain distance range of its location by setting the order acceptance range conditions. Specifically, the target client sends a waybill pull request to the fulfillment service end based on the location information of the target distribution resource and the order acceptance range conditions, obtains the candidate waybill for the waybill pull request and displays it on the candidate waybill display interface of the target client. For example, if the rider sets the order acceptance range condition to accept waybills within 7 kilometers, the fulfillment service end will only query the information of the waybills to be dispatched within 7 kilometers of the rider's location information as the candidate waybills of the rider.

[0056] Step S103: sending the candidate waybills of the target delivery resource to the target client corresponding to the target delivery resource, so that the target client displays the candidate waybills.

[0057] This step is to display the corresponding candidate waybills to the target delivery resource. If the resource-waybills-pricing relationship data stored in Redis is serialized data (such as a binary stream), the relevant data of the candidate waybills obtained by the query needs to be deserialized using the corresponding or the same serialization protocol, and the data received by the target client is the deserialized data.

[0058] In this embodiment, the candidate waybill is the first waybill assigned to the distribution resource, or the second waybill diffused to the distribution resource. That is, a waybill to be assigned can be assigned to a specific distribution resource according to the waybill assignment method, and at the same time, it can also be diffused to a specific distribution resource according to the waybill diffusion method. The specific distribution resource can confirm the order for any candidate waybill assigned to or diffused to the specific distribution resource. In fact, a waybill assigned by a waybill assignment method can be a weak assignment or a strong assignment. For a weakly assigned waybill, a specific distribution resource may not accept it, and for a strongly assigned waybill, a specific distribution resource may not accept it under certain conditions. The data of the candidate waybill obtained by the target client may include the pricing information of the candidate waybill that matches the target distribution resource. If the pricing information includes extended information and the extended information is a scheduling sorting order, then in the candidate waybill display interface of the target client, the display position of each candidate waybill can be based on the extended information in the pricing information of the candidate waybill.

[0059] In this embodiment, the target client can periodically trigger the refresh of candidate waybills, and the rider can also actively trigger the refresh of candidate waybills. The specific processing of the target client includes: detecting that the delivery resource triggers the refresh of the waybill or the target client periodically triggers the refresh of the waybill, sending a waybill refresh request to the fulfillment server to request the current candidate waybill; obtaining the current candidate waybill returned by the fulfillment server in response to the waybill refresh request, and using the current candidate waybill to refresh the candidate waybill display interface.

[0060] In this embodiment, it also includes: receiving an order acceptance request from the target client for the target distribution resource to undertake the delivery of a target waybill from the candidate waybill; sending a successful order acceptance response to the order acceptance request to the target client, adding the target waybill to the delivery task of the target distribution resource; updating the status of the target waybill to an accepted state. Accordingly, the process of the target distribution resource initiating an order acceptance using the target client includes: detecting that the target distribution resource selects to undertake the target waybill from the candidate waybill, sending an order acceptance request to the fulfillment service end for the target distribution resource to undertake the delivery of the target waybill; obtaining a successful order acceptance response to the order acceptance request, and adding the target waybill to the delivery task of the distribution resource.

[0061] Figure 2It is a schematic diagram of the timing of waybill processing provided by the first embodiment of the present application, and the figure involves a scheduled task, a scheduling service end and a fulfillment service end. It includes the following steps: S201, a round of scheduling every 30 seconds. In the workflow scheduled task, a scheduling task is triggered every 30 seconds, and the scheduling task can be a task deployed on the scheduling service end. S202, the scheduling service end and the fulfillment service end perform asynchronous call processing, and assign the waybill to be assigned to the distribution resources in an assignment or diffusion mode. The scheduling service end does not judge the assignment or diffusion result. The waybill to be assigned that fails to be assigned or diffused can be scheduled again in the next round of scheduling after 30 seconds. S203, the fulfillment service end returns success to the scheduling service end. S204, the fulfillment service end processes the matching results of the assigned or diffused waybill to be assigned through an asynchronous thread pool. The so-called matching result refers to the three-party matching result of the waybill, resource and pricing information, in which the scheduling service end determines the candidate distribution resources that match each waybill to be assigned (that is, the distribution resources that are allowed to undertake the waybill to be assigned) and determines the pricing information of each candidate distribution resource. S205, assemble the person-price relationship, and generate the resource-waybill-pricing relationship data, i.e., the person-price relationship, according to the pre-designed Redis-based storage mode. S206, if the person-price relationship corresponding to the distribution resource exceeds the preset storage length, delete at least part of the person-price relationship data of the distribution resource according to the deletion strategy. Specifically, delete according to the scheduling round deletion strategy. S207, serialize the person-price relationship. Specifically, serialize according to the protobuf protocol. S208, the serialized person-price relationship is stored in Redis.

[0062] In this embodiment, it also includes refreshing or cleaning the resource-waybill-pricing relationship data stored based on Redis, so as to increase the exposure rate of newly produced waybills to be dispatched and improve the dispatch efficiency. During implementation, at least part of the resource-waybill-pricing relationship data stored based on Redis is deleted according to the scheduling round deletion strategy. The so-called scheduling round refers to the number of times the waybill to be dispatched is scheduled. For example, when the waybill to be dispatched is dispatched to generate the matching result, the number of times the dispatched waybill is scheduled is recorded, or the scheduling mark of the waybill to be dispatched with the second or more scheduling times is set to old, and the scheduling mark of the waybill to be dispatched in the first round of scheduling is set to new. The so-called scheduling round deletion strategy refers to a strategy that determines whether to delete the relevant relationship data of the waybill to be dispatched in Redis storage based on the scheduling times or the scheduling mark. Deleting the resource-waybill-pricing relationship data according to the scheduling round deletion strategy specifically includes the following processing: obtaining the scheduling round of the waybill to be dispatched; obtaining the preset storage length of the distribution resource; according to the scheduling round and the preset storage length, deleting some waybills to be dispatched of the distribution resource, so that the resource-waybill-pricing relationship data of the distribution resource stored in Redis meets the preset storage length.

[0063] Among them, the preset storage length can be determined based on the number of candidate waybills displayed to the target distribution resource. For example, the design specification of the candidate waybill page of a distribution resource is to display up to 300 candidate waybills, and a multi-page display method can be adopted. Then the display interface of the lost candidate waybills is a page-turning method, displaying 30 waybills per page, and displayed in 10 pages. Therefore, the preset storage length of each candidate waybill of the distribution resource can be determined according to the number of candidate waybills to be displayed by the distribution resource and the data that each candidate waybill can be displayed to the distribution resource. The data that can be displayed to the distribution resource for each candidate waybill includes but is not limited to: basic waybill data, basic pricing information in the waybill pricing information, and extended information. Processing the relationship data related to the waybills to be delivered stored in Redis according to the scheduling round deletion strategy can reduce the bandwidth pressure of Redis.

[0064] The scheduling round deletion strategy is that if the resource-waybill-pricing relationship data that needs to be stored in Redis for a distribution resource exceeds the preset storage length, the candidate waybill whose scheduling times exceed the scheduling times threshold or the scheduling mark is set to old in the resource-waybill-pricing relationship data of the distribution resource already stored in Redis will be deleted first; if it still exceeds the preset storage length after the deletion operation, the waybill whose scheduling times exceed the scheduling times threshold or the scheduling mark is set to old in the matching results of this round of scheduling push that matches the distribution resource to be dispatched will continue to be deleted; if it still exceeds the preset storage length after the above deletion operation, the candidate waybill whose scheduling times do not exceed the scheduling times threshold or the scheduling mark is set to new in the resource-waybill-pricing relationship data of the distribution resource already stored in Redis will be deleted; if it still exceeds the preset storage length after the above deletion operation, the candidate waybill whose scheduling times do not exceed the scheduling times threshold or the scheduling mark is set to new in the matching results of this round of scheduling push will continue to be deleted, and the operation is carried out until the resource-waybill-pricing relationship data that needs to be stored in Redis for a distribution resource meets the preset storage length. Specifically, the method of deleting part of the waybills to be dispatched of the distribution resource according to the scheduling round and the preset storage length so that the resource-waybills-pricing relationship data of the distribution resource stored based on Redis meets the preset storage length includes: taking the existing waybills to be dispatched of the specific distribution resource stored based on Redis as the first waybills to be dispatched of the specific distribution resource; obtaining the waybills to be dispatched of the specific distribution resource in this round of scheduling as the second waybills to be dispatched of the specific distribution resource; determining the number of waybills to be dispatched corresponding to the specific distribution resource that exceeds the preset storage length according to the first waybills to be dispatched and the second waybills to be dispatched of the specific distribution resource as the number of waybills to be deleted that need to be deleted of the specific distribution resource in this round of scheduling; determining the first deleted waybills that can be deleted in the first waybills to be dispatched according to the dispatch type and scheduling round of the first waybills to be dispatched, and deleting at least part of the waybill data of the first deleted waybills from the resource-waybills-pricing relationship data of the specific distribution resource according to the number to be deleted. Further, after deleting the first deleted waybill, it is determined whether the number of deleted first deleted waybill meets the number to be deleted; if not, the second deleted waybill that can be deleted in the second to-be-dispatched waybill is determined according to the dispatch score ranking and dispatch type of the second to-be-dispatched waybill, and at least part of the second deleted waybill and its pricing information matching the specific distribution resource are deleted. Preferably, the first deleted waybill and the second deleted waybill are to-be-dispatched waybill whose dispatch round is greater than a preset dispatch number threshold and whose dispatch type is a diffusion type.Further, after deleting at least part of the second deleted waybill, determine whether the number of deleted first deleted waybill and second deleted waybill meets the number to be deleted; if not, determine the first waybill to be dispatched whose scheduling round indicates the first round of scheduling and whose dispatch type is the diffusion type as the third deleted waybill, and delete at least part of the third deleted waybill.

[0065] Please refer to Figure 3, the figure shows a waybill deletion process, which can be executed after determining the person-price relationship and before storing the person-price relationship in Redis. The so-called person-price relationship is an example of the resource-waybill-pricing relationship data, which can be specifically understood as the relationship data that characterizes the corresponding relationship between the distribution resources (such as riders), waybills and pricing information. The figure includes the following steps: S301, determine the person-price matching result. You can request the person-price matching result from the scheduling service end (or scheduling module), or determine the waybill to be assigned according to the waybill status, and then determine the distribution resources to be matched with the waybill to be assigned, and obtain the pricing information matched on each distribution resource to be matched with the waybill to be assigned, so as to obtain the person-price matching result. S302, determine whether the person-price relationship data that needs to be stored for a rider exceeds the person-price storage length. If not, execute S313; if so, execute S303. S303, obtain the number of waybills corresponding to the excess part, and then delete the waybills according to the number of waybills corresponding to the excess part until the person-price relationship data that needs to be stored meets the person-price storage length. S304, scheduling scoring and sorting, determine the scheduling order of the waybills to be dispatched, this sorting can be used to determine the display position of the candidate waybills, and can also be used to determine the deletion priority of the waybills. S305, delete the diffusion type person-price relationship data that already exists in Redis and is marked as old. The so-called old mark is the scheduling mark of the waybills to be dispatched that are not dispatched in the first round; the so-called diffusion type refers to the waybills to be dispatched that match one or more distribution resources according to the waybill diffusion method, which is consistent with the assignment type. The so-called assignment type refers to the waybills to be dispatched that are assigned to specific distribution resources according to the waybill assignment method. S306, determine whether the excess number of waybills has been deleted. If so, execute S313; if not, execute S307. S307, scheduling scoring and sorting, similar to the processing of S304. S308, delete the diffusion type person-price relationship data marked with old in this round of scheduling. That is, after deleting the diffused person-price relationship data of similar type that already exists in Redis and is not marked as old, if it still exceeds the storage length of the person-price, then continue to delete some person-price relationship data in this round of scheduling. S309, determine whether the number of waybills that exceed the limit has been deleted. If so, execute S313; if not, execute S310. S310, delete the diffused person-price relationship data of new type that already exists in Redis. The so-called new mark refers to the scheduling mark of the waybills to be dispatched in the first round of scheduling. S311, determine whether the number of waybills that exceed the limit has been deleted. If so, execute S313; if not, execute S312. S312, delete the diffused person-price relationship data of new type marked in this round of scheduling. S313, serialize the person-price. S314, store the person-price in Redis.

[0066] It should be noted that, in the absence of conflict, the features given in this embodiment and other embodiments of the present application can be combined with each other, and steps S101 and S102 or similar terms do not limit the steps to be executed sequentially.

[0067] So far, the method provided in this embodiment has been explained. The method is based on Redis to store resource-way order-pricing relationship data to provide a waybill dispatching solution with high availability and capable of supporting high concurrency scenarios, thereby solving the problem of improving the efficiency of waybill dispatching in high concurrency scenarios.

[0068] Based on the above embodiment, the second embodiment of the present application provides a waybill dispatching method, which is combined with Figure 4 The method is described in detail. For related parts, please refer to the corresponding part. Figure 4 The waybill dispatching method shown in the figure includes: step S401 to step S402.

[0069] Step S401, sending a waybill pull request to the fulfillment service end according to the location information of the target delivery resource and the order acceptance scope conditions.

[0070] The method provided in this embodiment is applied to the client corresponding to the distribution resource. The distribution resource uses the client to set the order range conditions, such as setting to accept waybills within 7 kilometers. The client generates a waybill pull request based on the location information of the target distribution resource and the order range conditions, and sends it to the fulfillment service end. The location information of the target distribution resource can be the information of the current location of the target distribution resource, or it can be the location information specified by the target distribution resource. The target distribution resource can send a waybill pull request in the start-up state or the non-start-up state to view the waybills in the corresponding grab order pool. The grab order pool can be understood as a set of waybills that can be displayed in the candidate waybill page of the distribution resource. The candidate waybill is the first waybill assigned to the distribution resource, or the second waybill diffused to the distribution resource. That is, a waybill to be assigned can be assigned to a specific distribution resource in the assignment mode, and can also be assigned to multiple matching candidate distribution resources in the diffusion mode. The assignment type of the waybill assigned in the assignment mode is the assignment type, and the assignment type of the waybill assigned in the diffusion mode is the diffusion type.

[0071] Step S402, obtain the candidate waybill of the target delivery resource returned by the fulfillment server in response to the waybill pull request, and display the candidate waybill; wherein the candidate waybill is the waybill data corresponding to the target delivery resource obtained in batches from the resource-waybill-pricing relationship data stored based on Redis.

[0072] In this embodiment, the client displays the candidate waybill on the candidate waybill display interface of the client. If the candidate waybill includes the dispatch sorting information of the candidate waybill, the display position of the candidate waybill on the candidate waybill display interface can be determined according to the dispatch sorting information.

[0073] Preferably, the method also includes: detecting that the target delivery resource selects to undertake the target waybill from the candidate waybills, sending an order acceptance request to the fulfillment service end for the target delivery resource to undertake the delivery of the target waybill; obtaining a successful order acceptance response to the order acceptance request, and adding the target waybill to the delivery task of the delivery resource.

[0074] In this embodiment, it also includes: detecting that the delivery resource triggers the refresh of the waybill or the client triggers the refresh of the waybill periodically, sending a waybill refresh request to the fulfillment server to request to obtain the current candidate waybill; obtaining the current candidate waybill returned by the fulfillment server in response to the waybill refresh request, and using the current candidate waybill to refresh the candidate waybill display interface.

[0075] So far, the method provided by this embodiment has been described. In the method, the client sends a waybill pull request to the fulfillment service end according to the location information of the target delivery resource and the order acceptance range conditions; the fulfillment service end, in response to the waybill pull request, obtains the waybill data corresponding to the target delivery resource in batches from the resource-waybill-pricing relationship data stored based on Redis, and returns it to the client and displays it as a candidate waybill for the target delivery resource. The resource-waybill-pricing relationship data stored based on Redis can support high-concurrency waybill pull processing, thereby solving the problem of improving the efficiency of waybill dispatching in high-concurrency scenarios.

[0076] Based on the above embodiments, the third embodiment of the present application provides a waybill dispatching system. Figure 5 The system is described in detail. For related parts, please refer to the corresponding parts. Figure 5 The waybill dispatching system shown in the figure includes: a client 501, a fulfillment server 502, and a scheduling server 503.

[0077] The client 501 is used to send a waybill pull request to the fulfillment server according to the location information of the target delivery resource and the order acceptance range conditions; obtain the candidate waybill of the target delivery resource returned by the fulfillment server in response to the waybill pull request; and display the candidate waybill on the candidate waybill display interface of the client. The client also initiates a refresh request to the fulfillment server to refresh the order grabbing pool in order to refresh the candidate waybill. The client can automatically initiate a refresh request at a fixed time, or receive the operation information of the target delivery resource and initiate a refresh request based on the operation information.

[0078] The fulfillment server 502 is used to obtain the waybill to be dispatched, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate delivery resources, provided by the scheduling server, and generate the resource-waybill-pricing relationship data of the delivery resources stored based on Redis; receive the waybill pull request sent by the client, and batch obtain the waybill data that matches the location information and order scope conditions of the target delivery resources from the resource-waybill-pricing relationship data stored based on Redis according to the waybill pull request, and send it to the client as the candidate waybill of the target delivery resource. The fulfillment server receives the person-price matching result pushed by the scheduling server through the assignment thread pool for processing the assignment process and / or the diffusion thread pool for processing the diffusion process. The person-price matching result refers to the waybill to be dispatched, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate delivery resources.

[0079] The dispatching service end 503 is used to obtain the waybill to be dispatched that is in the order acceptance state according to the waybill status, obtain the candidate distribution resources corresponding to the waybill to be dispatched according to the distribution area associated with the waybill to be dispatched, and determine the pricing information matching the candidate distribution resources for the waybill to be dispatched according to the pricing factor; and provide the waybill to be dispatched, the candidate distribution resources corresponding to the waybill to be dispatched, and the pricing information matching the candidate distribution resources to the fulfillment service end. The dispatching service end batch-acquires the produced waybill to be dispatched from the waybill library, obtains the distribution resources from the transportation capacity module, determines the candidate distribution resources matching the distribution resources for each waybill to be dispatched, and then obtains the pricing information of the waybill to be dispatched determined by the pricing module for each candidate distribution resource, thereby obtaining the matching results of the waybill to be dispatched, the distribution resources, and the pricing information, and pushes them to the fulfillment service end.

[0080] So far, the system provided in this embodiment has been described. The system obtains the waybill to be dispatched provided by the scheduling service end, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate delivery resources through the fulfillment service end, and generates the resource-waybill-pricing relationship data of the delivery resources stored based on Redis; receives the waybill pull request sent by the client, and batch obtains the waybill data that matches the location information and order acceptance range conditions of the target delivery resources from the resource-waybill-pricing relationship data stored based on Redis according to the waybill pull request, and sends it to the client as the candidate waybill of the target delivery resource. The scheduling service end obtains the waybill to be dispatched in the order acceptance state according to the waybill state, obtains the candidate delivery resources corresponding to the waybill to be dispatched according to the delivery area associated with the waybill to be dispatched, and determines the pricing information matching the candidate delivery resources for the waybill to be dispatched according to the pricing factor; and provides the waybill to be dispatched, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information matching the candidate delivery resources to the fulfillment service end. The client sends a waybill pull request to the fulfillment server based on the location information of the target delivery resource and the order acceptance range conditions; obtains the candidate waybill of the target delivery resource returned by the fulfillment server in response to the waybill pull request; and displays the candidate waybill on the candidate waybill display interface of the client. This provides a highly available waybill dispatching solution in high-concurrency scenarios.

[0081] Corresponding to the first embodiment, the fourth embodiment of the present application provides a waybill processing device. For the relevant parts, please refer to the description of the corresponding method embodiment. Figure 6 , the waybill processing device shown in the figure includes:

[0082] The relationship data generating unit 601 is used to obtain the waybill to be dispatched, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate delivery resources, and generate the resource-waybill-pricing relationship data of the delivery resources stored in Redis;

[0083] A data query unit 602 is used to batch-acquire candidate waybills of the target delivery resource from the resource-waybill-pricing relationship data according to the location information of the target delivery resource;

[0084] The data providing unit 603 is used to send the candidate waybills of the target delivery resource to the target client corresponding to the target delivery resource, so that the target client displays the candidate waybills.

[0085] Optionally, the resource-waybill-pricing relationship data of the distribution resource is hash mode data corresponding to the distribution resource, which is composed of a hash key and a storage object corresponding to the hash key; the relationship data generation unit 601 is specifically used to: determine a first prefix, and generate a key value of the hash key according to the first prefix and the distribution resource identifier of the distribution resource; generate a key value of the subkey according to the waybill identifier of the waybill to be dispatched, generate a storage value corresponding to the subkey according to the pricing information of the waybill to be dispatched that matches the distribution resource, and assemble the subkey and the storage value into a storage object corresponding to the hash key; store the hash key and the storage object corresponding to the hash key in a Redis database to form the resource-waybill-pricing relationship data of the distribution resource.

[0086] Optionally, the relationship data generation unit 601 is specifically used to: serialize the hash key and the storage object corresponding to the hash key based on a data serialization protocol, and store the serialized data obtained after the serialization process as the resource-waybill-pricing relationship data of the distribution resource in a Redis database.

[0087] Optionally, the pricing information includes: basic pricing information and scheduling information; wherein the scheduling information is used to determine the display order of the candidate waybills.

[0088] Optionally, the relationship data generation unit 601 is specifically used to: obtain the scheduling round of the waybill to be dispatched; obtain the preset storage length of the distribution resource; and delete some waybills to be dispatched of the distribution resource according to the scheduling round and the preset storage length, so that the resource-waybill-pricing relationship data of the distribution resource stored in Redis conforms to the preset storage length.

[0089] Optionally, the relationship data generation unit 601 is specifically used to: use the existing waybills to be dispatched of the specific distribution resource stored based on Redis as the first waybills to be dispatched of the specific distribution resource; obtain the waybills to be dispatched of the specific distribution resource in this round of scheduling as the second waybills to be dispatched of the specific distribution resource; determine the number of waybills to be dispatched corresponding to the specific distribution resource that exceeds the preset storage length based on the first waybills to be dispatched and the second waybills to be dispatched, as the number of waybills to be deleted that need to be deleted for the specific distribution resource in this round of scheduling; determine the first deleted waybill that can be deleted in the first waybill to be dispatched based on the dispatch type and scheduling round of the first waybill to be dispatched, and delete at least part of the waybill data of the first deleted waybill from the resource-waybill-pricing relationship data of the specific distribution resource according to the number to be deleted.

[0090] Optionally, the relationship data generation unit 601 is specifically used to: after deleting the first deleted waybill, determine whether the number of deleted first deleted waybill meets the number to be deleted; if not, determine the second deleted waybill that can be deleted in the second waybill to be dispatched according to the scheduling score ranking and dispatch type of the second waybill to be dispatched, and delete at least part of the second deleted waybill and its pricing information that matches the specific delivery resources.

[0091] Optionally, the first deleted waybill and the second deleted waybill are waybills to be dispatched whose scheduling round is greater than a preset scheduling number threshold and whose dispatch type is a diffusion type.

[0092] Optionally, the relationship data generation unit 601 is specifically used to: after deleting at least part of the second deleted waybill, determine whether the number of deleted first deleted waybill and second deleted waybill meets the number to be deleted; if not, determine the first waybill to be dispatched whose scheduling round indicates the first round of scheduling and whose dispatch type is a diffusion type as the third deleted waybill, and delete at least part of the third deleted waybill.

[0093] Optionally, the relationship data generation unit 601 is specifically used to: obtain a waybill to be dispatched that is in an order acceptance state according to the waybill status; obtain candidate delivery resources corresponding to the waybill to be dispatched according to the delivery area associated with the waybill to be dispatched; and determine pricing information that matches the candidate delivery resources for the waybill to be dispatched based on a pricing factor.

[0094] Optionally, the relationship data generation unit 601 is specifically used to: create an assignment thread pool and a diffusion thread pool; receive information about waybills to be assigned with delivery resources sent by the scheduling server through the threads in the assignment thread pool, and return assignment success to the scheduling server; receive information about waybills to be assigned without delivery resources sent by the scheduling server through the threads in the diffusion thread pool, and return diffusion success to the scheduling server.

[0095] Optionally, the data query unit 602 is specifically used to: receive a waybill pulling request sent by the target client for pulling candidate waybills for a target delivery resource; parse out an order acceptance range condition selected by the target delivery resource from the waybill pulling request; and for the target delivery resource, query from the resource-waybill-pricing relationship data to obtain a waybill whose distance from the location information of the target delivery resource meets the order acceptance range condition as a candidate waybill for the target delivery resource.

[0096] Optionally, the device also includes an order grabbing unit, which is used to: receive an order acceptance request from the target client for the target delivery resource to undertake the delivery of a target waybill among the candidate waybills; send a successful order acceptance response to the order acceptance request to the target client, and add the target waybill to the delivery task of the target delivery resource; and update the status of the target waybill to an accepted status.

[0097] Corresponding to the second embodiment, the fifth embodiment of the present application provides a waybill dispatching device. For the relevant parts, please refer to the description of the corresponding method embodiment. Figure 7 The waybill dispatching device shown in the figure comprises:

[0098] The order request unit 701 is used to send a waybill request to the fulfillment server according to the location information of the target delivery resource and the order acceptance range conditions;

[0099] Display unit 702 is used to obtain the candidate waybill of the target delivery resource returned by the fulfillment server in response to the waybill pull request, and display the candidate waybill; wherein the candidate waybill is the waybill data corresponding to the target delivery resource obtained in batches from the resource-waybill-pricing relationship data stored based on Redis.

[0100] Optionally, the device also includes an order grabbing unit, which is used to: detect that the target delivery resource selects to undertake the target waybill from the candidate waybills, and send an order acceptance request to the fulfillment service end for the target delivery resource to undertake the delivery of the target waybill; obtain a successful order acceptance response to the order acceptance request, and add the target waybill to the delivery task of the delivery resource.

[0101] Optionally, the candidate waybill is the first waybill assigned to the delivery resource, or the second waybill diffused to the delivery resource.

[0102] Optionally, the candidate waybill includes scheduling and sorting information of the candidate waybill; and the display unit is specifically used to determine the display position of the candidate waybill on the candidate waybill display interface according to the scheduling and sorting information.

[0103] Optionally, the device also includes a refresh unit, which is used to: detect that the delivery resource triggers the refresh of the waybill or the client triggers the refresh of the waybill periodically, send a waybill refresh request to the fulfillment server to request the current candidate waybill; obtain the current candidate waybill returned by the fulfillment server in response to the waybill refresh request, and use the current candidate waybill to refresh the candidate waybill display interface.

[0104] Based on the above embodiments, the sixth embodiment of the present application provides an electronic device. For the relevant parts, please refer to the corresponding description of the above embodiments. Figure 8 The electronic device shown in the figure includes: a memory 801 and a processor 802; the memory is used to store a computer program, and after the computer program is run by the processor, the method provided in the embodiment of the present application is executed.

[0105] Based on the above embodiments, the sixth embodiment of the present application provides a computer storage medium. For the relevant parts, please refer to the corresponding description of the above embodiments. Figure 8 The computer storage medium stores computer-executable instructions, and the computer-executable instructions are used to implement the method provided in the embodiment of the present application when executed by the processor.

[0106] In a typical configuration, an electronic device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0107] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0108] 1. Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by electronic devices. As defined in this article, computer-readable media does not include non-transitory media such as modulated data signals and carrier waves.

[0109] 2. Those skilled in the art should understand that the embodiments of the present application can be provided as methods, systems or computer program products. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0110] Although the present application is disclosed as above in the form of a preferred embodiment, it is not intended to limit the present application. Any technical personnel in this field may make possible changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall be based on the scope defined by the claims of the present application.

Claims

1. A waybill processing method, characterized in that: include: Obtain the waybill to be dispatched, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate delivery resources, and generate the resource-waybill-pricing relationship data of the delivery resources based on Redis storage; including: determining a first prefix, generating the key value of the hash key according to the first prefix and the delivery resource identifier of the delivery resource; generating the key value of the subkey according to the waybill identifier of the waybill to be dispatched, generating the storage value corresponding to the subkey according to the pricing information of the waybill to be dispatched that matches the delivery resource, assembling the subkey and the storage value into a storage object corresponding to the hash key; storing the hash key and the storage object corresponding to the hash key in the Redis database to form the resource-waybill-pricing relationship data of the delivery resources; Batch obtain candidate waybills of the target delivery resource from the resource-waybill-pricing relationship data according to the location information of the target delivery resource; The candidate waybills of the target delivery resource are sent to a target client corresponding to the target delivery resource, so that the target client displays the candidate waybills.

2. The method according to claim 1, characterized in that The storing of the hash key and the storage object corresponding to the hash key in the Redis database to form the resource-waybill-pricing relationship data of the distribution resource includes: The hash key and the storage object corresponding to the hash key are serialized based on a data serialization protocol, and the serialized data obtained after the serialization process is stored in a Redis database as resource-waybill-pricing relationship data of the distribution resource.

3. The method according to claim 1, characterized in that The pricing information includes: Basic pricing information and scheduling information; wherein the scheduling information is used to determine the display order of the candidate waybills.

4. The method according to claim 1, characterized in that: Also includes: Get the dispatch round of the waybill to be dispatched; Obtaining a preset storage length of the distribution resource; According to the scheduling round and the preset storage length, some waybills to be assigned of the distribution resource are deleted, so that the resource-waybill-pricing relationship data of the distribution resource stored in Redis conforms to the preset storage length.

5. The method according to claim 4, characterized in that The method of deleting part of the waybills to be assigned of the distribution resource according to the scheduling round and the preset storage length, so that the resource-waybills-pricing relationship data of the distribution resource stored in Redis conforms to the preset storage length, includes: The existing waybill to be dispatched of the specific delivery resource stored in Redis is used as the first waybill to be dispatched of the specific delivery resource; Obtaining the waybill to be assigned of the specific delivery resource in this round of scheduling as the second waybill to be assigned of the specific delivery resource; According to the first waybill to be dispatched and the second waybill to be dispatched of the specific delivery resource, the number of waybill to be dispatched corresponding to the specific delivery resource that exceeds the preset storage length is determined as the number of waybill to be dispatched that needs to be deleted for the specific delivery resource in this round of scheduling; According to the dispatch type and scheduling round of the first waybill to be dispatched, the first deleted waybill that can be deleted in the first waybill to be dispatched is determined, and at least part of the waybill data of the first deleted waybill is deleted from the resource-waybill-pricing relationship data of the specific distribution resource according to the quantity to be deleted.

6. The method according to claim 5, characterized in that After deleting the first deleted waybill, determining whether the quantity of the deleted first deleted waybill meets the quantity to be deleted; If not, determine the second deleted waybills that can be deleted in the second waybills to be dispatched based on the dispatch score ranking and dispatch type of the second waybills to be dispatched, and delete at least part of the second deleted waybills and their pricing information that matches the specific delivery resources.

7. The method according to claim 6, characterized in that The first deleted waybill and the second deleted waybill are waybills to be dispatched whose scheduling round is greater than a preset scheduling number threshold and whose dispatch type is a diffusion type.

8. The method according to claim 7, characterized in that Also includes: After deleting at least part of the second deleted waybills, determining whether the number of the deleted first deleted waybills and the second deleted waybills meets the number to be deleted; If not, determine the first waybill to be dispatched whose scheduling round indication is the first round scheduling and whose dispatch type is the diffusion type as the third deleted waybill, and delete at least part of the third deleted waybill.

9. The method according to claim 1, characterized in that: The obtaining of the waybill to be dispatched, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate delivery resources includes: Get the waybill to be dispatched in the order acceptance state according to the waybill status; Obtaining candidate delivery resources corresponding to the waybill to be dispatched according to the delivery area associated with the waybill to be dispatched; Determine pricing information matching the candidate delivery resource for the waybill to be assigned according to the pricing factor.

10. The method according to claim 1, characterized in that Also includes: Create a dispatch thread pool and a diffusion thread pool; Receiving, through the threads in the assignment thread pool, information of the waybill to be assigned with the distribution resources sent by the scheduling server, and returning the assignment success to the scheduling server; The information of the waybill to be dispatched but not assigned distribution resources sent by the scheduling service end is received through the threads in the diffusion thread pool, and a diffusion success is returned to the scheduling service end.

11. The method according to claim 1, characterized in that: The step of batch-acquiring candidate waybills of the target delivery resource from the resource-waybill-pricing relationship data according to the location information of the target delivery resource comprises: Receiving a waybill pulling request sent by the target client for pulling a candidate waybill of a target delivery resource; Parsing the order acceptance range conditions selected by the target delivery resource from the waybill pull request; For the target delivery resource, a waybill whose distance from the location information of the target delivery resource meets the order acceptance range condition is queried from the resource-waybill-pricing relationship data and is used as a candidate waybill for the target delivery resource.

12. The method according to claim 1, characterized in that Also includes: Receiving an order acceptance request from the target delivery resource to undertake the delivery of a target waybill among the candidate waybills, sent by the target client; A successful order acceptance response is sent to the target client for the order acceptance request, and the target waybill is added to the delivery task of the target delivery resource; the status of the target waybill is updated to an order-accepted status.

13. A waybill dispatching method, characterized in that: include: Send a shipping order request to the fulfillment server based on the location information of the target delivery resource and the order acceptance scope conditions; Obtain candidate waybills of the target delivery resource returned by the fulfillment service in response to the waybill pull request, and display the candidate waybills; wherein the candidate waybills are waybill data corresponding to the target delivery resource obtained in batches from resource-waybill-pricing relationship data stored based on Redis; wherein formation of the resource-waybill-pricing relationship data includes: determining a first prefix, and generating a key value of a hash key according to the first prefix and the delivery resource identifier of the delivery resource; generating a key value of a subkey according to the waybill identifier of the waybill to be dispatched, generating a storage value corresponding to the subkey according to pricing information of the waybill to be dispatched that matches the delivery resource, and assembling the subkey and the storage value into a storage object corresponding to the hash key; storing the hash key and the storage object corresponding to the hash key in a Redis database to form resource-waybill-pricing relationship data of the delivery resource.

14. The method according to claim 13, characterized in that Also includes: It is detected that the target delivery resource selects to undertake the target waybill from the candidate waybill, and sends an order acceptance request for the target delivery resource to undertake the delivery of the target waybill to the fulfillment service end; A successful order acceptance response is obtained for the order acceptance request, and the target waybill is added to the delivery task of the delivery resource.

15. The method according to claim 13, characterized in that The candidate waybill is the first waybill assigned to the delivery resource, or the second waybill diffused to the delivery resource.

16. The method according to claim 13, characterized in that The candidate waybills include scheduling and sorting information of the candidate waybills; The method further comprises: The display position of the candidate waybill on the candidate waybill display interface is determined according to the scheduling sorting information.

17. The method according to claim 13, characterized in that Also includes: When it is detected that the delivery resource triggers the refreshing of the waybill or the client triggers the refreshing of the waybill on a regular basis, a waybill refreshing request for requesting to obtain the current candidate waybill is sent to the fulfillment server; Obtain the current candidate waybill returned by the fulfillment service end in response to the waybill refresh request, and use the current candidate waybill to refresh the candidate waybill display interface.

18. A waybill dispatching system, characterized in that: include: Client, fulfillment server, and scheduling server; The client is used to send a waybill pull request to the fulfillment server according to the location information of the target delivery resource and the order acceptance range conditions; Obtaining a candidate waybill of the target delivery resource returned by the fulfillment service end in response to the waybill pull request; and displaying the candidate waybill on a candidate waybill display interface of the client; The fulfillment server is used to obtain the waybill to be dispatched, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information of the waybill to be dispatched that matches the candidate delivery resources, and generate resource-waybill-pricing relationship data of the delivery resources stored in Redis; Receive the waybill pull request sent by the client, and according to the waybill pull request, batch obtain the waybill data that matches the location information and order acceptance range conditions of the target distribution resource from the resource-waybill-pricing relationship data stored based on Redis, and send them to the client as candidate waybills of the target distribution resource; wherein, generating the resource-waybill-pricing relationship data of the distribution resource stored based on Redis includes: determining a first prefix, generating a key value of a hash key according to the first prefix and the distribution resource identifier of the distribution resource; generating a key value of a subkey according to the waybill identifier of the waybill to be dispatched, generating a storage value corresponding to the subkey according to the pricing information of the waybill to be dispatched that matches the distribution resource, and assembling the subkey and the storage value into a storage object corresponding to the hash key; storing the hash key and the storage object corresponding to the hash key in the Redis database to form the resource-waybill-pricing relationship data of the distribution resource; The dispatching service end is used to obtain a waybill to be dispatched that is in an order acceptance state according to the waybill status, obtain candidate delivery resources corresponding to the waybill to be dispatched according to the delivery area associated with the waybill to be dispatched, and determine pricing information matching the candidate delivery resources for the waybill to be dispatched according to pricing factors; and provide the waybill to be dispatched, the candidate delivery resources corresponding to the waybill to be dispatched, and the pricing information matching the candidate delivery resources to the fulfillment service end.

19. An electronic device, characterized in that: include: A memory, and a processor; the memory is used to store a computer program, and after the computer program is run by the processor, the method described in any one of claims 1 to 17 is executed.

20. A computer storage medium, characterized in that Computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, they are used to implement the method described in any one of claims 1 to 17.

Images