Live broadcast service hot restart processing method, device, equipment, medium and program product

Abstract

The present disclosure provides a live broadcast service hot restart processing method, device, equipment, medium and program product, which relates to the fields of data transmission, hot restart, consistent hashing, and live broadcast streaming technology. The method includes: receiving a first negotiation request initiated by an incremental client to a first port; forwarding the first negotiation request received from the first port to the first User Datagram Protocol (UDP) port of any incremental work process in a surviving state according to a preset port mapping rule, and returning the live data stream received from the incremental work process to the incremental client; forwarding the keep-alive request received from the second port to the second UDP port of the matching existing work process according to the port mapping rule, and returning the live data stream received from the existing work process to the corresponding existing client. Application of this method can avoid the problem that the existing client cannot continue to obtain the live data stream due to the hot restart of the live broadcast service.

Description

Technical Field

[0001] The present disclosure relates to the field of communication technology, specifically to the field of data transmission, hot restart, consistent hashing, and live streaming technology, and especially to a live streaming service hot restart processing method, device, electronic device, computer-readable storage medium, and computer program product. Background Art

[0002] Low-latency live streaming is a live streaming function that can reduce the live streaming delay to a few seconds. To achieve this low-latency live streaming, UDP (User Datagram Protocol, whose main characteristics are connectionless, no guarantee of reliable transmission and message-oriented) port is used for communication service.

[0003] To ensure that the client can continuously obtain the live data stream, even if the live service needs to be updated or upgraded, a hot restart is usually used to not stop or interrupt the running worker process used for live streaming.

[0004] That is, the working process that existed before the hot restart will not be destroyed due to the hot restart operation, but will remain for a period of time to continue returning the live data stream to the existing clients.

[0005] However, after the existing live broadcast service is hot restarted, an incremental work process will be created. As a result, due to the coexistence of existing work processes and incremental work processes, the consistent hashing algorithm cannot accurately connect the existing clients to the original matching work process, which in turn causes the existing clients to be unable to correctly pull the stream to the live broadcast data stream after the hot restart. Summary of the Invention

[0006] The embodiments of the present disclosure provide a live broadcast service hot restart processing method, device, electronic device, computer-readable storage medium, and computer program product.

[0007] In a first aspect, an embodiment of the present disclosure provides a method for processing a hot restart of a live broadcast service, which is applied to a load balancing service, comprising: receiving a first negotiation request initiated by an incremental client to a first port; wherein the incremental client is a client that initiates a live broadcast request after the live broadcast service is hot restarted, and the live broadcast service creates multiple incremental work processes after the hot restart, and the first negotiation request is used to negotiate a session traversal method for network address translation; forwarding the first negotiation request received from the first port to the first User Datagram Protocol (UDP) port of any surviving incremental work process according to a preset port mapping rule, and returning the live broadcast data stream received from the incremental work process to the incremental client; wherein the port mapping rule records a mapping relationship between different ports of the load balancing service and different UDP ports of the work process; according to the port mapping rule, forwarding a keep-alive request received from the second port to the second UDP port of a matching existing work process, and returning the live broadcast data stream received from the existing work process to the corresponding existing client; wherein the keep-alive request is initiated by the existing client, which is a client that existed before the hot restart, and the existing work process is a work process that provided the live broadcast data stream to the corresponding existing client before the hot restart.

[0008] In the second aspect, an embodiment of the present disclosure proposes a live broadcast service hot restart processing device, which is applied to a load balancing service, including: a first request receiving unit, configured to receive a first negotiation request initiated by an incremental client to a first port; wherein the incremental client is a client that initiates a live broadcast request after the live broadcast service is hot restarted, and the live broadcast service creates multiple incremental work processes after the hot restart, and the first negotiation request is used to negotiate a session traversal method of network address translation; a first negotiation request forwarding and live broadcast data stream return unit, configured to forward the first negotiation request received from the first port to the first User Datagram Protocol UDP port of any incremental work process in a surviving state according to a preset port mapping rule. , and returns the live data stream received from the incremental work process to the incremental client; wherein, the port mapping rule records the mapping relationship between different ports of the load balancing service and different UDP ports of the work process; the keep-alive request forwarding and live data stream returning unit is configured to forward the keep-alive request received from the second port to the second UDP port of the matching existing work process according to the port mapping rule, and return the live data stream received from the existing work process to the corresponding existing client; wherein, the keep-alive request is initiated by the existing client, the existing client is the client that existed before the hot restart, and the existing work process is the work process that provides the live data stream to the corresponding existing client before the hot restart.

[0009] In a third aspect, an embodiment of the present disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the live broadcast service hot restart processing method described in the first aspect can be implemented when the at least one processor executes the instructions.

[0010] In a fourth aspect, an embodiment of the present disclosure provides a non-transitory computer-readable storage medium storing computer instructions, which are used to enable a computer to implement the live broadcast service hot restart processing method described in the first aspect when executed.

[0011] In a fifth aspect, an embodiment of the present disclosure provides a computer program product comprising a computer program, which, when executed by a processor, can implement the steps of the live service hot restart processing method described in the first aspect.

[0012] The live broadcast service hot restart processing solution provided by the present disclosure controls the load balancing service to receive the first negotiation request sent by the incremental client after the hot restart through the new port, and forwards the first negotiation request received through the new port to the new UDP port of the incremental work process through the preset port mapping rule, thereby distinguishing it from the old port used by the existing client to send the keep-alive request to the load balancing service before the hot restart. Similarly, the load balancing service will also forward the keep-alive request received through the old port to the old UDP port of the existing work process through the port mapping rule, that is, the new and old clients communicate with the different UDP ports of the new and old work processes through different ports of the load balancing service, so that the existing client will not perceive the incremental work process based on the new port and the new UDP port, but will continue to locate the original communicating existing work process through the existing work process that communicates using the old port and the old UDP port. Therefore, the process positioning operation will not cause an error due to the change in the number of processes, resulting in the inability to locate the process through the consistent hash, thereby ensuring that the existing client can still continue to obtain the live data stream after the live broadcast service is hot restarted.

[0013] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Other features, objects and advantages of the present disclosure will become more apparent from a reading of the detailed description of non-limiting embodiments made with reference to the following drawings:

[0015] Figure 1 is an exemplary system architecture in which the present disclosure may be applied;

[0016] Figure 2 A schematic diagram of a process in which a client communicates with a worker in a live broadcast service through a load balancing service to pull a live broadcast data stream in the related art;

[0017] Figure 3 A flowchart of a live broadcast service hot restart processing method provided by an embodiment of the present disclosure;

[0018] Figure 4 A flowchart of a communication process between an existing client, a load balancing server, and an existing working process before a live broadcast service hot restart is provided in an embodiment of the present disclosure;

[0019] Figure 5-1 The embodiment of the present disclosure provides a method different from Figure 2 A flow chart showing the new communication solution between the client, load balancing service, and worker processes in the live streaming service.

[0020] Figure 5-2 The embodiment of the present disclosure provides a Figure 5-1 A diagram comparing the communication mode between the incremental client and the load balancing service and the incremental work process after the live broadcast service is hot restarted with the communication mode between the existing client and the load balancing service and the existing work process;

[0021] Figure 6 A flowchart of an incremental client communicating with an existing work process through a load balancing service provided in an embodiment of the present disclosure;

[0022] Figure 7 A flowchart of another embodiment of the present disclosure providing an incremental client communicating with an incremental work process through a load balancing service;

[0023] Figure 8 A structural block diagram of a live broadcast service hot restart processing device provided by an embodiment of the present disclosure;

[0024] Figure 9 A structural diagram of an electronic device suitable for executing a live broadcast service hot restart processing method provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0025] The following description of exemplary embodiments of the present disclosure is made in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those skilled in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. It should be noted that the embodiments in the present disclosure and the features in the embodiments can be combined with each other unless there is a conflict.

[0026] In the technical solutions disclosed herein, the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0027] Figure 1 An exemplary system architecture 100 is shown to which embodiments of the live service hot restart processing method, apparatus, electronic device, and computer-readable storage medium disclosed herein can be applied.

[0028] like Figure 1 As shown, the system architecture 100 may include terminal devices 101, 102, 103, a load balancing server 104, live servers 105, 106 and a live source server 107. The live servers 105 and 106 may each create multiple work processes (see Figure 1 The three boxes shown are used as examples to respond to live broadcast requests initiated by different clients. The network exists as a medium to provide a communication link between terminal devices 101, 102, 103 and any two of the load balancing server 104, live broadcast servers 105, 106, and live broadcast source server 107. The network can include various connection types, such as wired or wireless communication links or fiber optic cables.

[0029] Users can use terminal devices 101, 102, and 103 to interact with live broadcast source server 107 through load balancing server 104 and live broadcast servers 105 and 106 to receive live broadcast data streams or send messages and control information. Various applications for enabling information communication between terminal devices 101, 102, and 103, load balancing server 104, live broadcast servers 105 and 106, and live broadcast source server 107 can be installed, such as live broadcast viewing applications, on-demand applications, and instant messaging applications.

[0030] Terminal devices 101, 102, 103, load balancing server 104, live broadcast servers 105, 106, and live broadcast source server 107 can all be hardware or software. When terminal devices 101, 102, 103 are hardware, they can be various electronic devices with display screens, including but not limited to smartphones, tablet computers, laptop computers, desktop computers, etc.; when terminal devices 101, 102, 103 are software, they can be installed in the electronic devices listed above, which can be implemented as multiple software or software modules, or as a single software or software module, and are not specifically limited here. When load balancing server 104, live broadcast servers 105, 106, and live broadcast source server 107 are hardware, they can be implemented as a distributed server cluster consisting of multiple servers, or as a single server; when the server is software, it can be implemented as multiple software or software modules, or as a single software or software module, and are not specifically limited here.

[0031] The load balancing server 104 can provide various services through various built-in applications. Taking the live viewing application that can provide live broadcast services as an example, the load balancing server 104 can achieve the following effects when running the live viewing application: first, receiving the first negotiation request initiated by the incremental client to the first port. The incremental client is a client that initiates the live broadcast request after the live broadcast service is hot restarted. The live broadcast service creates multiple incremental work processes after the hot restart. The first negotiation request is used to negotiate the session traversal method of network address translation; then, according to the preset port mapping rules, the first negotiation request received from the first port is forwarded to the first user of any incremental work process in a surviving state. Datagram Protocol UDP port, and returns the live data stream received from the incremental work process to the incremental client, and the port mapping rule records the mapping relationship between different ports of the load balancing service and different UDP ports of the work process; at the same time, according to the port mapping rule, the keep-alive request received from the second port is forwarded to the second UDP port of the matching existing work process, and the live data stream received from the existing work process is returned to the corresponding existing client, the keep-alive request is initiated by the existing client, the existing client is the client that existed before the hot restart, and the existing work process is the work process that provides the live data stream to the corresponding existing client before the hot restart.

[0032] The live broadcast service hot restart processing method provided in the subsequent embodiments of the present disclosure is executed by the load balancing server 104 that load balances requests initiated by a large number of clients. Accordingly, the live broadcast service hot restart processing device can generally also be set in the load balancing server 104.

[0033] It should be understood that Figure 1The number of terminal devices, load balancing servers, live servers, work processes, and live source servers in the embodiment is merely illustrative. Any number of terminal devices, load balancing servers, live servers, work processes, and live source servers may be used as needed.

[0034] To understand the solution provided by this application for live broadcast service after hot restart, please first refer to Figure 2 , Figure 2 This is a flowchart of the client communicating with the working process in the live broadcast service through the load balancing service in the related technology to pull the live broadcast data stream:

[0035] First, the client sends an SDP packet to port 1052 of the load balancing service.

[0036] Among them, the full name of SDP in English is Session Description Protocol, which is used in this disclosure to describe the data packets describing the playback information in low-latency live broadcast, including offer and answer. The offer is sent by the playback end to the server end and is used to record the audio and video formats or parsing protocols supported by the playback end. The answer is returned by the server end to the client end and is used to record whether the audio and video data corresponding to the audio and video formats or parsing protocols supported by the client can be provided.

[0037] ①: The 1052 port of the load balancing service forwards the SDP packet to any surviving working process in the live broadcast service (i.e. Figure 2 Work process in 1);

[0038] ②: Work process 1 pulls the media playback information (including audio and video format and parsing protocol) of the requested live video from the live source server based on the received SDP packet and generates an answer;

[0039] ③: Worker process 1 stores the media playback information contained in the answer in the form of key-value pairs in other surviving work processes (i.e. Figure 2 Work process in 3);

[0040] ④Worker process 1 returns the answer to port 1052 of the load balancing service, which then returns it to the client through port 1052. This completes the first phase of negotiation interaction. The object of this phase of negotiation interaction is the format or parsing protocol of the audio and video data to ensure that the subsequently returned audio and video data is supported and playable by the client.

[0041] The client then initiates an ICE negotiation request to port 1052 of the load balancing service.

[0042] ICE stands for Interactive Connectivity Establishment. This phase of interaction primarily focuses on negotiation based on the STUN (Session traversal utilities for NAT) protocol, which simply uses UDP to traverse NAT. It is a lightweight protocol that provides a complete UDP-based NAT traversal solution, primarily serving as a tool for other protocols. It allows a client behind a NAT (or multiple NATs) to determine its public address, the type of NAT it is behind, and the internet port to which the NAT binds a local port. This information is used to establish UDP communication between two hosts behind NAT routers. The purpose is to find the information needed for the outside world to connect to the internal address. STUN exists to facilitate NAT traversal. STUN is a typical client / server model, with the client sending requests and the server responding. STUN is both a client / server and a request / response protocol.

[0043] ⑤ The 1052 port of the load balancing service forwards the Stun request (Stun protocol request packet) in the ICE negotiation request to any surviving working process in the live broadcast service (i.e. Figure 2 Work process in 4);

[0044] ⑥ Work process 4 obtains the relevant KV information from work process 3 that originally stores the media playback information of the requested live video;

[0045] ⑦Worker process 4 pulls the requested live data stream from the live source server;

[0046] ⑧Worker process 4 returns the pulled live data stream and KV information to port 1052 of the load balancing service, so that the load balancing service can return the data received at port 1052 to the client. At this point, a data packet constituting the live data stream can be sent to the client. In the subsequent process, the client will continue to send a keep-alive request through port 1052 of the load balancing service (to inform the load balancing service and worker process 4 that the client is still requesting subsequent live data). In this way, the latest live data stream will be continuously returned if the load balancing service and worker process 4 confirm that the client has not disconnected.

[0047] Different from the first phase negotiation interaction based on SDP packets in steps ①-④, the second phase negotiation interaction is mainly the Stun protocol negotiation interaction performed through ICE negotiation requests.

[0048] pass Figure 2 As can be seen from the above interaction steps described in the flowchart shown, when existing clients use the live broadcast service, the two-stage negotiation interaction uses the same port of the load balancing service (i.e., port 1052 in the above example) and the same port of different work processes (i.e., port 7070 in the above example). Therefore, under this solution, once the live broadcast service is hot restarted and multiple new work processes are created, when both the old and new work processes use port 7070 to communicate with the old and new clients through port 1052 of the load balancing service, the change in the number of work processes will cause the original solution of using consistent hashing to accurately locate the originally used work process to be destroyed, that is, the originally used work process cannot be accurately located through consistent hashing, which means that the work process that receives the keep-alive request from the old client cannot understand the request, and of course cannot return the latest live broadcast data stream it needs to the old client, resulting in the old client being unable to continue to obtain the live broadcast data stream normally due to the hot restart operation of the live broadcast service.

[0049] In passing Figure 2 After the flow diagram of the existing scheme and the above principle explanation, please refer to Figure 3 , Figure 3 This is a flowchart of a live broadcast service hot restart processing method provided in an embodiment of the present disclosure, in order to solve the defects of the prior art through the following steps included in process 300:

[0050] Step 301: Receive a first negotiation request initiated by an incremental client to a first port;

[0051] This step is intended to be performed by the execution subject of the live service hot restart processing method (for example Figure 1 The load balancing server 104 shown receives a first negotiation request initiated by an incremental client to a first port. The incremental client is a client that initiates a live broadcast request after the live broadcast service is hot restarted, and is also used to distinguish existing clients that have already initiated live broadcast requests before the live broadcast service is hot restarted. The live broadcast service will create multiple incremental work processes after the hot restart, and the incremental work process is also used to distinguish existing work processes that have been connected to existing clients before the live broadcast service is hot restarted. The first negotiation request is used to negotiate the session traversal method of network address translation, that is, the ICE negotiation request mentioned in the above embodiment.

[0052] This step is based on the fact that the live broadcast service has been hot-restarted and multiple incremental work processes have been created through the hot restart to connect to the live broadcast data acquisition requests initiated by the incremental client. The number of these incremental work processes is the same as the number of existing work processes.

[0053] Among them, live broadcast services can be divided into ordinary live broadcast services, low-latency live broadcast services and ultra-low-latency live broadcast services according to delay and stability. Among them, the delay of low-latency live broadcast services is generally 1-2 seconds, and the delay of ultra-low-latency live broadcast services can generally be shortened to less than 1 second. The live broadcast service targeted by the solution provided by the present disclosure can be a low-latency live broadcast service that uses UDP to reduce the delay to no more than a first preset time length. Specifically, the first negotiation request will also adaptively be a request for negotiation interaction of a session traversing the STUN protocol based on UDP for network address translation.

[0054] Step 302: forwarding the first negotiation request received from the first port to the first User Datagram Protocol (UDP) port of any surviving incremental work process according to a preset port mapping rule, and returning the live data stream received from the incremental work process to the incremental client;

[0055] Based on step 301, this step is intended to forward the first negotiation request received from the first port to the first User Datagram Protocol UDP port of any surviving incremental work process according to the preset port mapping rules, and return the live data stream received from the incremental work process to the incremental client.

[0056] Among them, the port mapping rule records the mapping relationship between different ports of the load balancing service and different UDP ports of the working process. A specific mapping relationship shown in this step is: the first port of the load balancing service corresponds to the first UDP port of the incremental working process, that is, the load balancing service will forward all information received through the first port to the first UDP port of the incremental working process, and the incremental working process will also process the information received through the first UDP port accordingly, and return the corresponding response information to the first port of the load balancing service.

[0057] Step 303: According to the port mapping rule, the keep-alive request received from the second port is forwarded to the second UDP port of the matching existing work process, and the live data stream received from the existing work process is returned to the corresponding existing client.

[0058] Based on step 301, this step aims to forward the keep-alive request received from the second port to the second UDP port of the matching existing work process according to the port mapping rules by the above-mentioned execution entity, and return the live data stream received from the existing work process to the corresponding existing client.

[0059] The keep-alive request is initiated by an existing client, which is a client that existed before the hot restart. The existing working process is a working process that provides live data streams to the corresponding existing client before the hot restart.

[0060] Different from the specific mapping relationship shown in step 302, this step also shows another specific mapping relationship, namely: the second port of the load balancing service corresponds to the second UDP port of the existing work process, that is, the load balancing service will forward the information received through the second port to the second UDP port of the existing work process, and the existing work process will also process the information received through the second UDP port accordingly, and return the corresponding response information to the second port of the load balancing service.

[0061] That is to say, even after the live broadcast service is hot restarted, the existing client still communicates with the second UDP port of the existing work process through the second port of the load balancing service to continue to obtain the live data stream. At the same time, the incremental client communicates with the first UDP port of the incremental work process through the first port of the load balancing service to obtain the live data stream. That is, the existing client and the incremental client independently realize the communication between the load balancing service and the work process based on different port mapping relationships, thereby obtaining the live data stream from the live broadcast source server respectively.

[0062] The live broadcast service hot restart processing method provided by the embodiment of the present disclosure controls the load balancing service to receive the first negotiation request sent by the incremental client after the hot restart through the new port, and forwards the first negotiation request received through the new port to the new UDP port of the incremental work process through the preset port mapping rule, thereby distinguishing it from the old port used by the existing client to send the keep-alive request to the load balancing service before the hot restart. Similarly, the load balancing service will also forward the keep-alive request received through the old port to the old UDP port of the existing work process through the port mapping rule, that is, the new and old clients communicate with the different UDP ports of the new and old work processes through different ports of the load balancing service, so that the existing client will not perceive the incremental work process based on the new port and the new UDP port, but will continue to locate the original communicating existing work process through the existing work process that communicates using the old port and the old UDP port. Therefore, the process positioning operation will not cause an error due to the change in the number of processes that cannot be located through consistent hashing, thereby ensuring that the existing client can still continue to obtain the live data stream after the live broadcast service is hot restarted.

[0063] Based on the above embodiments, please also refer to Figure 4 , Figure 4A flowchart of a communication process between an existing client, a load balancing server, and an existing working process before a live broadcast service hot restart is provided in an embodiment of the present disclosure, wherein process 400 includes the following steps:

[0064] Step 401: Receive a second negotiation request initiated by an existing client to a third port;

[0065] The second negotiation request is used to negotiate whether the actual audio and video format used by the live data stream is the audio and video format supported by the client. This is the first-stage negotiation interaction request initiated based on the SDP packet mentioned in the above embodiment, which includes the offer part.

[0066] Step 402: Send the second negotiation request to the third UDP port of any surviving working process in the surviving state according to the port mapping rule;

[0067] Step 403: Receive a second negotiation response returned by the existing work process to which the second negotiation request is sent;

[0068] The second negotiation response includes an answer portion.

[0069] Step 404: Return the second negotiation response with the second port attached to the existing client;

[0070] The second port is used to instruct the existing client to use the second port as the destination port for initiating the first negotiation request.

[0071] Step 405: Receive a first negotiation request initiated by an existing client to the second port;

[0072] The first negotiation request is used to negotiate a session traversal method of network address translation, for example, an ICE negotiation request, and specifically performs negotiation interaction based on the Stun protocol.

[0073] Step 406: forwarding the first negotiation request received from the second port to the second UDP port of any existing working process in a live state according to the port mapping rule;

[0074] Step 407: receiving the live data stream returned by the existing working process to which the first negotiation request is sent;

[0075] Step 408: Return the live data stream to the corresponding existing client.

[0076] The existing client will send the keep-alive request once every second preset duration after first receiving the live data stream. The second preset duration is used to distinguish it from the first preset duration mentioned in the above embodiment in name, but the specific duration values ​​of the two may be the same or different.

[0077] That is, this embodiment describes the steps 401 to 408. Figure 3 Before the steps provided in the embodiment shown, the existing client first obtains the live data stream through which interactive steps. The above process is actually Figure 2 All the steps mentioned in the illustrated embodiment have already occurred and will not be described again here.

[0078] Furthermore, if the time interval since the last keep-alive request was received exceeds a third preset duration, the corresponding existing working process can be destroyed. That is, if the third preset duration has passed, it can be determined that the existing client has actively disconnected from the live broadcast access and no longer needs to transmit the live broadcast data stream. Furthermore, when the last existing working process is destroyed, the second port can be used as a backup destination port for receiving the first negotiation request initiated after the next hot restart, for subsequent use.

[0079] For example, if the live broadcast service is hot-restarted again, the target destination port for the first negotiation request initiated by the incremental client can be selected from the port pool that records all backup destination ports according to a preset selection rule. The preset selection rule includes any of the following: sequential selection (e.g., a certain numbering order, such as an ascending numbering order), random selection, remainder selection, and round-robin selection.

[0080] exist Figure 2 The corresponding embodiment has described the communication method of the prior art. Figure 3 While the embodiments have described the steps of the new communication method provided by the present disclosure, the present disclosure further provides Figure 5-1 and Figure 5-2 A more comprehensive explanation of each of the new communication methods provided is provided:

[0081] First reference Figure 5-1 , Figure 5-1 The embodiment of the present disclosure provides a method different from Figure 2 Flowchart of the new communication solution between the client, load balancing service, and worker processes in the live broadcast service. Figure 2 The flow chart shown shows that:

[0082] Figure 5-1 During the first phase of negotiation and interaction between the client and the live broadcast service process through the load balancing service, Figure 2 They are exactly the same, that is, they also communicate with the worker process's port 7070 through the load balancing service's port 1052.

[0083] But the difference is: in the second phase of negotiation interaction and obtaining live data stream, Figure 5-1 A solution is provided for the client to communicate with the port 7080 of the working process through the 1053 port of the load balancing service. That is, under the new communication mode, during the second phase of interaction between the client and the live broadcast service, the client initiates a request to another port of the load balancing service, and the load balancing service forwards the request received from the other port to another UDP port of the working process under the preset port mapping rules, thereby realizing the separation of port usage in the first phase of negotiation interaction and the second phase of negotiation interaction.

[0084] Next reference Figure 5-2 , Figure 5-2 The embodiment of the present disclosure provides a Figure 5-1 Based on the comparison diagram of the communication mode between the incremental client and the load balancing service and the incremental work process after the live broadcast service hot restart and the communication mode between the existing client and the load balancing service and the existing work process, it can be seen that:

[0085] At this time, because the live broadcast service performs a hot restart, there will be two parts. One part is the live broadcast service composed of multiple existing work processes, which is mainly used to serve existing clients; the other part is the live broadcast service composed of multiple incremental work processes, which is dedicated to serving incremental clients.

[0086] That is, by default, incremental clients can Figure 5-1 The complete communication process shown is that the incremental client obtains the live data stream from the live source server, but the communication method used by the existing client before the hot restart is different from the already occupied load balancing port 1053 and the existing work process port 7080. The incremental client can further use the load balancing service port 1052 and the incremental work process port 7070 to complete the first phase of negotiation interaction, and in the second phase of negotiation interaction, use the unoccupied load balancing service port 1054 and the incremental work process port 7081, so that the port combination used by the existing client is different from the port combination used by the incremental client, and thus when the number of working processes under the port combination used by the client in each state does not change, the keep-alive request initiated by the existing client (corresponding to the failure of the keep-alive request) will not be destroyed due to the destruction of the consistent hash. Figure 5-2 ⑨) in the above is determined to be in the wrong working process, making it impossible for the existing client to obtain the latest live data stream (corresponding to Figure 5-2 The problem in ⑩) appears again.

[0087] On the basis of any of the above embodiments, considering that after the live broadcast service is hot restarted, multiple incremental work processes are usually gradually created over a period of time, that is, the creation time of different incremental work processes is different, so when the incremental work process has not been completely created and the load balancing service also needs to spend time to detect whether the incremental work process is in a live state, the present disclosure also adopts Figure 6 A flowchart for how an incremental client communicates with an existing worker process through a load balancing service is provided to try to circumvent the problems that may arise from the above situation. The flowchart includes the following steps:

[0088] Step 601: In response to the load balancing service not completing the liveness detection operation on all incremental work processes, receiving a second negotiation request initiated by the incremental client to the third port;

[0089] The second negotiation request is used to negotiate whether the actual audio and video format used by the live data stream is an audio and video format supported by the client;

[0090] Step 602: Send the second negotiation request to the third UDP port of any existing working process in a live state according to the port mapping rule;

[0091] Step 603: Receive a second negotiation response returned by the existing work process to which the second negotiation request is sent;

[0092] Step 604: Return the second negotiation response with the first port appended thereto to the incremental client.

[0093] The first port is used to instruct the incremental client to use the first port as the destination port for initiating the first negotiation request.

[0094] That is, before the load balancing service completes the detection operation for all incremental work processes, the present invention forwards the second negotiation request (that is, the first phase negotiation interaction based on the SDP packet) initiated by the received incremental client to the third port (for example, the 1052 port of the load balancing service mentioned in the above example) to the third UDP port of any surviving existing work process (for example, the 7070 port mentioned in the above example), and then completes the first phase of negotiation interaction processing through the existing work process, which mainly includes completing the confirmation of whether the audio and video format or the parsing protocol is supported and the storage of media playback information.

[0095] That is, considering that the incremental work process is not yet fully available under the current circumstances, the first phase of negotiation interaction required by the incremental client in this embodiment is completed by using the existing work process that is confirmed to be available.

[0096] Correspondingly, Figure 7Another flow chart of an incremental client communicating with an incremental work process through a load balancing service is shown, wherein the flow 700 includes the following steps:

[0097] Step 701: In response to the load balancing service having completed the detection operation on all incremental work processes, receiving a second negotiation request initiated by the incremental client to the third port;

[0098] The second negotiation request is used to negotiate whether the actual audio and video format used by the live data stream is an audio and video format supported by the client;

[0099] Step 702: Send the second negotiation request to the third UDP port of any incremental work process in a surviving state according to the port mapping rule;

[0100] Step 703: Receive a second negotiation response returned by the incremental work process to which the second negotiation request is sent;

[0101] Step 704: Return the second negotiation response with the first port appended thereto to the incremental client.

[0102] The first port is used to instruct the incremental client to use the first port as the destination port for initiating the first negotiation request.

[0103] Different from Figure 6 The illustrated embodiment is based on the assumption that the load balancing service has completed the activation operation for all incremental work processes. That is, all incremental work processes have been created and the load balancing service has completed the activation operation for all incremental work processes. Therefore, it can be determined that all incremental work processes are in an available state. Therefore, in this case, this embodiment can normally use the incremental work processes to complete the first phase of the negotiation interaction process with the incremental client.

[0104] Based on the above embodiment, the media playback information of the live stream included in the second negotiation response (such as the KV information mentioned in the above embodiment) can also be stored in any active working process and a preset second storage cluster. This allows the corresponding media playback information to be obtained from the second storage cluster when the incremental process has not been fully created and the corresponding media playback information cannot be obtained from the working process through the first protocol request.

[0105] Further references Figure 8 As an implementation of the methods shown in the above figures, the present disclosure provides an embodiment of a live broadcast service hot restart processing device. Figure 2 Corresponding to the method embodiment shown, the device can be specifically applied to various electronic devices.

[0106] like Figure 8 As shown, the live broadcast service hot restart processing device 800 of this embodiment may include: a first request receiving unit 801, a first negotiation request forwarding and live broadcast data stream returning unit 802, and a keep-alive request forwarding and live broadcast data stream returning unit 803. Among them, the first request receiving unit 801 is configured to receive a first negotiation request initiated by an incremental client to the first port. The incremental client is: a client that initiates a live broadcast request after the live broadcast service is hot restarted. The live broadcast service creates multiple incremental work processes after the hot restart. The first negotiation request is used to negotiate the session traversal method of the network address translation; the first negotiation request forwarding and live broadcast data stream returning unit 802 is configured to: forward the first negotiation request received from the first port to the first User Datagram Protocol UDP port of any incremental work process in a surviving state according to the preset port mapping rules, and forward the live broadcast data received from the incremental work process to the first User Datagram Protocol UDP port of any incremental work process in a surviving state. The data stream is returned to the incremental client, and the port mapping rules record the mapping relationship between different ports of the load balancing service and different UDP ports of the working process; the keep-alive request forwarding and live data stream return unit 803 is configured to: according to the port mapping rules, forward the keep-alive request received from the second port to the second UDP port of the matching existing working process, and return the live data stream received from the existing working process to the corresponding existing client. The keep-alive request is initiated by the existing client. The existing client is a client that exists before the hot restart, and the existing working process is a working process that provides the live data stream to the corresponding existing client before the hot restart.

[0107] In this embodiment, in the live service hot restart processing device 800, the specific processing of the first request receiving unit 801, the first negotiation request forwarding and live data stream returning unit 802, and the keep-alive request forwarding and live data stream returning unit 803 and the technical effects thereof can be referred to respectively. Figure 2 The relevant descriptions of steps 201-203 in the corresponding embodiment are not repeated here.

[0108] In some optional implementations of this embodiment, the live broadcast service is a low-latency live broadcast service that uses UDP to reduce the delay to no more than a first preset duration, and the first negotiation request is a request for negotiation interaction for a session traversing the STUN protocol for network address translation based on UDP.

[0109] In some optional implementations of this embodiment, the live service hot restart processing device 800 further includes:

[0110] A second request receiving unit is configured to receive a first negotiation request initiated by an existing client to the second port before performing a hot restart;

[0111] The first forwarding unit is configured to forward the first negotiation request received from the second port to the second UDP port of any existing working process in a surviving state according to the port mapping rule;

[0112] A first data stream receiving unit is configured to receive a live data stream returned by the existing working process to which the first negotiation request is sent;

[0113] The first data stream returning unit is configured to return the live data stream to the corresponding existing client; wherein the existing client will send a keep-alive request once every second preset time period after first receiving the live data stream.

[0114] In some optional implementations of this embodiment, the live service hot restart processing device 800 further includes:

[0115] A third request receiving unit is configured to receive a second negotiation request initiated by the existing client to the third port before receiving the first negotiation request initiated by the existing client to the second port; wherein the second negotiation request is used to negotiate whether the actual audio and video format used by the live data stream is an audio and video format supported by the client;

[0116] The second forwarding unit is configured to send the second negotiation request to a third UDP port of any surviving working process in a surviving state according to the port mapping rule;

[0117] A first response receiving unit is configured to receive a second negotiation response returned by the existing working process to which the second negotiation request is sent;

[0118] The first response returning unit is configured to return a second negotiation response with a second port attached to it to the existing client; wherein the second port is used to instruct the existing client to use the second port as a destination port for initiating the first negotiation request.

[0119] In some optional implementations of this embodiment, the live service hot restart processing device 800 further includes:

[0120] a destroying unit configured to, in response to a time interval from receiving a last keep-alive request exceeding a second preset time period, destroy the corresponding existing work process;

[0121] The backup destination port reserve unit is configured to use the second port as a backup destination port for receiving the first negotiation request initiated after the next hot restart in response to the last existing working process being destroyed.

[0122] In some optional implementations of this embodiment, the live service hot restart processing device 800 further includes:

[0123] The destination port selection unit is configured to select a target destination port as the destination port of the first negotiation request initiated by the incremental client from a port pool recording all backup destination ports according to a preset selection rule in response to the live broadcast service being hot restarted again.

[0124] In some optional implementations of this embodiment, the preset selection rule includes any of the following:

[0125] Sequential selection, random selection, remainder selection, and round-robin selection.

[0126] In some optional implementations of this embodiment, the live service hot restart processing device 800 further includes:

[0127] The fourth request receiving unit is configured to, before receiving the first negotiation request initiated by the incremental client to the first port, receive a second negotiation request initiated by the incremental client to the third port in response to the load balancing service not completing the live detection operation for all incremental work processes; wherein the second negotiation request is used to negotiate whether the actual audio and video format used by the live data stream is an audio and video format supported by the client;

[0128] The third forwarding unit is configured to send the second negotiation request to a third UDP port of any existing working process in a surviving state according to the port mapping rule;

[0129] A second response receiving unit is configured to receive a second negotiation response returned by the existing working process to which the second negotiation request is sent;

[0130] The second response returning unit is configured to return the second negotiation response with the first port attached to it to the incremental client; wherein the first port is used to instruct the incremental client to use the first port as the destination port for initiating the first negotiation request.

[0131] In some optional implementations of this embodiment, the live service hot restart processing device 800 further includes:

[0132] The fifth request receiving unit is configured to, before receiving the first negotiation request initiated by the incremental client to the first port, receive a second negotiation request initiated by the incremental client to the third port in response to the load balancing service completing the live detection operation for all incremental work processes; wherein the second negotiation request is used to negotiate whether the actual audio and video format used by the live data stream is an audio and video format supported by the client;

[0133] The fourth forwarding unit is configured to send the second negotiation request to the third UDP port of any incremental work process in a surviving state according to the port mapping rule;

[0134] a third response receiving unit, configured to receive a second negotiation response returned by the incremental work process to which the second negotiation request is sent;

[0135] The third response returning unit is configured to return the second negotiation response with the first port attached to it to the incremental client; wherein the first port is used to instruct the incremental client to use the first port as the destination port for initiating the first negotiation request.

[0136] In some optional implementations of this embodiment, the number of incremental work processes is consistent with the number of existing work processes.

[0137] In some optional implementations of this embodiment, the live service hot restart processing device 800 further includes:

[0138] The redundant storage unit is configured to store the media playback information of the live stream included in the second negotiation response in any surviving working process and a preset second storage cluster.

[0139] In some optional implementations of this embodiment, the live service hot restart processing device 800 further includes:

[0140] The media play request obtaining unit is configured to obtain corresponding media play information from the second storage cluster in response to the incremental process not being completely created and failing to obtain corresponding media play information from the working process through the first protocol request.

[0141] This embodiment exists as an apparatus embodiment corresponding to the above-mentioned method embodiment. The live service hot restart processing apparatus provided by this embodiment controls the load balancing service to receive the first negotiation request sent by the incremental client after the hot restart through the new port, and forwards the first negotiation request received through the new port to the new UDP port of the incremental work process through the preset port mapping rule, thereby distinguishing it from the old port used by the existing client to send the keep-alive request to the load balancing service before the hot restart. Similarly, the load balancing service will also forward the keep-alive request received through the old port to the old UDP port of the existing work process through the port mapping rule, that is, the new and old clients communicate with the different UDP ports of the new and old work processes through different ports of the load balancing service, so that the existing client will not perceive the incremental work process based on the new port and the new UDP port for communication, but will continue to locate the original communicating existing work process through the existing work process that communicates using the old port and the old UDP port. Therefore, the process positioning operation will not cause an error due to the change in the number of processes that cannot be located through consistent hashing, thereby ensuring that the existing client can still continue to obtain the live data stream after the live service is hot restarted.

[0142] According to an embodiment of the present disclosure, the present disclosure also provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the live broadcast service hot restart processing method described in any of the above embodiments can be implemented when the at least one processor executes them.

[0143] According to an embodiment of the present disclosure, the present disclosure further provides a readable storage medium, which stores computer instructions, and the computer instructions are used to enable a computer to implement the live broadcast service hot restart processing method described in any of the above embodiments when executed.

[0144] According to an embodiment of the present disclosure, the present disclosure also provides a computer program product, which, when executed by a processor, can implement the live broadcast service hot restart processing method described in any of the above embodiments.

[0145] Figure 9 A schematic block diagram of an example electronic device 900 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are provided as examples only and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0146] like Figure 9 As shown, the device 900 includes a computing unit 901, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 902 or a computer program loaded from a storage unit 908 into a random access memory (RAM) 903. Various programs and data required for the operation of the device 900 can also be stored in the RAM 903. The computing unit 901, the ROM 902, and the RAM 903 are connected to each other via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0147] Various components in the device 900 are connected to the I / O interface 905, including an input unit 906, such as a keyboard, a mouse, etc.; an output unit 907, such as various types of displays, speakers, etc.; a storage unit 908, such as a magnetic disk, an optical disk, etc.; and a communication unit 909, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 909 allows the device 900 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0148] The computing unit 901 can be a variety of general-purpose and / or specialized processing components with processing and computing capabilities. Some examples of the computing unit 901 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units that run machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 901 performs the various methods and processes described above, such as the live service hot restart processing method. For example, in some embodiments, the live service hot restart processing method can be implemented as a computer software program that is tangibly contained in a machine-readable medium, such as the storage unit 908. In some embodiments, part or all of the computer program can be loaded and / or installed on the device 900 via the ROM 902 and / or the communication unit 909. When the computer program is loaded into the RAM 903 and executed by the computing unit 901, one or more steps of the live service hot restart processing method described above can be performed. Alternatively, in other embodiments, the computing unit 901 can be configured to perform the live service hot restart processing method by any other appropriate means (e.g., by means of firmware).

[0149] Various embodiments of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0150] The program code for implementing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when the program code is executed by the processor or controller, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0151] In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, device or equipment. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0152] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0153] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0154] A computer system may include a client and a server. The client and server are generally remote from each other and typically interact via a communication network. The client-server relationship arises through computer programs running on the respective computers and establishing a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, a host product within a cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosts and virtual private server (VPS) services.

[0155] According to the technical solution of the embodiment of the present invention, the load balancing service is controlled to receive the first negotiation request sent by the incremental client after the hot restart through the new port, and the first negotiation request received through the new port is forwarded to the new UDP port of the incremental work process through the preset port mapping rule, so as to distinguish it from the old port used by the existing client to send the keep-alive request to the load balancing service before the hot restart. Similarly, the load balancing service will also forward the keep-alive request received through the old port to the old UDP port of the existing work process through the port mapping rule, that is, the new and old clients communicate with the different UDP ports of the new and old work processes through different ports of the load balancing service, so that the existing client will not perceive the incremental work process based on the new port and the new UDP port, but will continue to locate the original communicating existing work process through the existing work process that communicates using the old port and the old UDP port. Therefore, the process positioning operation will not cause an error due to the change in the number of processes and the inability to locate the error through consistent hashing, thereby ensuring that the existing client can still continue to obtain the live data stream when the live service is hot restarted.

[0156] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions disclosed in this disclosure can be achieved. This is not a limitation herein.

[0157] The above specific embodiments do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure shall be included within the scope of protection of this disclosure.

Claims

1. A live broadcast service hot restart processing method, wherein: Applied to load balancing services, including: Receiving a first negotiation request initiated by an incremental client to a first port; wherein the incremental client is a client that initiates the live broadcast request after a hot restart of the live broadcast service, the live broadcast service creates multiple incremental working processes after the hot restart, and the first negotiation request is used to negotiate a session traversal method for network address translation; According to a preset port mapping rule, the first negotiation request received from the first port is forwarded to the first User Datagram Protocol (UDP) port of any surviving incremental work process, and the live data stream received from the incremental work process is returned to the incremental client; wherein the port mapping rule records the mapping relationship between different ports of the load balancing service and different UDP ports of the work process; According to the port mapping rule, the keep-alive request received from the second port is forwarded to the second UDP port of the matching existing work process, and the live data stream received from the existing work process is returned to the corresponding existing client; wherein, the keep-alive request is initiated by the existing client, the existing client is a client that existed before the hot restart, and the existing work process is a work process that provides the live data stream to the corresponding existing client before the hot restart.

2. The method according to claim 1, wherein The live broadcast service is a low-latency live broadcast service that uses UDP to reduce the delay to no more than a first preset duration, and the first negotiation request is a request for negotiation interaction of a session traversing the STUN protocol for network address translation based on UDP.

3. The method according to claim 1, wherein Before performing the hot restart, the method further includes: receiving a first negotiation request initiated by the existing client to the second port; forwarding the first negotiation request received from the second port to the second UDP port of any existing working process in a surviving state according to the port mapping rule; receiving a live data stream returned by the existing working process to which the first negotiation request is sent; The live data stream is returned to the corresponding existing client; wherein the existing client sends the keep-alive request once every second preset time interval after first receiving the live data stream.

4. The method according to claim 3, wherein: Before receiving the first negotiation request initiated by the existing client to the second port, the method further includes: receiving a second negotiation request initiated by the existing client to the third port; wherein the second negotiation request is used to negotiate whether the actual audio and video format used by the live data stream is an audio and video format supported by the client; According to the port mapping rule, the second negotiation request is sent to the third UDP port of any surviving working process in a surviving state; receiving a second negotiation response returned by the existing work process to which the second negotiation request is sent; A second negotiation response with the second port attached is returned to the existing client; wherein the second port is used to instruct the existing client to use the second port as a destination port for initiating the first negotiation request.

5. The method according to claim 1, further comprising: In response to a time interval from receiving the last keep-alive request exceeding a second preset time length, destroying the corresponding existing work process; In response to the last existing working process being destroyed, the second port is used as a standby destination port for receiving the first negotiation request initiated after the next hot restart.

6. The method according to claim 5, further comprising: In response to the live broadcast service performing the hot restart again, according to a preset selection rule, a target destination port is selected as the destination port of the first negotiation request initiated by the incremental client from the port pool that records all the backup destination ports.

7. The method according to claim 6, wherein: The preset selection rule includes any of the following: Sequential selection, random selection, remainder selection, and round-robin selection.

8. The method according to claim 1, wherein Before receiving the first negotiation request initiated by the incremental client to the first port, the method further includes: In response to the load balancing service not completing the live detection operation for all the incremental work processes, receiving a second negotiation request initiated by the incremental client to the third port; wherein the second negotiation request is used to negotiate whether the actual audio and video format used by the live data stream is an audio and video format supported by the client; According to the port mapping rule, the second negotiation request is sent to the third UDP port of any existing working process in a surviving state; receiving a second negotiation response returned by the existing work process to which the second negotiation request is sent; A second negotiation response with the first port attached is returned to the incremental client; wherein the first port is used to instruct the incremental client to use the first port as a destination port for initiating the first negotiation request.

9. The method according to claim 1, wherein Before receiving the first negotiation request initiated by the incremental client to the first port, the method further includes: In response to the load balancing service completing the live detection operation for all the incremental work processes, receiving a second negotiation request initiated by the incremental client to the third port; wherein the second negotiation request is used to negotiate whether the actual audio and video format used by the live data stream is an audio and video format supported by the client; According to the port mapping rule, the second negotiation request is sent to the third UDP port of any incremental work process in a surviving state; receiving a second negotiation response returned by the incremental work process to which the second negotiation request is sent; A second negotiation response with the first port attached is returned to the incremental client; wherein the first port is used to instruct the incremental client to use the first port as a destination port for initiating the first negotiation request.

10. The method according to claim 1, wherein The number of the incremental work processes is consistent with the number of the existing work processes.

11. The method according to any one of claims 4, 8-9, further comprising: The media playback information of the live stream included in the second negotiation response is stored in any working process in a live state and a preset second storage cluster.

12. The method according to claim 11, wherein Also includes: In response to the incremental work process not being completely created and the corresponding media playback information being unable to be obtained from the work process through the first negotiation request, the corresponding media playback information is obtained from the second storage cluster.

13. A live broadcast service hot restart processing device, wherein: Applied to load balancing services, including: A first request receiving unit is configured to receive a first negotiation request initiated by an incremental client to a first port; wherein the incremental client is a client that initiates a live broadcast request after a hot restart of the live broadcast service, the live broadcast service creating multiple incremental working processes after the hot restart, and the first negotiation request is used to negotiate a session traversal method for network address translation; The first negotiation request forwarding and live data stream returning unit is configured to forward the first negotiation request received from the first port to the first User Datagram Protocol (UDP) port of any surviving incremental work process according to a preset port mapping rule, and return the live data stream received from the incremental work process to the incremental client; wherein the port mapping rule records the mapping relationship between different ports of the load balancing service and different UDP ports of the work process; The keep-alive request forwarding and live data stream return unit is configured to forward the keep-alive request received from the second port to the second UDP port of the matching existing work process according to the port mapping rule, and return the live data stream received from the existing work process to the corresponding existing client; wherein, the keep-alive request is initiated by the existing client, the existing client is a client that existed before the hot restart, and the existing work process is a work process that provides live data stream to the corresponding existing client before the hot restart.

14. The device according to claim 13, wherein The live broadcast service is a low-latency live broadcast service that uses UDP to reduce the delay to no more than a first preset duration, and the first negotiation request is a request for negotiation interaction of a session traversing the STUN protocol for network address translation based on UDP.

15. The apparatus according to claim 13, further comprising: A second request receiving unit is configured to receive a first negotiation request initiated by the existing client to the second port before performing the hot restart; A first forwarding unit is configured to forward the first negotiation request received from the second port to a second UDP port of any existing working process in a surviving state according to the port mapping rule; A first data stream receiving unit is configured to receive a live data stream returned by the existing working process to which the first negotiation request is sent; The first data stream returning unit is configured to return the live data stream to the corresponding existing client; wherein, the existing client will send the keep-alive request once every second preset time interval after first receiving the live data stream.

16. The apparatus according to claim 15, further comprising: A third request receiving unit is configured to receive a second negotiation request initiated by the existing client to the third port before receiving the first negotiation request initiated by the existing client to the second port; wherein the second negotiation request is used to negotiate whether the actual audio and video format used by the live data stream is an audio and video format supported by the client; A second forwarding unit is configured to send the second negotiation request to a third UDP port of any surviving working process in a surviving state according to the port mapping rule; a first response receiving unit, configured to receive a second negotiation response returned by the existing working process to which the second negotiation request is sent; The first response returning unit is configured to return a second negotiation response with the second port attached to it to the existing client; wherein the second port is used to instruct the existing client to use the second port as a destination port for initiating the first negotiation request.

17. The apparatus according to claim 13, further comprising: a destroying unit configured to, in response to a time interval from receiving the last keep-alive request exceeding a second preset time length, destroy the corresponding existing working process; The backup destination port reserve unit is configured to use the second port as a backup destination port for receiving the first negotiation request initiated after the next hot restart in response to the last of the existing working processes being destroyed.

18. The apparatus according to claim 17, further comprising: The destination port selection unit is configured to select, in response to the live broadcast service performing the hot restart again, a target destination port as the destination port of the first negotiation request initiated by the incremental client from a port pool recording all the backup destination ports according to a preset selection rule.

19. The device according to claim 18, wherein The preset selection rule includes any of the following: Sequential selection, random selection, remainder selection, and round-robin selection.

20. The apparatus according to claim 13, further comprising: The fourth request receiving unit is configured to, before receiving the first negotiation request initiated by the incremental client to the first port, receive a second negotiation request initiated by the incremental client to the third port in response to the load balancing service not completing the live detection operation for all the incremental work processes; wherein the second negotiation request is used to negotiate whether the actual audio and video format used by the live data stream is an audio and video format supported by the client; A third forwarding unit is configured to send the second negotiation request to a third UDP port of any existing working process in a surviving state according to the port mapping rule; A second response receiving unit is configured to receive a second negotiation response returned by the existing working process to which the second negotiation request is sent; The second response returning unit is configured to return a second negotiation response with the first port attached to it to the incremental client; wherein the first port is used to instruct the incremental client to use the first port as a destination port for initiating the first negotiation request.

21. The apparatus according to claim 13, further comprising: a fifth request receiving unit configured to, before receiving the first negotiation request initiated by the incremental client to the first port, receive a second negotiation request initiated by the incremental client to the third port in response to the load balancing service having completed the live detection operation for all the incremental work processes; wherein the second negotiation request is used to negotiate whether the actual audio and video format used by the live data stream is an audio and video format supported by the client; a fourth forwarding unit configured to send the second negotiation request to a third UDP port of any incremental work process in a surviving state according to the port mapping rule; a third response receiving unit, configured to receive a second negotiation response returned by the incremental work process to which the second negotiation request is sent; The third response returning unit is configured to return the second negotiation response with the first port attached to it to the incremental client; wherein the first port is used to instruct the incremental client to use the first port as the destination port for initiating the first negotiation request.

22. The apparatus according to claim 13, wherein The number of the incremental work processes is consistent with the number of the existing work processes.

23. The apparatus according to any one of claims 16, 20-21, further comprising: The redundant storage unit is configured to store the media playback information of the live stream included in the second negotiation response in any working process in a surviving state and a preset second storage cluster respectively.

24. The device according to claim 23, wherein Also includes: The media playback request acquisition unit is configured to acquire corresponding media playback information from the second storage cluster in response to the incremental work process not being completely created and the corresponding media playback information being unable to be acquired from the work process through the first negotiation request.

25. An electronic device comprising: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the live service hot restart processing method described in any one of claims 1-12.

26. A non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable the computer to execute the live broadcast service hot restart processing method according to any one of claims 1 to 12.

27. A computer program product, comprising a computer program, which, when executed by a processor, implements the steps of the live broadcast service hot restart processing method according to any one of claims 1 to 12.

Images