Live streaming scheduling method and apparatus

Abstract

The embodiment of the application provides a live streaming scheduling method and device, wherein the live streaming scheduling method comprises the following steps: receiving a live streaming scheduling request of a client, wherein the live streaming scheduling request contains a live streaming identifier of a to-be-scheduled live streaming; determining a first push streaming server cluster corresponding to the live streaming identifier; determining a target push streaming server cluster according to a to-be-consumed bandwidth corresponding to the to-be-scheduled live streaming, a residual bandwidth of the first push streaming server cluster and / or a target type bandwidth of at least one second push streaming server cluster; generating address information of a target edge server in the target push streaming server cluster; and returning the address information to the client, wherein the address information is used for the client to perform live streaming scheduling on the target edge server to obtain a corresponding scheduling result.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of computer, in particular to a live stream scheduling method. One or more embodiments of the present application also relate to a live stream scheduling device, a live stream scheduling system, a computing device, and a computer readable storage medium. BACKGROUND

[0002] With the development of technology, the definition and smoothness of video services are constantly improving. With the advent of the Internet era, users' demand for high-quality videos will be increasingly high. Currently, high-definition videos have become mainstream. Although the improvement of resolution and definition enhances users' viewing experience, it also dramatically increases traffic usage.

[0003] Currently, the popular video distribution method is to deploy video / audio / picture resources under a content delivery network (CDN). When a user needs to download resources, the user initiates a resource request to the CDN directly to realize downloading, live streaming, and on-demand. However, in the content delivery process, the user needs to manually configure the CDN for content delivery. This process not only has a high degree of human involvement, but also has a high source return rate of the CDN for live stream source return, which affects the bandwidth utilization of the CDN and the efficiency of live stream distribution. Therefore, an effective processing method is needed to solve such problems. SUMMARY

[0004] In view of this, embodiments of the present application provide a live stream scheduling method. One or more embodiments of the present application also relate to a live stream scheduling device, a live stream scheduling system, a computing device, and a computer readable storage medium to solve the technical defects in the prior art, such as the need for users to manually configure the CDN for content delivery, the high degree of human involvement, and the high source return rate of the CDN for live stream source return, which affects the efficiency of live stream distribution.

[0005] According to a first aspect of embodiments of the present application, a live stream scheduling method is provided, including:

[0006] receiving a live stream scheduling request of a client, wherein the live stream scheduling request contains a live stream identifier of a live stream to be scheduled;

[0007] determining a first push stream server cluster corresponding to the live stream identifier, and determining a target push stream server cluster according to a to-be-consumed bandwidth of the live stream to be scheduled, a residual bandwidth of the first push stream server cluster, and / or a target type bandwidth of at least one second push stream server cluster;

[0008] generate address information of a target edge server in the target push stream server cluster, and return the address information to the client, where the address information is used by the client to perform live streaming scheduling on the target edge server to obtain a corresponding scheduling result.

[0009] According to a second aspect of the embodiment of the present application, a live streaming scheduling device is provided, comprising:

[0010] a receiving module configured to receive a live streaming scheduling request of a client, where the live streaming scheduling request contains a live streaming identifier of a live streaming to be scheduled;

[0011] a determining module configured to determine a first push stream server cluster corresponding to the live streaming identifier, and determine a target push stream server cluster according to a to-be-consumed bandwidth of the live streaming to be scheduled, a residual bandwidth of the first push stream server cluster, and / or a target type bandwidth of at least one second push stream server cluster;

[0012] a generating module configured to generate address information of a target edge server in the target push stream server cluster, and return the address information to the client, where the address information is used by the client to perform live streaming scheduling on the target edge server to obtain a corresponding scheduling result.

[0013] According to a third aspect of the embodiment of the present application, a live streaming scheduling system is provided, comprising:

[0014] a first client, a second client, a streaming media server, a scheduling center, and at least two push stream server clusters;

[0015] the streaming media server is configured to receive a live streaming pushed by the first client;

[0016] the scheduling center is configured to receive a live streaming scheduling request of the second client, where the live streaming scheduling request contains a live streaming identifier of a live streaming to be scheduled, determine a first push stream server cluster corresponding to the live streaming identifier, and determine a target push stream server cluster according to a to-be-consumed bandwidth of the live streaming to be scheduled, a residual bandwidth of the first push stream server cluster, and / or a target type bandwidth of at least one second push stream server cluster, generate address information of a target edge server in the target push stream server cluster, and return the address information to the second client;

[0017] the target push stream server cluster is configured to obtain the live streaming to be scheduled from the streaming media server;

[0018] The second client is configured to perform live streaming scheduling to the target edge server based on the address information, and obtain a corresponding scheduling result.

[0019] According to a fourth aspect of the embodiments of the present application, a computing device is provided, comprising:

[0020] a memory and a processor;

[0021] The memory is configured to store computer executable instructions, and the processor is configured to execute the computer executable instructions, and when the processor executes the computer executable instructions, the steps of the live streaming scheduling method are implemented.

[0022] According to a fifth aspect of the embodiments of the present application, a computer readable storage medium is provided, which stores computer executable instructions, and when the instructions are executed by a processor, the steps of the live streaming scheduling method are implemented.

[0023] An embodiment of the present application implements a live streaming scheduling method and device, wherein the live streaming scheduling method comprises receiving a live streaming scheduling request of a client, wherein the live streaming scheduling request comprises a live streaming identifier of a live streaming to be scheduled, determining a first push streaming server cluster corresponding to the live streaming identifier, and determining a target push streaming server cluster according to a to-be-consumed bandwidth corresponding to the live streaming to be scheduled, a residual bandwidth of the first push streaming server cluster, and / or a target type bandwidth of at least one second push streaming server cluster, generating address information of a target edge server in the target push streaming server cluster, and returning the address information to the client, wherein the address information is used for the client to perform live streaming scheduling to the target edge server, and obtain a corresponding scheduling result.

[0024] According to the to-be-consumed bandwidth corresponding to the live streaming to be scheduled and the initial bandwidth or the residual bandwidth corresponding to each push streaming server cluster, an embodiment of the present application determines a target push streaming server cluster that meets a condition, so as to push the live streaming to be scheduled to each live streaming watching user through the target push streaming server cluster, that is, after multiple live streaming watching users respectively submit scheduling requests of the live streaming to be scheduled, the target push streaming server cluster only needs to perform once source returning of the live streaming to be scheduled, and subsequent live streaming scheduling to each live streaming watching user can be implemented, in this way, it is beneficial to reduce the source returning times of the push streaming server cluster to the live streaming to be scheduled, so as to realize reasonable utilization of the bandwidth of the push streaming server cluster, thereby being beneficial to improving the distribution efficiency of the live streaming. BRIEF DESCRIPTION OF DRAWINGS

[0025] Figure 1 is an architecture diagram of a live streaming scheduling system provided by an embodiment of the present application;

[0026] Figure 2is a flow chart of a live stream scheduling method provided by one embodiment of the present application;

[0027] Figure 3 is an interaction schematic diagram of a live stream scheduling method provided by one embodiment of the present application;

[0028] Figure 4 is a structural schematic diagram of a live stream scheduling apparatus provided by one embodiment of the present application;

[0029] Figure 5 is a structural block diagram of a computing device provided by one embodiment of the present application. DETAILED DESCRIPTION

[0030] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. However, the present application can be practiced without the specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the present application. Some portions of the detailed description which follow are presented in terms of algorithms, symbolic representations of operations on data bits or binary digital signals stored within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art.

[0031] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of one or more embodiments of the present application. As used in one or more embodiments of the present application and the accompanying claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used in one or more embodiments of the present application and the following claims, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0032] It will be understood that, although the terms first, second, etc. can be used herein to describe various information, these terms are not intended to denote a temporal or chronological order. Rather, these terms are used solely to distinguish one from another only. For example, a first can be termed a second, and, similarly, a second can be also termed a first, without departing from the scope of one or more embodiments of the present application. As used herein, the term "if' can be construed to mean "when" or "upon" or "in response to determining" terms denoting the occurrence of stated events or actions, depending on the context.

[0033] First, the noun terms related to one or more embodiments of the present application are explained.

[0034] CDN (Content Delivery Network): a content delivery network built on a network.

[0035] Live stream: transmission of live audio and video data, which can be transmitted to viewers as a stable and continuous stream through a network.

[0036] Live room: In the live streaming service, each host has a unique identifier, and the identifier can enter the host's live viewing page, i.e., the live room.

[0037] Relationship between live room and live stream: Generally speaking, one live room corresponds to one live stream. The live stream is for the CDN, and the live room is for the live platform.

[0038] Live uplink: The part of the host pushing the stream to the streaming server is called live uplink.

[0039] Live downlink: The part of the user pulling the stream from the streaming server or CDN for viewing is called live downlink.

[0040] Edge computing: A distributed computing architecture that moves application, data, and service computing from the network center node to the network logical edge node for processing.

[0041] Streaming server: A server that receives user push streams.

[0042] In the present application, a live stream scheduling method is provided. One or more embodiments of the present application simultaneously relate to a live stream scheduling device, a live stream scheduling system, a computing device, and a computer-readable storage medium, which are described in detail one by one in the following embodiments.

[0043] The overall process of the current live streaming is as follows: the host pushes the live stream to the streaming server (edge server), the scheduling center allocates the live stream scheduling task to the target CDN according to the remaining bandwidth resources of each CDN. The target CDN sources back to the streaming server for live stream pulling, and then the live viewing user establishes a connection with the target CDN for pulling and viewing.

[0044] In the live streaming system, the host pushes the stream, and the user watches, which generates downlink bandwidth. The viewing service is generally provided by the CDN service provider, and different CDN service providers can provide limited services, i.e., each CDN can only carry a fixed downlink bandwidth, such as 100G, which means a maximum of 100G downlink bandwidth.

[0045] In order to let the bandwidth usage of each service provider CDN not exceed the maximum limit and ensure a certain usage rate, random allocation is generally made according to the proportion. For example, the downlink bandwidth carried by A CDN is 200G, and the downlink bandwidth carried by B CDN is 300G. When scheduling the live stream, the probability of allocating the scheduling task to A CDN is 200 / (200+300)=40%, and the probability of allocating the scheduling task to B CDN is 60%.

[0046] However, such a processing method has the following problems:

[0047] The return rate is high, and the artificial participation degree is high. Since A CDN and B CDN need to return to the streaming media server for live streaming pull streaming, the export bandwidth of the streaming media server will be increased. If the live streaming distribution task of a live room is allocated to a CDN, the CDN can carry the downlink bandwidth of the task when the number of viewers in the live room is small, but when the number of viewers in the live room is large, the downlink bandwidth of the task may exceed the amount that the CDN itself can carry. If this situation is to be avoided, manual participation is required to configure, and when the downlink bandwidth is close to exceeding the CDN carrying capacity, the live streaming distribution task is redistributed according to the bandwidth remaining of other CDNs.

[0048] For example, under normal circumstances, the live streaming distribution task of live room X is allocated to A CDN, when the number of viewers in live room X is only a few tens of people, the downlink bandwidth generated by the live streaming distribution task is only a few hundred megabytes, which will not cause pressure on the overall bandwidth of A CDN. However, when the number of viewers in live room X is one million, the downlink bandwidth generated by the live streaming distribution task will be several hundred G (such as 300G), which will obviously exceed the carrying capacity (200G) of A CDN. In this case, part of the live streaming distribution task needs to be allocated to B CDN, which increases a return flow. In subsequent live streaming, for example, the next day, the number of viewers in live room X does not reach one million, and the downlink bandwidth generated by the live streaming distribution task does not exceed the carrying capacity of A CDN, so there is no need to allocate part of the live streaming distribution task to other CDNs. In this case, the special configuration of "allocating part of the live streaming distribution task to B CDN" needs to be manually deleted.

[0049] Based on this, the embodiments of the present application make the selection of CDN more accurate in reducing the return source situation and reduce manual intervention.

[0050] Referring to Figure 1 , Figure 1 An architecture diagram of a live streaming scheduling system according to an embodiment of the present application is shown, which includes:

[0051] A first client 102, a second client 104, a streaming media server 106, a scheduling center 108, and at least two push streaming server clusters 110;

[0052] The streaming media server 106 is configured to receive the live streaming pushed by the first client 102;

[0053] The scheduling center 108 is configured to receive a live streaming scheduling request of the second client 104, wherein the live streaming scheduling request contains a live streaming identifier of a live streaming to be scheduled, determine a first push streaming server cluster 110 corresponding to the live streaming identifier, and determine a target push streaming server cluster 110 according to a to-be-consumed bandwidth of the live streaming to be scheduled, a residual bandwidth of the first push streaming server cluster 110, and / or a target type bandwidth of at least one second push streaming server cluster 110, generate address information of a target edge server in the target push streaming server cluster 110, and return the address information to the second client 104;

[0054] The target push streaming server cluster 110 is configured to obtain the live streaming to be scheduled from the streaming media server 106.

[0055] The second client 104 is configured to perform live streaming scheduling on the target edge server based on the address information, and obtain a corresponding scheduling result.

[0056] Figure 1 In the method, the anchor pushes a live streaming to the streaming media server 106 through the first client 102 in a live streaming process, and the live streaming watching user sends a live streaming scheduling request to the scheduling center 108 through the second client 104 when watching the live streaming through the second client 104. The scheduling center 108 determines a first push streaming server cluster 110 corresponding to a live streaming identifier of a live streaming to be scheduled according to the live streaming identifier contained in the live streaming scheduling request, and determines a target push streaming server cluster 110 according to a to-be-consumed bandwidth of the live streaming to be scheduled, a residual bandwidth of the first push streaming server cluster 110, and / or a target type bandwidth of at least one second push streaming server cluster 110, generates address information of a target edge server in the target push streaming server cluster 110, and returns the address information to the second client 104. The target push streaming server cluster obtains the live streaming to be scheduled from the streaming media server 106, and then the second client 104 performs live streaming scheduling on the target edge server based on the address information, and obtains a corresponding scheduling result, thereby meeting the live streaming watching demand of the live streaming watching user.

[0057] According to the to-be-consumed bandwidth corresponding to the to-be-scheduled live stream and the initial bandwidth or the residual bandwidth corresponding to each push stream server cluster, the embodiment of the application determines a target push stream server cluster that meets the condition, so as to push the to-be-scheduled live stream to each live viewing user through the target push stream server cluster. That is, after multiple live viewing users respectively submit scheduling requests for the to-be-scheduled live stream, the target push stream server cluster only needs to perform once source return of the to-be-scheduled live stream, and subsequent live stream scheduling can be performed to each live viewing user. In this way, the number of times of source return of the to-be-scheduled live stream by the push stream server cluster is reduced, the bandwidth of the push stream server cluster is reasonably utilized, and the distribution efficiency of the live stream is improved.

[0058] The above is a schematic scheme of a live stream scheduling system according to the embodiment. It should be noted that the technical scheme of the live stream scheduling system and the technical scheme of the live stream scheduling method described below belong to the same concept. The details of the technical scheme of the live stream scheduling system that are not described in detail can be referred to the description of the technical scheme of the live stream scheduling method.

[0059] Referring to Figure 2 , Figure 2 A flowchart of a live stream scheduling method according to an embodiment of the application is shown, including the following steps:

[0060] Step 202, receiving a live stream scheduling request of a client, wherein the live stream scheduling request contains a live stream identifier of a to-be-scheduled live stream.

[0061] Specifically, the live stream scheduling method provided by the embodiment of the application is applied to a scheduling center.

[0062] The live stream is data generated in the process of anchor live streaming. The to-be-scheduled live stream is a live stream generated by an anchor that a live viewing user wants to watch. The client is a terminal used by a live viewing user to watch live streaming. The live stream identifier is used to uniquely identify a live stream, which can be a live room name or a live room ID of an anchor live room, and is used to represent the correspondence between the live room and the live stream.

[0063] In actual application, when a live viewing user needs to watch the live streaming of an anchor, the live viewing user can send a live stream scheduling request to the scheduling center through the client (player of the client), and the request can carry the live stream identifier of the to-be-scheduled live stream. After receiving the scheduling request, the scheduling center can determine a push stream server cluster for the live viewing user to push the live stream, and return the address information of a target edge server in the push stream server cluster to the live viewing user, so that the live viewing user performs live stream scheduling to the target edge server through the address information to obtain a corresponding scheduling result, thereby realizing live viewing.

[0064] The push stream server cluster refers to a set of at least two push stream servers (edge nodes or edge servers), and in actual application, the push stream server cluster can be a content distribution network (CDN).

[0065] In a specific implementation, before receiving a live stream scheduling request of a client, initial bandwidths corresponding to the at least two push stream server clusters can be determined.

[0066] According to the initial bandwidths and the number of live rooms to be pushed, at least one target live room to be pushed corresponding to a first push stream server cluster is determined, and a corresponding relationship between the first push stream server cluster and a live room identifier of the at least one target live room to be pushed is established, where the first push stream server cluster is one of the at least two push stream server clusters.

[0067] Specifically, a live room to be pushed refers to a live room that is not performing live streaming or is performing live streaming. After receiving a live stream scheduling request, the scheduling center can determine a push stream server cluster for a live viewing user to push a live stream for the live viewing user. Different push stream server clusters, that is, different CDNs, can provide different downstream bandwidths. Therefore, to ensure the efficiency of live stream scheduling and reduce backflow, the push stream server cluster for processing a live stream pushing task of a different live room can be determined before receiving a live stream scheduling request of a client.

[0068] Specifically, initial bandwidths corresponding to the push stream server clusters can be determined first, and then according to the initial bandwidths and the number of live rooms to be pushed, at least one target live room to be pushed corresponding to each push stream server cluster is determined. The corresponding relationship between the push stream server cluster and the target live room to be pushed indicates that the push stream server cluster is used to process a live stream pushing task of the target live room to be pushed.

[0069] Therefore, after determining at least one target live room to be pushed corresponding to each push stream server cluster, a corresponding relationship between each push stream server cluster and a live room identifier of at least one target live room to be pushed corresponding to the push stream server cluster can be established.

[0070] According to the initial bandwidths and the number of live rooms to be pushed, at least one target live room to be pushed corresponding to a first push stream server cluster is determined, and a corresponding relationship between the first push stream server cluster and a live room identifier of the at least one target live room to be pushed is established, where the first push stream server cluster is one of the at least two push stream server clusters.

[0071] The bandwidth ratios between the initial bandwidths corresponding to the at least two push stream server clusters are determined.

[0072] According to the bandwidth ratios and the number of live rooms to be pushed, the live rooms to be pushed are divided into groups to generate at least two live room groups, where the number of the live room groups is equal to the number of the at least two push stream server clusters.

[0073] According to the bandwidth proportion and the number of the to-be-pushed live rooms contained in each of the at least two live room sets, a target live room set corresponding to the first push server cluster is determined, and the to-be-pushed live rooms contained in the target live room set are determined as at least one target to-be-pushed live room corresponding to the first push server cluster.

[0074] Specifically, according to the initial bandwidth and the number of the to-be-pushed live rooms, at least one target to-be-pushed live room corresponding to each push server cluster is determined. Specifically, the bandwidth proportion between the initial bandwidths corresponding to each push server cluster can be determined first, and then the to-be-pushed live rooms are divided into at least two live room sets according to the bandwidth proportion and the total number of the to-be-pushed live rooms, so as to generate the live room sets. The number of the generated live room sets is equal to the number of the push server clusters. Then, according to the bandwidth proportion and the number of the to-be-pushed live rooms contained in each of the live room sets, a target live room set corresponding to each push server cluster is determined, and the to-be-pushed live rooms contained in the target live room set are determined as target to-be-pushed live rooms corresponding to the push server cluster.

[0075] For example, there are three push server clusters, which are A CDN, B CDN and C CDN. The downlink bandwidth (initial bandwidth) of A CDN is 200G, the downlink bandwidth (initial bandwidth) of B CDN is 400G, and the downlink bandwidth (initial bandwidth) of C CDN is 400G. There are 100 to-be-pushed live rooms, and the live room identifiers thereof are 1, 2, …, 100, respectively. In this case, the bandwidth proportion between the initial bandwidths corresponding to the three push server clusters is 1:2:2. Then, according to the bandwidth proportion and the total number of the to-be-pushed live rooms, the to-be-pushed live rooms are divided into sets, so as to generate three live room sets, which are live room set Z1, live room set Z2 and live room set Z3. The live room set Z1 contains 20 live room identifiers, the live room set Z2 contains 40 live room identifiers, and the live room set Z3 contains 40 live room identifiers. If the 100 to-be-pushed live rooms (live room identifiers) are sequentially divided, the live room set Z1 contains live room identifiers 1-20, the live room set Z2 contains live room identifiers 21-60, and the live room set Z3 contains live room identifiers 61-100.

[0076] In this case, it is determined that the target live streaming room corresponding to the A CDN is the live streaming room 1-20, the target live streaming room corresponding to the B CDN is the live streaming room 21-60, and the target live streaming room corresponding to the C CDN is the live streaming room 61-100, that is, the A CDN is used to push the live streaming of the live streaming room 1-20 to the live streaming viewing user, the B CDN is used to push the live streaming of the live streaming room 21-60 to the live streaming viewing user, and the C CDN is used to push the live streaming of the live streaming room 61-100 to the live streaming viewing user.

[0077] In step 204, the first push streaming server cluster corresponding to the live streaming identifier is determined, and the target push streaming server cluster is determined according to the to-be-consumed bandwidth of the to-be-scheduled live streaming, the residual bandwidth of the first push streaming server cluster, and / or the target type bandwidth of the at least one second push streaming server cluster.

[0078] Specifically, since the correspondence between the push streaming server cluster and the target to-be-pushed live streaming room is determined in advance, that is, the push streaming server cluster used to process the push streaming task of the to-be-scheduled live streaming is determined, after receiving the live streaming scheduling request, the live streaming identifier included in the live streaming request is determined first, and the first push streaming server cluster corresponding to the live streaming identifier is determined, so as to push the live streaming corresponding to the live streaming identifier to the client of the live streaming viewing user through the first push streaming server cluster.

[0079] However, in actual application, there may be a case that the residual downstream bandwidth of the first push streaming server cluster does not meet the bandwidth required for push streaming, and therefore, after the first push streaming server cluster is determined, the target push streaming server cluster used to process the push streaming task of the to-be-scheduled live streaming is determined according to the to-be-consumed bandwidth of the to-be-scheduled live streaming, the residual bandwidth of the first push streaming server cluster, and / or the target type bandwidth of the at least one second push streaming server cluster. The target push streaming server cluster can be the first push streaming server cluster or the second push streaming server cluster.

[0080] The purpose of determining the target push streaming server cluster is to determine whether the residual bandwidth of the first push streaming server cluster meets the condition, that is, whether the push streaming server cluster used to push the live streaming corresponding to the live streaming identifier to the live streaming viewing user needs to be replaced, so as to ensure the efficiency of live streaming push.

[0081] In specific implementation, the first push streaming server cluster corresponding to the live streaming identifier is determined by:

[0082] The live room identifier corresponding to the live streaming identifier is determined.

[0083] The first push streaming server cluster corresponding to the live streaming identifier is determined according to the correspondence between the live room identifier and the push streaming server cluster.

[0084] Specifically, since the correspondence between the push server cluster and the live room to be pushed is determined in advance, when the first push server cluster corresponding to the live stream identifier is determined, the live room identifier corresponding to the live stream identifier can be determined first, and then the first push server cluster corresponding to the live stream identifier is determined according to the correspondence between the live room identifier of the live room to be pushed and the push server cluster, and the correspondence between the live stream identifier and the live room identifier.

[0085] Then, whether the to-be-consumed bandwidth exceeds the carrying capacity of the first push server cluster can be determined according to the remaining bandwidth of the first push server cluster and the to-be-consumed bandwidth corresponding to the live stream to be scheduled, so as to determine whether to use the first push server cluster to perform the distribution task of the live stream to be scheduled, or to assign the distribution task of the live stream to be scheduled to other second push server cluster for execution.

[0086] The to-be-consumed bandwidth corresponding to the live stream to be scheduled can be determined by the number of live viewing users of the live room, specifically, the target live stream identifier corresponding to the live stream to be scheduled is determined, and the to-be-consumed bandwidth corresponding to the live stream to be scheduled is determined according to the number of live stream scheduling requests containing the target live stream identifier.

[0087] Specifically, each live stream scheduling request containing the same live stream identifier has the same to-be-consumed bandwidth, so the to-be-consumed bandwidth corresponding to the live stream to be scheduled can be determined by determining the live stream scheduling request containing the live stream identifier of the live stream to be scheduled, and determining the total number of the live stream scheduling request, and the total number can represent the total number of live viewing users of the live room to which the live stream identifier belongs.

[0088] In a specific implementation, the target push server cluster is determined according to the to-be-consumed bandwidth corresponding to the live stream to be scheduled, the remaining bandwidth of the first push server cluster, and / or the target type bandwidth of the at least one second push server cluster, including:

[0089] determining whether the to-be-consumed bandwidth corresponding to the live stream to be scheduled is greater than the remaining bandwidth of the first push server cluster;

[0090] if not, the first push server cluster is determined as the target push server cluster;

[0091] if yes, the target push server cluster is determined according to the target type bandwidth of the at least one second push server cluster.

[0092] Specifically, since the correspondence between the push server cluster and the live room to be pushed is determined in advance, after determining the first push server cluster corresponding to the live stream identifier, whether the to-be-consumed bandwidth exceeds the carrying capacity of the first push server cluster can be determined according to the residual bandwidth of the first push server cluster and the to-be-consumed bandwidth corresponding to the live stream to be scheduled. If not, the first push server cluster can be determined as the target push server cluster to perform the distribution task of the live stream to be scheduled through the first push server cluster. If yes, the target push server cluster needs to be determined according to the target type bandwidth (initial downlink bandwidth or residual downlink bandwidth) of at least one second push server cluster, so as to allocate the distribution task of the live stream to be scheduled to other second push server cluster for execution.

[0093] The embodiments of the present application can determine the allocated quota according to the initial bandwidth provided by each CDN and the real-time bandwidth of each CDN. When the real-time bandwidth of each CDN does not exceed the threshold, the distribution is performed according to the proportion.

[0094] For example, the downlink bandwidth of A CDN is 200G, the downlink bandwidth of B CDN is 400G, and the downlink bandwidth of C CDN is 400G. The live stream distribution task of live room identifier 1-20 is allocated to A CDN, the live stream distribution task of live room identifier 21-60 is allocated to B CDN, and the live stream distribution task of live room identifier 61-100 is allocated to C CDN, so as to ensure that after the live room identifier is hashed into a number between 1 and 100, the corresponding live stream distribution task can be evenly allocated to different CDNs.

[0095] In addition, in the case that the to-be-consumed bandwidth corresponding to the live stream to be scheduled is greater than the residual bandwidth of the first push server cluster, the target push server cluster needs to be determined according to the target type bandwidth of at least one second push server cluster, wherein the target type bandwidth includes the initial bandwidth.

[0096] Correspondingly, determining the target push server cluster according to the target type bandwidth of the at least one second push server cluster comprises:

[0097] Determining the initial bandwidth corresponding to each of the at least two second push server clusters;

[0098] Determining at least one target live room to be pushed corresponding to any one second push server cluster according to the initial bandwidth and the number of live rooms to be pushed;

[0099] Determining the target push server cluster corresponding to the live stream identifier according to the correspondence between the live stream identifier and the target live room to be pushed, and the correspondence between the target live room to be pushed and the second push server.

[0100] Specifically, in a case where it is determined that the to-be-consumed bandwidth corresponding to the to-be-scheduled live stream is greater than the residual bandwidth of the first push server cluster, it is indicated that the push server cluster used for pushing the live stream corresponding to the live stream identifier to the live viewing user needs to be replaced.

[0101] In this case, the at least one target to-be-pushed live room corresponding to each second push server cluster can be re-determined according to the initial bandwidths respectively corresponding to the second push server clusters. Specifically, the to-be-pushed live rooms can be set-divided according to the bandwidth ratios between the initial bandwidths respectively corresponding to the second push server clusters and the total number of to-be-pushed live rooms, and then the target live room set corresponding to each second push server cluster can be determined according to the bandwidth ratios and the number of to-be-pushed live rooms contained in each live room set, and the to-be-pushed live rooms contained in the target live room set are determined as the target to-be-pushed live rooms corresponding to the second push server cluster.

[0102] For example, the target to-be-pushed live rooms corresponding to the A CDN are live rooms 1-20, but after receiving a live stream scheduling request of any one or at least two live rooms in the live rooms 1-20, it is determined that the to-be-consumed bandwidth corresponding to the to-be-scheduled live stream is greater than the residual bandwidth of the A CDN, and thus the push server cluster used for pushing the live streams of the live rooms 1-20 to the live viewing user needs to be replaced. In this case, the correspondence between the B CDN, the C CDN and the live room identifiers of the live rooms needs to be re-established.

[0103] The downlink bandwidth (initial bandwidth) of the B CDN is 400G, the downlink bandwidth (initial bandwidth) of the C CDN is 400G, and there are 100 to-be-pushed live rooms with live room identifiers 1, 2, …, 100. In this case, the bandwidth ratio between the initial bandwidths respectively corresponding to the two push server clusters is 1:1, and then the to-be-pushed live rooms can be set-divided according to the bandwidth ratio and the total number of to-be-pushed live rooms, so as to generate two live room sets, i.e., a live room set Z4 and a live room set Z5. The live room set Z4 contains 50 live room identifiers, and the live room set Z5 contains 50 live room identifiers. If the 100 to-be-pushed live rooms (live room identifiers) are sequentially divided, the live room set Z4 contains live room identifiers 1-50, and the live room set Z5 contains live room identifiers 51-100.

[0104] In this case, it can be determined that the target to-be-pushed live rooms corresponding to the B CDN are 1-50, and the target to-be-pushed live rooms corresponding to the C CDN are 51-100. That is, the B CDN is used to push the live streams of the live rooms 1-50 to the live viewing user, and the C CDN is used to push the live streams of the live rooms 51-100 to the live viewing user.

[0105] Alternatively, the live broadcast room set Z4 contains live broadcast room identifiers 1-10, 21-60, and the live broadcast room set Z5 contains live broadcast room identifiers 11-20, 61-100. The actual situation can be determined, and this is not limited.

[0106] After the at least one target live broadcast room corresponding to each second push server cluster is re-determined, it means that after a new live broadcast watching user submits a live stream scheduling request containing the live stream identifier, the new target push server cluster needs to be determined according to the correspondence between the re-determined live broadcast room identifier and the push server cluster, so that the new target push server cluster pushes the live stream based on the live stream scheduling request. However, for the live stream scheduling requests received before the at least one target live broadcast room corresponding to each second push server cluster is re-determined, the historical target push server cluster still pushes the live stream.

[0107] When determining the correspondence between the first push server cluster, the second push server cluster and each live broadcast room identifier, there is actually a hidden precondition, that is, the number of viewers of each live broadcast room is about the same, or is uniformly distributed. Therefore, according to the live broadcast room identifier, the live stream pushing task is distributed to each push server cluster, and the downlink bandwidth consumed by each push server cluster is also uniform. However, in actual application, the number of live broadcast watching users of different live broadcast rooms is different. If the task allocation for each push server cluster is still based on the uniform distribution logic, it may cause the downlink bandwidth of one CDN to be quickly consumed. For example, the live stream distribution task corresponding to the live broadcast room identifier 15 is allocated to the A CDN, but the downlink bandwidth consumed by this task is 250G, which is much higher than the configuration bandwidth (initial bandwidth) of the A CDN.

[0108] To prevent the above situation from occurring, when the real-time number of viewers of a live broadcast room exceeds a certain threshold, the live stream distribution task of the live broadcast room is started to be allocated to other CDNs, so as to ensure that the bandwidth of each push server cluster can be reasonably utilized and improve the utilization rate.

[0109] Alternatively, the target type bandwidth includes a remaining bandwidth;

[0110] In the case of at least two second inference server clusters, the target push server cluster is determined according to the target type bandwidth of the at least one second push server cluster, comprising:

[0111] Determine the remaining bandwidth corresponding to the at least two second push server clusters, respectively;

[0112] According to the remaining bandwidth and the number of the to-be-pushed live streaming rooms, at least one target to-be-pushed live streaming room corresponding to any one second push streaming server cluster is determined.

[0113] According to the correspondence between the live streaming identifier and the target to-be-pushed live streaming room, and the correspondence between the target push streaming room and the second push streaming server, the target push streaming server cluster corresponding to the live streaming identifier is determined.

[0114] In the case where there is one second push streaming server cluster, the target push streaming server cluster is determined according to the target type bandwidth of the at least one second push streaming server cluster, comprising:

[0115] It is judged whether the to-be-consumed bandwidth corresponding to the to-be-scheduled live streaming is greater than the remaining bandwidth corresponding to the second push streaming server cluster.

[0116] If not, the second push streaming server cluster is determined as the target push streaming server cluster.

[0117] Specifically, as described above, in the case where the to-be-consumed bandwidth corresponding to the to-be-scheduled live streaming is greater than the remaining bandwidth of the first push streaming server cluster, it indicates that the push streaming server cluster for pushing the live streaming corresponding to the live streaming identifier to the live streaming watching user needs to be replaced. In this case, if there is only one second push streaming server cluster, it can be first judged whether the to-be-consumed bandwidth corresponding to the to-be-scheduled live streaming is greater than the remaining bandwidth corresponding to the second push streaming server cluster. If not, the second push streaming server cluster is determined as the target push streaming server cluster, so as to push the live streaming through the second push streaming server cluster.

[0118] Or, in the case where there are two or more second push streaming server clusters, in addition to determining the target push streaming server cluster according to the initial bandwidth of each second push streaming server cluster, the target push streaming server cluster can also be determined according to the remaining bandwidth (remaining downstream bandwidth) of each second push streaming server cluster. Specifically, the to-be-pushed live streaming rooms can be divided into sets according to the bandwidth ratio between the remaining bandwidths corresponding to each second push streaming server cluster and the total number of the to-be-pushed live streaming rooms. Then, according to the bandwidth ratio and the number of the to-be-pushed live streaming rooms contained in each live streaming room set, the target live streaming room set corresponding to each second push streaming server cluster is determined, and the to-be-pushed live streaming rooms contained in the target live streaming room set are determined as the target to-be-pushed live streaming rooms corresponding to the second push streaming server cluster.

[0119] For example, the target to-be-pushed live streaming rooms corresponding to the pre-determined A CDN are live streaming rooms 1-20, but in the case where the push streaming server cluster for pushing the live streams of the live streaming rooms 1-20 to the live streaming watching users needs to be replaced, it is necessary to re-establish the correspondence between the B CDN, the C CDN and the live streaming identifiers of the live streaming rooms.

[0120] In this case, the bandwidth ratio between the remaining bandwidths of the two push stream server clusters is 1:9. Then, the to-be-pushed live broadcast rooms are divided into two sets according to the bandwidth ratio and the total number of the to-be-pushed live broadcast rooms, that is, two live broadcast room sets, live broadcast room set Z6 and live broadcast room set Z7, are generated. The live broadcast room set Z6 contains 10 live broadcast room identifiers, and the live broadcast room set Z7 contains 90 live broadcast room identifiers. If the 100 to-be-pushed live broadcast rooms (live broadcast room identifiers) are sequentially divided, the live broadcast room set Z6 contains live broadcast room identifiers 1-10, and the live broadcast room set Z7 contains live broadcast room identifiers 11-100.

[0121] In this case, it can be determined that the target to-be-pushed live broadcast rooms corresponding to the B CDN are 1-10, and the target to-be-pushed live broadcast rooms corresponding to the C CDN are 11-100. That is, the B CDN is used to push the live streams of the live broadcast rooms 1-10 to the live broadcast watching users, and the C CDN is used to push the live streams of the live broadcast rooms 11-100 to the live broadcast watching users.

[0122] According to the initial bandwidth of each second push stream server cluster, a target push stream server cluster is determined, provided that the real-time bandwidth of each second push stream server cluster does not exceed the initial bandwidth. When the number of live broadcast watching users of a live broadcast room grows too fast and the bandwidth of each push stream server cluster cannot be reasonably utilized according to the foregoing strategy, the live stream distribution task needs to be re-allocated.

[0123] For example, the configuration bandwidth of the A CDN is 200G, and 180G is used, so that there is basically no remaining capacity. The configuration bandwidth of the B CDN is 400G, and 200G is used. The configuration bandwidth of the C CDN is 400G, and 300G is used. In this case, the task allocation cannot be performed according to A:B:C=1:2:2 or B:C=1:1, but should be re-allocated according to the remaining capacity of each CDN, that is, the task allocation is performed according to the ratio of B:C=(400-200):(400-300)=2:1.

[0124] In step 206, address information of a target edge server in the target push stream server cluster is generated, and the address information is returned to the client. The address information is used for the client to perform live stream scheduling on the target edge server to obtain a corresponding scheduling result.

[0125] Specifically, the target edge server, which can be a server closest to the client in the target push stream server cluster, pushes the live stream for the client through the server closest to the user, which is conducive to reducing the resource consumption of the push stream process, reducing the time consumed by the push stream, and improving the push stream efficiency.

[0126] After the target push stream server cluster is determined, the target edge server for pushing the live stream for the client is determined, and address information of the target edge server is generated, and then the address information is returned to the client. The client can schedule the live stream to the target edge server through the address information to obtain a corresponding scheduling result.

[0127] Before the client schedules the live stream to the target edge server, the target push stream server cluster can pull the live stream corresponding to the live stream identifier from the stream media server and synchronize it to each edge server in the cluster.

[0128] The embodiments of the present application dynamically adjust the use proportion of each CDN by means of bandwidth configuration amount, real-time amount, gradient scheduling of bandwidth, etc., which is conducive to reducing the source return while ensuring that the bandwidth of the CDN is scheduled within a normal range.

[0129] One embodiment of the present application implements a live stream scheduling method and device, wherein the live stream scheduling method comprises receiving a live stream scheduling request of a client, wherein the live stream scheduling request contains a live stream identifier of a live stream to be scheduled, determining a first push stream server cluster corresponding to the live stream identifier, and determining a target push stream server cluster according to a to-be-consumed bandwidth of the live stream to be scheduled, a remaining bandwidth of the first push stream server cluster, and / or a target type bandwidth of at least one second push stream server cluster, generating address information of a target edge server in the target push stream server cluster, and returning the address information to the client, wherein the address information is used for the client to schedule the live stream to the target edge server to obtain a corresponding scheduling result.

[0130] According to the to-be-consumed bandwidth of the live stream to be scheduled and the initial bandwidth or the remaining bandwidth corresponding to each push stream server cluster, the embodiments of the present application determine a target push stream server cluster that meets the condition, so as to push the live stream to be scheduled to each live stream watching user through the target push stream server cluster. That is, after multiple live stream watching users respectively submit scheduling requests of the live stream to be scheduled, the target push stream server cluster only needs to do once source return of the live stream to be scheduled, and then live stream scheduling can be implemented to each live stream watching user. In this way, it is conducive to reducing the source return times of the push stream server cluster to the live stream to be scheduled, so as to realize reasonable utilization of the bandwidth of the push stream server cluster, thereby being conducive to improving the distribution efficiency of the live stream.

[0131] With reference to Figure 3 The live stream scheduling method provided by the embodiments of the present application is further described by taking the application of the live stream scheduling method in the live field as an example. Among them, Figure 3 An interaction diagram of a live stream scheduling method provided by an embodiment of the present application is shown, which specifically includes the following steps:

[0132] In step 302, the anchor pushes a live stream to a stream media server through a first client.

[0133] In step 304, a live stream scheduling request is sent by a live stream watching user to a scheduling center through a second client, wherein the live stream scheduling request contains a live stream identifier of a live stream to be scheduled.

[0134] In step 306, the scheduling center determines a first push stream server cluster corresponding to the live stream identifier.

[0135] In step 308, the scheduling center obtains a residual bandwidth of the first push stream server cluster and / or a target type bandwidth of at least one second push stream server cluster.

[0136] In step 310, the scheduling center determines a target push stream server cluster according to a to-be-consumed bandwidth corresponding to the live stream to be scheduled, the residual bandwidth of the first push stream server cluster and / or the target type bandwidth of the at least one second push stream server cluster.

[0137] In step 312, the target push stream server cluster obtains the live stream to be scheduled from the stream media server.

[0138] In step 314, the scheduling center generates address information of a target edge server in the target push stream server cluster, and returns the address information to the second client.

[0139] In step 316, the second client performs live stream scheduling to the target edge server based on the address information, and obtains a corresponding scheduling result.

[0140] In step 318, the second client plays the live stream in the scheduling result through a playing interface.

[0141] According to the to-be-consumed bandwidth corresponding to the to-be-scheduled live stream and the initial bandwidth or the residual bandwidth corresponding to each push stream server cluster, the embodiment of the application determines a target push stream server cluster that meets the condition, so as to push the to-be-scheduled live stream to each live viewing user through the target push stream server cluster, that is, after multiple live viewing users respectively submit scheduling requests for the to-be-scheduled live stream, the target push stream server cluster only needs to perform once source returning of the to-be-scheduled live stream, and subsequent live stream scheduling to each live viewing user can be implemented. In this way, it is beneficial to reduce the source returning times of the push stream server cluster to the to-be-scheduled live stream, so as to realize reasonable utilization of the bandwidth of the push stream server cluster, thereby being beneficial to improving the distribution efficiency of the live stream.

[0142] Corresponding to the method embodiment, the application further provides a live stream scheduling device embodiment, Figure 4 The structure of a live stream scheduling device provided by an embodiment of the application is shown. As shown in Figure 4 The device comprises:

[0143] The receiving module 402 is configured to receive a live stream scheduling request of a client, wherein the live stream scheduling request comprises a live stream identifier of a to-be-scheduled live stream.

[0144] The determining module 404 is configured to determine a first push stream server cluster corresponding to the live stream identifier, and determine a target push stream server cluster according to a to-be-consumed bandwidth corresponding to the to-be-scheduled live stream, a residual bandwidth of the first push stream server cluster, and / or a target type bandwidth of at least one second push stream server cluster.

[0145] The generating module 406 is configured to generate address information of a target edge server in the target push stream server cluster, and return the address information to the client, wherein the address information is used for the client to perform live stream scheduling to the target edge server to obtain a corresponding scheduling result.

[0146] Optionally, the determining module 404 is configured to:

[0147] Determine a live room identifier corresponding to the live stream identifier.

[0148] According to a corresponding relationship between the live room identifier and the push stream server cluster, determine the first push stream server cluster corresponding to the live stream identifier.

[0149] Optionally, the live stream scheduling device further comprises an establishing module configured to:

[0150] Determine initial bandwidths respectively corresponding to at least two push stream server clusters.

[0151] According to the initial bandwidth and the number of the to-be-pushed live broadcast rooms, at least one target to-be-pushed live broadcast room corresponding to a first push server cluster is determined, and a corresponding relationship between the first push server cluster and a live broadcast room identifier of the at least one target to-be-pushed live broadcast room is established, wherein the first push server cluster is one of the at least two push server clusters.

[0152] Optionally, the establishing module is further configured to:

[0153] determine bandwidth proportions among the initial bandwidths respectively corresponding to the at least two push server clusters;

[0154] perform set division on the to-be-pushed live broadcast rooms according to the bandwidth proportions and the number of the to-be-pushed live broadcast rooms, to generate at least two live broadcast room sets, wherein the number of the live broadcast room sets is equal to the number of the at least two push server clusters;

[0155] determine a target live broadcast room set corresponding to a first push server cluster according to the bandwidth proportions and the number of to-be-pushed live broadcast rooms respectively contained in the at least two live broadcast room sets, and determine to-be-pushed live broadcast rooms contained in the target live broadcast room set as at least one target to-be-pushed live broadcast room corresponding to the first push server cluster.

[0156] Optionally, the determining module 404 is configured to:

[0157] determine whether to-be-consumed bandwidth corresponding to the to-be-scheduled live stream is greater than the residual bandwidth of the first push server cluster;

[0158] if not, the first push server cluster is determined as the target push server cluster;

[0159] if yes, a target push server cluster is determined according to the target type bandwidth of the at least one second push server cluster.

[0160] Optionally, the target type bandwidth includes an initial bandwidth.

[0161] Correspondingly, the determining module 404 is further configured to:

[0162] determine initial bandwidths respectively corresponding to at least two second push server clusters;

[0163] determine at least one target to-be-pushed live broadcast room corresponding to any one second push server cluster according to the initial bandwidths and the number of the to-be-pushed live broadcast rooms;

[0164] According to the corresponding relationship between the live stream identifier and the target to-be-pushed live broadcast room and the corresponding relationship between the target pushed live broadcast room and the second pushed server cluster, the target pushed server cluster corresponding to the live stream identifier is determined.

[0165] Optionally, the target type bandwidth includes a remaining bandwidth.

[0166] Correspondingly, the determining module 404 is further configured to:

[0167] Determine the remaining bandwidth corresponding to each of the at least two second pushed server clusters.

[0168] According to the remaining bandwidth and the number of to-be-pushed live broadcast rooms, at least one target to-be-pushed live broadcast room corresponding to any one of the second pushed server clusters is determined.

[0169] According to the corresponding relationship between the live stream identifier and the target to-be-pushed live broadcast room and the corresponding relationship between the target pushed live broadcast room and the second pushed server cluster, the target pushed server cluster corresponding to the live stream identifier is determined.

[0170] Optionally, the target type bandwidth includes a remaining bandwidth.

[0171] Correspondingly, the determining module 404 is further configured to:

[0172] Determine whether the to-be-consumed bandwidth corresponding to the to-be-scheduled live stream is greater than the remaining bandwidth corresponding to the second pushed server cluster.

[0173] If not, the second pushed server cluster is determined as the target pushed server cluster.

[0174] Optionally, the live stream scheduling apparatus further includes a processing module configured to:

[0175] Determine a target live stream identifier corresponding to a to-be-scheduled live stream.

[0176] According to the number of live stream scheduling requests containing the target live stream identifier, a to-be-consumed bandwidth corresponding to the to-be-scheduled live stream is determined.

[0177] An embodiment of the present application receives a live streaming scheduling request of a client through a receiving module, wherein the live streaming scheduling request contains a live streaming identifier of a live streaming to be scheduled, determines a first push streaming server cluster corresponding to the live streaming identifier through a determining module, and determines a target push streaming server cluster according to a to-be-consumed bandwidth corresponding to the live streaming to be scheduled, a residual bandwidth of the first push streaming server cluster, and / or a target type bandwidth of at least one second push streaming server cluster, generates address information of a target edge server in the target push streaming server cluster through a generating module, and returns the address information to the client, wherein the address information is used for the client to perform live streaming scheduling to the target edge server to obtain a corresponding scheduling result.

[0178] According to the to-be-consumed bandwidth corresponding to the live streaming to be scheduled and the initial bandwidth or the residual bandwidth corresponding to each push streaming server cluster, an embodiment of the present application determines a target push streaming server cluster meeting a condition, so as to push the live streaming to be scheduled to each live viewing user through the target push streaming server cluster, that is, after multiple live viewing users respectively submit scheduling requests of the live streaming to be scheduled, the target push streaming server cluster only needs to perform once source returning of the live streaming to be scheduled, and subsequent live streaming scheduling to each live viewing user can be implemented, in this way, it is beneficial to reduce the source returning times of the push streaming server cluster to the live streaming to be scheduled, so as to realize reasonable utilization of the bandwidth of the push streaming server cluster, thereby being beneficial to improving the distribution efficiency of the live streaming.

[0179] The above is a schematic scheme of a live streaming scheduling device of an embodiment of the present application. It should be noted that the technical scheme of the live streaming scheduling device belongs to the same concept as the technical scheme of the live streaming scheduling method described above, and the details of the technical scheme of the live streaming scheduling device which are not described in detail can be referred to the description of the technical scheme of the live streaming scheduling method.

[0180] Figure 5 A structural block diagram of a computing device 500 according to an embodiment of the present application is shown. The components of the computing device 500 include but are not limited to a memory 510 and a processor 520. The processor 520 is connected with the memory 510 through a bus 530, and a database 550 is used to save data.

[0181] The computing device 500 also includes an access device 540 that enables the computing device 500 to communicate via one or more networks 560. Examples of such networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or combinations of such networks, such as the Internet. The access device 540 can include one or more of any type of network interface (for example, a network interface card (NIC)), such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a global microwave interconnection access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, a near field communication (NFC) interface, and so on.

[0182] In an embodiment of the present application, the above-mentioned components of the computing device 500, as well as other components not shown in FIG. 5, can be connected to each other by a bus, for example. Figure 5 It should be understood that the computing device structure diagram shown is for the purpose of example only, and is not a limitation on the scope of the present application. Other components can be added or replaced as needed by those skilled in the art. Figure 5 It should be understood that the computing device structure diagram shown is for the purpose of example only, and is not a limitation on the scope of the present application. Other components can be added or replaced as needed by those skilled in the art.

[0183] The computing device 500 can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (for example, a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, and so on), a mobile phone (for example, a smartphone), a wearable computing device (for example, a smart watch, smart glasses, and so on), or other types of mobile devices, or a stationary computing device such as a desktop computer or PC. The computing device 500 can also be a mobile or stationary server.

[0184] The processor 520 is configured to execute computer-executable instructions, and the processor 520 implements the steps of the live stream scheduling method when executing the computer-executable instructions.

[0185] The above is a schematic scheme of a computing device according to the present embodiment. It should be noted that the technical scheme of the computing device and the technical scheme of the live stream scheduling method described above belong to the same concept, and the details of the technical scheme of the computing device that are not described in detail can be referred to the description of the technical scheme of the live stream scheduling method.

[0186] The present embodiment also provides a computer-readable storage medium storing computer-executable instructions, and the instructions are executed by the processor to implement the steps of the live stream scheduling method.

[0187] The above is a schematic solution of the computer readable storage medium of the embodiment. It should be noted that the technical solution of the storage medium and the technical solution of the live stream scheduling method described above belong to the same concept, and the details of the technical solution of the storage medium that are not described in detail can be seen from the description of the technical solution of the live stream scheduling method.

[0188] The specific embodiments of the application have been described. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order and still accomplish desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown or sequential order to achieve desirable results. In certain implementations, multitasking and parallel processing can be advantageous.

[0189] The computer readable medium can include any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, a Read-Only Memory (ROM), a Random Access Memory (RAM), an electrical carrier signal, a telecommunications signal, and a software distribution medium, etc. It should be noted that the contents included in the computer readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practices in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practices, the computer readable medium does not include electrical carrier signals and telecommunications signals.

[0190] It should be noted that for the foregoing method embodiments, in order to facilitate description, they are all expressed as a combination of a series of actions, but those skilled in the art should know that the embodiments of the present application are not limited to the order of the actions described, because according to the embodiments of the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions and modules involved are not necessarily necessary for the embodiments of the present application.

[0191] In the above embodiments, the description of each embodiment has its own emphasis, and the parts not described in detail in a certain embodiment can be seen from the related description of other embodiments.

[0192] The preferred embodiments of the application disclosed above are only used to facilitate the description of the application. Alternative embodiments do not describe all the details and limit the application to the specific embodiments described. Obviously, according to the content of the embodiments of the application, many modifications and changes can be made. The application selects and describes these embodiments in order to better explain the principles and practical applications of the embodiments of the application, so that those skilled in the art can well understand and utilize the application. The application is limited by the claims and their full scope and equivalents.

Claims

1. A live streaming scheduling method, characterized in that, The method comprises: receiving a live stream scheduling request of a client, wherein the live stream scheduling request contains a live stream identifier of a live stream to be scheduled; determining a first push stream server cluster corresponding to the live stream identifier, and determining a target push stream server cluster according to a to-be-consumed bandwidth corresponding to the live stream to be scheduled, a residual bandwidth of the first push stream server cluster, and / or a target type bandwidth of at least one second push stream server cluster; generating address information of a target edge server in the target push stream server cluster, and returning the address information to the client, wherein the address information is used for the client to perform live stream scheduling on the target edge server to obtain a corresponding scheduling result; wherein the determination of the target push stream server cluster according to the to-be-consumed bandwidth corresponding to the live stream to be scheduled, the residual bandwidth of the first push stream server cluster, and / or the target type bandwidth of the at least one second push stream server cluster comprises: determining whether the to-be-consumed bandwidth corresponding to the live stream to be scheduled is greater than the residual bandwidth of the first push stream server cluster; if not, determining the first push stream server cluster as the target push stream server cluster; if yes, determining the target push stream server cluster according to the target type bandwidth of the at least one second push stream server cluster; wherein the target type bandwidth comprises an initial bandwidth; correspondingly, the determination of the target push stream server cluster according to the target type bandwidth of the at least one second push stream server cluster comprises: determining initial bandwidths corresponding to the at least two second push stream server clusters respectively; determining at least one target to-be-pushed live room corresponding to any one of the second push stream server clusters according to the initial bandwidths and a number of to-be-pushed live rooms; determining the target push stream server cluster corresponding to the live stream identifier according to a corresponding relationship between the live stream identifier and the target to-be-pushed live room, and a corresponding relationship between the target push stream live room and the second push stream server.

2. The live streaming scheduling method of claim 1, wherein, The determination of the first push stream server cluster corresponding to the live stream identifier comprises: determining a live room identifier corresponding to the live stream identifier; determining the first push stream server cluster corresponding to the live stream identifier according to a corresponding relationship between the live room identifier and the push stream server cluster.

3. The live streaming scheduling method of claim 1 or 2, wherein, The method further comprises: determining initial bandwidths corresponding to the at least two push stream server clusters respectively; determining at least one target to-be-pushed live room corresponding to the first push stream server cluster according to the initial bandwidths and a number of to-be-pushed live rooms, and establishing a corresponding relationship between the first push stream server cluster and live room identifiers of the at least one target to-be-pushed live room, wherein the first push stream server cluster is one of the at least two push stream server clusters.

4. The live streaming scheduling method of claim 3, wherein, The determination of the at least one target to-be-pushed live room corresponding to the first push stream server cluster according to the initial bandwidths and the number of to-be-pushed live rooms comprises: determining bandwidth proportions among the initial bandwidths corresponding to the at least two push stream server clusters respectively; According to the bandwidth proportion and the number of the to-be-pushed live streaming rooms, the to-be-pushed live streaming rooms are set and divided to generate at least two live streaming room sets, wherein the number of the live streaming room sets is equal to the number of the at least two push streaming server clusters; According to the bandwidth proportion and the number of the to-be-pushed live streaming rooms included in the at least two live streaming room sets, a target live streaming room set corresponding to a first push streaming server cluster is determined, and the to-be-pushed live streaming rooms included in the target live streaming room set are determined as at least one target to-be-pushed live streaming room corresponding to the first push streaming server cluster.

5. The live streaming scheduling method of claim 1, wherein, The target type bandwidth includes residual bandwidth; Accordingly, the target push streaming server cluster is determined according to the target type bandwidth of the at least one second push streaming server cluster, including: The residual bandwidth corresponding to at least two second push streaming server clusters is determined; According to the residual bandwidth and the number of the to-be-pushed live streaming rooms, at least one target to-be-pushed live streaming room corresponding to any one second push streaming server cluster is determined; According to the correspondence between the live stream identifier and the target to-be-pushed live streaming room, and the correspondence between the target push streaming room and the second push streaming server, the target push streaming server cluster corresponding to the live stream identifier is determined.

6. The live streaming scheduling method of claim 1, wherein, The target type bandwidth includes residual bandwidth; Accordingly, the target push streaming server cluster is determined according to the target type bandwidth of the at least one second push streaming server cluster, including: It is judged whether the to-be-consumed bandwidth corresponding to the to-be-scheduled live stream is greater than the residual bandwidth corresponding to the second push streaming server cluster; If not, the second push streaming server cluster is determined as the target push streaming server cluster.

7. The live streaming scheduling method of claim 1, wherein, Further comprising: The target live stream identifier corresponding to the to-be-scheduled live stream is determined; The to-be-consumed bandwidth corresponding to the to-be-scheduled live stream is determined according to the number of live stream scheduling requests containing the target live stream identifier.

8. A live streaming scheduling apparatus, characterized by comprising: It comprises: The receiving module is configured to receive the live stream scheduling request of the client, wherein the live stream scheduling request contains the live stream identifier of the to-be-scheduled live stream; The determining module is configured to determine the first push streaming server cluster corresponding to the live stream identifier, and determine the target push streaming server cluster according to the to-be-consumed bandwidth corresponding to the to-be-scheduled live stream, the residual bandwidth of the first push streaming server cluster, and / or the target type bandwidth of the at least one second push streaming server cluster; The generating module is configured to generate the address information of the target edge server in the target push streaming server cluster, and return the address information to the client, wherein the address information is used for the client to perform live stream scheduling to the target edge server to obtain the corresponding scheduling result; According to the to-be-consumed bandwidth corresponding to the to-be-scheduled live stream, the residual bandwidth of the first push streaming server cluster, and / or the target type bandwidth of the at least one second push streaming server cluster, the target push streaming server cluster is determined, including: It is judged whether the to-be-consumed bandwidth corresponding to the to-be-scheduled live stream is greater than the residual bandwidth of the first push streaming server cluster; If not, the first push streaming server cluster is determined as the target push streaming server cluster; If yes, a target push stream server cluster is determined according to a target type bandwidth of the at least one second push stream server cluster; The target type bandwidth comprises an initial bandwidth; Correspondingly, the step of determining the target push stream server cluster according to the target type bandwidth of the at least one second push stream server cluster comprises: determining initial bandwidths corresponding to the at least two second push stream server clusters respectively; determining at least one target to-be-pushed live room corresponding to any one of the second push stream server clusters according to the initial bandwidths and a quantity of to-be-pushed live rooms; and determining the target push stream server cluster corresponding to the live stream identifier according to a correspondence between the live stream identifier and the target to-be-pushed live room and a correspondence between the target to-be-pushed live room and the second push stream server.

9. A live streaming scheduling system, characterized in that, Comprise: a first client, a second client, a streaming media server, a dispatching center and at least two push stream server clusters; The streaming media server is configured to receive a live stream pushed by the first client; The dispatching center is configured to receive a live stream dispatching request of the second client, wherein the live stream dispatching request comprises a live stream identifier of a to-be-dispatched live stream, determine a first push stream server cluster corresponding to the live stream identifier, determine a target push stream server cluster according to a to-be-consumed bandwidth corresponding to the to-be-dispatched live stream, a residual bandwidth of the first push stream server cluster and / or a target type bandwidth of the at least one second push stream server cluster, generate address information of a target edge server in the target push stream server cluster, and return the address information to the second client; The target push stream server cluster is configured to obtain the to-be-dispatched live stream from the streaming media server; The second client is configured to perform live stream dispatching to the target edge server based on the address information and obtain a corresponding dispatching result; The target type bandwidth comprises an initial bandwidth; Correspondingly, the step of determining the target push stream server cluster according to the target type bandwidth of the at least one second push stream server cluster comprises: determining initial bandwidths corresponding to the at least two second push stream server clusters respectively; determining at least one target to-be-pushed live room corresponding to any one of the second push stream server clusters according to the initial bandwidths and a quantity of to-be-pushed live rooms; and determining the target push stream server cluster corresponding to the live stream identifier according to a correspondence between the live stream identifier and the target to-be-pushed live room and a correspondence between the target to-be-pushed live room and the second push stream server. ​ ​ ​ ​ 10. A computing device, comprising: Comprising: a memory and a processor; the memory is configured to store computer-executable instructions, and the processor is configured to execute the computer-executable instructions, and when the processor executes the computer-executable instructions, steps of the live streaming scheduling method in any one of claims 1-7 are implemented.

11. A computer readable storage medium, characterized in that, The computer program product has computer instructions stored therein, and when the computer instructions are executed by a processor, steps of the live streaming scheduling method in any one of claims 1-7 are implemented.

12. A computer program product comprising computer instructions, characterized in that, The computer program product has computer instructions stored therein, and when the computer instructions are executed by a processor, steps of the live streaming scheduling method in any one of claims 1-7 are implemented.

Images