Event-based live broadcast guarantee method and system based on dynamic emergency page

Abstract

The present invention discloses a method and system for event-based live broadcast assurance based on a dynamic emergency page. The method comprises: a server side monitors and obtains the abnormal frequency of the live broadcast service response of the live broadcast room in real time, and compares the abnormal frequency with a preset threshold range; if the abnormal frequency falls within the preset threshold range, the server side initiates emergency management for the live broadcast room; the emergency management is used to forward the client user request of the live broadcast room to the emergency page address for continued viewing. The present invention designs a dynamic emergency page and linkage mechanism for event-based live broadcast assurance to meet the demand for normal live broadcast viewing in the first place when an abnormality occurs in the live broadcast service.

Description

Technical Field

[0001] The present invention relates to the technical field of live broadcast emergency guarantee, and in particular to an event-based live broadcast guarantee method and system based on a dynamic emergency page. Background Art

[0002] Live streaming has become a global phenomenon in recent years, especially live broadcasts of major events, attracting enormous audiences. With this surge in traffic, live streaming systems and services are prone to uncontrollable anomalies. Consequently, maintaining the stability of these systems and services is under considerable pressure. When a live streaming system experiences a failure, system designs typically incorporate service circuit breakers or downgrades to ensure live streaming availability. However, these operational measures can be implemented in an untimely manner, leading to secondary errors and, in the worst case, a potential avalanche of service. Crucially, a mechanism should be in place to ensure that the live streaming page remains accessible and the stream remains viewable. To achieve this, systematic considerations are required: how to dynamically generate an emergency page, ensure its constant accessibility, ensure page security, and coordinate backend emergency switches and configuration items for triggering emergencies.

[0003] The live broadcast viewing system architecture diagram without emergency page is as shown in the attached Figure 1 As shown, from the perspective of a viewer entering a live studio, they open the studio address using a mobile phone or PC browser, then sequentially download static resources such as the studio page (S1), access live service information (S2, including information such as the studio introduction and live video stream address), and play the live video stream using a player (S3). In traditional architectures, when high concurrency reaches a bottleneck, the S2 service call link is prone to failure, and the standard studio page will malfunction, resulting in slow or even outright interruption of access requests. Without any emergency response measures, this can lead to serious operational incidents. Specific manifestations may include: being unable to enter the studio page (due to lack of basic studio information); after finally getting in, interactive features are unavailable, but frequent requests continue, leading to persistent backend service issues, which deteriorate further and eventually cause a service outage. Furthermore, page downloads (S1) and live video streams (S3) are typically accelerated by CDNs (static resource CDN and video CDN, respectively) to significantly reduce concurrency and high traffic pressure. Therefore, this invention assumes that S1 and S3 will not fail and focuses solely on S2 failure emergency response.

[0004] The architecture diagram of the live broadcast viewing system of the traditional emergency page is as shown in the attached figure. Figure 2As shown, compared with the architecture without an emergency page, this solution pre-sets an emergency live broadcast room page with downgraded functions. Through the dynamic-to-static tool, only the basic information of the live broadcast room and the live video stream address are statically preset. All other business interactive service call links are disconnected and there is no connection. When the standard live broadcast room encounters an abnormal business call link (S2) or the call times out, it will actively prompt you to jump to the emergency page to continue watching. Therefore, compared with the solution without an emergency page, this solution can solve the problem of continuing to watch the live broadcast through the backup page when there is a problem in the live broadcast room. Although some additional interactive functions are downgraded, it will not cause large-scale complaints about not being able to watch. For example, the invention patent with application number 202010468373.7 discloses a method and system for responding to sudden bursts of live broadcast traffic, including: real-time monitoring and obtaining the abnormal frequency of the live broadcast service response from the live broadcast service backend; when a hot live broadcast viewing request initiated by a user is obtained, the abnormal frequency of the live broadcast service response from the live broadcast service backend is compared with a preset first threshold, and the hot live broadcast viewing request is forwarded to the live broadcast service backend or the proxy unit according to the comparison result. This traditional and popular solution effectively addresses the issue of emergency pages during emergencies. However, it still has several significant drawbacks: The emergency page must be pre-configured for each livestream studio. This makes maintenance extremely difficult with the large number of studios requiring support, making manual maintenance impossible. When a problem occurs, standard livestream studios still have to wait for a service call to time out before jumping to the emergency page. This call, when a known fault exists, accelerates the downtime of backend services. Summary of the Invention

[0005] A brief overview of embodiments of the present invention is provided below to provide a basic understanding of certain aspects of the present invention. It should be understood that the following overview is not an exhaustive overview of the present invention. It is not intended to identify key or important aspects of the present invention, nor is it intended to limit the scope of the present invention. Its purpose is simply to present certain concepts in a simplified form as a prelude to the more detailed description discussed later.

[0006] According to one aspect of the present application, a method for event-based live broadcast assurance based on a dynamic emergency page is provided, comprising: a server side monitoring and obtaining the abnormal frequency of the live broadcast service response of the live broadcast room in real time, and comparing the abnormal frequency with a preset threshold range; if the abnormal frequency falls within the preset threshold range, the server side initiates emergency management for the live broadcast room; the emergency management is used to forward the client user request of the live broadcast room to the emergency page address for continued viewing. Abnormal live broadcast service response is generally due to an excessively large number of requests, which exceeds the tolerance of the live broadcast service response.

[0007] The present invention is provided with emergency management functions for emergency configuration, management, and page generation. Unlike the prior art, the present invention does not provide an interface for back-end business services, but directly dynamically generates a page from the live broadcast room page that is unrelated to the back-end service (completely disconnected). In this way, the service response pressure is unrelated to the back-end and is only related to the CDN, so that the business service backend can still be opened even if it is completely down.

[0008] Furthermore, the emergency management specifically includes:

[0009] The server simulates browser rendering to dynamically generate the emergency page for the live broadcast room and generates the emergency page address; at the same time, it updates the status of the live broadcast room to the emergency state;

[0010] When the client user request detects that the current live broadcast room is in an emergency state and the abnormal frequency of the live broadcast service response is greater than the highest value of the preset threshold range, it jumps to its emergency page address to continue watching.

[0011] In addition, a second emergency page can be prepared in advance according to actual needs. When the live emergency management service also fails, jump to the preset second emergency page address to continue watching.

[0012] The above-mentioned preset threshold is generally a range (with a minimum value and a maximum value), for example, 100-105. If the abnormal frequency is greater than the minimum value of the preset threshold, the preset threshold range is entered and emergency management is initiated. Because the emergency management service needs to dynamically generate the emergency page of this live broadcast room, the emergency page can be generated when the abnormal frequency reaches the minimum value of the preset threshold range. When the abnormal frequency reaches the maximum value of the preset threshold range, the emergency page is directly jumped.

[0013] This application dynamically generates an emergency page for the live broadcast room and generates an emergency page address through browser rendering when the abnormal frequency of the live broadcast service response is within a preset threshold range. Compared with the emergency live broadcast room page in the prior art that only statically presets the basic information of the live broadcast room and the live video stream address, it can maximize the client audience's experience of having a better seamless connection.

[0014] Furthermore, the event-based live broadcast guarantee method also includes: when the abnormal frequency of the live broadcast service response of the live broadcast room is less than the lowest value of the preset threshold range, the status of the live broadcast room is updated to a normal state, and the service data required for the live broadcast of the live broadcast room is restored.

[0015] Furthermore, the browser rendering is simulated to dynamically generate the emergency page of the live broadcast room. Specifically, the server renders the page resources of the live broadcast room and the dynamic information of the live broadcast room (such as the live broadcast room name, basic introduction, video playback stream address, etc.) in one, and then regenerates a static page and uploads it to the resource server. The static page disconnects the data interface obtained by dynamic requests in the page, and directly writes its information to the page after unified acquisition. In this way, the emergency page opened by the audience is a very simple display page, without complex data acquisition logic and high interactive concurrency pressure. The traditional emergency page in the prior art is not a simple emergency page. It is also mixed with many complex data interfaces related to the business.

[0016] Specifically, the emergency page of the live broadcast room is dynamically generated by simulating browser rendering, including: analyzing the original live broadcast room page through code, caching the pure page resources and information acquisition class interface data, and then merging them together to generate a new page, and blocking all calling interfaces with code to prevent them from calling backend services. After the code is blocked, it is merged into the page again, and finally a real-time simulated rendering emergency page is generated. The data interface mainly includes two types of data interfaces: information acquisition class and command class. The command class mainly refers to related interfaces such as addition, modification and deletion.

[0017] Furthermore, the emergency page includes a real-time simulation rendering emergency page and a preset template rendering emergency page. Among them, the real-time simulation rendering emergency page is a dynamic-to-static page, which loads the page data of the current live broadcast room in real time, and after loading the basic information related to the live broadcast room, the final display page is re-staticized into a new set of pages; then all the logic codes for the interactive background request data are disconnected; finally, this static page is persisted and uploaded to the resource server. It solves the problem that the system can quickly generate a set of emergency pages for operation and maintenance emergencies without any emergency measures prepared.

[0018] The preset template renders the emergency page, using some simple and interface-beautified template pages that have been preset in advance for rendering. After merging and rendering the page resources and data, a static page without background interactive logic is generated. The advantage of this emergency page is that it is more suitable for live broadcast rooms that need to be protected, which have high requirements for page aesthetics, user prompt logic, etc., and also have multi-channel backup streams. Even when it is known in advance that the number of viewers far exceeds the bottleneck of the live broadcast system, a customized emergency page can be directly generated through this module without having to wait for problems to occur before ensuring it.

[0019] There is not only one type of emergency page, and simulation rendering is only the most important one among them. It is very effective in emergencies when there is no advance emergency preparation. In addition, according to needs, you can also choose to use some emergency page modules with various functions and various interface styles that are prepared in advance, or you can choose multi-channel backup stream protection. In this application, the emergency page may also include a preset emergency page. This emergency page is a supplement to the first two rendered emergency pages. When the number of viewers exceeds the bottleneck of the live broadcast system by a little bit, but not particularly large, this preset emergency page type can be recommended for functional downgrade. Its advantage is that there is no need to regenerate a set of pages for a single live broadcast room, but a set of live broadcast room pages that always exist and can be used by all live broadcast rooms. It is similar to a standard live broadcast room, including data interaction functions with the background. However, its interactive data only supports the most basic small amount of live broadcast room information data. It needs to consume some resources of the live broadcast system background service.

[0020] The above three types of emergency pages are not a one-to-one choice. You can flexibly choose according to the needs of the scenario at the time, and all three sets of emergency pages can exist at the same time.

[0021] According to another aspect of the present application, there is provided an event-based live broadcast guarantee system based on a dynamic emergency page, comprising:

[0022] An abnormality judgment module, which is used to monitor and obtain the abnormal frequency of the live broadcast service response of the live broadcast room in real time, and compare the abnormal frequency with the preset threshold range; if the abnormal frequency enters the preset threshold range, the server will initiate emergency management for the live broadcast room;

[0023] The emergency management module is used to forward the client user request of the live broadcast room to the emergency page address to continue watching.

[0024] Furthermore, the emergency management module specifically includes:

[0025] Rendering unit: This rendering unit is used to simulate browser rendering to dynamically generate the emergency page of the live broadcast room and generate the emergency page address;

[0026] Live broadcast room status unit: used to update the status of the live broadcast room to emergency state or normal state according to the comparison result of the abnormal frequency of the live broadcast service response and the preset threshold range;

[0027] Jump unit: This jump unit is used to jump to the emergency page address to continue watching when the current live broadcast room is in an emergency state and the abnormal frequency of the live broadcast service response is greater than the highest value of the preset threshold range.

[0028] Event-based live streaming has a strong time-sensitive nature, making it extremely important to ensure the smooth running of major live events. When a live streaming system malfunctions (such as a backend service outage or streaming service anomalies), the live stream must be immediately available for viewing. This invention addresses this issue by designing a dynamic emergency page and linkage mechanism to ensure smooth viewing of the live stream even when an anomaly occurs. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The present invention can be better understood by referring to the following description in conjunction with the accompanying drawings, in which the same or similar reference numerals are used throughout the drawings to represent the same or similar components. The accompanying drawings, together with the following detailed description, are incorporated into and form a part of this specification and are used to further illustrate the preferred embodiments of the present invention and to explain the principles and advantages of the present invention.

[0030] In the picture:

[0031] Figure 1 This is a diagram of the system architecture without an emergency page;

[0032] Figure 2 This is a diagram of the traditional emergency page system architecture;

[0033] Figure 3 This is a schematic diagram of the system architecture of the dynamic emergency page according to an embodiment of the present invention;

[0034] Figure 4 This is a schematic diagram of the live broadcast emergency management backend service-system architecture according to an embodiment of the present invention;

[0035] Figure 5 This is a schematic diagram of the architecture of the emergency page rendering module in the live broadcast room according to an embodiment of the present invention;

[0036] Figure 6 This is the internal process of the real-time simulation rendering module according to an embodiment of the present invention;

[0037] Figure 7 This is the difference between the rendered page and the original page in the embodiment of the present invention. DETAILED DESCRIPTION

[0038] Embodiments of the present invention will be described below with reference to the accompanying drawings. Elements and features described in one drawing or one embodiment of the present invention may be combined with elements and features shown in one or more other drawings or embodiments. It should be noted that for the sake of clarity, the drawings and descriptions omit the representation and description of components and processes that are not relevant to the present invention and are known to those of ordinary skill in the art.

[0039] Event-based live broadcast has a strong time attribute. The guarantee work of major live broadcast activities is extremely important. When the live broadcast system fails (such as background service downtime, stream service abnormality, etc.), it is necessary to ensure that the live broadcast can be carried out on time and watched normally. The present invention designs a dynamic emergency page and linkage mechanism for live broadcast guarantee to meet the demand of watching live broadcast normally in the first time when the live broadcast service is abnormal. Figure 1 and Figure 2 The problem described in the scenario.

[0040] An embodiment of the present invention provides an event-based live broadcast guarantee method based on a dynamic emergency page, which mainly includes triggering conditions and dynamic generation of live broadcast emergency pages, static data of emergency pages, emergency page security guarantee, and a systematic linkage method.

[0041] Among them, the triggering conditions and dynamic generation of the live broadcast emergency page: the server monitors and obtains the abnormal frequency of the live broadcast service response of the live broadcast room in real time, and compares the abnormal frequency with the preset threshold range; if the abnormal frequency enters the preset threshold range, the server initiates emergency management for the live broadcast room;

[0042] Emergency page static data, emergency page security, and systematic linkage methods constitute emergency management services, used to forward client user requests for the live broadcast room to the emergency page address for continued viewing. Abnormal live broadcast service responses are generally due to excessive request volume, exceeding the live broadcast service's response capacity.

[0043] See also Figure 3 Emergency management specifically includes the server simulating browser rendering to dynamically generate the emergency page of the live broadcast room and generate the emergency page address; at the same time, updating the status of the live broadcast room to the emergency state; when the client user request detects that the current live broadcast room is already in an emergency state and the abnormal frequency of the live broadcast service response is greater than the highest value of the preset threshold range, it jumps to its emergency page address to continue watching.

[0044] The live broadcast guarantee system based on the above-mentioned event-based live broadcast guarantee method based on dynamic emergency pages is composed of the following modules: live video stream service module, video CDN module, live broadcast room page static resource service module, static resource CDN module, live broadcast business management back-end service module, standard live broadcast room page module, dynamic emergency live broadcast room page module, and live broadcast emergency management back-end service module.

[0045] From the audience's perspective, the live studio address is opened using a mobile phone or PC browser. In a standard live studio page module, the normal process involves downloading static resources such as the studio page (S1), accessing live business information (S2.2, including information such as the studio introduction and live video stream address), and then playing the live video stream using a player.

[0046] When high concurrency reaches a bottleneck, the S2.2 business call link is prone to failure, and the performance of the standard live broadcast room page will go wrong, resulting in slow requests to enter the live broadcast room or even direct interruption. When an abnormal situation occurs in the standard live broadcast room, a failure message will be sent to the "live broadcast emergency management backend service" module, C1: When the total number of failures reaches a preset threshold, such as 100 times (not too low to prevent some local network problems), the live broadcast emergency management backend service will start to dynamically obtain the live broadcast room information, C2: Simulate browser rendering to dynamically generate the emergency page of this live broadcast room, and then immediately upload it to the "live broadcast room page static resource service" module and cache it in the static CDN. Finally, the status of this live broadcast room is updated to the emergency status to prevent the client from frequently accessing the business management service when a problem has occurred.

[0047] In addition, page downloads (S1 and S4) and live video streaming (S5) are usually accelerated by CDN (the static resource CDN module and the video CDN module, respectively) to significantly reduce concurrency and high-traffic pressure. Therefore, this invention assumes that S1, S4, and S5 will not fail and only focuses on the emergency response of S2.

[0048] When the S2.2 service call link fails, after a short period of time (about 1 minute), the "Live Emergency Management Service" dynamically generates an emergency page for this live broadcast room. After re-entering the live broadcast room, the "Live Emergency Management Backend Service" can be called to detect that the current live broadcast room is already in an emergency state and obtain the newly created emergency page address (S2.1). When the client detects that it is already in an emergency state, it jumps directly to the newly generated emergency page to continue watching (S3). Assuming that the live broadcast emergency management service also fails at this time, if there is a preset emergency page, after the timeout, you can also jump to the default emergency page address to continue watching.

[0049] After entering the dynamically generated emergency page, the page and other static resources are downloaded (S4). Because the page already contains static live broadcast room information and the live video stream playback address, the video stream can be played directly (S5). The emergency page itself has no connection to the live broadcast business management backend service itself. Functional degradation is used to ensure the most important live video playback service.

[0050] The live broadcast emergency management backend service can dynamically create an emergency page and upload it to the static resource server upon system monitoring or manual discovery of problems. System monitoring can be based on the current live broadcast room, the number of client service call failures, and pre-set thresholds. Upon creation, the current live broadcast room status is updated to emergency status.

[0051] When the "Live Business Management Backend Service" experiences an exception, the client relies on the "Live Emergency Management Backend Service" to understand the live broadcast room status. Therefore, this emergency management service must adhere to several principles to maximize its high performance, high concurrency, high stability, and high scalability. These principles include: stateless service, minimal business logic, low hardware resource requirements, pure computing + local memory caching, and quasi-linear horizontal scalability.

[0052] As attached Figure 4 As shown in the figure, the live broadcast emergency management backend service - system architecture diagram describes in detail the internal workflow of the live broadcast emergency management service, which mainly includes the emergency live broadcast room configuration module, failure threshold judgment module, live broadcast room emergency status module, and live broadcast room page rendering module.

[0053] The live studio rendering module is responsible for rendering the live studio's page resources and dynamic information (such as the live studio name, basic introduction, video playback stream address, etc.) on the server side, regenerating a static page and uploading it to the resource server (C2). The static page disconnects the interface for dynamically requested data in the page, and directly writes the information after unified acquisition. In this way, the emergency page opened by the audience is a very simple display page, without complex data acquisition logic and high interactive concurrency pressure.

[0054] There's more than one type of emergency page, and simulated rendering is just one of the most important. It's extremely effective in emergencies when no prior preparation is available. You can also choose from a variety of pre-prepared emergency page modules with various functions and interface styles, or opt for multi-channel backup streams.

[0055] The emergency live broadcast room configuration module is used to configure some configurations for the emergency page generated by the live broadcast room, including default configurations and special configurations for specific live broadcast rooms. For example, the number of failure threshold judgments, the backup stream address of the live broadcast room stream, the emergency page type, etc.

[0056] When the system does not need to automatically sense and the manual interface needs to be used to actively trigger the generation of an emergency page, the "Generate" button in this module can be used to actively generate the specified emergency page (C1.1).

[0057] The failure threshold judgment module is responsible for receiving error logs (C0) indicating abnormalities or timeouts when the client enters the live broadcast room. When the number of log errors in this live broadcast room reaches the set global default threshold or a threshold number set for this live broadcast room, it triggers the real-time generation of an emergency page (C1.2). The type of emergency page generated is determined by the emergency live broadcast room configuration.

[0058] After generating the emergency page, the live broadcast room status needs to be updated (C3) to inform the client that the emergency page is now enabled and that repeated requests to the backend service are no longer necessary. This reduces the concurrency pressure on the server. When the fault is resolved, the live broadcast room status is restored.

[0059] like Figure 5 The figure shows the architecture diagram of the live broadcast room emergency page rendering module. It mainly includes the rendering configuration loading module, real-time simulation rendering module, preset template rendering module and preset template specifying module.

[0060] The rendering configuration loading module is used to preload all required information into the module before rendering, so that it can be used by downstream rendering. This includes page resources of the live broadcast room, basic information data of the live broadcast room, emergency type, emergency configuration information, etc.

[0061] There are three main types of emergency page generation. Strictly speaking, only two types require rendering: real-time simulation rendering and preset template rendering. The other type is a preset emergency page, which can be specified by simply selecting it.

[0062] A real-time simulation rendering module switches from dynamic to static pages, loading the current live studio page in real time. After loading the basic information related to the live studio, the final display page is re-staticized into a new set of pages. The interactive backend data request logic code is then disconnected and a "Too many concurrent users, maintenance in progress" prompt is added, or no prompt is given. Finally, this static page is persisted and uploaded to the resource server. This solves the problem of no emergency measures being prepared, allowing the system to quickly generate a set of emergency pages for operation and maintenance emergencies.

[0063] The preset template rendering module has the same main process logic as the real-time simulation rendering module. It merges and renders the page resources and data to generate a static page without background interactive logic. The difference is that this module does not use the current live broadcast room to simulate the rendering of the page in real time, but uses some simple and interface-beautified template pages that are preset in advance to render. The advantage of this module is that it is more suitable for live broadcast rooms that need to be protected, which have high requirements for the beauty of the page, user prompt logic, etc., and also have multi-channel backup streams. Even when it is known in advance that the number of viewers far exceeds the bottleneck of the live broadcast system, a customized emergency page can be directly generated through this module, and there is no need to wait for problems to occur before ensuring it.

[0064] The Preset Page Designation module complements the previous two rendering modules and is recommended as an emergency page type when the number of viewers exceeds the bottleneck of the live broadcast system by a small but not excessive amount. Its advantage is that there is no need to regenerate a set of pages for each live broadcast room. Instead, a set of live broadcast room pages exists for all live broadcast rooms to use. Similar to a standard live broadcast room, it includes data interaction with the backend. However, its interactive data only supports a small amount of basic live broadcast room information. It consumes some resources from the live broadcast system backend services.

[0065] The above three emergency page types are not a one-to-one choice. You can flexibly choose according to the needs of the scenario at the time, and all three sets of emergency pages can exist at the same time.

[0066] like Figure 6 As shown, the real-time simulation rendering module aims to analyze the original live studio page through code, cache the pure page resources and information acquisition interface data, and then merge them together to generate a new page. It also blocks all call interfaces with code to prevent them from calling backend services. The interface mainly includes two types of data interfaces: information acquisition and command interfaces. The command class mainly refers to interfaces related to adding, modifying, and deleting. After code blocking, it is merged back into the page, and finally a real-time simulation rendering emergency page is generated.

[0067] like Figure 7 As shown, the main difference between the original live page and the real-time simulated rendering emergency page is that the real-time simulated rendering emergency page does not require data from the backend. It is an independent page, independent of the backend service and unaffected by performance bottlenecks or failures of the backend service. The display data is rendered in advance or in real time and static (that is, the data is also part of the page). The original live page, on the other hand, needs to request data from the backend service as usual.

[0068] The present invention is described below with a specific embodiment:

[0069] For a live stream of a hot event, the expected number of viewers is expected to exceed the current concurrent user bottleneck of the live streaming system. This requires a series of operational and maintenance measures to be prepared in advance, including the assumption that if a certain number of concurrent viewers is reached, the live streaming system will crash, making it impossible to access the live streaming room and related interactive data.

[0070] like Figure 4 As shown, enter the live broadcast emergency management background service module in advance, make some configurations related to the emergency service of this live broadcast room, set the failure threshold to 100, and configure and prepare multiple live broadcast video streaming addresses to prevent streaming anomalies and provide redundancy.

[0071] like Figure 5As shown, because this live studio has a higher security level, you can prepare the emergency page using the second preset template in advance. Select an emergency page template and configure the streaming addresses for multiple channels. Choose a style with a simple interface and concise logic. After rendering the generated emergency page, upload it to the resource server for backup.

[0072] The first type is real-time simulation rendering of the emergency page. When a sudden failure occurs during the live broadcast and there is no manual on-site intervention, this emergency page is triggered when the failure count threshold of 100 times is reached.

[0073] Configuration is complete and the live broadcast phase begins.

[0074] like Figure 3 As shown in the figure, from the perspective of the audience entering the live broadcast room, the live broadcast room address is opened using a mobile phone or PC browser. In the standard live broadcast room page module, under normal circumstances, the process is to download static resources such as the live broadcast room page (S1), call the live broadcast service information (S2.2, including information such as the live broadcast room introduction and live broadcast video stream address), and use the player to play the live video stream.

[0075] like Figure 4 As shown, assuming that due to high concurrency, the system design bottleneck is exceeded, resulting in an abnormal S2.2 business call link, which leads to a failure to enter the live broadcast room. Each failure log is recorded by the live broadcast emergency management service (C0). When the number of failures in this live broadcast room reaches the pre-designed threshold of 100 times, the emergency page generation event is triggered (C1.2). The live broadcast room emergency page rendering module is then called to automatically simulate the browser to render the current live broadcast room, merge the live broadcast room static page resources and the live broadcast room dynamic data to generate a new set of static pages, and disconnect all interactive business call logic. Upload to the resource server (C2). The status of this live broadcast room is then updated to the emergency status (C3).

[0076] When the emergency page is generated, viewers who enter the standard live broadcast room, such as Figure 4 As shown, the homepage actively detects whether the live broadcast room is in an emergency state (S2.1). If it detects that it is in an emergency state, it can obtain the address of the currently generated emergency page through this interface. Jump directly to the emergency page just generated (real-time simulation rendering of the emergency page) to continue watching.

[0077] After entering the emergency page, the page is downloaded in sequence (S4). This page already includes all the information related to the live broadcast room (including the live broadcast room name, introduction, streaming address, etc.), and there is no need to call the business interaction interface again for dynamic acquisition. The live broadcast then uses the player to load the live video stream for playback (S5).

[0078] At this point, the emergency response to business interaction failures in the live broadcast system has been completed.

[0079] However, if a video push exception suddenly occurs during a live broadcast, that is, if there is a problem with the S5 video stream, the default real-time simulation rendering emergency page will not be able to provide an emergency response because it only has one playback stream address.

[0080] Therefore, the second emergency type "preset template rendering emergency page" preset before the live broadcast comes into play. Figure 4 As shown, enter the emergency live broadcast room configuration module and adjust the emergency page type of this live broadcast room to "preset template rendering emergency page" through manual triggering (C1.1). This emergency page is a simple live broadcast room page that has been preset and contains 2 live video playback streams, one main and one backup.

[0081] Afterwards, viewers who enter the live broadcast room will be directly redirected to the "pre-set template rendering emergency page" to watch.

[0082] This embodiment explains how to ensure that when both the live service system and the main live video stream have abnormalities, the scene can still be watched through the two emergency page types of "real-time simulation rendering emergency page" and "pre-set template rendering emergency page".

[0083] In addition, the method of the present invention is not limited to being executed in the time sequence described in the specification, and can also be executed in other time sequences, in parallel, or independently. Therefore, the execution order of the method described in this specification does not limit the technical scope of the present invention.

[0084] Although the present invention has been disclosed above through the description of specific embodiments of the present invention, it should be understood that all the above embodiments and examples are illustrative rather than restrictive. Those skilled in the art may devise various modifications, improvements, or equivalents of the present invention within the spirit and scope of the appended claims. Such modifications, improvements, or equivalents should also be considered to be within the scope of protection of the present invention.

Claims

1. An event-based live broadcast guarantee method based on a dynamic emergency page, characterized by: include: The server monitors and obtains the abnormal frequency of the live broadcast service response in the live broadcast room in real time, and compares the abnormal frequency with the preset threshold range; If the abnormal frequency reaches the preset threshold range, the server will initiate emergency management for the live broadcast room; The emergency management is used to forward the client user request of the live broadcast room to the emergency page address for continued viewing; The emergency management specifically includes: The server simulates browser rendering to dynamically generate the emergency page for the live broadcast room and generates the emergency page address; at the same time, it updates the status of the live broadcast room to the emergency state; When the client user requests to detect that the current live broadcast room is in an emergency state and the abnormal frequency of the live broadcast service response is greater than the highest value of the preset threshold range, the user will be redirected to the emergency page address to continue watching; Prepare a second emergency page according to actual needs. When the live emergency management service also fails, jump to the prepared second emergency page address to continue watching.

2. The event-based live broadcast guarantee method according to claim 1, characterized in that: The event-based live broadcast guarantee method also includes: when the abnormal frequency of the live broadcast service response of the live broadcast room is less than the lowest value of the preset threshold range, the status of the live broadcast room is updated to a normal state, and the service data required for the live broadcast of the live broadcast room is restored.

3. The event-based live broadcast guarantee method according to claim 1, characterized in that: The emergency page of the live broadcast room is dynamically generated by simulating browser rendering. Specifically, the server renders the page resources of the live broadcast room and the dynamic information of the live broadcast room two-in-one, regenerates a static page and uploads it to the resource server. The static page disconnects the data interface obtained by dynamic requests in the page, obtains its information uniformly and writes it directly to the page.

4. The event-based live broadcast guarantee method according to claim 1, characterized in that: The emergency page includes a real-time simulation rendering emergency page and a preset template rendering emergency page; The real-time simulation rendering of the emergency page loads the page data of the current live broadcast room in real time, and after loading the basic information related to the live broadcast room, the final display page is re-staticized into a new set of pages; then all the logic codes for the interactive background request data are disconnected; finally, this static page is persisted and uploaded to the resource server; The preset template renders the emergency page, using some simple and interface-beautified template pages preset in advance for rendering, and merges the page resources and data for rendering to generate a static page without background interactive logic.

5. An event-based live broadcast guarantee system based on a dynamic emergency page, characterized by: include: An abnormality judgment module, which is used to monitor and obtain the abnormal frequency of the live broadcast service response of the live broadcast room in real time, and compare the abnormal frequency with the preset threshold range; if the abnormal frequency enters the preset threshold range, the server will initiate emergency management for the live broadcast room; An emergency management module, which is used to forward the client user request of the live broadcast room to the emergency page address to continue watching; The emergency management module specifically includes: Rendering unit: This rendering unit is used to simulate browser rendering to dynamically generate the emergency page of the live broadcast room and generate the emergency page address; Live broadcast room status unit: used to update the status of the live broadcast room to emergency state or normal state according to the comparison result of the abnormal frequency of the live broadcast service response and the preset threshold range; Jump unit: This jump unit is used to jump to the emergency page address to continue watching when the current live broadcast room is in an emergency state and the abnormal frequency of the live broadcast service response is greater than the highest value of the preset threshold range; prepare a second emergency page according to actual needs, and when the live broadcast emergency management service also fails, jump to the prepared second emergency page address to continue watching.

Images