CDN live broadcast disaster recovery processing method, apparatus and device, and medium

Abstract

The invention provides a disaster recovery processing method and device for CDN live broadcast, equipment and a medium, and relates to the technical field of cloud computing, in particular to the fields of CDN, content delivery networks and live broadcast. According to the specific implementation scheme, a flow quality analysis platform obtains quality data of edge nodes and center nodes from a system log, and fault nodes and types of the fault nodes are determined through a fault recognition model or based on a threshold value range of the quality data. The identified faulty node information is sent to a node configuration platform, generating a configuration block including filters and processing operations. And the configuration block is issued to each node, and the node judges whether the filter is hit or not according to the flow information and executes corresponding disaster recovery processing when the filter is hit. Through the above method, the efficiency and accuracy of fault detection are improved, the manual intervention and troubleshooting time are reduced, the continuity of user experience and the high efficiency of service are ensured, and the quality of live broadcast service and the user experience are improved.

Description

Technical Field

[0001] The present disclosure relates to CDN, content distribution network and live broadcast in the field of cloud computing technology, and in particular to a disaster recovery processing method, device, equipment and medium for CDN live broadcast. Background Art

[0002] With the rapid development of Internet technology and the growing demand for video content, content delivery networks (CDNs) have been widely used around the world. CDNs can effectively improve the speed and reliability of content transmission by deploying server nodes in multiple geographical locations. Especially in live broadcast services, the role of CDNs is particularly important.

[0003] Live streaming services need to transmit video content to viewers around the world in real time and efficiently, which places higher demands on the performance and stability of CDN. In order to ensure the continuity and high-quality transmission of live streaming services, the CDN system needs to have strong disaster recovery capabilities. Summary of the invention

[0004] The present invention provides a method, device, equipment and medium for disaster recovery processing of CDN live broadcast.

[0005] According to a first aspect of the present disclosure, a disaster recovery processing method for CDN live broadcast is provided, comprising:

[0006] Get the quality data of the node from the obtained log;

[0007] Based on the quality data, determining at least one faulty node and a fault type of each faulty node;

[0008] The at least one faulty node and the fault type of each faulty node are sent to a node configuration platform, and the fault type of the at least one faulty node is used to configure the node for disaster recovery processing.

[0009] According to a second aspect of the present disclosure, a disaster recovery processing method for CDN live broadcast is provided, comprising:

[0010] Obtain at least one faulty node and the fault type of each faulty node;

[0011] Based on the at least one faulty node and the fault type of each faulty node, generating a plurality of configuration blocks, each configuration block including a filter and a corresponding processing operation;

[0012] The multiple configuration blocks are issued so that each node performs disaster recovery processing based on the multiple configuration blocks.

[0013] According to a third aspect of the present disclosure, a disaster recovery processing method for CDN live broadcast is provided, which is applied to a node and includes:

[0014] Acquire multiple configuration blocks, where the multiple configuration blocks are configured based on the fault node and the fault type, and each configuration block includes a filter and a corresponding processing operation;

[0015] Based on the multiple configuration blocks and the flow information of the node, determining whether a filter in any configuration block is hit;

[0016] If the filter of the target configuration block is determined to be hit, disaster recovery processing is performed according to the processing operation in the target configuration block.

[0017] According to a fourth aspect of the present disclosure, a disaster recovery processing device for CDN live broadcast is provided, comprising:

[0018] A first processing unit, configured to obtain quality data of a node from the obtained log;

[0019] A second processing unit, configured to determine at least one faulty node and a fault type of each faulty node based on the quality data;

[0020] The third processing unit is used to send the at least one faulty node and the fault type of each faulty node to the node configuration platform, and the fault type of the at least one faulty node is used to configure the node for disaster recovery processing.

[0021] According to a fifth aspect of the present disclosure, a disaster recovery processing device for CDN live broadcast is provided, comprising:

[0022] A first processing unit, configured to obtain at least one faulty node and a fault type of each faulty node;

[0023] A second processing unit, configured to generate a plurality of configuration blocks based on the at least one faulty node and the fault type of each faulty node, each configuration block including a filter and a corresponding processing operation;

[0024] The third processing unit is used to send the multiple configuration blocks so that each node performs disaster recovery processing based on the multiple configuration blocks.

[0025] According to a sixth aspect of the present disclosure, a disaster recovery processing device for CDN live broadcast is provided, comprising:

[0026] A first processing unit, configured to obtain a plurality of configuration blocks, wherein the plurality of configuration blocks are obtained based on the configuration of the faulty nodes and the fault types, and each configuration block includes a filter and a corresponding processing operation;

[0027] A second processing unit, configured to determine whether a filter in any configuration block is hit based on the multiple configuration blocks and the flow information of the node;

[0028] The third processing unit is configured to perform disaster recovery processing according to the processing operation in the target configuration block if it is determined that the filter of the target configuration block is hit.

[0029] According to a seventh aspect of the present disclosure, there is provided an electronic device, comprising: a memory, a processor;

[0030] The memory stores computer-executable instructions;

[0031] The processor executes the computer-executable instructions stored in the memory, so that the processor performs the methods described in the first to third aspects.

[0032] According to a seventh aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to enable the computer to execute the methods described in the first to third aspects.

[0033] According to the technology disclosed in the present invention, the problem of service interruption and quality degradation caused by node failure in CDN live broadcast service is solved. Through the automated disaster recovery processing method, the technology can quickly identify and locate the faulty node and its fault type, and quickly generate and send the corresponding configuration block to each node according to the faulty node and fault type. The node migrates the affected traffic to the normally operating node based on multiple configuration blocks and the node's flow information, thereby effectively avoiding service interruption and quality degradation, improving the system's response speed and automation, reducing dependence on manual intervention, optimizing resource allocation, ensuring the continuity and stability of live broadcast services, and significantly improving user experience while reducing operation and maintenance costs and complexity.

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

[0035] The accompanying drawings are used to better understand the present solution and do not constitute a limitation of the present disclosure.

[0036] Figure 1 It is a scene diagram that can implement a CDN live broadcast disaster recovery processing method of an embodiment of the present disclosure;

[0037] Figure 2 It is a flowchart of a disaster recovery processing method for CDN live broadcast provided by the first embodiment of the present disclosure;

[0038] FIG3( a ) is a schematic diagram of a specific implementation of a CDN live broadcast disaster recovery processing method provided by the second embodiment of the present disclosure;

[0039] FIG3( b ) is a schematic diagram of another specific implementation of a CDN live broadcast disaster recovery processing method provided by the second embodiment of the present disclosure;

[0040] Figure 4 It is a schematic diagram of a specific implementation of a CDN live broadcast disaster recovery processing method provided by the third embodiment of the present disclosure;

[0041] Figure 5 It is a structural schematic diagram of a disaster recovery processing device for CDN live broadcast provided by the first embodiment of the present disclosure;

[0042] Figure 6 It is a structural schematic diagram of a disaster recovery processing device for CDN live broadcast provided by the second embodiment of the present disclosure;

[0043] Figure 7 It is a structural schematic diagram of a disaster recovery processing device for CDN live broadcast provided by the third embodiment of the present disclosure;

[0044] Figure 8 It is a structural schematic diagram of an electronic device used to implement the disaster recovery processing method of CDN live broadcast in the embodiment of the present disclosure. DETAILED DESCRIPTION

[0045] The following is a description of exemplary embodiments of the present disclosure in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0046] Before introducing the embodiments of the present disclosure, the application background of the embodiments of the present disclosure is first explained:

[0047] With the popularization of the Internet and the surge in video content consumption, live streaming services have become an important part of modern digital media. CDN plays a key role in live streaming services. By deploying distributed nodes around the world, it can effectively and quickly transmit video content to viewers to ensure a smooth viewing experience. However, live streaming services have extremely high requirements for network stability and real-time performance. Any node failure or network anomaly may cause service interruption or quality degradation. Therefore, improving the disaster recovery capability of the CDN system and ensuring that normal services can be quickly restored when a failure occurs is an important direction for current technological development.

[0048] In CDN live broadcast application scenarios, the existing disaster recovery method usually removes the faulty node from the scheduling system (i.e., down node). For newly established live broadcast connections, this method can indeed effectively avoid nodes with problems and ensure high-quality transmission of newly added live streams. However, considering the long connection characteristics of live broadcast services, the service quality of existing long connections (stock connections) will still be affected. In addition, existing disaster recovery methods usually require manual intervention to identify and handle faulty nodes. There is an unnecessary delay between fault detection and traffic switching, which reduces the response speed of the system. Not only does it increase labor costs, it may also affect the newly established incremental data streams during the configuration and distribution process, resulting in a decline in user experience.

[0049] In summary, providing a technical solution that can achieve true automated disaster recovery and fully meet the requirements of modern live broadcast services for high reliability and high availability is a technical problem that needs to be solved urgently.

[0050] Based on the above technical problems, the inventors found that by automatically transmitting the detected fault information to the node configuration platform, a configuration block containing specific filtering rules and processing operations for different fault types can be generated and quickly sent to each node when a fault occurs. After receiving the configuration, the node determines whether it hits the filter in the configuration block based on its own flow information and performs the corresponding processing operation when it hits, thereby realizing automated disaster recovery. Through the above method, not only the response speed of the system is improved, the dependence on manual intervention is reduced, but also the continuity and stability of the live broadcast service are ensured, and the user experience is significantly improved.

[0051] Based on this, the present disclosure provides a disaster recovery processing method, device, equipment and medium for CDN live broadcast, which is applied to CDN, content distribution network and live broadcast in the field of cloud computing technology to achieve the technical effect of ensuring the continuity and stability of live broadcast services and improving user experience.

[0052] Figure 1It is a scenario diagram of a disaster recovery processing method for CDN live broadcast that can implement an embodiment of the present disclosure, and the scenario includes at least a client 101, a server 102, etc. CDN is deployed on a server 102. In a push stream scenario, a user uploads the live broadcast content to an edge node of the CDN through the client 101. The edge node receives the content and transmits it to a central node or other relay nodes for further distribution to other users. If an edge node or a central node fails, it can quickly switch to other normal nodes to ensure that the live broadcast is not interrupted. In a pull stream scenario, a user requests to receive live broadcast content from an edge node of the CDN through the client 101. The edge node obtains the content from the central node and transmits it to the audience. If an edge node or a central node fails, it can quickly switch to other normal nodes to ensure that the reception of live broadcast content is not interrupted, thereby ensuring a good user experience.

[0053] The client 101 can be a smart phone, tablet computer, camera, local personal computer (PC), laptop, desktop and other electronic devices with multiple network connections and multimedia processing capabilities. The device is connected to the CDN through the network to participate in the uploading and receiving of live content. The server 102 can be a cloud server, server cluster, virtual server, etc. Through the server, the CDN can provide efficient and reliable content distribution services to ensure a good user experience under various network conditions.

[0054] It should be noted that the physical devices involved in the above descriptions are exemplary in the figures and do not represent the only ones. The present disclosure does not specifically limit the specific forms and types of the physical devices involved.

[0055] The following specific embodiments are used to describe in detail the technical solution of the present invention and how the technical solution of the present invention solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present invention will be described below in conjunction with the accompanying drawings.

[0056] The following is an introduction to the specific implementation scheme of the CDN live broadcast disaster recovery processing method provided by the present disclosure:

[0057] Figure 2 FIG. 1 is a flow chart of a CDN live broadcast disaster recovery processing method provided by the first embodiment of the present disclosure. Figure 2 As shown, the disaster recovery processing method of the CDN live broadcast specifically includes:

[0058] S201: Obtain quality data of the node from the obtained log.

[0059] In this step, the nodes in the CDN architecture include edge nodes and central nodes. Edge nodes are deployed on servers at the edge of the network, close to users to reduce latency and improve response speed. They are responsible for processing user requests and providing fast content distribution and processing capabilities. Central nodes are deployed on servers at the core of the network, responsible for managing and coordinating content distribution and data synchronization between multiple edge nodes. They have stronger computing and storage capabilities and are used to process large-scale data and complex content management tasks. System logs are a key data source for evaluating and monitoring the quality of each node, and usually contain multiple types of data, including timestamps, node identifiers, user request information, streaming media information, error and warning information, bandwidth usage, cache hit rate, and connection information.

[0060] Specifically, the flow quality analysis platform obtains the quality data of the nodes from the system log. The quality data of the edge nodes include: the flow quality of the push flow, the flow quality of the pull flow, the flow quality of the retweet, the success rate of the push and pull flow, the number of push and pull flows, and the node log accumulation percentage of each edge node; the quality data of the central node includes: the flow quality of the push flow, the flow quality of the pull flow, the flow quality of the retweet, the success rate of the push and pull flow, the number of push and pull flows, and the proportion of the outbound and inbound bandwidth of each central node. Among them, push flow refers to the process of users uploading video or audio content from a device to a server, that is, the process of content uploading, and pull flow refers to the process of users obtaining video or audio content from a server, that is, the process of content downloading.

[0061] The push stream quality refers to the quality of the streaming media content uploaded by the user from the client to the edge node or the central node, including indicators such as the clarity, bit rate, and frame rate of the video or audio; the push stream quality refers to the quality of the streaming media content transmitted from the edge node or the central node to the client, which also involves indicators such as the clarity, bit rate, and frame rate of the video or audio; the forwarded stream quality refers to the quality of the streaming media content forwarded by the edge node or the central node to other nodes or clients after receiving the push stream; the push and pull stream success rate refers to the ratio of the number of successful completions of the push and pull operations to the total number of attempts; the number of push and pull streams refers to the total number of push and pull requests processed by the edge node or the central node within a specific time period; the outbound and inbound bandwidth ratio of the edge node refers to the percentage of the amount of log data generated on the edge node relative to the log storage capacity of the edge node. A high accumulation percentage indicates that the node network is speed-limited in the outbound direction; the outbound and inbound bandwidth ratio of the central node refers to the usage ratio of the outbound bandwidth and the inbound bandwidth from the central node during data transmission. A high outbound bandwidth ratio indicates that the central node is mainly receiving and aggregating data. By monitoring and analyzing the above quality data, the streaming quality analysis platform can identify potential performance bottlenecks and problems, optimize the configuration and operation of edge nodes, and improve the overall streaming service quality and user experience.

[0062] S202: Determine at least one faulty node and a fault type of each faulty node based on the quality data.

[0063] In this step, the fault types include edge node speed limit, central node inbound and outbound faults, and full bandwidth of central node. Edge node speed limit means that the upload or download speed of edge nodes is limited due to network policy or hardware limitations, which will directly affect the quality of push and pull streams, resulting in a decrease in the bit rate of video or audio streams, affecting the user's viewing experience; central node inbound and outbound faults refer to the transmission anomalies of outbound or inbound traffic caused by network connection problems, hardware failures, or software configuration errors during the data transmission process of the central node. Outbound faults will cause the video or audio content to be unable to be effectively distributed from the central node to the edge node or client, and inbound faults will cause the central node to be unable to receive data from the content source or other nodes; full bandwidth of central node means that the available bandwidth of the central node is fully occupied, resulting in the inability to process additional traffic requests. This usually occurs during traffic peaks or when the node is improperly configured, resulting in data transmission delays, increased packet loss rates, and overall performance degradation.

[0064] As described in S201, the system log is a key data source for evaluating and monitoring the quality of each node, and contains multiple types of data based on live broadcast history data, including timestamps, node identifiers, user request information, streaming media information, errors and warning information, bandwidth usage, cache hit rate, and connection information, etc., which provides a basis for building a fault identification model. First, an initial fault identification model is built based on a neural network model; second, according to the historical live broadcast data, the quality data and fault conditions of multiple central nodes and edge nodes are obtained to obtain a sample set. The sample set includes multiple samples, each of which includes the quality data of a node and whether there is a fault. When the node has a fault, the sample also includes the fault type. For example, an exemplary sample is obtained: the stream quality of the edge node's push stream is 60%, the stream quality of the pull stream is 65%, the stream quality of the retweet is 70%, the push and pull stream success rate is 80%, the number of push and pull streams is 500, the node log accumulation percentage is 30%, there is a fault and the fault type is edge node speed limit. It can be seen from this exemplary sample that the speed limit of the edge node affects the upload and download speed of the video or audio content, resulting in more transmission failures and data processing backlogs. Based on the sample set composed of such exemplary samples, the initial fault identification model is trained to obtain a fault identification model. Through this fault identification model, the flow quality analysis platform can automatically obtain relevant information of the node with the fault, thereby improving the automation and intelligence level of the flow quality analysis platform.

[0065] Specifically, on the one hand, the quality data of the edge nodes and the central nodes described in S201 are input into the pre-acquired fault identification model for fault identification, and at least one faulty node and the type of each faulty node in the CDN live broadcast are obtained. It can be understood that the fault identification model is a model for identifying node faults obtained by training based on the historical data of the live broadcast node.

[0066] On the other hand, based on the quality data and the threshold range of quality data under different types of faults of different types of nodes, at least one faulty node and the fault type of each faulty node are determined. Specifically, based on the live broadcast history data, the threshold range of quality data under different types of node faults is determined. The determination of the threshold range is based on multiple factors such as user experience, network performance standards, service quality requirements, historical fault records, and business needs. It is necessary to ensure high-quality user experience while meeting technical and business requirements. For example, if the stream quality of the edge node's push stream is less than 70%, the stream quality of the pull stream is less than 70%, the stream quality of the retweet is less than 75%, the push and pull stream success rate is less than 85%, and the node log accumulation percentage is higher than 25%, it is determined that the edge node may have an edge node speed limit failure.

[0067] By automatically analyzing the quality data of each node, the flow quality analysis platform can quickly identify faulty nodes and their specific types, reducing the need for manual intervention and troubleshooting time. It not only improves the efficiency of fault detection, but also enhances the accuracy of diagnosis and reduces the risk of false alarms and missed alarms. The accumulated fault data can also be used to further analyze and optimize network architecture and service strategies to promote continuous improvement.

[0068] S203: Send at least one failed node and the failure type of each failed node to the node configuration platform, and the failure type of at least one failed node is used to configure the node for disaster recovery processing.

[0069] For the node configuration platform side, at least one faulty node and the fault type of each faulty node are obtained, that is, at least one faulty node and the fault type of each faulty node sent by the receiving flow quality analysis platform are received.

[0070] Specifically, after detecting a faulty node, the flow quality analysis platform packages at least one faulty node and the fault type of each faulty node into a data message, and sends it to the node configuration platform using standard protocols such as Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS) or Message Queue Telemetry Transport (MQ Telemetry Transport, MQTT). The node configuration platform receives and parses the data message content by listening to a predetermined network port or application programming interface (Application Programming Interface, API), and executes corresponding configuration and disaster recovery processing strategies according to the fault type to ensure fast and reliable information transmission, so that the node configuration platform can respond to faults in a timely and rapid manner.

[0071] S204: Based on at least one faulty node and the fault type of each faulty node, generate a plurality of configuration blocks, each configuration block including a filter and a corresponding processing operation.

[0072] In this step, the configuration block is a logical unit used to manage and process faulty nodes. Each configuration block includes filters and corresponding processing operations, which are used to identify and process specific types of faults. The filters play a role of screening and identification in the configuration block, and the processing operations are specific measures performed on the nodes that pass the filters. These measures may include rerouting traffic, switching to backup nodes, adjusting resource allocation, or executing other disaster recovery strategies.

[0073] Specifically, the node configuration platform generates multiple configuration blocks based on at least one faulty node, the fault type of each faulty node, and the pre-configured filtering rules and processing actions for different fault types. For example, the fault type identified by the filtering rules of the filter in configuration block 1 is edge node speed limit, which is specifically manifested as the flow quality of the edge node's push flow is lower than 70%, the flow quality of the pull flow is lower than 70%, the flow quality of the retweet is lower than 75%, the push and pull flow success rate is lower than 85%, and the node log accumulation percentage is higher than 25%. The corresponding processing operation is switching to the backup node. The fault type identified by the filtering identification rules of the filter in configuration block 2 is that the central node bandwidth is full, which is specifically manifested as the flow quality of the central node's push flow is lower than 70%, the flow quality of the pull flow is lower than 70%, the flow quality of the retweet is lower than 75%, the push and pull flow success rate is lower than 85%, the number of push and pull flows increases abnormally, and the proportion of outbound and inbound bandwidth is close to or reaches 100%. The corresponding processing operation is to dynamically adjust the traffic routing and allocate part of the traffic to other central nodes that are not fully loaded. By generating these configuration blocks, the node configuration platform can automatically apply appropriate measures to resolve different fault types and ensure network stability and service quality.

[0074] S205: Send multiple configuration blocks so that each node performs disaster recovery processing based on the multiple configuration blocks.

[0075] For any node side, multiple configuration blocks are obtained. The multiple configuration blocks are configured based on the faulty nodes and fault types. Each configuration block includes a filter and a corresponding processing operation.

[0076] In this step, the node configuration platform writes the generated multiple configuration blocks into Platform, so that each node performs disaster recovery based on the multiple configuration blocks.

[0077] The node configuration platform communicates with the Platform through an API interface or configuration management tool. After the configuration block is generated, it is serialized into a standardized data format, such as JSON or XML, for easy transmission and parsing. Next, the platform sends the serialized configuration block data to the designated API endpoint of the Platform through an HTTP POST request or other protocol. After receiving the configuration block data, the Platform parses and verifies the data to ensure that its format is correct and the content is complete. If the verification passes, the Platform will store these configuration blocks in its internal configuration database or configuration management system. Once the configuration block is successfully written, the Platform will update its configuration status so that the relevant nodes can obtain the latest configuration for application. The node identifies the current fault type based on the filtering rules in the configuration block and performs corresponding processing operations, such as switching to a backup node, adjusting traffic routing, or optimizing resource allocation. Through this process, the entire network can achieve fast and automated disaster recovery processing, ensuring that the quality of service can be quickly restored and maintained when a fault occurs. It not only improves the resilience and reliability of the network, but also reduces the need for manual intervention and improves overall operational efficiency.

[0078] S206: Based on the multiple configuration blocks and the flow information of the node, determine whether a filter in any configuration block is hit.

[0079] In this step, the node's flow information refers to the real-time data collected from the edge node or the central node, including the flow quality of the push flow, the flow quality of the pull flow, the flow quality of the retweet, the success rate of the push and pull flow, the number of push and pull flows, bandwidth usage, etc., which is used to indicate the current status and performance of the node.

[0080] Specifically, after the node configuration platform writes the generated multiple configuration blocks into the Platform, any node compares the multiple configuration blocks and the current flow information of the node to determine whether the flow information of the node meets the conditions of the filter. If the flow information of a node meets the conditions of one or more filters, it is considered that the node hits the corresponding configuration block; if the flow information of a node does not meet the conditions of any filter, it is considered that the node does not hit any configuration block. At this time, the node is considered to be in normal operation, no faults or anomalies requiring intervention are detected, no disaster recovery strategy will be executed, and the node will continue to operate according to its current configuration and operating status. Through this process, any node can automatically identify and respond to faults in the network in order to intervene in time to ensure the continuity and quality of live broadcast services.

[0081] S207: If it is determined that the filter of the target configuration block is hit, disaster recovery processing is performed according to the processing operation in the target configuration block.

[0082] In this step, disaster recovery refers to a series of strategies and measures taken in fields such as information technology or data management to respond to emergencies that may cause system interruption or data loss (such as natural disasters, hardware failures, network attacks, etc.) to ensure the availability, integrity and continuity of systems and data, so as to reduce the impact of disasters on business operations and ensure that the system can resume operation quickly after a disaster occurs.

[0083] In a specific implementation of the present disclosure, if the flow information of a node meets the conditions of one or more filters, it is determined that the node hits the filter of the corresponding configuration block, and it is determined to be the filter of the target configuration block. First, a target duration is randomly generated, and after the target duration, disaster recovery processing is performed according to the processing operations in the target configuration block. The target duration can range from a few seconds to a few minutes, depending on the specific needs of the system, the load conditions, and the business continuity requirements. By introducing random delays, it is possible to avoid disaster recovery processing for all faulty nodes at the same time, thereby preventing the instantaneous load surge from causing a secondary impact on the system, helping to balance the system load, reduce resource competition and conflicts, and improve the overall stability of the system.

[0084] Specifically, in the first case: if the flow information of a central node meets the conditions of one or more filters, it is determined that the central node hits the filter of the corresponding configuration block, and it is determined to be the filter of the target configuration block, and disaster recovery processing is performed according to the processing operation in the target configuration block. When the central node has a serious failure or is completely unavailable, in order to ensure the continuity and stability of the service, all traffic is transferred to other normally operating nodes, that is, the central node is blocked, and all push streams and all pull streams in the central node are switched to other central nodes that are not at fault. When the load of the central node is too high or the bandwidth is close to saturation, in order to effectively relieve the pressure on the node, while keeping some of the functions of the node operational and avoiding excessive adjustment burden on the system, it is sufficient to partially transfer the traffic, that is, block the central node, and switch part of the push stream inventory on the central node to other central nodes that are not at fault.

[0085] The second case: If the flow information of an edge node meets the conditions of one or more filters, it is determined that the edge node hits the filter of the corresponding configuration block, and it is determined to be the filter of the target configuration block, and disaster recovery processing is performed according to the processing operation in the target configuration block. The fault type of the edge node is edge node speed limit, so the corresponding disaster recovery processing measure is to forward the push and / or pull flow in the edge node to other edge nodes in the same region as the edge node and without speed limit. Edge nodes that are geographically closer in the same region mean shorter network paths and faster response times. At the same time, edge nodes in the same region have similar network conditions and service capabilities in the same network topology. Therefore, selecting edge nodes in the same region can significantly reduce network latency, ensuring that users will not experience significant delays or interruptions due to node speed limits when accessing CDN live content, minimizing network latency and bandwidth consumption, maintaining service efficiency and stability, and dynamically adapting to changes in network conditions without affecting user experience.

[0086] The disaster recovery processing method for CDN live broadcast provided by the embodiment of the present disclosure obtains the quality data of the node from the system log, identifies the faulty node and its fault type, and performs automatic disaster recovery processing based on the configuration block generated by the faulty node and the fault type. The disaster recovery processing method for CDN live broadcast improves the efficiency and accuracy of fault detection by automatically identifying and responding to faults, reduces manual intervention and troubleshooting time, ensures the continuity of user experience and the efficiency of service, enhances the elasticity and reliability of the CDN system, optimizes resource allocation, and improves the quality of live broadcast services and user experience.

[0087] FIG3(a) is a schematic diagram of a specific implementation of a CDN live broadcast disaster recovery processing method provided by the second embodiment of the present disclosure, and FIG3(b) is a schematic diagram of another specific implementation of a CDN live broadcast disaster recovery processing method provided by the second embodiment of the present disclosure. On the basis of the above embodiment, if the flow information of a central node meets the conditions of one or more filters, it is determined that the central node hits the filter of the corresponding configuration block, and it is determined to be the filter of the target configuration block, and disaster recovery processing is performed according to the processing operation in the target configuration block. Specifically including:

[0088] In the first case, as shown in Figure 3(a), when the central node has a serious failure or completely loses its function, that is, when the central node fails in the ingress and egress directions, in order to ensure the continuity and stability of the service, all traffic is rerouted to other normally operating nodes, that is, the central node is blocked, and all push and pull flows in the central node are switched to other central nodes that are not faulty.

[0089] In the second case, as shown in Figure 3(b), when the central node is overloaded or its bandwidth is close to saturation, that is, when the central node bandwidth is fully utilized, in order to effectively relieve the node pressure while maintaining some of the node's functions and avoiding excessive adjustment burden on the system, it is sufficient to partially transfer the traffic, that is, to block the central node and switch part of the traffic flow on the central node to other central nodes that are not at fault.

[0090] The above-mentioned disaster recovery method corresponding to the central node failure significantly improves the elasticity and reliability of the system, optimizes resource allocation, and ensures the service quality and user experience under different failure situations.

[0091] Figure 4 is a schematic diagram of a specific implementation of a CDN live broadcast disaster recovery processing method provided by the third embodiment of the present disclosure, such as Figure 4 As shown, based on the above embodiment, if the flow information of a certain edge node meets the conditions of one or more filters, it is determined that the edge node hits the filter of the corresponding configuration block, and it is determined to be the filter of the target configuration block, and disaster recovery processing is performed according to the processing operation in the target configuration block. Specifically including:

[0092] like Figure 4 As shown, when the edge node fails, that is, the edge node is speed-limited, in order to ensure that users do not experience obvious delays or interruptions due to node speed limits when accessing CDN live content, the corresponding disaster recovery processing method is to forward the push and / or pull streams in the edge node to other edge nodes in the same area as the edge node and without speed limits.

[0093] The above-mentioned disaster recovery method corresponding to edge node failure can effectively ensure that users will not experience obvious delays or interruptions when accessing CDN live content. Secondly, because edge nodes in the same region are selected, bandwidth consumption is reduced, regional load balancing in the same region is achieved, and the situation where a certain edge node is overloaded while other node resources are idle is avoided, thereby improving the overall service reliability and user experience.

[0094] Figure 5 Schematic diagram of a CDN live broadcast disaster recovery processing device provided by the first embodiment of the present disclosure, which is applied to a stream quality analysis platform, such as Figure 7 As shown, the disaster recovery processing device 50 for CDN live broadcast includes:

[0095] The first processing unit 501 is used to obtain the quality data of the node from the obtained log;

[0096] A second processing unit 502 is used to determine at least one faulty node and a fault type of each faulty node based on the quality data;

[0097] The third processing unit 503 is used to send at least one faulty node and the fault type of each faulty node to the node configuration platform, and the fault type of at least one faulty node is used to configure the node for disaster recovery processing.

[0098] In a possible implementation, the second processing unit 502 includes:

[0099] The first processing module 5021 is used to input the quality data into a pre-acquired fault identification model to perform fault identification, and obtain at least one fault node and the fault type of each fault node;

[0100] Among them, the fault identification model is a model used to identify node faults based on historical data training of live broadcast nodes.

[0101] The second processing module 5022 is used to determine at least one faulty node and the fault type of each faulty node based on the quality data and the threshold range of the quality data under different types of faults of different types of nodes.

[0102] In a possible implementation manner, the CDN live broadcast disaster recovery processing device 50 further includes:

[0103] The fourth processing unit 504 is used to build an initial fault identification model based on the neural network model;

[0104] A fifth processing unit 505 is used to obtain quality data and fault conditions of multiple central nodes and multiple edge nodes according to the live broadcast history data, and obtain a sample set, where the sample set includes multiple samples, each sample includes quality data of a node and whether there is a fault, and when a node has a fault, the sample also includes the fault type;

[0105] The sixth processing unit 506 is used to train the initial fault recognition model according to the sample set to obtain a fault recognition model.

[0106] In a possible implementation, the above-mentioned quality data include: the push flow quality, pull flow quality, retweet flow quality, push and pull flow success rate, number of push and pull flows, and node log accumulation percentage of each edge node; the push flow quality, pull flow quality, retweet flow quality, push and pull flow success rate, number of push and pull flows, and outbound and inbound bandwidth ratio of each central node.

[0107] In a possible implementation manner, the above-mentioned fault types include: edge node speed limitation, central node ingress and egress failure, and central node bandwidth fullness.

[0108] The disaster recovery processing device for CDN live broadcast provided in the embodiment of the present disclosure can execute the method provided in the above-mentioned embodiment, and its implementation principle and technical effect are similar, which will not be repeated here.

[0109] Figure 6 Schematic diagram of a CDN live broadcast disaster recovery processing device provided by the second embodiment of the present disclosure, which is applied to a node configuration platform, such as Figure 6 As shown, the disaster recovery processing device 60 of the CDN live broadcast includes:

[0110] The first processing unit 601 is used to obtain at least one faulty node and a fault type of each faulty node;

[0111] A second processing unit 602, configured to generate a plurality of configuration blocks based on at least one faulty node and a fault type of each faulty node, each configuration block including a filter and a corresponding processing operation;

[0112] The third processing unit 603 is used to send multiple configuration blocks so that each node performs disaster recovery processing based on the multiple configuration blocks.

[0113] In a possible implementation, the second processing unit 602 includes:

[0114] The first processing module 6021 is used to generate multiple configuration blocks based on at least one faulty node, the fault type of each faulty node, and pre-configured filtering rules and processing actions for different fault types of different nodes.

[0115] In a possible implementation, the third processing unit 603 includes:

[0116] The second processing module 6031 is used to write multiple configuration blocks into Platform.

[0117] In a possible implementation, the first processing unit 601 includes:

[0118] The third processing module 6011 is used to receive at least one faulty node and the fault type of each faulty node sent by the flow quality analysis platform.

[0119] In a possible implementation manner, the above-mentioned fault types include: edge node speed limitation, central node ingress and egress failure, and central node bandwidth fullness.

[0120] The disaster recovery processing device for CDN live broadcast provided in the embodiment of the present disclosure can execute the method provided in the above-mentioned embodiment, and its implementation principle and technical effect are similar, which will not be repeated here.

[0121] Figure 7 Schematic diagram of a CDN live broadcast disaster recovery processing device provided by the second embodiment of the present disclosure, which is applied to nodes such as Figure 7 As shown, the disaster recovery processing device 70 of the CDN live broadcast includes:

[0122] The first processing unit 701 is used to obtain multiple configuration blocks, where the multiple configuration blocks are configured based on the fault node and the fault type, and each configuration block includes a filter and a corresponding processing operation;

[0123] The second processing unit 702 is used to determine whether a filter in any configuration block is hit based on the flow information of the multiple configuration blocks and the node;

[0124] The third processing unit 703 is configured to perform disaster recovery processing according to the processing operation in the target configuration block if it is determined that the filter of the target configuration block is hit.

[0125] In a possible implementation, the third processing unit 703 includes:

[0126] The first processing module 7031 is used to randomly generate a target duration;

[0127] The second processing module 7032 is used to perform disaster recovery processing according to the processing operations in the target configuration block after the target duration.

[0128] In a possible implementation, the second processing module 7032 includes:

[0129] The first processing submodule 70321 is used to block the central node and switch all push streams and all pull streams in the central node to other central nodes that are not faulty;

[0130] or,

[0131] Block the central node and switch part of the streaming capacity on the central node to other central nodes that are not faulty.

[0132] The second processing submodule 70322 is used to forward the push stream and / or pull stream in the edge node to other edge nodes that are in the same area as the edge node and have no speed limit.

[0133] The disaster recovery processing device for CDN live broadcast provided in the embodiment of the present disclosure can execute the method provided in the above-mentioned embodiment, and its implementation principle and technical effect are similar, which will not be repeated here.

[0134] According to an embodiment of the present disclosure, the present disclosure also provides an electronic device and a readable storage medium.

[0135] According to an embodiment of the present disclosure, the present disclosure provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to enable a computer to execute the technical solution in the aforementioned method embodiment.

[0136] Figure 8It is a structural schematic diagram of an electronic device used to implement the disaster recovery processing method of CDN live broadcast of the embodiment of the present disclosure. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or required herein.

[0137] like Figure 8 As shown, the device 80 includes a computing unit 801, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 to a random access memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the device 80 can also be stored. The computing unit 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0138] A number of components in the device 80 are connected to the I / O interface 805, including: an input unit 806, such as a keyboard, a mouse, etc.; an output unit 807, such as various types of displays, speakers, etc.; a storage unit 808, such as a disk, an optical disk, etc.; and a communication unit 809, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 809 allows the device 80 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0139] The computing unit 801 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as the disaster recovery processing method. For example, in some embodiments, the disaster recovery processing method may be implemented as a computer software program, which is tangibly included in a machine-readable medium, such as a storage unit 808. In some embodiments, part or all of the computer program may be loaded and / or installed on the device 80 via the ROM 802 and / or the communication unit 809. When the computer program is loaded into the RAM 803 and executed by the computing unit 801, one or more steps of the disaster recovery processing method described above may be executed. Alternatively, in other embodiments, the computing unit 801 may be configured to execute the disaster recovery processing method in any other appropriate manner (eg, by means of firmware).

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

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

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

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

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

[0145] A computer system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The relationship between the client and the server is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or a cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and virtual private servers (VPS). The server may also be a server of a distributed system, or a server combined with a blockchain.

[0146] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this disclosure can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solutions disclosed in this disclosure can be achieved, and this document does not limit this.

[0147] The above specific implementations do not constitute a limitation on the protection scope of the present disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.

Claims

1. A disaster recovery processing method for CDN live broadcast, comprising: Get the quality data of the node from the obtained log; Based on the quality data, determining at least one faulty node and a fault type of each faulty node; The at least one faulty node and the fault type of each faulty node are sent to a node configuration platform, and the fault type of the at least one faulty node is used to configure the node for disaster recovery processing.

2. The method according to claim 1, wherein: The determining, based on the quality data, at least one faulty node and a fault type of each faulty node comprises: Inputting the quality data into a pre-acquired fault identification model for fault identification, and obtaining the at least one faulty node and the fault type of each faulty node; The fault identification model is a model for identifying node faults obtained by training based on historical data of live broadcast nodes.

3. The method according to claim 1, wherein: The determining, based on the quality data, at least one faulty node and a fault type of each faulty node comprises: Based on the quality data and the quality data threshold ranges under different types of faults of different types of nodes, the fault types of the at least one faulty node and each faulty node are determined.

4. The method according to claim 2, further comprising: Construct an initial fault identification model based on a neural network model; According to the live broadcast history data, quality data and fault conditions of multiple central nodes and multiple edge nodes are obtained to obtain a sample set, wherein the sample set includes multiple samples, each sample includes quality data of a node and whether there is a fault, and when the node has a fault, the sample also includes the fault type; The initial fault identification model is trained according to the sample set to obtain the fault identification model.

5. The method according to any one of claims 1 to 4, wherein: The quality data include: The push quality, pull quality, retweet quality, push and pull success rate, push and pull quantity, and node log accumulation percentage of each edge node; The push quality, pull quality, retweet quality, push and pull success rate, push and pull quantity, and inbound and outbound bandwidth ratio of each central node.

6. The method according to any one of claims 1 to 5, wherein: The fault types include: The edge nodes are speed-limited, the central nodes have inbound and outbound failures, and the central nodes’ bandwidth is fully utilized.

7. A disaster recovery method for CDN live broadcast, comprising: Obtain at least one faulty node and the fault type of each faulty node; Based on the at least one faulty node and the fault type of each faulty node, generating a plurality of configuration blocks, each configuration block including a filter and a corresponding processing operation; The multiple configuration blocks are issued so that each node performs disaster recovery processing based on the multiple configuration blocks.

8. The method according to claim 7, wherein: The generating a plurality of configuration blocks based on the at least one faulty node and the fault type of each faulty node comprises: The multiple configuration blocks are generated based on the at least one faulty node, the fault type of each faulty node, and pre-configured filtering rules and processing actions for different fault types of different nodes.

9. The method according to claim 7 or 8, wherein: The sending down the multiple configuration blocks includes: The multiple configuration blocks are written into Platform.

10. The method according to any one of claims 7 to 9, wherein: The obtaining of at least one faulty node and the fault type of each faulty node includes: At least one faulty node and a fault type of each faulty node sent by the receiving flow quality analysis platform.

11. The method according to any one of claims 7 to 10, wherein: The fault types include: The edge nodes are speed-limited, the central nodes have inbound and outbound failures, and the central nodes’ bandwidth is fully utilized.

12. A disaster recovery processing method for CDN live broadcast, applied to a node, comprising: Acquire multiple configuration blocks, where the multiple configuration blocks are configured based on the fault node and the fault type, and each configuration block includes a filter and a corresponding processing operation; Based on the multiple configuration blocks and the flow information of the node, determining whether a filter in any configuration block is hit; If the filter of the target configuration block is determined to be hit, disaster recovery processing is performed according to the processing operation in the target configuration block.

13. The method according to claim 12, wherein: The performing disaster recovery processing according to the processing operation in the target configuration block includes: Randomly generate target duration; After the target duration, disaster recovery processing is performed according to the processing operations in the target configuration block.

14. The method according to claim 12 or 13, wherein: If the node is a central node, performing disaster recovery processing according to the processing operation in the target configuration block includes: The central node is blocked, and all push and pull streams in the central node are switched to other central nodes that are not faulty; or, The central node is blocked, and part of the streaming inventory on the central node is switched to other central nodes that are not faulty.

15. The method according to claim 12 or 13, wherein: If the node is an edge node, performing disaster recovery processing according to the processing operation in the target configuration block includes: The push stream and / or pull stream in the edge node is forwarded to other edge nodes in the same area as the edge node and without speed limit.

16. A disaster recovery processing device for CDN live broadcast, comprising: A first processing unit, configured to obtain quality data of a node from the obtained log; A second processing unit, configured to determine at least one faulty node and a fault type of each faulty node based on the quality data; The third processing unit is used to send the at least one faulty node and the fault type of each faulty node to the node configuration platform, and the fault type of the at least one faulty node is used to configure the node for disaster recovery processing.

17. A disaster recovery processing device for CDN live broadcast, comprising: A first processing unit, configured to obtain at least one faulty node and a fault type of each faulty node; A second processing unit, configured to generate a plurality of configuration blocks based on the at least one faulty node and the fault type of each faulty node, each configuration block including a filter and a corresponding processing operation; The third processing unit is used to send the multiple configuration blocks so that each node performs disaster recovery processing based on the multiple configuration blocks.

18. A disaster recovery processing device for CDN live broadcast, comprising: A first processing unit, configured to obtain a plurality of configuration blocks, wherein the plurality of configuration blocks are obtained based on the configuration of the faulty nodes and the fault types, and each configuration block includes a filter and a corresponding processing operation; A second processing unit, configured to determine whether a filter in any configuration block is hit based on the multiple configuration blocks and the flow information of the node; The third processing unit is configured to perform disaster recovery processing according to the processing operation in the target configuration block if it is determined that the filter of the target configuration block is hit.

19. An electronic device comprising: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 15.

20. A non-transitory computer-readable storage medium storing computer instructions, wherein: The computer instructions are used to cause the computer to execute the method according to any one of claims 1 to 15.

Images