CN114143569A

CN114143569A - Webpage recording and live broadcasting method and system

Info

Publication number: CN114143569A
Application number: CN202111370362.6A
Authority: CN
Inventors: 马宇坚; 韦松; 徐延霞; 罗士新
Original assignee: Juhaokan Technology Co Ltd
Current assignee: Juhaokan Technology Co Ltd
Priority date: 2021-11-18
Filing date: 2021-11-18
Publication date: 2022-03-04
Anticipated expiration: 2041-11-18
Also published as: CN114143569B

Abstract

The application provides a webpage recording and live broadcasting method and system. The method comprises the following steps: the method comprises the steps that a scheduling server receives a service request instruction of a user and heartbeat information of a plurality of recorded live broadcast servers, wherein the service request instruction comprises a service type; the heartbeat information comprises the service state of the recording live broadcast server. And the dispatching server responds to the service request instruction and allocates the first server to execute the task according to the service type and the service state. And if the scheduling server detects that the first server is abnormal, allocating the task executed by the first server to the second server to execute the task. By the method, when the recording live broadcast server is abnormal, the scheduling server can switch other recording live broadcast servers to execute tasks in time according to heartbeat information sent by the recording live broadcast server, so that the webpage media resource content can be accurately and completely recorded, the webpage recording and live broadcast failures are prevented, and the use experience of a user is improved.

Description

Webpage recording and live broadcasting method and system

Technical Field

The application relates to the technical field of intelligent equipment, in particular to a webpage recording and live broadcasting method and system.

Background

With the continuous development of internet technology, webpage recording and live broadcasting are popular on various network platforms and widely applied to scenes such as conference live broadcasting, teaching live broadcasting, game live broadcasting and entertainment live broadcasting. By utilizing the characteristics of intuition, rapidness, rich content, strong interactivity, unlimited region and the like of the internet, the media content such as documents, videos and the like displayed by the webpage in the display equipment such as a computer, a smart phone and the like can be recorded, and a user can play back and watch the recorded webpage media content in real time or through the display equipment of the client.

The existing method for recording and live broadcasting the webpage media asset content is realized by calling recording and live broadcasting services. Only one recording and live broadcast service is allocated to a recording and live broadcast task of one media asset content of a webpage, and once the recording and live broadcast service is abnormal, the recording and live broadcast of the webpage media asset content can be stopped, so that the webpage media asset content cannot be accurately and completely recorded, and the recording and live broadcast of the webpage media asset content fails.

Disclosure of Invention

The application provides a webpage recording and live broadcasting method and system, and aims to solve the problem that the existing webpage recording and live broadcasting method and server cannot guarantee complete and accurate recording of webpage media content.

In a first aspect, the present application provides a method for recording and live broadcasting a web page, including:

the method comprises the steps that a scheduling server receives a service request instruction of a user and heartbeat information of a plurality of recorded live broadcast servers, wherein the service request instruction comprises a service type; the heartbeat information comprises a service state of the recording live broadcast server, and the service state comprises an idle state and a non-idle state;

the scheduling server responds to the service request instruction, and allocates a first server to execute a task according to the service type and the service state, wherein the first server is a recording live broadcast server in an idle state;

and if the scheduling server detects that the first server is abnormal, the task executed by the first server is distributed to a second server to execute the task, and the second server is another idle recording live server.

In a second aspect, the present application further provides a method for recording and live broadcasting a web page, including:

the method comprises the steps that a recording live broadcast server sends heartbeat information to a scheduling server, wherein the heartbeat information comprises a service state of the recording live broadcast server, and the service state comprises an idle state and a non-idle state;

the recording live broadcast server receives and executes a task distributed by a scheduling server, and the task is distributed by the scheduling server according to a service request instruction of a user and the service state;

and if the recording live broadcast server detects that the abnormality occurs, distributing the task to other recording live broadcast servers in idle states for execution.

In a third aspect, the present application further provides a web page recording and live broadcasting system, which includes a scheduling server and a recording live broadcasting server, wherein,

the scheduling server is configured to: receiving a service request instruction of a user and heartbeat information of a plurality of recording live broadcast servers, wherein the service request instruction comprises a service type; the heartbeat information comprises a service state of the recording live broadcast server, and the service state comprises an idle state and a non-idle state; responding to the service request instruction, and allocating a first server to execute a task according to the service type and the service state, wherein the first server is a recording live broadcast server in an idle state; if the first server is detected to be abnormal, distributing the task executed by the first server to a second server to execute the task, wherein the second server is another idle recording live broadcast server;

the recorded live broadcast server is configured to: sending heartbeat information to the scheduling server, receiving and executing a task distributed by the scheduling server, wherein the task is distributed by the scheduling server according to a service request instruction of a user and the service state; and if the abnormal condition is detected, distributing the task to other recording live broadcast servers in idle states.

According to the technical scheme, the webpage recording and live broadcasting method and system are provided. The system comprises a scheduling server and a recording live broadcast server. The recording live broadcast server transmits the service state of the recording live broadcast server in a mode of sending heartbeat information to the scheduling server. The scheduling server selects the recording live broadcast server in an idle state to execute tasks according to the service request sent by the user and the service state of the recording live broadcast server, and the recording live broadcast server can execute tasks such as webpage recording and live broadcast according to the service request. When the recording live broadcast server is abnormal, the scheduling server can timely switch other recording live broadcast servers in idle states to execute tasks according to heartbeat information sent by the recording live broadcast server, so that accurate and complete recording of webpage media resource contents can be guaranteed, failure of webpage recording and live broadcast is prevented, and use experience of users is improved.

Drawings

In order to more clearly explain the technical solution of the present application, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious to those skilled in the art that other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 is a usage scenario of a display device in an embodiment of the present application;

FIG. 2 is a schematic diagram illustrating a data interaction relationship between a display device and a server in an embodiment of the present application;

FIG. 3 is a schematic diagram illustrating a communication connection relationship between a display device and a server according to an embodiment of the present application;

fig. 4 is a schematic structural diagram of a web page recording and live broadcasting system in an embodiment of the present application;

fig. 5 is an interaction timing diagram of a connection between a scheduling server and a recording live broadcast server in the embodiment of the present application;

fig. 6 is an interaction timing diagram of a recording live broadcast server executing tasks in the embodiment of the present application;

FIG. 7 is a flowchart illustrating a method for handling an exception by a dispatch server according to an embodiment of the present application;

fig. 8 is a schematic flowchart of a method for processing an exception by a recording live broadcast server in the embodiment of the present application;

fig. 9 is an interaction timing diagram of merging and uploading files by a recording live server in the embodiment of the present application;

fig. 10 is an interaction timing diagram of merging and uploading files by a recording live server according to another embodiment of the present application;

fig. 11 is an interaction timing diagram of merging and uploading files by a recording live server according to another embodiment of the present application;

fig. 12 is an interaction timing diagram of a user client viewing recorded and live broadcast in the embodiment of the present application.

Detailed Description

To make the purpose and embodiments of the present application clearer, the following will clearly and completely describe the exemplary embodiments of the present application with reference to the attached drawings in the exemplary embodiments of the present application, and it is obvious that the described exemplary embodiments are only a part of the embodiments of the present application, and not all of the embodiments.

It should be noted that the brief descriptions of the terms in the present application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of the present application. These terms should be understood in their ordinary and customary meaning unless otherwise indicated.

The terms "first," "second," "third," and the like in the description and claims of this application and in the above-described drawings are used for distinguishing between similar or analogous objects or entities and not necessarily for describing a particular sequential or chronological order, unless otherwise indicated. It is to be understood that the terms so used are interchangeable under appropriate circumstances.

The terms "comprises" and "comprising," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a product or apparatus that comprises a list of elements is not necessarily limited to all elements expressly listed, but may include other elements not expressly listed or inherent to such product or apparatus.

The term "module" refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and/or software code that is capable of performing the functionality associated with that element.

Fig. 1 is a schematic diagram of an operation scenario between a display device and a control apparatus according to an embodiment. As shown in fig. 1, a user may operate the display apparatus 200 through the smart device 300 or the control device 100.

In some embodiments, the control apparatus 100 may be a remote controller, and the communication between the remote controller and the display device includes an infrared protocol communication or a bluetooth protocol communication, and other short-distance communication methods, and controls the display device 200 in a wireless or wired manner. The user may input a user instruction through a key on a remote controller, voice input, control panel input, etc., to control the display apparatus 200.

In some embodiments, the smart device 300 (e.g., mobile terminal, tablet, computer, laptop, etc.) may also be used to control the display device 200. For example, the display device 200 is controlled using an application program running on the smart device.

In some embodiments, the display device 200 may also be controlled in a manner other than the control apparatus 100 and the smart device 300, for example, the voice command control of the user may be directly received by a module configured inside the display device 200 to obtain a voice command, or may be received by a voice control device provided outside the display device 200.

In some embodiments, as shown in fig. 2, fig. 2 is a schematic diagram of a data interaction relationship between a display device and a server in an embodiment of the present application, and in use, the display device 200 may communicate with the server 400 to implement data interaction. In order to realize data interaction between the display apparatus 200 and the server 400, the display apparatus 200 needs to establish a communication connection with the server 400. For example, the display apparatus 200 and the server 400 may each be connected to the internet and transfer interactive data between the display apparatus 200 and the server 400 through an internet transfer protocol.

In some embodiments, it is desirable to have means for establishing a communication connection on the display device 200 and the server 400, respectively. Fig. 3 is a schematic diagram of a communication connection relationship between a display device and a server in an embodiment of the present application, as shown in fig. 3, a communicator 220 may be disposed in the display device 200, a communication module 410 may be disposed in the server 400, and the communicator 220 and the communication module 410 may simultaneously support at least one same communication mode to establish the communication connection relationship. For example, the communicator 220 on the display apparatus 200 includes a fiber interface, so that the display apparatus 200 can be connected to a network through the fiber interface; meanwhile, the communication module 410 of the server 400 also includes an optical fiber interface, and may also be connected to a network through the optical fiber interface to implement a communication connection between the display device 200 and the server 400.

It should be noted that the display device 200 and the server 400 may also establish a communication connection relationship by using other connection manners. Such as wired broadband, wireless local area network, cellular network, bluetooth, infrared, radio frequency communication, etc.

The display device 200 and the server 400 may be in a "many-to-one" connection relationship, that is, a plurality of display devices 200 may establish a communication connection with the same server 400, so that the server 400 may provide services for the plurality of display devices 200. A "many-to-many" connection relationship may be established between the display apparatuses 200 and the servers 400, that is, the plurality of display apparatuses 200 may establish a communication connection with the plurality of servers 400, so that the plurality of servers 400 can provide different services for the display apparatuses 200, respectively. Obviously, in an individual application scenario, there may also be a "one-to-one" connection relationship between the display devices 200 and the servers 400, i.e., one server 400 exclusively serves one display device 200.

In some scenes such as conference live broadcast, teaching live broadcast, game live broadcast and entertainment live broadcast, a user can record and live broadcast the webpage media asset content in the display device 200 through the server 400. The existing method for recording and live broadcasting the webpage media asset content is realized by calling recording and live broadcasting services. Only one recording and live broadcasting service is allocated to a recording and live broadcasting task of one media asset content of a webpage, but if the recording and live broadcasting service is closed, or the recording and live broadcasting service is disconnected with the webpage to be recorded, or a plurality of recording and live broadcasting services record and broadcast the same media asset content in the webpage at the same time, the recording and live broadcasting of the media asset content of the webpage fails.

In order to ensure that the content of the webpage media assets can be recorded completely and accurately and improve the use experience of a user, a webpage recording and live broadcasting system is provided in some embodiments of the application. Referring to fig. 4, fig. 4 is a schematic structural diagram of a web page recording and live broadcasting system in an embodiment of the present application, as shown in fig. 4, the system includes: dispatch server and a plurality of live broadcast server of recording. The recording live broadcast server can provide recording service, live broadcast service, file merging service, file uploading service and the like. It should be noted that the scheduling server and the live recording server in the embodiment of the present application may be disposed in electronic devices such as a display device and a terminal, or may be independently disposed as a server device, which is not specifically limited in this application.

Referring to fig. 5, fig. 5 is an interaction timing diagram illustrating a connection between a scheduling server and a live recording server in an embodiment of the present application, and as shown in fig. 5, before a live recording server performs recording and live broadcasting services on a web page, it first needs to register in the scheduling server and establish a connection. Then, the recording live broadcast server feeds back information such as the service state of the recording live broadcast server to the scheduling server in a mode of sending heartbeat information to the scheduling server, so that the scheduling server can distribute tasks according to the service state of the recording live broadcast server. The specific implementation method comprises the following steps S101-S103:

s101, the recording live broadcast server sends registration information to a scheduling server, wherein the registration information comprises a local IP of the server.

Because the webpage recording and live broadcasting system comprises the plurality of recording live broadcasting servers, the recording live broadcasting servers need to be registered in the scheduling server before being used and connected with the scheduling server for convenience of management. Specifically, the recording live broadcast server sends registration information to the scheduling server, wherein the registration information includes a local IP of the recording live broadcast server. Because each recording live broadcast server has an independent IP address, the scheduling server can identify according to the IP address and distinguish different recording live broadcast servers so as to manage the recording live broadcast servers.

And S102, the scheduling server receives the registration information sent by the recording live broadcast server and verifies and registers according to the local IP.

And if the scheduling server passes the verification registration, the scheduling server establishes connection with the recording live broadcast server and sends heartbeat interval time to the recording live broadcast server. The heartbeat interval time is used for determining the frequency of sending heartbeat information by the recording live broadcast server, and may be, for example, 1 second, 5 seconds, 10 seconds, and the like. And if the heartbeat interval time is 1 second, the recording live broadcast server sends heartbeat information every 1 second. The shorter the heartbeat interval time is, the higher the frequency of recording heartbeat information sent by the live broadcast server is, and the more timely and accurate the information fed back by the live broadcast server is. The longer the heartbeat interval time is, the lower the frequency of recording heartbeat information sent by the live broadcast server is, the less resources consumed by the server is, and the lower the energy consumption is. The specific heartbeat interval is determined according to the actual application condition of the server, and the heartbeat interval time is not specifically limited by the application.

And S103, after receiving the heartbeat interval, the recording live broadcast server starts to send heartbeat information to the scheduling server at the heartbeat interval.

It should be noted that, the heartbeat mechanism in the embodiment of the present application refers to: after the two devices are connected, whether the two devices are still connected effectively is judged by sending information at a certain frequency. For example, after the device a and the device B establish a connection, there may be a long time when there is no data communication between the device a and the device B. Theoretically, the connection between device a and device B is always kept connected, but in practice it is difficult to know what failure occurs if an intermediate node. Even, some nodes (firewalls) automatically disconnect connections without data interaction within a certain time. At this time, it is necessary to send heartbeat information between the device a and the device B for determining whether the device a and the device B still maintain valid connection.

There are various ways of sending heartbeat information between devices, taking device a and device B as an example, the device a may send heartbeat information to device B, and the device B may determine whether the device a keeps an effective connection according to the heartbeat information. Or the device B may send heartbeat information to the device a, and the device a determines whether the device B maintains the valid connection according to the heartbeat information. For example, first, the device a sends heartbeat information to the device B, and then the device B sends heartbeat information to the device a after receiving the heartbeat information sent by the device a, so as to implement that the device a and the device B mutually judge whether to keep effective connection.

The heartbeat information may include fixed information or dynamic information. In this embodiment of the present application, the heartbeat information includes: and recording local IP and service state information of the live broadcast server. The local IP of the recording live broadcast server is used for the scheduling server to identify the identity of the recording live broadcast server, and the service state information is used for the scheduling server to judge whether the recording live broadcast server is in a working state or an idle state so as to be convenient for the scheduling server to carry out allocation management on the recording live broadcast server.

In an exemplary implementation manner, recording heartbeat information sent by a live broadcast server specifically includes: global Service ID (Global session code), Task ID (Task code), Service ID (traffic code), and Status (Status). The Global Service ID is generated by the scheduling server and indicates a Global session number currently serviced by the server. The Task ID and the Service ID can be generated by a scheduling server or a user through a Service platform system. The Task ID is used for distinguishing different Service platform systems, and the Service ID is used for distinguishing different tasks, such as recording, live broadcasting, file merging or file uploading. The Task currently executed by the recording live broadcast server can be determined by Global Service ID, and can also be determined by Task ID and Service ID together.

The Status is used for reflecting the current service state of the recording live broadcast server, and different numbers are added behind the Status to indicate different states. For example, Status 0 indicates that the recording live server is currently in an idle state, i.e., has no processing task. At this time, the Global Service ID, Task ID, and Service ID are all null strings. Status 1 indicates that the recording live server is recording. Status 2 indicates that recording is suspended by the recording live server. Status 3 indicates that the live broadcast server is recorded in the file merging process. Status 4 indicates recording in the live server file upload. Status5 indicates that the recording live broadcast server finishes reporting.

For example, when recording the heartbeat information sent by the live broadcast server, the heartbeat information is: global Service ID, Task ID, and Service ID are all empty strings, Status 0. Namely, the recorded live broadcast server is in an idle state, and can accept new tasks.

The heartbeat information may be sent at certain heartbeat intervals, i.e. at certain frequencies, or may be sent in other regular or other manners.

In some embodiments, when the service state of the recording live broadcast server changes, the heartbeat information can be immediately sent to the scheduling server without being sent at a heartbeat interval. Therefore, the recording live broadcast server can timely and accurately feed back the service state of the recording live broadcast server to the scheduling server, so that the scheduling server can manage according to the state fed back by the recording live broadcast server.

After the recording live broadcast server is connected with the scheduling server, the scheduling server can distribute tasks such as recording, live broadcast and the like to the recording live broadcast server in an idle state according to a user service request instruction received by the service platform system and service state information of the recording live broadcast server. And after receiving the tasks sent by the scheduling server, the recording live broadcast server executes and completes the corresponding tasks. Referring to fig. 6, fig. 6 is an interaction timing chart of a recording live broadcast server executing tasks in the embodiment of the present application, and as shown in fig. 6, the specific method includes the following steps S201 to S205:

s201, a scheduling server receives a service request instruction of a user, wherein the service request instruction comprises a service type and a service parameter.

In some embodiments, the web page recording and live broadcasting system provided by the present application further includes a service platform. And the user inputs a service request instruction through the service platform, and the service platform sends the service request instruction to the scheduling server. The service platform can be arranged in electronic equipment such as display equipment and the like, and can also be independently arranged as a device.

In some embodiments, taking the case that the user needs a recording service and a live broadcast service as examples, the service types in the service request instruction include: recording, live broadcasting and the like. The service parameters in the service request instruction specifically include: recording and live broadcasting request ID, webpage url, window size (resolution), recording and live broadcasting video frame rate, recording and live broadcasting video code rate, live broadcasting stream pushing url address, recording and live broadcasting result callback url, uploading cloud storage request and other information.

And the recording and live broadcast request ID is a task code selected by a user. The webpage url is a link address of a webpage to be recorded and live broadcast. The window size (resolution), the frame rates of the recorded and live video, and the code rates of the recorded and live video are all specific parameters of recording and live broadcasting. The recording and live broadcasting type is the recording service, the live broadcasting service or the recording and live broadcasting service selected by the user. And the live broadcast stream push url address is used for recording a link address during live broadcast stream push. And the recording and live result callback url is used for feeding back the link address of the recording and live result. And the uploading cloud storage request is used for judging whether the recorded file needs to be uploaded to the cloud storage.

S202, the scheduling server allocates a free-state live recording server, namely the first server, according to the recording and live broadcasting types in the service request instruction and the service state information of the live recording server.

For example, the services include a recording live broadcast server a, a recording live broadcast server B, a recording live broadcast server C, and a recording live broadcast server D. The heartbeat information sent by the recording live broadcast server A comprises Status 0, namely, the recording live broadcast server A is in an idle state. The heartbeat information sent by the recording live broadcast server B comprises Status 1, namely, the recording live broadcast server B is in a recording state. The heartbeat information sent by the recording live broadcast server C includes Status 2, which means that the recording live broadcast server C is in a recording suspension state. The heartbeat information sent by the recording live broadcast server D comprises Status 4, namely, the recording live broadcast server D is in a file uploading state. When the user selects the recording service in the service request instruction received by the scheduling server, the scheduling server selects a recording live broadcast server capable of executing the recording task according to the service state information sent by the recording live broadcast server.

In some embodiments, in order to ensure the accuracy of the recorded live broadcast server in executing the task, only the recorded live broadcast server in Status 0 is used as the recorded live broadcast server in the idle state, and can be allocated to execute the recorded task. That is, only the recording live server in a fully idle state may be allocated to perform the recording task. In this case, in connection with the example given above, only recording live server a is in the service state Status of Status 0. Therefore, the scheduling server allocates the recording live broadcast server a to execute the recording task, that is, the recording live broadcast server a is the first server.

In some embodiments, in order to improve the operating efficiency of the server and save operating resources, the recording live broadcast server may be allocated to execute the recording task as long as the recording live broadcast server is not in the service states of Status 1 and Status 2, that is, as long as the recording live broadcast server is not in the recording state and the recording pause state, the recording live broadcast server is considered to be in the idle state. That is, the recording live broadcast server can perform other recording tasks even in the service states of Status 3 (in file merge), Status 4 (in file upload), and Status5 (end of report). In this case, in connection with the above example, since the recording live broadcast server a is in the service state of Status 0, the recording live broadcast server D is in the service state of Status 4. Therefore, the scheduling server may allocate the recording live broadcast server a or the recording live broadcast server D to perform the recording task, that is, the recording live broadcast server a or the recording live broadcast server D may be the first server.

S203, the first server executes the task according to the service request.

The service request instruction comprises: recording and live broadcast request ID, webpage url, window size (resolution), recording and live broadcast video frame rate, and recording and live broadcast video code rate are taken as examples. The recording live broadcast server can execute corresponding tasks according to the recording and live broadcast request IDs and open a webpage to be recorded and live broadcast according to a webpage url. And recording and live-broadcasting video frame rates and recording and live-broadcasting video code rates according to the window size (resolution), and finally generating a recording file.

In an exemplary implementation manner, the recording File generated by the recording live broadcast server is an NFS (Network File System) File. The NFS file system is one of the current mainstream heterogeneous platform shared file systems, and is mainly applied to the UNIX environment. By using NFS, users and programs can access files on remote systems as they do to local files, enabling the nodes of each computer to conveniently use resources on the web as they do local resources. In other words, NFS can be used for remote access and sharing of network files in different types of computers, operating systems, network architectures, and transport protocol execution environments. The NFS transport protocol is used for file access and shared communication between servers and clients, thereby enabling clients to remotely access data stored on a storage device. Therefore, in this embodiment, the recorded file generated by the live broadcast server is recorded as an NFS file, so that the server efficiently manages the recorded shared file.

In an exemplary implementation, the NFS file generated by the recording live broadcast server is stored in a NAS (Network Attached Storage). The NAS is a device connected to a network and having a data storage function, and is also called a "network storage". It is a dedicated data storage server. The NAS takes data as a center, thoroughly separates storage devices from servers, and centrally manages the data, thereby releasing bandwidth, improving performance, reducing total cost of ownership, and protecting investment. The cost is far lower than using server storage, and the efficiency is far higher than server storage.

In order to improve the system performance and uninterrupted user access, the NAS adopts specialized operating systems for accessing network files, and the operating systems support both standard file access and corresponding network protocols, so that the NAS technology can meet specific user requirements. For example, when some enterprises need to deal with the problem of rapid data growth or solve the system limitation caused by mutually independent working environments, a new generation of NAS technology can be adopted to solve the problems by using a centralized network file access mechanism and sharing, so as to achieve the purposes of reducing the system management cost and improving the data backup and recovery functions.

In some embodiments, the NFS file further comprises: and recording the service state of the live broadcast server. The file recorded by the recording live broadcast server also comprises service states of the recording live broadcast server, such as recording, recording pause or file merging. Therefore, the live recording server can conveniently judge the current state according to the service state in the recorded NFS file. Particularly, after the recording live broadcast server is abnormally restarted, the recording live broadcast server can quickly acquire the service state before the abnormality according to the NFS file.

In some embodiments, the same task can be assigned to only one recording live broadcast server for execution. Therefore, when Global Service ID, Task ID and Service ID in the heartbeat information sent by a recording live broadcast server are not empty, it means that the recording live broadcast server is assigned a Task. If the scheduling server receives the heartbeat information, and the same Global Service ID, Task ID and Service ID are found after inquiry, the fact that other recorded live broadcast servers execute the Task is indicated. At this time, the scheduling server sends result error information (for example, result. code is not 0) to the recording live broadcast server. And stopping executing the task after the recording live broadcast server receives the result error information. Therefore, the situation that one task is executed by a plurality of recorded live broadcast servers can be prevented.

And S204, live streaming of the recorded file to the CDN by the first server according to the live streaming url address.

Live broadcast push streaming is a process of transmitting a recorded file packaged in an acquisition stage to a network, namely transmitting a video signal of a live broadcast site to the network. Live streaming firstly requires that recorded files such as audio and video data and the like are packaged by using a transmission protocol to become streaming data. Common Live Streaming protocols include RTSP (Real Time Streaming Protocol), RTMP (Real Time Messaging Protocol), HLS (HTTP Live Streaming, adaptive bitrate Streaming Protocol based on HTTP), and the like.

Audio and video data and other recording files are encapsulated through a transmission protocol, and after the audio and video data and other recording files are converted into streaming data, the streaming data is pushed to a Network end through a certain Quality of Service (Qos) algorithm, and the streaming data is distributed through a Content Delivery Network (CDN). The CDN is an intelligent virtual network constructed on the basis of the existing network, and by means of edge servers deployed in various places and functional modules of load balancing, content distribution, scheduling and the like of a central platform, a user can obtain required content nearby, network congestion is reduced, and the access response speed and hit rate of the user are improved.

The basic principle of the CDN is to widely adopt various cache servers, distribute the cache servers to a region or a network where user access is relatively concentrated, when a user accesses a website, point the user access to a cache server that is closest to and works normally, and directly respond to a user request by using a global load technology.

The CDN can avoid bottlenecks and links on the internet that may affect the data transmission speed and stability, so that the content transmission is faster and more stable. By placing node servers at various positions of the network to form a layer of intelligent virtual network on the basis of the existing internet, the CDN system can redirect the request of a user to a service node closest to the user in real time according to network flow, connection of each node, load condition, distance to the user, response time and other comprehensive information. The method aims to enable the user to obtain the required content nearby, solve the problem of congestion of the Internet network and improve the response speed of the user for accessing the website.

S205, the scheduling server receives the end instruction of the user, sends the end instruction to the first server, and the first server ends the task according to the end instruction. The first server sends task end information to the scheduling server after ending the service,

in some embodiments, the user inputs the end instruction through the service platform, and the service platform sends the end instruction to the scheduling server. And after receiving the task ending information, the scheduling server sends a service result callback url to the service platform so as to inform a user of ending the task through the service platform.

In the process of executing tasks such as recording, live broadcasting and the like, if an abnormal condition occurs, the scheduling server distributes the task executed by the first server to other recording live broadcasting servers with idle service states. Therefore, when a certain recording live broadcast server is abnormal, for example, the recording live broadcast server is closed, the recording live broadcast server is disconnected from the scheduling server, and the condition that the heartbeat information sent by the recording live broadcast server is overtime is caused. The scheduling server can reallocate the tasks to other idle recording live broadcast servers to execute in time, and smooth completion of the tasks is guaranteed.

In some embodiments, the scheduling server determines whether the first server continues to execute the task allocated before the interruption of the connection according to the interval between the two adjacent heartbeat messages. Referring to fig. 7, fig. 7 is a flowchart illustrating a method for handling an exception by a dispatch server in an embodiment of the present application, as shown in fig. 7, the method includes the following steps S301 to S304:

s301: and the scheduling server acquires the receiving interval time for receiving the two adjacent heartbeat information.

Under normal conditions, the first server continuously sends heartbeat information to the scheduling server at heartbeat intervals. When the first server is disconnected from the dispatching server in the abnormal condition, the first server stops sending heartbeat information to the dispatching server. And when the first server is restarted, the heartbeat information with the service state being idle is directly sent to the scheduling server. And the dispatching server records a receiving moment each time the first server receives the heartbeat information sent by the first server, and the receiving moments are subtracted from each other to obtain the receiving interval time of the two adjacent heartbeat information.

S302: and the scheduling server judges whether the receiving interval time is less than the preset first heartbeat timeout time.

In some embodiments, the user may preset a first heartbeat timeout period, and the scheduling server determines, according to the first heartbeat timeout period, whether to re-allocate the task executed before the abnormal first server is disconnected to the abnormal first server. The first heartbeat timeout time is usually set to be 3 to 5 heartbeat interval times, and the user can set the first heartbeat timeout time according to the actual application situation, which is not specifically limited in the present application.

S303: and if the receiving interval time is less than the preset first heartbeat timeout time, the scheduling server continuously distributes the task executed before the first server is disconnected to the first server.

In some embodiments, if the receiving interval time is less than the preset first heartbeat timeout time, it indicates that the first server has been restarted quickly after being disconnected, the service function is resumed, and the task allocated before the connection is interrupted can be continuously executed, and the scheduling server continuously allocates the task executed before the connection is interrupted by the first server to the first server.

S304: and if the receiving interval time is greater than or equal to the preset first heartbeat timeout time, the scheduling server distributes the task executed before the interruption connection of the recording live broadcast server to other idle recording live broadcast servers, namely a second server.

In some embodiments, if the receiving interval time is greater than or equal to the preset first heartbeat timeout time, it indicates that the time for disconnecting the recording live broadcast server is too long, and in order to ensure the successful completion of the task, the scheduling server may allocate the task executed by the abnormal recording live broadcast server to other recording live broadcast servers in an idle state. And the abnormal recording live broadcast server waits for the scheduling server to distribute other tasks. In some embodiments, the scheduling server may also allocate the tasks executed by the abnormal recording live broadcast server to other recording live broadcast servers which are not in the recording (Status 1) and recording pause (Status 2) service states. The above two idle state conditions are described in detail above, and are not described herein.

In some embodiments, the recording live broadcast server may also automatically determine whether an abnormal condition occurs, and determine whether to continue to execute the task according to the interruption time. Referring to fig. 8, fig. 8 is a schematic flowchart illustrating a method for processing an exception by a recording live broadcast server in an embodiment of the present application, and as shown in fig. 8, the method for processing an exception by the recording live broadcast server includes the following steps S401 to S404:

s401, when the first server and the scheduling server are restarted after the connection is interrupted, the first server obtains the time of the interrupted connection.

In some embodiments, if abnormal conditions such as power-off of the device, shutdown of the device, or failure in pulling of the service process occur in the live recording server, the live recording server may be disconnected from the scheduling server. The first server can be restarted by the user operating the power-off and shutdown device or the first server pulling the service process again. When the first server is restarted, the first server acquires the time for interrupting the connection. Specifically, the time when the first server disconnects and the time when the first server reestablishes the connection are recorded in the first server, and the time when the first server disconnects is subtracted from the time when the first server reestablishes the connection to obtain the time when the first server disconnects.

S402, the first server judges whether the connection interruption time is less than a preset second heartbeat timeout time.

In some embodiments, the user may preset a second heartbeat timeout period, and the first server determines, according to the second heartbeat timeout period, whether to continue to execute the task allocated before the interrupted connection after the first server is restarted. The second heartbeat timeout time is usually set to be 3 to 5 heartbeat interval times, and the user can set the second heartbeat timeout time according to the actual application situation, which is not specifically limited in the present application.

And S403, if the connection interruption time is less than the preset second heartbeat timeout time, the first server continues to execute the task distributed before the connection interruption.

In some embodiments, if the time for interrupting the connection is less than the preset second heartbeat timeout time, it indicates that the first server has been restarted quickly after being disconnected, and the task allocated before the interrupted connection can be continuously executed. In an alternative implementation, the first server may obtain the task information from the NFS file recorded before the disconnection, and continue to perform the task.

S404, if the connection interruption time is greater than or equal to the preset second heartbeat timeout time, the first server sends heartbeat information with an idle service state to the scheduling server, the task distributed before the connection interruption is not executed any more, and the scheduling server waits for other tasks to be distributed.

In some embodiments, if the connection interruption time is greater than or equal to the preset second heartbeat timeout time, which indicates that the first server is disconnected for too long, in order to ensure that the task is completed successfully, the scheduling server may allocate the task executed by the abnormal first server to another recording live server in an idle state (Status 0). The first server sends heartbeat information with an idle Service state to the scheduling server, for example, heartbeat information with Global Service ID, Task ID and Service ID being all null character strings, Status 0 is sent. The first server waits for the dispatch server to assign additional tasks. In some embodiments, the scheduling server may also allocate the task executed by the first server with the abnormality to other recording live broadcast servers which are not in the recording (Status 1) and recording pause (Status 2) service states. The descriptions of the two cases are given above, and are not repeated herein.

It should be noted that, in order to ensure the integrity of the NFS file recorded by the task and prevent the NFS file recorded by the same task from being repeatedly processed or other recorded live broadcast servers cannot use the NFS file, the first server does not need to process the NFS file recorded before interruption after restarting, so that other recorded live broadcast servers can process the NFS file conveniently, and the task is guaranteed to be completed smoothly.

In some embodiments, in order to improve the reliability of the operation of the scheduling server, a service request instruction input by a user, heartbeat information sent by a recording live broadcast server, and each task allocation information are stored in a local file of the scheduling server. Therefore, even if the scheduling server is in abnormal conditions such as power failure and faults, the heartbeat information and the task allocation information sent by the recorded live broadcast server before restarting can be obtained according to the local file after the scheduling server is restarted. Specifically, the service request instruction includes: recording and live broadcasting request ID, webpage url, window size (resolution), recording and live broadcasting video frame rate, recording and live broadcasting video code rate, recording and live broadcasting type, live broadcasting push flow url address, recording and live broadcasting result callback url, uploading cloud storage request and other service parameters. The heartbeat information sent by the recording live broadcast server comprises information of executing tasks and service states of the recording live broadcast server. For example, it may include: global Service ID (Global session code), Task ID (Task code), Service ID (Service code), and Status (Service Status). The task allocation information includes: the system comprises a task and a recording live broadcast server for executing the task. For example, a Task may be determined according to parameters such as Global Service ID (Global session code), Task ID (Task code), and Service ID (Service code), and a live recording server executing the Task may be determined according to a local IP of the live recording server.

In some embodiments, in order to further improve the reliability of the file saved by the scheduling server, the scheduling server may save information, such as a service request instruction input by a user, heartbeat information sent by a recording live broadcast server, and assignment information of each task, in the shared file NFS file.

In some practical application scenarios, if a user wants to pause recording and live broadcasting in the process of executing tasks such as recording and live broadcasting by a recording and live broadcasting server, a pause instruction is input through a service platform. And after receiving the pause instruction of the user, the service platform sends the pause instruction to the scheduling server, the scheduling server sends the pause instruction to the recording live broadcast server, and the recording live broadcast server responds to the pause instruction to pause the recording. At this time, the recording live broadcast server is in a tentative recording state, namely, a Status 2 state.

When the recording live broadcast server is in a service suspension state, if a user wants to continue the service, a recovery instruction can be input through the service platform. And after receiving a recovery instruction of the user, the service platform sends the recovery instruction to the scheduling server, the scheduling server sends the recovery instruction to the recording live broadcast server, and the recording live broadcast server responds to the recovery instruction to recover service. At this time, the service state of the recording live broadcast server is changed from the tentative recording state to the recording state, that is, from the Status 2 state to the Status 1 state.

In some embodiments, after the recording live broadcast server finishes the service, if the recording is suspended and resumed, or the recording is interrupted abnormally in the recording live broadcast server, or the recording live broadcast server switches to other recording live broadcast servers to record abnormally, the recording live broadcast server may record to generate a plurality of recording files, and at this time, the recording live broadcast server needs to merge the plurality of recording files to obtain one recording file. And recording a service state, namely a Status 3 state, of the live broadcast server during file merging.

Referring to fig. 9, fig. 9 is an interaction timing diagram of merging files and uploading files of the recording live broadcast server in the embodiment of the present application, and as shown in fig. 9, after the recording live broadcast server merges to obtain one recording file, it is determined whether the recording file needs to be uploaded for cloud storage according to whether an upload cloud storage request is included in a service request instruction. And if the service request instruction comprises an uploading cloud storage request, the recording live broadcast server uploads the recording file to the cloud storage. At this time, the recording live broadcast server is in a file uploading state, namely a Status 4 state. And after the uploading end service of the recording live broadcast server is finished, uploading end information is sent to the scheduling server, and then the scheduling server sends an uploading result callback url to the service platform according to the uploading end information so as to inform a user that the file uploading is finished through the service platform. On the contrary, if the service request instruction does not include the request for uploading the cloud storage, the recording live broadcast server does not need to upload the recording file to the cloud storage.

In some embodiments, please refer to fig. 10, fig. 10 is an interaction timing diagram of merging and uploading files by a recording live broadcast server in another embodiment of the present application, as shown in fig. 10, in order to prevent an abnormality of the recording live broadcast server. Whether the recorded files are combined or not and whether the recorded files are uploaded to the cloud storage can be judged by the scheduling server and distributed to the recording live broadcast server in an idle service state for execution, and the method specifically comprises the following steps:

s501, after the scheduling server receives the task end information of the recording live broadcast server, the scheduling server judges whether a plurality of recording files exist, and then the scheduling server sends a file merging instruction and the names of the recording files needing to be merged to the recording live broadcast server.

And S502, the recording live broadcast server merges the recording files corresponding to the file names according to the merging file instruction.

And S503, after the merging of the recording live broadcast servers is finished, sending merging end information to the scheduling server.

And S504, after receiving the merging end information, the scheduling server judges whether the recording file needs to be uploaded for cloud storage according to whether the service request instruction comprises an uploading cloud storage request.

And S505, if the service request instruction comprises an uploading cloud storage request, the scheduling server sends an uploading file instruction to the recording live broadcast server.

And S506, the recording live broadcast server uploads the combined recording file to cloud storage according to the file uploading instruction.

And S507, the recording live broadcast server sends uploading end information to the scheduling server.

S508, the scheduling server sends an uploading result to the service platform and calls back the url so as to inform the user of the completion of the file uploading through the service platform.

In some embodiments, please refer to fig. 11, fig. 11 is an interaction timing chart of merging and uploading files by a recording live broadcast server in another embodiment of the present application, as shown in fig. 11, in order to improve the operating efficiency of the server. After judging whether the recorded files are combined and whether the recorded files are uploaded to the cloud storage, the scheduling server can send a file combining instruction and a file uploading instruction to the recorded live broadcast server at the same time. Therefore, the scheduling server does not need to wait until the recorded live broadcast server is finished, and then judges whether the recorded file needs to be uploaded to the cloud storage, so that the operating efficiency of the server is improved.

In some embodiments, please refer to fig. 12, fig. 12 is an interaction timing chart of a user client viewing recording and live broadcasting in the embodiment of the present application, and as shown in fig. 12, when the user wants to view recording and live broadcasting, the user viewing client may be used to obtain a recording and live broadcasting address from a service platform. And the user watching client watches the recording and the live broadcasting through the CDN according to the recording and live broadcasting addresses. If the recording file is uploaded and stored in the cloud storage, the CDN may return to the source through the cloud storage to obtain the recording file.

Finally, it should be noted that: the above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

The foregoing description, for purposes of explanation, has been presented in conjunction with specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the embodiments to the precise forms disclosed above. Many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles and the practical application, to thereby enable others skilled in the art to best utilize the embodiments and various embodiments with various modifications as are suited to the particular use contemplated.

Claims

1. A webpage recording and live broadcasting method is characterized by comprising the following steps:

2. The method of claim 1, wherein the step of the dispatch server assigning the task executed by the first server to a task executed by a second server if the first server is detected to be abnormal comprises:

the scheduling server acquires a receiving interval time, wherein the receiving interval time is the time for receiving two adjacent heartbeat messages sent by the first server;

the scheduling server judges whether the receiving interval time is greater than or equal to a preset first heartbeat timeout time or not;

and if the receiving interval time is greater than or equal to a preset first heartbeat timeout time, the scheduling server distributes the task executed by the first server to the second server.

3. The method of claim 1, wherein the step of receiving heartbeat information of a plurality of recorded live servers by the scheduling server further comprises:

the scheduling server receives registration information sent by the recording live broadcast server, wherein the registration information comprises a local IP;

the scheduling server registers the recording live broadcast server according to the local IP;

and the scheduling server sends heartbeat interval time to the registered recording live broadcast server.

4. A webpage recording and live broadcasting method is characterized by comprising the following steps:

5. The method as claimed in claim 4, wherein if the recorded live broadcast server detects that the abnormality occurs, the step of allocating the task to other recorded live broadcast servers in idle states to execute includes:

if the recording live broadcast server is disconnected with the scheduling server, when the recording live broadcast server is connected with the scheduling server again, the recording live broadcast server acquires the connection interruption time;

the recording live broadcast server judges whether the connection interruption time is greater than or equal to a preset second heartbeat timeout time;

and if the connection interruption time is greater than or equal to a preset second heartbeat timeout time, the recording live broadcast server sends heartbeat information of which the service state is an idle state to the scheduling server.

6. The method of claim 4, wherein the step of the first server sending heartbeat information to the dispatch server is preceded by the step of:

the recording live broadcast server sends registration information to the scheduling server, wherein the registration information comprises a local IP;

the recording live broadcast server receives heartbeat interval time sent by the scheduling server;

and the recording live broadcast server sends heartbeat information to the scheduling server according to the heartbeat interval time.

7. The method according to any one of claims 4-6, wherein the service request instruction includes a webpage address and a service parameter, and the step of the recording live broadcast server performing the task includes:

the recording live broadcast server opens a target webpage according to the webpage address;

and the recording live broadcast server performs webpage recording and/or live broadcast service on the target webpage according to the service parameters to generate a recording file.

8. The method of claim 7, wherein the service parameter comprises a live streaming address, and the step of generating the recording file by the recording live server further comprises:

and the recording live broadcast server live broadcasts and streams the recording file to the CDN according to the live broadcast stream pushing address.

9. The method of claim 7, wherein the service parameters further include an upload cloud storage request, and the step of generating the recording file by the recording live broadcast server further includes:

the recording live broadcast server judges whether the number of the recording files is more than one;

if the number of the recorded files is more than one, the recorded live broadcast server merges the recorded files to obtain merged files;

the recording live broadcast server judges whether the service parameters comprise an uploading cloud storage request or not;

and if the service parameters comprise an uploading cloud storage request, the recording live broadcast server uploads the merged file to a cloud storage.

10. The method of claim 7, wherein the service parameters further include an upload cloud storage request, and the step of generating the recording file by the recording live broadcast server further includes:

the recording live broadcast server receives a file merging instruction sent by the scheduling server and the name of the merged recording file;

the recording live broadcast server merges the recording files according to the merging file instruction and the merged recording file name to obtain a merging file;

the recording live broadcast server receives an uploading file instruction sent by the scheduling server;

and the recording live broadcast server uploads the merged file to cloud storage according to the file uploading instruction.

11. A webpage recording and live broadcasting system is characterized by comprising a scheduling server and a recording live broadcasting server, wherein,