CN111340363B

CN111340363B - Mixed distribution method and device for same-city delivery orders

Info

Publication number: CN111340363B
Application number: CN202010119404.8A
Authority: CN
Inventors: 何柳华; 刘慧明; 王少锋; 何一纯
Original assignee: Dongpu Software Co Ltd
Current assignee: Dongpu Software Co Ltd
Priority date: 2020-02-26
Filing date: 2020-02-26
Publication date: 2022-06-24
Anticipated expiration: 2040-02-26
Also published as: CN111340363A

Abstract

The application discloses a mixed distribution method and a mixed distribution device for same-city delivery orders, wherein the method comprises the following steps: s1, responding to the order issuing action of the user terminal, judging that the order is a merchant order or a personal order, executing S2 if the order is the merchant order, and executing S4 if the order is the personal order; s2, inquiring whether a corresponding merchant of the user terminal has a binding team, if so, executing S3, otherwise, executing S4; s3, pushing the order to a distributor terminal of the binding team; s4, inquiring whether a bottom-pocket team exists in the area, if yes, executing S5, and if not, executing S6; s5, pushing the order to a scheduling background of the bottom-pocketed team; and S6, pushing the order to a distributor terminal near the sending position of the order. Therefore, the existing distribution modes are integrated and optimized, the existing distribution modes are supported, multiple distribution modes can be combined and used according to the requirements in practical application, and the distribution modes are optimized, the human efficiency is maximized, and the profit is maximized.

Description

Mixed distribution method and device for same-city delivery orders

Technical Field

The present application relates to the field of logistics technologies, and in particular, to a method and an apparatus for mixed allocation of delivery orders in the same city, an electronic device, and a computer storage medium.

Background

The logistics is a process of organically combining functions such as transportation, storage, loading and unloading, transportation, packaging, circulation processing, distribution, information processing and the like according to actual needs to meet user requirements in the process of flowing articles from a supply place to a receiving place. The development of the internet makes online shopping become a part of people's life, and for example, take-out, leg running, home arrival and the like distribute and go to home services, so that people can enjoy various conveniences without going out of home.

Based on the development of new retail markets, the same-city distribution scenes are more and more. The distribution scenes in the market at present are basically based on the following:

1. the merchant self-sends. This model requires the enterprise to recruit delivery personnel in advance and take charge of delivery in a dedicated area. The method has the advantages of high distribution timeliness and convenience in management. The defects are high cost, low distribution efficiency in the peak period of distribution and waste of personnel in the valley period.

2. Crowdsourcing. Crowd-sourced mode is the task of delivering a delivery directly to the local delivery market. The method has the advantages of high flexibility of distribution markets and great uncertainty of merchants. When the weather is bad or during the traditional holidays, the distribution market has obvious imbalance of supply and demand, the order delay rate is extremely high, and direct economic loss is brought to merchants.

3. And (5) carrying out regional contract. This model is where the merchant gives the delivery of the designated area to a third party in a collaborative manner. The method has the advantages of facilitating the management of enterprises and causing great uncertainty. The delivery timeliness, the service attitude of the deliverer and even the operation state of the third-party company all affect the delivery quality and bring uncertainty to the operation of the merchant.

Based on this, for the same city delivery scene, a more reasonable order distribution mode is needed.

Disclosure of Invention

The utility model aims to provide a with mixed distribution method of city delivery order form and device, electronic equipment, computer storage medium, integrate the accent to current multiple delivery mode, can use multiple delivery mode according to the demand combination in the practical application on the basis of supporting current delivery mode, the delivery process flexibility ratio is high, the ageing is high, the management of being convenient for reduces the uncertainty that brings for the trade company, the cost is also lower.

The purpose of the application is realized by adopting the following technical scheme:

in a first aspect, the present application provides a method for mixed allocation of orders delivered in the same city, including:

s1, responding to the action of the user terminal for issuing the order, judging that the order is a merchant order or a personal order, executing S2 if the order is the merchant order, and executing S4 if the order is the personal order;

s2, inquiring whether a corresponding merchant of the user terminal has a binding team, if so, executing S3, otherwise, executing S4;

s3, pushing the order to a distributor terminal of the binding team;

s4, inquiring whether a bottom-pocket team exists in the area, if yes, executing S5, and if not, executing S6;

s5, pushing the order to a scheduling background of the bottom-pocketed team;

and S6, pushing the order to a distributor terminal near the sending position of the order.

Like this, when the trade company sends an order, if there is corresponding group of binding, then the group of binding can see the order very first time, carries out the delivery operation simultaneously, if do not bind the group, then at first the propelling movement gives the group at the bottom of the pocket, if do not have the group at the bottom of the pocket then issue crowd-sourced market, carry out the delivery of robbing the order by crowd-sourced deliverer. When individuals issue a bill, if a bottom pocket team exists, the bill is firstly pushed to the bottom pocket team, otherwise, the bill is issued to a crowdsourcing market. Compared with crowdsourcing distributors, the binding team and the bottom-of-pocket team are convenient to manage, the bottom-of-pocket team can directly distribute orders which cannot be distributed by the binding team of a merchant, and the distribution is on-time and efficient. The crowdsourcing market, in addition to the two, can handle orders that are not under the responsibility of the binding team and the bottom-of-pocket team. Therefore, the existing distribution mode is integrated and optimized, the existing distribution mode is supported, multiple distribution modes can be combined and used according to requirements in practical application, the distribution process is high in flexibility and high in timeliness, management is facilitated, uncertainty brought to merchants is reduced, the cost is low, the distribution mode is optimized, the human efficiency is maximized, and the income is maximized.

Optionally, the method further comprises:

responding to the action of the user terminal selecting the binding team, generating a binding record and storing the binding record in a database;

the method for querying whether a binding team exists in a merchant corresponding to the user terminal in S2 includes:

inquiring whether a corresponding merchant of the user terminal has a binding team or not in a redis cache; if the redis cache does not exist, inquiring whether a binding team exists in a merchant corresponding to the user terminal in the database; and if the database exists, writing the queried binding team into a redis cache.

When a merchant and a team bind a cooperative relationship, a record of the binding relationship is inserted into the database. In order to improve the requesting efficiency and avoid repeated query operation, when the binding information of the merchant is queried, the binding relationship can be written into the redis cache, a certain time is reserved, and when the merchant places an order again, a corresponding binding team can be called from the redis cache. Through data comparison, simultaneous use of the redis cache and the database can greatly improve throughput, reduce response time and improve user experience.

Optionally, the S3 includes:

pushing the order to a distributor terminal of the binding team, and if the binding team does not accept the order within the first predetermined time period, executing S6.

When the binding team of the merchant does not deliver the order for a preset time, the order flows into a crowdsourcing market, and crowdsourcing distributors are enabled to complete the delivery, so that the order delivery can be guaranteed to be on-time and efficient.

Optionally, the S6 includes:

setting a second preset time length as a time label of a distributor terminal near the dispatching position of the order, wherein the second preset time length is expressed in the form of a positive integer;

every unit time length of interval, the time label is reduced by one;

and when the time label is zero, pushing the order to the distributor terminal.

In this way, the time length and interval of order pushing are controlled by the delay task of the rabbitMQ.

Optionally, in S6, the dispatch location of the order is represented in GEO trellis coded format and stored in redisGEO;

generating a hash key in a GEO grid coding format by using the current position of the distributor terminal, wherein the hash key is used as a first part of a redisGEO key;

dividing the current timestamp by the number of milliseconds corresponding to a second preset time length, rounding, recording as a first time point, adding one to the first time point to obtain a second time point, and taking the first time point and the second time point as a second part of the redisGEO key;

composing the first part and the second part of the redisGEO key into a redisGEO key and storing the redisGEO key into the redisGEO;

and if the current timestamp reaches the timestamp corresponding to the second time point, marking the state of the redisGEO key as invalid.

The hash key of the GEO grid may be selected as the first part of the key of redisGEO when entering the current location of the distributor. In order to ensure that the position uploaded by the distributor terminal is uploaded within the second preset time, the timestamp of the current system is divided by the number of milliseconds corresponding to the second preset time, and the integer is obtained to form a second part of the key of redisGEO; in order to ensure that each recorded current position of the distributor can be obtained within the second preset time, 2 time points, namely, the number of milliseconds corresponding to the GEO hash key + the timestamp/the second preset time and GEO hash key + (the number of milliseconds corresponding to the timestamp/the second preset time +1) can be stored. And independently setting the failure time of each redisGEO key by using the second time point, automatically failing due to expiration, and avoiding a large amount of garbage data in the redis cache from occupying cache resources.

Optionally, in S6, a hash key of a predetermined number of GEO grids is generated as a first part of the redisGEO key by using the current position of the distributor terminal and the position near the current position.

In order to avoid the boundary problem, when storing the redis, besides the GEO hash key of the current position, a plurality of GEO hash keys around the current position of the distributor can be stored, so that data can be conveniently called in the subsequent order distribution process.

Optionally, the S6 includes:

obtaining the delivery position of the order and the current position of the distributor terminal in redisGEO, and screening the distributor terminal with the distance from the delivery position within a preset distance;

and pushing the order to the screened deliverer terminal.

Therefore, distributors within the specified distance can be screened by utilizing redisGEO, if the range of the initially selected GEO hash is large, a configurable distance can be added at the position to realize linear screening within the preset range, the limitation of a simple GEO hash key is avoided, and the order is pushed to the distributors within the preset distance.

Optionally, the method further comprises: if the current time is not within the predetermined time period, adding the dispatchers of the binding team to a list of dispatchers available for scheduling by the bottom-of-pocket team.

The preset time period is, for example, a meal peak period, so that when the customer is not in the meal peak period, the takeaway delivery staff of the merchant binding team can deliver fresh orders, express orders and the like by crowdsourcing the identity of the delivery staff, the income of the delivery staff is improved, and the personnel use cost of the enterprise where the delivery staff is located is reduced.

In a second aspect, the present application provides a city delivery order mixing and dispensing device, comprising:

the order classification module is used for responding to the action of the user terminal for releasing the order, judging that the order is a merchant order or a personal order, calling the binding query module if the order is the merchant order, and calling the bottom-binding query module if the order is the personal order;

the binding query module is used for querying whether a binding team exists in a merchant corresponding to the user terminal, if so, the binding push module is called, and otherwise, the bottom-of-pocket query module is called;

the binding pushing module is used for pushing the order to a distributor terminal of the binding team;

the bottom pocket query module is used for querying whether a bottom pocket team exists in the area, if yes, the bottom pocket push module is called, and otherwise, the crowd-sourcing push module is called;

the bottom-pocket pushing module is used for pushing the order to a scheduling background of the bottom-pocket team;

and the crowdsourcing pushing module is used for pushing the order to a distributor terminal near the sending position of the order.

Optionally, the city delivery order mixed allocation device further includes a binding record storage module, configured to generate a binding record in response to an action of the user terminal selecting a binding team, and store the binding record in a database;

the method for inquiring whether the merchant corresponding to the user terminal has the binding team by the binding inquiry module comprises the following steps:

Optionally, the binding pushing module is configured to push the order to a distributor terminal of the binding team, and if the binding team does not accept the order within a first predetermined time, call the crowdsourcing pushing module.

Optionally, the crowdsourcing pushing module comprises:

the label setting unit is used for setting a second preset time length as a time label of a distributor terminal near a dispatching position of the order, and the second preset time length is expressed in a positive integer form;

the tag processing unit is used for subtracting one from the time tag every unit time length;

and the timing pushing unit is used for pushing the order to the distributor terminal when the time tag is zero.

Optionally, the crowdsourcing pushing module comprises:

a delivery position storage unit, configured to represent and store the delivery position of the order in a GEO trellis coded format;

the distributor position storage unit is used for generating a hash key in a GEO grid coding format by using the current position of the distributor terminal, and the hash key is used as a first part of the redisGEO key;

the time point saving unit is used for dividing the current timestamp by the number of milliseconds corresponding to a second preset time length, rounding the number of the milliseconds, recording the number of the milliseconds as a first time point, adding one to the first time point to obtain a second time point, and taking the first time point and the second time point as a second part of the redisGEO key;

the distributor information storage unit is used for forming a redisGEO key by the first part and the second part of the redisGEO key and storing the redisGEO key in the redisGEO;

and the state changing unit is used for marking the state of the redisGEO key as invalid if the current timestamp reaches the timestamp corresponding to the second time point.

Optionally, the crowdsourcing pushing module generates a hash key of a predetermined number of GEO-grids as a first part of the redisGEO key using the current location of the distributor terminal and its nearby location.

Optionally, the crowdsourcing pushing module comprises:

the screening unit is used for acquiring the delivery position of the order and the current position of the distributor terminal in redisGEO and screening the distributor terminal with the distance from the delivery position within a preset distance;

and the screening and pushing unit is used for pushing the order to the screened deliverer terminal.

Optionally, the city delivery order mixing and distributing device further comprises a dispatcher scheduling module, configured to add the dispatchers of the binding team to a dispatcher list available for scheduling by the bottom-of-the-pocket team if the current time is not within the predetermined time period.

In a third aspect, the present application provides a method for mixed allocation of delivery orders in the same city, including:

r1, responding to the action of the user terminal for issuing the order, judging that the order is a merchant order or a personal order, executing R2 if the order is a merchant order, and executing R4 if the order is a personal order;

r2, inquiring whether a corresponding merchant of the user terminal has a binding team, if so, executing R3, otherwise, executing R4;

r3, pushing the order to a distributor terminal of the binding team;

r4, pushing the order to a distributor terminal near the sending position of the order.

Like this, when the trade company sends an order, if there is corresponding group of binding, then the group of binding can see the order very first time, carries out the delivery operation simultaneously, if do not bind the group, then issues crowd-sourced market, is robbed the order and delivers by crowd-sourced delivery person. When the individual issues the order, the order is directly issued to the crowdsourcing market. The crowdsourcing market, in addition to binding teams, is able to handle orders that are not under the responsibility of the binding team. Therefore, the existing distribution mode is integrated and optimized, the existing distribution mode is supported, multiple distribution modes can be combined and used according to requirements in practical application, the distribution process is high in flexibility and high in timeliness, management is facilitated, uncertainty brought to merchants is reduced, the cost is low, the distribution mode is optimized, the human efficiency is maximized, and the income is maximized.

Optionally, the method further comprises:

the method for querying whether a binding team exists in a merchant corresponding to the user terminal in the R2 includes:

Optionally, the R3 includes:

pushing the order to a distributor terminal of the binding team, and executing R4 if the binding team does not accept the order within a first predetermined time period.

Optionally, the R4 includes:

every unit time length of interval, the time label is reduced by one;

and when the time label is zero, pushing the order to the distributor terminal.

Optionally, in the R4, the dispatch location of the order is represented in a GEO trellis coded format and stored in redisGEO;

composing the first part and the second part of the redisGEO key into a redisGEO key and storing the redisGEO key in a redisGEO;

Optionally, in R4, a hash key of a predetermined number of GEO grids is generated as a first part of the redisGEO key by using the current position of the distributor terminal and the position in the vicinity thereof.

Optionally, the R4 includes:

and pushing the order to the screened dispatcher terminal.

In a fourth aspect, the present application provides an electronic device, including a processor and a memory, where the processor executes computer instructions stored in the memory, so that the electronic device performs any one of the above methods for mixed allocation of delivery orders in city.

In a fifth aspect, the present application provides a computer storage medium comprising computer instructions that, when executed on an electronic device, cause the electronic device to perform any one of the above-mentioned methods for mixed allocation of in-town delivery orders.

Drawings

The present application is further described below with reference to the drawings and examples.

Fig. 1 is a schematic flow chart illustrating a method for mixed allocation of orders for in-town delivery according to a first embodiment;

fig. 2 is a flowchart illustrating a method of querying whether a binding team exists in a merchant corresponding to the user terminal in step S2 in fig. 1;

FIG. 3 is a schematic of runtime-response time when mysql database is used directly;

FIG. 4 is a schematic of runtime-response time for the concurrent use of the mysql database and the redis cache;

FIG. 5 is a first flowchart of step S6 in FIG. 1;

FIG. 6 is a schematic diagram of the operation of the rabbitMQ timer;

FIG. 7 is a flow diagram of approximate encoding of latitude 39.928167;

FIG. 8 is a schematic diagram of a combination of latitude and longitude codes to generate a new string;

FIG. 9 is a corresponding plot of decimal and base32 encoding;

FIG. 10 is a flowchart illustrating the method of step S6 in FIG. 1 for recording the dispatch location of the order and the current location of the distributor terminal in GEO grid format;

FIG. 11 is a second flowchart of step S6 of FIG. 1;

fig. 12 is a schematic structural diagram of a city delivery order mixing and distributing device 200 according to a second embodiment;

fig. 13 is a schematic diagram of a first structure of the crowdsourcing pushing module 260 in fig. 12;

fig. 14 is a schematic diagram of a second structure of the crowdsourcing pushing module 260 in fig. 12;

fig. 15 is a schematic diagram of a third structure of the crowdsourcing pushing module 260 in fig. 12;

fig. 16 is a flowchart illustrating a method for mixed allocation of orders for same city delivery according to a third embodiment.

In the figure: 200. the order mixing and distributing device is distributed in the same city; 210. an order classification module; 220. a binding query module; 230. binding a push module; 240. a bottom-pocketed query module; 250. a pocket bottom pushing module; 260. a crowdsourcing push module; 261a, a label setting unit; 261b, a label processing unit; 261c, a timing pushing unit; 262a, a delivery position holding unit; 262b, a distributor position storage unit; 262c, a time point storage unit; 262d, distributor information storage unit; 262e, a state change unit; 263a, a screening unit; 263b, a screening and pushing unit; 270. a binding record storage module; 280. a dispatcher scheduling module; 310. a user terminal; 320. a distributor terminal; 330. scheduling background of the bottom-pocketed team.

Detailed Description

The present application is further described with reference to the accompanying drawings and the detailed description, and it should be noted that, in the present application, the embodiments or technical features described below may be arbitrarily combined to form a new embodiment without conflict.

Referring to fig. 1, the first embodiment provides a method for mixed allocation of orders delivered in the same city, which includes steps S1-S6.

In this embodiment, the same city refers to the same region, the level of the region may be country, province, city, district, county, town, county, village, etc., and the same region generally refers to the same city, the same district, the same county, the same town or the same county. The order is a takeout order, an express order, a legging order and the like which are delivered in a city. For example, the present embodiment may be applied to distribution of takeout orders in beijing, or distribution of running orders in the haichi district in beijing. The hybrid allocation is an allocation mode in which a plurality of allocation methods such as self-service, crowd-sourcing, regional contracting, and the like are used in combination. The method of the embodiment is combined with an order system, so that the order can be rapidly, efficiently and reasonably distributed.

Step S1, responding to the action of the user terminal for issuing the order, judging that the order is a merchant order or a personal order, executing S2 if the order is a merchant order, and executing S4 if the order is a personal order.

The merchant order in this embodiment refers to an order issued by a merchant, the merchant generally refers to a large, medium, small, and micro enterprise that develops business activities and often generates distribution business, and the type of the merchant order may include takeaway type, express type, and the like. The individual order refers to an order issued by an individual, and the individual order is mostly express or leg-running. The user terminal is terminal equipment for ordering by a merchant or an individual, and can be a mobile phone, a tablet computer, a computer, intelligent wearing equipment or other intelligent terminal equipment.

And step S2, inquiring whether a corresponding merchant of the user terminal has a binding team, if so, executing S3, otherwise, executing S4.

The binding team refers to a delivery team pre-bound by the merchant. In this embodiment, each merchant corresponds to a unique binding team, so that orders generated by the merchant can be directly distributed to the binding team, and then distributed by a distributor of the binding team.

The merchant can register the merchant account through the merchant account APP (application) and establish a binding relationship with the distribution team. A manager of a delivery team can register the delivery team through a webpage or a client, a delivery person is added to the team, and the delivery person can install a delivery terminal APP on a delivery person terminal.

When a merchant and a team bind a cooperative relationship, a record of the binding relationship can be inserted into the database. In order to improve the requesting efficiency and avoid repeated query operation, when the binding information of the merchant is queried, the binding relationship can be written into the redis cache, a certain time is reserved, and when the merchant places an order again, a corresponding binding team can be called from the redis cache. Wherein the database may be a mysql database.

In a preferred case, before step S2, the method may further include: and responding to the action of selecting a binding team by the user terminal, generating a binding record and saving the binding record to a database.

The binding record may include a merchant corresponding to the user terminal and a binding team corresponding to the merchant, and may also include a time when the merchant and the binding team establish a binding relationship.

Referring to fig. 2, the method for querying whether a binding team exists in a merchant corresponding to the user terminal in S2 may include: inquiring whether a corresponding merchant of the user terminal has a binding team or not in a redis cache; if the redis cache does not exist, inquiring whether a binding team exists in a merchant corresponding to the user terminal in the database; and if the database exists, writing the queried binding team into a redis cache.

The S2 may write the queried binding record of the merchant and the binding team into a redis cache, where the binding record may be stored in the redis cache for a certain time, for example, 15 minutes or 20 minutes, and the binding record is automatically deleted after the expiration.

The S2 may further include: and when the merchant corresponding to the user terminal cancels the binding relation with the binding team, deleting the corresponding binding record in the database and the redis cache.

Fig. 3 is a schematic view of runtime-response time when the mysql database is directly used, and fig. 4 is a schematic view of runtime-response time when the mysql database and the redis cache are used simultaneously, in which the abscissa axis is runtime and the granularity is 500 msec, and the ordinate axis is response time and the unit is msec. The data is from a local terminal device, the running system of the terminal device is window 7, the processor model is i7-4790, and the memory capacity is 8G. As can be seen from the comparison between the data in fig. 3 and the data in fig. 4, the simultaneous use of the redis cache and the mysql database can greatly improve the throughput, reduce the response time, and improve the user experience.

And step S3, pushing the order to a distributor terminal of the binding team.

The distributor terminal is a terminal device used by a distributor, and can be a bargun, a mobile phone, a tablet computer, a computer, an intelligent wearable device or other intelligent terminal devices. The dispatchers from the unbound team do not receive the push for the order.

Wherein the S3 may include: pushing the order to a distributor terminal of the binding team, and if the binding team does not accept the order within the first predetermined time period, executing S6.

The first predetermined period of time is a predetermined period of time which may be 3 minutes, 5 minutes, 15 minutes, or the like. When the binding team of the merchant does not deliver the order for a preset time, the order flows into a crowdsourcing market, and crowdsourcing distributors are enabled to complete the delivery, so that the order delivery can be guaranteed to be on-time and efficient.

And step S4, inquiring whether a bottoming team exists in the area, if so, executing S5, and otherwise, executing S6.

The area is the area where the issuing position of the order is located. When the merchant does not bind the team, whether the bankruptcy team exists in the region can be inquired. The bottom-bound team refers to a third party team corresponding to a certain area or a plurality of areas, and the team can provide delivery service when no team is bound by a merchant. Some areas have bottom-pocketed teams and some areas may not have corresponding bottom-pocketed teams.

The method for inquiring whether the region in which the user terminal is located has a bottom team may be similar to the method for inquiring whether the merchant corresponding to the user terminal has a binding team, and details are not repeated here.

And step S5, pushing the order to a scheduling background of the bottom-pocketed team.

After the order is received by the bottom-pocketed team, the order can be distributed to a certain distributor through the scheduling background for distribution. The scheduling background of the bottom-pocketed team can also perform operations such as adding, deleting or modifying the distributor list.

Preferably, the method may further comprise: if the current time is not within the predetermined time period, adding the dispatchers of the binding team to a list of dispatchers available for scheduling by the bottom-of-pocket team.

The predetermined time period is a preset time period, which may be a meal peak period, such as 10: 00-14: 00. like this, when not being in at the peak of dinner, the takeaway distributor of trade company's binding team can be with crowdsourcing distributor's identity, and fresh order, express delivery order etc. are given birth to in the delivery, improve distributor's income, reduce the personnel selection cost of distributor place enterprise.

And step S6, pushing the order to a distributor terminal near the sending position of the order.

The method in the embodiment is suitable for a mixed distribution system for orders distributed in the same city, and the system can preset default pushing distance L, pushing times N and interval time t. And when the unit of T is minutes and the unit of L is kilometers, within the total push time T, the dispatchers within the range of L kilometers every T minutes receive order distribution notifications, and N is a positive integer. And the dispatchers within the pushing distance can perform order grabbing and dispatching.

Step S6 may employ a rabbitMQ to implement separate control of the push duration. The rabbitMQ is an open source Message agent software (also called Message-oriented middleware) that implements Advanced Message Queuing Protocol (AMQP). The rabbitMQ timer is used for setting a delay task and controlling the time length and the interval of order pushing, so that the preset time length can be ensured every interval, and each distributor can receive an order.

Referring to fig. 5, the S6 may include steps S611 to S613.

Step S611, for the distributor terminal near the dispatch location of the order, setting a second predetermined time length as a time label of the distributor terminal, where the second predetermined time length is expressed in a form of a positive integer.

The second predetermined period of time is a predetermined period of time, such as 3 minutes, 5 minutes, or 10 minutes, etc. The time tags may be represented by time, as shown in FIG. 6, where each time tag corresponds to a terminal of a distributor.

And step S612, subtracting one from the time label every unit time length.

With continued reference to fig. 6, the unit time period is a predetermined time period, such as 1 minute. Each time tag is automatically decremented by one at each 1 minute lapse. Executing the task once per minute by the rabbitMQ timer, if the time tag number is greater than 0, reducing the time number by one, and re-throwing the time tag number into the delay queue, and when the time is equal to 0, calling the step S613 to complete the task.

Step S613, when the time stamp is zero, pushing the order to the distributor terminal.

Step S6 may record the delivery location of the order, the current location of the distributor terminal, using the format of the GEO grid. The following warp and weft values are given: (116.389550, 39.928167) performing an algorithmic description of the GEO mesh.

The process of approximating and coding the latitude 39.928167 with the latitude interval of the earth as [ -90,90] comprises the steps a-h.

Step a, dividing the interval of [ -90,90] into [ -90,0), [0,90], namely left and right intervals, and determining 39.928167 to belong to the right interval of [0,90], namely 1;

step b, dividing the interval [0,90] into two intervals [0,45 ], [45,90], and determining 39.928167 as the left interval [0,45 ] marked as 0;

c, recursion the above process 39.928167 always belongs to a certain interval [ a, b ], and the interval [ a, b ] is always reduced with each iteration and approaches 39.928167 more and more;

step d, recording 0 if the given latitude 39.928167 belongs to the left interval and 1 if it belongs to the right interval, the length of the sequence being related to the number of divisions of the given interval, as shown in fig. 7;

step e, the earth longitude interval is [ -180,180], and longitude 116.389550 can be encoded. By the above calculation, the latitude-generated code is 110100101100010, and the longitude-generated code is 101110001100011;

step f, merging: longitude is set at even positions, latitude is set at odd positions, and 2 strings of codes are combined to generate a new string as shown in figure 8;

step g, according to fig. 9, firstly converting 11100111010010001111000001101 into decimal corresponding to 28, 29, 4, 15, 0, 13, the base32 code corresponding to decimal is wx4g0e, and the code is used as the GEO grid code of the longitude and latitude;

and h, converting the GEO grid codes into longitude and latitude by a decoding algorithm which is opposite to the GEO grid codes.

The magnitude of the GEO-grid design variation may be selected in the following ranges: precision 1: 2500 km; and 2, precision: 630 km; precision 3: 78 km; and (4) precision: 30 km; and precision 5: 2.4 km; and precision 6: 610 m; and (7) precision: 76 m; and precision 8: 19m, respectively. In practical application of the embodiment, the precision 4: 30 km. The reference value of the distribution range in the same city is 3-5 km, and 30km is selected, so that sufficient configuration space can be ensured.

Referring to fig. 10, the method for recording the delivery location of the order and the current location of the distributor terminal in the GEO grid format in S6 may include steps S621 to S625.

Step S621, the dispatch location of the order is expressed in GEO trellis code format and stored in redisGEO.

redisGEO is a cache area for GEO mesh format data.

Step S622, generating a hash key in GEO mesh coding format as a first part of the redisGEO key using the current position of the distributor terminal.

The hash key of the GEO grid may be selected as the first part of the key of redisGEO when entering the current location of the distributor. hash is a function of compressing a message of arbitrary length to a message digest of some fixed length, and can transform an input of arbitrary length into an output of fixed length, which is a hash value, by a hash algorithm. Since different inputs may hash to the same output, it is not possible to determine a unique input value from the hash value. The hash key is a key of the hash function. redisGEO key is a key to redisGEO.

In a preferred case, the S622 may include: and generating a hash key of a predetermined number of GEO grids by using the current position of the distributor terminal and the position nearby the current position as a first part of the redisGEO key.

In order to avoid the boundary problem, when storing the redis, besides the GEO hash key of the current position, a plurality of GEO hash keys around the current position of the distributor can be stored, so that data can be conveniently called in the subsequent order distribution process. The predetermined number is a preset positive integer, for example 6, 8 or 10.

Step S623, dividing the current timestamp by the number of milliseconds corresponding to a second preset time length, rounding, recording as a first time point, adding one to the first time point to obtain a second time point, and taking the first time point and the second time point as a second part of the redisGEO key.

In order to ensure that the position uploaded by the distributor terminal is uploaded within the second preset time, the timestamp of the current system is divided by the number of milliseconds corresponding to the second preset time, and the integer is obtained to form a second part of the key of the redisGEO; in order to ensure that each recorded current position of the distributor can be obtained within the second preset time, 2 time points, namely, the number of milliseconds corresponding to the GEO hash key + the timestamp/the second preset time and GEO hash key + (the number of milliseconds corresponding to the timestamp/the second preset time +1) can be stored.

The time stamp is the total number of milliseconds from greenwich time 1970, 01, 00 hours 00 minutes 00 seconds (beijing time 1970, 01, 08 hours 00 seconds) to the present. The second predetermined period of time is a predetermined period of time, which may be 5 minutes or 10 minutes. When the second predetermined time period is 5 minutes, the corresponding number of milliseconds is 300000.

Step S624, the first part and the second part of the redisGEO key form the redisGEO key and store the redisGEO key.

Step S625, if the current timestamp reaches the timestamp corresponding to the second time point, the state of the redisGEO key is marked as invalid.

The redisGEO stores the position information of a plurality of distributor terminals, the expiration time of each redisGEO key is independently set by using the second time point, expiration is automatically expired, and a large amount of garbage data in the redis cache is prevented from occupying cache resources.

Referring to fig. 11, the S6 may include steps S631 to S632.

Step S631, obtaining the delivery position of the order and the current position of the distributor terminal in redisGEO, and screening the distributor terminals whose distance from the delivery position is within a predetermined distance.

The predetermined distance is a predetermined distance, for example, 1 km, 3 km, or 5 km.

And step S632, pushing the order to the screened distributor terminal.

Therefore, distributors within the specified distance can be screened by utilizing redisGEO, if the range of the initially selected GEO hash is large, a configurable distance can be added at the position to realize linear screening within the preset range, the limitation of a simple GEO hash key is avoided, and the order is pushed to the distributors within the preset distance. By utilizing the quick response of redisGEO, the order distribution efficiency is greatly improved.

In a first embodiment, the bottom-of-pocket team can directly deliver orders which cannot be delivered by the binding team of the merchant, and the delivery is guaranteed to be on-time and efficient. The crowdsourcing market, in addition to the two, can handle orders that are not under the responsibility of the binding team and the bottom-of-pocket team. Therefore, the existing distribution mode is integrated and optimized, the existing distribution mode is supported, multiple distribution modes can be combined and used according to the requirements in practical application, the distribution process is high in flexibility and timeliness, management is facilitated, uncertainty brought to merchants is reduced, cost is low, the distribution mode is optimized, the human efficiency is maximized, and benefits are maximized; the multi-dimensional configuration, the pushing time, the pushing times, the pushing range and the like are supported, and orders within one or more preset distances can be pushed to the distributor terminal within each preset time length; by using the most popular current technologies, including redis, rabbitMQ, GEO hash algorithm and the like, millisecond-level response can still be achieved at the level of hundreds of thousands of users, and the order distribution efficiency is improved.

Referring to fig. 12, a second embodiment provides a mixed distribution device 200 for orders delivered in the same city, including an order classification module 210, a binding query module 220, a binding push module 230, a bottom query module 240, a bottom push module 250, and a crowd-sourcing push module 260, where the order classification module 210 performs data interaction with the binding query module 220 and the bottom query module 240 respectively, the binding query module 220 further performs data interaction with the binding push module 230 and the bottom query module 240 respectively, and the bottom query module 240 further performs data interaction with the bottom push module 250 and the crowd-sourcing push module 260 respectively.

The order classification module 210 is configured to determine that the order is a merchant order or a personal order in response to an action of the user terminal 310 issuing the order, invoke the binding query module 220 if the order is a merchant order, and invoke the bottom-of-the-book query module 240 if the order is a personal order.

The binding query module 220 is configured to query whether a binding team exists in a merchant corresponding to the user terminal 310, if so, invoke the binding push module 230, otherwise, invoke the bottom-of-pocket query module 240.

The binding push module 230 is used to push the order to the dispatcher terminal 320 of the binding team.

The bottom-of-pocket query module 240 is configured to query whether a bottom-of-pocket team exists in the area, if so, invoke the bottom-of-pocket push module 250, otherwise, invoke the crowd-sourcing push module 260.

The pocket bottom pushing module 250 is configured to push the order to a scheduling back-end 330 of the pocket bottom team.

The crowd-sourced pushing module 260 is used to push the order to a distributor terminal 320 near the dispatch location of the order.

With continued reference to fig. 12, the same city delivery order mix dispensing apparatus 200 may further include a binding record saving module 270 for generating and saving a binding record to a database in response to an action of the user terminal 310 selecting a binding team. The binding record keeping module 270 performs data interaction with the binding query module 220.

The method for the binding inquiry module 220 to inquire whether a binding team exists in the merchant corresponding to the user terminal 310 includes: inquiring whether a corresponding merchant of the user terminal 310 has a binding team in a redis cache; if the redis cache does not exist, inquiring whether a binding team exists in a corresponding merchant of the user terminal 310 in the database; and if the database exists, writing the queried binding team into a redis cache.

The binding push module 230 may be configured to push the order to the distributor terminal 320 of the binding team, and to invoke the crowd-sourcing push module 260 if the binding team does not accept the order within a first predetermined length of time.

Referring to fig. 13, the crowdsourcing pushing module 260 may include a tag setting unit 261a, a tag processing unit 261b, and a timing pushing unit 261c, where the tag setting unit 261a performs data interaction with the tag processing unit 261b, and the tag processing unit 261b further performs data interaction with the timing pushing unit 261 c.

The tag setting unit 261a is configured to set a second predetermined time period as a time tag of the deliverer terminal 320 for the deliverer terminal 320 near the dispatch location of the order, and the second predetermined time period is expressed in the form of a positive integer.

The tag processing unit 261b is configured to decrement the time tag by one every interval unit duration.

The timing pushing unit 261c is configured to push the order to the distributor terminal 320 when the time stamp is zero.

Referring to fig. 14, the crowdsourcing pushing module 260 may include a dispatch position saving unit 262a, a distributor position saving unit 262b, a time point saving unit 262c, a distributor information saving unit 262d, and a state changing unit 262e, where the distributor position saving unit 262b and the time point saving unit 262c respectively perform data interaction with the distributor information saving unit 262d, and the distributor information saving unit 262d also performs data interaction with the state changing unit 262 e.

The dispatch location storage unit 262a is used to represent and store the dispatch location of the order in GEO trellis coded format.

The distributor location saving unit 262b is configured to generate a hash key in GEO trellis code format as a first part of the redisGEO key using the current location of the distributor terminal 320.

The time point saving unit 262c is configured to divide the current timestamp by the number of milliseconds corresponding to the second predetermined time duration, perform rounding, record the result as a first time point, add one to the first time point to obtain a second time point, and use the first time point and the second time point as a second part of the redisGEO key.

The distributor information storage unit 262d is configured to combine the first part and the second part of the redisGEO key into a redisGEO key and store the redisGEO key in the redisGEO.

The state changing unit 262e is configured to mark the state of the redisGEO key as invalid if the current timestamp reaches the timestamp corresponding to the second time point.

Preferably, the crowdsourcing pushing module 260 may generate a hash key of a predetermined number of GEO grids as a first part of the redisGEO key using the current location of the distributor terminal 320 and its nearby location.

Referring to fig. 15, the crowdsourcing pushing module 260 may include a screening unit 263a, a screening pushing unit 263b, and the screening unit 263a and the screening pushing unit 263b perform data interaction.

The filtering unit 263a is configured to obtain the dispatch location of the order and the current location of the distributor terminal 320 in redisGEO, and filter the distributor terminal 320 whose distance from the dispatch location is within a predetermined distance.

The screening pushing unit 263b is configured to push the order to the screened dispatcher terminal 320.

With continued reference to FIG. 12, the city delivery order mix dispenser 200 may further include a dispatcher scheduling module 280 for adding dispatchers of the binding team to a list of dispatchers available for scheduling by the bottom team if the current time is not within a predetermined time period. The dispatcher scheduling module 280 interacts with the scheduling back-office 330 of the bottom-of-pocket team for data.

Referring to FIG. 16, the third embodiment provides a method for mixed allocation of orders distributed in the same city, which includes steps R1-R4.

And step R1, responding to the action of the user terminal for issuing the order, judging that the order is a merchant order or a personal order, executing R2 if the order is the merchant order, and executing R4 if the order is the personal order.

And step R2, inquiring whether a corresponding merchant of the user terminal has a binding team, if so, executing R3, otherwise, executing R4.

And step R3, pushing the order to a distributor terminal of the binding team.

And step R4, pushing the order to a distributor terminal near the sending position of the order.

In some embodiments, the method may further comprise: responding to the action of the user terminal selecting the binding team, generating a binding record and storing the binding record in a database; the method for querying whether a binding team exists in a merchant corresponding to the user terminal in the R2 may include: inquiring whether a corresponding merchant of the user terminal has a binding team or not in a redis cache; if the redis cache does not exist, inquiring whether a binding team exists in a merchant corresponding to the user terminal in the database; and if the database exists, writing the queried binding team into a redis cache.

In some embodiments, the R3 may include: pushing the order to a distributor terminal of the binding team, and executing R4 if the binding team does not accept the order within a first predetermined time period.

In some embodiments, the R4 may include: setting a second preset time length as a time label of a distributor terminal near the dispatching position of the order, wherein the second preset time length is expressed in the form of a positive integer; every unit time length of interval, the time label is reduced by one; and when the time label is zero, pushing the order to the distributor terminal.

In some embodiments, in the R4, the dispatch location of the order may be represented in GEO trellis coded format and stored in redisGEO; generating a hash key in a GEO grid coding format by using the current position of the distributor terminal as a first part of the redisGEO key; dividing the current timestamp by the number of milliseconds corresponding to a second preset time length, rounding, recording as a first time point, adding one to the first time point to obtain a second time point, and taking the first time point and the second time point as a second part of the redisGEO key; composing the first part and the second part of the redisGEO key into a redisGEO key and storing the redisGEO key into the redisGEO; and if the current timestamp reaches the timestamp corresponding to the second time point, marking the state of the redisGEO key as invalid.

In some embodiments, in the R4, a hash key of a predetermined number of GEO grids may be generated as a first part of a redisGEO key using the current location of the distributor terminal and its vicinity.

In some embodiments, the R4 may include: obtaining the delivery position of the order and the current position of the distributor terminal in redisGEO, and screening the distributor terminal with the distance from the delivery position within a preset distance; and pushing the order to the screened dispatcher terminal.

In some embodiments, the method may further comprise: if the current time is not within the predetermined time period, adding the dispatchers of the binding team to a list of dispatchers available for scheduling by the bottom-of-pocket team.

A fourth embodiment provides an electronic device comprising a processor and a memory, wherein the processor executes computer instructions stored in the memory to cause the electronic device to perform any one of the above-described methods for mixed allocation of orders for co-located delivery.

A fifth embodiment provides a computer storage medium comprising computer instructions that, when executed on an electronic device, cause the electronic device to perform any of the above-described methods for mixed allocation of orders for co-located delivery.

The foregoing description and drawings are only for purposes of illustrating the preferred embodiments of the present application and are not intended to limit the present application, which is, therefore, to the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present application.

Claims

1. A mixed distribution method for on-city delivery orders is characterized by comprising the following steps:

s3, pushing the order to a distributor terminal of the binding team;

s5, pushing the order to a scheduling background of the bottom-pocketed team;

s6, pushing the order to a distributor terminal near the sending position of the order;

wherein the S6 includes:

setting a second preset time length as a time label of a distributor terminal near the dispatching position of the order, wherein the second preset time length is a preset time length and is expressed in the form of a positive integer;

every unit time length of interval, the time label is reduced by one;

and when the time label is zero, pushing the order to the distributor terminal.

2. The method of claim 1, further comprising:

responding to the action of selecting a binding team by the user terminal, generating a binding record and storing the binding record in a database;

3. The city delivery order mix-distribution method of claim 1, wherein the S3 includes:

pushing the order to a distributor terminal of the binding team, and if the binding team does not accept the order within a first preset time period, executing S6, wherein the first preset time period is a preset time period.

4. The city delivery order mixed distribution method according to claim 1, wherein in S6, the dispatch location of the order is represented in GEO grid code format and stored in redisGEO;

dividing the current timestamp by the number of milliseconds corresponding to a second preset time length, rounding, recording as a first time point, adding one to the first time point to obtain a second time point, and taking the first time point and the second time point as a second part of the redisGEO key, wherein the second preset time length is a preset time length;

5. The city delivery order mixed distribution method according to claim 4, wherein in the S6, a hash key of a predetermined number of GEO grids is generated as a first part of the redisGEO key using the current position of the dispenser terminal and the vicinity thereof.

6. The city delivery order mix distribution method according to claim 4, wherein the S6 includes:

acquiring a delivery position of the order and the current position of the distributor terminal in redisGEO, and screening the distributor terminal with the distance from the delivery position within a preset distance;

and pushing the order to the screened deliverer terminal.

7. The method of claim 1, further comprising: if the current time is not within the predetermined time period, adding the dispatchers of the binding team to a list of dispatchers available for scheduling by the bottom-of-the-pocket team.

8. A city delivery order mix dispensing apparatus, comprising:

the order classification module is used for responding to the action of the user terminal for releasing the order, judging that the order is a merchant order or a personal order, calling the binding query module if the order is the merchant order, and calling the bottom-seeking query module if the order is the personal order;

the pocket bottom pushing module is used for pushing the order to a scheduling background of the pocket bottom team;

the crowdsourcing pushing module is used for pushing the order to a distributor terminal near the sending position of the order;

wherein the crowdsourcing push module comprises:

the label setting unit is used for setting a second preset time length as a time label of a distributor terminal near the dispatching position of the order, and the second preset time length is expressed in the form of a positive integer;

9. A method for mixed allocation of orders for same-city delivery, comprising:

r3, pushing the order to a distributor terminal of the binding team;

r4, pushing the order to a distributor terminal near the sending position of the order;

wherein R4 includes:

every unit time length of interval, the time label is reduced by one;

and when the time label is zero, pushing the order to the distributor terminal.