WO2018095308A1 - 一种业务量的预测方法及装置 - Google Patents

一种业务量的预测方法及装置 Download PDF

Info

Publication number
WO2018095308A1
WO2018095308A1 PCT/CN2017/112069 CN2017112069W WO2018095308A1 WO 2018095308 A1 WO2018095308 A1 WO 2018095308A1 CN 2017112069 W CN2017112069 W CN 2017112069W WO 2018095308 A1 WO2018095308 A1 WO 2018095308A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
historical
restaurant
type
time
Prior art date
Application number
PCT/CN2017/112069
Other languages
English (en)
French (fr)
Inventor
范驰
孟超峰
罗晗
隋宜桓
窦方钰
Original Assignee
口碑控股有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 口碑控股有限公司 filed Critical 口碑控股有限公司
Priority to US16/463,920 priority Critical patent/US11443251B2/en
Publication of WO2018095308A1 publication Critical patent/WO2018095308A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • G06Q30/0202—Market predictions or forecasting for commercial activities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/12—Hotels or restaurants
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0125—Traffic data processing
    • G08G1/0129—Traffic data processing for creating historical data or processing based on historical data

Definitions

  • the present application relates to the field of information technology, and in particular, to a method and an apparatus for predicting traffic volume.
  • the load of the server is mainly generated during the execution of the service, and is not generated when the business result is generated. That is, the actual traffic generation time should be at the time when the service starts to be executed, instead of At the moment when the business result is generated at the end of the execution, the actual business peak arrival time should be the time when a large number of services start to be executed, not the time when the business result is generated at the end of execution.
  • the execution time of different types of services is also different.
  • the time required for users to operate is different. Therefore, for services with shorter execution time, services can be generated faster.
  • the calculated traffic volume is not too low relative to the actual traffic volume, and the statistical service peak arrival time is not too lagging relative to the actual service peak arrival time. , may still be within the acceptable range, and for a business with a long execution time, the determined business volume is too low relative to the actual business volume, and the determined business peak arrival time is relative to the actual business peak arrival time. There is also a large lag.
  • the moment when the server receives the login request is the time when the service starts to be executed, and after the server receives the login request, the user name and password are verified to be correct.
  • Performing the login and generating the login result according to the prior art method, it is acceptable to use the generated number of login results as the traffic at the current time.
  • the user needs to perform a large number of inquiries, and also needs to submit an order, a payment, and the like. If the number of payment results counted at the current time is used as the current amount of business, it will obviously The determined business volume is lower than the actual business volume.
  • the server will collect the payment according to the successful payment payment by the courier.
  • the business volume and when the user uses the express delivery service B to transport the goods, he can directly contact the courier by telephone, text message, etc., to instruct the customer to pick up the goods after picking up the goods, and to express the delivery to the receiving party, the receiving party After the payment is made, the courier can submit the payment result to the server after the payment is successful.
  • the amount of service determined by the prior art is significantly lower than the actual amount of traffic, and if the number of payment results is reached, the number reaches the peak. The moment to determine the arrival time of the business peak is also lagging for the express delivery service B.
  • the embodiment of the present invention provides a method and a device for predicting traffic volume, which are used to solve the problem that the current time traffic volume determined in the prior art is inaccurate and is not conducive to server operation and maintenance.
  • a method of predicting traffic volume including:
  • the peak value of the number of payments for the second service in history is determined as a historical peak
  • a method of predicting traffic volume including:
  • the first type of restaurant is used to provide a catering business that is shorter than a preset time from placing an order to paying.
  • the second type of restaurant is used to provide a catering business that takes longer than the preset duration from order to payment.
  • a forecasting device for traffic volume comprising:
  • a time determination module determining a time at which the number of payment for the first service reaches a peak as the designated time
  • the historical peak module determines the peak number of payments for the second service in history based on the saved history as a historical peak
  • the traffic module predicts the traffic of the second service at the specified time, where the first service and the second service belong to the same type of service, and the execution manner of the first service and the second
  • the service execution time of the first service is shorter than the preset duration, and the service execution time of the second service is longer than the preset duration.
  • a forecasting device for traffic volume comprising:
  • Receiving module receiving payment information for the first type of restaurant
  • a time determination module determining, according to each payment information for the first type of restaurant, a time at which the number of payment for the first type of restaurant reaches a peak as a designated time;
  • the historical peak module determines the historical peak number of payments for the second type of restaurant as a historical peak
  • a traffic module predicting a traffic volume of the second type of restaurant at the specified time according to the historical peak, wherein the first type of restaurant is used to provide a time from placing an order to paying for less than a preset duration In the catering business, the second type of restaurant is used to provide catering business from the time of placing an order to paying for a predetermined period of time.
  • the application server determines the time when the number of payment of the first service reaches the peak time as the specified time, and determines the possible traffic volume of the second service at the current time according to the peak value of the number of payment times of the second service recorded in the history. Compared with the prior art, even if the time when the number of payment times reaches a peak is relatively lagging, the present application can more accurately determine the traffic volume of the service at the current time, thereby providing a more accurate operation and maintenance process for the server. Reference.
  • FIG. 1 is a process of predicting traffic volume according to an embodiment of the present application
  • 2a is an architecture on which a restaurant traffic prediction process according to an embodiment of the present application is based;
  • FIG. 2b is a process for predicting a restaurant traffic volume according to an embodiment of the present application.
  • FIG. 3 is a schematic diagram of traffic volume in an actual application according to an embodiment of the present application.
  • FIG. 4 is a schematic structural diagram of a device for predicting traffic volume according to an embodiment of the present application.
  • FIG. 5 is a schematic structural diagram of another apparatus for predicting traffic volume according to an embodiment of the present disclosure.
  • the embodiment of the present application provides a method for predicting the traffic volume.
  • the services with different execution modes are respectively referred to as the first service and the second service, respectively.
  • FIG. 1 is a process for predicting traffic volume according to an embodiment of the present application, which specifically includes the following steps:
  • S101 Determine a time when the number of payment for the first service reaches a peak as the designated time.
  • the determination of the number of payment of the first service may be implemented by a server of the corresponding service provider, where the service provider includes but is not limited to: a website, a bank, a telecommunication operator, or the like. .
  • the user can use a certain service (that is, the first service) provided by the service provider by sending a service request to the server of the service provider (hereinafter referred to as the server), and accordingly, the user uses the item.
  • the business usually pays the corresponding business cost (eg, pays the corresponding amount), and the server records the business cost paid by the user. For example, in the process of using the express delivery service, the user pays the freight, and the corresponding courier submits the payment result to the courier website server, and the payment is recorded on the server.
  • the number of payment of the first service will reach a peak at a certain time (ie, a specified time), wherein the peak value should be understood as a service within a certain time period.
  • a certain time ie, a specified time
  • the peak value should be understood as a service within a certain time period.
  • the maximum value of the quantity in practical applications, there may be more than one peak in the whole time period. Not here This constitutes a limitation on the present application.
  • S102 Determine, according to the saved history, a peak of the number of payment times for the second service in history, as a historical peak.
  • the second service is also provided by the corresponding service provider.
  • the express service B in the foregoing example belongs to the same service as the first service, but the two services are executed differently.
  • the statistics of the peak value of the number of payment times of the first service by the server are relatively timely, but the statistics of the peak value of the number of payment times by the server for the second service are relatively lagging.
  • the server usually records the services that it performs or completes, and records the number of payments of different services at each moment. As a historical record, then according to the historical record, The peak of the number of payments of the second service in history can be determined.
  • the traffic of the second service at the specified time may be estimated, that is, the following step S103 is performed.
  • S103 Predict an actual traffic volume of the second service at the specified moment according to the historical peak.
  • the first service and the second service belong to the same type of service, and the execution manner of the first service is different from the execution manner of the second service, and the service execution time of the first service is shorter than the preset.
  • the duration of the service of the second service is longer than the preset duration.
  • the amount of traffic can be considered as the number of services that the server is executing according to the received service request and does not generate a payment result.
  • the traffic volume of the second service at the specified time may be used as a reference for subsequent operations (such as server maintenance operations).
  • the preset duration is used to quantify the execution of the first service and the second service.
  • the preset duration is usually different, which may be based on the actual service scenario.
  • the setting is made here, and does not constitute a limitation on the present application.
  • the execution time of the first service is shorter than the second service execution time because the execution manner of the first service and the second service is different.
  • the number of payment will be preferentially peaked, and for the second service, because the execution time of the second service is longer, the statistics of the number of payment for the second service are more The lag, but in fact, the traffic of the second service may have reached a peak value. Therefore, in order to determine the actual traffic volume of the second service, the server will pay the number of times of the first service in the embodiment of the present application. The time at which the peak is reached is determined as the designated time, and the amount of traffic of the second service at the current time is determined based on the peak of the number of payment times of the second service recorded in the history.
  • determining the traffic volume specifically, predicting the traffic volume of the second service at the specified time according to the historical peak value, including: determining a number of payment times for the second service at the specified time As the current number of times, in the historical time period, determining a historical time corresponding to the specified time, determining, according to the saved historical record, the number of payment for the second service at the historical time, as a historical number, comparing And determining, according to the comparison result and the historical peak value, the traffic volume of the second service at the specified time.
  • the server receives the The time when the number of payment peaks is relatively lagging (here, the process from the start of express delivery to the completion of payment by the receiver can be regarded as the process in which the second service is being executed), and obviously, the business being executed before the number of payment reaches the peak The amount may have reached its peak. Therefore, historical peaks can be used.
  • the traffic volume of the second service determined by the foregoing method at the specified time is essentially an estimated value obtained according to the historical record, but the historical peak value of the number of payment times of the second service in history The size is not consistent.
  • the historical peak may be higher than the second business traffic at the current moment, or may be lower than the second business traffic at the current moment.
  • the value may be adjusted for the determined historical peak.
  • the second service is determined according to the comparison result and the historical peak.
  • Determining the traffic of the time at the specified time including: determining a difference between the current number of times and the number of historical times, determining a weight corresponding to the difference according to a preset correspondence between the difference and the weight, according to the weight and the The historical peak predicts the amount of traffic of the second service at the specified time.
  • the number of payments that the server has counted is 500 (ie, the current number of times mentioned above), and the number of payments that the server has counted is assumed on the previous day at 12:00. 400 (ie, the number of historical times mentioned above), obviously, at 12:00, the number of payments that the server has counted the previous day is smaller than the number of payments that the current server has counted, so the difference can be determined to be 100, then It indicates that on the same day, the amount of business that express delivery B is carrying out express delivery is likely to be greater than that of the previous day.
  • the application of the restaurant recommendation category (hereinafter referred to as: recommended application) is widely used by users, and through the recommended application, the user can know the basic information of various restaurants and the dining situation. Payment can be made using this recommended app.
  • restaurants are divided into different types: fast food restaurants and dinner restaurants.
  • fast food restaurants use the first way to pay for meals
  • the dining restaurants use the first way to pay after meals.
  • the server can receive payment information sent by different types of restaurants, and use this to count the dining situation of each restaurant.
  • the server can receive payment information sent by different types of restaurants, and use this to count the dining situation of each restaurant.
  • the method for predicting the amount of traffic provided in the embodiment of the present application is also applicable to the scenario of counting restaurant dining conditions.
  • the server in the background of the recommendation application receives the payment information sent by different types of restaurants, and generates corresponding meal situations.
  • the method for predicting the traffic volume in the scenario is as shown in FIG. 2b, and specifically includes the following steps:
  • S201 Receive payment information corresponding to the first type of restaurant.
  • the first type of restaurant is used to provide a catering business from the time of placing the order to the payment for a shorter period of time than the preset time, such as: a fast food restaurant
  • the second type of restaurant is used to provide a time from the order to the payment is longer than Pre-set catering business, such as: dinner restaurant.
  • the server will receive the payment information of the first type of restaurant in time.
  • S202 Determine, according to each payment information for the first type of restaurant, a time when the number of payment for the first type of restaurant reaches a peak as a designated time.
  • the time when the number of payment corresponding to the first type of restaurant reaches a peak in some set time periods may be, for example, lunch time (11:30 to 13:30), For dinner time (17:00 to 20:00), etc.
  • the time when the number of payment for the first type of restaurant reaches the peak can be as follows: at 12:00 during lunch time, the number of payments reaches the peak.
  • this does not constitute a copy of this Application limit.
  • the number of payments in the first type of restaurant peaked, indicating that the dining conditions of the first type of restaurant (eg, dining popularity) peaked.
  • S203 Determine, according to the saved historical record, a historical peak value of the payment for the second type of restaurant as a historical peak.
  • the statistics of the number of paymentes by the server for the second type of restaurant can usually only lag behind the user's meal, that is, the statistics on the number of payment times. Therefore, in order to determine the designation At the time (eg, 12:00 in the previous example), the number of payments for the second type of restaurant will determine the peak number of payments in the history for reference, for example, the peak number of payment for the second type of restaurant in the lunch time of the previous day. Historical peak.
  • S204 Predict the traffic volume of the second type of restaurant at the specified moment according to the historical peak.
  • the user may be in a dining state (but not paid), and the user currently eating may be able to make payment for the second type of restaurant after the meal ends.
  • the number of times reaches a peak, then the historical peak of the previous day can be used as the actual meal situation (ie, business volume) of the day.
  • Determining, according to the historical peak, the traffic of the second type of restaurant at the specified time the method further comprising: receiving each payment information corresponding to the second type of restaurant, and then predicting according to the historical peak
  • the amount of service of the second type of restaurant at the specified time includes: determining, according to each payment information corresponding to the second type of restaurant, the number of payment for the second type of restaurant at the specified time, as current The number of times, in the historical time period, determining a historical time corresponding to the specified time, determining, according to the saved history, the number of payments for the second type of restaurant at the historical time, as a historical number, comparing the The current number of times and the number of times of history, and based on the comparison result and the historical peak value, predict the amount of traffic of the second type of restaurant at the specified time.
  • determining, according to the comparison result and the historical peak value, the traffic volume of the second type of restaurant at the specified time specifically: determining a difference between the current number of times and the historical number of times, according to a preset Corresponding relationship between the difference value and the weight, determining a weight corresponding to the difference, according to the weight And the historical peak predicts the amount of traffic of the second type of restaurant at the specified time.
  • the statistics of the number of times the server pays for the first type of restaurant A and the second type of restaurant B are shown, assuming that during the lunch time of D n days (which can be understood as the day), the restaurant A The number of payments reaches a peak of 500 at 12:00. At the same time, the number of payments by Restaurant B is 100 (the current number). Obviously, considering the dining mode of Restaurant B, there may be a certain number of users who are in the state of eating and not The payment is made, so in order to determine the business volume of the restaurant B at 12:00, reference can be made to the peak number of payment of the restaurant B during the D n-1 day lunch period, as can be seen from FIG. 3, the restaurant B is at D n-1 The number of payments at 12:30 reached a peak of 450.
  • the business volume of the restaurant B at 12:00 on the D n day is determined as 360, that is, the peak number of payment of the restaurant B at the lunch time of the D n day is expected to be 360.
  • the server may display the popularity value of each restaurant to the user who uses the recommended application based on the determined traffic volume, and the method further includes: determining, according to the determined service volume, and a preset rule, The value of the popularity of the second type of restaurant at the specified time is displayed.
  • the popularity value of the restaurant may be determined on the basis of the traffic volume, and the popularity value may be determined by using a star rating method. For example, if the traffic volume exceeds 150, The five-star popularity value is displayed, and the above manner does not constitute a limitation on the embodiments of the present application.
  • the technical carrier involved in the payment in the embodiment of the present application may include, for example, Near Field Communication (NFC), WIFI, 3G/4G/5G, POS card swiping technology, two-dimensional code scanning technology, and barcode scanning code.
  • NFC Near Field Communication
  • WIFI Wireless Fidelity
  • 3G/4G/5G 3G/4G/5G
  • POS card swiping technology 3G/4G/5G
  • POS card swiping technology two-dimensional code scanning technology
  • barcode scanning code e.g., Bluetooth, infrared, Short Message Service (SMS), Multimedia Message Service (MMS), etc.
  • SMS Short Message Service
  • MMS Multimedia Message Service
  • the above is the method for predicting the traffic volume provided by the embodiment of the present application. Based on the same idea, the present application A corresponding traffic forecasting device is also provided, as shown in FIGS. 4 and 5.
  • FIG. 4 is a schematic structural diagram of a device for predicting traffic volume according to an embodiment of the present disclosure, specifically including:
  • the time determination module 401 determines a time when the number of payment for the first service reaches a peak as the designated time
  • the historical peak module 402 determines, according to the saved history record, a historical peak value of the payment for the second service as a historical peak;
  • the traffic module 403 is configured to predict the traffic of the second service at the specified time, where the first service and the second service belong to the same type of service, and the execution manner of the first service is The service execution time of the first service is shorter than the preset duration, and the service execution time of the second service is longer than the preset duration.
  • the traffic module 403 determines, according to the current number of times, the number of payment for the second service at the specified time, as the current time, determines a historical time corresponding to the specified time in the historical time period, according to the saved history. Determining, in the historical moment, the number of payment for the second service, as the historical number, comparing the current number of times with the historical number of times, and predicting the second service according to the comparison result and the historical peak value The amount of business at the specified time.
  • the traffic module 403 determines a difference between the current number of times and the historical number, and determines a weight corresponding to the difference according to a preset correspondence between the difference and the weight, according to the weight and the history.
  • the peak predicts the amount of traffic of the second service at the specified time.
  • FIG. 5 is a schematic structural diagram of another apparatus for predicting traffic volume according to an embodiment of the present disclosure, specifically including:
  • the receiving module 501 receives payment information corresponding to the first type of restaurant
  • the time determination module 502 determines, according to each payment information for the first type of restaurant, a time at which the number of payment for the first type of restaurant reaches a peak as a designated time;
  • the historical peak module 503 determines, according to the saved history, the historical peak value of the payment for the second type of restaurant as a historical peak;
  • a traffic module 504 predicting, according to the historical peak, the second type of restaurant at the time of the designation Engraved business volume, wherein the first type of restaurant is used to provide catering business from the time the order is placed to the payment time is shorter than the preset time period, and the second type of restaurant is used to provide the time from the order to the payment is longer than the pre-payment A long-term catering business.
  • the receiving module 501 receives each payment information corresponding to the second type of restaurant, and the traffic module 504 determines, according to each payment information for the second type of restaurant, the second class at the specified time.
  • the number of times the restaurant pays, as the current number of times determines the historical time corresponding to the specified time in the historical time period, and determines the number of payments for the second type of restaurant at the historical time according to the saved history.
  • the historical number the current number of times and the number of historical times are compared, and based on the comparison result and the historical peak value, the traffic volume of the second type of restaurant at the specified time is predicted.
  • the traffic module 504 determines a difference between the current number of times and the historical number, and determines a weight corresponding to the difference according to a preset correspondence between the difference and the weight, according to the weight and the history.
  • the peak predicts the amount of traffic of the second type of restaurant at the specified time.
  • the device further includes: a display processing module 505, determining, according to the predicted traffic volume, and a preset rule, a popularity value of the second type of restaurant at the specified moment, and displaying.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • ABEL Advanced Boolean Expression Language
  • AHDL Altera Hardware Description Language
  • HDCal JHDL
  • Lava Lava
  • Lola MyHDL
  • PALASM RHDL
  • VHDL Very-High-Speed Integrated Circuit Hardware Description Language
  • Verilog Verilog
  • the controller can be implemented in any suitable manner, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor.
  • computer readable program code eg, software or firmware
  • examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, The Microchip PIC18F26K20 and the Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic.
  • the controller can be logically programmed by means of logic gates, switches, ASICs, programmable logic controllers, and embedding.
  • Such a controller can therefore be considered a hardware component, and the means for implementing various functions included therein can also be considered as a structure within the hardware component.
  • a device for implementing various functions can be considered as a software module that can be both a method of implementation and a structure within a hardware component.
  • the system, device, module or unit illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product having a certain function.
  • a typical implementation device is a computer.
  • the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or A combination of any of these devices.
  • embodiments of the present invention can be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.
  • the computing device includes one or more processors (CPUs), inputs/outputs Interface, network interface, and memory.
  • processors CPUs
  • inputs/outputs Interface network interface
  • memory volatile and non-volatile memory
  • the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
  • RAM random access memory
  • ROM read only memory
  • Memory is an example of a computer readable medium.
  • Computer readable media includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology.
  • the information can be computer readable instructions, data structures, modules of programs, 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 disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.
  • embodiments of the present application can be provided as a method, system, or computer program product.
  • the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment in combination of software and hardware.
  • the application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • the application can be described in the general context of computer-executable instructions executed by a computer, such as Such as program modules.
  • program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types.
  • the present application can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are connected through a communication network.
  • program modules can be located in both local and remote computer storage media including storage devices.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Human Resources & Organizations (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Game Theory and Decision Science (AREA)
  • Tourism & Hospitality (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Educational Administration (AREA)
  • Chemical & Material Sciences (AREA)
  • Analytical Chemistry (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Traffic Control Systems (AREA)

Abstract

一种业务量的预测方法及装置，确定针对第一业务的支付次数达到峰值的时刻，作为指定时刻（S101），根据保存的历史记录，确定历史上针对第二业务的支付次数峰值，作为历史峰值（S102），根据所述历史峰值，预测所述第二业务在所述指定时刻的实际业务量（S103），其中，所述第一业务与所述第二业务属于同一类业务，所述第一业务的执行方式与所述第二业务的执行方式不同，所述第一业务的业务执行时间短于预设时长，所述第二业务的业务执行时间长于预设时长。通过上述实施例，即使对于支付次数达到峰值的时刻较为滞后的业务，本技术方案也能够较为准确地确定出该业务在当前时刻的业务量，从而为服务器的运维过程提供较为准确的参考。

Description

一种业务量的预测方法及装置 技术领域
本申请涉及信息技术领域，尤其涉及一种业务量的预测方法及装置。
背景技术
在网络业务飞速发展的当代，业务提供商的服务器负荷也越来越重，对实时的确定业务量已经变的尤为重要。
在现有技术中，确定某个业务的业务量时，一般需要统计单位时间内生成的业务结果的数量，作为当前时刻的业务量，如果某一时刻生成的业务结果的数量达到峰值，则确定该时刻即为业务高峰的到来时刻。
但是，在实际应用场景中，服务器的负荷主要是在业务执行的过程中产生，并不是在生成业务结果时产生，也就是说，实际的业务量产生时刻应该在业务开始执行的时刻，而不是执行结束时产生业务结果的时刻，实际的业务高峰到来时刻应该是大量的业务开始执行的时刻，而不是执行结束时产生业务结果的时刻。
而且，不同种类的业务的执行时间也有所不同，或者说，用户在执行不同种类的业务时，用户需要操作的时间有所不同，那么，对于执行时间较短的业务，可以较快的生成业务结果，通过现有技术中统计业务量的方法，统计出的业务量相对于实际的业务量不会过于偏低，统计出的业务高峰到来时刻相对于实际的业务高峰到来时刻也不会过于滞后，可能尚在可接受范围内，而对于执行时间较长的业务，则会使确定出的业务量相对于实际业务量过于偏低，确定出的业务高峰到来时刻相对于实际的业务高峰到来时刻也存在较大的滞后。
例如，对于简单的登录来说，服务器接收到登录请求的时刻即为业务开始执行的时刻，而服务器接收到登录请求后，只要验证用户名和密码正确，即可 执行登录并生成登录结果，按照现有技术的方法，将登录结果的生成数量作为当前时刻的业务量是可以接受的。但是，对于订火车票这种业务来说，用户需要进行大量的查询，还需要提交订单、支付等过程，如果将当前时刻统计出的支付结果生成数量作为当前时刻的业务量，则显然会使确定出的业务量低于实际的业务量，这是因为当前时刻尚有很多用户已经在执行查询、提交订单等订票的业务过程，但尚未完成支付，也就不会产生支付结果，如果将支付结果生成数量峰值的到来时刻确定为业务高峰到来时刻，则也会使确定出的业务高峰到来时刻滞后很多。
即便是对于同类但执行方式不同的业务来说，也是如此。例如，对于快递业务A和快递业务B来说，用户在使用快递业务A运送货物时，需要先支付运费，再进行快递运输，相应地，服务器会根据快递员上传的支付成功的支付结果，统计其业务量，而用户在使用快递业务B运送货物时，可直接通过电话、短信等方式联系快递员，以指示其上门取货后进行快递运输，待快递送达至接收方后，由接收方进行支付，支付成功后，快递员可将支付结果提交到服务器。显然，若以当前时刻接收到支付结果的数量作为业务量，则对于快递业务B来说，现有技术确定出的业务量明显低于实际的业务量，若以接收到支付结果的数量达到峰值的时刻确定业务峰值的到来时刻，则对于快递业务B来说也是滞后的。
可见，现有技术中确定的当前时刻业务量的准确性较低，这无疑对服务器的运维和管理是非常不利的。
发明内容
本申请实施例提供一种业务量的预测方法及装置，用于解决现有技术中确定出的当前时刻业务量不准确，不利于服务器运维的问题。
本申请实施例采用下述技术方案：
一种业务量的预测方法，包括：
确定针对第一业务的支付次数达到峰值的时刻，作为指定时刻；
根据保存的历史记录，确定历史上针对第二业务的支付次数峰值，作为历史峰值；
根据所述历史峰值，预测所述第二业务在所述指定时刻的业务量，其中，所述第一业务与所述第二业务属于同一类业务，所述第一业务的执行方式与所述第二业务的执行方式不同，所述第一业务的业务执行时间短于预设时长，所述第二业务的业务执行时间长于预设时长。
一种业务量的预测方法，包括：
接收针对第一类餐馆的各支付信息；
根据针对所述第一类餐馆的各支付信息，确定针对所述第一类餐馆的支付次数达到峰值的时刻，作为指定时刻；
根据保存的历史记录，确定历史上针对第二类餐馆的支付次数峰值，作为历史峰值；
根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量，其中，所述第一类餐馆用以提供从下单到支付的时间短于预设时长的餐饮业务，所述第二类餐馆用以提供从下单到支付的时间长于预设时长的餐饮业务。
一种业务量的预测装置，包括：
时刻确定模块，确定针对第一业务的支付次数达到峰值的时刻，作为指定时刻；
历史峰值模块，根据保存的历史记录，确定历史上针对第二业务的支付次数峰值，作为历史峰值；
业务量模块，预测所述第二业务在所述指定时刻的业务量，其中，所述第一业务与所述第二业务属于同一类业务，所述第一业务的执行方式与所述第二业务的执行方式不同，所述第一业务的业务执行时间短于预设时长，所述第二业务的业务执行时间长于预设时长。
一种业务量的预测装置，包括：
接收模块，接收针对第一类餐馆的各支付信息；
时刻确定模块，根据针对所述第一类餐馆的各支付信息，确定针对所述第一类餐馆的支付次数达到峰值的时刻，作为指定时刻；
历史峰值模块，根据保存的历史记录，确定历史上针对第二类餐馆的支付次数峰值，作为历史峰值；
业务量模块，根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量，其中，所述第一类餐馆用以提供从下单到支付的时间短于预设时长的餐饮业务，所述第二类餐馆用以提供从下单到支付的时间长于预设时长的餐饮业务。
本申请服务器会将第一业务的支付次数达到峰值的时刻确定为指定时刻，并根据历史上记录的第二业务的支付次数的峰值，确定在当前时刻下第二业务可能的业务量。相较于现有技术而言，即使对于支付次数达到峰值的时刻较为滞后的业务，本申请也能够较为准确地确定出该业务在当前时刻的业务量，从而为服务器的运维过程提供较为准确的参考。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本申请实施例提供的业务量的预测过程；
图2a为本申请实施例提供的餐馆业务量的预测过程所基于的架构；
图2b为本申请实施例提供的餐馆业务量的预测过程；
图3为本申请实施例提供的在实际应用中业务量的示意图；
图4为本申请实施例提供的一种业务量的预测装置结构示意图；
图5为本申请实施例提供的另一种业务量的预测装置结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
正如前述，针对同种类、但执行方式不同的业务，在统计其业务量的过程中，存在对当前时刻业务量确定不准确的现象，基于此，本申请实施例提供一种业务量的预测方法，以尽量准确地确定执行方式不同的业务在当前时刻的业务量，为了便于后续描述，将执行方式不同的业务分别称为第一业务和第二业务。以下结合附图，详细说明本申请各实施例提供的技术方案。
实施例一
图1为本申请实施例提供的业务量的预测过程，具体包括以下步骤：
S101：确定针对第一业务的支付次数达到峰值的时刻，作为指定时刻。
在实际应用场景中，对第一业务的支付次数的确定，可以由相应的业务提供方的服务器所实现，其中，所述的业务提供方，包括但不限于：网站、银行、电信运营商等。
用户可以通过向业务提供方的服务器(以下简称为：服务器)发出业务请求的方式，使用该业务提供方所提供的某项业务(也即，第一业务)，相应地，用户使用了该项业务通常会支付相应的业务代价(如：支付相应的款项)，服务器则会针对用户所支付的业务代价进行记录。例如：用户在使用快递业务的过程中，支付了运费，由相应的快递员将支付结果提交给快递网站服务器，在服务器上，便会记录本次支付。
显然，随着用户的使用，该第一业务的支付次数将在某一时刻(即，指定时刻)达到峰值，其中，所述的峰值，应理解为在某一设定的时间段之内业务量的最大值，在实际应用中，在全时段内，所述的峰值可以有多个。这里并不 构成对本申请的限定。
S102：根据保存的历史记录，确定历史上针对第二业务的支付次数峰值，作为历史峰值。
所述第二业务，同样由相应的业务提供方所提供，如前述示例中的快递业务B，与前述的第一业务属于同类业务，但两种业务的执行方式不同。在本申请实施例中，对于该第二业务而言，确定出该第二业务的业务高峰到来的时刻，相较于该第二业务实际的业务高峰存在较大的滞后。
换言之，由于第一、第二业务之间的执行方式不同，服务器对第一业务的支付次数的峰值的统计较为及时，但服务器针对第二业务的支付次数的峰值的统计较为滞后。
考虑到在实际应用场景下，服务器通常会针对其所执行或完成的业务均会进行记录，具体可记录不同的业务在各时刻所的支付次数，作为历史记录，那么，根据历史记录，也就可以确定出第二业务在历史上的支付次数的峰值。
根据第二业务的支付次数的历史峰值，可针对指定时刻第二业务的业务量进行预估，也即，执行下述步骤S103。
S103：根据所述历史峰值，预测所述第二业务在所述指定时刻的实际业务量。
其中，所述第一业务与所述第二业务属于同一类业务，所述第一业务的执行方式与所述第二业务的执行方式不同，所述第一业务的业务执行时间短于预设时长，所述第二业务的业务执行时间长于预设时长。
所述的业务量，可认为是服务器根据已接收到的业务请求，正在执行且并未产生支付结果的业务的数量。
对于第二而言，由于服务器确定出第二业务的支付次数的时刻较为滞后，也就是说，在服务器统计出第二业务的支付次数之前，该第二业务的实际量可能已达到峰值，所以，可根据第二业务历史上的支付次数的峰值，作为指定时刻第二业务可能的业务量，为后续操作(如：服务器维护操作)作为参考。
当然，所述的预设时长，用于量化上述第一业务和第二业务所需的执行之间，对于不同的业务场景，预设时长的设定通常不同，具体可以根据实际业务场景的需要进行设定，这里并不构成对本申请的限定。
由上述过程可见，当不同用户使用业务提供方所提供的第一业务及第二业务时，由于第一业务与第二业务的执行方式不同，使得第一业务执行时间短于第二业务执行时间，在此情况下，对于第一业务而言，其支付次数将优先达到峰值，而对于第二业务而言，由于第二业务的执行时间较长，导致对第二业务的支付次数的统计较为滞后，但实际上，第二业务的业务量可能已达到峰值，那么，为了较为准确地确定出第二业务实际的业务量，故在本申请实施例中，服务器会将第一业务的支付次数达到峰值的时刻确定为指定时刻，并根据历史上记录的第二业务的支付次数的峰值，确定在当前时刻下第二业务可能的业务量。
相较于现有技术而言，即使对于支付次数达到峰值的时刻较为滞后的业务，本申请也能够较为准确地预测出该业务在当前时刻的业务量，从而为服务器的运维过程提供较为准确的参考。
对于前述确定业务量的过程，具体来说，根据所述历史峰值，预测所述第二业务在所述指定时刻的业务量，包括：确定在所述指定时刻针对所述第二业务的支付次数，作为当前次数，在历史时间段中，确定与所述指定时刻相对应的历史时刻，根据保存的历史记录，确定在所述历史时刻针对所述第二业务的支付次数，作为历史次数，比较所述当前次数与所述历史次数，并根据比较结果以及所述历史峰值，确定所述第二业务在所述指定时刻的业务量。
以前述快递业务为例进行详细说明，对于快递业务B(即，第二业务)来说，由于快递运输的运费在接收方接收到快递后才进行支付，故在该场景下，服务器接收到的支付次数达到峰值的时刻较为滞后(这里，从快递运输开始至接收方完成支付的过程，便可看作是第二业务正在执行的过程)，显然，在支付次数达到峰值前，正在执行的业务量可能已达到峰值。故可采用历史峰值的 方式确定快递业务B的在12:00时的业务量：
在此假设，以12:00作为指定时刻，通过历史记录，可确定前一天快递业务B的中午时段的支付次数出现在12:30，数值为500(次)，故可以将该历史峰值确定为12:00时快递业务B的支付次数峰值。
需要说明的是，采用上述方法所确定出的第二业务在指定时刻的业务量，实质上是一种根据历史记录得到的预估值，但是，历史上第二业务的支付次数的历史峰值的大小并不一致，换言之，历史峰值有可能高于当前时刻第二业务业务量，也有可能低于当前时刻第二业务业务量。那么，为了更加准确地对确定第二业务的业务量，故可以针对确定的历史峰值进行数值上的调整，具体而言：根据比较结果以及所述历史峰值，确定所述第二业务在所述指定时刻的业务量，包括：确定所述当前次数与所述历史次数的差值，根据预设的差值与权重的对应关系，确定所述差值对应的权重，根据所述权重以及所述历史峰值预测所述第二业务在所述指定时刻的业务量。
沿用上例，假设在12:00，针对快递业务B，服务器已统计出的支付次数为500(即，前述的当前次数)，并假设前一天在12:00时，服务器已统计出的支付次数为400(即，前述的历史次数)，显然，在12:00时，前一天服务器已统计出的支付次数小于当前服务器已统计出的支付次数，故可确定差值为100，那么，也就表明在当天，快递业务B正在进行快递运输的业务量有可能多于前一天的业务量，所以，可确定权重假设为0.2，那么，在此基础上，也就可以针对历史峰值进行调整，即，500*(1+0.2)＝600，从而，确定当天12:00时快递业务B正在快递运输过程中的数量为600(即，后续服务器可统计出支付次数为600)。
上述示例仅是为了说明本申请实施例中所述的业务量的预测方法，并不应理解为对本申请的限定。
除了上述的场景，目前，餐馆推荐类的应用(后续简称为：推荐应用)广泛被用户使用，通过推荐应用，用户可获知各类餐馆的基本信息以及就餐情况， 并可使用该推荐应用进行支付。
在实际应用中，餐馆分为不同类型：快餐类餐馆以及正餐类餐馆，其中，快餐餐馆的就餐方式为先支付后就餐，而正餐餐馆的就餐方式为先就餐后支付，由此，推荐应用后台的服务器可接收不同类型的餐馆发送的支付信息，并以此来统计各餐馆的就餐情况，然而，正是由于两种餐馆的就餐方式不同，那么，对于正餐餐馆而言，用户在就餐完成后进行支付，所以，推荐应用后台服务器获得正餐餐馆的支付信息通常是滞后的，这样一来，对于使用推荐应用的用户来说，也就不能准确地获知正餐餐馆当前的就餐情况。
因此，本申请实施例中所提供的业务量的预测方法还适用于对餐馆就餐情况统计的场景。具体地，如图2a所示，为本场景下的架构示意图，推荐应用后台的服务器(以下简称：服务器)接收不同类型餐馆发送的支付信息，并以此生成相应的就餐情况。
基于如图2a所示的架构，在该场景下的业务量的预测方法如图2b所示，具体包括以下步骤：
S201：接收针对第一类餐馆对应的各支付信息。
其中，所述第一类餐馆用以提供从下单到支付的时间短于预设时长的餐饮业务，如：快餐类餐馆，所述第二类餐馆用以提供从下单到支付的时间长于预设时长的餐饮业务，如：正餐类餐馆。
可见，对于第一类餐馆，由于其就餐方式为先支付后就餐，故服务器将及时地接收到第一类餐馆的支付信息。
S202：根据针对所述第一类餐馆的各支付信息，确定针对所述第一类餐馆的支付次数达到峰值的时刻，作为指定时刻。
在实际应用中，通常可以在某些设定的时段内确定第一类餐馆对应的支付次数达到峰值的时刻，这里的设定时段，可以如：午餐时段(11:30～13:30)、晚餐时段(17:00～20:00)等，第一类餐馆对应的支付次数达到峰值的时刻，可以如：午餐时段内的12:00时，支付次数达到峰值。当然，这里并不构成对本 申请的限定。
显然，第一类餐馆的支付次数达到峰值，也就表明该第一类餐馆的就餐情况(如：就餐人气)达到峰值。
S203：根据保存的历史记录，确定历史上针对第二类餐馆的支付次数峰值，作为历史峰值。
由于与第一类餐馆的就餐方式不同，服务器针对第二类餐馆的支付次数的统计，通常只能在用户就餐结束后，也即，对支付次数的统计出现了滞后，所以，为了确定出指定时刻(如：上例中的12:00)针对第二类餐馆的支付次数，将确定历史上的支付次数峰值，以作为参考，例如：以前一天午餐时段中第二类餐馆的支付次数峰值作为历史峰值。
S204：根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量。
沿用上例，在12:00时，对于第二餐馆而言，用户可能正处于就餐状态(但并未支付)，当前正在就餐的用户在就餐结束后，可能能够使得该第二类餐馆的支付次数达到峰值，那么，也就可以根据前一天的历史峰值作为当天实际的就餐情况(即，业务量)。
根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量之前，所述方法还包括：接收针对第二类餐馆对应的各支付信息，那么，根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量，具体包括：根据所述第二类餐馆对应的各支付信息，确定在所述指定时刻针对所述第二类餐馆的支付次数，作为当前次数，在历史时间段中，确定与所述指定时刻相对应的历史时刻，根据保存的历史记录，确定在所述历史时刻针对所述第二类餐馆的支付次数，作为历史次数，比较所述当前次数与所述历史次数，并根据比较结果以及所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量。
更为具体地，根据比较结果以及所述历史峰值，确定所述第二类餐馆在所述指定时刻的业务量，具体包括：确定所述当前次数与所述历史次数的差值，根据预设的差值与权重的对应关系，确定所述差值对应的权重，根据所述权重 以及所述历史峰值预测所述第二类餐馆在所述指定时刻的业务量。
例如：如图3所示，示出了服务器对第一类餐馆A和第二类餐馆B的支付次数的统计值，假设，在Dn天(可理解为当天)的午餐时段，餐馆A的支付次数在12:00达到峰值500，同一时刻，餐馆B的支付次数为100(当前次数)，显然，考虑到餐馆B的就餐方式，可以还有一定数量的用户处于正在就餐的状态而并未进行支付，所以，为了确定出该餐馆B在12:00时的业务量，可参考餐馆B在Dn-1天午餐时段的支付次数峰值，从图3中可见，餐馆B在Dn-1天12:30的支付次数达到峰值450。
为了更加准确地估计餐馆B在Dn天12:00时的支付次数峰值，则可确定餐馆B在Dn-1天12:00时的支付次数，即为120(历史次数)。那么，当前次数与历史次数的差值为-20，进而可确定出该差值对应的权重，假设，差值在[-1，-20]区间内的权重为-0.2，所以，便可以确定在Dn天12:00时，餐馆B的支付次数峰值为：450*(1-0.2)＝360。
故在本示例下，将餐馆B在Dn天12:00时的业务量确定为360，即表示餐馆B在Dn天的午餐时段的支付次数峰值预计为360。
在实际应用场景下，服务器可基于确定出的业务量，向使用推荐应用的用户展示各餐馆的人气值，所述方法还包括：根据确定出的所述业务量，以及预设的规则，确定所述第二类餐馆在所述指定时刻的人气值，展示所述人气值。
作为本申请实施例中的一种方式，可以在业务量的基础上，结合人气系数确定餐馆的人气值，当然，人气值还可以采用星级的方式进行展示，如：业务量超过150，则展示五星的人气值，以上方式并不构成对本申请实施例的限定。
本申请实施例中所述支付涉及的技术载体，例如可以包括近场通信(Near Field Communication，NFC)、WIFI、3G/4G/5G、POS机刷卡技术、二维码扫码技术、条形码扫码技术、蓝牙、红外、短消息(Short Message Service，SMS)、多媒体消息(Multimedia Message Service，MMS)等。
以上为本申请实施例提供的业务量的预测方法，基于同样的思路，本申请 还提供了相应的业务量的预测装置，如图4、图5所示。
图4为本申请实施例提供的业务量的预测装置结构示意图，具体包括：
时刻确定模块401，确定针对第一业务的支付次数达到峰值的时刻，作为指定时刻；
历史峰值模块402，根据保存的历史记录，确定历史上针对第二业务的支付次数峰值，作为历史峰值；
业务量模块403，预测所述第二业务在所述指定时刻的业务量，其中，所述第一业务与所述第二业务属于同一类业务，所述第一业务的执行方式与所述第二业务的执行方式不同，所述第一业务的业务执行时间短于预设时长，所述第二业务的业务执行时间长于预设时长。
所述业务量模块403，确定在所述指定时刻针对所述第二业务的支付次数，作为当前次数，在历史时间段中，确定与所述指定时刻相对应的历史时刻，根据保存的历史记录，确定在所述历史时刻针对所述第二业务的支付次数，作为历史次数，比较所述当前次数与所述历史次数，并根据比较结果以及所述历史峰值，预测所述第二业务在所述指定时刻的业务量。
所述业务量模块403，确定所述当前次数与所述历史次数的差值，根据预设的差值与权重的对应关系，确定所述差值对应的权重，根据所述权重以及所述历史峰值预测所述第二业务在所述指定时刻的业务量。
图5为本申请实施例提供的另一种业务量的预测装置结构示意图，具体包括：
接收模块501，接收针对第一类餐馆对应的各支付信息；
时刻确定模块502，根据针对所述第一类餐馆的各支付信息，确定针对所述第一类餐馆的支付次数达到峰值的时刻，作为指定时刻；
历史峰值模块503，根据保存的历史记录，确定历史上针对第二类餐馆的支付次数峰值，作为历史峰值；
业务量模块504，根据所述历史峰值，预测所述第二类餐馆在所述指定时 刻的业务量，其中，所述第一类餐馆用以提供从下单到支付的时间短于预设时长的餐饮业务，所述第二类餐馆用以提供从下单到支付的时间长于预设时长的餐饮业务。
所述接收模块501，接收针对第二类餐馆对应的各支付信息，所述业务量模块504，根据针对所述第二类餐馆的各支付信息，确定在所述指定时刻针对所述第二类餐馆的支付次数，作为当前次数，在历史时间段中，确定与所述指定时刻相对应的历史时刻，根据保存的历史记录，确定在所述历史时刻针对所述第二类餐馆的支付次数，作为历史次数，比较所述当前次数与所述历史次数，并根据比较结果以及所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量。
所述业务量模块504，确定所述当前次数与所述历史次数的差值，根据预设的差值与权重的对应关系，确定所述差值对应的权重，根据所述权重以及所述历史峰值预测所述第二类餐馆在所述指定时刻的业务量。
所述装置还包括：展示处理模块505，根据预测出的所述业务量，以及预设的规则，确定所述第二类餐馆在所述指定时刻的人气值，并展示。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它 与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。 具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出 接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例 如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (14)

  1. 一种业务量的预测方法，其特征在于，所述方法包括：
    确定针对第一业务的支付次数达到峰值的时刻，作为指定时刻；
    根据保存的历史记录，确定历史上针对第二业务的支付次数峰值，作为历史峰值；
    根据所述历史峰值，预测所述第二业务在所述指定时刻的业务量，其中，所述第一业务与所述第二业务属于同一类业务，所述第一业务的执行方式与所述第二业务的执行方式不同，所述第一业务的业务执行时间短于预设时长，所述第二业务的业务执行时间长于预设时长。
  2. 如权利要求1所述的方法，其特征在于，根据所述历史峰值，预测所述第二业务在所述指定时刻的业务量，具体包括：
    确定在所述指定时刻针对所述第二业务的支付次数，作为当前次数；
    在历史时间段中，确定与所述指定时刻相对应的历史时刻；
    根据保存的历史记录，确定在所述历史时刻针对所述第二业务的支付次数，作为历史次数；
    比较所述当前次数与所述历史次数，并根据比较结果以及所述历史峰值，预测所述第二业务在所述指定时刻的业务量。
  3. 如权利要求2所述的方法，其特征在于，根据比较结果以及所述历史峰值，预测所述第二业务在所述指定时刻的业务量，具体包括：
    确定所述当前次数与所述历史次数的差值；
    根据预设的差值与权重的对应关系，确定所述差值对应的权重；
    根据所述权重以及所述历史峰值预测所述第二业务在所述指定时刻的业务量。
  4. 一种业务量的预测方法，其特征在于，所述方法包括：
    接收针对第一类餐馆的各支付信息；
    根据针对所述第一类餐馆的各支付信息，确定针对所述第一类餐馆的支付 次数达到峰值的时刻，作为指定时刻；
    根据保存的历史记录，确定历史上针对第二类餐馆的支付次数峰值，作为历史峰值；
    根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量，其中，所述第一类餐馆用以提供从下单到支付的时间短于预设时长的餐饮业务，所述第二类餐馆用以提供从下单到支付的时间长于预设时长的餐饮业务。
  5. 如权利要求4所述的方法，其特征在于，根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量之前，所述方法还包括：
    接收针对第二类餐馆的各支付信息；
    根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量，具体包括：
    根据针对所述第二类餐馆的各支付信息，确定在所述指定时刻针对所述第二类餐馆的支付次数，作为当前次数；
    在历史时间段中，确定与所述指定时刻相对应的历史时刻；
    根据保存的历史记录，确定在所述历史时刻针对所述第二类餐馆的支付次数，作为历史次数；
    比较所述当前次数与所述历史次数，并根据比较结果以及所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量。
  6. 如权利要求5所述的方法，其特征在于，根据比较结果以及所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量，具体包括：
    确定所述当前次数与所述历史次数的差值；
    根据预设的差值与权重的对应关系，确定所述差值对应的权重；
    根据所述权重以及所述历史峰值预测所述第二类餐馆在所述指定时刻的业务量。
  7. 如权利要求4～6任一所述的方法，其特征在于，所述方法还包括：
    根据预测出的所述业务量，以及预设的规则，确定所述第二类餐馆在所述 指定时刻的人气值；
    展示所述人气值。
  8. 一种业务量的预测装置，其特征在于，所述装置包括：
    时刻确定模块，确定针对第一业务的支付次数达到峰值的时刻，作为指定时刻；
    历史峰值模块，根据保存的历史记录，确定历史上针对第二业务的支付次数峰值，作为历史峰值；
    业务量模块，预测所述第二业务在所述指定时刻的业务量，其中，所述第一业务与所述第二业务属于同一类业务，所述第一业务的执行方式与所述第二业务的执行方式不同，所述第一业务的业务执行时间短于预设时长，所述第二业务的业务执行时间长于预设时长。
  9. 如权利要求8所述的装置，其特征在于，所述实际业务量模块，确定在所述指定时刻针对所述第二业务的支付次数，作为当前次数，在历史时间段中，确定与所述指定时刻相对应的历史时刻，根据保存的历史记录，确定在所述历史时刻针对所述第二业务的支付次数，作为历史次数，比较所述当前次数与所述历史次数，并根据比较结果以及所述历史峰值，预测所述第二业务在所述指定时刻的业务量。
  10. 如权利要求9所述的装置，其特征在于，所述实际业务量模块，确定所述当前次数与所述历史次数的差值，根据预设的差值与权重的对应关系，确定所述差值对应的权重，根据所述权重以及所述历史峰值预测所述第二业务在所述指定时刻的业务量。
  11. 一种业务量的预测装置，其特征在于，所述装置包括：
    接收模块，接收针对第一类餐馆的各支付信息；
    时刻确定模块，根据针对所述第一类餐馆的各支付信息，确定针对所述第一类餐馆的支付次数达到峰值的时刻，作为指定时刻；
    历史峰值模块，根据保存的历史记录，确定历史上针对第二类餐馆的支付 次数峰值，作为历史峰值；
    业务量模块，根据所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量，其中，所述第一类餐馆用以提供从下单到支付的时间短于预设时长的餐饮业务，所述第二类餐馆用以提供从下单到支付的时间长于预设时长的餐饮业务。
  12. 如权利要求11所述的装置，其特征在于，所述接收模块，接收针对第二类餐馆的各支付信息；
    所述业务量模块，根据针对所述第二类餐馆的各支付信息，确定在所述指定时刻针对所述第二类餐馆的支付次数，作为当前次数，在历史时间段中，确定与所述指定时刻相对应的历史时刻，根据保存的历史记录，确定在所述历史时刻针对所述第二类餐馆的支付次数，作为历史次数，比较所述当前次数与所述历史次数，并根据比较结果以及所述历史峰值，预测所述第二类餐馆在所述指定时刻的业务量。
  13. 如权利要求14所述的装置，其特征在于，所述业务量模块，确定所述当前次数与所述历史次数的差值，根据预设的差值与权重的对应关系，确定所述差值对应的权重，根据所述权重以及所述历史峰值预测所述第二类餐馆在所述指定时刻的业务量。
  14. 如权利要求11～13中任一所述的装置，其特征在于，所述装置还包括：展示处理模块，根据预测出的所述业务量，以及预设的规则，确定所述第二类餐馆在所述指定时刻的人气值，并展示。
PCT/CN2017/112069 2016-11-25 2017-11-21 一种业务量的预测方法及装置 WO2018095308A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/463,920 US11443251B2 (en) 2016-11-25 2017-11-21 Method and device for predicting traffic

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201611055796.6A CN107092973B (zh) 2016-11-25 2016-11-25 一种业务量的预测方法及装置
CN201611055796.6 2016-11-25

Publications (1)

Publication Number Publication Date
WO2018095308A1 true WO2018095308A1 (zh) 2018-05-31

Family

ID=59648721

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/112069 WO2018095308A1 (zh) 2016-11-25 2017-11-21 一种业务量的预测方法及装置

Country Status (3)

Country Link
US (1) US11443251B2 (zh)
CN (3) CN108921333B (zh)
WO (1) WO2018095308A1 (zh)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108921333B (zh) 2016-11-25 2021-04-27 口碑(上海)信息技术有限公司 一种业务量的预测方法及装置
CN109471783B (zh) * 2017-09-08 2022-07-05 北京京东尚科信息技术有限公司 预测任务运行参数的方法和装置
CN109146128B (zh) * 2018-06-29 2022-02-18 创新先进技术有限公司 业务数据处理方法、装置及服务器
CN110728588A (zh) * 2018-07-17 2020-01-24 新智数字科技有限公司 表计抄表的方法、远程管理平台及业务系统
CN109242519B (zh) * 2018-09-25 2022-12-16 创新先进技术有限公司 一种异常行为识别方法、装置和设备
CN109302352A (zh) * 2018-10-09 2019-02-01 阿里巴巴集团控股有限公司 一种数据流量控制方法、装置及系统
CN111385328B (zh) * 2018-12-29 2024-04-05 三六零科技集团有限公司 业务请求的处理方法、系统及电子设备
CN111833083B (zh) * 2019-04-17 2024-06-11 杭州淘票票影视文化有限公司 多媒体内容的数据处理方法及装置
CN110163417B (zh) * 2019-04-26 2023-09-01 创新先进技术有限公司 一种业务量的预测方法、装置及设备
CN112243258B (zh) * 2020-10-14 2023-08-11 中国联合网络通信集团有限公司 一种用户感知速率的确定方法及装置
US11876721B2 (en) * 2021-04-09 2024-01-16 Microsoft Technology Licensing, Llc Time-based traffic routing
CN115082133B (zh) * 2022-08-19 2022-11-18 深圳云威网络科技有限公司 一种用于目标页流量分析管理系统及管理方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104182801A (zh) * 2013-05-22 2014-12-03 阿里巴巴集团控股有限公司 一种预测网站访问量的方法及设备
CN104616086A (zh) * 2015-02-28 2015-05-13 北京嘀嘀无限科技发展有限公司 用于动态设置订单的缓冲时间的方法和设备
CN104616065A (zh) * 2015-02-13 2015-05-13 北京嘀嘀无限科技发展有限公司 用于处理订单的方法及设备
CN107092973A (zh) * 2016-11-25 2017-08-25 口碑控股有限公司 一种业务量的预测方法及装置

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6970829B1 (en) * 2000-02-14 2005-11-29 Iex Corporation Method and system for skills-based planning and scheduling in a workforce contact center environment
US6842719B1 (en) * 2003-02-26 2005-01-11 Kerien W. Fitzpatrick Real-time prediction and management of food product demand
JP2005010970A (ja) * 2003-06-18 2005-01-13 Hitachi Ltd 分散キャッシュ制御方法、ネットワークシステムおよび当該ネットワークに用いられる制御サーバないしルータ
CN102111284B (zh) * 2009-12-28 2013-09-04 北京亿阳信通科技有限公司 电信业务量预测方法和装置
JP5606214B2 (ja) * 2010-08-18 2014-10-15 シャープ株式会社 電力自動売買システム
CN102819768B (zh) * 2011-11-07 2015-08-19 金蝶软件（中国）有限公司 客流数据分析的方法及系统
US8595050B2 (en) * 2011-12-27 2013-11-26 Grubhub, Inc. Utility for determining competitive restaurants
CN102711177A (zh) * 2012-04-26 2012-10-03 北京邮电大学 基于业务预测的负载均衡方法
WO2014054612A1 (ja) * 2012-10-01 2014-04-10 日本電気株式会社 到着時間分布制御システム、到着時間分布制御装置及びインセンティブ設計方法
CN104424294A (zh) * 2013-09-02 2015-03-18 阿里巴巴集团控股有限公司 一种信息处理方法及装置
CN103490956A (zh) * 2013-09-22 2014-01-01 杭州华为数字技术有限公司 基于业务量预测的自适应节能控制方法及设备、系统
CN106063204A (zh) * 2014-04-03 2016-10-26 英派尔科技开发有限公司 域名服务器业务量估计
CN103984993B (zh) * 2014-05-13 2017-01-25 东南大学 一种轨道交通客流od分布实时推测方法
CN104581779B (zh) * 2014-12-11 2018-11-30 华为技术有限公司 一种业务处理方法以及装置
CN104504595B (zh) * 2014-12-19 2017-12-08 上海点啥网络科技有限公司 一种基于在线订购的可预估取货时间的方法及其应用
CN104599092B (zh) * 2015-02-25 2019-02-12 北京嘀嘀无限科技发展有限公司 用于监控订单业务的方法及设备
CN105719019A (zh) * 2016-01-21 2016-06-29 华南理工大学 一种考虑用户预约数据的公共自行车高峰期需求预测方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104182801A (zh) * 2013-05-22 2014-12-03 阿里巴巴集团控股有限公司 一种预测网站访问量的方法及设备
CN104616065A (zh) * 2015-02-13 2015-05-13 北京嘀嘀无限科技发展有限公司 用于处理订单的方法及设备
CN104616086A (zh) * 2015-02-28 2015-05-13 北京嘀嘀无限科技发展有限公司 用于动态设置订单的缓冲时间的方法和设备
CN107092973A (zh) * 2016-11-25 2017-08-25 口碑控股有限公司 一种业务量的预测方法及装置

Also Published As

Publication number Publication date
CN108921333B (zh) 2021-04-27
CN107092973A (zh) 2017-08-25
US11443251B2 (en) 2022-09-13
CN108596401A (zh) 2018-09-28
US20200074357A1 (en) 2020-03-05
CN107092973B (zh) 2018-05-25
CN108921333A (zh) 2018-11-30
CN108596401B (zh) 2020-04-24

Similar Documents

Publication Publication Date Title
WO2018095308A1 (zh) 一种业务量的预测方法及装置
WO2019007286A1 (zh) 一种事件提醒方法及装置
WO2020063174A1 (zh) 一种资源分享方法、装置及设备
KR102399908B1 (ko) 결제 방법, 장치 및 디바이스
US20200294141A1 (en) Credit guarantee-based service processing
WO2019196543A1 (zh) 二维码图片获取方法、装置以及设备
US11188987B2 (en) System and method for providing a spend memory record
TWI718379B (zh) 針對使用共享物品的使用者評估方法、裝置及設備
WO2022267766A1 (zh) 访问聚合码支付页面的方法、装置、设备及介质
US20190295136A1 (en) Method and device for releasing evaluation information
CA3059627A1 (en) Method and device for account creation, account refilling and data synchronization
WO2018188621A1 (zh) 一种资源传输方法及装置
CN108153795B (zh) 一种电子红包的数据处理方法、系统和装置
CN108985817B (zh) 关联业务处理方法及装置、店铺推荐方法及装置
US20140279302A1 (en) Automatic budget tracking and notification
WO2019214305A1 (zh) 一种基于doi的支付方法、装置及设备
US11087382B2 (en) Adapting digital order to venue service queue
WO2019137357A1 (zh) 付款码获取、支付请求响应方法、装置以及设备
WO2021218667A1 (zh) 资源转移任务的触发
CN112184193A (zh) 缴费处理方法及装置
WO2017124935A1 (zh) 事务处理方法和系统
US20240103736A1 (en) Systems and methods for managing access to resources in a computing environment
US20200322298A1 (en) Electronic message reply criteria tracking and compensation initation system
CA3175260A1 (en) Systems and methods for managing access to resources in a computing environment
WO2016045543A1 (zh) 一种电子邮件显示方法、装置及一种电子装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17873121

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17873121

Country of ref document: EP

Kind code of ref document: A1