A live streaming processing method and live streaming source station cluster

Abstract

The present application provides a live stream processing method and a live source station cluster. The present application will allocate corresponding service slots to each service node in the live source station cluster based on the service capabilities of the service node itself. In this way, after the scheduling node obtains the live stream processing request, it will accurately calculate the corresponding response slot value based on the request content, determine the target service node corresponding to the response slot value, respond to the live stream processing request, and meet the push or pull service requirements. Compared with the processing method of determining the target service node based on polling or consistent hashing algorithm, the present application ensures the load balancing of each service node, and is also convenient for adding and / or deleting service nodes and scheduling nodes in the system.

Description

Technical Field

[0001] The present application relates to the field of live broadcast applications, and specifically to a live broadcast stream processing method and a live broadcast source station cluster. Background Art

[0002] With the rapid development of Internet communication technology, live streaming has been widely used due to its advantages of being intuitive, fast, and not geographically restricted. As the demand for live streaming increases, the scale of live streaming source station clusters is getting larger and larger to meet the needs of live streaming services of different scales.

[0003] Among them, during the operation of the live broadcast service, if the live broadcast source device A that provides the live broadcast stream encounters problems such as performance bottlenecks or network failures, it is usually necessary to interrupt the live broadcast service first, and based on the consistent hashing algorithm, migrate the live broadcast stream processing request of the live broadcast service to the live broadcast source device B, which reduces the live broadcast experience. Summary of the invention

[0004] In order to solve the above technical problems, the embodiments of the present application provide the following technical solutions:

[0005] On the one hand, the present application proposes a live stream processing method, the method comprising:

[0006] Obtaining a live stream processing request; the live stream processing request includes a request object identifier and a live stream identifier;

[0007] According to the request object identifier and the live stream identifier, the total number of preset slots of the live source station cluster is processed to determine a response slot value corresponding to the live stream processing request;

[0008] The service node corresponding to the service slot where the response slot value is located is determined as the target service node; wherein the service slot of each service node in the live source station cluster is obtained according to the total number of preset slots and the service capacity of each service node, and the service capacity of the service node is obtained according to the configuration parameters of the service node;

[0009] The live stream processing request is sent to the target service node, and the target service node responds to the live stream processing request.

[0010] Optionally, obtaining the service slots of each service node according to the total number of preset slots and the service capability of each service node includes:

[0011] Obtain multiple configuration parameters of each service node in the live source station cluster;

[0012] Obtaining the service capability of the corresponding service node according to the multiple configuration parameters and the preset capability weights;

[0013] Obtaining the number of slots of each service node according to the service capability of each service node and the total number of preset slots;

[0014] Determine a slot range value corresponding to the service node according to the identification order of each service node and the corresponding number of slots;

[0015] The slot range value is determined as a service slot corresponding to the service node.

[0016] Optionally, obtaining the service capability of the corresponding service node according to the multiple configuration parameters and the preset capability weights includes:

[0017] Obtaining a corresponding performance value of the service node according to at least one of the configuration parameters used to characterize the same performance of the service node;

[0018] Get preset capability weights corresponding to different performances;

[0019] A weighted operation is performed on the multiple performance values ​​and the preset capability weight of the same service node to obtain the service capability of the service node.

[0020] Optionally, the method further includes:

[0021] Obtaining a status message reported by each service node in a message queue; the status message includes status information and slot data corresponding to the service node, and the slot data includes at least a service slot currently allocated to the service node;

[0022] Detecting that the service node has not reported a new status message within a first time period, determining that the service node is in a pending offline state;

[0023] Sending a health detection request to the service node in the to-be-offline state;

[0024] Determine that a health detection response message fed back by the service node in the to-be-offline state is received, and control the service node to switch from the to-be-offline state to a healthy state;

[0025] Determine that no health detection response message fed back by the service node in the to-be-offline state is received, and verify whether the service node is offline according to a preset verification method;

[0026] If the verification result indicates that the service node is offline, controlling the service node to switch from the to-be-offline state to the offline state;

[0027] It is prohibited to send a live stream processing request to the service node in the offline state.

[0028] Optionally, verifying whether the service node is offline according to a preset verification method includes:

[0029] Re-sending a health detection request to the service node at a second interval;

[0030] If a health detection response message fed back by the service node is received, it is determined that the service node is in a healthy state;

[0031] If no health detection response message fed back by the service node is received, detecting whether the number of detection times of sending the health detection request to the second service node reaches a preset detection threshold;

[0032] If not reached, resend the health detection request to the service node at the second interval described in step;

[0033] If so, it is determined that the service node is in an offline state.

[0034] Optionally, the verifying whether the service node is offline according to a preset verification method further includes:

[0035] Sending a status verification request for the service node in a pending offline state to each second scheduling node in the live broadcast source station cluster; wherein the second scheduling node refers to other scheduling nodes among the multiple scheduling nodes included in the live broadcast source station cluster, except for the first scheduling node currently verifying whether the service node is offline;

[0036] Receiving a status verification response message fed back by each second scheduling node, and determining whether the service node fed back by the corresponding second scheduling node is in an offline state;

[0037] The second scheduling nodes detect a first number and feedback that the service node is in an offline state, and determine that the service node is in an offline state; the first number is greater than half of the total number of the scheduling nodes included in the live source station cluster.

[0038] Optionally, the method further includes:

[0039] Obtain a service node deletion request and determine the service slot of the service node to be deleted;

[0040] According to the service capabilities of each service node retained in the live source station cluster, the service slots of the service nodes to be deleted are allocated to each of the retained service nodes to update the service slots of the retained service nodes;

[0041] Sending the updated service slots of the reserved service nodes to the second scheduling nodes in the live source station cluster, and the second scheduling nodes updating the service slots of the corresponding service nodes;

[0042] A service slot update message is sent to the signaling server, and the signaling server controls each connected live stream processing object to perform a live stream address change operation according to the updated service slots of each reserved service node, and resend the corresponding live stream processing request.

[0043] Optionally, the method further includes:

[0044] Obtaining an idle slot recovery application message; the idle slot recovery application message is sent by a newly added service node in the live source station cluster, or is sent by any original service node when the current load exceeds a preset value;

[0045] Determine an idle slot in the service slots of each original service node; the idle slot is recovered through multiple handshake operations between the first scheduling node and the corresponding service node;

[0046] According to the free slots, the service slots of the original service nodes are updated, and the service slots of the newly added service nodes are determined;

[0047] The service slot of the newly added service node is sent to the newly added service node for storage, and the updated service slots of all service nodes currently included in the live broadcast source station cluster are synchronously updated to the second scheduling node.

[0048] On the other hand, the present application also proposes a live stream processing method, the method comprising:

[0049] The first service node obtains a live stream processing request; the live stream processing request includes a request object identifier and a live stream identifier;

[0050] According to the request object identifier and the live stream identifier, the total number of preset slots of the live source station cluster is processed to determine a response slot value corresponding to the live stream processing request;

[0051] Comparing the response slot value with the service slot of the first service node itself; wherein the service slot is obtained according to the total number of preset slots and the service capability of the service node, and the service capability of the service node is obtained according to the configuration parameters of the service node;

[0052] Determine that the service slot of the own service slot does not include the response slot value, compare the response slot value with the service slot of the second service node stored locally, and determine a third service node corresponding to the response slot value from a plurality of the second service nodes;

[0053] The live stream processing request is forwarded to the third service node, and the third service node verifies that its own service slot does not contain the response slot value. However, when it is determined that the forwarding number of the live stream processing request is greater than the forwarding threshold, the third service node refuses to respond to the live stream processing request and triggers each service node to perform a service slot synchronization operation.

[0054] On the other hand, the present application also proposes a live broadcast source station cluster, including: multiple service nodes, multiple scheduling nodes, a message queue server and a signaling server, wherein the service nodes and the scheduling nodes are deployed in a one-to-one correspondence, wherein:

[0055] The signaling server is used to connect to each live stream processing object and send a live stream processing request from any of the live stream processing objects to the scheduling node or the service node;

[0056] The service node is used to implement the live stream processing method executed by the corresponding side;

[0057] The scheduling node is used to implement the live stream processing method executed by the corresponding side;

[0058] The message queue server is used to store the service status and service slot reported by the service node.

[0059] On the other hand, the present application also proposes a computer-readable storage medium on which computer instructions are stored. The computer instructions are loaded and executed by a processor to implement the above-mentioned floating clover remote sensing identification method.

[0060] Based on the above technical solution, the present application provides a live stream processing method and a live source station cluster. The present application will allocate corresponding service slots to each service node in the live source station cluster according to the service capabilities of the service node itself. In this way, after the scheduling node obtains the live stream processing request, it will accurately calculate the corresponding response slot value based on the request content, determine the target service node with the service slot where the response slot value is located, respond to the live stream processing request, and meet the push or pull service requirements. Compared with the processing method of determining the target service node based on polling or consistent hashing algorithm, the present application ensures load balancing of each service node, and is also convenient for adding and / or deleting service nodes and scheduling nodes in the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0062] Figure 1 A schematic diagram of the structure of an optional example of a live source station cluster applicable to the live stream processing method proposed in the present application;

[0063] Figure 2 A flowchart of an optional example of the live stream processing method proposed in this application;

[0064] Figure 3 A flowchart of another optional example of the live stream processing method proposed in this application;

[0065] Figure 4 A flowchart of another optional example of the live stream processing method proposed in this application;

[0066] Figure 5 A flowchart of another optional example of the live stream processing method proposed in this application;

[0067] Figure 6 A flowchart of another optional example of the live stream processing method proposed in this application;

[0068] Figure 7 A flowchart of another optional example of the live stream processing method proposed in this application;

[0069] Figure 8 A flowchart of another optional example of the live stream processing method proposed in this application;

[0070] Fig. 9 A signaling flow diagram of another optional example of the live stream processing method proposed in this application;

[0071] Fig.10 A structural diagram of another optional example of the live stream processing device proposed in this application;

[0072] Fig.11 This is a structural diagram of another optional example of the live streaming processing device proposed in this application. DETAILED DESCRIPTION

[0073] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. It can be understood that the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0074] Reference Figure 1, is a structural diagram of an optional example of a live source station cluster applicable to the live stream processing method proposed in the present application, the live source station cluster may include multiple service nodes 110, multiple scheduling nodes 120, a message queue server 130 and a signaling server 140, the service node 110 and the scheduling node 120 are deployed in a one-to-one correspondence (i.e., mapping), wherein:

[0075] The service node 110 may be a device that can provide live streaming processing (such as push streaming or pull streaming) services. This application does not limit the device type. The multiple service nodes 110 included in the live source station cluster may be devices of the same type or different types. This application does not limit this. Regarding how the service node 100 implements live streaming processing (such as push streaming or pull streaming services), please refer to the description of the corresponding method embodiment below.

[0076] In actual applications, each service node 110 can regularly publish its own service status (such as whether it is online, the remaining load size, the list of stream information it undertakes, etc., this application does not limit the information content contained in the service status, which can be determined according to the situation) and service slots (that is, the specific slot range that can undertake push or pull stream services) to the message queue server 130, and subscribe to status messages of other service nodes in the cluster to learn the service status and service slots of other service nodes, but it is not limited to this publish-subscribe status message transmission method.

[0077] The scheduling node 120 can act as an observer of the cluster, and monitor the status changes of the service node 110 by subscribing to the status message of the corresponding service node from the message queue server 130, so as to timely discover the offline service node, update its service status, and prevent it from continuing to participate in the live broadcast scheduling, and improve the response efficiency of the live broadcast stream processing request. It is also possible to implement the response scheduling of the live broadcast stream processing request based on the monitored service status and service slot, and migrate the live broadcast stream to the capable service node response without interrupting the live broadcast business, so as to ensure the load balancing of each service node 110. The implementation process can refer to the live broadcast stream processing method described from the scheduling node side in the following embodiment, and the embodiment of this application will not be described in detail here.

[0078] It should be noted that in the actual application of the present application, the one-to-one corresponding service node 110 and the scheduling node 120 can be deployed in the same device, such as using the container Docker to be deployed on the same host machine, so that the device can be used as a service node and a scheduling node to implement the live stream processing method proposed in the present application; of course, the one-to-one corresponding service node 110 and the scheduling node 120 can also be deployed in different devices, and the two can be connected via wireless or wired communication to achieve data interaction between the two.

[0079] The message queue server 130 serves as a storage server of the cluster and can be used to store the service status and service slot reported by each service node 110. Since each service node 110 can periodically update its service status and service slot, the present application adopts this message queue storage method to store the status message sent by the service node 110, and can accurately identify the latest status message, so that the scheduling node 120 can subscribe to the latest status message and determine the latest service status of the corresponding service node 110 and the latest service slot allocated to it.

[0080] It can be seen that the message queue server 130 in the cluster can achieve communication connection with each service node 110 and scheduling node 120 through wireless or wired communication to realize the transmission of data such as status messages. This application does not elaborate on the communication connection method and data transmission process between the service node 110, the scheduling node 120 and the message queue server 130, which can be determined based on the live stream processing requirements.

[0081] The signaling server 140 can be connected to various live stream processing objects, such as the live broadcast client used by the user. The signaling server 140 can send the live stream processing request from any live stream processing object to the scheduling node or service node, and process it according to the live stream processing method of the corresponding side to meet the push or pull stream access requirements of the corresponding live stream processing object.

[0082] It should be understood that Figure 1 The structure of the live broadcast source station cluster shown does not constitute a limitation on the live broadcast source station cluster in the embodiment of the present application. In actual applications, the live broadcast source station cluster may include Figure 1 There are more devices shown, which are not listed one by one in this application.

[0083] In combination with the composition structure of the live broadcast source station cluster described in the above embodiments, and the functions of each component device, the live broadcast stream processing method proposed in this application will be described from the scheduling node and service node sides respectively, but is not limited to the description content of the embodiments below.

[0084] Reference Figure 2 , is a flow chart of an optional example of the live streaming processing method proposed in the present application. The method can be executed by a scheduling node in a live source station cluster. The embodiment of the present application can optimize the load balancing implementation method in the scheduling process, such as Figure 2 As shown, the method may include:

[0085] Step S21, obtaining a live stream processing request; the live stream processing request includes a request object identifier and a live stream identifier;

[0086] Step S22, processing the total number of preset slots of the live source station cluster according to the request object identifier and the live stream identifier, and determining a response slot value corresponding to the live stream processing request;

[0087] Combined with the relevant description of each component device of the live source station cluster in the above embodiment, since each scheduling node in the live source station cluster subscribes to the status information of the one-to-one mapped service node and caches it, when receiving the live stream processing request sent by the signaling server, such as a push stream or pull stream request, a hash value calculation can be performed based on the application instance name APP (recorded as the request object identifier) ​​and the stream name stream (recorded as the live stream identifier) ​​contained therein to obtain the corresponding check value, thereby performing a modulo operation on the total number of preset slots (such as 1024 slots, etc., the present application does not limit the value of the total number of preset slots) to accurately determine the response slot value of this response to the live stream processing request. The calculation process can be determined based on the historical scheduling rules, and the present application does not limit the calculation method of the response slot value.

[0088] Among them, the calculation process of the above-mentioned check value can be implemented based on a hash algorithm such as CRC (Cyclic Redundancy Check) 16 algorithm or MD5 algorithm (Message Digest Algorithm, fifth-generation message digest algorithm). This application does not elaborate on the calculation implementation process of the check value.

[0089] Step S23, determining the service node corresponding to the service slot where the response slot value is located as the target service node;

[0090] It should be noted that in this application, the service slots of each service node in the live source station cluster can be obtained based on the total number of preset slots and the service capabilities of each service node, and the service capabilities of the service node can be obtained based on the configuration parameters of the service node (such as the number of CPU physical cores, CPU frequency, memory size, etc.). It can be seen that this application allocates the service slots of each service node as a whole based on the service capabilities of each service node, that is, the slot range value, so that it matches the service capabilities of the service node, so as to avoid too many idle slots, reduce the overload of service nodes and cause insufficient slots, and realize the reuse of the performance of each service node.

[0091] Based on this, after the scheduling node determines the response slot value of the live stream processing request, it can determine the target service node corresponding to the response slot value according to the service slots of each service node, that is, the service node to which the response slot value is assigned. This application does not limit the implementation method of how to determine the target service node and the service slots of each service node.

[0092] Step S24: sending the live stream processing request to the target service node, and the target service node responds to the live stream processing request.

[0093] In summary, in the embodiments of the present application, a corresponding service slot is allocated to each service node in the live source station cluster based on the service capabilities of the service node itself. In this way, after the scheduling node obtains the live stream processing request, it will accurately calculate the corresponding response slot value based on the request content, that is, which slot responds to the live stream processing request. Since the service slots of each server node match its own service capabilities, compared with the processing method of determining the target service node based on polling or consistent hashing algorithm, the present application proposes a processing method of determining the target service node for push or pull stream services based on the calculated response slot value, which ensures the load balancing of each service node and facilitates the addition and / or deletion of service nodes and scheduling nodes in the system.

[0094] Reference Figure 3 , is a flowchart of another optional example of the live streaming processing method proposed in this application. The method can still be executed by the scheduling node. This embodiment can describe how to implement the allocation process of the service slots of each service node based on the service capabilities of each service node to ensure the load balancing of each service node, but is not limited to the service slot allocation implementation method described in this embodiment. Figure 3 As shown, the method may include:

[0095] Step S31, obtaining multiple configuration parameters of each service node in the live source station cluster;

[0096] In order to obtain the service capability of each service node, that is, the computing power of the service node, multiple configuration parameters that can characterize the performance of the service node can be obtained, such as the number of CPU physical cores, CPU frequency, memory size, etc. This application does not limit the type of configuration parameters of each service node and the method of obtaining them.

[0097] Step S32, obtaining the service capability of the corresponding service node according to the plurality of configuration parameters and the preset capability weight;

[0098] In an embodiment of the present application, the preset capability weight can represent the degree of influence of the configuration parameters of different types of performance on the service capability of the service node. The present application does not limit the numerical value of the preset capability weight. By way of example, for the configuration parameters as exemplified above, the preset capability weight of the above-mentioned CPU computing power can be 70%, and the preset capability weight of the memory capacity can be 30%.

[0099] Based on this, the present application can use the preset capability weights to perform weighted operations on the obtained multiple configuration parameters to determine the service capability of the corresponding service node. In the service capability calculation process, the performance values ​​of the different performances of the service node represented by each configuration parameter can be first obtained, and then the preset capability weights of the corresponding performance categories can be combined to calculate the service capability of the service node with the corresponding performance value.

[0100] Optionally, the above step S32 may include but is not limited to: obtaining a corresponding performance value of the service node based on at least one configuration parameter used to characterize the same performance of the service node; obtaining preset capability weights corresponding to different performances, and then performing weighted operations on multiple performance values ​​and preset capability weights of the same service node to obtain the service capability of the service node.

[0101] For example, the configuration parameters listed above can be substituted into the CPU physical core number and CPU frequency of each service node into the calculation formula of CPU computing power (i.e., computing performance value) = CPU physical core number * CPU frequency / GHZ (frequency unit: gigahertz) to obtain the computing performance value of the corresponding service node. The memory capacity of each service node can be substituted into the calculation formula of memory capacity = memory size / GB (memory capacity unit: gigabyte) to obtain the storage performance value of the corresponding service node.

[0102] Afterwards, the service capacity of the corresponding service node can be obtained by weighted calculation of the CPU computing power (i.e., computing performance value) and memory capacity (i.e., storage performance value) of each service node according to the service capacity calculation method of service capacity = CPU computing power * 70% + memory capacity * 30%. However, it is not limited to the service capacity calculation method of the service node described in this embodiment.

[0103] Step S33, obtaining the number of slots of each service node according to the service capacity of each service node and the total number of preset slots;

[0104] Since each slot corresponds to a live stream processing address, the push or pull stream request of the live broadcast business is realized based on it. In order to ensure that the service capacity of the service node matches the number of allocated slots, during the execution of the live broadcast business, it is necessary to avoid the situation where there are still many idle slots under high load, or the service node is still capable of responding to the live stream processing request, but the allocated slots have been used, that is, too few slots are allocated to the service node, thereby causing a waste of service node resources. The scheduling node will calculate the number of slots of each service node based on the service capacity of each service node. For example, for service nodes with higher service capacity, a larger number of slots can be allocated; and for service nodes with lower service capacity, a smaller number of slots can be allocated.

[0105] Based on this, in some embodiments, the total service capacity of all service nodes included in the cluster can be obtained, that is, the service capacity of each service node is summed up, and then the service capacity of each service node is ratioed to the total service capacity to obtain the ratio of each service capacity to the total service capacity, that is, the proportion of the service capacity of each service node in the total service capacity, and it is multiplied by the total number of preset slots to obtain the number of slots allocated to the corresponding service node.

[0106] Exemplarily, the live broadcast source station cluster includes service node A, service node B and service node C. The service capacity of service node A is recorded as A1, the service capacity of service node B is recorded as B1, and the service capacity of service node C is recorded as C1. According to the slot allocation method described above, the number of slots of service node A = A1 / (A1+B1+C1)*total number of preset slots; the number of slots of service node B = B1 / (A1+B1+C1)*total number of preset slots; the number of slots of service node C = C1 / (A1+B1+C1)*total number of preset slots.

[0107] Step S34, determining the slot range value of the corresponding service node according to the identification order of each service node and the corresponding slot quantity;

[0108] Step S35: determine the slot range value as the service slot of the corresponding service node.

[0109] For the live broadcast source station cluster containing all service nodes, they can be sorted according to the identifier used to distinguish each service node (such as service name, etc.) to obtain a service node identification dictionary. In this way, after determining the number of slots that each service node's own service capability can support according to the method described above, they can be sorted according to the service node identification dictionary to determine the slot range value corresponding to the service node, thereby obtaining the service slots of each service node.

[0110] For example, the three service nodes A, B, and C mentioned above are still used as examples for explanation. If the total number of preset slots is 1024 slots (it may also be 65535 slots, and the total number of preset slots can be determined based on the resource configuration of the cluster. This application does not limit its value), according to the above allocation method, it is determined that service node A is allocated 200 slots, service node B is allocated 300 slots, and service node C is allocated 524 slots. According to the order of service node A, service node B, and service node C, the corresponding slot range values ​​can be A (0-199), B (200-499), and C (500-1023) respectively.

[0111] Need to explain. Regarding the implementation method of allocating service slots to each service node based on the service capabilities of each service node in the cluster, including but not limited to the implementation method described above, the service capabilities of each service node can also be calculated based on actual application needs by obtaining other dimensional information, and even the network parameters of the service network that the service node provides push or pull services can be combined to determine the slot allocation weight of each service node to improve the accuracy of slot allocation. In addition, regarding the virtual number of other slots, the implementation process of determining the slot range value of each service node is similar, and this application does not give detailed examples one by one.

[0112] Reference Figure 4 , which is a flowchart of another optional example of the live streaming processing method proposed in this application. The method can still be executed by the scheduling node. This embodiment can optimize the health monitoring method of each service node in the cluster to ensure that the service node in the offline state no longer participates in the subsequent live streaming scheduling, such as Figure 4 As shown, the method may include:

[0113] Step S41, obtaining a status message reported by each service node in the message queue; the status message includes status information and slot data of the corresponding service node, and the slot data includes at least a service slot currently allocated to the service node;

[0114] The health monitoring of nodes in the live source station cluster can be completed by a storage server such as a message queue, which records the status messages regularly reported by each service node, that is, messages containing the service node's own status information and service slots, so that the service node can read the latest status messages reported by other service nodes from the message queue. The implementation process is not described in detail in this application.

[0115] Based on this, each scheduling node in the live source station cluster can also subscribe to the status message of each service node in the message queue. Since the scheduling nodes and service nodes of the cluster are mapped one by one, the scheduling node can directly read the status message of its own mapped service node from the message queue, and read the status message of other mapped service nodes from the message queue through other scheduling nodes, but it is not limited to this status message acquisition method.

[0116] Step S42: Detecting that the service node has not reported a new status message within the first time period, determining that the service node is in a pending offline state;

[0117] Step S43, sending a health detection request to the service node in the offline state;

[0118] For each scheduling node in the cluster, it can act as an observer to monitor whether the mapped service node is offline, that is, to perform health detection on the mapped service node. If the scheduling node finds that it has not received a status message from a mapped service node for a period of time (recorded as the first time period), that is, no new status message of the mapped service node is read from the message queue within the first time period, the service node can be marked as being in a suspicious state, that is, to be offline. Afterwards, a health detection request can be sent to the service node to further detect whether the suspicious service node is offline.

[0119] Step S44, determining whether a health detection response message fed back by a service node in a to-be-offline state is received; if yes, proceeding to step S45; if no, executing step S46;

[0120] Step S45, controlling the service node to switch from the offline state to the healthy state;

[0121] Following the above analysis, after the scheduling node sends a health detection request to the mapped suspicious service node (i.e., in the offline state), if the service node is in a healthy state (i.e., normal working state, also called online state), after receiving the health detection request, it will usually feedback the corresponding health detection response message to indicate that the service node is in a healthy state. In this way, the service node in the offline state can be re-marked as a healthy state. This application does not limit the marking method of the service node's state.

[0122] Step S46, verifying whether the service node is offline according to a preset verification method;

[0123] Step S47: if the verification result indicates that the service node is offline, control the service node to switch from a pending offline state to an offline state;

[0124] According to the status verification implementation method of the service node described above, if the scheduling node does not receive the health detection response message fed back by the mapped service node, it can further verify whether the service node is offline according to the preset verification method. This application does not limit the content of the preset verification method and it can be determined according to the situation.

[0125] Optionally, if any scheduling node does not receive a health detection response message from the mapped service node that is in an offline state according to the health monitoring method described above, it may send a health detection request again after a certain period of time to determine again whether the server can normally feedback a health detection response message. After multiple detections, if the actual number of detections reaches a preset detection threshold (i.e., the preset maximum number of detections), and the scheduling node still does not receive a health detection response message from the service node, the service node may be marked as offline, thereby improving the reliability of health detection of the service node.

[0126] Based on this, the above-mentioned step S46 may include: re-sending a health detection request to the service node at an interval of a second time period, and if a health detection response message fed back by the service node is received, determining that the service node is in a healthy state; conversely, if the health detection response message fed back by the service node is not received, detecting whether the number of detection times of sending a health detection request to the second service node reaches a preset detection threshold, if not reached, re-executing the step of re-sending a health detection request to the service node at an interval of the second time period, and performing health detection again; if reached, determining that the service node is in an offline state, but is not limited to this offline detection implementation method.

[0127] In some other embodiments, in order to avoid inaccurate health monitoring results of service nodes due to network anomalies of the scheduling node itself, when the scheduling node determines that the mapped service node is in a pending offline state, it can inquire other scheduling nodes in the cluster about the status of the service node. If more than half of the scheduling nodes determine that the service node is in an offline state, the service node is marked as offline.

[0128] Based on this, Figure 5 As shown, the state verification method of the service node in the offline state executed by the first scheduling node may include:

[0129] Step S51, the first scheduling node sends a status verification request for the service node in the offline state to each second scheduling node in the live source station cluster;

[0130] In an embodiment of the present application, the second scheduling node may refer to other scheduling nodes among the multiple scheduling nodes included in the live broadcast source station cluster, except for the first scheduling node that is currently verifying whether the service node in the offline state is offline. The present application does not elaborate on the communication implementation method between different scheduling nodes in the cluster. For example, the first scheduling node publishes a status verification request in the cluster, which can be stored in a message queue. After that, each second scheduling node can subscribe to the status verification request published by the first scheduling node, and determine whether the service node is in an offline state according to but not limited to the health monitoring method of the service node described above, and obtain a corresponding status verification response message, but is not limited to the status verification request publishing and subscription implementation method described in this embodiment.

[0131] Step S52, receiving a status verification response message fed back by each second scheduling node, and determining whether the service node fed back by the corresponding second scheduling node is in an offline state;

[0132] Step S53: Detecting the first number of second scheduling nodes feeding back that the service node is in an offline state, determining that the service node is in an offline state.

[0133] Following the above analysis, after the first scheduling node obtains the status verification response message fed back by each second scheduling node, the status verification response message includes the health detection result of the corresponding second scheduling node detecting whether the service node is offline. In this way, the first scheduling node can count the contents of each status verification response message to determine the number of second scheduling nodes that report that the service node is in an offline state. If the number is greater than or equal to the first number, that is, greater than half of the total number of the scheduling nodes included in the live source station cluster, the service node can be considered to be in an offline state; otherwise, the service node can be considered to be in a healthy state or remain in a pending offline state.

[0134] Step S48: prohibiting sending a live stream processing request to a service node in an offline state.

[0135] According to but not limited to the verification implementation method of whether the service node is offline described above, after determining that the service node is offline, the service node can be prohibited from participating in subsequent live broadcast scheduling, that is, the live broadcast stream processing requests such as live broadcast push or pull received by the scheduling node subsequently will no longer be allocated to the service node in the offline state, thereby ensuring the efficiency of push or pull and improving the live broadcast experience.

[0136] Reference Figure 6 , which is a flow chart of another optional example of the live stream processing method proposed in the present application. The method can still be executed by the scheduling node. This embodiment can optimize the live stream migration process. In practical applications, when an abnormality such as excessive service node load or node downtime may cause interruption of the live service, the automatic migration function of the live stream is particularly important. That is, when an event that may affect the live service is detected, the live stream of the live service can be promptly migrated to other healthy service nodes to ensure that the live service is not interrupted. It may include but is not limited to the application scenarios described in this embodiment where live stream migration is performed due to service node deletion, such as Figure 6 As shown, the live streaming processing method proposed in this application may also include:

[0137] Step S61, obtaining a service node deletion request, and determining a service slot of the service node to be deleted;

[0138] When the service node status is unavailable or requires to go offline (i.e., it is determined to switch to the offline state), the service node can be recorded as a service node to be deleted. In order to avoid waste of resources and ensure that the live broadcast business processed by the service node will not be interrupted due to the deletion of the service node, before deleting the service node to be deleted from the cluster, the service slot previously allocated to the service node to be deleted can be allocated to other retained service nodes, so as to migrate the live broadcast stream of the live broadcast business executed by the service slot of the service node to the allocated retained service node, and the service node continues to support the live broadcast business, so that the push and pull clients (i.e., the request objects) can establish a long connection with the signaling server and maintain the keepalive state (keepalive).

[0139] Based on this, any scheduling node that receives a service node deletion request can trigger the generation of a corresponding service node deletion request based on factors such as the status of the service node or the user's operation on the service node, and determine the service slot corresponding to the service node to be deleted. Regarding the implementation method of how to allocate service slots to different service nodes in the cluster, please refer to the description of the corresponding part of the context, which will not be described in detail in this embodiment.

[0140] Step S62, according to the service capabilities of each service node reserved in the live source station cluster, allocating the service slot of the service node to be deleted to each reserved service node, so as to update the service slot of the reserved service node;

[0141] Step S63, sending the updated service slots of each reserved service node to each second scheduling node in the live source station cluster, and the second scheduling node updates the service slots of the corresponding service nodes;

[0142] Regarding the implementation process of step S62, reference may be made to the implementation scheme of how to allocate service slots to each service node according to the service capability of the service node described in the corresponding part of the above embodiment, which will not be described in detail in this embodiment.

[0143] After the service slots of each service node retained in the cluster are updated, they can be published to each second scheduling node in a timely manner according to the status message reporting method mentioned above, so that each second scheduling node can update the service slots of each service node retained in the cluster that it records, and replace the deleted service nodes with the retained service nodes. The live broadcast business performed by the deleted service nodes is executed through the allocated slot range, that is, the live broadcast stream previously processed by the deleted service node is migrated to the retained service nodes, such as the service nodes assigned to the slot value that responds to the live broadcast stream processing request, without interrupting the live broadcast business.

[0144] Step S64, sending a service slot update message to the signaling server, and the signaling server controls each connected live stream processing object to perform a live stream address change operation according to the updated service slots of each service node, and resend the corresponding live stream processing request.

[0145] Following the above analysis, in the case where the cluster deletes one or more service nodes, resulting in the need to migrate the live stream (i.e., the push or pull stream performed by the service node to be deleted), after the service slots of the service node to be deleted are allocated to the retained service nodes according to the method described above, the client that was previously provided with push or pull stream services by the service node to be deleted, i.e., the live stream processing request object, can be promptly notified through the signaling server, such as by sending a service slot update message (or other notification method) to the live stream processing object through the signaling server, so that the live stream processing request can perform an address change operation accordingly, and the live stream processing requests subsequently sent can be rescheduled according to the method described above, and a new service node can be determined to push and pull the stream again to meet the live stream processing requirements of the live stream processing request. The implementation process is not described in detail in this application.

[0146] Reference Figure 7 , is a flowchart of another optional example of the live stream processing method proposed in this application. This method can still be executed by the scheduling node. Different from the scenario described in the above embodiment where the live stream migration is caused by the deletion of the service node, this embodiment can describe the application scenario where the live stream migration is performed due to the addition of a service node in the live source station cluster to ensure load balancing. This application does not describe in detail the implementation method of deleting or adding a service node in the live source station cluster. In the live stream processing method described in the above embodiment, Figure 7 As shown, the method may also include:

[0147] Step S71, receiving a free slot application message sent by a newly added service node of the live source station cluster;

[0148] Step S72, sending an idle slot recovery application message to each original service node of the live source station cluster, so that the original service node determines the idle slot in its own service slot according to the idle slot recovery application message;

[0149] After a new service node is added to the live broadcast source station cluster, a scheduling node that is mapped one-to-one with the new service node will be configured in the cluster. In order to enable the new service node to participate in the live broadcast scheduling for push or pull services, the new service node can apply for a free slot from the local scheduling node (i.e., the first scheduling node mapped to the new service node). After receiving the free slot application message sent by the new service node, the first scheduling node can send a free slot recovery application message to other service nodes in the cluster, that is, send a free slot recovery application message, thereby instructing the service node that has received the free slot recovery application message to determine the free slots in the service slots that have been allocated to it according to the content of the message.

[0150] Among them, the free slot recovery application message sent by the first scheduling node can include a request for the number of free slots supported by different service nodes, so that the service node can determine the free slot value that meets the requested number of free slots based on this; of course, the free slot recovery application message may also not include the number requirements for the free slots that each service node needs to provide, then the service node can directly query the number of free slots that it can transfer and its slot value, etc. The present application does not limit the method for obtaining free slots of each service node.

[0151] Step S73, receiving the idle slots fed back by the original service nodes, and sending a confirmation message of reclaiming the idle slots to the corresponding service node, so that the service node determines a new service slot according to the reclaimed idle slots;

[0152] Step S74, receiving the idle slot recovery confirmation message fed back by the original service node, and updating the stored service slots of each original service node;

[0153] In an embodiment of the present application, after the first scheduling node receives the idle slots fed back by the service node, it can send a confirmation to recover the idle slots again to inform the corresponding service node that the first scheduling node has successfully received the fed back idle slots. After that, the service node can also reply with a confirmation message, and complete the reallocation of the idle slots through a four-way handshake. The scheduling node and the service node can reallocate the service slots of each service node according to the slot allocation method described above, but is not limited to the communication implementation method described in this embodiment.

[0154] Step S75, determining a service slot of the newly added service node according to the received free slots from the original service node;

[0155] Step S76, sending the service slot of the newly added service node to the newly added service node storage, and synchronously updating the updated service slots of all service nodes currently included in the live broadcast source station cluster to the second scheduling node.

[0156] After the first scheduling node obtains an idle slot from the original service node in the cluster according to the above method, it can increase the service slot of the newly added service node accordingly, and the newly added service node caches the service slot allocated to itself to complete the slot allocation task of the newly added service node, so that it can work normally online, that is, it can support push or pull streaming services. Afterwards, the first scheduling node can inform the second scheduling node of the updated service slots of all service nodes in the cluster at this time through message publishing methods such as broadcasting, so that each scheduling node in the cluster can know the service slots of the newly added service node and the updated service slots of the original service node. The implementation process is not described in detail in this application.

[0157] Reference Figure 8 , which is another optional example of the flow chart of the live streaming processing method proposed in this application. This method can still be executed by the scheduling node. In actual applications, if a service node is overloaded, in order to ensure load balancing and push / pull efficiency, this application proposes to reallocate the slot values ​​of each service node and migrate the live streaming of the high-load service node. Of course, this slot reallocation method can also be applied to the application scenario after adding a new service node to the cluster described above, such as Figure 8 As shown, the live streaming processing method proposed in this application may also include:

[0158] Step S81, obtaining an idle slot recovery application message;

[0159] In an embodiment of the present application, the idle slot recovery request message may be sent by a newly added service node in the live source station cluster, or sent by any original service node when the current load exceeds a preset value. The present application does not restrict the content of the idle slot recovery request message and its generation process, which may be determined according to the circumstances.

[0160] Step S82, determining the free slots in the service slots of each original service node;

[0161] Step S83, updating the service slot of each service node according to the free slot;

[0162] In combination with the free slot acquisition method described in the above embodiment, the free slot can be recovered through multiple handshake operations between the first scheduling node and the corresponding service node, that is, after the overloaded service node or the newly added service node triggers the slot reallocation operation, the local scheduling node is applied for slot recovery, and the local scheduling node (referred to as the first scheduling node) receives the slot recovery application and returns a reply allowing recovery. After receiving the reply, the corresponding service node can update its own service slot, and the first scheduling node can also update the slot data of each service node (including updating the service slot of the original service node and the service slot of the newly added service node, which can be determined according to the application scenario). The implementation process is not described in detail in the embodiment of this application.

[0163] Step S84, sending the updated service slots of each service node to the corresponding service node storage, and synchronously updating the updated service slots of all service nodes currently included in the live source station cluster to each second scheduling node.

[0164] In the application scenario of a newly added service node, as analyzed above, the service slot of the newly added service node can be sent to the newly added service node for storage, so that the newly added service node can provide push or pull streaming services through the allocated service slot.

[0165] Optionally, in the application scenarios described above, in the process of the first scheduling node sending various types of broadcast messages as described above to each second scheduling node, in order to avoid the loss of broadcast messages notifying other scheduling nodes, the first scheduling node may repeatedly send broadcast messages with the same content multiple times (such as 3 times, etc., and the present application does not limit the number of times the broadcast message is repeatedly sent), including but not limited to the slot data such as the updated service slots of each service node listed above.

[0166] In addition, for each scheduling node in the cluster, it can subscribe to the slot data regularly reported by each service node from the message queue, compare it with the slot data of the service nodes cached by itself, and achieve synchronous update to ensure that the slot data of each service node cached by each scheduling node is consistent with the slot data currently actually possessed by each service node.

[0167] Based on the live stream processing method described in the above embodiments, in scenarios such as adding service nodes, deleting service nodes, or service nodes being overloaded (such as the load exceeds the preset value, the load situation can be determined based on the number of used slots or the number of free slots, etc., which is not limited in this application), and being unable to receive new push streams, it is usually necessary to reallocate slots to each service node in the cluster. That is to say, when the scenarios including but not limited to those listed in this article are detected, a dynamic slot allocation operation can be triggered, and the service slots allocated to each service node in the corresponding scenario are determined according to the slot allocation implementation method described above, and subsequent live stream processing requests are executed accordingly, including migrating the live stream of the previously processed live service to the new service node to meet the push or pull stream service of the corresponding client.

[0168] In practical applications, for the live streaming processing methods described in the above embodiments, in application scenarios such as adding a new service node, deleting a service node, or reallocating a service node slot, the local scheduling node needs to notify other scheduling nodes to synchronously update the slot data of the corresponding service node. When more than half of the scheduling nodes reply that the update is complete, it can be considered that the slot data of the corresponding service node has been successfully updated, thereby ensuring that the scheduling nodes with inconsistent cache content can achieve consistency in the slot data of each service node cached by each scheduling node by subscribing to the scheduling service node slot data. Among them, the slot data of the service node may include but is not limited to: the slot range value currently allocated to the service node, that is, the service slot, and the used slot value, etc. Different slots can be represented by a bitmap, and the location of the existing or used slot can be marked as 1, otherwise it can be marked as 0, so the service slot allocated to the service node can be determined by marking 1.

[0169] Reference Fig. 9 , which is a flow chart of another optional example of the live stream processing method proposed in the present application. The method can still be executed by a service node, and the service node can be any service node in the cluster. In order to more clearly describe the processing of the service node and other service nodes, the service node that executes the live stream processing method can be recorded as the first service node, and the other service nodes can be recorded as the second service node.

[0170] Based on this, Fig. 9 As shown, the method may include:

[0171] Step S91: The first service node obtains a live stream processing request; the live stream processing request includes a request object identifier and a live stream identifier;

[0172] Step S92: The first service node processes the total number of preset slots of the live source station cluster according to the request object identifier and the live stream identifier, and determines a response slot value corresponding to the live stream processing request;

[0173] Combined with the description of the corresponding part of the above embodiment, any service node receives a push or pull request, that is, a live stream processing request, scheduled and allocated by the scheduling node. It can calculate the check value through the instance name app (that is, the request object identifier) / stream name stream (live stream identifier), and then take the modulus of the preset maximum slot value (that is, the preset total number of slots) to obtain the precise slot value slot_v (that is, the response slot value). The calculation process is not described in detail in this application.

[0174] Step S93, the first service node compares the response slot value with the service slot of the first service node itself;

[0175] In combination with the slot allocation implementation method described above, the service slots of each service node are obtained based on the preset total number of slots and the service capability of the service node. The service capability of the service node can be obtained based on the configuration parameters of the service node. The implementation process can refer to the description of the corresponding part of the above embodiment, and the embodiment of the present application will not be described in detail here.

[0176] Step S94, the first service node determines that its own service slot does not include the response slot value, compares the response slot value with the service slots of the second service node stored locally, and determines a third service node corresponding to the response slot value from multiple second service nodes;

[0177] Step S95: the first service node forwards the live streaming processing request to the third service node;

[0178] As analyzed above, the first service node compares the calculated response slot value slot_v with the slot values ​​in the service slots allocated to it. If the service slot contains slot_v, the first service node can execute the live stream processing request and provide live stream processing services such as push or pull streams. If the slot values ​​of the first service node itself are inconsistent with slot_v, check the slot_v and the slot data of other service nodes cached by itself, find the service node corresponding to slot_v, jump to the corresponding service node, and provide the client with push or pull stream services.

[0179] Optionally, in the above jump process, in order to avoid long response time and reduce the live broadcast experience, the number of forwarding times of the same live stream processing request can be recorded. After the forwarding number reaches the forwarding threshold (such as forwarding 3 times), if the service node corresponding to slot_v is still not found, the service can be rejected, that is, the live stream processing request is rejected.

[0180] Step S96, when the third service node verifies that its own service slot does not contain the response slot value, but determines that the forwarding number of the live stream processing request is greater than the forwarding threshold, it refuses to respond to the live stream processing request and triggers each service node to perform a service slot synchronization operation.

[0181] Since the above-mentioned query process of the service node corresponding to slot_v is implemented by the first service node based on the slot data of each service node cached by itself, the slot data may be different from the actual slot data of the corresponding service node. For example, after the last synchronization, the service node updates its own slot data, but has not yet synchronized to other service nodes (including the first service node). The first service node queries the third service node corresponding to slot_v based on the slot data of each service node cached by itself, and the third service node still needs to further verify whether slot_v belongs to its own slot value.

[0182] After verification, the third server node determines that slot_v belongs to its own slot value and can execute the live stream processing service; otherwise, the service can be rejected, or the slot data of each service node cached by the third service node can be queried in the query method described above to see whether it is consistent with the slot_v. If there is a consistent service node, it can also be determined whether the number of forwarding times is greater than the forwarding threshold. If not, the live stream processing request is forwarded to the newly determined service node (recorded as the fourth service node) and verification is continued according to the above method; if the number of forwarding times is greater than the forwarding threshold, that is, it exceeds the maximum number of jumps, the service can be rejected, and then the local service node and scheduling node are notified to synchronize the slot data of each service node to improve the response efficiency of subsequent push or pull services.

[0183] In summary, during the execution of the live stream processing method described above in the present application, when the scheduling service node performs push or pull services, according to the above processing method, it is determined that the calculated slot_v is inconsistent with the service slot of the service node itself, resulting in the service node being unable to serve the live stream processing request assigned to the service node. In this case, the live stream processing request can be assigned to other service nodes for processing according to the above method, thereby improving the service response speed.

[0184] Reference Fig.10 , is a schematic diagram of an optional example of a live stream processing device proposed in this application, and the device may include:

[0185] The live stream processing request obtaining module 101 is used to obtain a live stream processing request; the live stream processing request includes a request object identifier and a live stream identifier;

[0186] A response slot value determination module 102 is used to process the total number of preset slots of the live source station cluster according to the request object identifier and the live stream identifier, and determine the response slot value corresponding to the live stream processing request;

[0187] The target service node determination module 103 is used to determine the service node corresponding to the service slot where the response slot value is located as the target service node; wherein the service slot of each service node in the live source station cluster is obtained according to the total number of preset slots and the service capacity of each service node, and the service capacity of the service node is obtained according to the configuration parameters of the service node;

[0188] The live stream processing request sending module 104 is used to send the live stream processing request to the target service node, and the target service node responds to the live stream processing request.

[0189] The device comprises a service slot acquisition module, which is used to obtain the service slot of each service node according to the total number of preset slots and the service capacity of each service node;

[0190] Optionally, the service slot acquisition module may include:

[0191] A configuration parameter acquisition unit, used to acquire multiple configuration parameters of each service node in the live source station cluster;

[0192] A service capability obtaining unit, configured to obtain the service capability of the corresponding service node according to the plurality of configuration parameters and the preset capability weight;

[0193] A slot quantity obtaining unit, configured to obtain the slot quantity of each service node according to the service capability of each service node and the total number of preset slots;

[0194] A slot range value determining unit, configured to determine a slot range value corresponding to the service node according to the identification order of each service node and the corresponding number of slots;

[0195] A service slot determining unit is used to determine the slot range value as a service slot corresponding to the service node.

[0196] Optionally, the service capability obtaining unit may include:

[0197] a performance value obtaining unit, configured to obtain a corresponding performance value of the service node according to at least one of the configuration parameters used to characterize the same performance of the service node;

[0198] A preset capability weight obtaining unit, used to obtain preset capability weights corresponding to different performances;

[0199] The weighted operation unit is used to perform weighted operation on the multiple performance values ​​and the preset capability weights of the same service node to obtain the service capability of the service node.

[0200] The device described in the above embodiments may further include:

[0201] A status message acquisition module, used to acquire the status message reported by each service node in the message queue; the status message includes the status information and slot data corresponding to the service node, and the slot data at least includes the service slot currently allocated to the service node;

[0202] A status message detection module, configured to detect that the service node has not reported a new status message within a first period of time, and determine that the service node is in a pending offline state;

[0203] A health detection request sending module, used to send a health detection request to the service node in the to-be-offline state;

[0204] A first state control module is used to determine the health detection response message fed back by the service node in the to-be-offline state, and control the service node to switch from the to-be-offline state to a healthy state;

[0205] A verification module, used to determine that a health detection response message fed back by the service node in the to-be-offline state is not received, and verify whether the service node is offline according to a preset verification method;

[0206] A second state control module, configured to control the service node to switch from the to-be-offline state to the offline state if the verification result indicates that the service node is offline;

[0207] The prohibition module is used to prohibit sending a live stream processing request to the service node in the offline state.

[0208] Optionally, the verification module may include:

[0209] A health detection request resending unit, configured to determine that a health detection response message fed back by the service node in the to-be-offline state is not received, and to resend a health detection request to the service node at an interval of a second time length;

[0210] A first determining unit, configured to determine that the service node is in a healthy state if a health detection response message fed back by the service node is received;

[0211] A first detection unit is configured to detect whether the number of detection times of sending a health detection request to the second service node reaches a preset detection threshold if no health detection response message fed back by the service node is received; if not, trigger a health detection request resending unit to resend a health detection request to the service node at an interval of a second time length;

[0212] The second determining unit is configured to determine that the service node is in an offline state when the number of detection times does not reach a preset detection threshold.

[0213] In some further embodiments, the verification module may further include:

[0214] A status verification request sending unit, configured to send a status verification request for the service node in a pending offline state to each second scheduling node in the live source station cluster; wherein the second scheduling node refers to other scheduling nodes among the multiple scheduling nodes included in the live source station cluster, except for the first scheduling node currently verifying whether the service node is offline;

[0215] A third determining unit, configured to receive a status verification response message fed back by each second scheduling node, and determine whether the service node fed back by the corresponding second scheduling node is in an offline state;

[0216] The fourth determination unit is used to detect that the first number of the second scheduling nodes feedback that the service node is in an offline state, and determine that the service node is in an offline state; the first number is greater than half of the total number of the scheduling nodes included in the live source station cluster.

[0217] In some further embodiments, based on the above description, the device may further include:

[0218] A service slot determining device, used to obtain a service node deletion request and determine a service slot of a service node to be deleted;

[0219] A service slot updating device, for allocating the service slot of the to-be-deleted service node to each of the reserved service nodes according to the service capabilities of each of the reserved service nodes in the live source station cluster, so as to update the service slot of the reserved service node;

[0220] A service slot sending device, used for sending the updated service slots of the reserved service nodes to each second scheduling node in the live source station cluster, so that the second scheduling node updates the service slot of the corresponding service node;

[0221] The service slot update message sending module is used to send a service slot update message to the signaling server, and the signaling server controls each connected live stream processing object to perform a live stream address change operation according to the updated service slots of each reserved service node, and resend the corresponding live stream processing request.

[0222] In some further embodiments, based on the above description, the device may further include:

[0223] An idle slot recovery application message obtaining module is used to obtain an idle slot recovery application message; the idle slot recovery application message is sent by a newly added service node in the live source station cluster, or is sent by any original service node when the current load exceeds a preset value;

[0224] An idle slot determination module, used to determine an idle slot in the service slots of each original service node; the idle slot is recovered through multiple handshake operations between the first scheduling node and the corresponding service node;

[0225] A service slot updating module, used to update the service slots of the original service nodes according to the free slots, and determine the service slots of the newly added service nodes;

[0226] The service slot sending module is used to send the service slot of the newly added service node to the newly added service node storage, and synchronously update the updated service slots of all service nodes currently included in the live source station cluster to the second scheduling node.

[0227] Reference Fig.11 , is a structural diagram of another optional example of the live streaming processing device proposed in this application, which can be described from the service node side, such as Fig.11 As shown, the device may include:

[0228] The live stream processing request obtaining module 111 is used to obtain a live stream processing request; the live stream processing request includes a request object identifier and a live stream identifier;

[0229] A response slot value determination module 112 is used to process the total number of preset slots of the live source station cluster according to the request object identifier and the live stream identifier, and determine the response slot value corresponding to the live stream processing request;

[0230] A first comparison module 113 is used to compare the response slot value with the service slot of the first service node itself; wherein the service slot is obtained according to the total number of preset slots and the service capability of the service node, and the service capability of the service node is obtained according to the configuration parameters of the service node;

[0231] A second comparison module 114 is configured to determine that the service slot of the own service slot does not contain the response slot value, compare the response slot value with the service slot of the second service node stored locally, and determine a third service node corresponding to the response slot value from a plurality of the second service nodes;

[0232] The live stream processing request forwarding module 115 is used to forward the live stream processing request to the third service node, and the third service node verifies that its own service slot does not contain the response slot value, but when it is determined that the forwarding number of the live stream processing request is greater than the forwarding threshold, it refuses to respond to the live stream processing request and triggers each service node to perform a service slot synchronization operation.

[0233] It should be noted that the various modules, units, etc. in the above-mentioned device embodiments can be stored in the memory as program modules, and the above-mentioned program modules stored in the memory can be executed by the processor to implement the corresponding functions, or they can be implemented by combining the program model and hardware. Regarding the functions implemented by each program module and its combination, as well as the technical effects achieved, please refer to the description of the corresponding parts of the above-mentioned method embodiments, which will not be repeated in this embodiment.

[0234] The embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. The computer program is loaded and executed by a processor to implement the steps of the above-mentioned live stream processing method. The specific implementation process can refer to the description of the corresponding part of the above-mentioned embodiment, which will not be repeated in this embodiment.

[0235] Finally, it should be noted that the terms such as "first" and "second" in this application are only used for descriptive purposes to distinguish one operation, unit or module from another operation, unit or module, and do not necessarily require or imply any actual relationship or order between these units, operations or modules. And they cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features.

[0236] In addition, the various embodiments in this specification are described in a progressive or parallel manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other. For the devices and clusters disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method part.

[0237] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the core idea or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A live stream processing method, characterized in that: The method comprises: The first service node obtains a live stream processing request; the live stream processing request includes a request object identifier and a live stream identifier; According to the request object identifier and the live stream identifier, the total number of preset slots of the live source station cluster is processed to determine a response slot value corresponding to the live stream processing request; Comparing the response slot value with the service slot of the first service node itself; wherein the service slot is obtained according to the total number of preset slots and the service capability of the service node, and the service capability of the service node is obtained according to the configuration parameters of the service node; Determine that the service slot of the own service slot does not include the response slot value, compare the response slot value with the service slot of the second service node stored locally, and determine a third service node corresponding to the response slot value from a plurality of the second service nodes; The live stream processing request is forwarded to the third service node, and the third service node verifies that its own service slot does not contain the response slot value. However, when it is determined that the forwarding number of the live stream processing request is greater than the forwarding threshold, the third service node refuses to respond to the live stream processing request and triggers each service node to perform a service slot synchronization operation.

2. A live broadcast source station cluster, characterized in that: include: A plurality of service nodes, a plurality of scheduling nodes, a message queue server and a signaling server, wherein the service nodes and the scheduling nodes are deployed in a one-to-one correspondence, wherein: The signaling server is used to connect to each live stream processing object and send a live stream processing request from any of the live stream processing objects to the scheduling node or the service node; The service node is used to implement the live stream processing method according to claim 1; The scheduling node is used to obtain a live stream processing request, wherein the live stream processing request includes a request object identifier and a live stream identifier; based on the request object identifier and the live stream identifier, the total number of preset slots of the live source station cluster is processed to determine a response slot value corresponding to the live stream processing request; the service node corresponding to the service slot where the response slot value is located is determined as a target service node; wherein the service slot of each service node in the live source station cluster is obtained based on the total number of preset slots and the service capacity of each service node, and the service capacity of the service node is obtained based on the configuration parameters of the service node; the live stream processing request is sent to the target service node, and the target service node responds to the live stream processing request; The message queue server is used to store the service status and service slot reported by the service node.

3. The live broadcast source station cluster according to claim 2, characterized in that: The scheduling node obtains the service slots of each service node according to the total number of preset slots and the service capability of each service node, including: Obtain multiple configuration parameters of each service node in the live source station cluster; Obtaining the service capability of the corresponding service node according to the multiple configuration parameters and the preset capability weights; Obtaining the number of slots of each service node according to the service capability of each service node and the total number of preset slots; Determine a slot range value corresponding to the service node according to the identification order of each service node and the corresponding number of slots; The slot range value is determined as a service slot corresponding to the service node.

4. The live broadcast source station cluster according to claim 3, characterized in that: The obtaining, according to the plurality of configuration parameters and the preset capability weights, the service capability of the corresponding service node comprises: Obtaining a corresponding performance value of the service node according to at least one of the configuration parameters used to characterize the same performance of the service node; Get preset capability weights corresponding to different performances; A weighted operation is performed on the multiple performance values ​​and the preset capability weight of the same service node to obtain the service capability of the service node.

5. The live broadcast source station cluster according to any one of claims 2 to 4, characterized in that: The scheduling node is also used for: Obtaining a status message reported by each service node in a message queue; the status message includes status information and slot data corresponding to the service node, and the slot data includes at least a service slot currently allocated to the service node; Detecting that the service node has not reported a new status message within a first time period, determining that the service node is in a pending offline state; Sending a health detection request to the service node in the to-be-offline state; Determine that a health detection response message fed back by the service node in the to-be-offline state is received, and control the service node to switch from the to-be-offline state to a healthy state; Determine that no health detection response message fed back by the service node in the to-be-offline state is received, and verify whether the service node is offline according to a preset verification method; If the verification result indicates that the service node is offline, controlling the service node to switch from the to-be-offline state to the offline state; It is prohibited to send a live stream processing request to the service node in the offline state.

6. The live broadcast source station cluster according to claim 5, characterized in that: The verifying whether the service node is offline according to a preset verification method includes: Re-sending a health detection request to the service node at a second interval; If a health detection response message fed back by the service node is received, it is determined that the service node is in a healthy state; If no health detection response message fed back by the service node is received, detecting whether the number of detection times of sending health detection requests to the service node reaches a preset detection threshold; If not reached, resend the health detection request to the service node at the second interval described in step; If so, it is determined that the service node is in an offline state.

7. The live broadcast source station cluster according to claim 5, characterized in that: The verifying whether the service node is offline according to a preset verification method further includes: Sending a status verification request for the service node in a pending offline state to each second scheduling node in the live broadcast source station cluster; wherein the second scheduling node refers to other scheduling nodes among the multiple scheduling nodes included in the live broadcast source station cluster, except for the first scheduling node currently verifying whether the service node is offline; Receiving a status verification response message fed back by each second scheduling node, and determining whether the service node fed back by the corresponding second scheduling node is in an offline state; The second scheduling nodes detect a first number and feedback that the service node is in an offline state, and determine that the service node is in an offline state; the first number is greater than half of the total number of the scheduling nodes included in the live source station cluster.

8. The live broadcast source station cluster according to claim 5, characterized in that: The scheduling node is also used for: Obtain a service node deletion request and determine the service slot of the service node to be deleted; According to the service capabilities of each service node retained in the live source station cluster, the service slots of the service nodes to be deleted are allocated to each of the retained service nodes to update the service slots of the retained service nodes; Sending the updated service slots of the reserved service nodes to the second scheduling nodes in the live source station cluster, and the second scheduling nodes updating the service slots of the corresponding service nodes; A service slot update message is sent to the signaling server, and the signaling server controls each connected live stream processing object to perform a live stream address change operation according to the updated service slots of each reserved service node, and resend the corresponding live stream processing request.

9. The live broadcast source station cluster according to claim 5, characterized in that: The scheduling node is also used for: Obtaining an idle slot recovery application message; the idle slot recovery application message is sent by a newly added service node in the live source station cluster, or is sent by any original service node when the current load exceeds a preset value; Determine an idle slot in the service slots of each original service node; the idle slot is recovered through multiple handshake operations between the first scheduling node and the corresponding service node; According to the free slots, the service slots of the original service nodes are updated, and the service slots of the newly added service nodes are determined; The service slot of the newly added service node is sent to the newly added service node for storage, and the updated service slots of all service nodes currently included in the live broadcast source station cluster are synchronously updated to the second scheduling node.

Images