CN114143569B

CN114143569B - Webpage recording and live broadcasting method and system

Info

Publication number: CN114143569B
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: 2024-02-27
Anticipated expiration: 2041-11-18
Also published as: CN114143569A

Abstract

The application provides a webpage recording and live broadcasting method and system. The method comprises the following steps: the scheduling server receives a service request instruction of a user and heartbeat information of a plurality of live broadcast recording servers, wherein the service request instruction comprises a service type; the heartbeat information includes a service status of the recording live server. The scheduling server responds to the service request instruction and distributes the first server to execute tasks according to the service type and the service state. And if the scheduling server detects that the first server is abnormal, the task executed by the first server is distributed to the second server to execute the task. According to the method provided by the application, when the live recording server is abnormal, the scheduling server can timely switch other live recording servers to execute tasks according to the heartbeat information sent by the live recording server, so that the accurate and complete recording of the webpage media resource content is ensured, the webpage recording and live broadcasting failure is 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, web recording and live broadcasting are popular on various network platforms, and are widely applied to scenes such as conference live broadcasting, teaching live broadcasting, game live broadcasting, entertainment live broadcasting and the like. By utilizing the characteristics of visual and quick internet, rich content, strong interactivity, unrestricted region and the like, the method can record the media content such as documents, videos and the like displayed by the web pages in the display equipment such as computers, smart phones and the like, and users can watch the recorded web page media content in real time or in playback through the display equipment of the client.

The existing recording and live broadcasting method of the webpage media asset content is realized by calling recording and live broadcasting service. And only one recording and live broadcasting service is allocated to one media content recording and live broadcasting task of the webpage, and once the recording and live broadcasting service is abnormal, the recording and live broadcasting of the webpage media content can be stopped, so that the webpage media content cannot be accurately and completely recorded, and the recording and live broadcasting of the webpage media content are failed.

Disclosure of Invention

The application provides a webpage recording and live broadcasting method and system, which are used for solving the problem that the existing webpage recording and live broadcasting method and server cannot guarantee complete and accurate webpage media resource content recording.

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

the scheduling server receives service request instructions of users and heartbeat information of a plurality of live broadcast recording servers, wherein the service request instructions comprise service types; the heartbeat information comprises a service state of the recording live broadcast server, wherein the service state comprises an idle state and a non-idle state;

the scheduling server responds to the service request instruction, and distributes a first server to execute tasks according to the service type and the service state, wherein the first server is a live recording 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 live recording server in an idle state.

In a second aspect, the present application further provides a method for recording and 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 live recording server receives and executes tasks distributed by the scheduling server, and the tasks are distributed by the scheduling server according to service request instructions of users and the service states;

and if the recording live broadcast server detects that the abnormality occurs, the task is distributed to other recording live broadcast servers in idle states to be executed.

In a third aspect, the present application further provides a web recording and live broadcasting system, including a scheduling server and a recording live broadcasting server, where,

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

The live recording server is configured to: sending heartbeat information to the scheduling server, receiving and executing tasks distributed by the scheduling server, wherein the tasks are distributed by the scheduling server according to service request instructions of users and the service states; and if the occurrence of the abnormality is detected, the task is distributed to the recording live broadcast servers in other idle states.

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

Drawings

In order to more clearly illustrate the technical solutions of the present application, the drawings that are needed in the embodiments will be briefly described below, and it will be obvious to those skilled in the art that other drawings can be obtained from these drawings without inventive effort.

Fig. 1 is a usage scenario of a display device according to an embodiment of the present application;

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;

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;

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

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

fig. 6 is an interactive timing chart of recording tasks performed by the live broadcast server in the embodiment of the present application;

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

fig. 8 is a flowchart illustrating a method for recording a live server to handle an exception in the embodiment of the present application;

fig. 9 is an interactive timing chart of recording a merging file and an uploading file of a live broadcast server in the embodiment of the present application;

Fig. 10 is an interactive timing chart of recording a merging file and an uploading file of a live broadcast server according to another embodiment of the present application;

fig. 11 is an interactive timing chart of recording a merging file and an uploading file of a live broadcast server according to another embodiment of the present application;

fig. 12 is an interaction timing chart of watching recording and live broadcast by a user client in an embodiment of the present application.

Detailed Description

For purposes of clarity and implementation of the present application, the following description will make clear and complete descriptions of exemplary implementations of the present application with reference to the accompanying drawings in which exemplary implementations of the present application are illustrated, it being apparent that the exemplary implementations described are only some, but not all, of the examples of the present application.

It should be noted that the brief description of the terms in the present application is only for convenience in understanding the embodiments described below, and is not intended to limit the embodiments of the present application. Unless otherwise indicated, these terms should be construed in their ordinary and customary meaning.

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

The terms "comprises," "comprising," and "having," 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 explicitly 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 or/and software code that is capable of performing the function 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 device 200 through the smart device 300 or the control apparatus 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 infrared protocol communication or bluetooth protocol communication, and other short-range communication modes, and the display device 200 is controlled by a wireless or wired mode. The user may control the display device 200 by inputting user instructions through keys on a remote control, voice input, control panel input, etc.

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

In some embodiments, the display device 200 may also perform control 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 through a module configured inside the display device 200 device for acquiring voice commands, or the voice command control of the user may be received through a voice control device configured outside the display device 200 device.

In some embodiments, as shown in fig. 2, 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, where in use, the display device 200 may communicate with the server 400 to implement data interaction. In order to achieve data interaction between the display device 200 and the server 400, the display device 200 needs to establish a communication connection with the server 400. For example, both the display device 200 and the server 400 may be connected to the internet and interactive data may be transferred between the display device 200 and the server 400 via an internet transmission protocol.

In some embodiments, it may be necessary to provide components 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 the embodiment of the present application, as shown in fig. 3, a communicator 220 may be provided in the display device 200, meanwhile, a communication module 410 may be provided in the server 400, and the communicator 220 and the communication module 410 may simultaneously support at least one same communication mode to establish a communication connection relationship. For example, the communicator 220 on the display device 200 includes a fiber optic interface, such that the display device 200 may connect to a network through the fiber optic interface; meanwhile, the communication module 410 of the server 400 also includes an optical fiber interface, and may be connected to a network through the optical fiber interface, so as 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 use other connection methods to establish a communication connection relationship. Such as wired broadband, wireless local area network, cellular network, bluetooth, infrared, radio frequency communications, etc.

A "many-to-one" connection may be between the display device 200 and the server 400, i.e., multiple display devices 200 may establish a communication connection with the same server 400, such that the server 400 may provide services to multiple display devices 200. The display device 200 and the server 400 may also be in a "many-to-many" connection relationship, i.e., the plurality of display devices 200 may establish communication with the plurality of servers 400, so that the plurality of servers 400 may respectively provide different services for the display device 200. It is obvious that in an individual application scenario, there may also be a "one-to-one" connection between the display device 200 and the server 400, i.e. one server 400 is dedicated to serve one display device 200.

In some live conference, live teaching, live game, live entertainment, etc. scenarios, a user may record and live web media asset content in the display device 200 through the server 400. The existing recording and live broadcasting method of the webpage media asset content is realized by calling recording and live broadcasting service. Only one recording and live broadcasting service is allocated to one media content recording and live broadcasting task of the webpage, however, if the recording and live broadcasting service is closed, or the recording and live broadcasting service is disconnected from the webpage to be recorded, or a plurality of recording and live broadcasting services simultaneously record and live broadcast the same media content in the webpage, and other abnormal conditions can cause recording and live broadcasting failure of the media content of the webpage.

In order to ensure that the webpage media resource content can be recorded completely and accurately and improve the use experience of users, a webpage recording and live broadcasting system is provided in some embodiments of the present application. Referring to fig. 4, fig. 4 is a schematic structural diagram of a web recording and live broadcasting system according to an embodiment of the present application, as shown in fig. 4, the system includes: a scheduling server and a plurality of live recording servers. 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, in the embodiment of the present application, the scheduling server and the live recording server may be provided in electronic devices such as a display device and a terminal, or may be provided as a server device independently, which is not specifically limited in this application.

Referring to fig. 5, fig. 5 is an interactive timing chart of connection between the scheduling server and the live recording server in the embodiment of the present application, as shown in fig. 5, before the live recording server records and live broadcasts the web page, the live recording server needs to register in the scheduling server and establish connection. And then, the live recording server feeds back information such as the service state of the live recording 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 live recording 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 server local IP.

Because the webpage recording and live broadcasting system provided by the embodiment of the application comprises a plurality of live recording servers, the live recording servers need to be registered in the scheduling server before use and are connected with the scheduling server for convenience in management. Specifically, the live recording server sends registration information to the scheduling server, wherein the registration information includes the local IP of the live recording server. Because each live recording server has an independent IP address, the scheduling server can identify according to the IP address, and different live recording servers can be distinguished, so that the live recording servers can be managed conveniently.

S102, the scheduling server receives registration information sent by the live recording server, and performs verification registration according to the local IP.

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

S103, after the live broadcast recording server receives the heartbeat interval, the live broadcast recording 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: when two devices are connected, whether effective connection is still maintained is judged by sending information at a certain frequency between the two devices. For example, after a connection is established between device a and device B, there may be a long period of time when there is no data to or from device a and device B. Theoretically, the connection between device a and device B is kept connected all the time, but in practice it is difficult to know if an intermediate node fails. Even some nodes (firewalls) will automatically disconnect connections that have no data interaction for a certain period of time. At this time, heartbeat information needs to be sent between device a and device B to determine whether a valid connection is still maintained between device a and device B.

There are various ways of sending heartbeat information between devices, for example, device a and device B may send heartbeat information to device B by device a, and device B determines whether device a remains effectively connected according to the heartbeat information. The device B may also send heartbeat information to the device a, and the device a determines whether the device B remains actively connected according to the heartbeat information. The device a and the device B may send heartbeat information to each other, for example, first, the device a sends heartbeat information to the device B, then the device B sends heartbeat information to the device a after receiving the heartbeat information sent by the device a, so as to determine whether the device a and the device B keep effective connection with each other.

The heartbeat information can include fixed information or dynamic information. In the embodiment of the present application, the heartbeat information includes: recording local IP and service state information of a live broadcast server. The local IP of the live recording server is used for the scheduling server to identify the identity of the live recording server, and the service state information is used for the scheduling server to judge whether the live recording server is in a working state or an idle state, so that the scheduling server can conveniently distribute and manage the live recording server.

In an exemplary implementation manner, recording heartbeat information sent by the live broadcast server specifically includes: global Service ID (global session code), task ID (Task code), service ID (Service code), status. Global Service ID is generated by the dispatch server, representing the global session number of the server's current service. The Task ID and the Service ID can be generated by a dispatch server and also can be generated by a user through a Service platform system. The Task ID is used to distinguish between different Service platform systems, and the Service ID is used to distinguish between different tasks, such as recording, live broadcast, file merging, file uploading, and the like. The Task currently executed by the live recording server may be determined by Global Service ID, or may be determined by the Task ID and the Service ID together.

The Status is used for reflecting the current service state of the live broadcast server, and different numbers are added after the Status to represent different states. For example, status 0 indicates that the recording live server is currently idle, i.e., has no processing tasks. At this time, global Service ID, task ID, service ID are empty strings. Status 1 indicates that the recording live server is recording. Status 2 indicates recording of the live server recording pause. Status 3 indicates recording live server file merge. Status 4 indicates that the live server file is being recorded in the upload. Status 5 indicates that the recording live server ends reporting.

For example, when recording heartbeat information sent by the live broadcast server is: global Service ID, task ID, service ID are empty strings, status 0. That is, the live recording server is in 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 rules or other ways.

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

After the live broadcast recording server is connected with the scheduling server, the scheduling server can distribute tasks such as recording, live broadcast and the like to the live broadcast recording server in an idle state according to the user service request instruction received by the service platform system and the service state information of the live broadcast recording server. And after the recording live broadcast server receives the task sent by the scheduling server, executing and completing the corresponding task. Referring to fig. 6, fig. 6 is an interactive timing chart of recording tasks performed by the live broadcast server in the embodiment of the present application, 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 recording and live broadcasting system provided by the application further comprises 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 an example that a user needs to record a service or live broadcast a service, the service types in the service request instruction include: recording, live broadcast, etc. The service parameters in the service request instruction specifically include: recording, broadcasting request ID, web page url, window size (resolution), recording, broadcasting video frame rate, recording, broadcasting video code rate, broadcasting push url address, recording, broadcasting result callback url, uploading cloud storage request and other information.

The recording and live broadcast request ID is a task code selected by a user. The web page url is the link address of the web page to be recorded and live broadcast. The window size (resolution), the frame rate of the recorded and live video, and the code rate of the recorded and live video are specific parameters of the recorded and live video. The recording and live broadcast type is a recording service, a live broadcast service or a recording and live broadcast service selected by a user. The live push url address is used for recording the link address of live push. Recording and live broadcasting results call back url to feed back the link address of the recording and live broadcasting results. The uploading cloud storage request is used for judging whether the recorded file needs to be uploaded to cloud storage.

S202, the scheduling server distributes the idle state recording live broadcast server, namely the first server, according to the recording and live broadcast type in the service request instruction and the service state information of the recording live broadcast server.

For example, the services include a live recording server a, a live recording server B, a live recording server C, and a live recording server D. The heartbeat information sent by the live recording server A includes Status 0, namely the live recording server A is in an idle state. The heartbeat information sent by the live recording server B includes Status 1, namely, the live recording server B is in a recording state. The heartbeat information sent by the live recording server C includes Status 2, which indicates that the live recording server C is in a recording suspension state. And 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 the 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, to ensure the accuracy of the recording live server performing the task, only the recording live server of Status 0 may be allocated as the recording live server in the idle state to perform the recording task. That is, only the recording live server in the completely idle state may be allocated to perform the recording task. In this case, in connection with the example cited above, only the recording live server a is in the Status 0 service state. 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 operation efficiency of the server and save operation resources, the recording live server may be allocated to perform the recording task as long as it is not in the service states of Status 1 and Status 2, i.e. the recording live server is not in the recording state and the recording pause state, and is considered to be in the idle state. That is, the recording live server can perform other recording tasks even while in the service states of Status 3 (in file merge), status 4 (in file upload), and Status5 (end report). In this case, in connection with the example set forth above, since the recording live server a is in the service state of Status 0, the recording live server D is in the service state of Status 4. Thus, the scheduling server may allocate the recording live server a or the recording live server D to perform a recording task, i.e. the recording live server a or the recording live server D may be the first server.

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

The service request instruction includes: recording and live broadcasting request ID, web page url, window size (resolution), recording and live broadcasting video frame rate, recording and live broadcasting video code rate are taken as examples. The recording live broadcast server can execute corresponding tasks according to the recording and live broadcast request ID, and opens the webpage to be recorded and live broadcast according to the webpage url. And recording and broadcasting video frame rate according to the window size (resolution), recording and broadcasting video code rate, recording files of corresponding parameters, and finally generating recording files.

In one exemplary implementation, the recording file generated by the recording live server is an NFS (Network File System ) file. NFS file system is one of the current mainstream heterogeneous platform sharing file systems, and is mainly applied in UNIX environment. By using NFS, users and programs can access files on a remote system like local files, enabling nodes of each computer to use resources on the network as conveniently as 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 operating environments. NFS transport protocol is used for file access and shared communication between a server and a client, thereby enabling the client to remotely access data stored on a storage device. Therefore, in this embodiment, the recorded file generated by the live broadcast server is an NFS file, so that the server efficiently manages the recorded shared file.

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

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

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

In some embodiments, the same task can only be allocated to one recording live server for execution. Therefore, when the heartbeat information Global Service ID, task ID, service ID sent by a recording live server is not null, it indicates that the recording live server is assigned a Task. If the scheduling server receives the heartbeat information, the same Global Service ID, task ID and Service ID are found to exist after inquiry, and the Task is indicated to be executed by other live recording servers. At this time, the scheduling server transmits a result error message (e.g., result. Code is not 0) to the recording live server. And stopping executing the task after the recording live broadcast server receives the result error information. In this way, it is possible to prevent a situation in which one task is performed by a plurality of recording live servers.

S204, the first server pushes the live broadcast of the recorded file to the CDN according to the live broadcast push url address.

Live broadcast push flow is the process of transmitting the recorded files packaged in the acquisition stage to the network, namely the process of transmitting video signals of live broadcast sites to the network. Live push streaming firstly needs to encapsulate recorded files such as audio and video data and the like by using a transmission protocol to become streaming data. Typical live push streaming protocols are RTSP (Real Time Streaming Protocol, real-time streaming protocol), RTMP (Real Time Messaging Protocol, real-time messaging protocol), HLS (HTTP Live Streaming, HTTP-based adaptive rate streaming protocol), etc.

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

The basic principle of the CDN is that various cache servers are widely adopted, the cache servers are distributed to areas or networks where user accesses are relatively concentrated, when the user accesses a website, the global load technology is utilized to direct the user accesses to the cache servers which work normally and are closest to the website, and the cache servers directly respond to the user requests.

The CDN can avoid bottlenecks and links on the Internet, which possibly affect the data transmission speed and stability, so that the content transmission is faster and more stable. Through a layer of intelligent virtual network formed by node servers placed everywhere in the network and based on the existing internet, the CDN system can redirect the user's request to the service node nearest to the user in real time according to the network flow and the comprehensive information of the connection of each node, the load condition, the distance to the user, the response time and the like. 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 ending instruction of the user, sends the ending instruction to the first server, and the first server ends the task according to the ending instruction. The first server will send the task end information to the dispatch server after ending the service,

In some embodiments, the user inputs an end instruction through the service platform, which sends the end instruction to the dispatch 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 the task ending through the service platform.

In the process of executing tasks such as recording, live broadcasting and the like, if abnormal conditions occur, the scheduling server distributes the tasks executed by the first server to the recording live broadcasting servers with idle other service states. Thus, when an abnormal situation occurs in a certain recording live broadcast server, for example, the recording live broadcast server is closed, the recording live broadcast server is disconnected with the scheduling server, and the recording live broadcast server sends heartbeat information overtime and the like. The scheduling server can timely reassign the tasks to other idle live recording servers for execution, and smooth completion of the tasks is ensured.

In some embodiments, the scheduling server determines whether the first server continues to perform the task allocated before the connection was interrupted based on the time interval between receiving the adjacent two heartbeat messages. Referring to fig. 7, fig. 7 is a flowchart of a method for processing an exception by a scheduling server according to an embodiment of the present application, as shown in fig. 7, the specific method includes the following steps S301 to S304:

S301: the scheduling server acquires the receiving interval time for receiving the adjacent two heartbeat messages.

Under normal circumstances, the first server will continuously send heartbeat information to the scheduling server at heartbeat interval times. When the first server is disconnected from the scheduling server under abnormal conditions, the first server stops sending heartbeat information to the scheduling server. And after the first server is restarted, the heartbeat information with the idle service state is directly sent to the scheduling server. And the scheduling server records a receiving moment when receiving the heartbeat information sent by the first server every time, and the adjacent two receiving moments are subtracted to obtain the receiving interval time of the adjacent two heartbeat information.

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

In some embodiments, the user presets a first heartbeat timeout period, and the scheduling server determines whether to reassign the task executed before the abnormal first server interrupts the connection to the abnormal first server according to the first heartbeat timeout period. The first heartbeat timeout time is generally set to 3 to 5 heartbeat interval times, and the user can set the first heartbeat timeout time according to practical application conditions, which is not particularly limited in this application.

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

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

S304: 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 recording live server is disconnected to other idle state recording live servers, namely the second server.

In some embodiments, if the receiving interval time is greater than or equal to the preset first heartbeat timeout time, it is indicated that the disconnection time of the recording live broadcast server is too long, and in order to ensure smooth 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. The live server waits for the dispatch server to distribute other tasks. In some embodiments, the scheduling server may also assign tasks performed by the abnormally recorded live server to other recorded live servers that are not in the recording (Status 1) and pause recording (Status 2) service states. The details of the above two idle state cases are described above, and are not repeated here.

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

s401, after the first server and the scheduling server are disconnected and restarted, the first server acquires the time of disconnection.

In some embodiments, if an abnormal situation such as power-off, shutdown or service process pulling failure occurs in the recording live broadcast server, the recording live broadcast server is disconnected from the scheduling server. The first server may be restarted by a user operating the power-off, shutdown device, or by the first server re-pulling the service process. When the first server is restarted, the first server obtains the time when it is disconnected. Specifically, the moment of disconnection and the moment of connection reestablishment are recorded in the first server, and the moment of disconnection is subtracted from the moment of connection reestablishment, so that the time of disconnection of the first server is obtained.

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

In some embodiments, the user presets a second timeout, and the first server determines whether to continue to execute the task allocated before the connection is interrupted after restarting according to the second timeout. The second heartbeat timeout time is usually set to 3 to 5 heartbeat interval times, and the user can set the second heartbeat timeout time according to practical application conditions, which is not particularly limited in this application.

S403, if the connection interruption time is smaller 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 interrupt connection time is less than the preset second heartbeat timeout time, it indicates that the first server has been restarted quickly after the disconnection, and the task assigned before the interrupt connection may be continued to be 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 interrupt connection time is greater than or equal to the preset second heartbeat timeout time, the first server sends heartbeat information with idle service state to the scheduling server, does not execute tasks distributed before interrupt connection, and waits for the scheduling server to distribute other tasks.

In some embodiments, if the connection interruption time is greater than or equal to the preset second heartbeat timeout time, it is indicated that the first server is disconnected too long, and in order to ensure smooth completion of the task, the scheduling server may allocate the task executed by the first server with the exception to other live recording servers in an idle state (Status 0). The first server sends heartbeat information with idle Service Status, for example, heartbeat information with idle character strings, status 0, for example, global Service ID, task ID, and Service ID. The first server waits for the dispatch server to assign other tasks. In some embodiments, the dispatch server may also assign tasks performed by the first server that is experiencing the anomaly to other live recording servers that are not in recording (Status 1) and pause recording (Status 2) service states. The details of the above two cases are described above, and are not repeated here.

It should be noted that, in order to ensure the integrity of the NFS file recorded by the task, the situation that the NFS file recorded by the same task is repeatedly processed or the NFS file cannot be used by other live recording servers is prevented, and the NFS file recorded before interruption does not need to be processed after the first server is restarted, so that the NFS file is processed by other live recording servers, and smooth completion of the task is ensured.

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

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

In some practical application scenarios, if a user pauses recording and live broadcasting in the process of executing tasks such as recording and live broadcasting by the recording and live broadcasting server, a pause instruction is input through a service platform. After receiving a pause instruction of a user, the service platform sends the pause instruction to a scheduling server, the scheduling server sends the pause instruction to a live recording server, and the live recording server pauses recording in response to the pause instruction. At this time, the live recording server is in a tentative recording state, i.e., status 2 state.

When the live recording server is in a suspended service state, if the user wants to continue the service, a resume instruction can be input through the service platform. After receiving the 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 live recording server, and the live recording server responds to the recovery instruction to recover service. At this time, the service state of the live recording 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 live recording server finishes the service, if there is a pause in recording and a resume in recording, or the live recording server has an abnormal interruption in recording, or the live recording server has an abnormal switching of recording of other live recording servers, a plurality of recording files are generated by recording the live recording server, and at this time, the live recording server needs to combine the plurality of recording files to obtain one recording file. And recording the service state of the live broadcast server when the files are combined, namely the Status 3 state.

Referring to fig. 9, fig. 9 is an interactive timing chart of a merging file and an uploading file of a live broadcast recording server in the embodiment of the present application, and as shown in fig. 9, after the live broadcast recording server merges to obtain a recording file, whether the recording file needs to be uploaded and stored in cloud is determined according to whether an uploading cloud storage request is included in a service request instruction. And if the service request instruction comprises a cloud storage uploading request, uploading the recorded file to the cloud storage by the recording live broadcast server. At this time, the live recording server is in the file upload state, i.e., status 4 state. And after the live broadcast server is recorded and the service is finished, uploading finishing 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 finishing information so as to inform a user that the uploading of the file is finished through the service platform. In contrast, 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, referring to fig. 10, fig. 10 is an interactive timing chart of merging files and uploading files of a live recording server according to another embodiment of the present application, as shown in fig. 10, in order to prevent an abnormality in recording the live recording server. Whether the recorded files are combined or not and whether cloud storage is uploaded or not can be judged by the scheduling server and is distributed to the recording live broadcast server in the idle service state for execution, and the specific steps are as follows:

s501, after receiving the task end information of the live recording server, the scheduling server judges that if a plurality of recording files exist, the scheduling server sends a file merging instruction and a recording file name to be merged to the live recording server.

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

S503, after the merging of the live broadcast server is finished, sending merging finishing information to the scheduling server.

And S504, after receiving the merging end information, the scheduling server judges whether the recorded file needs to be uploaded to cloud storage according to whether an uploading cloud storage request is included in the service request instruction.

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

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

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

And S508, the scheduling server sends an uploading result callback url to the service platform so as to inform the user that the uploading of the file is finished through the service platform.

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

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

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution 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 scheme described in the foregoing embodiments can be modified or some or all of the technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the corresponding technical solutions 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 method for recording and broadcasting web pages, comprising:

the scheduling server receives service request instructions of users and heartbeat information of a plurality of live broadcast recording servers, wherein the service request instructions comprise service types; the heartbeat information comprises a service state of the recording live broadcast server, wherein the service state comprises an idle state and a non-idle state; the non-idle state is a recording state and a recording pause state, and the idle state comprises a file merging state and/or a file uploading state;

the scheduling server responds to the service request instruction, and distributes a first server to execute a first task according to the service type and the service state, wherein the first server is a live recording server in an idle state so that the first server can record the first task while executing a current file merging task and/or a file uploading task, and the same task can only be distributed to one live recording server;

The scheduling server determines a first interval time for receiving two adjacent heartbeat messages sent by the first server;

the scheduling server judges whether the first interval time of the receiving is larger than or equal to a preset first heartbeat timeout time; if the first interval time of receiving is greater than or equal to a preset first heartbeat timeout time, namely the first server is abnormal, the scheduling server receives a second interval time sent by the first server, wherein the second interval time is the interrupt connection time acquired by the first server; if the second interval time is smaller than a preset second heartbeat timeout time, the scheduling server continuously distributes the task executed before the first server interrupts connection to the first server; if the second interval time is greater than or equal to a preset second heartbeat timeout time, the scheduling server distributes the first server executing task to the second server executing task, and the scheduling server receives the heartbeat information that the service state is idle and is sent by the first server, so that the first server does not execute the task distributed before the connection is interrupted any more, and waits for the scheduling server to distribute other tasks; and the scheduling server distributes the task executed by the first server to a second server to execute the task, wherein the second server is another live recording server in an idle state so that the second server can record the first task while executing the current file merging task and/or file uploading task.

2. The method of claim 1, wherein the step of the scheduling server receiving heartbeat information for the plurality of live recording servers further comprises:

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

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

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

3. A method for recording and broadcasting web pages, comprising:

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 non-idle state is a recording state and a recording pause state, and the idle state comprises a file merging state and/or a file uploading state;

the method comprises the steps that a first server receives and executes a first task distributed by a scheduling server, wherein the first task is distributed by the scheduling server according to a service request instruction of a user and the service state, the first server is a live recording server in an idle state, so that the first server records the first task while executing a current file merging task and/or a file uploading task, and the same task can only be distributed to one live recording server;

When a first interval time sent by the first server to the scheduling server is greater than or equal to a preset first heartbeat timeout time, namely the first server is abnormal, the first server sends a second interval time to the scheduling server, wherein the second interval time is the interrupt connection time acquired by the first server; when the second interval time is smaller than a preset second heartbeat timeout time, the task executed before the first server is disconnected is continuously distributed to the first server; when the second interval time is greater than or equal to a preset second heartbeat timeout time, the first server executing task is distributed to a second server executing task, and heartbeat information which is sent by the first server and has idle service state is received, so that the first server does not execute tasks distributed before connection interruption, and waits for other tasks to be distributed; the task executed by the first server is distributed to a second server for execution, and the second server is another live recording server in an idle state so that the second server records the first task while executing the current file merging task and/or file uploading task; the first interval time is the time of recording two adjacent heartbeat information sent by the live broadcast server to the scheduling server.

4. The method of claim 3, wherein the step of the recording the live server sending heartbeat information to the scheduling server is preceded by:

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

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

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

5. The method of claim 3 or 4, wherein the service request instruction includes a web page address and a service parameter, and wherein the recording the live server performs the task comprises:

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

and the live recording server carries out webpage recording and/or live broadcasting service on the target webpage according to the service parameters to generate a recording file.

6. The method of claim 5, wherein the service parameters include live push addresses, and wherein the step of recording the live server to generate the recorded file further comprises:

And the live recording server live-broadcasting and pushing the recorded file to the CDN according to the live-broadcasting and pushing address.

7. The method of claim 5, wherein the service parameters further comprise an upload cloud storage request, and wherein the step of recording the live server to generate the recording file further comprises:

the live recording server judges whether the number of the recorded files is larger than one;

if the number of the recorded files is greater than one, the recorded live broadcast server combines a plurality of the recorded files to obtain a combined file;

the live recording 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, uploading the combined file to cloud storage by the live recording server.

8. The method of claim 7, wherein the service parameters further comprise an upload cloud storage request, and wherein the step of recording the live server to generate the recording file further comprises:

the live recording server receives the combined file instruction and the combined recorded file name sent by the scheduling server;

the recording live broadcast server carries out recording file combination according to the file combination instruction and the combined recording file name to obtain a combined file;

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

and uploading the combined file to cloud storage by the live recording server according to the file uploading instruction.

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

the scheduling server is configured to: receiving a service request instruction of a user and heartbeat information of a plurality of live recording servers, wherein the service request instruction comprises a service type; the heartbeat information comprises a service state of the recording live broadcast server, wherein the service state comprises an idle state and a non-idle state; the non-idle state is a recording state and a recording pause state, and the idle state comprises a file merging and/or file uploading state; responding to the service request instruction, and according to the service type and the service state, distributing a first server to execute a first task, wherein the first server is an idle-state recording live broadcast server so that the first server can record the first task while executing a current file merging task and/or a file uploading task, and the same task can only be distributed to one recording live broadcast server; the scheduling server determines a first interval time for receiving two adjacent heartbeat messages sent by the first server;

The scheduling server judges whether the first interval time of the receiving is larger than or equal to a preset first heartbeat timeout time; if the first interval time is greater than or equal to the preset first heartbeat timeout time, namely the first server is abnormal, if the first interval time is less than the preset first heartbeat timeout time, the scheduling server receives a second interval time, and the second interval time is the interrupt connection time acquired by the scheduling server; the scheduling server judges whether the second interval time is smaller than a preset second heartbeat timeout time or not; if the second interval time is smaller than the preset second heartbeat timeout time, the scheduling server continuously distributes the task executed before the first server interrupts the connection to the first server; if the second interval time is greater than or equal to a preset second heartbeat timeout time, the scheduling server distributes the first server executing task to the second server executing task, and the scheduling server receives the heartbeat information that the service state is idle and is sent by the first server, so that the first server does not execute the task distributed before the connection is interrupted any more, and waits for the scheduling server to distribute other tasks; the scheduling server distributes the task executed by the first server to a second server to execute the task, wherein the second server is another live recording server in an idle state so that the second server records the first task while executing the current file merging task and/or file uploading task;

The live recording server is configured to: sending heartbeat information to the scheduling server, receiving and executing tasks distributed by the scheduling server, wherein the tasks are distributed by the scheduling server according to service request instructions of users and the service states; when the first interval time sent by the live recording server to the scheduling server is larger than or equal to the preset first heartbeat timeout time, sending a second interval time to the scheduling server when the first interval time is smaller than the preset first heartbeat timeout time, wherein the second interval time is the interrupt connection time acquired by the first server; when the second interval time is smaller than a preset second heartbeat timeout time, the task executed before the first server is disconnected is continuously distributed to the first server; when the second interval time is greater than or equal to a preset second heartbeat timeout time, the first server executing task is distributed to the second server executing task, the first server sends heartbeat information with idle service state to the scheduling server, the task distributed before connection interruption is not executed any more, and the scheduling server waits for distributing other tasks; the task is assigned to the recording live server in the other idle state.