Live time-shift processing method and time-shift content pre-warming control method

Abstract

Embodiments of the present application provide a live broadcast time shift processing method, a time shift content preheating control method, a device, a computer device, a computer readable storage medium, and a computer program product, which belong to the technical field of network live broadcast and content distribution. The live broadcast time shift processing method comprises: obtaining activity stage data and activity event data of a target live broadcast activity; generating an activity event graph based on the activity stage data and the activity event data, the activity event graph comprising an activity stage state and an event anchor point corresponding to an activity key event; determining a predicted time shift load sequence based on the activity event graph; determining resource coordination control information based on the predicted time shift load sequence and a time shift cluster capacity; and controlling a resource unit to be lent out or recovered between a live broadcast cluster and a time shift cluster according to the resource coordination control information. The embodiments of the present application can match the resource coordination control between the live broadcast cluster and the time shift cluster with the time shift load change caused by the activity event.

Description

Technical Field

[0001] This application relates to the field of live streaming technology, and in particular to a live streaming time-shift processing method, a time-shift content preheating control method, an apparatus, a computer device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] In live event scenarios, live content typically supports both live playback and time-shifted playback simultaneously. Viewers may request time-shifted playback of already broadcast segments while watching the live event. For live events with phased processes and key events, such as sports events, large-scale events, game streams, concerts, or press conferences, the playback end may request time-shifted playback of already broadcast segments. Key events during the event may cause a concentrated increase in time-shift requests within a short period, resulting in significant fluctuations in the time-shift request load on the origin server. Related handling methods typically rely on reserved resources or passive scaling based on system load; simultaneously, the caching of time-shifted content may also depend on requests triggering cache updates. When the live request load and time-shift request load exhibit differentiated changes at different stages, or when time-shift requests corresponding to key segments of the event arrive in concentrated bursts, the resource configuration between the live and time-shift clusters, as well as the deployment of time-shifted content in cache nodes, may struggle to match the actual load changes in a timely manner, thus affecting the collaborative control of origin server resources and the stability of cache response.

[0003] It should be noted that the above content is not necessarily prior art, nor is it intended to limit the scope of patent protection of this application. Summary of the Invention

[0004] This application provides a live streaming time-shift processing method, a time-shift content preheating control method, an apparatus, a computer device, a computer-readable storage medium, and a computer program product to solve or alleviate one or more of the technical problems mentioned above.

[0005] One aspect of this application provides a live streaming time-shifting processing method, applied to a source station scheduling and control system, the method comprising: Acquire activity phase data and activity event data for the target live streaming event; Based on the activity phase data and the activity event data, an activity event map is generated, which includes the activity phase status and event anchor points corresponding to key activities. Based on the activity event graph, a predicted time-shifted load sequence is determined; Based on the predicted time-shifted load sequence and time-shifted cluster capacity, resource coordination control information is determined; Based on the resource coordination control information, the control resource unit is allowed to lend or reclaim resources between the live streaming cluster and the time-shifted cluster.

[0006] Optionally, based on the activity phase data and the activity event data, an activity event map is generated, including: Obtain the activity type corresponding to the target live streaming activity; Load an activity phase state machine template based on the activity type. The activity phase state machine template includes the phase sequence corresponding to the activity type and the default duration range of each phase. Based on the activity phase data, the current activity phase status of the target live broadcast activity is determined; Based on the activity event data, determine the event type and occurrence timestamp of the key events in the activity; Based on the event type, the occurrence timestamp, and the activity stage status, event anchor points corresponding to the key events of the activity are generated.

[0007] Optionally, the method further includes: When an activity phase change signal is received, the activity phase state machine is controlled to transition from the current activity phase state to the next activity phase state. If the duration of the current activity phase state meets the timeout protection condition and no activity phase change signal is obtained, the activity phase state machine is controlled to transition from the current activity phase state to the next activity phase state. Within the transition time window after the state transition, equivalent stage parameters are generated based on the first stage parameters before the state transition and the second stage parameters after the state transition.

[0008] Optionally, based on the activity event map, determining the predicted time-shifted load sequence includes: Based on the baseline parameters and activity importance weights corresponding to the current activity phase status, determine the baseline time shift load; Based on the event anchor points in the activity event graph, determine the active event window; For an event anchor point in the active event window, the event pulse load corresponding to the event anchor point is determined based on the event type, influence parameter, decay parameter, and time difference between the event anchor point and the current time. The predicted time-shifted load sequence is determined based on the baseline time-shifted load and the event pulse load.

[0009] Optionally, determining the predicted time-shift load sequence based on the baseline time-shift load and the event pulse load includes: The event pulse loads corresponding to multiple event anchor points in the active event window are superimposed to obtain the total event pulse load. If the total event pulse load exceeds the pulse superposition limit, the total event pulse load is adjusted based on the pulse superposition limit. The predicted time-shifted load sequence is determined based on the baseline time-shifted load and the corrected total event pulse load; The predicted values ​​in the predicted time-shifted load sequence are configured with confidence intervals, and the resource coordination control information is determined based on the upper bound of the confidence intervals.

[0010] Optionally, based on the predicted time-shifted load sequence and time-shifted cluster capacity, resource coordination control information is determined, including: Based on the predicted time-shifted load sequence, the conservative predicted load within the target prediction time window is determined; Based on the conservative predicted load and the time-shifted cluster capacity, determine the amount of resources that can be lent out or the resource reclamation trigger information; Based on the amount of resources available for lending or the resource recycling trigger information, the resource coordination control information is generated.

[0011] Optionally, based on the conservatively predicted load and the time-shifted cluster capacity, the amount of resources that can be lent out is determined, including: The lendable ratio is determined based on the safety factor and the ratio of the conservatively predicted load to the time-shifted cluster capacity. The amount of resources available for lending is determined based on the lending ratio and the number of resource units in the time-shifted cluster. The resource unit is the smallest unit of resource borrowing, and the resource unit includes a computing node and the network bandwidth resources corresponding to the computing node.

[0012] Optionally, based on the resource coordination control information, controlling resource units to lend out between the live streaming cluster and the time-shifted cluster includes: Determine the target resource unit corresponding to the amount of available resources from the idle resource pool of the time-shifted cluster; Control the migration of the target resource unit from the time-shift cluster to the live streaming cluster; Register the target resource unit to the service discovery system corresponding to the live streaming cluster; Update the load balancing weights corresponding to the live streaming cluster.

[0013] Optionally, determining the target resource unit corresponding to the amount of available resources from the idle resource pool of the time-shifted cluster includes: Obtain the load status and location attributes of each candidate resource unit in the idle resource pool; Based on the load status and the location attribute, the candidate resource units are sorted. Based on the sorting results, the target resource unit is determined from the candidate resource units.

[0014] Optionally, the method further includes: Maintain the resource status for each resource unit, including the ready status, the lending status, the lent status, and the recycling status; During the process of the control resource unit lending or reclaiming resources between the live streaming cluster and the time-shifted cluster, the resource status of the resource unit is updated.

[0015] Optionally, based on the conservatively predicted load and the time-shifted cluster capacity, resource reclamation trigger information is determined, including: When the predicted time-shifted load sequence indicates that the time-shifted load is trending upward, the resource reclamation trigger information is determined; Based on the load rise rate and resource switching time required corresponding to the predicted time-shifted load sequence, a pre-recovery window is determined; Based on the pre-recovery window, resource coordination control information is generated to control the recovery of lent resource units.

[0016] Optionally, based on the resource coordination control information, controlling the reclamation of resource units between the live streaming cluster and the time-shifted cluster includes: Determine the resource units to be reclaimed from the resource units that have been lent to the live streaming cluster; The load balancer of the live streaming cluster is controlled to mark the resource unit to be reclaimed as empty, so that the resource unit to be reclaimed will no longer receive new connections; When the resource unit to be recycled meets the conditions for completion of emptying, the resource unit to be recycled is deregistered from the service discovery system corresponding to the live streaming cluster, and the resource unit to be recycled is registered to the service discovery system corresponding to the time-shifted cluster. Update the load balancing weights corresponding to the time-shifted cluster.

[0017] Optionally, after the load balancer of the live streaming cluster marks the resource unit to be reclaimed as empty, it further includes: Monitor the number of active connections on the resource unit to be reclaimed; When the number of active connections drops to zero, it is determined that the resource unit to be recycled meets the conditions for completion of emptying. If the waiting time meets the maximum waiting time and the number of active connections has not dropped to zero, a flow end signal is sent to the connection on the resource unit to be reclaimed, and the connection on the resource unit to be reclaimed is closed.

[0018] Optionally, the method further includes: During the process of controlling resource units to borrow or reclaim resources between the live streaming cluster and the time-shifted cluster, the time-shifted cluster retains a proportion of resource units not less than a preset safety lower limit that do not participate in the borrowing.

[0019] Optionally, the method further includes: Obtain time-shift request statistics, which are generated based on at least one of the target timestamp of the time-shift playback request, the viewing duration, and the request source information; Based on the time-shift request statistics, hot spots on the live stream timeline are determined; The hotspot segments are associated with the event anchors in the event graph to generate event popularity association data; Based on the event popularity correlation data, update the prediction parameters corresponding to the event type in the event graph.

[0020] Optionally, based on the event popularity correlation data, the prediction parameters corresponding to the event type in the activity event map are updated, including: Based on the event popularity correlation data, determine the actual request density peak and predicted pulse peak corresponding to the event type; Based on the actual request density peak and the predicted pulse peak, update the influence parameter corresponding to the event type; Based on the request density decay curve corresponding to the hotspot segment, update the decay parameter corresponding to the event type; The updates of the influence parameter and the decay parameter are constrained by the single adjustment magnitude and the cumulative adjustment range.

[0021] Another aspect of this application provides a time-shifted content preheating control method, applied to a CDN preheating control system, the method comprising: Receive preheating trigger information, which is generated based on event anchors in the activity event graph, and includes event type and anchor timestamp; Based on the event type and the anchor timestamp, determine the target preheating time interval; Based on the preheating target time interval, a list of time-shifted content segments is determined; Based on the time-shifted content fragment list, a preheating task is generated; Based on the preheating task, the target cache node is controlled to cache the corresponding time-shifted content fragment.

[0022] Optionally, based on the event type and the anchor timestamp, the preheating target time interval is determined, including: Based on the event type, query the mapping relationship between the event type and the preheating parameters to obtain the pre-offset and post-offset corresponding to the event type; Based on the anchor timestamp and the preceding offset, the start time of the preheating target time interval is determined; Based on the anchor timestamp and the subsequent offset, the end time of the preheating target time interval is determined.

[0023] Optionally, based on the preheating target time interval, a list of time-shifted content segments is determined, including: Query the slice index of time-shifted content; Determine the media slice identifier whose timestamp falls within the preheating target time interval from the slice index; Determine the index file segment corresponding to the media slice identifier; The time-shifted content fragment list is generated based on the media slice identifier and the index file fragment.

[0024] Optionally, the preheating trigger information also includes an event importance level; based on the time-shifted content segment list, a preheating task is generated, including: Based on the importance level of the event, the task priority of the preheating task is determined; The preheating task is generated based on the task priority and the time-shifted content fragment list; Insert the preheating task into the priority queue.

[0025] Optionally, based on the preheating task, controlling the target cache node to cache the corresponding time-shifted content fragment includes: Retrieve preheating tasks to be executed from the priority queue; Based on the event importance level corresponding to the preheating task to be executed, the target cache node is determined; The target cache node is controlled to cache the time-shifted content fragment corresponding to the preheating task to be executed; The target cache node includes at least one of CDN edge nodes, CDN middle layer nodes, or origin server hot cache.

[0026] Optionally, based on the preheating task, controlling the target cache node to cache the corresponding time-shifted content fragment includes: Allocate a preheating bandwidth quota, independent of the user request service, to the preheating task; Within the preheating bandwidth quota, preheating transmission bandwidth is allocated based on the task priority of each preheating task in the priority queue; If the usage status of the preheating bandwidth quota meets the quota limit conditions, low-priority preheating tasks will be slowed down or suspended.

[0027] Optionally, the method further includes: Obtain the task execution status of the preheating task, the task execution status including the push success status and / or push delay status corresponding to the target cache node; Based on the task execution status, update the preheating completion status of the preheating task.

[0028] Optionally, the method further includes: Get time-shift request statistics; Based on the time-shift request statistics, hot spots on the live stream timeline are determined; The hotspot segments are associated with the event anchor points to generate event preheating feedback data; Based on the event preheating feedback data, update the mapping relationship between event type and preheating parameters.

[0029] Optionally, based on the event preheating feedback data, the mapping relationship between event types and preheating parameters is updated, including: Based on the difference between the playback start time corresponding to the hot spot segment and the anchor point timestamp, the preceding offset statistical value is determined; Based on the difference between the playback end time corresponding to the hot spot segment and the anchor point timestamp, the post-offset statistical value is determined; If the preceding offset statistic or the following offset statistic meets the adjustment trigger condition, update the preceding offset or following offset corresponding to the event type.

[0030] Another aspect of this application provides a time-shifted content preheating control device, applied to a CDN preheating control system, the device comprising: The acquisition module is used to acquire activity phase data and activity event data of the target live event; The generation module is used to generate an activity event map based on the activity stage data and the activity event data. The activity event map includes the activity stage status and event anchor points corresponding to key events of the activity. The prediction module is used to determine the predicted time-shifted load sequence based on the activity event map; The determination module is used to determine resource coordination control information based on the predicted time-shifted load sequence and the time-shifted cluster capacity; The control module is used to control the resource units to lend or reclaim resources between the live streaming cluster and the time-shifted cluster based on the resource coordination control information.

[0031] Another aspect of this application provides a live streaming time-shift processing apparatus applied to a CDN preheating control system, the apparatus comprising: The receiving module is used to receive preheating trigger information, which is generated based on event anchors in the activity event graph and includes event type and anchor timestamp. The first determining module is used to determine the preheating target time interval based on the event type and the anchor timestamp; The second determining module is used to determine a list of time-shifted content segments based on the preheating target time interval; The generation module is used to generate a preheating task based on the time-shifted content fragment list; The control module is used to control the target cache node to cache the corresponding time-shifted content fragment based on the preheating task.

[0032] Another aspect of this application provides a computer device, including: At least one processor; and A memory that is communicatively connected to the at least one processor; Wherein: the memory stores instructions that can be executed by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method as described above.

[0033] Another aspect of this application provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the method described above.

[0034] Another aspect of this application provides a computer program product including a computer program that, when executed by a processor, implements the method described above.

[0035] The embodiments of this application employing the above technical solution may include the following advantages: By acquiring activity phase data and activity event data of the target live event, and generating an activity event map including activity phase status and event anchor points, the time-shifted load prediction process can incorporate time information corresponding to the activity process and key events; furthermore, by determining the predicted time-shifted load sequence based on the activity event map, and by determining resource coordination control information based on the predicted time-shifted load sequence and time-shifted cluster capacity, the resource coordination control information can correspond to the predicted time-shifted load changes; and then, by controlling resource units to lend or reclaim resources between the live cluster and the time-shifted cluster according to the resource coordination control information, the matching degree between resource configuration and time-shifted load changes between the live cluster and the time-shifted cluster can be improved, reducing the risk of mismatch between resource coordination control and time-shifted load changes. Attached Figure Description

[0036] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of the claims. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0037] Figure 1 This diagram schematically illustrates the operating environment of a live streaming time-shift processing method according to an embodiment of this application. Figure 2 A flowchart illustrating a time-shifting processing method for live streaming according to Embodiment 1 of this application is shown schematically. Figure 3 A flowchart illustrating the time-shifted content preheating control method according to Embodiment 2 of this application is shown schematically; Figure 4 The illustration shows an example of an application of the time-shift processing method for live streaming according to an embodiment of this application; Figure 5 This illustration schematically shows another application example diagram of the time-shift processing method for live streaming according to an embodiment of this application; Figure 6 A block diagram of a live streaming time-shift processing apparatus according to Embodiment 3 of this application is shown schematically; Figure 7 A block diagram of a time-shifted content preheating control device according to Embodiment 4 of this application is schematically shown; and Figure 8 A schematic diagram of the hardware architecture of a computer device according to Embodiment 5 of this application is shown. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0039] It should be noted that the descriptions involving "first," "second," etc., in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0040] In the description of this application, it should be understood that the numerical labels before the steps do not indicate the order of the steps, but are only used to facilitate the description of this application and to distinguish each step, and therefore should not be construed as a limitation of this application.

[0041] It should be noted that if this application involves data collection, storage, use, transmission, and processing, each stage of these data collection will strictly comply with the laws, regulations, industry standards, and regulatory requirements of the data source country, usage country, and relevant countries and regions to ensure the legality and compliance of data activities. In the collection stage, the purpose, method, and scope of collection will be clearly communicated to the data subject in a prominent manner. Collection will be carried out only after obtaining the data subject's legal authorization, ensuring that the collection process adheres to the principle of minimum necessity and does not exceed the scope of data collection. In the storage stage, the data storage period can be limited, and data can be promptly deleted, anonymized, or encrypted after the storage purpose is achieved. In the usage stage, at least one of the following methods can be used to process the original data to reduce the risk of sensitive information leakage: field-level desensitization, data generalization, data anonymization, and data encryption. In the transmission and processing stages, access control, transmission encryption, permission isolation, or log auditing can be used to ensure the confidentiality and security of data during transmission and processing.

[0042] First, a definition of the terminology used in this application is provided: Live event streaming refers to events that are distributed in real-time over a network and support time-shift playback. Target live events can include live sports events, large-scale events, game streams, esports match streams, concert streams, press conference streams, or other live events with phases and key events. Event phase data can be used to characterize the current phase of the target live event or changes in that phase. Event event data can be used to characterize key events occurring during the target live event. Key events can be events that may cause a concentrated shift in time-shift playback requests.

[0043] Time-shifting can refer to the ability to allow a requester to access and play segments of already broadcast live content during a live stream.

[0044] The origin server can refer to a server cluster used to store and distribute live and time-shifted content. It can respond to CDN origin requests as well as some direct requests.

[0045] A live streaming cluster can refer to a collection of source site resources used to receive requests for live streaming playback.

[0046] A time-shift cluster can refer to a collection of origin server resources used to receive time-shifted replay requests.

[0047] A resource unit can be the smallest control granularity for resource borrowing, and can include a computing node and the network bandwidth resources corresponding to that computing node.

[0048] An activity event graph can be a time-series diagram structure with activity stage states as the backbone and event anchor points corresponding to key events as nodes. It is used to characterize the stage progress and key event distribution of a target live-streamed activity along the live-stream timeline. The activity event graph can be a directed time-series diagram structure. This structure uses activity stage states as the main framework and event anchor points corresponding to key events as nodes, representing the chronological relationship between activity stage states and key events through a directed relationship in the time direction. This directed time-series diagram structure allows the source station scheduling and control system to simultaneously read the activity stage states, event types, and the position of event occurrence times on the live-stream timeline when generating predicted time-shifted load sequences, thus forming a structured input for time-shifted load prediction.

[0049] An event anchor point can be the time position of a key event on the live broadcast timeline.

[0050] A predicted time-shifted load sequence can be a data sequence used to characterize changes in time-shifted request load within a future target prediction time window.

[0051] A CDN preheating control system can be a system used to generate preheating tasks based on preheating trigger information and control the target cache nodes to cache time-shifted content fragments.

[0052] The target cache node can be a cache node controlled by the CDN preheating control system to cache time-shifted content fragments. The target cache node can include at least one of CDN edge nodes, CDN middle layer nodes, or origin server hot cache.

[0053] Origin server hot caching can be used as an optional type of target cache node to provide hot caching capabilities close to the origin server when time-shifted content fragments are not pushed to CDN edge nodes or CDN middle layer nodes.

[0054] HLS, or HTTP-based streaming media transport protocol, can divide video content into multiple media slices and organize the playlist of media slices through an index file.

[0055] Media slices can include TS slice files.

[0056] The index file fragment can include segments from the M3U8 index file that correspond to the target time interval. When performing time-shifted content preheating, the CDN preheating control system can simultaneously determine the media slice identifier and the corresponding index file fragment, so that the target cache node can provide the media slice and the corresponding index information when responding to the time-shift request.

[0057] Secondly, to facilitate understanding of the technical solutions provided in the embodiments of this application by those skilled in the art, the relevant technologies are described below: In live streaming scenarios of large-scale events, such as football and basketball matches, when high-profile events occur, including goals, last-minute victories, controversial calls, or crucial saves, a large number of users typically initiate time-shift replay requests within a very short period, hoping to watch and share the highlights multiple times. These requests have a clear event-driven characteristic; time-shift traffic can rapidly surge to dozens of times the normal level within seconds to tens of seconds after the event occurs, and then gradually decline.

[0058] However, the time-shift processing technology for live streaming that the inventors are aware of has the following drawbacks: First, the physically isolated architecture leads to low resource utilization. While deploying live streaming and time-shift services on separate clusters for fault isolation reduces the mutual impact between different services, the inability to share resources between the two clusters can easily result in a large amount of idle resources during scenarios with frequent shifts between peak and off-peak periods, such as sporting events. For example, during the halftime break of a sporting event, time-shift request volume drops significantly, but idle resources in the time-shift cluster cannot be dynamically reused by the live streaming service; conversely, when live streaming pressure is low, the resources of the live streaming cluster cannot support sudden bursts of time-shift traffic. Therefore, to meet peak load requirements, both the live streaming cluster and the time-shift cluster typically need to be configured with maximum capacity, resulting in low overall resource utilization.

[0059] Second, the scaling-up and scaling-down mechanism lacks event awareness. Time-shift systems trigger elastic scaling based on operational metrics such as CPU utilization, bandwidth usage, or connection count, passively responding to traffic spikes. They lack the ability to anticipate the progress of events (events) and critical events. Since time-shift traffic triggered by events like goals, red cards, or last-minute victories typically peaks within seconds, while the scaling process requires minutes of response time, the system is prone to issues such as origin server congestion, request queuing, or playback stuttering before scaling is complete. This makes it difficult to meet the low latency and high concurrency requirements of certain events (such as sporting events).

[0060] Third, CDN caching mechanisms are ill-suited for time-shifted scenarios. Time-shifted content is essentially a historical time segment, and there are usually no access requests before the event occurs, so CDN nodes may lack corresponding caches. When a large number of users simultaneously rewatch a highlight, related requests will concentrate and penetrate the CDN, directly returning to the origin server, causing the origin server to experience enormous pressure in a short period of time. CDNs employ a passive caching strategy of caching only after user requests, resulting in a significantly lower cache hit rate in time-shifted events compared to live streaming. Furthermore, due to the discrete nature of different users' rewatch times, effective data sharing between P2P nodes is difficult, hindering the effective alleviation of hotspot origin server load pressure.

[0061] Fourth, there is a lack of a closed-loop optimization mechanism based on user behavior. Different activity types and event types have significantly different impacts on user replay behavior, but the system struggles to dynamically adjust event impact parameters based on historical behavior data. Furthermore, pre-heating strategies typically employ fixed pre-heating ranges or fixed caching durations, making it difficult to dynamically optimize resource allocation based on actual replay patterns. This easily leads to both wasted pre-heating resources and insufficient pre-heating of popular content.

[0062] Fifth, existing general routing and storage optimization solutions are insufficient to address the core issue of event time-shifting. Routing live and time-shifted requests to different backends based on request type using a load balancer is essentially conventional traffic distribution and cannot solve the problem of predicting sudden time-shifted traffic triggered by critical events. While tiered storage of hot, warm, and cold data can improve storage efficiency, this static optimization strategy based on long-term access frequency is ill-suited to the transient hotspot changes driven by sudden events in some event scenarios (such as sporting events), and therefore cannot effectively cope with the instantaneous back-to-origin pressure brought by large-scale event time-shifted requests.

[0063] To address this, this application provides a time-shifting processing scheme for live streaming. In this scheme, the origin server scheduling and control system generates an activity event graph based on the activity phase data and activity event data of the target live streaming activity. Based on the activity event graph, it determines a predicted time-shifting load sequence. Then, based on the predicted time-shifting load sequence and the time-shifting cluster capacity, it generates resource coordination control information to control the lending or reclamation of resource units between the live streaming cluster and the time-shifting cluster. Furthermore, the CDN preheating control system determines the target preheating time interval based on preheating trigger information generated from event anchors and controls the target cache nodes to cache the corresponding time-shifted content fragments. See below for details.

[0064] Finally, for ease of understanding, an exemplary operating environment is provided below.

[0065] like Figure 1As shown, in some embodiments, the operating environment may include an activity data source 2, an origin server scheduling and control system 4, a live streaming cluster 6, a time-shifted cluster 8, a CDN preheating control system 10, CDN nodes 12, and a playback terminal 14. The activity data source 2 can be used to provide activity phase data and activity event data for the target live streaming activity. The origin server scheduling and control system 4 can be used to generate an activity event graph, determine the predicted time-shifted load sequence, determine resource coordination control information, and control the borrowing or reclamation of resource units between the live streaming cluster 6 and the time-shifted cluster 8. The live streaming cluster 6 can be used to receive live real-time playback requests. The time-shifted cluster 8 can be used to receive time-shifted playback requests. The CDN preheating control system 10 can be used to receive preheating trigger information generated based on event anchors and generate preheating tasks based on the preheating trigger information. The CDN nodes 12 include CDN edge nodes or CDN middleware nodes, which can be used to cache time-shifted content segments. The target cache nodes include CDN edge nodes, CDN middleware nodes, or origin server hot caches. The playback terminal 14 can be used to initiate live streaming playback requests or time-shifted playback requests and receive live streaming content or time-shifted content.

[0066] The origin server scheduling and control system 4 and the CDN preheating control system 10 can be logically independent service systems or service components. The origin server scheduling and control system 4 can be used to execute time-shift processing methods for live streaming, and the CDN preheating control system 10 can be used to execute time-shifted content preheating control methods. They can be deployed as different service components within the same service platform, or they can be deployed on different service platforms. The above deployment methods are only for illustrating exemplary operating environments and do not imply that the origin server scheduling and control system 4 and the CDN preheating control system 10 must be executed by the same physical device, nor do they imply that they must be merged into the same execution entity.

[0067] The service platform can consist of one or more computing devices, which may include servers, server clusters, cloud computing service centers, or virtualized computing instances. The service platform can communicate with the live streaming cluster 6, time-shifted cluster 8, CDN node 12, and playback terminal 14 via a network. The network can include wired or wireless networks, such as fiber optic networks, Ethernet, cellular networks, Wi-Fi networks, or combinations thereof. It should be noted that the above devices are exemplary, and the number and type of devices can be adjusted in different scenarios or according to different needs.

[0068] In some embodiments, the source station scheduling and control system 4 may include an activity event graph layer, a resource elastic borrowing and coordination layer, and a replay heat feedback analysis layer. The activity event graph layer may include an activity calendar module, a stage state machine module, a real-time event stream access module, an event anchor point registration module, and an event pulse prediction module. The activity calendar module can be used to provide schedule information for the target live event. The stage state machine module can be used to determine the stage state of the activity based on the activity type. The real-time event stream access module can be used to receive score changes, penalty information, substitution information, or other activity event data. The event anchor point registration module can be used to mark the occurrence positions of key events on the live timeline. The event pulse prediction module can be used to determine the predicted time-shifted load sequence based on the activity stage state and event anchor points.

[0069] The resource elastic borrowing and coordination layer can include a borrowing ratio determination module, a zero-disruption switchover module, and a pre-reclamation window control module. The borrowing ratio determination module determines the amount of resources available for borrowing based on the predicted time-shifted load sequence and time-shifted cluster capacity. The zero-disruption switchover module controls connection emptying and service discovery switching during resource reclamation. The pre-reclamation window control module triggers the reclamation of borrowed resource units before the predicted time-shifted load increases.

[0070] The CDN preheating control system 10 may include a preheating range determination module, a preheating task queue module, and a multi-level push module. The preheating range determination module can be used to determine the target preheating time interval based on event anchor points. The preheating task queue module can be used to sort preheating tasks according to event importance levels. The multi-level push module can be used to control the caching of time-shifted content segments corresponding to CDN edge nodes, CDN middle-layer nodes, or origin server hot caches. The replay popularity feedback analysis layer can be used to determine hotspot segments based on time-shifted request statistics and associate these hotspot segments with event anchor points to update prediction parameters or preheating parameters.

[0071] Through the above architecture, the event graph layer can provide event-aware input for the resource elastic borrowing and coordination layer and the CDN preheating control system. The resource elastic borrowing and coordination layer can adjust the origin server resource ownership based on the prediction results. The CDN preheating control system can pre-cache time-shifted content segments based on event anchors. The replay popularity feedback analysis layer can calibrate subsequent prediction and preheating parameters based on the actual time-shifted request distribution, thereby forming a closed-loop processing path of event occurrence, prediction pulse, resource scheduling, content preheating, user replay, popularity analysis and parameter calibration.

[0072] In some embodiments, the source station scheduling control system 4, the CDN preheating control system 10, or monitoring components connected in communication with them can also record operational status data such as resource unit status, preheating task status, push success status, and push delay status. This operational status data can be used for subsequent fault location, task tracking, or scheduling parameter updates, and is not limited to being displayed through a specific monitoring interface. By recording this operational status data, the traceability of resource collaborative control and preheating task control processes can be improved.

[0073] Example 1 Figure 2 A flowchart illustrating a live broadcast time-shifting processing method according to Embodiment 1 of this application is shown schematically. This live broadcast time-shifting processing method can be applied to a source station scheduling and control system. Figure 2 As shown, the time-shift processing method for this live broadcast may include steps S200 to S208, wherein: Step S200: Obtain activity phase data and activity event data for the target live streaming event; Step S202: Based on the activity stage data and the activity event data, generate an activity event map, which includes the activity stage status and event anchor points corresponding to key events of the activity. Step S204: Based on the activity event graph, determine the predicted time-shifted load sequence; Step S206: Based on the predicted time-shifted load sequence and time-shifted cluster capacity, determine resource coordination control information; Step S208: Based on the resource coordination control information, control the resource unit to lend or reclaim resources between the live streaming cluster and the time-shifted cluster.

[0074] In this embodiment, an activity event map is generated using activity phase data and activity event data of the target live event. This allows the subsequent prediction process to simultaneously utilize the current stage state of the target live event and the position of key events on the live timeline. By determining the predicted time-shifted load sequence based on the activity event map, a time-shifted load prediction result matching the activity progress and key events can be obtained. Furthermore, resource coordination control information is determined based on the predicted time-shifted load sequence and time-shifted cluster capacity. By controlling resource units to lend or reclaim resources between the live streaming cluster and the time-shifted cluster according to this information, the resource allocation adjustment between the live streaming cluster and the time-shifted cluster can correspond to the predicted time-shifted load changes, thereby reducing the mismatch between source station resource coordination control and time-shifted load changes.

[0075] The following combination Figure 2 The steps S200 to S208 and other optional steps are further described.

[0076] Step S200To obtain activity phase data and activity event data for the target live streaming event.

[0077] Specifically, the target live broadcast activity can be a currently broadcast sports interaction or other live broadcast activity with phases and key events. Activity phase data can be used to characterize the current phase or phase changes of the target live broadcast activity, such as pre-match, first half, halftime, second half, extra time, post-match, etc. Activity event data can be used to characterize key events occurring in the target live broadcast activity, such as goals, penalties, red cards, key saves, or other activity events that may cause a concentrated change in time-shift replay requests. The source station scheduling and control system can obtain the above data from activity data sources, activity event streams, activity calendar systems, or internal event acquisition modules.

[0078] Specifically, activity phase data may include at least one of the following: phase identifier, phase start time, phase end time, phase change signal, or phase duration. Activity event data may include at least one of the following: event type, event occurrence timestamp, activity to which the event belongs, corresponding phase of the event, or event importance information. After acquiring the above data, the source station scheduling and control system can provide an input basis for generating an activity event map.

[0079] In this way, the source station scheduling and control system can acquire technical data related to the progress of the target live broadcast activity before executing resource collaborative control, so that subsequent prediction and resource control no longer rely solely on the lagging changes in the source station load, but can form a pre-control basis by combining the activity stage and activity events.

[0080] Step S202 Based on the activity stage data and the activity event data, an activity event map is generated, which includes the activity stage status and event anchor points corresponding to key events of the activity.

[0081] Specifically, an event graph can be used to represent the semantic progress of a target live-streaming event on the live-streaming timeline. Event stage status can characterize the current stage of the target live-streaming event. Event anchors can characterize the location of key events on the live-streaming timeline. The origin server scheduling and control system can use the event stage status as the graph skeleton and add key events corresponding to the event event data as nodes or anchors to the event graph. Specifically, the origin server scheduling and control system can first determine the current event stage status based on the event stage data, then determine the event type and occurrence timestamp of the key event based on the event event data, and then generate the event anchor corresponding to the key event in the event graph. Event anchors can be associated with event type, occurrence timestamp, event stage status, event identifier, or other data items that can be used for subsequent prediction.

[0082] In some embodiments, the event graph may further include temporal association edges between multiple event anchors. These temporal association edges can be used to characterize the sequential relationships between different key events on the live broadcast timeline and the propagation relationships of events. The source station scheduling and control system can establish directed connections between event anchors according to the chronological order of event occurrence to form a directed temporal graph structure. Thus, information such as the stage status of an activity, the location of events, and the temporal evolution relationships between different key events can be obtained through the event graph.

[0083] In some embodiments, the origin server scheduling control system can load the schedule information corresponding to the event calendar before the start of the target live event, and select the corresponding event phase state machine template according to the event type of the target live event. The event phase state machine template may include a standard phase sequence for that event type and a default duration range for each phase. The origin server scheduling control system can initialize the event phase state machine to the pre-event warm-up phase and load the historical traffic baseline parameters corresponding to the pre-event warm-up phase. As the target live event progresses, the origin server scheduling control system can update the event phase state machine based on the event phase data.

[0084] In this way, the phase changes and key event distribution of the target live event can be organized into a time sequence diagram structure suitable for computer system processing, which facilitates the subsequent generation of predicted time-shifted load sequences based on the graph. At the same time, an initial phase state and initial baseline parameters can be established for the event graph before the event starts, so that the subsequent event anchor registration and predicted time-shifted load sequence generation have a clear state machine basis.

[0085] In an optional embodiment, generating an activity event map based on the activity phase data and the activity event data may include steps S2021 to S2025: Step S2021: Obtain the activity type corresponding to the target live streaming activity; Step S2022: Load the activity phase state machine template based on the activity type. The activity phase state machine template includes the phase sequence corresponding to the activity type and the default duration range of each phase. Step S2023: Based on the activity stage data, determine the current activity stage status of the target live broadcast activity; Step S2024: Based on the activity event data, determine the event type and occurrence timestamp of the key activity events; Step S2025: Based on the event type, the occurrence timestamp, and the activity stage status, generate event anchor points corresponding to the key events of the activity.

[0086] Specifically, activity types can be used to select a phase state machine template that matches the target live activity. For example, different activity types may have different phase sequences, phase duration ranges, and phase switching conditions. The activity phase state machine template provides a rule-based framework for determining the activity phase state, enabling the origin server scheduling and control system to determine the current activity phase state based on activity phase data. For activity event data, the origin server scheduling and control system can obtain the event type and occurrence timestamp from the real-time event stream and associate them with the current activity phase state to generate event anchors.

[0087] The above method allows the event graph to simultaneously include stage status and key event time locations, enabling the subsequent prediction of time-shifted load sequences to distinguish the impact of different event stages and different event types on time-shifted load.

[0088] In an optional embodiment, the method may further include steps S2026 to S2028: Step S2026: When an activity phase change signal is received, control the activity phase state machine to transition from the current activity phase state to the next activity phase state. Step S2027: If the duration of the current activity phase state meets the timeout protection condition and no activity phase change signal is obtained, control the activity phase state machine to transition from the current activity phase state to the next activity phase state. Step S2028: Within the transition time window after the state transition, generate equivalent stage parameters based on the first stage parameters before the state transition and the second stage parameters after the state transition.

[0089] Specifically, the active phase state machine can transition states based on explicit active phase change signals, or when the phase duration reaches the default duration range or timeout protection conditions are met. The first phase parameters characterize the time-shifted load baseline parameters or impulse response characteristics corresponding to the active phase before the state transition, while the second phase parameters characterize the time-shifted load baseline parameters or impulse response characteristics corresponding to the active phase after the state transition. Equivalent phase parameters can be generated within the transition time window by combining the first and second phase parameters, ensuring a smoother change in the predicted time-shifted load sequence during phase switching.

[0090] In some embodiments, the source station scheduling control system can perform linear interpolation calculations on the first-stage parameters and the second-stage parameters according to time weights within a transition time window. Specifically, at the beginning of the transition time window, the equivalent stage parameters correspond to the first-stage parameters; as the transition time window progresses, the weights corresponding to the second-stage parameters gradually increase; at the end of the transition time window, the equivalent stage parameters switch to the second-stage parameters. For example, if the length of the transition time window is T, and the duration currently within the transition time window is t, the source station scheduling control system can determine the fusion weights corresponding to the second-stage parameters according to t / T.

[0091] In some embodiments, the state transitions of the active phase state machine can be unidirectional ordered transitions. For example, in a football match, the active phase states may sequentially include at least a portion of the following: pre-match warm-up, first half, halftime, second half, first half of extra time, second half of extra time, penalty shootout, and post-match review. The source station scheduling control system may not support rollback from the later active phase state to the previous active phase state to reduce oscillations in prediction parameters caused by repeated switching of phase states.

[0092] In some embodiments, if the duration of the current active phase state meets the timeout protection condition and no active phase change signal is received, the source station scheduling and control system may also record phase transition anomaly information. This phase transition anomaly information can be used to characterize that the state transition was triggered by timeout protection, rather than by an explicit phase change signal pushed by the active data source. By recording phase transition anomaly information, a basis can be provided for subsequent verification of active phase data or for backtracking prediction deviations.

[0093] By using the above methods, the impact of sudden changes in the state during the activity phase on the load prediction results can be reduced, making the subsequent resource coordination and control information more stable.

[0094] Step S204: Based on the activity event map, determine the predicted time-shifted load sequence.

[0095] Specifically, the predicted time-shifted load sequence can be used to characterize the predicted time-shifted request volume or predicted time-shifted service load at different times within a future target prediction time window. The source station scheduling and control system can extract information such as the current activity phase status, event anchors, event types, and occurrence timestamps from the activity event graph, and generate the predicted time-shifted load sequence based on this information. The predicted time-shifted load sequence can include predicted values ​​generated within the next few minutes at a second-level time granularity or other configurable time granularities. The current activity phase status can be used to determine the baseline portion of the time-shifted load, and the event anchors can be used to determine the pulsed load portion caused by key events in the activity. The source station scheduling and control system can combine the baseline portion and the pulsed portion to obtain the predicted time-shifted load sequence over a future period. This sequence can be organized by second, by time slice, or by other configurable granularities; this application does not limit this.

[0096] By using the above methods, the predicted time-shifted load sequence can reflect the impact of activity phases and key events on the time-shifted request load, providing data basis for the generation of subsequent resource coordination control information.

[0097] In an optional embodiment, determining the predicted time-shifted load sequence based on the activity event graph may include steps S2041 to S2044: Step S2041: Determine the baseline time-shift load based on the baseline parameters and activity importance weights corresponding to the current activity phase status; Step S2042: Determine the active event window based on the event anchor points in the activity event graph; Step S2043: For the event anchor point in the active event window, based on the event type, influence parameter, decay parameter and time difference between the event anchor point and the current time, determine the event pulse load corresponding to the event anchor point; Step S2044: Determine the predicted time-shifted load sequence based on the baseline time-shifted load and the event pulse load.

[0098] Specifically, baseline parameters can be used to characterize the baseline level of time-shift load during the current activity phase. Activity importance weights can be used to characterize the overall impact of the target live activity on the scale of time-shift requests. The active event window can be used to retain event anchors that have not yet decayed below the removal condition. For event anchors in the active event window, influence parameters and decay parameters can be determined based on the event type of the event anchor, and the event pulse load can be determined by combining the time elapsed since the event occurred.

[0099] In some embodiments, the baseline time-shift load can be determined based on the average time-shift request load of similar historical activities at the same stage, the activity importance weight, and the baseline coefficient corresponding to the current activity stage state. The average time-shift request load of similar historical activities at the same stage can be used to characterize the normal time-shift request level of this activity type at the same stage; the activity importance weight can be used to characterize the impact of the target live activity itself on the scale of time-shift requests; and the baseline coefficient corresponding to the current activity stage state can be used to characterize the differences in time-shift requests between different activity stages. In this way, the baseline time-shift load can simultaneously reflect the impact of activity type, activity stage, and activity importance on time-shift requests.

[0100] In some embodiments, the event pulse load corresponding to an event anchor point can be determined using an exponential decay method. Specifically, the source station scheduling control system can combine the influence parameter corresponding to the event type with the decay term to determine the event pulse load corresponding to the event anchor point at the current moment; the decay term can decrease as the time difference between the event anchor point and the current moment increases. For example, a goal event can correspond to a higher influence parameter and a slower decay rate, while a yellow card event can correspond to a lower influence parameter and a faster decay rate. The above examples are only used to illustrate that different event types can have different impulse response characteristics and are not intended to limit the event type or parameter values.

[0101] In some embodiments, the source station scheduling control system can maintain an active event window. The active event window can include event anchors that occurred within the most recent configurable time period and whose event pulse load has not yet decayed to a level suitable for removal. If the event pulse load corresponding to an event anchor decays to below a configurable proportion of the baseline time-shifted load, the source station scheduling control system can remove that event anchor from the active event window. This approach reduces the interference of historical events that no longer significantly affect time-shifted load prediction on current prediction results.

[0102] By using the above method, the predicted time-shifted load sequence can simultaneously reflect the basic time-shifted load corresponding to the activity phase and the short-term load pulses caused by key events, thereby improving the adaptability of the prediction results to the activity process.

[0103] In an optional embodiment, determining the predicted time-shift load sequence based on the baseline time-shift load and the event pulse load may include steps S2045 to S2048: Step S2045: The event pulse loads corresponding to multiple event anchor points in the active event window are superimposed to obtain the total event pulse load; Step S2046: If the total event pulse load exceeds the pulse superposition limit, the total event pulse load is corrected based on the pulse superposition limit. Step S2047: Determine the predicted time-shifted load sequence based on the baseline time-shifted load and the corrected total event pulse load; Step S2048, wherein the predicted values ​​in the predicted time-shifted load sequence are configured with confidence intervals, and the resource coordination control information is determined based on the upper bound of the confidence intervals.

[0104] Specifically, in situations where multiple critical events occur consecutively within a short period, the load from these multiple event pulses may simultaneously affect future time-shifted loads. The source station scheduling and control system can superimpose these multiple event pulse loads to obtain the total event pulse load. To mitigate the risk of over-reserving resources, an upper limit for pulse superposition can be set, and corrections can be made when the total event pulse load exceeds this limit. Confidence intervals can be used to characterize the uncertainty range of each predicted value in the predicted time-shifted load sequence. Resource coordination control information is determined based on the upper bound of the confidence interval, allowing for a certain margin in resource control.

[0105] In some embodiments, each predicted value in the predicted time-shifted load sequence can be configured with a corresponding confidence interval. The width of this confidence interval can be positively correlated with the time elapsed between the predicted time and the current time; that is, the further the predicted time is from the current time, the higher the uncertainty of the predicted value, and the wider the confidence interval can be. Resource coordination control information is determined based on the upper bound of the confidence interval, which can reserve more resource margin for the time-shifted cluster when the prediction uncertainty is high.

[0106] By using the above methods, the upper limit of the prediction results can be controlled when multiple events occur consecutively, while reserving a stable safety space for resource collaborative control and reducing the impact of prediction uncertainty on resource collaborative control.

[0107] Step S206 Based on the predicted time-shifted load sequence and time-shifted cluster capacity, resource coordination control information is determined.

[0108] Specifically, time-shift cluster capacity can be used to characterize the current or available time-shift request carrying capacity of the time-shift cluster. Resource coordination control information can be used to indicate the lending, reclamation, or hold status of resource units between the live broadcast cluster and the time-shift cluster. The source station scheduling and control system can perform matching analysis between the predicted time-shift load sequence and the time-shift cluster capacity to determine whether it is currently permissible to lend some time-shift cluster resources to the live broadcast cluster, or whether it is necessary to reclamation of already lent resource units to the time-shift cluster.

[0109] In some embodiments, the live streaming cluster and the time-shifted cluster can belong to different service domains. The origin server scheduling and control system can dynamically adjust the allocation of resource units across different service domains based on predicted time-shifted load changes. This approach can improve resource reuse rates across business scenarios and reduce resource idleness issues caused by long-term static resource reservations.

[0110] When the predicted time-shifted load is below the capacity of the time-shifted cluster and resource redundancy exists, the amount of resources available for lending can be determined. When the predicted time-shifted load shows an upward trend or is expected to approach the capacity constraints of the time-shifted cluster, resource reclamation trigger information can be determined. Resource coordination control information may include the number of resource units to be lent, the identifier of the resource unit to be lent, the resource reclamation trigger time, the identifier of the resource unit to be reclaimed, or other data that can be used for resource control.

[0111] In some embodiments, the source station scheduling control system can read the predicted time-shifted load sequence at a configurable period and compare the predicted time-shifted load sequence with the time-shifted cluster capacity. If the ratio of the predicted time-shifted load to the time-shifted cluster capacity remains below the borrowing trigger threshold, the source station scheduling control system can determine that there are available resources to be borrowed. If the predicted time-shifted load sequence indicates an upward trend in time-shifted load and the ratio of the predicted time-shifted load to the time-shifted cluster capacity is about to reach or exceed the reclamation trigger threshold, the source station scheduling control system can determine resource reclamation trigger information.

[0112] In this way, resource collaborative control information can be generated based on the predicted time-shifted load sequence rather than the current load state, enabling resource control to match the changing trend of time-shifted load in advance; at the same time, resource lending and resource reclamation can correspond to different trigger conditions, thereby avoiding frequent switching of resource units between live clusters and time-shifted clusters.

[0113] In an optional embodiment, determining resource coordination control information based on the predicted time-shifted load sequence and time-shifted cluster capacity may include steps S2061 to S2063: Step S2061: Based on the predicted time-shifted load sequence, determine the conservative predicted load within the target prediction time window; Step S2062: Based on the conservative predicted load and the time-shifted cluster capacity, determine the amount of resources that can be lent out or the resource reclamation trigger information; Step S2063: Generate the resource coordination control information based on the amount of resources available for lending or the resource recycling trigger information.

[0114] Specifically, the target prediction time window can be a configurable time window following the current moment. Conservative load prediction can be determined based on the higher predicted value, peak value, or upper bound of the confidence interval in the predicted time-shifted load sequence. Available resource quantity can be used to characterize the number of resource units allowed to be borrowed from the time-shifted cluster to the live streaming cluster. Resource reclamation trigger information can be used to characterize the need to reclaim resource units already borrowed to the live streaming cluster back to the time-shifted cluster.

[0115] In this way, a distinction can be made between the two control directions of resource lending and resource recovery, enabling the source station scheduling and control system to form corresponding control strategies based on predicted load trends.

[0116] In an optional embodiment, determining the amount of resources that can be lent out based on the conservatively predicted load and the time-shifted cluster capacity may include steps S2064 to S2066: Step S2064: Determine the lendable ratio based on the safety factor and the ratio between the conservative predicted load and the time-shifted cluster capacity; Step S2065: Determine the amount of resources that can be lent out based on the lent-out ratio and the number of resource units in the time-shifted cluster; Step S2066, wherein the resource unit is the smallest granularity of resource borrowing, and the resource unit includes a computing node and the network bandwidth resources corresponding to the computing node.

[0117] Specifically, a safety factor can be used to reserve additional capacity for time-shifted clusters. The ratio between the conservatively predicted load and the time-shifted cluster capacity can characterize the extent to which the predicted time-shifted load occupies the time-shifted cluster capacity. The source station scheduling and control system can determine the available lending ratio based on this ratio and the safety factor, and then calculate the number of available resource units based on the available lending ratio. Resource units include compute nodes and the network bandwidth resources corresponding to the compute nodes, allowing the lending operation to consider both computing power and network distribution capabilities.

[0118] In some embodiments, the source station scheduling control system can determine a candidate lending ratio based on the result of subtracting the ratio between the conservatively predicted load and the time-shifted cluster capacity from 1, combined with a safety factor, and compare the candidate lending ratio with zero, using the larger result as the available lending ratio. The safety factor can be a configurable parameter less than one, used to reserve additional capacity margin for the time-shifted cluster. For example, the source station scheduling control system can determine the remaining capacity ratio based on 1 - (conservatively predicted load / time-shifted cluster capacity), and scale the remaining capacity ratio based on the safety factor to obtain the available lending ratio. For example, with a safety factor of 0.8 and a remaining capacity ratio of 0.5, the available lending ratio can be determined to be 0.4.

[0119] In some embodiments, the source station scheduling and control system can convert the available lending ratio into the number of available resource units, and round down the conversion result to obtain the amount of available resources. By rounding down, the risk of over-lending caused by the conversion of decimal resource units can be reduced.

[0120] By using the above method, the predicted load can be linked to the granularity of resource borrowing, so that the determination of the amount of resources that can be borrowed has a clear calculation basis, thereby reducing the risk of insufficient time-shifted cluster capacity due to excessive resource borrowing.

[0121] Step S208 Based on the resource coordination control information, the control resource unit is allowed to lend or reclaim resources between the live streaming cluster and the time-shifted cluster.

[0122] Specifically, the source station scheduling and control system can control the ownership relationship of resource units based on resource coordination control information. When the resource coordination control information indicates that resources can be lent out, the target resource unit can be identified from the time-shifted cluster and migrated to the live broadcast cluster. When the resource coordination control information indicates that resources need to be reclaimed, the resource unit to be reclaimed can be identified from the resource units already lent to the live broadcast cluster and reclaimed to the time-shifted cluster.

[0123] The lending or reclamation of resource units can involve operations such as registration or deregistration with the service discovery system, updating load balancing weights, and updating resource status. The origin server scheduling and control system can control these operations to switch the service range of the corresponding resource unit from one cluster to another.

[0124] In this way, the live streaming cluster and the time-shifted cluster can coordinate resources based on the predicted time-shifted load sequence, thereby improving the matching degree between resource configuration and load changes.

[0125] In an optional embodiment, controlling the resource unit to borrow resources between the live streaming cluster and the time-shifted cluster based on the resource coordination control information may include steps S2081 to S2084: Step S2081: Determine the target resource unit corresponding to the amount of available resources from the idle resource pool of the time-shifted cluster; Step S2082: Control the target resource unit to migrate from the time-shift cluster to the live streaming cluster; Step S2083: Register the target resource unit to the service discovery system corresponding to the live streaming cluster; Step S2084: Update the load balancing weights corresponding to the live streaming cluster.

[0126] Specifically, the idle resource pool can include resource units currently belonging to the time-shifted cluster that have not been borrowed. The origin server scheduling and control system can select target resource units from the idle resource pool based on the amount of available resources and control the migration of the target resource units to the live streaming cluster. After registering the target resource units with the service discovery system corresponding to the live streaming cluster, the load balancer of the live streaming cluster can distribute live streaming requests to the target resource units. Updating the load balancing weights corresponding to the live streaming cluster allows the target resource units to gradually receive live streaming requests.

[0127] By using the above method, resource units can be borrowed to the live streaming cluster when there is predicted redundant capacity in the time-shifted cluster, thereby improving resource utilization efficiency.

[0128] In an optional embodiment, determining the target resource unit corresponding to the amount of lent resources from the idle resource pool of the time-shifted cluster may include steps S2085 to S2087: Step S2085: Obtain the load status and location attributes of each candidate resource unit in the idle resource pool; Step S2086: Sort the candidate resource units based on the load status and the location attribute; Step S2087: Based on the sorting results, determine the target resource unit from the candidate resource units.

[0129] Specifically, load status can be used to characterize the current computing load, network bandwidth usage, or number of connections of a candidate resource unit. Location attributes can be used to characterize the network location relationship between the candidate resource unit and the live streaming hotspot area or the live streaming cluster service area. The origin server scheduling and control system can prioritize candidate resource units with lower load and location attributes that better match the needs of the live streaming cluster as target resource units.

[0130] In some embodiments, location attributes may include the network location relationship between candidate resource units and live streaming cluster hotspot areas. The origin server scheduling and control system may prioritize candidate resource units with lower current load and closer network distance to live streaming cluster hotspot areas as target resource units.

[0131] For example, the source station scheduling and control system can generate a comprehensive score based on the CPU utilization, network bandwidth utilization, and network latency between the candidate resource unit and the live streaming hotspot area, and sort the candidate resource units according to the comprehensive score from high to low. Thus, candidate resource units with lower network latency and lower CPU utilization can obtain higher sorting priority.

[0132] By using the above methods, the borrowed target resource unit can be made more suitable for receiving live streaming cluster requests, reducing the decline in scheduling performance caused by high load on the resource unit itself or mismatch in network location.

[0133] In an optional embodiment, the method may further include steps S2088 to S2089: Step S2088: Maintain the resource status for each resource unit. The resource status includes ready status, lending status, borrowed status, and recycling status. Step S2089: During the process of the control resource unit borrowing or reclaiming resources between the live streaming cluster and the time-shifted cluster, the resource status of the resource unit is updated.

[0134] Specifically, the ready state indicates that the resource unit belongs to the available resource pool of the time-shifted cluster; the loaning state indicates that the resource unit is being migrated from the time-shifted cluster to the live streaming cluster; the loaned-out state indicates that the resource unit has received a request in the live streaming cluster; and the recycling state indicates that the resource unit is being migrated from the live streaming cluster back to the time-shifted cluster. The source station scheduling and control system can update the resource status according to the migration progress of the resource unit.

[0135] By using the above methods, the source station scheduling and control system can clearly define the ownership and migration status of each resource unit at any given time, thereby reducing the risk of the same resource unit being repeatedly borrowed or reclaimed.

[0136] In an optional embodiment, determining resource reclamation trigger information based on the conservative predicted load and the time-shifted cluster capacity may include steps S20810 to S20812: Step S20810: In the case where the predicted time-shifted load sequence indicates that the time-shifted load is on an upward trend, determine the resource reclamation trigger information; Step S20811: Determine the pre-recovery window based on the load rise rate and resource switching time corresponding to the predicted time-shifted load sequence; Step S20812: Based on the pre-recovery window, generate resource coordination control information for controlling the recovery of lent resource units.

[0137] Specifically, the load rise rate can be determined based on the load changes between adjacent prediction times in the predicted time-shifted load sequence. The time required for resource switching can include the connection clearing time, deregistration time, registration time, and load balancing weight update time required for a resource unit to switch from the live cluster back to the time-shifted cluster. The pre-reclaim window allows the source server scheduling and control system to initiate resource reclamation in advance before the predicted time-shifted load reaches a high level.

[0138] By using the above methods, resource units can be returned to the time-shifted cluster before the time-shifted load actually increases, thereby improving the time-shifted cluster's preparedness for subsequent increases in time-shifted requests.

[0139] In an optional embodiment, controlling the reclamation of resource units between the live streaming cluster and the time-shifted cluster based on the resource coordination control information may include steps S20813 to S20816: Step S20813: Determine the resource units to be reclaimed from the resource units that have been borrowed to the live streaming cluster; Step S20814: Control the load balancer of the live streaming cluster to mark the resource unit to be reclaimed as empty, so that the resource unit to be reclaimed will no longer receive new connections. Step S20815: If the resource unit to be recycled meets the conditions for completion of emptying, the resource unit to be recycled is deregistered from the service discovery system corresponding to the live streaming cluster, and the resource unit to be recycled is registered to the service discovery system corresponding to the time-shifted cluster. Step S20816: Update the load balancing weights corresponding to the time-shifted cluster.

[0140] Specifically, resource units to be reclaimed can be selected from those already lent to the live streaming cluster. The emptied state prevents the live streaming cluster from allocating new connections to the resource units to be reclaimed, while allowing existing connections to continue processing. Once the emptied resource unit meets the emptied condition, it can be deregistered from the live streaming cluster service discovery system and registered with the time-shifted cluster service discovery system. After updating the load balancing weights corresponding to the time-shifted cluster, time-shifted requests can be allocated to that resource unit.

[0141] In some embodiments, deregistering the resource unit to be reclaimed from the service discovery system corresponding to the live streaming cluster and registering it with the service discovery system corresponding to the time-shifted cluster can be performed atomically. Specifically, the origin server scheduling and control system can complete the deregistration of the resource unit to be reclaimed from the live streaming cluster service discovery registry and its registration with the time-shifted cluster service discovery registry within the same switching transaction. This ensures that at any given time, the resource unit to be reclaimed belongs to only one of the live streaming cluster or the time-shifted cluster, reducing request routing confusion caused by the same resource unit being scheduled by two clusters simultaneously.

[0142] By using the above methods, the impact on existing live streaming connections can be reduced when reclaiming resource units, and the reclaimed resource units can receive time-shift requests in a timely manner.

[0143] In an optional embodiment, after the load balancer of the live streaming cluster marks the resource unit to be reclaimed as empty, steps S20817 to S20819 may be included: Step S20817: Monitor the number of active connections on the resource unit to be reclaimed; Step S20818: When the number of active connections drops to zero, determine that the resource unit to be recycled meets the emptying completion condition; Step S20819: If the waiting time meets the maximum waiting time and the number of active connections has not dropped to zero, send a flow end signal to the connection on the resource unit to be reclaimed, and close the connection on the resource unit to be reclaimed.

[0144] Specifically, the number of active connections can be used to characterize the number of live connections still being processed on the resource unit to be reclaimed. The origin server scheduling and control system can perform service discovery switching when the number of active connections drops to zero. If the waiting time reaches the maximum waiting time and there are still active connections, a flow end signal can be sent to the relevant connection and the connection can be closed to avoid the resource unit to be reclaimed remaining in a reclaiming state for an extended period.

[0145] By using the above methods, the resource recycling process can be made controllable by setting termination conditions while minimizing the impact on existing connections.

[0146] In an optional embodiment, the method may further include step S20820: Step S20820: During the process of controlling resource units to borrow or reclaim resources between the live streaming cluster and the time-shifted cluster, the time-shifted cluster controls the retention of resource units not less than a preset safety lower limit ratio that do not participate in the borrowing.

[0147] Specifically, the preset safety lower limit ratio can be used to characterize the minimum proportion of resources that the time-shifted cluster should retain during any resource borrowing process. When determining the amount of resources that can be borrowed or executing resource borrowing, the source station scheduling and control system can use this preset safety lower limit ratio as a constraint to ensure that a portion of resource units remain in the time-shifted cluster.

[0148] By using the above methods, the basic carrying capacity of the time-shift cluster can be maintained while improving resource utilization, reducing the risk of insufficient time-shift request capacity due to excessive lending.

[0149] In an optional embodiment, the method may further include steps S210 to S216: Step S210: Obtain time-shift request statistics, which are generated based on at least one of the target timestamp of the time-shift playback request, the viewing duration, and the request source information; Step S212: Based on the time-shift request statistics, determine the hot spots on the live broadcast timeline; Step S214: Associate the hotspot segments with the event anchor points in the activity event graph to generate event popularity association data; Step S216: Based on the event popularity correlation data, update the prediction parameters corresponding to the event type in the activity event map.

[0150] Specifically, time-shift request statistics can be obtained by aggregating and statistically analyzing time-shift playback requests. The target timestamp can be used to characterize the live broadcast time position of the time-shift playback request, the viewing duration can be used to characterize the continuous access time of the requester to that segment, and the request source information, which is aggregated or anonymized, can be used to characterize the region or node information of the request source. The origin server scheduling and control system can bin the time-shift request statistics according to the live broadcast timeline to obtain the request density of different time segments, and identify segments with higher request density as hotspot segments.

[0151] In some embodiments, time-shift request statistics can be obtained by aggregating time-shift playback request metadata collected from the CDN edge and the origin server. The time-shift playback request metadata may include the target timestamp of the time-shift playback request, the actual viewing duration, and the request source information after aggregation or de-identification. The origin server scheduling and control system can divide the live broadcast timeline into buckets according to a configurable statistical window length and count the number of time-shift requests within each time bucket.

[0152] In some embodiments, the request density can be determined based on the ratio between the number of time-shifted requests within a time bucket and the window duration of that time bucket. The system can compare the request density corresponding to each time bucket with the average request density for the entire target live event. If the request density corresponding to a certain time bucket exceeds the product of the average request density and a preset threshold multiple, the live time segment corresponding to that time bucket can be identified as a hotspot segment.

[0153] Specifically, hotspot segments and event anchors can be correlated based on time distance or time overlap to generate event popularity correlation data. This data can characterize the actual time-shifted replay popularity of a particular type of event, providing a basis for subsequent updates to prediction parameters. For example, the source station scheduling and control system can perform time alignment analysis based on the time difference between the center time of a hotspot segment and the timestamp of the event anchor. If the time difference is less than a preset correlation time threshold, it can be determined that there is a correlation between the hotspot segment and the corresponding event anchor. This improves the matching accuracy of event popularity correlation data.

[0154] By using the above method, the prediction parameters can be updated based on the actual time-shift request statistics, reducing the prediction bias caused by using fixed prediction parameters for a long time.

[0155] In an optional embodiment, updating the prediction parameters corresponding to the event type in the activity event map based on the event popularity correlation data may include steps S2161 to S2164: Step S2161: Based on the event popularity correlation data, determine the actual request density peak and predicted pulse peak corresponding to the event type; Step S2162: Update the influence parameter corresponding to the event type based on the actual request density peak and the predicted pulse peak. Step S2163: Update the decay parameter corresponding to the event type based on the request density decay curve corresponding to the hot spot segment; Step S2164, wherein the updates of the influence parameter and the decay parameter are constrained by the single adjustment magnitude and the cumulative adjustment range.

[0156] Specifically, the actual peak request density can be determined based on the maximum value or statistical peak of the time-shifted request density in the hotspot segment. The predicted pulse peak can be determined based on the predicted pulse value corresponding to the event anchor point in the predicted time-shifted load sequence. The influence parameter can be updated based on the deviation between the actual peak request density and the predicted pulse peak. The request density decay curve can be obtained based on the change in request density in each time segment after the hotspot segment, and the decay parameter can be updated based on this decay curve.

[0157] In some embodiments, the origin server scheduling control system can determine the correction direction and magnitude of the influence parameter based on the ratio between the actual peak request density and the predicted peak pulse value corresponding to an event type. Furthermore, the origin server scheduling control system can adjust the influence parameter corresponding to the event type in conjunction with a configurable learning rate. In this way, the influence parameter can be adjusted upwards when the actual peak request density is higher than the predicted peak pulse value, and downwards when the actual peak request density is lower than the predicted peak pulse value, making the predicted peak pulse load of subsequent similar events closer to the actual request distribution.

[0158] In some embodiments, prediction parameter updates can be performed on a session-level or event-level feedback basis. Session-level feedback can be performed in batches after a target live event concludes to update prediction parameters based on time-shifted request statistics for the entire event. Event-level feedback can be performed during the event to perform in-game fine-tuning after detecting key events that meet the criteria for extremely high impact, in order to correct predictions for subsequent similar events within the same event. This approach balances the stability of parameter updates with the timeliness of response to high-impact events.

[0159] The above methods can be used to update the impact level and decay characteristics corresponding to the event type, making the subsequent predicted time-shift load sequence closer to the actual time-shift request distribution; by constraining the single adjustment magnitude and cumulative adjustment range, the risk of excessive parameter fluctuations can be reduced.

[0160] Example 2 Figure 3 A flowchart illustrating a time-shifted content preheating control method according to Embodiment 2 of this application is shown schematically. This time-shifted content preheating control method can be applied to a CDN preheating control system. Figure 3 As shown, the time-shifted content preheating control method may include steps S300 to S308, wherein: Step S300: Receive preheating trigger information, which is generated based on event anchors in the activity event graph and includes event type and anchor timestamp; Step S302: Determine the preheating target time interval based on the event type and the anchor timestamp; Step S304: Based on the preheating target time interval, determine the time-shifted content segment list; Step S306: Generate a preheating task based on the time-shifted content fragment list; Step S308: Based on the preheating task, control the target cache node to cache the corresponding time-shifted content fragment.

[0161] In this embodiment, the CDN preheating control system receives preheating trigger information generated based on event anchors, thereby obtaining the event type and anchor timestamp corresponding to the key events of the activity. By determining the target preheating time interval based on the event type and anchor timestamp, the range of time-shifted content related to the key events of the activity can be determined. Furthermore, by determining a list of time-shifted content segments based on the target preheating time interval and generating preheating tasks, the preheating control object can be concretized into cacheable time-shifted content segments. By controlling the target cache node to cache the corresponding time-shifted content segments based on the preheating tasks, the time-shifted content segments related to the key events of the activity can enter the target cache node before the user's time-shifting request arrives, thereby reducing the possibility of related requests penetrating the cache and returning to the origin.

[0162] The following combination Figure 3 The steps S300 to S308 and other optional steps are further described below.

[0163] Step S300 The system receives preheating trigger information, which is generated based on event anchors in the activity event graph. The preheating trigger information includes the event type and the anchor timestamp.

[0164] Specifically, preheating trigger information can be generated by the origin server scheduling and control system, the activity event graph layer, or other systems capable of accessing the activity event graph. Event types can be used to characterize the categories of key events in the activity, and anchor timestamps can be used to characterize the location of the key event on the live broadcast timeline. After receiving the preheating trigger information, the CDN preheating control system can determine the range of time-shifted content that needs to be preheated based on the preheating trigger information.

[0165] The CDN preheating control system can obtain preheating triggering basis from event anchor points, so that the preheating process is associated with the position of key events on the live broadcast timeline.

[0166] Step S302 Based on the event type and the anchor timestamp, the preheating target time interval is determined.

[0167] Specifically, different event types may correspond to different replay ranges. For example, replay requests for certain events may be concentrated in the period before and after the event occurs. The CDN preheating control system can determine the corresponding pre-offset and post-offset based on the event type, and combine this with the anchor timestamp to determine the target preheating time interval. The target preheating time interval can be used to characterize the range of time-shifted content that needs to be cached in advance.

[0168] By using the above methods, the target time interval for preheating can be aligned with the type and occurrence time of key events in the activity, reducing the waste of cache resources or insufficient preheating caused by an overly wide or narrow preheating range.

[0169] In an optional embodiment, determining the preheating target time interval based on the event type and the anchor timestamp may include steps S3021 to S3023: Step S3021: Based on the event type, query the mapping relationship between the event type and the preheating parameters to obtain the pre-offset and post-offset corresponding to the event type; Step S3022: Determine the start time of the preheating target time interval based on the anchor timestamp and the preceding offset; Step S3023: Determine the end time of the preheating target time interval based on the anchor timestamp and the post offset.

[0170] Specifically, the mapping relationship between event types and preheating parameters can be used to record the preheating range parameters corresponding to different types of events. The preceding offset can be used to determine the content range that needs to be preheated before the event occurs, and the following offset can be used to determine the content range that needs to be preheated after the event occurs. The CDN preheating control system can use the anchor timestamp as a reference, shifting forward by the preceding offset to obtain the start time, and shifting backward by the following offset to obtain the end time.

[0171] In some embodiments, the mapping relationship between event types and preheating parameters may include the correspondence between event type, pre-offset offset, post-offset offset, push level, and priority level. The pre-offset and post-offset offsets can be used to determine the target preheating time interval, the push level can be used to determine the target cache node level corresponding to the preheating task, and the priority level can be used to determine the sorting position of the preheating task in the priority queue. Through the above mapping relationship, the CDN preheating control system can determine the preheating range, preheating depth, and task priority according to the differences in different event types.

[0172] Using the above methods, the target time interval for preheating can be determined according to the differences in event types, so that the preheating range is closer to the distribution of review needs for key events of different activities.

[0173] Step S304 Based on the preheating target time interval, a list of time-shifted content segments is determined.

[0174] Specifically, time-shifted content can be organized in the form of media slices, index file fragments, or other media content fragments. The CDN preheating control system can query the slice index of time-shifted content and filter content fragments whose timestamps fall within the preheating target time interval from the slice index to form a list of time-shifted content fragments.

[0175] Using the above method, the preheating target time interval can be converted into a specific set of executable cache objects, which facilitates the subsequent generation of preheating tasks.

[0176] In an optional embodiment, determining the list of time-shifted content segments based on the preheating target time interval may include steps S3041 to S3044: Step S3041: Query the slice index of the time-shifted content; Step S3042: Determine the media slice identifier whose timestamp falls within the preheating target time interval from the slice index; Step S3043: Determine the index file segment corresponding to the media slice identifier; Step S3044: Generate the time-shifted content segment list based on the media slice identifier and the index file fragment.

[0177] Specifically, in scenarios based on HLS and other fragmented transmission methods, media slice identifiers can correspond to TS slice files, and index file fragments can correspond to relevant fragments in M3U8 index files. The CDN preheating control system can use both media slice identifiers and index file fragments as preheating objects, so that the target cache node can provide both media slice and index information simultaneously when it receives a time-shift request.

[0178] In some embodiments, the CDN preheating control system can arrange time-shifted content segments in the playback order list. During the arrangement process, the CDN preheating control system can set higher priority for time-shifted content segments that are closer to the anchor timestamp. In this way, time-shifted content segments that are closer to the occurrence time of the key event can be cached first during the preheating process, thereby improving the timeliness of preheating key time-shifted content.

[0179] By using the above methods, the completeness of the time-shifted content fragment list can be improved, and the risk of requests going back to the origin caused by only warming up media slices without warming up index file fragments can be reduced.

[0180] Step S306 Based on the list of time-shifted content fragments, a preheating task is generated.

[0181] Specifically, a preheating task may include a list of time-shifted content segments to be preheated, a target cache node range, task priority, task status, or other information used to control the preheating execution. The CDN preheating control system can encapsulate the list of time-shifted content segments into one or more preheating tasks to allow for independent scheduling of different events or different preheating objects.

[0182] Using the methods described above, a list of time-shifted content fragments can be converted into schedulable, traceable, and executable task objects.

[0183] In an optional embodiment, the preheating trigger information further includes an event importance level; generating a preheating task based on the time-shifted content segment list may include steps S3061 to S3063: Step S3061: Determine the task priority of the preheating task based on the importance level of the event; Step S3062: Generate the preheating task based on the task priority and the time-shifted content fragment list; Step S3063: Insert the preheating task into the priority queue.

[0184] Specifically, event importance levels can be used to characterize the degree to which critical events of an activity may cause a concentration of time-shift requests. The CDN preheating control system can determine task priorities based on event importance levels and insert preheating tasks into a priority queue. The priority queue can be used to control the execution order of preheating tasks when multiple preheating tasks exist concurrently.

[0185] By using the above methods, pre-event tasks corresponding to more important activities and key events can be prioritized, thereby improving the coverage of pre-event resources for key time-shifted content.

[0186] Step S308Based on the preheating task, the target cache node is controlled to cache the corresponding time-shifted content fragment.

[0187] Specifically, the target cache node may include at least one of CDN edge nodes, CDN middleware nodes, or origin server hot cache. The CDN preheating control system can control the target cache node to pull or receive the corresponding time-shifted content segment based on the time-shifted content segment list and target cache node information in the preheating task, so that the time-shifted content segment is cached in the target cache node.

[0188] In this way, time-shifted content fragments corresponding to key events of the activity can be deployed to the target cache node before the time-shifted request group arrives, thereby reducing the probability that the target cache node will send a request to the origin server due to cache miss.

[0189] In an optional embodiment, controlling the target cache node to cache the corresponding time-shifted content segment based on the preheating task may include steps S3081 to S3084: Step S3081: Obtain the preheating task to be executed from the priority queue; Step S3082: Determine the target cache node based on the event importance level corresponding to the preheating task to be executed; Step S3083: Control the target cache node to cache the time-shifted content fragment corresponding to the preheating task to be executed; Step S3084, wherein the target cache node includes at least one of CDN edge node, CDN middle layer node or origin hot cache.

[0190] Specifically, for pre-warming tasks with high event importance, the CDN pre-warming control system can identify CDN edge nodes with coverage closer to the requesting end as target cache nodes. For pre-warming tasks with low event importance, CDN middle-layer nodes or origin server hot caches can be identified as target cache nodes. The selection method for target cache nodes can be configured based on event importance, cache resource status, node coverage, or historical request distribution.

[0191] In some embodiments, the CDN preheating control system can determine the push level corresponding to the target cache node based on the event's importance level. For critical events that meet the highest importance criteria, the CDN preheating control system can identify CDN edge nodes as target cache nodes, so that the corresponding time-shifted content segments are pushed to cache nodes closer to the requesting end. For critical events that meet the medium importance criteria, the CDN preheating control system can identify CDN middle-layer nodes as target cache nodes, so that edge nodes can pull content on demand in subsequent requests. For critical events that meet the low importance criteria, the CDN preheating control system can identify the origin server hot cache as the target cache node to improve the subsequent origin server response speed.

[0192] The above method allows for layered control of preheating depth based on the importance of events, balancing cache hit rate and cache resource consumption.

[0193] In an optional embodiment, controlling the target cache node to cache the corresponding time-shifted content segment based on the preheating task may include steps S3085 to S3087: Step S3085: Allocate a preheating bandwidth quota to the preheating task that is independent of the user request service; Step S3086: Within the preheating bandwidth quota, preheating transmission bandwidth is allocated based on the task priority of each preheating task in the priority queue. Step S3087: If the usage status of the preheating bandwidth quota meets the quota restriction conditions, the low-priority preheating task is slowed down or suspended.

[0194] Specifically, preheating bandwidth quotas can be used to limit the network transmission resources occupied by preheating tasks, preventing them from affecting user service requests. The CDN preheating control system can allocate preheating transmission bandwidth to each preheating task according to its priority within the preheating bandwidth quota. When the preheating bandwidth quota reaches or approaches its limit, low-priority preheating tasks can be slowed down or suspended.

[0195] In some embodiments, when multiple preheating tasks compete for preheating bandwidth quotas, the CDN preheating control system can allow high-priority preheating tasks to preempt at least a portion of the preheating transmission bandwidth of low-priority preheating tasks. The low-priority preheating tasks whose bandwidth is preempted can be executed at a reduced speed or suspended. In this way, time-shifted content fragments corresponding to active key events that are more likely to cause concentrated time-shift requests can be prioritized to reach the target cache node.

[0196] By using the above methods, the impact of the preheating task on user request services can be controlled while the preheating task is being executed, making the preheating control process more stable.

[0197] In an optional embodiment, the method may further include steps S310 to S312: Step S310: Obtain the task execution status of the preheating task, the task execution status including the push success status and / or push delay status corresponding to the target cache node; Step S312: Based on the task execution status, update the preheating completion status of the preheating task.

[0198] Specifically, the task execution status can be returned by the target cache node, the preheating task scheduler, or relevant monitoring modules. A successful push status indicates whether the time-shifted content fragment has entered the target cache node, while a push delay status indicates the latency during the preheating task execution process. The CDN preheating control system can update the preheating completion status based on the task execution status for subsequent queries to determine if the preheating task is complete.

[0199] In some embodiments, the task execution status may include the push success rate and push latency statistics for each target cache node. The push success rate can be used to characterize the proportion of time-shifted content segments successfully cached in the target cache node, and the push latency statistics can be used to characterize the time spent from the generation of the preheating task to the completion of caching. The CDN preheating control system can update the preheating completion status of the preheating task based on the push success rate and push latency statistics.

[0200] The above methods can be used to track the status of the preheating task, making the preheating process observable and updatable.

[0201] In an optional embodiment, the method may further include steps S314 to S320: Step S314: Obtain time-shift request statistics; Step S316: Based on the time-shift request statistics, determine the hot spots on the live broadcast timeline; Step S318: Associate the hotspot segment with the event anchor point to generate event preheating feedback data; Step S320: Based on the event preheating feedback data, update the mapping relationship between event type and preheating parameters.

[0202] Specifically, time-shift request statistics can be generated based on the target timestamp, viewing duration, request source information, or other statistical dimensions of time-shift replay requests on the live stream timeline. Hotspot segments can be live stream time segments with high time-shift request density. The CDN preheating control system can associate hotspot segments with event anchors to determine whether the actual replay range triggered by a certain type of event matches the existing preheating parameters.

[0203] In some embodiments, time-shift request statistics can be obtained by aggregating time-shift playback request metadata collected from the CDN edge and origin servers. The time-shift playback request metadata may include the target timestamp of the time-shift playback request, the actual viewing duration, and the request source information after aggregation or de-identification processing. The CDN preheating control system can divide the live broadcast timeline into buckets according to a configurable statistical window length and count the number of time-shift requests within each time bucket.

[0204] In some embodiments, the request density can be determined based on the ratio between the number of time-shifted requests within a time bucket and the window duration of that time bucket. The CDN preheating control system can compare the request density corresponding to each time bucket with the average request density corresponding to the entire target live event. If the request density corresponding to a certain time bucket exceeds the product of the average request density and a preset threshold multiple, the live time segment corresponding to that time bucket can be identified as a hotspot segment.

[0205] Using the above method, the mapping relationship between event types and preheating parameters can be updated according to the actual time-shift request distribution, so that the subsequent preheating target time interval is closer to the actual playback range.

[0206] In an optional embodiment, updating the mapping relationship between event type and preheating parameters based on the event preheating feedback data may include steps S3201 to S3203: Step S3201: Determine the preceding offset statistical value based on the difference between the playback start time corresponding to the hot spot segment and the anchor point timestamp; Step S3202: Determine the post-offset statistical value based on the difference between the playback end time corresponding to the hot spot segment and the anchor point timestamp; Step S3203: If the preceding offset statistics or the following offset statistics meet the adjustment triggering conditions, update the preceding offset or following offset corresponding to the event type.

[0207] Specifically, the preceding offset statistics can be used to characterize the offset of the actual playback start time relative to the event anchor timestamp, and the following offset statistics can be used to characterize the offset of the actual playback end time relative to the event anchor timestamp. If there is a discrepancy between the preceding or following offset statistics and the current preheating parameters that needs adjustment, the CDN preheating control system can update the preceding or following offset corresponding to the event type.

[0208] In some embodiments, the preceding offset statistic can be determined based on the median offset of the playback start time relative to the anchor timestamp for multiple hotspot segments. The following offset statistic can be determined based on the median offset of the playback end time relative to the anchor timestamp for multiple hotspot segments. By using the median as the statistic, the impact of a small number of abnormal playback requests on the update of the warm-up range mapping relationship can be reduced.

[0209] In some embodiments, the mapping between event types and preheating parameters can be updated via either session-level or event-level feedback. Session-level feedback can be performed in batches after a target live event concludes, updating preheating parameters based on time-shifted request statistics for the entire event. Event-level feedback can be performed during the event to fine-tune the preheating of subsequent similar events within the same event after detecting a key event that meets the criteria for extremely high impact. This approach balances the stability of parameter updates with the timeliness of response to high-impact events.

[0210] The above method allows for feedback updates to the preheating range, reducing insufficient or redundant preheating caused by a mismatch between the fixed preheating range and the actual playback range.

[0211] To facilitate understanding of this application, an exemplary application of time-shifted content preheating control is provided below. In this exemplary application, an event anchor point corresponding to a goal event is generated in the event graph. This event anchor point is associated with an event type and an anchor point timestamp. The CDN preheating control system receives preheating trigger information generated based on this event anchor point and queries the mapping relationship between the event type and preheating parameters based on the event type to obtain the pre-offset and post-offset. The CDN preheating control system determines the target preheating time interval based on the anchor point timestamp and queries the slice index of the time-shifted content. From the slice index, it selects the media slice identifier and the corresponding index file fragment that fall within the target preheating time interval. The CDN preheating control system generates preheating tasks based on these media slice identifiers and index file fragments and inserts the preheating tasks into a priority queue according to the event importance level. Subsequently, the CDN preheating control system retrieves the preheating tasks to be executed from the priority queue and controls the target cache node to cache the corresponding time-shifted content fragments. Thus, time-shifted content fragments related to key events of the event can be pre-cached to the target cache node.

[0212] In one exemplary application, the CDN preheating control system can respond to the same critical event in parallel with the origin server scheduling control system. While the origin server scheduling control system determines the predicted time-shifted load sequence based on the critical event and triggers the resource pre-reclamation process, the CDN preheating control system can synchronously receive preheating trigger information generated based on the event anchor point of the critical event. The CDN preheating control system can determine the target preheating time interval based on the event type, using the anchor point timestamp as the center, and set the time-shifted content segments within this target time interval as preheating objects. For critical events with high importance, the CDN preheating control system can prioritize pushing media slices and index file segments near the anchor point to CDN edge nodes. In this way, resource reclamation and content preheating can be performed in parallel for the same critical event, reducing the origin server back-to-origin pressure when time-shifted requests arrive in concentrated bursts.

[0213] In some embodiments, the CDN preheating control system pre-caches corresponding time-shifted content segments to target cache nodes based on key event activities. This increases the likelihood of cache nodes hitting the corresponding time-shifted content segments, reduces the probability of time-shifted requests penetrating cache nodes and returning to the origin server, and lowers the processing pressure on the origin server caused by concentrated origin server requests. These effects can be evaluated based on the preheating task execution status, push success rate, push latency statistics, and subsequent time-shifted request statistics.

[0214] To make this application easier to understand, several exemplary applications are provided below to illustrate this embodiment.

[0215] In an exemplary application, such as Figure 4As shown, the target live streaming event is a large-scale football match broadcast live. The match calendar provides schedule information to the event event graph layer (match event graph layer), and the real-time event stream continuously reports events such as goals and penalties. The stage state machine in the match event graph layer executes stage transitions according to the match progress, and the event anchor registration module timestamps key events; the event pulse prediction model combines stage states and event anchors to calculate event pulse load. For example, after a goal occurs in the second half, the system predicts that a large number of time-shifted replay requests will occur in a short period of time. The resource elastic borrowing and coordination layer performs borrowing ratio calculation based on the prediction results to determine the available borrowing ratio, and generates resource coordination control information for controlling the reclamation of borrowed resource units through connection emptying, service discovery switching, and pre-reclamation windows, and reclaims some resource units that have been borrowed to the live streaming cluster to the time-shift cluster in advance. The CDN preheating control system dynamically determines the preheating target time interval according to the event anchors, and preheats the corresponding time-shifted content to CDN edge nodes and CDN middle layer nodes through the preheating task queue module and multi-level push strategy. In the origin cluster layer, the live streaming cluster includes fixed resources and a borrowed resource pool, while the time-shifted cluster includes fixed resources and a borrowed resource pool. Resource ownership between the two is dynamically switched based on prediction results. When a user initiates a time-shift request on their terminal, if CDN edge nodes A, B, C, or D have already completed pre-warming, the CDN edge node directly hits the cache; otherwise, it returns to the origin cluster. Some CDN edge nodes can pre-cache time-shifted content segments based on pre-warming tasks, while others can retrieve time-shifted content from the origin cluster on demand. The system also collects time-shifted request statistics, generated based on at least one of the target timestamp, viewing duration, and request source information of the time-shifted playback request. These statistics are then used in the playback popularity feedback analysis layer to perform request density statistics, automatic marking of hot segments, and parameter calibration feedback.

[0216] In another exemplary application, such as Figure 5As shown, during a live broadcast of a large-scale sporting event, the event data source (event data source) continuously pushes event event data (event event data) to the system, including key events such as goals, penalties, and substitutions. After receiving the event event data, the event graph prediction model generates event anchors and determines the predicted time-shift load sequence based on the current event stage (current event stage). For example, when the system detects a goal, it can predict a large number of time-shift replay requests in the near future, forming a corresponding predicted time-shift load sequence and preheating trigger information. Simultaneously, the playback terminal initiates time-shift requests and generates time-shift request statistics. The replay popularity feedback analysis module performs statistical analysis on user requests, obtaining request density and hotspot segment information. For example, the system can identify high-frequency replay behavior in video segments near a goal. The replay popularity feedback analysis module further forms parameter calibration feedback from the hotspot analysis results, used to update the influence parameters and decay constants in the event graph prediction model; it can also generate preheating optimization feedback to update the preheating range mapping table. Driven by the prediction signal, the dual-cluster elastic borrowing and coordination module performs resource borrowing, connection emptying, service discovery switching, and resource reclamation. For example, when a surge in time-shifted load is predicted, some resources borrowed from the live streaming cluster are reclaimed to the time-shifted cluster. The time-shifted content preheating control system executes content push, priority sorting, and multi-level preheating, distributing time-shifted content corresponding to hot events to edge node caches in advance. In the origin server + CDN layer, the live streaming cluster and the time-shifted cluster dynamically adjust resource ownership according to the borrowing strategy, and CDN edge nodes respond to the preheated cached content. When the playback client initiates another time-shifted request, the cached content can be returned directly by the CDN edge nodes first, thereby reducing the pressure on the origin server and improving the playback client's request response efficiency.

[0217] In another exemplary application, the target live event is a live sports event. The origin server scheduling and control system receives event phase data (event phase data) and determines that the target live event (target live sports event) is currently in the second half. The origin server scheduling and control system receives event event data, determines that a goal event has occurred at a certain moment on the live timeline, and generates an event anchor point corresponding to the goal event. Based on the baseline parameters corresponding to the second half phase, the importance weight of the target live sports event, the influence parameters and decay parameters corresponding to the goal event, the origin server scheduling and control system determines the predicted time-shifted load sequence within the future target prediction time window. If the predicted time-shifted load sequence indicates that the time-shifted load is about to increase, the origin server scheduling and control system determines a pre-reclaiming window and identifies resource units to be reclaimed from the resource units already lent to the live streaming cluster. The origin server scheduling and control system controls the load balancer of the live streaming cluster to mark the resource units to be reclaimed as empty, so that they no longer receive new live streaming connections; after the number of active connections drops to zero, the origin server scheduling and control system deregisters the resource unit to be reclaimed from the service discovery system corresponding to the live streaming cluster and registers it to the service discovery system corresponding to the time-shifted cluster. Thus, the resource unit can be returned to the time-shifted cluster before the concentrated arrival of time-shifted requests.

[0218] In another exemplary application, the target live broadcast event is a large-scale sporting event. The origin server scheduling and control system detects a goal event at the 78th minute of the live broadcast timeline and registers the corresponding event anchor in the event graph (event event graph). This event anchor can be associated with the event type, anchor timestamp, and current event phase status (current event phase status). If a yellow card event occurred at the 65th minute before the goal event, the origin server scheduling and control system can determine that the pulse contribution of the yellow card event has attenuated based on the time difference between the yellow card event and the current time, and make the current predicted time-shift load sequence mainly affected by the event pulse load of the goal event in the 78th minute. The origin server scheduling and control system can initiate the resource pre-reclamation process in advance based on this predicted time-shift load sequence, and control the resource units already lent to the live broadcast cluster to perform connection emptying and service discovery switching. In this way, resource units can be returned to the time-shift cluster before the concentrated arrival of time-shift requests, thereby improving the time-shift cluster's readiness to handle subsequent time-shift requests.

[0219] In some embodiments, the predicted time-shift load sequence can characterize the future time-shift request load corresponding to key events of an event (key events of a competition) which may be significantly higher than the baseline time-shift load. The source station scheduling and control system can adjust resource unit allocation in advance based on this prediction, enabling the time-shift cluster to obtain more available resources before subsequent concentrated arrival of time-shift requests. This approach improves the matching degree between resource coordination control and actual changes in time-shift requests, which is beneficial for improving resource utilization efficiency and reducing the load pressure caused by resource allocation lag.

[0220] In other exemplary applications, the target live streaming event can also be a large-scale event live stream, a game live stream, an e-sports match live stream, a concert live stream, or a press conference live stream. Taking a game live stream or an e-sports match live stream as an example, the event phase states can include at least one of the following: the opening phase, the confrontation phase, the resource acquisition phase, and the settlement phase; the key events of the event can include at least one of the following: the target object is defeated, a key resource is acquired, the phase objective is achieved, or the game state changes. The source server scheduling and control system can generate an event graph based on the above-mentioned event phase states and key events, and determine the predicted time-shifted load sequence based on the event graph to control the lending or reclamation of resource units between the live streaming cluster and the time-shifted cluster.

[0221] Example 3 Figure 6 A block diagram of a live streaming time-shift processing apparatus according to Embodiment 3 of this application is schematically shown. This live streaming time-shift processing apparatus can be applied to a source station scheduling and control system. The apparatus can be divided into one or more program modules, one or more of which are stored in a storage medium and executed by one or more processors to complete the embodiments of this application. The program modules referred to in the embodiments of this application are a series of computer program instruction segments capable of performing specific functions. The following description will specifically introduce the functions of each program module in this embodiment. The apparatus 600 may include an acquisition module 610, a generation module 620, a prediction module 630, a determination module 640, and a control module 650.

[0222] The acquisition module 610 is used to acquire activity phase data and activity event data of the target live event.

[0223] The generation module 620 is used to generate an activity event map based on the activity stage data and the activity event data. The activity event map includes the activity stage status and event anchor points corresponding to key events of the activity.

[0224] The prediction module 630 is used to determine the predicted time-shifted load sequence based on the activity event map.

[0225] The determination module 640 is used to determine resource coordination control information based on the predicted time-shifted load sequence and time-shifted cluster capacity.

[0226] The control module 650 is used to control the resource unit to lend or reclaim resources between the live streaming cluster and the time-shifted cluster based on the resource coordination control information.

[0227] The live streaming time-shift processing device of this embodiment can execute any of the live streaming time-shift processing methods in Embodiment 1. The specific implementation method and technical effect can be referred to Embodiment 1, and will not be repeated here.

[0228] Example 4 Figure 7 A block diagram of a time-shifted content preheating control device according to Embodiment 4 of this application is schematically shown. This time-shifted content preheating control device can be applied to a CDN preheating control system. The device can be divided into one or more program modules, one or more of which are stored in a storage medium and executed by one or more processors to complete the embodiments of this application. The program modules referred to in the embodiments of this application are a series of computer program instruction segments capable of performing specific functions. The following description will specifically introduce the functions of each program module in this embodiment. The device 700 may include a receiving module 710, a first determining module 720, a second determining module 730, a generating module 740, and a control module 750.

[0229] The receiving module 710 is used to receive preheating trigger information, which is generated based on event anchors in the activity event graph, and includes event type and anchor timestamp.

[0230] The first determining module 720 is used to determine the preheating target time interval based on the event type and the anchor timestamp.

[0231] The second determining module 730 is used to determine a list of time-shifted content segments based on the preheating target time interval.

[0232] The generation module 740 is used to generate a preheating task based on the time-shifted content fragment list.

[0233] The control module 750 is used to control the target cache node to cache the corresponding time-shifted content fragment based on the preheating task.

[0234] The live streaming time-shift processing device of this embodiment can execute any of the live streaming time-shift processing methods in Embodiment 2. The specific implementation method and technical effect can be referred to Embodiment 2, and will not be repeated here.

[0235] Example 5 Figure 8 This diagram schematically illustrates the hardware architecture of a computer device according to Embodiment 5 of this application. In some embodiments, the computer device 10000 may be a rack server, blade server, tower server, or cabinet server (including standalone servers or server clusters composed of multiple servers), etc. Figure 8 As shown, the computer device 10000 includes, but is not limited to: a memory 10010, a processor 10020, and a network interface 10030 that can communicate and be linked with each other via a system bus. Wherein: The memory 10010 includes at least one type of computer-readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 10010 may be an internal storage module of a computer device 10000, such as the hard disk or memory of the computer device 10000. In other embodiments, the memory 10010 may also be an external storage device of the computer device 10000, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 10000. Of course, the memory 10010 may also include both the internal storage module and the external storage device of the computer device 10000. In this embodiment, the memory 10010 is typically used to store the operating system and various application software installed on the computer device 10000, such as the program code of the method described in any of the above embodiments. Furthermore, the memory 10010 can also be used to temporarily store various types of data that have been output or will be output.

[0236] In some embodiments, processor 10020 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other chip. Processor 10020 is typically used to control the overall operation of computer device 10000, such as performing control and processing related to data interaction or communication with computer device 10000. In this embodiment, processor 10020 is used to run program code stored in memory 10010 or process data.

[0237] Network interface 10030 may include a wireless network interface or a wired network interface, which is typically used to establish a communication link between computer device 10000 and other computer devices. For example, network interface 10030 is used to connect computer device 10000 to an external terminal via a network, establishing a data transmission channel and communication link between computer device 10000 and the external terminal. The network may be an intranet, the Internet, Global System for Mobile Communication (GSM), Wideband Code Division Multiple Access (WCDMA), 4G network, 5G network, Bluetooth, Wi-Fi, or other wireless or wired networks.

[0238] It should be pointed out that, Figure 8 Only computer devices with components 10010-10030 are shown; however, it should be understood that it is not required to implement all of the shown components, and more or fewer components may be implemented instead.

[0239] In this embodiment, the method described in any of the above embodiments stored in memory 10010 can also be divided into one or more program modules and executed by one or more processors (such as processor 10020) to complete the embodiments of this application.

[0240] Example 6 This application also provides a computer-readable storage medium storing computer instructions, which, when executed by a processor, implement the methods described in any of the above embodiments.

[0241] In this embodiment, the computer-readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the computer-readable storage medium may be an internal storage unit of a computer device, such as the hard disk or memory of the computer device. In other embodiments, the computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Of course, the computer-readable storage medium may include both internal storage units and external storage devices of the computer device. In this embodiment, the computer-readable storage medium is typically used to store the operating system and various application software installed on the computer device, such as the program code of the method described in any of the above embodiments. In addition, the computer-readable storage medium can also be used to temporarily store various types of data that have been output or will be output.

[0242] Example 7 This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in any of the above embodiments.

[0243] Obviously, those skilled in the art should understand that the modules or steps of the embodiments of this application described above can be implemented using general-purpose computer devices. They can be centralized on a single computer device or distributed across a network of multiple computer devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computer device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of this application are not limited to any particular combination of hardware and software.

[0244] It should be noted that the above are merely preferred embodiments of this application and do not limit the scope of patent protection of this application. Any equivalent structural or procedural changes made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of this application.

Claims

1. A time-shift processing method for live streaming, characterized in that, Applied to a source station scheduling and control system, the method includes: Acquire activity phase data and activity event data for the target live streaming event; Based on the activity phase data and the activity event data, an activity event map is generated, which includes the activity phase status and event anchor points corresponding to key activities. Based on the activity event graph, a predicted time-shifted load sequence is determined; Based on the predicted time-shifted load sequence and time-shifted cluster capacity, resource coordination control information is determined; Based on the resource coordination control information, the control resource unit is allowed to lend or reclaim resources between the live streaming cluster and the time-shifted cluster.

2. The method according to claim 1, characterized in that, Based on the activity phase data and the activity event data, an activity event map is generated, including: Obtain the activity type corresponding to the target live streaming activity; Load an activity phase state machine template based on the activity type. The activity phase state machine template includes the phase sequence corresponding to the activity type and the default duration range of each phase. Based on the activity phase data, the current activity phase status of the target live broadcast activity is determined; Based on the activity event data, determine the event type and occurrence timestamp of the key events in the activity; Based on the event type, the occurrence timestamp, and the activity stage status, event anchor points corresponding to the key events of the activity are generated.

3. The method according to claim 2, characterized in that, The method further includes: When an activity phase change signal is received, the activity phase state machine is controlled to transition from the current activity phase state to the next activity phase state. If the duration of the current activity phase state meets the timeout protection condition and no activity phase change signal is obtained, the activity phase state machine is controlled to transition from the current activity phase state to the next activity phase state. Within the transition time window after the state transition, equivalent stage parameters are generated based on the first stage parameters before the state transition and the second stage parameters after the state transition.

4. The method according to claim 1, characterized in that, Based on the activity event graph, the predicted time-shifted load sequence is determined, including: Based on the baseline parameters and activity importance weights corresponding to the current activity phase status, determine the baseline time-shift load; Based on the event anchor points in the activity event graph, determine the active event window; For an event anchor point in the active event window, the event pulse load corresponding to the event anchor point is determined based on the event type, influence parameter, decay parameter, and time difference between the event anchor point and the current time. The predicted time-shifted load sequence is determined based on the baseline time-shifted load and the event pulse load.

5. The method according to claim 4, characterized in that, Based on the baseline time-shift load and the event pulse load, the predicted time-shift load sequence is determined, including: The event pulse loads corresponding to multiple event anchor points in the active event window are superimposed to obtain the total event pulse load; If the total event pulse load exceeds the pulse superposition limit, the total event pulse load is adjusted based on the pulse superposition limit. The predicted time-shifted load sequence is determined based on the baseline time-shifted load and the corrected total event pulse load; The predicted values ​​in the predicted time-shifted load sequence are configured with confidence intervals, and the resource coordination control information is determined based on the upper bound of the confidence intervals.

6. The method according to claim 1, characterized in that, Based on the predicted time-shifted load sequence and time-shifted cluster capacity, resource coordination control information is determined, including: Based on the predicted time-shifted load sequence, the conservative predicted load within the target prediction time window is determined; Based on the conservative predicted load and the time-shifted cluster capacity, determine the amount of resources that can be lent out or the resource reclamation trigger information; Based on the amount of resources available for lending or the resource recycling trigger information, the resource coordination control information is generated.

7. The method according to claim 6, characterized in that, Based on the conservatively predicted load and the time-shifted cluster capacity, the amount of resources available for lending is determined, including: The lendable ratio is determined based on the safety factor and the ratio of the conservatively predicted load to the time-shifted cluster capacity. The amount of resources available for lending is determined based on the lending ratio and the number of resource units in the time-shifted cluster. The resource unit is the smallest unit of resource borrowing, and the resource unit includes a computing node and the network bandwidth resources corresponding to the computing node.

8. The method according to claim 7, characterized in that, Based on the resource coordination control information, the control resource unit borrows resources between the live streaming cluster and the time-shifted cluster, including: Determine the target resource unit corresponding to the amount of available resources from the idle resource pool of the time-shifted cluster; Control the migration of the target resource unit from the time-shift cluster to the live streaming cluster; Register the target resource unit to the service discovery system corresponding to the live streaming cluster; Update the load balancing weights corresponding to the live streaming cluster.

9. The method according to claim 8, characterized in that, Determining the target resource unit corresponding to the amount of available resources from the idle resource pool of the time-shifted cluster includes: Obtain the load status and location attributes of each candidate resource unit in the idle resource pool; Based on the load status and the location attribute, the candidate resource units are sorted. Based on the sorting results, the target resource unit is determined from the candidate resource units.

10. The method according to claim 1, characterized in that, The method further includes: Maintain the resource status for each resource unit, including the ready status, the lending status, the lent status, and the recycling status; During the process of the control resource unit lending or reclaiming resources between the live streaming cluster and the time-shifted cluster, the resource status of the resource unit is updated.

11. The method according to claim 6, characterized in that, Based on the conservatively predicted load and the time-shifted cluster capacity, resource reclamation trigger information is determined, including: When the predicted time-shifted load sequence indicates that the time-shifted load is trending upward, the resource reclamation trigger information is determined; Based on the load rise rate and resource switching time required corresponding to the predicted time-shifted load sequence, a pre-recovery window is determined; Based on the pre-recovery window, resource coordination control information is generated to control the recovery of lent resource units.

12. The method according to claim 11, characterized in that, Based on the resource coordination control information, the control of resource units between the live streaming cluster and the time-shifted cluster includes: Determine the resource units to be reclaimed from the resource units that have been lent to the live streaming cluster; The load balancer of the live streaming cluster is controlled to mark the resource unit to be reclaimed as empty, so that the resource unit to be reclaimed will no longer receive new connections; When the resource unit to be recycled meets the conditions for completion of emptying, the resource unit to be recycled is deregistered from the service discovery system corresponding to the live streaming cluster, and the resource unit to be recycled is registered to the service discovery system corresponding to the time-shifted cluster. Update the load balancing weights corresponding to the time-shifted cluster.

13. The method according to claim 12, characterized in that, After the load balancer controlling the live streaming cluster marks the resource units to be reclaimed as empty, it also includes: Monitor the number of active connections on the resource unit to be reclaimed; When the number of active connections drops to zero, it is determined that the resource unit to be recycled meets the conditions for completion of emptying. If the waiting time meets the maximum waiting time and the number of active connections has not dropped to zero, a flow end signal is sent to the connection on the resource unit to be reclaimed, and the connection on the resource unit to be reclaimed is closed.

14. The method according to any one of claims 1 to 13, characterized in that, The method further includes: During the process of controlling resource units to borrow or reclaim resources between the live streaming cluster and the time-shifted cluster, the time-shifted cluster retains a proportion of resource units not less than a preset safety lower limit that do not participate in the borrowing.

15. The method according to any one of claims 1 to 13, characterized in that, The method further includes: Obtain time-shift request statistics, which are generated based on at least one of the target timestamp of the time-shift playback request, the viewing duration, and the request source information; Based on the time-shift request statistics, hot spots on the live stream timeline are determined; The hotspot segments are associated with the event anchors in the event graph to generate event popularity association data; Based on the event popularity correlation data, update the prediction parameters corresponding to the event type in the event graph.

16. The method according to claim 15, characterized in that, Based on the event popularity correlation data, update the prediction parameters corresponding to the event type in the activity event graph, including: Based on the event popularity correlation data, determine the actual request density peak and predicted pulse peak corresponding to the event type; Based on the actual request density peak and the predicted pulse peak, update the influence parameter corresponding to the event type; Based on the request density decay curve corresponding to the hotspot segment, update the decay parameter corresponding to the event type; The updates of the influence parameter and the decay parameter are constrained by the single adjustment magnitude and the cumulative adjustment range.

17. A method for controlling the preheating of time-shifted content, characterized in that, The method, applied to a CDN preheating control system, includes: Receive preheating trigger information, which is generated based on event anchors in the activity event graph, and includes event type and anchor timestamp; Based on the event type and the anchor timestamp, determine the target preheating time interval; Based on the preheating target time interval, a list of time-shifted content segments is determined; Based on the time-shifted content fragment list, a preheating task is generated; Based on the preheating task, the target cache node is controlled to cache the corresponding time-shifted content fragment.

18. The method according to claim 17, characterized in that, Based on the event type and the anchor timestamp, the preheating target time interval is determined, including: Based on the event type, query the mapping relationship between the event type and the preheating parameters to obtain the pre-offset and post-offset corresponding to the event type; Based on the anchor timestamp and the preceding offset, the start time of the preheating target time interval is determined; Based on the anchor timestamp and the subsequent offset, the end time of the preheating target time interval is determined.

19. The method according to claim 17, characterized in that, Based on the preheating target time interval, a list of time-shifted content segments is determined, including: Query the slice index of time-shifted content; Determine the media slice identifier whose timestamp falls within the preheating target time interval from the slice index; Determine the index file segment corresponding to the media slice identifier; The time-shifted content fragment list is generated based on the media slice identifier and the index file fragment.

20. The method according to claim 17, characterized in that, The preheating trigger information also includes an event importance level; based on the time-shifted content segment list, a preheating task is generated, including: Based on the importance level of the event, the task priority of the preheating task is determined; The preheating task is generated based on the task priority and the time-shifted content fragment list; Insert the preheating task into the priority queue.

21. The method according to claim 20, characterized in that, Based on the preheating task, the target cache node is controlled to cache the corresponding time-shifted content fragment, including: Retrieve preheating tasks to be executed from the priority queue; Based on the event importance level corresponding to the preheating task to be executed, the target cache node is determined; The target cache node is controlled to cache the time-shifted content fragment corresponding to the preheating task to be executed; The target cache node includes at least one of CDN edge nodes, CDN middle layer nodes, or origin server hot cache.

22. The method according to claim 20, characterized in that, Based on the preheating task, the target cache node is controlled to cache the corresponding time-shifted content fragment, including: Allocate a preheating bandwidth quota, independent of the user request service, to the preheating task; Within the preheating bandwidth quota, preheating transmission bandwidth is allocated based on the task priority of each preheating task in the priority queue; If the usage status of the preheating bandwidth quota meets the quota limit conditions, low-priority preheating tasks will be slowed down or suspended.

23. The method according to any one of claims 17 to 22, characterized in that, The method further includes: Obtain the task execution status of the preheating task, the task execution status including the push success status and / or push delay status corresponding to the target cache node; Based on the task execution status, update the preheating completion status of the preheating task.

24. The method according to any one of claims 17 to 22, characterized in that, The method further includes: Get time-shift request statistics; Based on the time-shift request statistics, hot spots on the live stream timeline are determined; The hotspot segments are associated with the event anchor points to generate event preheating feedback data; Based on the event preheating feedback data, update the mapping relationship between event type and preheating parameters.

25. The method according to claim 24, characterized in that, Based on the event preheating feedback data, update the mapping relationship between event type and preheating parameters, including: Based on the difference between the playback start time corresponding to the hot spot segment and the anchor point timestamp, the preceding offset statistical value is determined; Based on the difference between the playback end time corresponding to the hot spot segment and the anchor point timestamp, the post-offset statistical value is determined; If the preceding offset statistic or the following offset statistic meets the adjustment trigger condition, update the preceding offset or following offset corresponding to the event type.

26. A time-shift processing device for live streaming, characterized in that, The device, applied to a source station scheduling and control system, includes: The acquisition module is used to acquire activity phase data and activity event data of the target live event; The generation module is used to generate an activity event map based on the activity stage data and the activity event data. The activity event map includes the activity stage status and event anchor points corresponding to key events of the activity. The prediction module is used to determine the predicted time-shifted load sequence based on the activity event map; The determination module is used to determine resource coordination control information based on the predicted time-shifted load sequence and the time-shifted cluster capacity; The control module is used to control the resource units to lend or reclaim resources between the live streaming cluster and the time-shifted cluster based on the resource coordination control information.

27. A time-shifted content preheating control device, characterized in that, The device, applied to a CDN preheating control system, includes: The receiving module is used to receive preheating trigger information, which is generated based on event anchors in the activity event graph and includes event type and anchor timestamp. The first determining module is used to determine the preheating target time interval based on the event type and the anchor timestamp; The second determining module is used to determine a list of time-shifted content segments based on the preheating target time interval; The generation module is used to generate a preheating task based on the time-shifted content fragment list; The control module is used to control the target cache node to cache the corresponding time-shifted content fragment based on the preheating task.

28. A computer device, characterized in that, include: At least one processor; and A memory communicatively connected to the at least one processor; wherein: The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 25.

29. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 25.

30. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 25.

Images