CN113411272A

CN113411272A - Traffic scheduling method and device and electronic equipment

Info

Publication number: CN113411272A
Application number: CN202010182842.9A
Authority: CN
Inventors: 岳乾坤; 闫卫斌; 陈爽
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2020-03-16
Filing date: 2020-03-16
Publication date: 2021-09-17

Abstract

The embodiment of the invention relates to a traffic scheduling method, a traffic scheduling device and electronic equipment, wherein the method comprises the following steps: acquiring idle flow of a target time unit; determining a flow packet which corresponds to the target time unit and is available for release according to the idle flow; and pushing the release information of the flow packet to a target user.

Description

Traffic scheduling method and device and electronic equipment

Technical Field

Embodiments of the present invention relate to the field of traffic scheduling technologies, and in particular, to a traffic scheduling method, a traffic scheduling apparatus, an electronic device, and a computer-readable storage medium.

Background

The network throughput capacity is an important competitive power of the storage service, the access traffic of the storage user has an obvious 'peak valley' characteristic, and the traffic usage in the daytime is usually several times that in the nighttime, so that the traffic capacity of the service party at nighttime is obviously in an idle waste state, and a new traffic scheduling method is necessarily provided to realize the effective utilization of idle traffic.

Disclosure of Invention

The embodiment of the invention provides a new technical scheme for flow scheduling.

According to a first aspect of the present invention, an embodiment of a traffic scheduling method is provided, the method including:

acquiring idle flow of a target time unit;

determining a flow packet which corresponds to the target time unit and is available for release according to the idle flow;

and pushing the release information of the flow packet to a target user.

Optionally, the determining, according to the idle traffic, a traffic packet available for release corresponding to the target time unit includes:

and splitting the idle flow into at least one flow packet which corresponds to the target time unit and is available for release by taking a set flow unit as a unit.

Optionally, the method further comprises a step of determining the flow unit, including:

acquiring historical access data of a historical time unit, wherein the historical time unit is a previous time unit corresponding to the target time unit in the same period, and the historical access data comprises: the number of users using traffic in the historical time unit, and/or the traffic usage of the users in the historical time unit;

and determining the flow unit according to the historical access data.

Optionally, the method further comprises:

detecting whether a function of releasing idle flow is started or not;

and executing the operation of acquiring the idle flow of the target time unit under the condition that the function is started.

Optionally, the method further comprises:

and acquiring the user for starting the permission of occupying the idle flow as the target user.

Optionally, the method further comprises:

determining a selling price of the flow package;

providing a selling price of the flow package in the release information.

Optionally, the determining the selling price of the flow rate package comprises:

determining the selling price of the flow packet according to at least one item of the size of the flow packet, the size of the idle flow and the idle flow preemption record of the historical time unit;

wherein the historical time unit is a previous time unit of the same period of time corresponding to the target time unit.

Optionally, the method further comprises:

determining whether any target user is successfully preempted according to a preemption request for the traffic packet sent by any target user after receiving the release information;

and recording the traffic packet occupied by any target user under the account of any target user under the condition of successful preemption.

Optionally, the method further comprises:

and in the target time unit, preferentially using the preempted traffic packet relative to the original traffic of any target user to execute the preset task of any target user.

Optionally, the method further comprises:

and after the target time unit is finished, clearing the occupied traffic packet recorded under the account.

Optionally, after recording the traffic packet occupied by the arbitrary target user under the account of the arbitrary target user, the method further includes:

judging whether the traffic resource of the service node where the any target user is currently located can meet the traffic use requirement of the any target user according to the available traffic of the account;

and under the condition that the traffic use requirement cannot be met, dispatching the any target user to other service nodes meeting the traffic use requirement.

Optionally, the method further comprises:

for the preempted traffic packet, determining the maximum usage amount of the arbitrary target user for the traffic packet in each sub-period of the target time unit;

and executing a preset task based on the corresponding maximum usage amount in any sub-period.

Optionally, the method further comprises the step of determining a maximum usage of the arbitrary sub-period, comprising:

determining the maximum usage amount of any sub-period according to the size of the preempted flow packet and/or the time-sharing flow control result of the flow packet of the historical time unit preempted by any target user;

wherein the historical time unit is a previous time unit corresponding to the target time unit in the same period; the time-sharing flow control result comprises the maximum usage amount of each sub-period set for the historical time unit and/or the usage rate of the allocated flow resource of the arbitrary target user in each sub-period of the historical time unit.

Optionally, the method further comprises a step of determining an idle traffic of the target time unit, including:

acquiring the maximum service flow supported by the target service node corresponding to the flow scheduling in the target time unit;

acquiring the predicted usage flow of the target time unit;

and determining the idle flow of the target time unit according to the maximum service flow and the predicted using flow.

Optionally, the obtaining of the maximum service traffic supported by the target service node corresponding to the traffic scheduling in the target time unit includes:

and acquiring the E2E capability C1 of the target service node in the target time unit as the maximum service traffic.

Optionally, the method further comprises the step of obtaining a predicted usage flow rate of the target time unit, comprising:

obtaining the predicted use flow of the target time unit through a preset model;

wherein the model is arranged to provide a predicted usage flow for the target time unit based on an actual usage flow for a historical time unit, the historical time unit being a previous time unit corresponding to the target time unit for the same period of time.

Optionally, the step of obtaining the predicted usage flow rate of the target time unit further includes:

correcting the model according to the use flow deviation of the historical time unit closest to the target time unit;

the obtaining of the predicted usage flow of the target time unit through a preset model comprises:

and obtaining the predicted use flow of the target time unit according to the corrected model.

Optionally, the method further comprises:

acquiring network flow parameters of the target time unit, wherein the network flow parameters comprise at least one of network inlet and outlet flow, load balancing equipment flow, front-end equipment flow, index layer load flow of a distributed system and disk load flow;

determining the actual use flow of the target time unit according to the network flow parameter of the target time unit;

and correcting the model according to the deviation between the actual use flow of the target time unit and the predicted use flow of the target time unit.

According to a second aspect of the present invention, there is provided another embodiment of a traffic scheduling method, which is implemented by a terminal device, the method including:

providing a preemption interface for preempting a flow packet according to release information of the release flow packet pushed by a server, wherein the release information comprises the flow packet which can be released in a target time unit;

acquiring a preemption request for the flow packet sent by the preemption interface;

sending the preemption request to the server for preemption processing;

and acquiring and providing preemption result information returned by the server after the preemption processing.

Optionally, the method further comprises:

acquiring the number of the preempted flow packets corresponding to the target time unit according to the preemption result information;

and closing the preemption interface for preempting the flow packets of the target time unit under the condition that the number reaches the set upper limit of the number.

According to a third aspect of the present invention, there is also provided an embodiment of a traffic scheduling apparatus, including:

the flow acquisition module is used for acquiring the idle flow of the target time unit;

a release processing module, configured to determine, according to the idle traffic, a traffic packet that corresponds to the target time unit and is available for release; and the number of the first and second groups,

and the release interaction module is used for pushing the release information of the flow packet to a target user.

According to a fourth aspect of the present specification, there is further provided an embodiment of an electronic device, including the traffic scheduling apparatus according to the third aspect of the present specification, or the electronic device includes:

a memory for storing executable commands;

a processor, configured to execute the traffic scheduling method according to the first aspect or the second aspect of the present specification under the control of the executable command.

According to a fifth aspect of the present description, there is also provided an embodiment of a computer-readable storage medium storing executable instructions that, when executed by a processor, perform the traffic scheduling method according to the first or second aspect of the present description.

In one embodiment, the idle traffic of any target time unit is obtained, and the idle traffic is split into the traffic packets which can be released, so that the target user can seize the traffic packets for free or at a lower price, thereby effectively utilizing the idle traffic of any time unit and achieving the traffic balancing effect of peak clipping and valley filling.

Other features of the present description and advantages thereof will become apparent from the following detailed description of exemplary embodiments thereof, which proceeds with reference to the accompanying drawings.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the specification and together with the description, serve to explain the principles of the specification.

FIG. 1 is a schematic diagram of a scenario in which a traffic scheduling method of an embodiment may be implemented;

FIG. 2 is a block diagram of a hardware configuration of a traffic scheduling system that may be used to implement one embodiment;

FIG. 3 is a flow diagram of a method of traffic scheduling according to one embodiment;

FIG. 4 is a flow diagram of a method of traffic scheduling according to one embodiment;

FIG. 5 is an interactive flow diagram of a traffic scheduling method according to an example;

FIG. 6 is a functional block diagram of a traffic scheduling apparatus according to one embodiment;

FIG. 7 is a functional block diagram of an electronic device according to one embodiment.

Detailed Description

Various exemplary embodiments of the present specification will now be described in detail with reference to the accompanying drawings.

The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or uses.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, further discussion thereof is not required in subsequent figures.

With the advent of the internet era, various network services are more abundant, and when a user uses a network service, for example, when accessing a storage service, the user needs to occupy service resources such as service traffic of a service node, where the service node may be a single node or a cluster node, and the like, which is not limited herein. For the use of network services, because the demand in the daytime is significantly higher than the demand at night, the access traffic of a user accessing a service node has a significant peak-valley characteristic, which, under the condition that the throughput of the service node is constant, will generate a large idle traffic in a period of low access traffic, and further cause an unbalanced problem in the use of service resources. In order to achieve balanced use of service resources as much as possible, traffic scheduling measures need to be adopted to achieve the effect of peak and valley removal of service traffic.

In one traffic scheduling scheme, cross-cluster scheduling may be performed on service traffic, which can solve the problem of resource usage imbalance among different clusters in the same time period, but cannot solve the problem of resource usage imbalance in different time periods.

In an embodiment of the present invention, because the idle traffic is used as preemptive traffic, the idle traffic can be provided to the user for free use or sold to the user at a lower price than normal traffic, and therefore, if the user occupies the idle traffic, it means that the user can use the network service at a lower cost in the time unit, which will attract the user to visit the service node in the time period with originally lower visiting traffic, thereby effectively solving the problem of uneven use of resources in different time periods.

Fig. 1 shows a schematic application scenario diagram of the method of the embodiment. As shown in fig. 1, in this embodiment, the server 1100, as a traffic scheduling device, may obtain idle traffic of the service cluster 2000 (a service node) in time sharing on the next day on the current day, for example, this may obtain the idle traffic in time units of 30 minutes, 1 hour, or other integer hours. In the case of obtaining the time-sharing idle traffic in the time unit of 1 hour, for the next day, 24 idle traffic will be obtained, including idle traffic of 0:00-1:00, 1:00-2:00, idle traffic of 2:00-3:00, idle traffic of 3:00-4:00, … …, and idle traffic of 23:00-24: 00. Here, for any day, only the time-sharing idle traffic of the set time range may be obtained, and the set time range may be a time range in which a large idle traffic exists in one day, for example, a time range of 0:00 to 7:00, so as to improve the cost performance of processing the idle traffic according to the method of the embodiment, which is not limited herein. After obtaining the time-sharing idle traffic of the next day, the server 1100 may split the idle traffic of the target time unit into at least one traffic packet meeting the minimum usage requirement, where the target time unit is any time interval of the next day, for example, 1:00-2:00 time intervals of the next day, and push release information of the traffic packets available for release to the target user, where the release information may include usage time of the traffic packet, and may also include at least one of a size of the traffic packet, a number of the traffic packets, and a selling price of the traffic packet.

After receiving the release information, the terminal device 1200 of the target user may prompt the target user to have idle traffic that can be preempted at a low price, for example, if the target user needs to preempt the idle traffic, the terminal device may enter a traffic preemption interface that displays the release information of the traffic packets, and send a preemption request to the server 1100 through a key that triggers the preemption request and is provided by the traffic preemption interface, for example, the target user initiates a preemption request for a traffic packet whose usage age is 1:00-2:00 of the next day.

After receiving the preemption request, the server 1100 determines whether the target user successfully preempts the requested traffic packet, and if the preemption is successful, adds the preempted traffic packet to the account of the target user. In this way, the target user may perform traffic tasks using the traffic packet at 1:00-2:00 on the next day.

In this application scenario, the server 1100 may be any device in the service cluster 2000, or may be another device independent of the service cluster 2000, which is not limited herein.

< hardware Equipment >

Fig. 2 is a schematic structural diagram of a traffic scheduling system to which the traffic scheduling method according to an embodiment of the present invention can be applied.

As shown in fig. 2, the traffic scheduling system 1000 of the present embodiment may include a server 1100 and a terminal device 1200.

The server 1100 may be, for example, a blade server, a rack server, or the like, and the server 1100 may also be a server cluster deployed in a cloud, which is not limited herein.

As shown in fig. 2, the server 1100 may include a processor 1110, a memory 1120, an interface device 1130, and a communication device 1140. Processor 1110 is configured to execute program instructions that may employ an instruction set of architectures such as x86, Arm, RISC, MIPS, SSE, and the like. The memory 1120 includes, for example, a ROM (read only memory), a RAM (random access memory), a nonvolatile memory such as a hard disk, and the like. The interface device 1130 includes, for example, a USB interface, a serial interface, an RJ45 interface, and the like.

In this embodiment, the memory 1120 of the server 1100 is configured to store instructions for controlling the processor 1110 to operate to implement or support the implementation of a traffic scheduling method according to any of the embodiments. The skilled person can design the instructions according to the solution disclosed in the present specification. How the instructions control the operation of the processor is well known in the art and will not be described in detail herein.

Those skilled in the art will appreciate that although a number of devices are shown in fig. 2 for the server 1100, the server 1100 of the present embodiments may refer to only some of the devices, such as the processor 1110, the memory 1120, and the communication device 1140, among others.

As shown in fig. 2, the terminal apparatus 1200 may include a processor 1210, a memory 1220, an interface device 1230, a communication device 1240, a display device 1250, an input device 1260, an audio output device 1270, an audio pickup device 1280, and the like. The processor 1210 may be a central processing unit CPU, a microprocessor MCU, or the like. The memory 1220 includes, for example, a ROM (read only memory), a RAM (random access memory), a nonvolatile memory such as a hard disk, and the like. The interface device 1230 includes, for example, a USB interface, a headphone interface, and the like. The communication device 1240 can perform wired or wireless communication, for example. The display device 1250 is, for example, a liquid crystal display, a touch display, or the like. The input device 1260 may include, for example, a touch screen, a keyboard, a mouse, and the like. The terminal apparatus 1200 may output the audio information through the audio output device 1270, the audio output device 1270 including a speaker, for example. The terminal apparatus 1200 may pick up voice information input by the user through the audio pickup device 1280, and the audio pickup device 1280 includes, for example, a microphone.

The terminal device 1200 may be a smart phone, a laptop computer, a desktop computer, a tablet computer, etc., and is not limited herein.

In this embodiment, the memory 1220 of the terminal device 1200 is configured to store instructions for controlling the processor 1210 to operate to implement or support the implementation of a traffic scheduling method according to any of the embodiments. The skilled person can design the instructions according to the solution disclosed in the present specification. How the instructions control the operation of the processor is well known in the art and will not be described in detail herein.

It should be understood by those skilled in the art that although a plurality of devices of the terminal apparatus 1200 are illustrated in fig. 2, the terminal apparatus 1200 of the present embodiment may refer to only some of the devices.

As shown in fig. 2, the server 1100 and the terminal device 1200 may be communicatively connected through a network 1300, where the network 1300 may be a wireless network, a wired network, a local area network, or a wide area network.

The traffic scheduling system 1000 shown in fig. 2 is merely illustrative and is in no way intended to limit the present description, its applications, or uses. For example, although fig. 2 shows only one server 1100 and one terminal device 1200, it is not meant to limit the respective numbers, and the traffic scheduling system 1000 may include a plurality of servers 1100 and/or a plurality of terminal devices 1200.

< method embodiment I >

The present embodiment provides a traffic scheduling method, which is implemented by a traffic scheduling device, which may be, for example, the server 1100 in fig. 1 and fig. 2. Fig. 3 shows a schematic flow chart of the traffic scheduling method of this embodiment, taking an arbitrary time unit of an arbitrary service node as an example, where the arbitrary service node is denoted as a target service node, the arbitrary time unit is denoted as a target time unit, and the target time unit has a date identifier and a time period identifier, for example, a time period of the target time unit is day.

As shown in fig. 3, the traffic scheduling method of this embodiment may include the following steps S3100 to S3300:

step S3100, acquiring an idle traffic of the target time unit.

The idle traffic of the target time unit is the remaining traffic existing in the target time unit by the target service node.

In this embodiment, the idle traffic of the target time unit may be estimated before entering the target time unit, so as to be acquired in step S3100.

In one embodiment, the method may further include the following steps S3011 to S3013:

step S3011, obtain the maximum service traffic that the target service node can provide in the target time unit.

The maximum service traffic reflects a maximum network throughput of the target service node at the target event unit.

The maximum service traffic may be represented by E2E capability C1 of the target service node at the target time unit, i.e., in one embodiment, the obtaining the maximum service traffic of the target service node at the target time unit may include: and acquiring the E2E capability C1 of the target service node in the target time unit as the maximum service flow.

In step S3012, the predicted usage flow rate for the target time unit is obtained.

The predicted usage traffic is a predicted value of service traffic occupied by the target service node in the target time unit.

In this embodiment, the predicted usage flow rate of the target time unit may be provided by a preset model.

In one embodiment, the model may set the predicted usage flow for any period of time, and determine the predicted usage flow for the target time unit based on the period of time corresponding to the target time unit. For example, the predicted usage flow rate for the 0:00-1:00 time period is set to be W01, the predicted usage flow rate for the 1:00-2:00 time period is set to be W12, and so on, so that the predicted usage flow rate for the target time unit is W12 in the case where the time period corresponding to the target time unit is 1:00-2: 00.

In another embodiment, the model may also be configured to determine the predicted usage flow for the target time unit based on actual usage flow for a historical time unit corresponding to the target time unit, wherein the historical time unit is a prior time unit corresponding to the target time unit for the same period of time.

For example, the model may be set to use the actual usage traffic of the historical time unit closest to the target time unit as the predicted usage traffic of the target time unit. The actual usage traffic is an actual value of the service traffic occupied by the target service node in the corresponding historical time unit.

For another example, the model may be configured to use an average value of actual usage flow rates of historical time units within a set time range as the predicted usage flow rate of the target time unit.

For another example, the model may be set to use the minimum value of the actual usage flow rate of the historical time unit in the set time range as the predicted usage flow rate of the target time unit.

For example, the model may be modified according to a deviation between an actual usage flow rate of a historical time unit closest to the target time unit and a predicted usage flow rate of the corresponding historical time unit, so as to obtain the predicted usage flow rate of the target time unit through the modified model, which is not limited herein.

The correction is, for example, to determine a correction factor according to the deviation, so that the model can determine the predicted usage flow rate of the target time unit by the correction factor.

In order to realize continuous modification of the adopted model so as to continuously improve the prediction accuracy of the model, after the target time unit is entered, the method can further comprise the following steps: collecting the network flow parameter of the target time unit; determining the actual use flow of the target time unit according to the network flow parameter of the target time unit; and correcting a model used for flow rate prediction based on a deviation between an actual usage flow rate and a predicted usage flow rate of the target time unit.

In this embodiment, the method may further include the step of obtaining an actual usage flow rate of any historical time unit, including: acquiring network flow parameters acquired in any historical time unit; and determining the actual use flow of the arbitrary historical time unit according to the network flow parameter.

The network flow parameter comprises at least one of network inlet and outlet flow, load balancing equipment flow, front-end equipment flow, index layer load flow of a distributed system and disk load flow.

Step S3013, determining the idle traffic of the target time unit for obtaining in step S3100 according to the maximum service traffic and the predicted usage traffic.

According to the step S3013, the idle traffic of the target time unit is equal to the difference between the maximum service traffic and the predicted usage traffic.

Step S3200, determining a flow packet for release corresponding to the target time unit according to the idle flow.

In an embodiment, the idle traffic can be split into at least one traffic packet according to the size of the idle traffic, so as to improve the probability that a target user with a use demand can occupy the idle traffic.

In this embodiment, the sizes of the traffic packets obtained by splitting may be the same or different, and are not limited herein.

In one embodiment, the step S3200 of determining the traffic packets available for release corresponding to the target time unit according to the idle traffic may include the following steps: and taking the set flow unit as a unit, splitting the idle flow into at least one flow packet which corresponds to the target time unit and is available for release.

The flow unit may be a fixed value set in advance.

The traffic unit may recognize the requirement for performing the basic task, for example, the traffic unit is set to 10Gbps, and the like, which is not limited herein.

In this embodiment, a unified traffic unit may be set. For this reason, any split flow packet may have one flow unit, or may have one flow unit or other integer number of flow units, which is not limited herein.

In this embodiment, two or more standard traffic units may be set, so that the idle traffic can be split into traffic packets of different specifications according to the traffic units.

In this embodiment, the set traffic unit may also be continuously adjusted according to the number of users using the network service in the target time unit and/or the traffic usage of the users in the target time unit, so that the traffic packet obtained by splitting according to the traffic unit can better meet the usage requirement of the users. In this regard, the method may further include the step of determining the flow cell, including: acquiring historical access data of a historical time unit corresponding to the target time unit; and determining the flow unit according to the historical access data.

The historical access data may include, for example: at least one of the number of users using traffic in the historical time unit and the traffic usage of the users in the historical time unit.

This may be, for example, the smallest flow usage as the flow unit.

For another example, this may be to divide the idle traffic equally by the number of users and take the average as the traffic unit.

For another example, this may be to divide the idle traffic equally according to the number of users, if the average traffic is greater than the minimum traffic usage, then the average traffic is taken as the traffic unit, otherwise, the minimum traffic usage is taken as the traffic unit, and the like, which is not limited herein.

Step S3300, the release information of the traffic packet is pushed to the target user.

The release information may include the usage age of the traffic packet, that is, the time information of the target time unit corresponding to the traffic packet, where the time information includes the date and the time period, for example, the time period.

The release information may also include the size of the traffic packet.

The release information may also include the number of traffic packets, etc.

The release information may also include the selling price of the traffic packet.

According to the step S3300, the target user receiving the release information can preempt the traffic packet through the respective terminal device, and if the target user preempts the traffic packet, the target user can access the target service node at a lower cost by using the preempted traffic packet within the corresponding usage timeliness range, and execute a preset task.

The target user may be all users of the target service node, or may be a part of users selected from all users, which is not limited herein.

In an embodiment, the traffic scheduling device may push the release information of the traffic packet only to the user who starts to preempt the idle traffic right, so as to improve the conversion rate of the pushing.

In this embodiment, the method may further include the steps of: and acquiring a user for starting the permission of occupying the idle flow as a target user.

In this embodiment, the user of the target service node may select to turn on the idle traffic preemption permission or turn off the idle traffic preemption permission, and the like, through the terminal device.

As can be seen from the above steps 3100 to S3300, by the method of this embodiment, the idle traffic of any target time unit can be split into the traffic packets that can be sold, and the release information of the traffic packets is pushed to the target user, so that the target user can seize the traffic packet at a lower price to guide the target user to use the network service in the time period when the original idle traffic is large, and reduce the traffic occupation in the hot time period.

In an embodiment, the target service node may select whether to start a function of releasing idle traffic, and the traffic scheduling device may determine whether to perform the steps S3100 to S3300 for the target service node according to whether the target service node starts the function, so as to improve flexibility of performing traffic scheduling.

In this embodiment, the method may further include the following steps S3021 to S3022:

step S3021, detecting whether to start the function of releasing the idle traffic.

In this embodiment, the operation and maintenance staff may set any service node to turn on or off the function through the operation terminal, and send the setting result to the traffic scheduling device for recording. The operation terminal is a terminal device used by operation and maintenance personnel, and the terminal device can be a mobile phone, a PC (personal computer), a notebook computer, a tablet computer and the like.

In step S3022, when the function has been turned on, the operation of acquiring the idle traffic of the target time unit in step S3100 above is executed again.

In this embodiment, if the target service node does not turn on the function, the traffic scheduling device will not execute the above steps S3100 to S3300 for the target service node.

In one embodiment, the release information of the traffic packet pushed in step S3300 may include a selling price of the traffic packet, so that the target user may select whether to preempt the idle traffic according to whether the selling price meets its expectation.

In this embodiment, the method may further include the following steps S3031 to S3032:

in step S3031, the selling price of the flow rate package obtained in step S3200 is determined.

For example, the flow scheduler may set a uniform selling price for any flow packet.

For another example, the traffic scheduling device may pre-store a comparison table reflecting a mapping relationship between the time period and the selling price, so that the selling price of the time period corresponding to the target time unit may be looked up in the comparison table as the selling price of each traffic packet obtained in step S3200.

For another example, the flow scheduling device may determine the selling price of the corresponding flow packet according to the size of the flow packet. In this case, the selling price of the unit flow rate can be preset, and thus, the selling price of the corresponding flow rate packet can be determined according to the unit flow rate number of the flow rate packet.

For another example, the selling price of the flow packet may be determined according to the size of the idle flow rate of the target time unit, which may be that the more the idle flow rate of the target time unit is, the lower the selling price of the flow packet, and the like. For this, a comparison table reflecting the idle flow range and the selling price of the flow packet may be preset to determine the selling price of the flow packet of the target time unit, etc. according to the comparison table.

For another example, the selling price of the traffic packet of the target time unit may be determined according to the idle traffic preemption record of the historical time unit corresponding to the target time unit. The idle traffic preemption record includes preemption number, preemption success rate, and selling price of the traffic packet, etc.

For another example, the selling price of the flow package for the target time cell may also be determined according to any combination of the above examples.

The selling price of the flow rate package may be a definite value or a price range, which is not limited herein. In the case of a price range, the final price of the preempted traffic packets may be dynamically adjusted within the price range according to the preempted ranking and/or the remaining amount of traffic packets, etc.

Step S3032 provides the selling price of the flow package in the release information of the flow package.

In this embodiment, referring to fig. 1, the selling price of the corresponding flow packet may be provided in each piece of release information.

In one embodiment, after receiving the release information of the traffic packet, any target user may preempt the traffic packet as needed, and if the traffic packet is preempted, the traffic packet may be used in the target time unit, so as to reduce the cost of using the network service.

In this embodiment, the method may further include the following steps S3411 to S3412:

step S3411, determining whether any target user successfully preempts based on the preemption request for preempting the traffic packet sent by the target user after receiving the release information.

In this embodiment, a preemption object for any one preemption request may be set as a traffic packet.

In this embodiment, the target user may also be allowed to select the number of traffic packets to be preempted, and for this purpose, the preemption request may include information on the number of traffic packets to be preempted.

In one embodiment, processing the preemption request to determine whether the preemption of the arbitrary target user was successful may include: checking whether the arbitrary target user has successfully paid the fee of the flow packet to be preempted, and determining that the preemption fails under the condition of unsuccessful payment.

In another embodiment, it may be configured to, in a case that it is determined that the preemption is successful, request the arbitrary target user to pay a fee again, for example, the fee is not received within a set time, and re-release the traffic packet preempted by the arbitrary target user, which is not limited herein.

In one embodiment, processing the preemption request may also include: and determining whether the arbitrary target user is successfully preempted according to the current residual quantity of the flow packets of the target time unit, namely embodying the preemptive-first-obtained state.

In one embodiment, processing the preemption request may also include: and determining whether the arbitrary target user successfully preempts according to whether the number of the traffic packets preempted by the arbitrary target user for the target time unit reaches a set upper limit of the number.

In this embodiment, for any time unit, an upper limit of the number of traffic packets that can be preempted by any target user may be set. For example, it may be set that any target user can only preempt one traffic packet for any time unit. For example, the upper limit of the number of arbitrary target users for an arbitrary time unit may be set according to the user rank of the arbitrary target users, and the upper limit of the number may be increased as the rank is higher.

In this embodiment, the traffic scheduling device may detect, when receiving the preemption request, whether the preemption channel of the target time unit by the arbitrary target user has been closed, and determine that preemption is successful if not closed, and return a notification of preemption failure to the arbitrary target user if closed, where the preemption channel of the target time unit by the arbitrary target user is closed when the number of traffic packets of the target time unit that the arbitrary target user preempts reaches the corresponding upper limit of the number.

Here, the traffic scheduling device may update the number of the traffic packets of the target time unit that are preempted by the arbitrary target user when the processing result of processing the preemption request is that preemption is successful, and close the preemption channel of the target time unit by the arbitrary target user when the number reaches the corresponding upper limit of the number.

In this embodiment, the terminal device of the arbitrary target user may also be configured to close the interface that preempts the traffic packet of the target time unit when the number of the traffic packets of the target time unit preempted by the arbitrary target user reaches the corresponding upper limit of the number. For example, after any target user has preempted a traffic packet for the next day in fig. 1 for a period of 1:00-2:00, the corresponding "preempt" key is set to indicate a non-triggerable gray, etc.

In an embodiment, a combination of any of the above processing manners may be adopted to determine whether the arbitrary target user performs successful preemption, which is not limited herein.

Step S3412, recording the traffic packet preempted by any target user in the account of the any target user when the preemption is successful.

According to the step S3412, in the case where the preempted traffic packet is recorded in the account, the arbitrary target user can access the target service node using the traffic packet at the target time unit.

In this embodiment, when preemption fails, a preemption result of preemption failure is returned to the arbitrary target user.

In one embodiment, in the case that an arbitrary target user preempts a traffic packet to a target time unit, the arbitrary target user may access a target service node using the preempted traffic packet when the target time unit arrives, so as to execute a preset task of the arbitrary target user.

In this embodiment, the method may further include the steps of: and in the target time unit, preferentially using the preempted traffic packet relative to the original traffic of any target user to execute the preset task of the any target user.

In the embodiment, in the target time unit, the preempted traffic packet is preferentially used to execute the preset task, so that the cost of using the network service of any target user can be effectively reduced.

In this embodiment, the method may also include the steps of: determining the maximum usage amount of the arbitrary target user for the traffic packet in each sub-period of the target time unit according to the preempted traffic packet; and, at any of the sub-periods, performing a preset task based on the corresponding maximum usage.

For example, the preempted traffic packets may be uniformly distributed to each sub-period of the target time unit, and the average value is used as the maximum usage amount, so as to perform time-sharing flow control on the usage of the preempted traffic packets in the target time unit.

For another example, the maximum usage amount of the arbitrary target user in each sub-period of the target time unit may be determined according to the time-sharing flow control result of the preempted idle flow for the historical time unit. The time-sharing flow control result may include a maximum usage amount of each sub-period and a usage rate of the allocated flow resource for each sub-period.

For any sub-period, when the usage of the preempted traffic packet exceeds the corresponding maximum usage amount, the preset task may be refused to be executed, or the preset task may be executed using the original traffic, which is not limited herein.

In one embodiment, since the preempted traffic packet has a usage age, in order to perform effective age management on the preempted traffic packet, the method may further include: and after the target time unit is finished, clearing the occupied traffic packet recorded under the account.

In an embodiment, after an arbitrary target user preempts a traffic packet in a target time unit, the arbitrary target user has a higher traffic usage requirement in the target time unit, and at this time, a target service node may have a situation that its own traffic resource cannot meet the traffic usage requirement.

In this embodiment, after recording the traffic packet occupied by the arbitrary target user under the account of the arbitrary target user, the method may further include the following steps: judging whether the flow resource of the service node where the any target user is currently located can meet the requirements of the any target user or not according to the available flow of the account; and under the condition that the requirement cannot be met, dispatching the arbitrary target user to other service nodes capable of meeting the requirement.

< method example two >

The present embodiment provides a traffic scheduling method, which is implemented by a terminal device, for example, the terminal device 1200 in fig. 1 or fig. 2. Fig. 4 is a flowchart illustrating a traffic scheduling method according to this embodiment. As shown in fig. 4, the identity authentication method of this embodiment may include the following steps S4100 to S4400:

step S4100, providing a preemption interface for preempting the released traffic packet according to release information of the released traffic packet pushed by the traffic scheduling apparatus, where the release information includes the traffic packet available for release in the target time unit.

The release information may further include at least one of a number of the traffic packets released at the target time unit, a size of the traffic packets released at the target time unit, and a selling price of the traffic packets released at the target time unit.

In step S4200, a preemption request for the traffic packet issued by the preemption interface is acquired.

In this embodiment, after receiving the release information, the terminal device may provide, on the traffic preemption interface, a preemption interface for preempting the traffic packet of the target time unit, so that the target user sends a preemption request through the preemption interface.

In one embodiment, the method may further comprise the steps of: acquiring the number of the flow packets of the target time unit which are preempted according to the preemption result information; and closing the preemption interface for preempting the flow packets of the target time unit under the condition that the number reaches the set upper limit of the number.

Step S4300, sending the preemption request to the traffic scheduling device for preemption.

The preemption process includes determining whether the target user successfully preempts a preemption object for the preemption request.

Step S4400 acquires and provides preemption result information returned by the traffic scheduling apparatus after performing the preemption processing.

The preemption result information includes information on preemption success or preemption failure.

If the preemption is successful, the preemption result information may also include a prompt message that records the preempted traffic packet under the corresponding account, and the like, which is not limited herein.

In one embodiment, after the target user successfully preempts, a traffic task corresponding to the target time unit may be set by the terminal device, and after receiving the task information, the terminal device uploads the task information to the traffic scheduling device, so that the traffic scheduling device can call the preempted traffic packet to execute the traffic task when the target time unit arrives, and feed back a task execution result to the terminal device.

< example >

Fig. 5 is a flowchart illustrating an example of traffic scheduling interaction between the traffic scheduling apparatus 6000 and the terminal device 1200 of the target user, where the example illustrates the interaction process by taking traffic scheduling for an arbitrary time unit (denoted as a target time unit) as an example.

As shown in fig. 5, in this example, the traffic scheduling apparatus 6000 may be divided into a traffic analysis module, a traffic release module, and a traffic scheduling module according to the function of the traffic scheduling apparatus 6000.

In this example, as shown in fig. 5, the traffic analysis module determines the idle traffic of the target time unit in step S611, and provides the idle traffic of the target time unit to the traffic release module for traffic release processing.

When the traffic release module performs the traffic release process, in step S621, the idle traffic of the target time unit is split into at least one traffic packet, and in step S622, release information of the traffic packets is generated and pushed to the target user to perform preemption of the traffic packet, where the release information may be marked with a selling price of the traffic packet, and the selling price may be a specific price or a price range, which is not limited herein.

After receiving the release information, the target user may preempt the traffic packet in step S121, and send a preemption request for the released traffic packet to the traffic release module.

The traffic release module, upon receiving the preemption request at step S623, will process the preemption request at step S624 to determine whether preemption was successful. If the preemption is successful, the traffic release module records the preempted traffic packet into the account of the target user in step S625, and feeds back the corresponding preemption result to the target user in step S626, and if the preemption is unsuccessful, the traffic release module proceeds to step S626 and feeds back the corresponding preemption result to the target user.

After receiving the preemption result, the terminal device 1200 provides the preemption result in step S122, and determines whether the preemption is successful in step S123, if so, allows the target user to configure the traffic task corresponding to the target time unit in step S124, and sends the configured traffic task to the traffic release module for recording, and if not, returns to step S121 so that the target user can continue to preempt the traffic.

After receiving the traffic task configured by the target user, the traffic release module may record, in step S627, the traffic task preset by the target user and corresponding to the target time unit.

When the target time unit arrives, the traffic scheduling module may pull the traffic task from the traffic releasing module in step S631, call the preempted traffic packet to execute the traffic task in step S632, and feed back a task execution result to the terminal device 1200 of the target user.

After receiving the task execution result, the terminal device 1200 displays the task execution result in step S125.

< apparatus embodiment >

Fig. 6 shows a functional block diagram of a traffic scheduling device according to an embodiment.

In this embodiment, the traffic scheduling apparatus 6000 may include a traffic acquiring module 6100, a release processing module 6200, and a release interacting module 6300.

In one embodiment, the traffic acquisition module 6100, the release handling module 6200, and the release interaction module 6300 constitute a traffic release module in the above example.

The traffic acquiring module 6100 is configured to acquire the idle traffic of the target time unit.

The release processing module 6200 is configured to determine, according to the idle traffic, a traffic packet available for release corresponding to the target time unit.

The release interaction module 6300 is configured to push release information of the traffic packet to a target user.

In one embodiment, the release processing module 6200, when determining, according to idle traffic, a traffic packet available for release corresponding to the target time unit, may be configured to: and splitting the idle flow into at least one flow packet which corresponds to the target time unit and is available for release by taking a set flow unit as a unit.

In one embodiment, the release handling module 6200 may also be used to determine the flow element. The release handling module 6200, in determining the flow unit, may be configured to: acquiring historical access data of a historical time unit, wherein the historical time unit is a previous time unit corresponding to the target time unit in the same period, and the historical access data comprises: the number of users using traffic in the historical time unit, and/or the traffic usage of the users in the historical time unit; and determining the flow unit according to the historical access data.

In one embodiment, the traffic acquisition module 6100 may also be configured to: detecting whether a function of releasing idle flow is started or not; and executing the operation of acquiring the idle flow of the target time unit under the condition that the function is started.

In one embodiment, the release interaction module 6300 may be further configured to: and acquiring the user for starting the permission of occupying the idle flow as the target user.

In one embodiment, the release processing module 6200 may be further configured to: determining a selling price of the flow package; and providing a selling price of the flow packet in the release information.

In one embodiment, the release processing module 6200, in determining the selling price of the traffic packet, may be to: and determining the selling price of the flow packet according to at least one item of the size of the flow packet, the size of the idle flow and the idle flow preemption record of the historical time unit. The historical time unit is a previous time unit of the same period corresponding to the target time unit.

In one embodiment, the release processing module 6200 may be further configured to: determining whether any target user is successfully preempted according to a preemption request for the traffic packet sent by any target user after receiving the release information; and recording the traffic packet occupied by the any target user under the account of the any target user under the condition that the preemption is successful.

In one embodiment, the apparatus 6000 may further include a traffic scheduling module. The traffic scheduling module may be to: and in the target time unit, preferentially using the preempted traffic packet relative to the original traffic of any target user to execute the preset task of any target user.

In one embodiment, the apparatus 6000 may further include a traffic scheduling module. The traffic scheduling module may be to: and after the target time unit is finished, clearing the occupied traffic packet recorded under the account.

In one embodiment, the apparatus 6000 may further include a traffic scheduling module. The traffic scheduling module may be to: after the flow packet occupied by any target user is recorded under the account of any target user, judging whether the flow resource of the service node where any target user is currently located can meet the flow use requirement of any target user according to the available flow of the account; and under the condition that the traffic use demand cannot be met, dispatching the arbitrary target user to other service nodes meeting the traffic use demand.

In one embodiment, the apparatus 6000 may further include a traffic scheduling module. The traffic scheduling module may be to: for the preempted traffic packet, determining the maximum usage amount of the arbitrary target user for the traffic packet in each sub-period of the target time unit; and executing a preset task based on the corresponding maximum usage amount in any of the sub-periods.

In one embodiment, the traffic scheduling module may also be configured to determine a maximum usage for any of the sub-periods. The traffic scheduling module, when determining the maximum usage amount for any sub-period, may be configured to: and determining the maximum usage amount of any sub-period according to the size of the preempted flow packet and/or the time-sharing flow control result of the flow packet of the historical time unit preempted by any target user.

In this embodiment, the historical time unit is a previous time unit of the same time period corresponding to the target time unit; the time-sharing flow control result comprises the maximum usage amount of each sub-period set for the historical time unit and/or the usage rate of the allocated flow resource of the arbitrary target user in each sub-period of the historical time unit.

In one embodiment, the apparatus 6000 can also include a traffic analysis module, which can be used to determine the idle traffic of the target time unit for the traffic acquisition module 6100 to acquire. The traffic analysis module, when determining the idle traffic for the target time unit, may be configured to: acquiring the maximum service flow supported by the target service node corresponding to the flow scheduling in the target time unit; acquiring the predicted usage flow of the target time unit; and determining the idle flow of the target time unit according to the maximum service flow and the predicted using flow.

In an embodiment, when obtaining the maximum service traffic supported by the target service node corresponding to the traffic schedule in the target time unit, the traffic analysis module may be configured to: and acquiring the E2E capability C1 of the target service node in the target time unit as the maximum service traffic.

In one embodiment, the traffic analysis module may be further configured to obtain a predicted usage traffic for the target time unit. The flow analysis module, when obtaining the predicted usage flow for the target time unit, may be configured to: and obtaining the predicted use flow of the target time unit through a preset model. In this embodiment, the model is arranged to provide a predicted usage flow for the target time unit based on an actual usage flow for a historical time unit, the historical time unit being a previous time unit corresponding to the target time unit for the same period of time.

In one embodiment, the traffic analysis module, when obtaining the predicted usage traffic for the target time unit, may be further configured to: and correcting the model according to the use flow deviation of the historical time unit closest to the target time unit so as to obtain the predicted use flow of the target time unit through a preset model.

In one embodiment, the traffic analysis module may be further configured to: acquiring network flow parameters of the target time unit, wherein the network flow parameters comprise at least one of network inlet and outlet flow, load balancing equipment flow, front-end equipment flow, index layer load flow of a distributed system and disk load flow; determining the actual use flow of the target time unit according to the network flow parameter of the target time unit; and correcting the model according to the deviation between the actual use flow of the target time unit and the predicted use flow of the target time unit.

< apparatus embodiment >

In this embodiment, an electronic device is further provided, and the electronic device 7000 may include the traffic scheduling apparatus 6000 described in the apparatus embodiment of this specification.

In further embodiments, as shown in FIG. 7, the electronic device 7000 may include a memory 7100 and a processor 7200. The memory 7100 is used to store executable commands. The processor 7200 is configured to perform the method described in any of the method embodiments or to perform the method described in any of the second method embodiment under the control of executable commands stored in the memory 7100.

The electronic device 7000 may be a server or a terminal device according to an implementation subject of the executed method embodiment, and is not limited herein.

In one embodiment, any of the modules in the above apparatus embodiments may be implemented by the processor 7200.

< computer-readable storage Medium embodiment >

The present embodiments provide a computer-readable storage medium having stored therein an executable command that, when executed by a processor, performs a method described in any of the method embodiments of the present specification.

One or more embodiments of the present description may be a system, method, and/or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions embodied thereon for causing a processor to implement various aspects of the specification.

The computer readable storage medium may be a tangible device that can hold and store the instructions for use by the instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic memory device, a magnetic memory device, an optical memory device, an electromagnetic memory device, a semiconductor memory device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device, such as punch cards or in-groove projection structures having instructions stored thereon, and any suitable combination of the foregoing. Computer-readable storage media as used herein is not to be construed as transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., optical pulses through a fiber optic cable), or electrical signals transmitted through electrical wires.

The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a respective computing/processing device, or to an external computer or external storage device via a network, such as the internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. The network adapter card or network interface in each computing/processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing/processing device.

The computer program instructions for carrying out operations for embodiments of the present description may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, an electronic circuit, such as a programmable logic circuit, a Field Programmable Gate Array (FPGA), or a Programmable Logic Array (PLA), can execute computer-readable program instructions to implement various aspects of the present description by utilizing state information of the computer-readable program instructions to personalize the electronic circuit.

Aspects of the present description are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the description. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer-readable medium storing the instructions comprises an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present description. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. It is well known to those skilled in the art that implementation by hardware, implementation by software, and implementation by a combination of software and hardware are equivalent.

The foregoing description of the embodiments of the present specification has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen in order to best explain the principles of the embodiments, the practical application, or improvements made to the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein. The scope of the application is defined by the appended claims.

Claims

1. A traffic scheduling method comprises the following steps:

acquiring idle flow of a target time unit;

and pushing the release information of the flow packet to a target user.

2. The method of claim 1, wherein the determining, from the idle traffic, traffic packets corresponding to the target time unit available for release comprises:

3. The method of claim 2, wherein the method further comprises the step of determining the flow cell, comprising:

and determining the flow unit according to the historical access data.

4. The method of claim 1, wherein the method further comprises:

detecting whether a function of releasing idle flow is started or not;

5. The method of claim 1, wherein the method further comprises:

6. The method of claim 1, wherein the method further comprises:

determining a selling price of the flow package;

providing a selling price of the flow package in the release information.

7. The method of claim 6, wherein the determining a selling price of the flow package comprises:

8. The method of claim 1, wherein the method further comprises:

9. The method of claim 8, wherein the method further comprises:

10. The method of claim 8, wherein the method further comprises:

11. The method of claim 8, wherein after recording the traffic packets preempted by the arbitrary target user under an account of the arbitrary target user, the method further comprises:

12. The method of claim 8, wherein the method further comprises:

13. The method of claim 12, wherein the method further comprises the step of determining a maximum usage of the arbitrary sub-period, comprising:

14. The method of claim 1, wherein the method further comprises the step of determining idle traffic for the target time unit, comprising:

acquiring the predicted usage flow of the target time unit;

15. The method of claim 14, wherein the obtaining the maximum service traffic supported by the target serving node corresponding to the traffic schedule in the target time unit comprises:

16. The method of claim 14, further comprising the step of obtaining a predicted usage flow for the target time unit, comprising:

17. The method of claim 16, wherein the step of obtaining the predicted usage flow for the target time unit further comprises:

18. The method of claim 16, further comprising:

19. A traffic scheduling method implemented by a terminal device includes:

sending the preemption request to the server for preemption processing;

20. The method of claim 19, wherein the method further comprises:

21. A traffic scheduling apparatus, comprising:

22. An electronic device comprising the traffic scheduling apparatus of claim 21, or comprising:

a memory for storing executable commands;

a processor for performing the method of any of claims 1-20 under the control of the executable command.

23. A computer-readable storage medium storing executable instructions that, when executed by a processor, perform the method of any one of claims 1-20.