Information pushing method and device

Abstract

The embodiment of the invention provides an information pushing method and device, computer equipment, a computer readable storage medium and a computer program product, and belongs to the field of data transmission. The information pushing method comprises the following steps: receiving a broadcasting signal of a target anchor, wherein the broadcasting signal carries a target anchor identifier; querying a plurality of corresponding audience data from a database according to the target anchor identifier; determining target audience data from multiple pieces of audience data corresponding to the target anchor; and pushing broadcast starting information of the target anchor to a target application program or an operating system configured at a target audience side according to the target audience data, so that the target application program or the operating system displays the broadcast starting information. According to the embodiment of the invention, the broadcast starting signal only carries the target anchor identifier, so that the problems of data accumulation and blockage in peak hours are effectively avoided, and the pushing throughput and efficiency are improved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of data transmission, and in particular to an information pushing method and device, computer equipment, computer readable storage medium, and computer program product. BACKGROUND

[0002] With the rapid popularization of Internet technology, network live broadcast is being received and loved by more and more people. Network live broadcast generally involves a live broadcast platform, a host terminal and a viewer terminal. The host terminal can provide multimedia content (such as video content) to the viewer terminal via the live broadcast platform, and can also receive multimedia content (such as comment content) provided by the viewer terminal via the live broadcast platform, thereby realizing the effect of live broadcast and interaction. With the rapid increase in the number of network live broadcast users, real-time interaction functions such as live broadcast pushing have become an important means to improve user experience and platform activity.

[0003] However, the existing live broadcast pushing method has the problem of information accumulation and congestion during peak periods, and the throughput and efficiency of pushing are both low.

[0004] It should be noted that the above content is not necessarily prior art, and is not used to limit the patent protection scope of the present application. SUMMARY

[0005] Embodiments of the present application provide an information pushing method and device, computer equipment, computer readable storage medium, and computer program product to solve or alleviate one or more technical problems raised above.

[0006] One aspect of an embodiment of the present application provides an information pushing method, which comprises: receiving a live broadcast signal of a target host, wherein the live broadcast signal carries a target host identifier; querying a plurality of viewer data corresponding to the target host identifier from a database; determining target viewer data from the plurality of viewer data corresponding to the target host; pushing live broadcast information of the target host to a target application program or an operating system configured for a target viewer terminal according to the target viewer data, so that the target application program or the operating system displays the live broadcast information.

[0007] Optionally, receiving a live broadcast signal of a target host comprises: asynchronously transmitting the target host identifier in the live broadcast signal to a live broadcast pushing signal consumption node through a message queue; The live broadcast pushing signal consumption node is configured to query a plurality of viewer data corresponding to the target host identifier from the database.

[0008] Optionally, the database comprises a cache database and a persistent storage database; wherein the cache database caches part of the multiple audience data corresponding to the anchor, and the persistent storage database stores multiple audience data of all anchors; and the multiple audience data corresponding to the target anchor is queried from the database according to the target anchor identifier, comprising: querying, according to the target anchor identifier, whether the multiple audience data corresponding to the target anchor exists in the cache database; reading the multiple audience data corresponding to the target anchor from the cache database in the case that the multiple audience data corresponding to the target anchor exists; reading the multiple audience data corresponding to the target anchor from the persistent storage database in the case that the multiple audience data corresponding to the target anchor does not exist.

[0009] Optionally, the information pushing method further comprises: acquiring multiple anchor identifiers, and reading multiple groups of audience data corresponding to the multiple anchor identifiers from the persistent storage database; one anchor identifier corresponds to one group of audience data; and one group of audience data comprises multiple audience data; associating the multiple groups of audience data with the respective anchor identifiers and writing the multiple groups of audience data into the cache database.

[0010] Optionally, determining the target audience data from the multiple audience data corresponding to the target anchor comprises: acquiring multiple interaction data between multiple audiences and the target anchor; determining the target audience data from the multiple audience data corresponding to the target anchor according to the multiple interaction data.

[0011] Optionally, pushing the on-air information of the target anchor to a target application program or operating system configured on a target audience terminal according to the target audience data comprises: pushing the target audience data to an application internal pushing consumption node; pushing the on-air information in real time through the application internal pushing consumption node; in the case that no feedback message of the target audience terminal is received for the on-air information, pushing the on-air information asynchronously and in batches.

[0012] Optionally, pushing the on-air information asynchronously and in batches comprises: pushing the target audience data to the system-level pushing consumption node to issue the on-air information through the system-level pushing consumption node; wherein the system-level pushing consumption node is internally provided with a local cache database, and the issuing speed of the on-air information is controlled through a token bucket algorithm.

[0013] Optionally, the information pushing method further comprises: Determine if the current time is within the target time window; If the current time is within the target time window, then the broadcast information will not be pushed to the target audience.

[0014] Optionally, the information push method further includes: If it fails to push the broadcast start information to the target audience, determine whether the current time has exceeded the valid push period; wherein the valid push period is determined based on the time when it first failed to push the broadcast start information to the target audience. If the current time has not exceeded the valid push period, the broadcast information will be partially retried and pushed. If the current time exceeds the valid push period, stop retrying the push.

[0015] Another aspect of this application provides an information push device, the device comprising: A receiving module is used to receive the broadcast start signal of the target broadcaster, wherein the broadcast start signal carries the target broadcaster's identifier; The query module is used to query data of multiple viewers from the database based on the target anchor identifier; The determination module is used to determine the target audience data from multiple audience data corresponding to the target anchor; The push module is used to push the broadcasting information of the target anchor to the target application or operating system configured on the target audience terminal based on the target audience data, so that the target application or the operating system can display the broadcasting information.

[0016] 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.

[0017] 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.

[0018] 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.

[0019] The embodiments of this application employing the above technical solution may include the following advantages: A broadcast start signal carrying only the target broadcaster's identifier is received. Subsequently, multiple corresponding audience data are queried from the database based on the target broadcaster's identifier, and the target audience data is determined from these multiple audience data. Based on the target audience data, the broadcast start information of the target broadcaster is pushed to the target application or operating system configured on the target audience's end, so that the target application or operating system can display the broadcast start information. In this embodiment, the broadcast start signal only transmits the broadcaster's identifier, effectively avoiding the problem of broadcast start information accumulation and congestion during peak periods, thereby improving the throughput and efficiency of the push. Attached Figure Description

[0020] 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.

[0021] Figure 1 This diagram schematically illustrates the operating environment of the information push method according to Embodiment 1 of this application; Figure 2 A flowchart illustrating an information push method according to Embodiment 1 of this application is shown schematically. Figure 3 Schematic illustration Figure 2 Flowchart of the sub-steps in step S202; Figure 4 Schematic illustration Figure 2 Flowchart of the sub-steps in step S204; Figure 5 Schematic illustration Figure 2 Flowchart of the sub-steps in step S206; Figure 6 The flowchart illustrating the addition of the information push method according to Embodiment 1 of this application is shown in the schematic diagram. Figure 7 The flowchart illustrating the addition of the information push method according to Embodiment 1 of this application is shown in the schematic diagram. Figure 8 The flowchart illustrating the addition of the information push method according to Embodiment 1 of this application is shown in the schematic diagram. Figure 9 An architectural diagram according to Embodiment 1 of this application is illustrated schematically; Figure 10 An exemplary application flowchart according to Embodiment 1 of this application is illustrated schematically; Figure 11 A block diagram of an information push device according to Embodiment 2 of this application is schematically shown; and Figure 12A schematic diagram of the hardware architecture of a computer device according to Embodiment 3 of this application is shown. Detailed Implementation

[0022] 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.

[0023] 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.

[0024] It should be noted that, in any stage of this application involving the collection, storage, use, transmission, and processing of data, each stage strictly adheres to the laws, regulations, industry standards, and regulatory requirements of the data source, usage location, 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 are clearly communicated to the data subject in a prominent manner. Collection is conducted only after obtaining the data subject's legal authorization, ensuring that the collection process follows the "minimum necessary" principle and does not exceed the scope of data collection. In the storage stage, storage periods are limited, and data is promptly deleted or anonymized / encrypted after the storage purpose is achieved. In the usage stage, a strict data security protection mechanism is implemented, using field-level desensitization technology and processing the original data according to preset desensitization rules. For different types of data, multiple desensitization strategies, such as data generalization, data anonymization, and data encryption, are employed to effectively mitigate the risk of sensitive information leakage and ensure that all data used is securely processed and desensitized, comprehensively protecting the rights and interests of data subjects and data security. In the transmission and processing stages, the confidentiality and security of data are ensured during transmission and processing.

[0025] 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.

[0026] First, a definition of the terminology used in this application is provided: Start signal: The "start live broadcast" event sent by the broadcaster or live broadcast scheduling system to the platform.

[0027] GRPC (gRPC Remote Procedure Calls) is a framework based on the HTTP / 2 protocol and Protocol Buffers (Protobuf), which can be applied to microservice architectures and cross-language service communication.

[0028] Secondly, to facilitate those skilled in the art to understand the technical solutions provided in the embodiments of this application, the relevant technologies are described below: Known information push methods are generally implemented in the following ways, but all of them have certain defects. Specifically: (1) Full-follower push mode: After the streamer starts broadcasting, messages are pushed to all of his / her followers. The message volume of this method will increase linearly with the number of the streamer's fans. For example, a streamer may generate millions of push messages in one broadcast. This may lead to system traffic limiting or rejection, and may also cause user fatigue, or even cause users to block pushes, which will weaken the subsequent precise operation effect. (2) Centralized aggregation push mode: Various business pushes, including live broadcasts, short videos, and operational activities, are uniformly managed through an aggregation push platform. The aggregation push platform distributes push tasks through distributed scheduling, usually directly splitting the streamer's fan list and stuffing it into sub-tasks. However, this method requires all services to be queued in the same scheduling pool, and the scheduling layer needs to continuously query the multi-dimensional feature vector table, which leads to the crowding of live streaming push quotas during peak marketing activities; the partition where the hot anchor is located may experience performance bottlenecks due to task overload, while the partition where the long tail anchor is located is idle, resulting in low overall resource utilization. (3) Pure client subscription polling mode: By sinking the push logic to the client, polling the server every tens of seconds or maintaining a long connection, querying the status of the followed anchor and then popping up a prompt. This method delegates the status query responsibility to thousands of clients, which leads to the client needing to maintain a long connection or poll periodically. In weak network scenarios, reconnection is frequent, increasing the user's traffic and power consumption. The experience is inconsistent when the polling times out, and the push is lost. Moreover, the server still has to handle high-concurrency polling, which does not truly save resources. (4) Hot fan caching: The hot fan list is cached in the key-value pair storage system, but its push link still directly stuffs the fan list into the message body. Encapsulating the fan list directly into the message body leads to message body bloat, placing a heavy burden on the message queue component, and consuming CPU resources for consumer deserialization, thereby reducing push throughput.

[0029] Therefore, this application provides an information push technology solution. In this technology solution, (1) only the anchor ID (identifier) ​​is transmitted, without carrying the UID (user) list, so that the size of the message body is reduced from KB or MB to less than 1KB. This significantly reduces the refresh time of the Broker (middleware of the message queue system) and the network transmission latency, thereby avoiding message accumulation during peak periods, effectively solving the problems of message flood and Broker blockage, and achieving millisecond-level first packet push and low resource consumption. (2) By keeping the fan list in the cache database for a long time, taking advantage of its read-heavy and write-light characteristics, the database is only queried from the source when the cache expires, so that the peak database query load can be reduced to 20% of the original; the cache hit latency is about 1 millisecond, which can effectively eliminate the database avalanche phenomenon, ensure real-time reading under high concurrency, and thus support millions of query requests per second (QPS). (3) The system-level push consumer adopts the method of built-in local buffer combined with token bucket, and performs rate control on each node to achieve rate limiting, and no longer relies on third-party rate limiting mechanisms. The system only performs queuing processing on the local node, avoiding the cascading blocking problem that may occur in the main link. The jitter during the queuing process is limited to the local node and will not affect the entire system. Therefore, the overall system operation is more stable and can adaptively limit the flow according to the local situation. (4) The invention adopts the GRPC (online) + HTTP batch (offline) method and selects the optimal calling method according to the user's online status. For online users, the push platform is directly requested through GRPC. The push platform pushes based on broadcast, achieving a sub-millisecond push delay and ensuring that the information can reach the user quickly. For offline users, the HTTP batch push method is adopted. The number of queries per second (QPS) is reduced by batch processing, reducing the pressure on the system, improving real-time performance, and increasing the utilization rate of the vendor quota, while taking into account both real-time performance and efficient utilization of system resources. (5) The invention adopts a local retry and dead letter isolation mechanism, retrying within the coroutine and recycling dead letters, so that poisoned messages will not block the entire partition. The recovery time of backlogged messages can be shortened from hours to minutes, thereby ensuring reliable delivery of messages and achieving rapid recovery. Through the aforementioned differentiated design, this technical solution systematically overcomes the shortcomings of the background technology in terms of latency, throughput, stability, and cost, and achieves comprehensive technical effects such as millisecond-level first packet delivery, high-concurrency processing capabilities, and low-cost operation. See below for details.

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

[0031] like Figure 1 As shown, the runtime environment diagram includes: Figure 1 The illustration shows an environmental application diagram according to an embodiment of this application.

[0032] The environmental diagram may include a service platform 2, broadcaster terminals (4A, 4B, ..., 4M), and viewer terminals (6A, 6B, ..., 6N). In a live broadcast scenario, the broadcaster terminals (4A, 4B, ..., 4M) log in to the service platform 2 and push live broadcast data to the viewer terminals (6A, 6B, ..., 6N) in real time through the service platform 2.

[0033] Service platform 2 can provide live streaming services, which can be a single server, a server cluster, or a cloud computing service center.

[0034] The broadcast terminals (4A, 4B, ..., 4M) are used to generate live streaming data in real time and to push the live streaming data. The live streaming data may include audio data or video data. The broadcast terminals can be electronic devices such as smartphones or tablets. Alternatively, the broadcast terminals can be virtual computing instances within service platform 2.

[0035] Viewer terminals (6A, 6B, ..., 6N) can be configured to receive live data from the broadcaster terminal in real time. Viewer terminals (6A, 6B, ..., 6N) can be any type of computing device, such as smartphones, tablets, laptops, smart TVs, in-vehicle terminals, etc. Viewer terminals (6A, 6B, ..., 6N) can have a built-in browser or dedicated program to receive the live data and output content to the user. The content may include video, audio, comments, text data, and / or the like.

[0036] The audience terminals (6A, 6B, ..., 6N) may include a player. The player outputs (e.g., displays, presents) content to the user. This content may include video, audio, comments, text data, and / or the like. The audience terminals (6A, 6B, ..., 6N) may include an interface that may include an input element (touchscreen). For example, the input element may be configured to receive user instructions that cause the audience terminals (6A, 6B, ..., 6N) to perform various operations, such as sending bullet comments, entering comments, sending gifts, etc.

[0037] The broadcast terminals (4A, 4B, ..., 4M), viewer terminals (6A, 6B, ..., 6N), and service platform 2 can be connected via a network. The network may include various network devices, such as routers, switches, multiplexers, hubs, modems, bridges, repeaters, firewalls, and / or proxy devices. The network may include physical links, such as coaxial cable links, twisted-pair cable links, fiber optic links, and combinations thereof and / or the like. The network may include wireless links, such as cellular links, satellite links, Wi-Fi links, and / or the like.

[0038] It should be noted that the number of broadcast terminals and viewer terminals shown in the diagram is merely illustrative and is not intended to limit the scope of patent protection of this application. In practice, any number of broadcast terminals and viewer terminals may be used.

[0039] The technical solution of this application will be described below through multiple embodiments, using service platform 2 as the implementing entity. It should be understood that these embodiments can be implemented in many different forms and should not be construed as being limited to the embodiments described herein.

[0040] Example 1 Figure 2 A flowchart illustrating an information push method according to Embodiment 1 of this application is shown.

[0041] like Figure 2 As shown, the information push method may include steps S200~S206, wherein: Step S200: Receive the broadcast start signal from the target broadcaster, wherein the broadcast start signal carries the target broadcaster's identifier; Step S202: Query the corresponding audience data from the database based on the target anchor identifier; Step S204: Determine the target audience data from the multiple audience data corresponding to the target anchor; Step S206: Push the broadcasting information of the target anchor to the target application or operating system configured on the target audience terminal according to the target audience data, so that the target application or the operating system can display the broadcasting information.

[0042] The broadcast signal in this embodiment only carries the broadcaster identifier (multiple audience data corresponding to the target broadcaster identifier are retrieved from the database) and does not carry the audience list, thereby effectively avoiding the problem of broadcast information accumulation and congestion during peak periods, and thus significantly improving the throughput and efficiency of push, achieving millisecond-level first packet push and reducing resource consumption.

[0043] The following combination Figure 2 The steps in steps S200 to S206, as well as other optional steps, are described in detail.

[0044] Step S200 The system receives the broadcast start signal from the target broadcaster, wherein the broadcast start signal carries the target broadcaster's identifier.

[0045] The start-up signal is a notification signal sent by the target broadcaster when initiating a live stream, informing them that the live stream has begun. The target broadcaster identifier can be a unique identifier used to uniquely identify the target broadcaster, and can take various forms such as broadcaster ID, room number, nickname, etc. The start-up signal can be received through various methods, including message queues, API calls, event listeners, Webhook callbacks, or long connections (WebSocket). An exemplary scheme for receiving the start-up signal is provided below.

[0046] In an optional embodiment, step S200 may include: The target broadcaster identifier in the broadcast start signal is asynchronously transmitted to the live broadcast push signal consumption node via a message queue. The live broadcast push signal consumption node is used to query the corresponding data of multiple viewers from the database.

[0047] For example, a message queue can refer to a message middleware for transmitting message content, used to implement asynchronous communication. The message content can refer to the broadcast start signal of the target broadcaster that needs to be transmitted. In some embodiments, the message queue can be implemented using Kafka, RocketMQ, RabbitMQ, etc. In some embodiments, the message queue can include a message queue name, message priority, and message expiration time. The live broadcast push signal consumption node can refer to a server or service component that processes messages in the message queue, used to query the database for corresponding data of multiple viewers from the message queue. In some embodiments, multiple broadcasters can be partitioned according to their respective broadcaster IDs. Each partition is responsible for processing the broadcast start information of a portion of the broadcasters, thereby achieving linear scalability, high concurrency, supporting a query rate of up to one million queries per second (QPS), while effectively reducing the peak query volume of the database.

[0048] In this embodiment, the broadcast start signal (carrying only the target broadcaster identifier) ​​is written to the message queue in the form of a message. The broadcast start information is asynchronously pulled by the live push signal consumption node, so that the live push signal consumption node can query the corresponding data of multiple viewers from the database. By using a lightweight message body (writing only the target broadcaster identifier to the message queue in the form of a message), this embodiment can not only effectively reduce the cluster size of the message queue system and reduce the input and output operations of message transmission, but also significantly shorten the message queue refresh time and network transmission latency, and reduce network bandwidth consumption; at the same time, it can effectively avoid message accumulation during peak periods and solve the problems of message flooding and congestion.

[0049] Step S202 Based on the target anchor's identifier, query the database for data on multiple corresponding viewers.

[0050] Audience data can refer to various information related to viewers, including viewer ID, nickname, following list, viewing history, and other data. In some embodiments, SQL (Structured Query Language) queries can be used to retrieve the audience data corresponding to a target broadcaster by identifying them, thereby improving query efficiency. Alternatively, other query syntaxes can be used as needed to enhance query flexibility.

[0051] In an optional embodiment, the database may include a cache database and a persistent storage database; wherein, the cache database caches multiple viewer data corresponding to some broadcasters, and the persistent storage database stores multiple viewer data for all broadcasters.

[0052] like Figure 3 As shown, step S202 may include: Step S300: Based on the target anchor identifier, query the cache database to see if there are multiple corresponding viewer data.

[0053] Step S302: If multiple audience data exist, read the corresponding multiple audience data from the cache database.

[0054] Step S304: If there is no corresponding multiple audience data, read the corresponding multiple audience data from the persistent storage database.

[0055] For example, a cache database can be a database that temporarily stores data on multiple viewers corresponding to a particular streamer, facilitating frequent access to viewer data. A persistent storage database is used to store data on multiple viewers corresponding to all streamers long-term, providing a complete data backup in case the cache database fails, thus improving the integrity of viewer data. If data on multiple viewers corresponding to a target streamer exists in the cache database, it is read first from the cache database. If data on multiple viewers corresponding to a target streamer does not exist in the cache database (e.g., the data on multiple viewers corresponding to the target live stream fails in the cache database), it is then read from the persistent storage database. In some embodiments, the read interface provided by the cache database or persistent storage database can be used to directly read the corresponding viewer data based on the target streamer's identifier. If it is necessary to read viewer data for multiple streamers, a batch read interface can be used to read the viewer data for multiple streamers at once, thereby reducing the number of queries.

[0056] In this embodiment, the multiple fan data corresponding to the target streamer is queried first from the cache database, and the multiple audience data corresponding to the target streamer is read from the persistent storage database only if the cache data does not exist (e.g., expired). This reduces the query load on the persistent storage database, effectively eliminates the persistent storage database avalanche phenomenon, and effectively ensures real-time reading under high concurrency, thereby supporting millions of query requests per second.

[0057] Step S204 The target audience data is determined from multiple audience data corresponding to the target anchor.

[0058] Target audience data can be determined from multiple audience data sets based on audience interaction data with the target streamer, audience activity levels, preference settings, and audience follow relationships. The audience data filtering logic can be hot-updated on the cache side and supports rapid deployment of A / B experiments and canary release strategies, thus achieving low cost and easy evolution. An exemplary solution is provided below.

[0059] In optional embodiments, such as Figure 4 As shown, step S204 may include: Step S400: Obtain interaction data between multiple viewers and the target anchor.

[0060] Step S402: Based on the multiple interactive data, determine the target audience data from the multiple audience data corresponding to the target anchor.

[0061] For example, interaction data between multiple viewers and the target streamer can be obtained through various methods such as querying specific databases, real-time monitoring, and log analysis. Interaction data refers to data used to measure viewers' interest and engagement with the target streamer, and may include the number of likes, comments, shares, viewing time, interaction frequency, sending bullet comments, and tipping. Based on such interaction data, target viewer data is determined from multiple viewer data corresponding to the target streamer. In some embodiments, a pre-trained machine learning model can be used to analyze the viewer interaction data to predict which viewers are more likely to be interested in the target streamer's broadcast information, thereby improving the accuracy of the selection.

[0062] In this embodiment, target audience data is selected from multiple audience data corresponding to the target streamer based on the interaction data between multiple viewers and the target streamer. This allows the streamer to push broadcast information only to the target audience, thereby solving the problem of traffic throttling caused by massive push information. At the same time, it reduces the fatigue of viewers due to frequent reception of broadcast information, thereby reducing the possibility of users blocking pushes due to dissatisfaction. This improves the effectiveness of subsequent precise operation and reduces platform costs.

[0063] Step S206Based on the target audience data, the broadcasting information of the target anchor is pushed to the target application or operating system configured on the target audience terminal so that the target application or operating system can display the broadcasting information.

[0064] Based on target audience data, notifications of a target streamer's live stream can be pushed to the target application or operating system configured on the target audience's device. Within the target application, the live stream information can be displayed via pop-ups or overlays. At the operating system level, it can be displayed in the notification bar, lock screen, or desktop. Target audience data refers to data about viewers interested in the target streamer. The target application refers to the application on the target audience's device used to watch the target streamer's live stream. The live stream information can be a notification pushed to the target audience about the target streamer's live stream, which may include the streamer's nickname, live stream time, live stream topic, live stream link, streamer avatar, and other content. The live stream information can be pushed to the target audience's device through various methods such as in-app notifications, system-level notifications, and third-party push services. An example push scheme is provided below.

[0065] In optional embodiments, such as Figure 5 As shown, step S206 may include: Step S500: Push the target audience data to the in-application push consumption node.

[0066] Step S502: Push the broadcast information in real time through the in-application push consumption node.

[0067] Step S504: If no feedback message regarding the broadcast information is received from the target audience, the broadcast information is pushed asynchronously in batches.

[0068] For example, target audience data can be pushed to a message queue to be pushed via a live stream push signal consumption node. An in-app push consumption node reads and consumes the live stream information from the message queue. Then, the live stream information is pushed to the target application on the target audience's end in real time via the in-app push consumption node. For example, sub-millisecond pushes can be achieved using gRPC, enabling the live stream information to be delivered to the target audience quickly and accurately. An in-app push consumption node can refer to a component responsible for handling in-app push tasks. When the target application receives the live stream information, it can send a feedback message to the service platform. If the service platform does not receive a feedback message from the target audience regarding the live stream information, the live stream information is asynchronously pushed in batches via the in-app push consumption node. For example, asynchronous batch pushes of live stream information can be performed using the HTTP protocol, thereby effectively reducing the number of queries per second (QPS) triggers while improving the real-time performance of pushes and quota utilization.

[0069] In this embodiment, the live broadcast information is pushed in real time through the in-application push consumption node. If no feedback message is received from the target audience regarding the live broadcast information, the live broadcast information is pushed asynchronously in batches. This can improve the timeliness and reliability of the live broadcast information delivery, thereby effectively avoiding push failures caused by network latency or the target audience being offline, improving the delivery rate under weak network conditions, and effectively avoiding repeated pushes of live broadcast information to the target audience, thereby improving user experience and system resource utilization.

[0070] In an optional embodiment, step S504 may include: pushing the target audience data to the system-level push consumption node, so as to distribute the broadcast start information through the system-level push consumption node. The system-level push consumption node has a built-in local cache database and uses a token bucket algorithm to control the distribution speed of the broadcast start information.

[0071] For example, the in-app push consumption node sends the broadcast launch information to the system-level push queue in the form of a message. The system-level push consumption node pulls the broadcast launch information from the system-level push queue, then verifies the push time window, and writes the broadcast launch information into the local cache database built into the system-level push consumption node. Then, multiple coroutines of the system-level push processor concurrently read the broadcast launch information from the local cache database, and control the distribution speed of the broadcast launch information through a token bucket algorithm. It should be noted that this embodiment of the application aggregates multiple target audience IDs into the same HTTP request and calls the push platform to execute the HTTP system-level push.

[0072] In this embodiment, the system-level push consumer node combines a local cache database and a token bucket algorithm to distribute broadcast information. This approach ensures that when rate limiting or network jitter occurs, the broadcast information is only queued on the local node without affecting the normal operation of the overall link, thereby effectively guaranteeing the stability and reliability of the push and achieving adaptive peak shaving and rate limiting.

[0073] In optional embodiments, such as Figure 6 As shown, the information push method may further include: Step S600: Obtain multiple broadcaster identifiers, and read corresponding sets of audience data from the persistent storage database based on the multiple broadcaster identifiers. One broadcaster identifier corresponds to one set of audience data. One set of audience data may include multiple sets of audience data.

[0074] Step S602: Associate the multiple sets of audience data with their respective corresponding anchor identifiers and write them into the cache database.

[0075] For example, multiple broadcaster identifiers can be obtained through various methods such as API calls, database queries, and message queues. Multiple sets of audience data can be read from a persistent storage database based on these broadcaster identifiers. Each set of audience data is associated with its corresponding broadcaster identifier and written to a cache database. By residing audience data in the cache database, the end-to-end latency is reduced, thus enabling the function of notification upon broadcast start. End-to-end refers to the process from the moment the target broadcaster starts broadcasting to the moment the target audience receives the broadcast start information. In some embodiments, the effective time period for each set of audience data in the cache database can be set. In some embodiments, the audience data can be stored in various formats to reduce cache usage and support parallel sharding computation.

[0076] In this embodiment, multiple sets of audience data are read from a persistent storage database based on multiple streamer identifiers, and each set of audience data is associated with its corresponding streamer identifier and written to a cache database. This dual-database structure allows for efficient and accurate querying of multiple fan data sets from the cache database based on the streamer identifier.

[0077] In optional embodiments, such as Figure 7 As shown, the information push method may further include: Step S700: Determine whether the current time is within the target time window.

[0078] Step S702: If the current time is within the target time window, then stop pushing the broadcast information to the target audience.

[0079] For example, a target time window can be obtained, and it can be determined whether the current time falls within the target time window. The target time window can refer to a predefined time range used to limit the effective time for pushing broadcast information. If the current time falls within the target time window, the push of broadcast information to the target audience is stopped. For example, to reduce late-night disturbances or the overlap of multiple consecutive pushes, a time window for prohibiting pushes (e.g., 23:00–08:00) or a cooldown time for a single broadcaster (e.g., a maximum of one push within 30 minutes) can be maintained for each viewer. In some embodiments, the target time window (quiet period) can be dynamically adjusted according to specific logic. If the current time falls outside the target time window, the push of broadcast information to the target audience continues.

[0080] In this embodiment, if the current time exceeds the target time window, the push of broadcast start information to the target audience is stopped, thereby reducing the disturbance to the target audience and improving the user experience.

[0081] In optional embodiments, such as Figure 8 As shown, the information push method may further include: Step S800: If it fails to push the broadcast start information to the target audience terminal, determine whether the current time exceeds the valid push time period; wherein the valid push time period is determined based on the time when it first fails to push the broadcast start information to the target audience terminal.

[0082] Step S802: If the current time has not exceeded the valid push time period, perform a partial retry push of the broadcast information.

[0083] Step S804: If the current time exceeds the valid push time period, stop retrying the push.

[0084] For example, if pushing broadcast information to the target audience fails, a partial retry of the broadcast information is performed if the current time has not exceeded the valid push period. If the valid push period has exceeded, the retry is stopped. This method effectively avoids blocking the entire system due to repeated failed broadcast information pushes, thereby improving push stability. After the system fault is recovered, not only is there no need to process a large amount of data, but the data (broadcast information) that could not be processed in time due to system faults or network problems can also be processed in a short time. Furthermore, it can effectively ensure that each broadcast information is delivered at least once, achieving reliable delivery and rapid recovery of broadcast information.

[0085] To make this application easier to understand, the following is combined with... Figure 9 , Figure 10 An example application is provided.

[0086] Step S11: Write the broadcaster's broadcast start signal as a message into the live stream push signal message queue (broadcast start message queue), and then have it sent by the live stream push signal consumer (live stream push signal node, corresponding to...) Figure 9 Consumer 1) asynchronously pulls the live broadcast signal from the live broadcast push signal message queue. The live broadcast signal carries the broadcaster ID.

[0087] In step S12, the live stream push signal consumer queries the streamer's corresponding fan data from the cache database or persistent storage database (fan DB) based on the streamer ID. The persistent storage database stores the fan data for all streamers, while the cache database caches the fan data for some streamers.

[0088] Specifically, based on the streamer ID, the system queries the cache database to see if multiple sets of fan data corresponding to the streamer exist. If they exist, the system reads these multiple sets of fan data from the cache database. If they do not exist, the system reads these multiple sets of fan data from the persistent storage database. The cache database is obtained through the following steps: querying the persistent storage database for multiple sets of fan data corresponding to multiple streamer identifiers, with one streamer identifier corresponding to one set of fan data; associating the multiple sets of fan data with their respective streamer identifiers and writing them into the cache database.

[0089] In step S13, the live stream push signal consumer obtains fan information (fan data) from multiple fans and filters out target fans based on this information. The fan information includes interaction data between multiple fans and the streamer, etc.

[0090] Step S14: The consumer receives the live stream push signal according to the customized push logic, which includes the streamer's live stream information (corresponding to...). Figure 9 The candidate messages in the corresponding Figure 10 The message to be pushed is forwarded to the message queue.

[0091] Step S15, In-app push consumer (in-app push node, corresponding to...) Figure 9 Consumer 2) reads and consumes the broadcast information from the message queue to be pushed, and forwards the broadcast information that needs to be pushed by the system to the system-level push message queue.

[0092] In step S16A, the in-app push consumer identifies the target fan terminal (viewer terminal) that needs to be pushed in-app, and pushes the broadcast information to the target application configured on the target fan terminal that needs to be pushed in-app, so that the broadcast information can be displayed in the target application.

[0093] Specifically, the in-app push consumer queries the cached database to see if the streamer's corresponding fan information exists. If it does, the fan information is retrieved from the cached database. If it doesn't exist, the fan information is retrieved from the persistent storage database, and based on this information, the target fans to be pushed to are identified from the target push fans. Then, the live stream information is pushed to the target application installed on the target fan's device. It should be noted that when the target application on the target fan's device receives the live stream information, the target fan's device will send a feedback message regarding the live stream information to the service platform.

[0094] Step S16B, system-level push consumer (system-level push node, corresponding to Figure 9Consumer 3) identifies the target fans who need system-level push notifications, and simultaneously reads the broadcast information from the system-level push message queue (retrieves cached push messages) and pushes it to the target fan's terminal, so that the broadcast information can be displayed in the operating system of the target fan's terminal. It should be noted that target fan terminals that have already received the broadcast information in the target application will not receive system-level push notifications again.

[0095] Specifically, the system-level push consumer queries the cache database to see if there is fan information corresponding to the streamer. If it exists, it retrieves the fan information from the cache database. If it does not exist, it retrieves the fan information from the persistent storage database and determines the target fans who need to be pushed to the system-level fans based on the fan information. It reads and consumes the broadcast information (system push message) from the system-level push message queue and temporarily stores the broadcast information in the local buffer queue. If the service platform does not receive feedback messages from the target fans who need to be pushed to the system regarding the broadcast information, it reads the broadcast information in the local buffer queue concurrently through multiple push coroutines of the system-level push processor and pushes it to the target fans who need to be pushed to the system (i.e., the fans who have already received the broadcast information in the target application will no longer be pushed to the system). It should be noted that (1) in addition to the local buffer queue, the broadcast information can also be temporarily stored in a lock-free queue. (2) The fan IDs of multiple target fans who need to be pushed to the system are aggregated into the same HTTP request, and the push platform is called to execute the HTTP system-level push to push the broadcast information to the target fans who need to be pushed to the system.

[0096] The above exemplary applications can systematically overcome the deficiencies in latency, throughput, stability, and cost, and achieve the technical effects of millisecond-level packet delivery, high concurrency, and low cost.

[0097] Example 2 Figure 11 The diagram schematically illustrates an information push device according to Embodiment 2 of this application. This device can be divided into one or more program modules. One or more program modules are stored in a storage medium and executed by one or more processors to complete the embodiment of this application. The program module referred to in this embodiment is a series of computer program instruction segments capable of performing a specific function. The following description will specifically introduce the function of each program module in this embodiment. For example... Figure 11 As shown, the device 1000 may include: a receiving module 1100, a query module 1200, a determining module 1300, and a pushing module 1400, wherein: The receiving module 1100 is used to receive the broadcast start signal of the target broadcaster, wherein the broadcast start signal carries the target broadcaster identifier; The query module 1200 is used to query multiple audience data corresponding to the target anchor identifier from the database; The determining module 1300 is used to determine target audience data from multiple audience data corresponding to the target anchor; The push module 1400 is used to push the broadcasting information of the target anchor to the target application or operating system configured on the target audience terminal according to the target audience data, so that the target application or the operating system can display the broadcasting information.

[0098] In an optional embodiment, the receiving module 1100 is further configured to: The target broadcaster identifier in the broadcast signal is asynchronously transmitted to the live push signal consumption node via a message queue. The live stream push signal consumption node is used to query the corresponding data of multiple viewers from the database.

[0099] In an optional embodiment, the database may include a cache database and a persistent storage database; wherein, the cache database caches multiple viewer data corresponding to some broadcasters, and the persistent storage database stores multiple viewer data for all broadcasters; the query module 1200 is further configured to: Based on the target streamer identifier, query the cache database to see if there are multiple corresponding viewer data; If multiple audience data exist, the corresponding multiple audience data are read from the cache database; If there is no corresponding multiple viewer data, the corresponding multiple viewer data is read from the persistent storage database.

[0100] In an optional embodiment, the information push device further includes a writing module, used for: Multiple broadcaster identifiers are obtained, and multiple sets of audience data corresponding to the broadcaster identifiers are read from the persistent storage database; one broadcaster identifier corresponds to one set of audience data; one set of audience data may include multiple sets of audience data. The multiple sets of audience data are associated with their respective anchor identifiers and written into the cache database.

[0101] In an optional embodiment, the determining module 1300 is further configured to: Acquire interaction data between multiple viewers and the target streamer; Based on the multiple interaction data, target audience data is determined from multiple audience data corresponding to the target anchor.

[0102] In an optional embodiment, the push module 1400: Push the target audience data to the in-app push consumption node; The live broadcast information is pushed in real time through the in-application push consumption node; If no feedback message regarding the broadcast start information is received from the target audience, the broadcast start information is pushed asynchronously in batches.

[0103] In an optional embodiment, asynchronously batch pushing the broadcast information includes: The target audience data is pushed to the system-level push consumption node so that the broadcast information can be sent out through the system-level push consumption node; The system-level push consumption node has a built-in local cache database and uses a token bucket algorithm to control the speed at which broadcast information is sent.

[0104] In an optional embodiment, the information push method further includes a first stop module, used for: Determine if the current time is within the target time window; If the current time is within the target time window, then the broadcast information will not be pushed to the target audience.

[0105] In an optional embodiment, the information push method further includes a second stop module, used for: If it fails to push the broadcast start information to the target audience, determine whether the current time has exceeded the valid push period; wherein the valid push period is determined based on the time when it first failed to push the broadcast start information to the target audience. If the current time has not exceeded the valid push period, the broadcast information will be partially retried and pushed. If the current time exceeds the valid push period, stop retrying the push.

[0106] Example 3 Figure 12 This diagram schematically illustrates the hardware architecture of a computer device 10000 suitable for implementing an information push method according to Embodiment 3 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 12 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 for information push methods. In addition, the memory 10010 can also be used to temporarily store various types of data that have been output or will be output.

[0107] 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.

[0108] 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.

[0109] It should be pointed out that, Figure 12 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.

[0110] In this embodiment, the information push method 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 embodiment of this application.

[0111] Example 4 This application also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the information push method in the embodiment.

[0112] 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 can 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 can 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., equipped on the computer device. Of course, the computer-readable storage medium can also include both the internal storage unit and the external storage device 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 information push method in the embodiment. 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.

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

[0114] 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.

[0115] 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. An information push method, characterized in that, For use with a server, the method includes: Receive the broadcast start signal from the target broadcaster, wherein the broadcast start signal carries the target broadcaster's identifier; Based on the target broadcaster's identifier, query the database for data on multiple corresponding viewers; Target audience data is determined from multiple audience data corresponding to the target streamer; Based on the target audience data, the broadcasting information of the target anchor is pushed to the target application or operating system configured on the target audience terminal, so that the target application or the operating system can display the broadcasting information.

2. The method according to claim 1, characterized in that, Receive the target streamer's live broadcast signal, including: The target broadcaster identifier in the broadcast signal is asynchronously transmitted to the live push signal consumption node via a message queue. The live stream push signal consumption node is used to query the corresponding data of multiple viewers from the database.

3. The method according to claim 1, characterized in that, The database includes a cache database and a persistent storage database; wherein, the cache database caches multiple viewer data corresponding to some broadcasters, and the persistent storage database stores multiple viewer data for all broadcasters; retrieving multiple viewer data corresponding to the target broadcaster from the database based on the target broadcaster identifier includes: Based on the target streamer identifier, query the cache database to see if there are multiple corresponding viewer data; If multiple audience data exist, the corresponding multiple audience data are read from the cache database; If there is no corresponding multiple viewer data, the corresponding multiple viewer data is read from the persistent storage database.

4. The method according to claim 3, characterized in that, The method further includes: Multiple broadcaster identifiers are obtained, and corresponding sets of audience data are read from the persistent storage database based on the multiple broadcaster identifiers; one broadcaster identifier corresponds to one set of audience data; one set of audience data includes multiple sets of audience data. The multiple sets of audience data are associated with their respective anchor identifiers and written into the cache database.

5. The method according to claim 1, characterized in that, Determining target audience data from multiple audience data corresponding to the target streamer includes: Acquire interaction data between multiple viewers and the target streamer; Based on the multiple interaction data, target audience data is determined from multiple audience data corresponding to the target anchor.

6. The method according to any one of claims 1 to 5, characterized in that, Based on the target audience data, the broadcasting information of the target anchor is pushed to the target application or operating system configured on the target audience's end, including: Push the target audience data to the in-app push consumption node; The live broadcast information is pushed in real time through the in-application push consumption node; If no feedback message regarding the broadcast start information is received from the target audience, the broadcast start information is pushed asynchronously in batches.

7. The method according to claim 6, characterized in that, Asynchronous batch push of the broadcast information includes: The target audience data is pushed to the system-level push consumption node so that the broadcast information can be sent out through the system-level push consumption node; The system-level push consumption node has a built-in local cache database and uses a token bucket algorithm to control the speed at which broadcast information is sent.

8. The method according to claim 7, characterized in that, The method further includes: Determine if the current time is within the target time window; If the current time is within the target time window, then the push of the broadcast information to the target audience will be stopped.

9. The method according to any one of claims 1-5, characterized in that, The method further includes: If it fails to push the broadcast start information to the target audience, determine whether the current time has exceeded the valid push period; wherein the valid push period is determined based on the time when it first failed to push the broadcast start information to the target audience. If the current time has not exceeded the valid push period, the broadcast information will be partially retried and pushed. If the current time exceeds the valid push period, stop retrying the push.

10. An information push device, characterized in that, The device includes: A receiving module is used to receive the broadcast start signal of the target broadcaster, wherein the broadcast start signal carries the target broadcaster's identifier; The query module is used to query data of multiple viewers from the database based on the target anchor identifier; The determination module is used to determine the target audience data from multiple audience data corresponding to the target anchor; The push module is used to push the broadcasting information of the target anchor to the target application or operating system configured on the target audience terminal based on the target audience data, so that the target application or the operating system can display the broadcasting information.

11. 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 9.

12. 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 9.

13. 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 described in claims 1 to 9.

Images