Live preloading method, readable storage medium

By querying a distributed database and creating a local preloading task in local storage when a task creation command is received, and using authentication skip parameters to preload the live stream, the problem of improper management of preloading tasks in the prior art is solved, and processing efficiency and system reliability are improved.

CN119729031BActive Publication Date: 2025-11-28CHINA TELECOM CLOUD TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411785007.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-12-06
Publication Date
2025-11-28
Estimated Expiration
2044-12-06

AI Technical Summary

Technical Problem

The lack of effective management of live streaming preloading tasks in existing technologies makes it difficult for content delivery networks to distinguish between preloading requests and regular live streaming requests, thus affecting the preloading effect.

Method used

By querying the distributed database and creating a local preloaded task in local storage when a task creation command is received, and using authentication skip parameters to preload the live stream, combined with task maintenance timers and key-value pair management, duplicate task creation is avoided and processing efficiency is improved.

Benefits of technology

It enables effective management of preloading tasks, improves the efficiency of the content delivery network in processing preloading requests, enhances the reliability and fault tolerance of the system, and optimizes the processing flow of live streaming preloading tasks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119729031B_ABST
    Figure CN119729031B_ABST
Patent Text Reader

Abstract

The application relates to a live broadcast preloading method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: obtaining a command identifier and initial task parameters in the case of receiving a task creation command; obtaining command parameters according to the command identifier, the initial task parameters and the current time in the case of not storing the command identifier in a distributed database; storing the command identifier and the command parameters as a first key-value pair into the distributed database; storing the command identifier and the command parameters as a second key-value pair into a local storage in the case of the local task number being less than a local task number threshold value, creating a local preloading task, and starting a task maintenance timer; the local preloading task is used for carrying an authentication skipping parameter to preload a live broadcast stream; and each local preloading task is maintained according to the second key-value pair under the triggering of the task maintenance timer. The method can improve the efficiency and stability of live broadcast preloading.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the field of streaming media technology, and in particular to a live streaming preloading method and device, a computer device, a computer readable storage medium and a computer program product. BACKGROUND

[0002] With the development of streaming media technology, live streaming preloading technology has emerged. The live streaming preloading technology can simulate a real live streaming request, preloads live streaming media data and preheats it, thereby reducing the first screen delay and improving the live streaming viewing experience of users. However, the related art often lacks effective management of live streaming preloading tasks, which makes it difficult for a content distribution network to distinguish between preloading requests and regular live streaming requests, thereby affecting the preloading effect. SUMMARY

[0003] Therefore, it is necessary to provide a live streaming preloading method, device, computer device, computer readable storage medium and computer program product to solve the above technical problems.

[0004] In a first aspect, the present application provides a live streaming preloading method, comprising:

[0005] In the case of receiving a task creation command, obtaining the command identifier and initial task parameters contained in the task creation command;

[0006] In the case of not storing the command identifier in the distributed database, obtaining the command parameters corresponding to the command identifier according to the command identifier, initial task parameters and current time;

[0007] Storing the command identifier and the command parameters as a first key-value pair in the distributed database;

[0008] In the case of the number of local tasks being less than a local task threshold, storing the command identifier and the command parameters as a second key-value pair in a local storage, creating a local preloading task according to the second key-value pair, and starting a task maintenance timer of the local preloading task; the local preloading task is used to carry an authentication skipping parameter to preload a live streaming; the authentication skipping parameter is used to instruct a content distribution network node not to authenticate a preloading request of the live streaming;

[0009] Under the triggering of the task maintenance timer of each local preloading task, maintaining each local preloading task according to the second key-value pair corresponding to each local preloading task.

[0010] In one of the embodiments, the maintaining each of the local preload tasks according to the second key-value pair corresponding to each of the local preload tasks comprises: obtaining a task state parameter, a next execution time, a resource address, and an instance parameter of the local preload task according to the command parameter contained in the second key-value pair; in a case where the instance parameter is a null value, the task state parameter is a task waiting state, and the next execution time is not later than the current time, generating a live stream pulling instance carrying the authentication skip parameter according to an authentication skip identifier and the resource address; the live stream pulling instance is used to send the preload request carrying the authentication skip parameter to the content distribution network; assigning the live stream pulling instance to the instance parameter, and assigning the task state parameter to a task running state; attempting to update the first key-value pair corresponding to the local preload task in the distributed database according to the task state parameter and the instance parameter; in a case where the first key-value pair is updated successfully, updating the second key-value pair of the local preload task in the local storage according to the task state parameter and the instance parameter; resetting the task maintenance timer of the local preload task.

[0011] In one of the embodiments, after the attempting to update the first key-value pair corresponding to the local preload task in the distributed database according to the task state parameter and the instance parameter, the method further comprises: in a case where the first key-value pair fails to be updated, terminating the live stream pulling instance corresponding to the local preload task, and setting the instance parameter to a null value; and deleting the second key-value pair corresponding to the local preload task.

[0012] In one of the embodiments, the command parameter comprises a last success time and a total failure number; after the assigning the live stream pulling instance to the instance parameter and the assigning the task state parameter to a task running state, the method further comprises: in a case where a pulling success response of the live stream pulling instance is received, setting the last success time to an instance end time of the live stream pulling instance; performing the attempting to update the first key-value pair corresponding to the local preload task in the distributed database according to the last success time; in a case where a pulling failure response of the live stream pulling instance is received, updating the next execution time of the local preload task according to the total failure number and a preset maximum retry interval; updating the total failure number of the local preload task, setting the instance parameter to a null value, and setting the task state parameter to a task waiting state; and performing the attempting to update the first key-value pair corresponding to the local preload task in the distributed database according to the next execution time, the total failure number, the instance parameter, and the task state parameter.

[0013] In one of the embodiments, the maintaining of each of the local preloading tasks according to the second key-value pair corresponding to each of the local preloading tasks comprises: obtaining an instance parameter, a last success time, an end time, and a task state parameter of the local preloading task according to the command parameter contained in the second key-value pair; setting the last success time as the current time and setting the task state parameter as a task running state if the instance parameter is a non-empty value; terminating a live stream pulling instance corresponding to the instance parameter if the task state parameter is the task running state and the end time is earlier than the current time, setting the instance parameter as a null value, and setting the task state parameter as a task end state; setting the task state parameter as a task timeout state if the task state parameter is a task waiting state and an interval between the last success time and the current time is not less than a timeout threshold; and executing a task deletion operation of the local preloading task if the task state parameter is the task end state or the task timeout state.

[0014] In one of the embodiments, the executing of the task deletion operation of the local preloading task comprises: attempting to connect the distributed database; updating the second key-value pair corresponding to the local preloading task according to the task state parameter or the task state parameter and the instance parameter if the connection fails; resetting the task maintenance timer; attempting to delete the first key-value pair corresponding to the local preloading task in the distributed database if the connection succeeds; deleting the second key-value pair corresponding to the local preloading task and sending task end information of the local preloading task if the first key-value pair is successfully deleted; and deleting the second key-value pair corresponding to the local preloading task if the deletion of the first key-value pair fails.

[0015] In one of the embodiments, the method further comprises: obtaining a command identifier dt contained in a task deletion command if the task deletion command is received; attempting to delete a first key-value pair corresponding to the command identifier in the distributed database if it is determined that the command identifier is stored in the distributed database; querying whether a second key-value pair corresponding to the command identifier is stored in the local storage if the first key-value pair is successfully deleted; stopping the task maintenance timer of a local preloading task corresponding to the second key-value pair and terminating a live stream pulling instance corresponding to the local preloading task if the second key-value pair exists; deleting the second key-value pair and sending task end information of the local preloading task.

[0016] In one of the embodiments, the method further comprises: obtaining the weight values of the first key-value pairs in the distributed database at the triggering of the task recovery timer; the weight values are obtained according to the last update times of the first key-value pairs; filtering expired key-value pairs from the first key-value pairs according to the weight values of the first key-value pairs and a preset task expiration duration; filtering to-be-recovered key-value pairs from the expired key-value pairs according to the local task recovery number and the weight values of the expired key-value pairs; updating the weight values of the to-be-recovered key-value pairs according to the current time; storing the to-be-recovered key-value pairs to the local memory in the case that the local memory does not store second key-value pairs corresponding to the to-be-recovered key-value pairs; creating a local preloading task according to the to-be-recovered key-value pairs, starting a task maintenance timer of the local preloading task; and resetting the task recovery timer.

[0017] In one of the embodiments, before the obtaining of the weight values of the first key-value pairs in the distributed database, the method further comprises: obtaining a distributed lock of the distributed database; in the case that the distributed lock is obtained, performing the step of obtaining the weight values of the first key-value pairs in the distributed database; in the case that the distributed lock fails to be obtained, resetting the task recovery timer; after the updating of the weight values of the to-be-recovered key-value pairs according to the current time, the method further comprises: releasing the distributed lock; in the case that the distributed lock fails to be released, resetting the task recovery timer.

[0018] In a second aspect, the application further provides a live broadcast preloading device, comprising:

[0019] A creation command receiving module is configured to obtain a command identifier and initial task parameters contained in a task creation command in the case that the task creation command is received.

[0020] An initial parameter obtaining module is configured to obtain command parameters corresponding to the command identifier according to the command identifier, the initial task parameters and a current time in the case that the distributed database does not store the command identifier.

[0021] A first key-value pair storing module is configured to store the command identifier and the command parameters to the distributed database as a first key-value pair.

[0022] a local task creation module, configured to, in a case where a number of local tasks is less than a local task number threshold, store the command identifier and the command parameter as a second key-value pair into a local storage, create a local preload task according to the second key-value pair, and start a task maintenance timer of the local preload task; the local preload task is configured to carry an authentication skip parameter to perform preload of a live stream; the authentication skip parameter is configured to instruct a content distribution network node not to perform authentication on a preload request of the live stream;

[0023] a local task maintenance module, configured to, under triggering of the task maintenance timer of each of the local preload tasks, maintain each of the local preload tasks according to the second key-value pair corresponding to each of the local preload tasks.

[0024] In a third aspect, the present application further provides a computer device, comprising a memory and a processor, the memory stores a computer program, and the processor implements the following steps when executing the computer program:

[0025] in a case where a task creation command is received, obtaining a command identifier and initial task parameters contained in the task creation command;

[0026] in a case where the command identifier is not stored in the distributed database, obtaining command parameters corresponding to the command identifier according to the command identifier, the initial task parameters and a current time;

[0027] storing the command identifier and the command parameter as a first key-value pair into the distributed database;

[0028] in a case where a number of local tasks is less than a local task number threshold, storing the command identifier and the command parameter as a second key-value pair into a local storage, creating a local preload task according to the second key-value pair, and starting a task maintenance timer of the local preload task; the local preload task is configured to carry an authentication skip parameter to perform preload of a live stream; the authentication skip parameter is configured to instruct a content distribution network node not to perform authentication on a preload request of the live stream;

[0029] in a case where a task creation command is received, obtaining a command identifier and initial task parameters contained in the task creation command;

[0030] In a fourth aspect, the present application further provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the following steps:

[0031] in a case where a task creation command is received, obtaining a command identifier and initial task parameters contained in the task creation command;

[0032] In a case where the command identifier is not stored in the distributed database, obtaining a command parameter corresponding to the command identifier according to the command identifier, the initial task parameter and a current time;

[0033] Storing the command identifier and the command parameter as a first key-value pair into the distributed database;

[0034] In a case where the number of local tasks is less than a local task number threshold, storing the command identifier and the command parameter as a second key-value pair into a local storage, creating a local preloading task according to the second key-value pair, starting a task maintenance timer of the local preloading task; the local preloading task is used to carry an authentication skipping parameter to pre-load a live stream; the authentication skipping parameter is used to instruct a content distribution network node not to authenticate a pre-loading request of the live stream;

[0035] Under triggering of the task maintenance timer of each local preloading task, maintaining each local preloading task according to the second key-value pair corresponding to each local preloading task.

[0036] In a fifth aspect, the present application further provides a computer program product, comprising a computer program which, when executed by a processor, implements the following steps:

[0037] In a case where a task creation command is received, obtaining a command identifier and an initial task parameter contained in the task creation command;

[0038] In a case where the command identifier is not stored in the distributed database, obtaining a command parameter corresponding to the command identifier according to the command identifier, the initial task parameter and a current time;

[0039] Storing the command identifier and the command parameter as a first key-value pair into the distributed database;

[0040] In a case where the number of local tasks is less than a local task number threshold, storing the command identifier and the command parameter as a second key-value pair into a local storage, creating a local preloading task according to the second key-value pair, starting a task maintenance timer of the local preloading task; the local preloading task is used to carry an authentication skipping parameter to pre-load a live stream; the authentication skipping parameter is used to instruct a content distribution network node not to authenticate a pre-loading request of the live stream;

[0041] Under triggering of the task maintenance timer of each local preloading task, maintaining each local preloading task according to the second key-value pair corresponding to each local preloading task.

[0042] The aforementioned live streaming preloading method, apparatus, computer device, computer-readable storage medium, and computer program product, upon receiving a task creation command, obtains the command identifier and initial task parameters contained therein. If the command identifier is not stored in the distributed database, the method obtains the command parameters corresponding to the command identifier based on the command identifier, initial task parameters, and current time. The method then associates the command identifier and command parameters as a first key-value pair and stores them in the distributed database. If the number of local tasks is less than a local task number threshold, the method associates the command identifier and command parameters as a second key-value pair and stores them in local storage. Based on the second key-value pair, a local preloading task is created, and a task maintenance timer for the local preloading task is started. Then, triggered by the task maintenance timer, each local preloading task is maintained based on its corresponding second key-value pair. This scheme, by first querying the distributed database for the existence of a duplicate task upon receiving a task creation command, and then performing subsequent operations, effectively avoids the duplicate creation of preloading tasks, thus achieving task deduplication. By creating a local preloading task that carries authentication skip parameters for preloading live streams, the content delivery network can differentiate between live stream preloading requests and regular live stream requests, skipping time-consuming authentication stages and thus improving the processing efficiency of preloading requests. Furthermore, through the interaction between physical nodes and a distributed database, this solution allows preloading tasks to be invoked and executed by other nodes in the distributed network, thereby improving the overall system reliability and fault tolerance. Therefore, this solution optimizes the processing flow of live stream preloading tasks, reducing processing time and ensuring system stability, thus enabling more efficient and reliable preloading of live content. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This is a diagram illustrating the application environment of the live streaming preloading method in one embodiment;

[0045] Figure 2 This is a flowchart illustrating a live streaming preloading method in one embodiment;

[0046] Figure 3 This is a flowchart illustrating the process of maintaining a local preloaded task in one embodiment;

[0047] Figure 4a flowchart of a process for maintaining local preloaded tasks in another embodiment;

[0048] Figure 5 a flowchart of a process for performing task deletion operations for local preloaded tasks in an embodiment;

[0049] Figure 6 a flowchart of a process for handling task deletion commands in an embodiment;

[0050] Figure 7 a flowchart of a process for performing task recovery in an embodiment;

[0051] Figure 8 a schematic diagram of an architecture for a preloaded task management system in an embodiment;

[0052] Figure 9 a block diagram of a structure of a live preloading apparatus in an embodiment;

[0053] Figure 10 a diagram of an internal structure of a computer device in an embodiment. DETAILED DESCRIPTION

[0054] In order to make the purposes, technical solutions and advantages of the present application clearer, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and should not be used to limit the present application.

[0055] The live preloading method provided by the embodiments of the present application can be applied in an application environment as shown in Figure 1 The terminal communicates with the content distribution network node through the network. The content distribution network node can be a cluster or a distributed system composed of multiple devices (for example, can include device 1, device 2, …, device N), wherein the computer device can be a server. The content distribution network node can communicate with other nodes in the content distribution network node cluster, and can directly or indirectly communicate with the live source. The live source can be a content distribution network source station or a terminal of a live initiator.

[0056] The terminal can be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers, Internet of Things devices, and portable wearable devices. The Internet of Things device can be a smart speaker, a smart television, a smart air conditioner, a smart vehicle-mounted device, a projection device, etc. The portable wearable device can be a smart watch, a smart bracelet, a head-mounted device, etc. The head-mounted device can be a virtual reality (VR) device, an augmented reality (AR) device, smart glasses, etc. The server can be a standalone physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0057] In an exemplary embodiment, as shown in Figure 2 , a live preloading method is provided, which is applied to the device 1 in Figure 1 , including the following steps:

[0058] Step S201, in the case of receiving a task creation command, obtaining the command identification and initial task parameters contained in the task creation command.

[0059] As shown in Figure 1 , the device in the content distribution network node can receive a task creation command from the terminal. Exemplarily, the task creation command can contain a command identification and initial task parameters. The command identification can be used to identify the live preloading task to be created, and the initial task parameters can include the resource address, start time, end time, timeout threshold, etc. of the live stream to be preloaded.

[0060] Step S202, in the case of querying that the command identification is not stored in the distributed database, obtaining the command parameter corresponding to the command identification according to the command identification, the initial task parameter and the current time.

[0061] As shown in Figure 1 , the device in the content distribution network node can query the distributed database through the distributed database service to confirm whether the command identification has been stored in the distributed database.

[0062] In the case of querying that the command identification is not stored in the distributed database, the command parameter can be obtained according to the command identification, the initial task parameter and the current time. Exemplarily, the command parameter can be represented as T t ={u t ,d t ,p t ,q t ,m t ,j t ,k t,f t i t ,s t}, where u t d is the resource address, used to indicate the address from which to retrieve the live stream t; t p is a command identifier used to identify the preloading task of the live stream t; t q is the start time of the live stream t; t m is the end time of the live stream t; t This is the timeout threshold; j t For the next execution time; k t For the final success time; f t i represents the total number of failures. t For instance parameters; s t These are task status parameters. Specifically, parameter u... t d t p t q t m t The parameter j can be obtained from the command identifier and initial task parameters. t It can be initialized to the start time p t Parameter k t It can be initialized to the start time p t Parameter f t It can be initialized to 0, parameter i t It can be initialized to an empty value, parameter s t It can be initialized to the task waiting state SI.

[0063] Step S203: Associate the command identifier and command parameters as a first key-value pair and store them in the distributed database.

[0064] For example, the command identifier d obtained according to the aforementioned process t and command parameter T t The two can be associated as a first key-value pair (d t :T t ), and store them in a distributed database.

[0065] Step S204: If the number of local tasks is less than the local task number threshold, associate the command identifier and command parameters as a second key-value pair and store them in the local memory. Create a local preload task based on the second key-value pair and start the task maintenance timer of the local preload task.

[0066] Wherein, the local task number can be the number of local preload tasks created and maintained by the device 1, and the local task number threshold can be used to represent the maximum number of local preload tasks that the device 1 can create. In the case where the local task number is less than the local task number threshold, the device 1 can command the association of the identification and the command parameter as a second key-value pair and store it in the local storage. Then, the device 1 can create a local preload task according to the command identification and the command parameter contained in the second key-value pair, and start the task maintenance timer of the task.

[0067] Wherein, as shown in Figure 1 The local preload task can perform the preloading of the live stream through the live gateway during the maintenance process. Wherein, the live gateway can be a gateway of a content delivery network (CDN). Alternatively, the local preload task can carry the authentication skipping parameter to perform the preloading of the live stream, and the live gateway can skip the authentication operation on the preloading request with the authentication skipping parameter when processing the preloading request.

[0068] Step S205, under the triggering of the task maintenance timer of each local preload task, each local preload task is maintained according to the second key-value pair corresponding to each local preload task.

[0069] Wherein, the task maintenance timer can count after being started, and trigger the task maintenance operation of the local preload task when the counting duration reaches the preset duration. Wherein, when maintaining the local preload task, the life cycle of the local preload task can be managed according to the second key-value pair, for example, the preloading and pulling of the live stream can be performed by creating a corresponding process instance, and the management of the end of pulling, pulling failure and the like can be performed.

[0070] In the above live preloading method, by querying whether the same task exists in the distributed database when receiving the task creation command, and then performing the subsequent operation, the repeated creation of the preloading task can be effectively avoided, and the task deduplication is realized. And by creating a local preload task that can carry an authentication skipping parameter to perform the preloading of the live stream, the authentication skipping parameter can be used to distinguish the preloading request of the live stream from the regular live request of the content delivery network, and the authentication and other time-consuming stages can be skipped, thereby improving the processing efficiency of the preloading request. Moreover, through the interaction between the physical node and the distributed database, the preloading task can be awakened and executed by other nodes in the distributed network, thereby improving the reliability and fault tolerance of the entire system. Therefore, the present scheme can optimize the processing flow of the live preloading task, which is conducive to reducing the processing time and ensuring the stability of the system, thereby realizing more efficient and reliable preloading of the live content.

[0071] In one example embodiment, as shown in Figure 3 According to the second key-value pair corresponding to each local preloading task, the maintenance of each local preloading task can include:

[0072] In step S301, according to the command parameters contained in the second key-value pair, the task state parameters, the next execution time, the resource address, and the instance parameters of the local preloading task are obtained.

[0073] The command parameters contained in the second key-value pair can include the task state parameters, the next execution time, the resource address, and the instance parameters of the local preloading task. Among them, the task state parameters s t can be initialized as the task waiting state SI, the next execution time j t is initialized as the start time p t , and the instance parameter i t can be initialized as a null value. During the maintenance of the local preloading task, the parameter values of these parameters can vary according to the specific scene. Among them, the resource address u t can indicate the address for obtaining the live stream.

[0074] In step S302, in the case that the instance parameter is a null value, the task state parameter is the task waiting state, and the next execution time is not later than the current time, a live stream pulling instance carrying an authentication skip parameter is generated according to the authentication skip identifier and the resource address.

[0075] When the instance parameter is a null value, it means that the local preloading task does not have a corresponding running live stream pulling instance. When the task state parameter is the task waiting state, it means that the task is waiting for execution. When the next execution time is not later than the current time, it means that the task can be attempted to execute at the current time. In this case, the authentication skip parameter can be generated according to the resource address and the preset authentication skip identifier, and then the live stream pulling instance can be created according to the authentication skip parameter and the resource address. Among them, the live stream pulling instance can send a preloading request carrying the authentication skip parameter to the content distribution network gateway.

[0076] Exemplarily, assuming that the authentication skip identifier is "skip" and the resource address is "http: / / abc.com / ***.flv", the authentication skip parameter skip=f(http: / / abc.com / ***.flv) can be obtained according to the identifier and the resource address processed by using the hash algorithm, where f() represents the hash algorithm. Exemplarily, the hash algorithm can be Message-Digest Algorithm version.5 (MD5). Then, the live stream pulling instance can be created according to the resource address, the instance can construct the address "http: / / abc.com / ***.flv?skip=f(http: / / abc.com / ***.flv)" carrying the authentication skip parameter and send a preloading request to the content distribution network, so that the gateway of the content distribution network can not perform authentication operation according to the authentication skip parameter after receiving the request.

[0077] In step S303, the live stream pulling instance is assigned to the instance parameter, and the task state parameter is assigned to the task running state.

[0078] In step S303, the live stream pulling instance is assigned to the instance parameter, and the task state parameter is assigned to the task running state.

[0079] In step S304, the first key-value pair corresponding to the local preloading task in the distributed database is attempted to be updated according to the task state parameter and the instance parameter.

[0080] In step S304, the first key-value pair corresponding to the local preloading task in the distributed database is attempted to be updated according to the task state parameter and the instance parameter.

[0081] In step S305, the second key-value pair of the local preloading task in the local storage is updated according to the task state parameter and the instance parameter in the case that the first key-value pair is successfully updated.

[0082] In step S305, the second key-value pair of the local preloading task in the local storage is updated according to the task state parameter and the instance parameter in the case that the first key-value pair is successfully updated.

[0083] In step S306, the task maintenance timer of the local preloading task is reset.

[0084] Wherein, after the update of the second key-value pair is completed, the task maintenance timer of the local preloading task can be reset to restart the counting.

[0085] In this embodiment, by creating the live stream pulling instance corresponding to the local preloading task in the maintenance process of the local preloading task, and carrying the authentication skipping parameter through the instance to pull the live stream, the gateway of the content distribution network can not perform authentication operation according to the authentication skipping parameter after receiving the request, thereby improving the processing efficiency. By updating the command parameter of the task in the maintenance process and updating it to the distributed database and the local storage, the distributed database and the local device can obtain the latest state of the task, so that the preloading task can be maintained according to the latest command parameter subsequently.

[0086] In an exemplary embodiment, after attempting to update the first key-value pair corresponding to the local preloading task in the distributed database according to the task state parameter and the instance parameter, the method can further include: in the case that the update of the first key-value pair fails, terminating the live stream pulling instance corresponding to the local preloading task, and setting the instance parameter to a null value; and deleting the second key-value pair corresponding to the local preloading task.

[0087] Wherein, when attempting to update the first key-value pair corresponding to the local preloading task in the distributed database, if it cannot be connected to the distributed database, or the corresponding first key-value pair cannot be found in the distributed database, or the modification of the first key-value pair is abnormal, it can be considered that the update of the first key-value pair fails. In this case, the live stream pulling instance created previously can be terminated, and the instance parameter can be set to a null value. Then, the second key-value pair corresponding to the local preloading task in the local storage can be deleted. Optionally, the task maintenance timer corresponding to the local preloading task can be stopped at the same time, thereby ending the maintenance process of the local preloading task.

[0088] In this embodiment, by terminating the local preloading task in the case that the update of the first key-value pair fails, the running of the live preloading task can be kept consistent with the record in the distributed database, which is conducive to improving the overall stability of the system.

[0089] In an example embodiment, the command parameter can include a last success time and a total failure number; after the live stream pulling instance is assigned to the instance parameter and the task state parameter is assigned to the task running state, the method can further include: in a case where a pulling success response of the live stream pulling instance is received, setting the last success time as an instance end time of the live stream pulling instance; according to the last success time, performing the step of attempting to update the first key-value pair corresponding to the local preloading task in the distributed database; or in a case where a pulling failure response of the live stream pulling instance is received, updating a next execution time of the local preloading task according to the total failure number and a preset maximum retry interval; updating the total failure number of the local preloading task, setting the instance parameter as a null value, and setting the task state parameter as a task waiting state; according to the next execution time, the total failure number, the instance parameter, and the task state parameter, performing the step of attempting to update the first key-value pair corresponding to the local preloading task in the distributed database.

[0090] The command parameter corresponding to the preloading task can further include a last success time and a total failure number. The last success time can be used to indicate a time at which the preloading task successfully performs live stream pulling for the last time, and the total failure number can be used to indicate a number of consecutive failures of the preloading task in performing live stream pulling after the preloading task is created. When the preloading task is created, the last success time can be initialized as a start time, and the total failure number can be initialized as 0. During maintenance of the local preloading task, the parameter values of these parameters can change according to specific scenarios.

[0091] Optionally, after the live stream pulling instance corresponding to the local preloading task is created, a state of the live stream pulling instance can be monitored until the live stream pulling instance ends. According to different responses of the live stream pulling instance received, different processing can be performed.

[0092] When a pulling success response of the live stream pulling instance is received, an instance end time of the live stream pulling instance can be assigned to the last success time. Then, according to the updated last success time, the step of attempting to update the first key-value pair corresponding to the local preloading task in the distributed database in the foregoing embodiment can be performed, and according to whether the first key-value pair is successfully updated, different processing of subsequent objects such as the second key-value pair, the task maintenance timer, and the live stream pulling instance can be performed.

[0093] When a pulling failure response of the live stream pulling instance is received, a next execution time of the local preloading task can be updated according to a total failure number before this failure and a preset maximum retry interval. For example, according to the total failure number f t , the maximum retry interval I max , a new next execution time j tFor n+min(2f) t 2 ,I max ), where n is the current time, and min represents the minimum value. Then, the total number of failures can be updated, based on the original total number of failures f. t Add 1 to the basic requirement. Additionally, you can set the instance parameter of the local preload task to null and the task status parameter to a task waiting state.

[0094] Then, similar to the case of receiving a successful pull response, the next execution time after this update, the total number of failures, instance parameters, and task status parameters can be used to attempt to update the first key-value pair corresponding to the local preloaded task in the distributed database. Depending on whether the first key-value pair is successfully updated, different processing can be performed on subsequent objects such as the second key-value pair, the task maintenance timer, and the live stream pull instance.

[0095] In this embodiment, different handling methods are adopted for different scenarios of whether the live stream is successfully retrieved, which can adapt to the volatility of live stream resources and effectively improve the fault tolerance and stability of the system. In particular, in the case of failure, a lazy retry strategy can be used to ensure that preloading continues, while avoiding unnecessary impact on task management performance caused by frequent retries.

[0096] In one exemplary embodiment, such as Figure 4 As shown, maintaining each local preloading task based on the second key-value pair corresponding to each local preloading task can include:

[0097] Step S401: Based on the command parameters contained in the second key-value pair, obtain the instance parameters, last success time, end time, and task status parameters of the local preloaded task.

[0098] The command parameters can include instance parameters of the locally preloaded task, last success time, end time, and task status parameters.

[0099] Step S402: If the instance parameter is not empty, then set the last success time to the current time and set the task status parameter to the task running status.

[0100] If the instance parameter is not empty, it means that the local preloading task has a corresponding running live stream fetch instance. In this case, the last success time can be set to the current time, and the task status parameter can be set to the task running status.

[0101] Step S403, if the task state parameter is the task running state and the end time is earlier than the current time, terminate the live stream pulling instance corresponding to the instance parameter, set the instance parameter to be null, and set the task state parameter to be the task end state.

[0102] If the end time corresponding to the local preloading task is earlier than the current time, it can be determined that the live corresponding to the local preloading task has ended. Based on this, for the local preloading task with the instance parameter being non-null, the task state parameter being the task running state, and the end time being earlier than the current time, the live stream pulling instance corresponding to the instance parameter can be terminated, and the instance parameter can be set to be null. Meanwhile, the task state parameter of the local preloading task can be set to be the task end state.

[0103] Step S404, if the task state parameter is the task waiting state and the interval between the last success time and the current time is not less than the timeout threshold, set the task state parameter to be the task timeout state.

[0104] If the command parameter corresponding to the local preloading task does not satisfy the conditions of steps S402 and S403, it can be determined whether the task state parameter is the task waiting state, and whether the interval between the last success time and the current time is less than the timeout threshold.

[0105] If the task state parameter is the task waiting state, it means that the local preloading task does not have a corresponding running live stream pulling instance, but is in a state of waiting for pulling again. If the interval between the last success time of the task and the current time is not less than the timeout threshold, it can be determined that the pulling retry of the task has timed out. Based on this, the task state parameter can be set to be the task timeout state.

[0106] Step S405, in the case that the task state parameter is the task end state or the task timeout state, perform the task deletion operation of the local preloading task.

[0107] If the task state parameter of the local preloading task is the task end state or the task timeout state, the task deletion operation can be performed on the local preloading task. The task deletion operation can delete the first key-value pair, the second key-value pair, and other related data of the local preloading task, and end the maintenance of the local preloading task.

[0108] In this embodiment, various different situations that can occur in the live data preloading process are considered and processed respectively, so that the life cycle of the preloading task can be finely controlled.

[0109] In an exemplary embodiment, as Figure 5As shown, the task deletion operation of performing the local preloading task can include:

[0110] In step S501, connection to the distributed database is attempted.

[0111] In the case where the task deletion operation of performing the local preloading task is required, connection to the distributed database is first attempted.

[0112] In step S502, in the case of a failed connection, the second key-value pair corresponding to the local preloading task is updated according to the task state parameter, or the task state parameter and the instance parameter, and the task maintenance timer is reset.

[0113] In the case where connection to the distributed database fails or is abnormal, the second key-value pair of the local preloading task can be updated first. Specifically, when the task state parameter of the local preloading task changes, the corresponding second key-value pair in the local storage can be updated according to the task state parameter; and when both the task state parameter and the instance parameter of the local preloading task change, the second key-value pair can be updated according to the new task state parameter and the instance parameter.

[0114] Then, the task maintenance timer of the local preloading task can be reset to restart timing. It can be understood that when the task maintenance timer is triggered again, the task deletion operation of the local preloading task can be performed again.

[0115] In step S503, in the case of a successful connection, the first key-value pair corresponding to the local preloading task in the distributed database is attempted to be deleted.

[0116] In the case where the distributed database is successfully connected, the first key-value pair corresponding to the command identifier of the local preloading task can be attempted to be found in the distributed database and deleted.

[0117] In step S504, if the first key-value pair is successfully deleted, the second key-value pair corresponding to the local preloading task is deleted, and the task end information of the local preloading task is sent.

[0118] In the case where the first key-value pair is successfully deleted, the second key-value pair corresponding to the local preloading task in the local storage can be deleted. Then, the task end information of the local preloading task can be sent to the terminal.

[0119] In step S505, if the first key-value pair is not successfully deleted, the second key-value pair corresponding to the local preloading task is deleted.

[0120] When other devices in the content distribution network cluster perform a task deletion operation on the local preloading task, the first key-value pair can not exist in the distributed database, resulting in a first key-value pair deletion failure. In this case, the second key-value pair corresponding to the local preloading task can be deleted from the local memory.

[0121] In this embodiment, by determining whether a task deletion operation is needed according to the task state parameter of the preloading task, and performing corresponding data deletion in the distributed database and locally when the task deletion operation is needed, the consistency and integrity of the data can be ensured, the residual of the task data in the system can be effectively avoided, and the resource utilization rate can be improved.

[0122] In an exemplary embodiment, as shown in Figure 6 The method can further include:

[0123] Step S601, in a case where a task deletion command is received, a command identifier included in the task deletion command is obtained.

[0124] As shown in Figure 1 The device 1 can receive a task deletion command from the terminal. The task deletion command can include a command identifier, which can be used to indicate the preloading task of the live stream to be deleted.

[0125] Optionally, after receiving the task deletion command, the device 1 can also check the legality of the parameters included in the task deletion command. If it is not legal, the device 1 can send a response exception information to the terminal.

[0126] Step S602, in a case where it is determined by querying that the command identifier is stored in the distributed database, a first key-value pair corresponding to the command identifier is attempted to be deleted from the distributed database.

[0127] The command identifier can be used to query the distributed database to determine whether the command identifier is stored in the distributed database. In a case where it is determined by querying that the command identifier is stored in the distributed database, the first key-value pair corresponding to the command identifier can be attempted to be deleted from the distributed database.

[0128] Optionally, if the command identifier does not exist in the distributed database, or the deletion of the first key-value pair corresponding to the command identifier fails, a response exception information can be sent to the terminal.

[0129] Step S603, in a case where the first key-value pair is successfully deleted, it is queried whether a second key-value pair corresponding to the command identifier is stored in the local memory.

[0130] In a case where the first key-value pair is deleted successfully, the device 1 can query whether the second key-value pair corresponding to the command identifier is stored in the local storage according to the command identifier.

[0131] Optionally, in a case where the query determines that the second key-value pair corresponding to the command identifier is not stored in the local storage, it can be determined that the local preloaded task corresponding to the command identifier is not maintained in the device 1. In this case, the device 1 can send the terminal the task end information of the preloaded task corresponding to the command identifier.

[0132] Step S604, if the second key-value pair exists, stopping the task maintenance timer of the local preloaded task corresponding to the second key-value pair, and terminating the live streaming pulling instance corresponding to the local preloaded task.

[0133] In a case where it is determined that the second key-value pair corresponding to the command identifier is stored in the local storage, it can be determined that the local preloaded task corresponding to the command identifier is created and maintained in the device 1. Based on this, the task maintenance timer of the local preloaded task can be stopped, so as to terminate the maintenance process of the task. Meanwhile, according to the instance parameter contained in the second key-value pair, it can be judged whether the task has a running live streaming pulling instance, and if so, the live streaming pulling instance can be terminated to stop pulling the corresponding live streaming.

[0134] Step S605, deleting the second key-value pair, and sending the task end information of the local preloaded task.

[0135] In a case where the foregoing operations are performed, the second key-value pair can be deleted in the local storage, and the terminal can be sent the task end information of the local preloaded task.

[0136] In this embodiment, by performing corresponding data deletion in the distributed database and the local storage in a case where the task deletion command is received, the consistency and integrity of data can be ensured, the residual of task data in the system can be effectively avoided, and the resource utilization rate can be improved.

[0137] In one exemplary embodiment, as shown in Figure 7 the method can further include:

[0138] Step S701, under the triggering of the task recovery timer, acquiring the weight value of each first key-value pair in the distributed database.

[0139] Specifically, the first key-value pair in the distributed database can be stored in association with a corresponding weight value. The weight value can be obtained according to the last update time of the first key-value pair. For example, when the first key-value pair is stored in the distributed database, the weight value thereof can be the storage time, and when the device in the content distribution network maintains the local preloading task that has been created and updates the corresponding first key-value pair in the distributed database, the weight value of the first key-value pair can be updated to the update time accordingly.

[0140] The device in the content distribution network can set a task recovery timer, which can be counted down after being started, and trigger the device to perform a task recovery operation when the counting duration reaches a preset duration. Under the triggering of the task recovery timer, the device in the content distribution network can first obtain the weight values of the first key-value pairs in the distributed database.

[0141] Step S702: According to the weight values of the first key-value pairs and a preset task expiration duration, expired key-value pairs are selected from the first key-value pairs.

[0142] According to the preset task expiration duration T, the task expiration time t = n-T can be obtained in combination with the current time n. Assuming that the first key-value pairs and the corresponding weight values are stored in the distributed database by using the task set Z with weights, the first key-value pairs with weight values less than t (i.e., the last update time is before the task expiration time) can be selected from the task set Z as expired key-value pairs according to the weight values of the first key-value pairs.

[0143] Step S703: According to the local task recovery number and the weight values of the expired key-value pairs, the to-be-recovered key-value pairs are selected from the expired key-value pairs; and the weight values of the to-be-recovered key-value pairs are updated according to the current time.

[0144] The local task recovery number can be the number of tasks that can be recovered by the device. For example, it can be obtained according to the local task number x, the local task number threshold N max , the preset maximum number of task recovery R max , and the number of expired key-value pairs len(z) (where z is the set of expired key-value pairs), and the local task recovery number can be represented as r = min(N max -x, R max , len(z)).

[0145] For the set of expired key-value pairs z, the expired key-value pairs can be sorted in ascending order of weight values (i.e., descending order of last update times), and then according to the local task recovery number r, the set z can be traversed from 0 to r, and the first r expired key-value pairs in the set z can be selected as to-be-recovered key-value pairs. Then, each to-be-recovered key-value pair di The weight value of i (0<=i

[0146] Optionally, after the key-value pair to be recovered is screened out, it can be checked whether the command parameter contained in the query is empty, and if it is empty, the key-value pair to be recovered can be deleted from the distributed database.

[0147] In step S704, if the second key-value pair corresponding to the key-value pair to be recovered is not stored in the local storage, the key-value pair to be recovered is stored in the local storage.

[0148] In the foregoing, for the key-value pair to be recovered screened out, it can be checked whether the second key-value pair corresponding to the key-value pair to be recovered is stored in the local storage. If the key-value pair to be recovered does not have the second key-value pair stored in the local storage, the key-value pair to be recovered can be stored in the local storage as a new second key-value pair.

[0149] It can be understood that when the key-value pair to be recovered has the second key-value pair stored in the local storage, the key-value pair to be recovered can be skipped, and the next key-value pair to be recovered is judged.

[0150] In step S705, a local preloading task is created according to the key-value pair to be recovered, and a task maintenance timer of the local preloading task is started.

[0151] In the foregoing, after the key-value pair to be recovered is stored in the local storage, it can be taken as a new second key-value pair, a local preloading task is created according to the command parameter contained therein, and a task maintenance timer of the local preloading task is started.

[0152] In step S706, the task recovery timer is reset.

[0153] In the foregoing, after the task recovery process is completed once, the task recovery timer can be reset so as to start timing again to trigger the next task recovery process after a preset time period.

[0154] In the embodiment, by setting the task recovery mechanism, the node of the content distribution network can actively wake up the expired preloading task, guarantee the complete execution of the task, and greatly improve the robustness and disaster recovery capability of the system.

[0155] In an example embodiment, before the step of obtaining the weight value of each first key-value pair in the distributed database, the method further comprises: obtaining a distributed lock of the distributed database; in a case where the distributed lock is obtained, performing the step of obtaining the weight value of each first key-value pair in the distributed database; and in a case where the distributed lock fails to be obtained, resetting the task recovery timer. After the weight value of each to-be-recovered key-value pair is updated according to the current time, the method further comprises: releasing the distributed lock; and in a case where the distributed lock fails to be released, resetting the task recovery timer.

[0156] In the process of task recovery, since operations on the distributed database are involved, a distributed lock can be used to ensure data consistency.

[0157] Specifically, before the weight value of each first key-value pair is obtained, the distributed lock of the distributed database can be first attempted to be obtained, and the weight value of each first key-value pair is obtained only in a case where the distributed lock is successfully obtained. In a case where the distributed lock fails to be obtained, the task recovery timer can be reset, so as to wait for a preset time length and then attempt to perform task recovery again.

[0158] Similarly, after the weight value of each to-be-recovered key-value pair is updated according to the current time, the distributed lock obtained previously can be released. In a case where the distributed lock is successfully released, the subsequent recovery process is performed again. In a case where the distributed lock fails to be released, the task recovery timer can be reset, so as to wait for a preset time length and then attempt to perform task recovery again.

[0159] In the embodiment, through application of the distributed lock, mutual access of different content distribution network nodes to the distributed database can be ensured, so as to avoid problems such as data inconsistency caused by concurrent operations.

[0160] In order to further describe the live preloading method of the present application, the following describes the live preloading method through detailed embodiments:

[0161] Specifically, the live preloading method in the embodiment can be performed by a preloading task management system as shown in FIG. 1. Figure 8 The system can be configured in a device of a content distribution network node.

[0162] In the embodiment, the live preloading method can be divided into five parts: initialization, task creation, task maintenance, task deletion, and task recovery. The initialization part can connect a distributed database and start a service; the task creation part can record task information and start an exclusive task maintenance timer for each task; the task maintenance part can manage the execution life cycle of a task; the task deletion part can clear task information, terminate preloading stream pulling, and initiate a callback request to notify the end of a task; and the task recovery part can read expired tasks from the distributed database and load and execute the tasks locally.

[0163] The initialization part can include the following steps:

[0164] Step S801, initialize and start the distributed database cluster, and if the initialization fails, the process ends.

[0165] Step S802, start the task recovery timer, and execute the task recovery part in the background.

[0166] Step S803, start the local preloading service and continuously listen. If a task creation command is received, execute the task creation part; if a task deletion command is received, execute the task deletion part; if the service is closed actively, the process ends; otherwise, continuously listen and wait.

[0167] The task creation part can include the following steps:

[0168] Step S811, check the legality of the parameters of the task creation command, and if the parameters are not legal, respond to an exception and execute step S803.

[0169] Step S812, obtain the command identifier d t and the initial task parameters contained in the task creation command. Query the distributed database to determine whether the same d t exists, and if the same d t exists, respond to an exception and execute step S803.

[0170] Step S813, define the current time n, and obtain the resource address u t of the live stream that needs to be preloaded, the start time p t , the end time q t , and the timeout threshold m t according to the initial task parameters. Define the next execution time j t , the last successful time k t , the instance parameter i t , the task state parameter s t , and initialize the parameter j t to the start time p t , the parameter k t to the start time p t , the parameter f t to 0, the parameter i t to an empty value, and the parameter s t to the task waiting state SI. Then, the command parameters T t ={u t ,d t ,p t ,q t ,m t ,j t ,kt ,f t i t ,s t Simultaneously, a weighted task set Z can be defined in the distributed database, and the command identifier and command parameters can be associated as the first key-value pair (d). t :T t Write Z with weight n. If writing to Z fails, a failure response is issued, and step S803 is executed.

[0171] Step S814, when the number of local tasks x is greater than the local task number threshold N. max In the case where the preloading task is registered with the distributed database but does not need to be executed locally, the response is successful, and step S803 is executed. Otherwise, the command identifier and command parameters are associated as a second key-value pair (d). t :T t Store the data in local memory, create a local preload task based on the second key-value pair, and start the task maintenance timer I for the local preload task. w The background parallel execution of the task maintenance part, upon successful response, proceeds to step S803.

[0172] The task maintenance section may include the following steps:

[0173] Step S821, based on the second key-value pair (d t :T t ), determine the command identifier d t Whether to store it in local memory; if not, the process ends.

[0174] Step S822, determine instance parameter i t Is it a null value? If the instance parameter i t If the value is non-empty, then the last success time k will be... t Set the current time n, and set the task status parameter s. t Set the task running status to SR.

[0175] Step S823, if the end time q t Earlier than the current time n, and the task status parameter s t If the task is in running state SR, then the instance parameter i will be terminated. t The corresponding live stream retrieval instance will use the instance parameter i. t Set the task status parameter s to the null value nil. t Set the task to the completed state (SE).

[0176] Step S824, if the final success time k t With timeout threshold m t The sum is greater than the current time n, and the task status parameter st For the task waiting state SI, set the task state parameter s. t Set the task to timeout status ST.

[0177] Step S825, if the task status parameter s t If the task is in a completed state (SE), a timed-out state (ST), or a voluntary stop state (SS), then delete d from Z in the distributed database. t First key-value pair (d t :T t If a connection error occurs during deletion, the local storage updates the second key-value pair (d). t :T t Reset task maintenance timer I w After waiting for the appropriate time, step S821 is executed again. If the first key-value pair is successfully deleted, the second key-value pair (d) in the local memory is deleted. t :T t The callback notification task has been completed, and the process ends. If the deletion of the first key-value pair fails, it indicates that the deletion task was caused by a service on another machine. t If empty, delete the second key-value pair (d) from local storage. t :T t The process is now complete.

[0178] Step S826, if the task status parameter s t The task is in a waiting state SI and the next execution time is j. t <= current time n, for resource address u t Generate authentication skip parameters, combine with the micro-stream client to generate a preload stream command, execute the preload stream command in the background to pull the stream to the content delivery network, and assign the live stream pull instance to the instance parameter i. t Background check i t In the current state, execute step S827 in parallel, and the main process executes step S829.

[0179] Step S827, if instance parameter i t Once the corresponding live stream retrieval instance is complete, proceed to step S828; otherwise, wait indefinitely.

[0180] Step S828: If a successful pull response is received, the last successful time k is recorded. t Set the instance end time for the live stream fetch instance, i.e., the current time n, and the total number of failures f. t Set to 0; if a fetch failure response is received, calculate the next execution time j. t ←n+min(2f t 2 ,I max ), where Imax Set the maximum retry interval; and update the total number of failures f. t ←f t +1, and the instance parameter i t Set to the null value nil. Where the task status parameter s... t If the task is in running state SR, then set it to task waiting state SI.

[0181] Step S829, update the first key-value pair (d) in the distributed database. t :T t Update d in Z according to the current time. t The weights. If updating the first key-value pair and its weights fails, the instance parameter i is terminated. t The corresponding live stream retrieval instance will use the instance parameter i. t Set to nil, delete the second key-value pair (d) in local memory. t :T t If the process ends, the second key-value pair (d) is updated in local memory. t :T t Reset maintenance timer I w After waiting for the appropriate amount of time, step S821 will be executed again.

[0182] The task deletion section may include the following steps:

[0183] Step S831: Check the validity of the parameters of the task deletion command. If the parameter is invalid, an error will be triggered. Then proceed to step S803.

[0184] Step S832: Query the distributed database to see if the command identifier d contained in the task deletion command exists. t If it does not exist, an exception will be triggered, and step S803 will be executed.

[0185] Step S833: Delete the first key-value pair (d) in the distributed database. t :T t If deletion fails, a failure response will be issued, and step S803 will be executed.

[0186] Step S834: Check if the command identifier d exists in the local memory. t If it exists, it means the task is executed on the local machine. In this case, stop the corresponding task maintenance timer and terminate its instance parameter i. t The corresponding live stream retrieval instance will use the instance parameter i. t Setting it to nil deletes the second key-value pair (d) from local memory. t :T t ).

[0187] Step S835, set the task status parameter st Set to task active stop state SS, send task end information, response success, execute step S803.

[0188] The task recovery part can include the following steps:

[0189] Step S841, define a distributed lock l, and lock on l. If the locking fails, reset the task recovery timer I h The task recovery part is executed after it is triggered again.

[0190] Step S842, define an expiration threshold t = n - T, where T is a preset task expiration time length. Define a set z of expired key-value pairs in Z that satisfy the weight value less than t. If the distributed database connection fails or z is empty, the distributed lock l is unlocked, and the task recovery timer I is reset h The task recovery part is executed after it is triggered again.

[0191] Step S843, define the number x of local tasks in the local storage, and define the local task recovery number r = min(N max -x, R max , len(z)), where R max is a preset maximum number of task recovery. The r expired key-value pairs with the smallest weight values in z are taken as the to-be-recovered key-value pairs, and the weight values of d i (0 <= i < r) in Z are updated to the current time n.

[0192] Step S844, release the distributed lock l. If the release fails, reset the task recovery timer I h The task recovery part is executed after it is triggered again.

[0193] Step S845, traverse the to-be-recovered key-value pairs (d i : T i )(0 <= i < r) in the distributed database. If T i is not empty and the connection is not abnormal, it is judged whether the corresponding second key-value pair is stored in the local storage. If yes, the next traversal is continued, otherwise the to-be-recovered key-value pair (d i : T i ) is recorded in the local storage, a corresponding task maintenance timer is started, and a task maintenance part is executed in the background in parallel. If T i is empty, the to-be-recovered key-value pair and its command identifier d i in Z are deleted. The task recovery timer I is reset h The task recovery part is executed after it is triggered again.

[0194] The technical effects of the embodiment include:

[0195] 1. The embodiment can realize fine management of the life cycle of content distribution network live streaming preloading tasks: The real-time and unpredictability of live streaming resources pose great challenges to preloading. Considering the uncertainty of the host's starting time, the timing of triggering the preloading task is particularly important. The scheme of the embodiment supports heating up the live streaming according to the preset start time, end time or stream pulling duration, and initiating a callback notification after the task is completed. This flexible time setting makes the preloading process of live streaming data more certain and efficient. In addition, for the volatility of live streaming resources, even if the real-time streaming data is temporarily interrupted, the task management mechanism of the embodiment can ensure the continuous preloading through the lazy retry strategy, while avoiding unnecessary impact on task management performance caused by frequent retries. For the problem of task loss, based on the efficient mechanism of distributed database, the embodiment can quickly wake up the preloading task on other healthy nodes of the cluster to ensure the complete execution of the task, thereby greatly improving the robustness and disaster recovery capability of the system.

[0196] 2. Seamless adaptation of content distribution network live streaming preloading task management and content distribution network: The preloading task management method of the embodiment adopts a decoupled design from the content distribution network live streaming gateway, ensuring that the performance of the content distribution network is not affected while being easy to maintain and manage. Combined with the data management mechanism of the distributed database and the architectural advantages of the cloud content distribution network, seamless integration with the content distribution network can be achieved without additional distributed nodes or database clusters. At the same time, the data consistency feature of the distributed database ensures that task creation or deletion commands sent to any preloading task management service can achieve unique management of the task.

[0197] 3. De-duplication of content distribution network live streaming preloading tasks: In traditional management methods, users often send excessive preloading requests due to the lack of effective management mechanisms, which not only increases the burden on the content distribution network, but also can cause unnecessary Query per Second (QPS) increase and cache size increase. The de-duplication mechanism of the embodiment can automatically identify and filter out redundant preloading requests, thereby reducing the pressure on the content distribution network and improving overall performance.

[0198] 4. Rapid identification of content distribution network live streaming preloading tasks: Preloading tasks are distinguished by specific identifiers, which enable the system to quickly identify and process these tasks. By skipping the time-consuming authentication phase of the content distribution network gateway, the preloading task identification mechanism of the embodiment significantly improves processing efficiency and reduces the performance overhead of the content distribution network. This feature not only ensures user experience, but also further improves the efficiency of the content distribution network.

[0199] It should be understood that although each step in the flowchart involved in the above embodiments is shown in sequence according to the arrow, these steps are not necessarily executed in the order indicated by the arrow. Unless otherwise specified herein, the execution of these steps is not strictly limited in sequence, and these steps can be executed in other orders. Moreover, at least part of the steps in the flowchart involved in the above embodiments can include multiple steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily sequential, but can be alternately executed with at least part of other steps or steps or stages in other steps.

[0200] Based on the same inventive concept, the embodiments of the present application also provide a live preloading device for implementing the live preloading method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme described in the above method, so the specific limitations in one or more live preloading device embodiments provided below can refer to the limitations of the live preloading method in the above text, which will not be repeated here.

[0201] In one exemplary embodiment, as shown in Figure 9 A live preloading device 900 is provided, comprising:

[0202] A creation command receiving module 901 is configured to, in a case where a task creation command is received, acquire a command identifier and initial task parameters contained in the task creation command;

[0203] An initial parameter acquiring module 902 is configured to, in a case where the command identifier is not stored in the distributed database, acquire command parameters corresponding to the command identifier according to the command identifier, the initial task parameters, and a current time;

[0204] A first key-value pair storage module 903 is configured to store the command identifier and the command parameters as a first key-value pair into the distributed database;

[0205] A local task creating module 904 is configured to, in a case where the number of local tasks is less than a local task number threshold, store the command identifier and the command parameters as a second key-value pair into a local storage, create a local preloading task according to the second key-value pair, and start a task maintenance timer of the local preloading task. The local preloading task is used to carry an authentication skipping parameter to pre-load a live stream. The authentication skipping parameter is used to instruct a content distribution network node not to authenticate a pre-loading request of the live stream.

[0206] The local task maintenance module 905 is configured to, under triggering of the task maintenance timer of each local preloaded task, maintain each local preloaded task according to the second key-value pair corresponding to each local preloaded task.

[0207] In an exemplary embodiment, the local task maintenance module 905 is further configured to: obtain a task state parameter, a next execution time, a resource address, and an instance parameter of the local preloaded task according to the command parameter contained in the second key-value pair; in a case where the instance parameter is a null value, the task state parameter is a task waiting state, and the next execution time is not later than the current time, generate a live stream pulling instance carrying the authentication skipping parameter according to an authentication skipping identifier and the resource address; the live stream pulling instance is configured to send the preloaded request carrying the authentication skipping parameter to the content distribution network; assign the live stream pulling instance to the instance parameter, and assign the task state parameter to a task running state; attempt to update the first key-value pair corresponding to the local preloaded task in the distributed database according to the task state parameter and the instance parameter; in a case where the first key-value pair is updated successfully, update the second key-value pair of the local preloaded task in the local storage according to the task state parameter and the instance parameter; and reset the task maintenance timer of the local preloaded task.

[0208] In an exemplary embodiment, the local task maintenance module 905 is further configured to: in a case where the first key-value pair fails to be updated, terminate the live stream pulling instance corresponding to the local preloaded task, and set the instance parameter to a null value; and delete the second key-value pair corresponding to the local preloaded task.

[0209] In an exemplary embodiment, the command parameter includes a last success time and a total failure number; the local task maintenance module 905 is further configured to: in a case where a pulling success response of the live stream pulling instance is received, set the last success time to an instance end time of the live stream pulling instance; perform the step of attempting to update the first key-value pair corresponding to the local preloaded task in the distributed database according to the last success time; in a case where a pulling failure response of the live stream pulling instance is received, update the next execution time of the local preloaded task according to the total failure number and a preset maximum retry interval; update the total failure number of the local preloaded task, set the instance parameter to a null value, and set the task state parameter to a task waiting state; and perform the step of attempting to update the first key-value pair corresponding to the local preloaded task in the distributed database according to the next execution time, the total failure number, the instance parameter, and the task state parameter.

[0210] In an example embodiment, the local task maintenance module 905 is further configured to: obtain, according to the command parameter contained in the second key-value pair, an instance parameter, a last success time, an end time, and a task state parameter of the local preloaded task; set the last success time as the current time and the task state parameter as a task running state if the instance parameter is a non-empty value; terminate a live stream pulling instance corresponding to the instance parameter, set the instance parameter as a null value, and set the task state parameter as a task end state if the task state parameter is the task running state and the end time is earlier than the current time; set the task state parameter as a task timeout state if the task state parameter is a task waiting state and the interval between the last success time and the current time is not less than a timeout threshold; and perform a task deletion operation of the local preloaded task if the task state parameter is the task end state or the task timeout state.

[0211] In an example embodiment, the local task maintenance module 905 is further configured to: attempt to connect to the distributed database; update the second key-value pair corresponding to the local preloaded task according to the task state parameter or the task state parameter and the instance parameter if the connection fails; reset the task maintenance timer; attempt to delete the first key-value pair corresponding to the local preloaded task from the distributed database if the connection succeeds; delete the second key-value pair corresponding to the local preloaded task and send task end information of the local preloaded task if the first key-value pair is successfully deleted; and delete the second key-value pair corresponding to the local preloaded task if the deletion of the first key-value pair fails.

[0212] In an example embodiment, the apparatus further includes: a deletion command receiving module configured to obtain a command identifier contained in a task deletion command if the task deletion command is received; a first key-value pair deleting module configured to attempt to delete a first key-value pair corresponding to the command identifier from the distributed database if it is determined by a query that the command identifier is stored in the distributed database; a second key-value pair querying module configured to query whether a second key-value pair corresponding to the command identifier is stored in the local storage if the first key-value pair is successfully deleted; a local task terminating module configured to stop the task maintenance timer of a local preloaded task corresponding to the second key-value pair and terminate a live stream pulling instance corresponding to the local preloaded task if the second key-value pair exists; and a local task deleting module configured to delete the second key-value pair and send task end information of the local preloaded task.

[0213] In an example embodiment, the apparatus further comprises: a weight obtaining module configured to obtain a weight value of each of the first key-value pairs in the distributed database upon triggering of the task recovery timer; the weight value is obtained according to a last update time of the first key-value pair; a first screening module configured to screen expired key-value pairs from the first key-value pairs according to the weight value of each of the first key-value pairs and a preset task expiration time length; a second screening module configured to screen a to-be-recovered key-value pair from the expired key-value pairs according to a local task recovery number and the weight value of each of the expired key-value pairs; update the weight value of each of the to-be-recovered key-value pairs according to a current time; a to-be-recovered key-value pair storage module configured to store the to-be-recovered key-value pair to the local storage if the local storage does not store a second key-value pair corresponding to the to-be-recovered key-value pair; a recovery task creating module configured to create a local preloading task according to the to-be-recovered key-value pair, and start a task maintenance timer of the local preloading task; and a recovery timer resetting module configured to reset the task recovery timer.

[0214] In an example embodiment, the apparatus further comprises: a distributed lock obtaining module configured to obtain a distributed lock of the distributed database; in a case where the distributed lock is obtained, the step of obtaining the weight value of each of the first key-value pairs in the distributed database is performed; in a case where the distributed lock is not obtained, the task recovery timer is reset; a distributed lock releasing module configured to release the distributed lock; and in a case where the distributed lock is not released, the task recovery timer is reset.

[0215] The above-mentioned modules in the live preloading apparatus can be all or partially realized by software, hardware, and combinations thereof. The above-mentioned modules can be embedded in or independent of a processor in a computer device in a hardware form, or stored in a memory in a computer device in a software form, so as to be called and executed by a processor to perform operations corresponding to the above-mentioned modules.

[0216] In an example embodiment, a computer device is provided, which can be a server, and an internal structure diagram of the computer device can be as shown in FIG. 8. Figure 10As shown in the figure. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through the system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capability. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store command identification, initial task parameters, second key-value pairs and other data. The input / output interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with external terminals through network connection. The computer program is executed by the processor to implement a live preloading method.

[0217] Those skilled in the art can understand that, Figure 10 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different component arrangement.

[0218] In one embodiment, a computer device is also provided, including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps in each of the above method embodiments.

[0219] In one embodiment, a computer readable storage medium is provided, which stores a computer program, and the computer program is executed by a processor to implement the steps in each of the above method embodiments.

[0220] In one embodiment, a computer program product is provided, including a computer program, and the computer program is executed by a processor to implement the steps in each of the above method embodiments.

[0221] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant regulations.

[0222] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, the processes of the above-mentioned embodiments can be included. Any reference to memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. The non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. The volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration but not limitation, the RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., and is not limited thereto. The processor involved in the embodiments provided in the present application can be a general processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., and is not limited thereto.

[0223] The technical features of the above embodiments can be combined arbitrarily. In order to make the description simple, all possible combinations of the technical features in the above embodiments are not described, but as long as the combinations of the technical features do not exist, they should be considered as the scope of the present application.

[0224] The above embodiments only express several implementation ways of the present application, and the description is specific and detailed, but it should not be understood as a limitation to the patent scope of the present application. It should be pointed out that for ordinary skilled in the art, without departing from the concept of the present application, several modifications and improvements can be made, which all belong to the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. A live preloading method, characterized by, The method comprises: In the case of receiving a task creation command, obtaining the command identification and initial task parameters contained in the task creation command; In the case of not storing the command identification in the distributed database, obtaining the command parameters corresponding to the command identification according to the command identification, initial task parameters and current time; Storing the command identification and the command parameters as a first key-value pair into the distributed database; In the case of the local task number being less than the local task number threshold, storing the command identification and the command parameters as a second key-value pair into the local storage, creating a local preloading task according to the second key-value pair, starting a task maintenance timer of the local preloading task; the local preloading task is used to carry an authentication skipping parameter for preloading of a live stream; the authentication skipping parameter is used to indicate that the content distribution network does not authenticate the preloading request of the live stream; Under the triggering of the task maintenance timer of each local preloading task, maintaining each local preloading task according to the second key-value pair corresponding to each local preloading task.

2. The method of claim 1, wherein, The maintaining each local preloading task according to the second key-value pair corresponding to each local preloading task comprises: Obtaining the task state parameter, next execution time, resource address and instance parameter of the local preloading task according to the command parameters contained in the second key-value pair; In the case of the instance parameter being a null value, the task state parameter being a task waiting state and the next execution time being not later than the current time, generating a live stream pulling instance carrying the authentication skipping parameter according to the authentication skipping identifier and the resource address; the live stream pulling instance is used to send the preloading request carrying the authentication skipping parameter to the content distribution network; Assigning the live stream pulling instance to the instance parameter and assigning the task state parameter to a task running state; Attempting to update the first key-value pair corresponding to the local preloading task in the distributed database according to the task state parameter and the instance parameter; In the case of successful updating of the first key-value pair, updating the second key-value pair of the local preloading task in the local storage according to the task state parameter and the instance parameter; Resetting the task maintenance timer of the local preloading task.

3. The method of claim 2, wherein, After the attempting to update the first key-value pair corresponding to the local preloading task in the distributed database according to the task state parameter and the instance parameter, further comprising: In the case of failed updating of the first key-value pair, terminating the live stream pulling instance corresponding to the local preloading task and setting the instance parameter to a null value; Deleting the second key-value pair corresponding to the local preloading task.

4. The method of claim 2, wherein, The command parameters comprise last success time and total failure times; After the assigning the live stream pulling instance to the instance parameter and assigning the task state parameter to a task running state, further comprising: In a case where a pull success response of the live stream pull instance is received, the last success time is set as an instance end time of the live stream pull instance; According to the last success time, the step of attempting to update the first key-value pair corresponding to the local preloading task in the distributed database is performed; Or, In a case where a pull failure response of the live stream pull instance is received, the next execution time of the local preloading task is updated according to the total failure number and a preset maximum retry interval; The total failure number of the local preloading task is updated, the instance parameter is set as a null value, and the task state parameter is set as a task waiting state; According to the next execution time, the total failure number, the instance parameter, and the task state parameter, the step of attempting to update the first key-value pair corresponding to the local preloading task in the distributed database is performed.

5. The method of claim 1, wherein, The local preloading task is maintained according to the second key-value pair corresponding to each local preloading task, including: The instance parameter, the last success time, the end time, and the task state parameter of the local preloading task are obtained according to the command parameter contained in the second key-value pair; If the instance parameter is a non-null value, the last success time is set as the current time, and the task state parameter is set as a task running state; If the task state parameter is a task running state and the end time is earlier than the current time, the live stream pull instance corresponding to the instance parameter is terminated, the instance parameter is set as a null value, and the task state parameter is set as a task end state; If the task state parameter is a task waiting state and the interval between the last success time and the current time is not less than a timeout threshold, the task state parameter is set as a task timeout state; In a case where the task state parameter is a task end state or a task timeout state, a task deletion operation of the local preloading task is performed.

6. The method of claim 5, wherein, The task deletion operation of the local preloading task includes: An attempt is made to connect the distributed database; In a case where the connection fails, the second key-value pair corresponding to the local preloading task is updated according to the task state parameter, or the task state parameter and the instance parameter, and the task maintenance timer is reset; In a case where the connection succeeds, an attempt is made to delete the first key-value pair corresponding to the local preloading task in the distributed database; If the first key-value pair is successfully deleted, the second key-value pair corresponding to the local preloading task is deleted, and task end information of the local preloading task is sent; If the first key-value pair is unsuccessfully deleted, the second key-value pair corresponding to the local preloading task is deleted.

7. The method of claim 1, wherein, The method further includes: In a case where a task deletion command is received, a command identifier dt contained in the task deletion command is obtained; In a case where it is determined through a query that the command identifier is stored in the distributed database, an attempt is made to delete the first key-value pair corresponding to the command identifier in the distributed database; In a case where the first key-value pair is deleted successfully, it is inquired whether the local storage stores a second key-value pair corresponding to the command identifier; If yes, the task maintenance timer of a local preloading task corresponding to the second key-value pair is stopped, and a live streaming pulling instance corresponding to the local preloading task is terminated; The second key-value pair is deleted, and task end information of the local preloading task is sent.

8. The method of claim 1, wherein, The method further comprises: Under triggering of a task recovery timer, weight values of the first key-value pairs in the distributed database are obtained; the weight values are obtained according to last update times of the first key-value pairs; According to the weight values of the first key-value pairs and a preset task expiration time length, expired key-value pairs are selected from the first key-value pairs; According to a local task recovery number and the weight values of the expired key-value pairs, to-be-recovered key-value pairs are selected from the expired key-value pairs; the weight values of the to-be-recovered key-value pairs are updated according to a current time; In a case where the local storage does not store a second key-value pair corresponding to the to-be-recovered key-value pair, the to-be-recovered key-value pair is stored to the local storage; A local preloading task is created according to the to-be-recovered key-value pair, and a task maintenance timer of the local preloading task is started; The task recovery timer is reset.

9. The method of claim 8, wherein, Before the weight values of the first key-value pairs in the distributed database are obtained, the method further comprises: A distributed lock of the distributed database is obtained; In a case where the distributed lock is obtained, the weight values of the first key-value pairs in the distributed database are obtained; In a case where the distributed lock is not obtained, the task recovery timer is reset. After the weight values of the to-be-recovered key-value pairs are updated according to the current time, the method further comprises: The distributed lock is released; In a case where the distributed lock is not released, the task recovery timer is reset.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by a processor to implement steps of the method in any one of claims 1 to 9. The computer program is executed by a processor to implement steps of the method in any one of claims 1 to 9.

Citation Information

Patent Citations

  • Video playing method and device, equipment and medium

    CN115529493A

  • OTT content timing publishing and updating processing method and device

    CN116886964A