Bullet screen live broadcast interaction method, server, program product and storage medium

Abstract

The invention provides a bullet screen live broadcast interaction method, a server, a program product and a storage medium, and relates to the technical field of real-time communication and online live broadcast. High-concurrency bottlenecks which are prone to occurring under an original centralized service architecture are processed in a decentralized mode, a single server and a synchronous service cluster are not relied on any more, the system is only responsible for data synchronization and state synchronization between a client side and a server side, long connection communication between the client side and the server side is maintained, and specific service logic is not executed; and the business service cluster is responsible for processing all back-end business logics and decoupling connection maintenance and business processing, so that the problem of long connection interruption of all users caused by business service restarting or faults is avoided. The service stability and high availability of the system in a multi-user live broadcast scene are improved, the user does not perceive abnormal conditions in the live broadcast process, and the user experience is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of real-time communication and online live broadcast, and particularly relates to a method for live broadcast interaction with bullet screen, a server, a program product and a storage medium. BACKGROUND

[0002] In today's Internet applications, the technology in the field of real-time communication and online live broadcast is developing rapidly, especially in the aspect of bullet screen interaction. Users can send bullet screen information while watching live broadcast, realizing real-time interaction with the host and other viewers.

[0003] Currently, live broadcast platforms generally use centralized service architecture to process bullet screen data. A single or a few servers are used to collect, store and distribute bullet screen information. In this architecture, all client bullet screen requests are sent directly to the central server, which is responsible for parsing requests, verifying content, and storing legal bullet screen information in a relational database. At the same time, the central server communicates with the client through long connection or polling, and pushes new bullet screen information to the relevant viewers. In order to improve response speed, some systems deploy load balancers in front of the central server to evenly distribute requests to multiple server nodes, but the core data processing and storage still depend on the central server cluster.

[0004] The existing centralized service architecture is prone to system bottlenecks when facing high-concurrency user requests, resulting in increased service delay and decreased user experience. The central server needs to handle a large number of read and write requests at the same time, and the I / O operation of the database becomes a performance bottleneck. Especially in popular live broadcast rooms, the frequency of bullet screen sending may reach thousands per second, and the central server is difficult to process such high-frequency requests in real time. SUMMARY

[0005] The present application provides a method for live broadcast interaction with bullet screen, a server, a program product and a storage medium, which are used to improve the ability to cope with a large number of read and write requests.

[0006] In a first aspect, the application provides a method for live interaction with a barrage, comprising: after a node in a synchronization service cluster receives a synchronization instruction from a client, writing node condition data containing a current component ID, state, timestamp, and room ID into a distributed coordination service for state recording; through a publish / subscribe mechanism of the distributed cache service, the synchronization service node publishes a notification message to a preset notification node; all nodes in a business service cluster listen to the notification node of the distributed cache service receiving the notification message; after receiving the notification message, the nodes in the business service cluster access the distributed coordination service to obtain the current state of all synchronized components, and compare with a preset number of push nodes; when the number matches, the business service cluster uses the distributed lock feature provided by the distributed coordination service to preempt a preset business lock, and the business service node that successfully acquires the lock becomes the main business node, and the remaining business service nodes enter a waiting state; the main business node consumes business data from the distributed cache service according to business logic, and interacts with the database to complete persistent storage or reading; the business data is derived from a barrage production and consumption process, wherein the barrage data in the business data is distributed to different topics of a notification message queue according to the room, and then stored in the distributed cache service after being processed by a barrage consumer; after the main business node completes processing, the result state is updated, and the processing result is pushed to all related clients through the synchronization service cluster.

[0007] By adopting the above technical solution, the high concurrency bottleneck that is prone to occur under the centralized service architecture is dispersedly processed, and a single server is no longer relied on. A synchronization service cluster is responsible for data synchronization and state synchronization between the client and the server, maintains long connection communication between the client and the server, but does not execute specific business logic. A business service cluster is responsible for processing all backend business logic, decouples connection maintenance and business processing, and avoids the problem of long connection interruption of all users caused by business service restart or failure. After the node in the synchronization service cluster receives the client synchronization instruction, node condition data containing multiple key information is written to the distributed coordination service. The synchronization service node publishes a notification message by means of the publish / subscribe mechanism of the distributed cache service, and all nodes of the business service cluster listen to and receive it, thereby establishing a message transmission link. The business service cluster node accesses the distributed coordination service to obtain the synchronized component state and compares it with the number of push node quantity. This comparison step uses the centralized control advantage of the distributed coordination service to filter out the appropriate opportunity. Then, the distributed lock feature is used to preempt the business lock to select the main business node, avoid confusion caused by simultaneous operation of multiple nodes, and ensure the orderliness of business processing. The main business node consumes business data from the distributed cache service, which acts as an efficient data staging and sharing space. The main business node then interacts with the database to complete storage or reading, realizes the persistent management and real-time calling of data. Finally, the main business node updates the result state and pushes it to the client through the synchronization service cluster, disperses the high concurrency bottleneck that is prone to occur under the centralized service architecture, no longer relies on a single server, solves the performance problem caused by a large number of read and write requests, thereby improves the system service stability and high availability in the multi-person live streaming scenario, and makes the user unaware of abnormal conditions during live streaming, thereby improving the user experience.

[0008] In some embodiments of the first aspect, the production and consumption process of the barrage specifically includes: each barrage producer node establishes a long connection with the barrage service of one or more third-party live broadcast platforms through a protocol, and receives barrage data containing user ID, room ID and barrage content in real time; after receiving the barrage data, the barrage producer node writes the barrage data as a message body into a specific topic corresponding to the room ID in a message queue service according to the room ID to which it belongs; a plurality of barrage consumer nodes are deployed, and each consumer node subscribes and consumes barrage data of one or more specific topics in the message queue service; the consumer node listens to the business data collection notification by using the publish / subscribe feature of the distributed cache service to determine the current business logic that needs to be processed; the consumer node processes the consumed barrage data according to the business state; in the case that the barrage content matches the current business logic, it is stored in the distributed cache service for the main business node; in the case that the barrage content does not match the current business logic, the barrage data is written into a local log file.

[0009] By adopting the above technical solution, the producer node writes the barrage belonging to the room ID as a message body into the corresponding specific topic in the message queue service, and uses the message queue to store the barrage data according to the topic, so as to realize the isolation and preliminary arrangement of barrage data in different live broadcast rooms, and make the subsequent processing more targeted. A plurality of barrage consumer nodes are deployed to subscribe and consume barrage data of these specific topics, and the processing logic is determined by listening to the business data collection notification through the publish / subscribe feature of the distributed cache service, so that the consumer node can flexibly process the barrage data according to different business states. The barrage matching the business logic is stored in the distributed cache service, which facilitates the main business node to quickly obtain hot data for real-time processing, the special barrage is stored in the database to meet the long-term storage requirement, and the unmatched barrage is written into a local log file to avoid invalid data interference. The buffering capacity of the message queue effectively undertakes the barrage flood peak, prevents the backend service from being directly impacted by high concurrency, sets the topic according to the room ID to achieve parallel processing of barrage in different live broadcast rooms, and the consumer architecture of multiple nodes and reasonable data hierarchical storage together improve the horizontal expansion capability and processing efficiency of the system, so that the main business node can always obtain key data with low delay, and ensure that the entire barrage live interaction is efficient and orderly.

[0010] In some embodiments of the first aspect, after receiving the notification message, the node in the business service cluster obtains the current state of all synchronized components by accessing the distributed coordination service, and compares the number of preset push nodes, specifically comprising: after the business service node in the business service cluster listens to the notification of the distributed cache service, it obtains all key-value pairs with the preset prefix in batches through the command of the distributed coordination service; by analyzing the key-value pairs, the business service node counts the total number of component instances that have completed synchronization preparation; the business service node compares the total number with the total number of push nodes required in the current business scenario; when the total number matches the total number of preset push nodes, the current business service node is allowed to participate in the election process of the master business node; if the numbers do not match, the business service node continues to wait.

[0011] By using the above technical solution, after the business service node in the business service cluster listens to the notification of the distributed cache service, it obtains all key-value pairs with the preset prefix in batches through the command of the distributed coordination service. The distributed coordination service plays a role in unified management and data integration, and can orderly gather dispersed component state information in the form of key-value pairs. The business service node analyzes the obtained key-value pairs, counts the total number of component instances that have completed synchronization preparation, and then compares the total number with the total number of push nodes required in the current business scenario. Only when the numbers match, the current business service node is allowed to participate in the election process of the master business node, ensuring that the nodes participating in the election are in the state of overall system state synchronization preparation, and eliminating the problems of delay and data error caused by the reckless development of business due to the unpreparedness of part of the components.

[0012] In some embodiments of the first aspect, after the numbers match, the business service cluster uses the distributed lock feature provided by the distributed coordination service to preempt the preset business lock, and the business service node that successfully obtains the lock becomes the master business node, and the remaining business service nodes enter a waiting state. After the step, the method further comprises: when the master business node loses connection with the distributed coordination service, the lock held by the master business node will be automatically released by the distributed coordination service after the lease expires; all other business service nodes in the waiting state can immediately perceive the event of the lock being released because they continuously listen to the state of the lock; when one or more business service nodes in the waiting state detect that the lock is released, they reattempt to obtain the distributed lock, thereby triggering a new round of election; the node that successfully obtains the lock becomes the new master business node; before starting to process the business, the new master business node will first check the completion status flag of the business; if the flag is not completed, the new master node re-executes the business logic from the last breakpoint or from the beginning; if the flag is completed, the new node directly returns and does not repeat the execution.

[0013] By adopting the technical scheme, when the master service node is disassociated with the distributed coordination service, the lock held by the master service node is automatically released by the distributed coordination service after the lease expires. All other service nodes in a waiting state can immediately perceive the event of the lock being released because they continuously monitor the state of the lock. When one or more service nodes in the waiting state detect that the lock is released, the service nodes reattempt to acquire the distributed lock, thereby triggering a new round of election. A decentralized and automated fault detection and recovery process is constructed by relying on the characteristics of the distributed coordination service, thereby effectively simplifying the system architecture. The node that successfully acquires the lock becomes a new master service node. Before starting to process the service, the new master service node first checks a completion state flag of the service. If the flag is not completed, the service logic is reexecuted from a last breakpoint or from the beginning. If the flag is completed, the service is directly returned and is not repeatedly executed. Through such a mechanism, when the master node fails, the automatic release of the lock and the quick lock acquisition election can ensure that a new master node is generated in a very short time, thereby greatly shortening the service interruption time, guaranteeing the service continuity and data consistency after the failover, and enabling the entire bullet screen live interactive system to still stably operate when facing node failure and other abnormal conditions, without affecting the normal use experience of users.

[0014] In combination with some embodiments of the first aspect, in some embodiments, after the master service node consumes the service data from the distributed cache service according to the service logic and performs the steps of data interaction with the database to complete the persistent storage or reading, the method further includes: embedding a timer in the master service node, actively sending a request to the distributed cache service at a preset cycle period, and acquiring an effective bullet screen data set stored in the distributed cache service, the data set being processed by the consumer node and being related to the current service logic; after the master service node acquires the bullet screen data set, caching the data set to one or more bullet screen push service nodes; the bullet screen push service nodes are responsible for efficiently distributing the bullet screen data to all clients connected to the synchronization service; wherein the leader node of the bullet screen push is generated through the election mechanism of the distributed coordination service, and the other push nodes serve as backups.

[0015] By adopting the technical scheme, the main service node is embedded with a timer, and the main service node actively sends a request to the distributed cache service at a preset cycle period. The timer enables the main service node to actively acquire data, and the main service node acquires the required barrage data set at a predetermined rhythm, thereby ensuring the timeliness and regularity of data acquisition and avoiding delay caused by passive waiting. After the main service node acquires the barrage data set, the data set is cached to one or more barrage push service nodes. In this way, a data buffer zone is built between the main service node and the client, thereby reducing the direct distribution pressure of the main service node and facilitating subsequent unified management and push. The barrage push service node is responsible for efficiently distributing the barrage data to all clients connected to the synchronization service. The leader node of the barrage push is generated through an election mechanism of the distributed coordination service, and the other push nodes serve as backups. The election mechanism ensures the authority and representativeness of the leader node, so that the leader node can reasonably coordinate the backup nodes to jointly complete the efficient data distribution task. In this way, an end-to-end, robust and efficient barrage push link is built, and the user can timely and smoothly receive the barrage information.

[0016] With reference to the first aspect, in some embodiments, after the step of updating the result state after the main service node completes processing and pushing the processing result to all related clients through the synchronization service cluster, the method further comprises: storing service data strongly related to the real-time service in the distributed cache service, the service data including barrage statistical results, valid service barrages to be pushed, and service intermediate state data requiring fast reading and writing; simultaneously, starting the snapshot storage mechanism; storing saved data requiring permanent saving, low-frequency access but high consistency in the database; the saved data including user basic information, special barrage data required for subsequent playback, and complete service flow records.

[0017] By adopting the technical scheme, the hierarchical heterogeneous storage architecture of Redis+MySQL gives full play to the advantages of different storage media, realizes the separation of hot and cold data, and quickly circulates hot data in the cache and safely stores cold data in the database, thereby achieving the best balance between cost and performance. The architecture not only effectively supports the real-time interaction of the front-end service, so that the user experiences smooth and instant service, but also provides a solid and reliable data foundation for the long-term operation and data analysis of the back-end, thereby ensuring that the entire barrage live interactive system can stably and efficiently operate at different business demand levels.

[0018] In some embodiments of the first aspect, in some embodiments, the master business node consumes business data from the distributed cache service according to business logic, and interacts with the database for data to complete persistent storage or reading; the business data is derived from the barrage production and consumption process, wherein the barrage data in the business data is distributed to different topics of the notification message queue according to the room, and then stored in the distributed cache service after being processed by the barrage consumer; specifically, after the master business node calculates the next state change instruction according to the business logic; the master business node sends the state change instruction to the synchronization service cluster; after receiving the state change instruction, the synchronization service cluster broadcasts in a full connection communication mode; wherein each synchronization service node that receives the instruction will synchronize the instruction to all server-side interactive video instances connected thereto without distinction, and all server-side interactive video instances connected thereto belong to different live rooms or different anchor camps.

[0019] By adopting the above technical solution, through such a broadcast mechanism, it is realized that in a complex multi-live room and multi-anchor camp environment, all instances participating in interaction can simultaneously receive a unified state change instruction, ensuring the consistency of the state of each part of the system. Although full connection broadcasting increases network traffic to some extent, this "centralized decision and full connection broadcast" synchronization strategy fundamentally solves the problem of multi-party state synchronization, so that all different live viewers see the same state, and for multi-person live, real-time synchronization experience can be provided, greatly improving the playability and fairness of multi-person live, and ensuring that live interaction can be orderly and coordinated between different camps and different live rooms, avoiding confusion and disputes caused by inconsistent states.

[0020] In the second aspect, the present application provides a service end of barrage live interaction, which comprises one or more processors and a memory; the memory is coupled with the one or more processors, and the memory is used to store computer program code, the computer program code comprises computer instructions, and the one or more processors invoke the computer instructions to enable the service end of barrage live interaction to perform the method described in the first aspect and any possible implementation manner of the first aspect.

[0021] In the third aspect, the present application provides a computer program product comprising instructions, which, when the computer program product is run on a service end of barrage live interaction, enable the service end of barrage live interaction to perform the method described in the first aspect and any possible implementation manner of the first aspect.

[0022] In a fourth aspect, the present application provides a computer readable storage medium, including instructions, when the instructions run on a server side of a live broadcast interaction, the server side of the live broadcast interaction executes the method as described in the first aspect and any possible implementation manner of the first aspect.

[0023] The one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: 1. The high concurrency bottleneck that is prone to occur in the centralized service architecture is dispersedly processed, and a single server is no longer relied on. A synchronization service cluster is synchronized, which is only responsible for data synchronization and state synchronization between the client and the server, maintains long connection communication between the client and the server, but does not execute specific business logic. A business service cluster is responsible for processing all back-end business logic, decouples connection maintenance and business processing, and avoids the problem of long connection interruption of all users caused by business service restart or failure. When a node in the synchronization service cluster receives a client synchronization instruction, node condition data containing multiple key information is written into a distributed coordination service. The synchronization service node publishes a notification message by means of the publish / subscribe mechanism of the distributed cache service, and all nodes of the business service cluster listen to and receive, thereby establishing a message transmission link. The business service cluster node accesses the distributed coordination service to obtain the synchronized component state and compares it with the number of push nodes. This comparison step uses the centralized control advantage of the distributed coordination service to filter out the appropriate opportunity. Then, the distributed lock feature is used to preempt the business lock to select the main business node, avoid confusion caused by simultaneous operation of multiple nodes, and ensure the orderliness of business processing. The main business node consumes business data from the distributed cache service, which acts as an efficient data staging and sharing space. The main business node then interacts with the database to complete storage or reading, realizes persistent management and real-time calling of data. Finally, the main business node updates the result state and pushes it to the client through the synchronization service cluster. The high concurrency bottleneck that is prone to occur in the centralized service architecture is dispersedly processed, and a single server is no longer relied on. The performance problem caused by a large number of read and write requests is solved, thereby improving the system service stability and high availability in the multi-person live broadcast scene, and making the user unaware of abnormal conditions during the live broadcast process, thereby improving the user experience.

[0024] 2. Producer nodes, based on the room ID to which the bullet comments belong, write them as message bodies into the corresponding specific topic in the message queue service. Leveraging the message queue's topic-based storage feature, isolation and initial organization of bullet comment data from different live stream rooms are achieved, making subsequent processing more targeted. Multiple bullet comment consumer nodes are deployed to subscribe to and consume bullet comment data for these specific topics. The publish / subscribe feature of the distributed caching service listens for business data collection notifications to determine processing logic, allowing consumer nodes to flexibly process bullet comment data based on different business states. Bullet comments matching business logic are stored in the distributed caching service, facilitating the main business node's rapid access to hot data for real-time processing. Special bullet comments are stored in the database to ensure long-term preservation, while mismatched bullet comments are written to local log files to avoid invalid data interference. The message queue's buffering capacity effectively handles bullet comment surges, preventing backend services from being directly impacted by high concurrency. Setting topics by room ID enables parallel processing of bullet comments from different live stream rooms. The multi-node consumer architecture, coupled with reasonable data tiered storage, improves the system's horizontal scalability and processing efficiency, ensuring that the main business node can always obtain key data with low latency, guaranteeing the efficient and orderly operation of the entire bullet comment live stream interaction.

[0025] 3. This broadcast mechanism ensures that, even in complex environments with multiple live streaming rooms and multiple broadcaster factions, all participating instances can simultaneously receive unified state change commands, guaranteeing the consistency of the state across all parts of the system. Although full-connection broadcasting increases network traffic, this "centralized decision-making, full-connection broadcasting" synchronization strategy fundamentally solves the problem of multi-party state synchronization, allowing viewers of all different live streams to see the same state. For multi-person live streams, it provides a real-time synchronized experience, greatly enhancing the playability and fairness of multi-person collaborative live streams. It ensures that live stream interactions can be conducted in an orderly and coordinated manner across different factions and live streaming rooms, avoiding chaos and disputes caused by inconsistent states. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the server architecture for interactive live streaming with bullet comments in this application embodiment. Figure 2 This is a flowchart illustrating a method for interactive live streaming with bullet comments in an embodiment of this application; Figure 3 This is a schematic diagram of the business module calling process in the method of interactive live streaming with bullet comments in the embodiments of this application; Figure 4 This is a schematic diagram of the bullet screen service acquisition process in the bullet screen live streaming interaction method in the embodiments of this application; Figure 5 This is a schematic diagram of the bullet screen service push process in the bullet screen live streaming interaction method in the embodiments of this application; Figure 6is a timing diagram of data synchronization in the method of the bullet screen live interaction in the embodiments of the present application. Figure 7 is an exemplary hardware structure diagram of a server in the bullet screen live interaction in the embodiments of the present application. DETAILED DESCRIPTION

[0027] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments and are not intended to be limiting of the present application. As used in the specification and the appended claims of the present application, the singular forms "a," "an" and "the" are intended to include plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0028] Hereinafter, the terms "first" and "second" are only for the purpose of description and cannot be understood as implying or suggesting relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined with "first" and "second" can explicitly or implicitly include one or more of the features, and in the description of the embodiments of the present application, the meaning of "a plurality of" is two or more, unless otherwise specified.

[0029] Please refer to Figure 1 Before a method of bullet screen live interaction of the present application is described, the architecture of bullet screen live interaction is first described. As Figure 1 shown, Figure 1 is a bullet screen live interaction system architecture diagram provided by the present solution, which includes top-level modules (screen recording service, stream pushing service), wherein the screen recording service includes a live filter (LiveManager) and a manager (Manager) component, which is responsible for live stream management; the stream pushing service connects "Bilibili live" and "Bilibili bullet screen", and can interact with external platforms. In addition, the system architecture also includes a core service layer, specifically: a synchronization service cluster (pushserver, mysql (database), redis (distributed cache service), etcd (distributed coordination service), mq (message queue, MessageQueue) and manager (manager), a business service cluster (business, responsible for business processing service), and a "bullet screen producer" and a "bullet screen consumer".

[0030] The functions of each core service are as follows: Synchronization service cluster (pushserver): only responsible for synchronization, including business data synchronization and playback state synchronization, does not do business processing, prevents long connection disconnection caused by business service restart, and improves stability.

[0031] Business: As a business server, it implements all the backend business processes in a multi-person live broadcast.

[0032] Redis: As a cache service, it is mainly responsible for statistics, storage of bullet screens, storage of business data, and message publishing and subscribing.

[0033] Database (mysql): Used for storing replay bullet screens and storing basic data of regular businesses.

[0034] Distributed coordination service (etcd): Responsible for master selection of the synchronization service cluster (pushserver), business scheduling, distributed lock management of the synchronization service cluster (pushserver) and the business service cluster (business), and obtaining and processing nodes.

[0035] Notification message queue (rocketmq): Responsible for storing bullet screens, and each room corresponds to a topic, and the content is distributed to the corresponding ConsumerQueue for consumer consumption.

[0036] Bullet screen producer: Deployed in multiple nodes, each node corresponds to a specific room, and establishes a websocket connection with the Bilibili bullet screen service to receive user information and all bullet screen information, wherein the user information is stored in the database (Mysql), and the bullet screen information is written to different topics according to the room.

[0037] Bullet screen consumer: Deployed in multiple nodes, each node consumes data of different rooms.

[0038] The functions of each core will be described in detail in subsequent embodiments, and will not be repeated here.

[0039] Please refer to Figure 2 and Figure 3 , Figure 2 is a flowchart of a method of bullet screen live interaction in the embodiments of the present application; Figure 3 is a schematic diagram of a business module calling process in the method of bullet screen live interaction in the embodiments of the present application; A method of bullet screen live interaction, comprising: S101, after the node in the synchronization service cluster (pushserver) receives a synchronization instruction from the client (SDK), the node writes node condition data containing the current component ID, state, timestamp and room ID into the distributed coordination service (etcd) for state recording; The synchronization service cluster (pushserver) refers to a set of multiple synchronization service nodes, used for processing synchronization requests of clients (SDK) and maintaining synchronization of system states; the node refers to a single server instance in the synchronization service cluster (pushserver); the client (SDK) refers to a terminal device (such as a mobile phone, a computer, etc.) used by a user to watch live broadcast and send a barrage; the synchronization instruction refers to a request signal sent by the client (SDK) to trigger synchronization of system states; the component ID is used to represent the unique identification of each functional component in the system; the state refers to the current running state of the component (such as ready, processing, exception, etc.); the timestamp is used to represent the specific time of data record, usually accurate to milliseconds; the room ID refers to the unique identification of a live broadcast room, used to distinguish different live broadcast scenes; the node condition data refers to a set containing the component ID, the state, the timestamp and the room ID, used to describe the current state of the node; the distributed coordination service (etcd) refers to tools such as etcd and ZooKeeper, used for state storage, service discovery and distributed lock management in a distributed system.

[0040] When the client (SDK) starts live broadcast watching, switches a live broadcast room or the system detects a component state exception, the client (SDK) sends a synchronization instruction to the synchronization service cluster (pushserver); after a node in the synchronization service cluster (pushserver) receives the instruction, the node collects the component ID corresponding to the node, the current running state, the timestamp of receiving the instruction and the room ID of the live broadcast room to which the node belongs, to form node condition data; then, the node writes the data into the distributed coordination service (etcd) to realize global recording of the state of the node and ensure that other service nodes can obtain the latest state of the node through the distributed coordination service (etcd).

[0041] It should be noted that the synchronization service cluster is only responsible for data synchronization and state synchronization between the client (SDK) and the server, maintains long connection communication between the client and the server, but does not execute specific business logic; the business service cluster is responsible for processing all back-end business logic, and completes complex business calculation and processing through interaction with the synchronization service cluster, the distributed cache service (redis), the distributed coordination service (etcd) and the database (mysql); the design of separating the service decouples connection maintenance and business processing, and avoids the problem of interruption of long connections of all users caused by restart or failure of the business service.

[0042] Please refer to Figure 6 , Figure 6 is a schematic diagram of a barrage service pushing process in the method of barrage live broadcast interaction in the embodiment of the application; S102, the synchronization service node publishes a notification message to a preset notification node through a publish / subscribe mechanism of a distributed cache service (redis); Among them, the synchronization service node refers to a single node in the synchronization service cluster (pushserver), responsible for performing specific synchronization operations; the distributed cache service (redis) refers to tools such as Redis, used to cache data and support publish / subscribe functions; the publish / subscribe mechanism refers to a message passing mode, in which the publisher sends messages to a specific channel, and the subscriber receives messages by subscribing to the channel; the preset notification node refers to a message channel defined in advance in the distributed cache service (redis), used to deliver synchronization notifications; the notification message refers to a message containing synchronization events, room ID, timestamp, etc., used to inform other service nodes that the system state has been updated.

[0043] When the synchronization service node successfully writes the node condition data into the distributed coordination service (etcd), it will immediately generate a notification message containing the event type of this synchronization (such as "node state update"), the corresponding room ID and timestamp; then, the node sends this message to the preset notification node (i.e. a specific channel) through the publish function of the distributed cache service (redis); Since the business service cluster (business) has pre-subscribed to the notification node, it can receive this message in real time, thereby knowing that the system state has changed and needs to be followed up for state comparison and business processing.

[0044] S103, all nodes in the business service cluster (business) listen to the notification node of the distributed cache service (redis) to receive notification messages; When the business service cluster (business) starts, all nodes will load the preset notification node name through the configuration file; each business service node establishes a long-term connection with the notification node through the subscribe function (such as the SUBSCRIBE command of Redis) of the distributed cache service (redis); When the synchronization service node publishes a message to the notification node, the distributed cache service (redis) will push the message to all business service nodes that subscribe to the node; After receiving the message, the business service node will temporarily store the message content and mark it as "to be processed", preparing for subsequent state comparison.

[0045] S104, after receiving the notification message, the nodes in the business service cluster (business) access the distributed coordination service (etcd) to obtain the current state of all synchronized components, and compare it with the preset number of push nodes; The synchronized components refer to system components that have completed state recording and written into the distributed coordination service (etcd); the current state refers to the latest running state (such as ready, online, etc.) of the components; and the preset number of push nodes refers to the total number of nodes (such as 3 push nodes working simultaneously in a certain live room) that need to participate in the push stream according to the live scene demand.

[0046] After receiving the notification message, the business service node parses the room ID in the message to determine the current live scene to be processed. Then, the node accesses the distributed coordination service (etcd) to query the state data of all synchronized components according to the room ID prefix. By analyzing these data, the node counts the total number of component instances in the "ready" state. Next, the node obtains the preset number of push nodes for the current room from the local configuration or the distributed coordination service (etcd). Finally, the actual number is compared with the preset number. If they are equal, it means that the system is ready and the master node election process can begin. If they are not equal, the node continues to wait for a new synchronization notification.

[0047] In some embodiments, step S104 specifically includes: S1041, after listening to the notification of the distributed cache service (redis), the business service node in the business service cluster (business) obtains all key-value pairs with a preset prefix in batches through the command of the distributed coordination service (etcd); The key-value pairs with a preset prefix refer to keys and their corresponding values named according to a unified rule in the distributed coordination service (etcd), and the prefix is used to identify related data under the same business scene.

[0048] The business service node receives a synchronization event notification (such as "component state has been updated") by listening to the preset notification node of the distributed cache service (redis). According to the room ID in the notification, the business service node determines the current business scene to be processed and generates a preset prefix for the key in the distributed coordination service (etcd). Then, the business service node calls the batch query command of the distributed coordination service (etcd) to obtain all key-value pair data under the prefix. These key-value pairs contain the IDs and states of all components in the room, which are temporarily stored in the local memory of the business service node for analysis and statistics.

[0049] S1042, by analyzing the key-value pairs, the business service node counts the total number of component instances that have completed synchronization preparation; S1043, the business service node compares the total number with the total number of push nodes required in the current business scene; S1044, when the total number matches the preset total number of push nodes, the current business service node is allowed to participate in the election process of the master business node. When the service service node determines that the statistical total number matches the preset push node total number, it means that all necessary components in the system are ready for the business processing phase; the node reads the entry condition of the main business node election from the local configuration and confirms that it meets the condition; then, the local election trigger mechanism is activated, and the election-related lock path in the distributed coordination service (etcd) is registered; when other nodes in the cluster also complete the matching determination, they participate in the main node election based on the distributed lock, and the current node can normally initiate a lock preemption request.

[0050] S1045, if the number does not match, the service service node continues to wait; Specifically, when the service service node determines that the number does not match, it analyzes the mismatch reason and records it in the local log; then, the election trigger mechanism is closed to avoid initiating invalid lock preemption requests; at the same time, the Watch mechanism of the distributed coordination service (etcd) is used to listen to the changes of key-value pairs under the preset prefix, or the notification node of the distributed cache service (redis) is resubscribed; when the synchronization notification is received again or the component state change is listened to, the process of S1041-S1043 is repeated until the statistical total number matches the preset number, and then the election link of S1044 is entered.

[0051] As can be seen, after the service service node in the service service cluster listens to the notification of the distributed cache service, it acquires all the key-value pairs of the preset prefix in batches through the command of the distributed coordination service. The distributed coordination service plays a role in unified management and data integration here, and can orderly gather the scattered component state information in the form of key-value pairs. The service service node parses the obtained key-value pairs, counts the total number of component instances that have completed synchronization preparation, and then compares the statistical total number with the total number of push nodes required in the current business scenario. Only when the number matches, the current service service node is allowed to participate in the election process of the main business node, ensuring that the nodes participating in the election are all in the state of synchronization preparation of the overall system, and eliminating the problems of delay and data error that may be caused by the reckless development of business when some components are not ready.

[0052] S105, when the number matches, the service service cluster (business) uses the distributed lock feature provided by the distributed coordination service (etcd) to preoccupy the preset business lock, and the service service node that successfully acquires the lock becomes the main business node, and the remaining service service nodes enter a waiting state; Among them, the preset business lock refers to the lock identifier defined in advance in the distributed coordination service (etcd), which is used to control the uniqueness of business processing; the waiting state refers to the state in which the node temporarily stops business processing and only listens to the change of the lock state.

[0053] When the comparison result in S104 is a quantity match, a node in the business service cluster (business) needs to be determined as a master node to handle the business, to avoid repeated processing by multiple nodes.

[0054] When the business service node determines that the number of synchronized components matches the number of preset push nodes, it will notify the entire business service cluster (business) to start master node election. All nodes in the cluster use the distributed lock function provided by the distributed coordination service (etcd) to initiate a preemption request to the preset business lock. The distributed coordination service (etcd) determines the order of the node request or the competition mechanism (only one node is allowed to successfully acquire the lock). The node becomes the master business node and is responsible for subsequent business data processing. The remaining nodes that do not acquire the lock enter a waiting state and continuously monitor the state changes of the business lock to participate in preemption again when the master node fails.

[0055] In some embodiments, the preemption of the business lock can be achieved in various ways: 1. The business service node generates a unique node identifier (such as UUID) and sends a request to the distributed coordination service (etcd) to acquire the lock, specifying the business lock path; 2. The distributed coordination service (etcd) determines whether the lock is idle, and if it is idle, assigns the lock to the node and sets a lease time; 3. The node that acquires the lock is marked as the "master business node", and the nodes that do not acquire the lock enter a waiting state and listen to the lock release event, which is not limited here.

[0056] In actual use, the master node responsible for core business processing may fail, so in some embodiments, after step S105, the method further includes: S1051, When the master business node loses contact with the distributed coordination service (etcd), the lock it holds will be automatically released by the distributed coordination service (etcd) when the lease expires; all other business service nodes in the waiting state can immediately sense the lock release event because they continuously monitor the lock state Wherein, the master node is out of connection with the distributed coordination service (etcd) means that the master node cannot keep communication with the distributed coordination service (etcd) (such as etcd) due to network failure, hardware exception, etc.; the held lock means the identification (such as / lock / business / room1001) acquired by the master node through the distributed coordination service (etcd) for exclusive business processing right; the lease expiration means the end of the validity period (such as 30 seconds) set by the distributed coordination service (etcd) for the lock, and if the master node does not renew the period, the lock will automatically expire; the other business service nodes in the waiting state are the business nodes that have not acquired the lock and are in an idle state; the continuously listening to the state of the lock means that the waiting node monitors the changes of the lock in real time through the Watch mechanism of the distributed coordination service (etcd); and the event of the lock being released means the notification that the lock becomes idle due to the expiration of the lease or voluntary release.

[0057] When the master node acquires the lock, the distributed coordination service (etcd) will allocate a lease (such as 30 seconds) for it, and the master node needs to periodically (such as every 10 seconds) send a renewal request to the coordination service to maintain the validity of the lock; when the master node is out of connection (such as downtime, network interruption), it cannot renew on time, and after the lease expires, the coordination service automatically marks the lock as "released"; at the same time, all business service nodes in the waiting state will immediately receive the event notification that the lock has been released through the Watch mechanism to monitor the path of the lock, and know that they can compete for the lock again to prepare for a new round of election.

[0058] S1052, when one or more business service nodes in the waiting state detect that the lock is released, the business service nodes reattempt to acquire the distributed lock, thereby triggering a new round of election S1053, the node that successfully acquires the lock becomes the new master node S1054, before starting to process the business, the new master node will first check the completion status marker of the business; if the marker is not completed, the new master node reexecutes the business logic from the last breakpoint or from the beginning; if the marker is completed, the new node directly returns and does not repeat the execution After the new master node becomes the master node, it first accesses the preset business state path in the distributed coordination service (etcd) or the database (mysql) to read the completion status marker of the business; if there is no breakpoint recorded, it starts from the beginning to process; if the marker is "completed", it directly returns and does not repeat the processing; during the processing, the new master node will periodically update the status marker to ensure that it can accurately recover in case of failure again.

[0059] It can be seen that when the master business node is disconnected with the distributed coordination service, the lock held by the master business node will be automatically released by the distributed coordination service after the lease expires. All other business service nodes in the waiting state can immediately perceive the event of the lock being released because they continuously monitor the state of the lock. When one or more waiting business service nodes detect that the lock is released, they reattempt to acquire the distributed lock, thereby triggering a new round of election. A decentralized and automated fault detection and recovery process is constructed relying on the characteristics of the distributed coordination service, effectively simplifying the system architecture. The node that successfully acquires the lock becomes the new master business node. Before starting to process the business, the new master business node will first check the completion status flag of the business. If the flag is not completed, the business logic is re-executed from the last breakpoint or from the beginning. If the flag is completed, the business is directly returned and is not repeated. Through such a mechanism, when the master node fails, the automatic release of the lock and the fast lock election can ensure that a new master node is generated in a very short time, greatly shortening the service interruption time, guaranteeing the business continuity and data consistency after the failover, and enabling the entire bullet screen live interactive system to still operate stably in the face of node failures and other abnormal situations, without affecting the normal use experience of users.

[0060] S106, the master business node consumes business data from the distributed cache service (redis) according to the business logic, and interacts with the database (mysql) to complete persistent storage or reading; the business data is derived from the bullet screen production and consumption process, wherein the bullet screen data in the business data is distributed to different topics of the notification message queue according to the room, and is stored in the distributed cache service (redis) after being processed by the bullet screen consumer; The business logic refers to the rules of live interaction (such as bullet screen voting statistics, gift special effect trigger conditions, etc.); the process of consuming business data refers to the process of the master business node acquiring and processing business data from the distributed cache service (redis); the database (mysql) refers to a relational database (mysql) such as MySQL, which is used to store business data that needs to be saved for a long time; persistent storage refers to the operation of writing data into the database (mysql) to achieve long-term storage; business data refers to data related to live interaction (such as bullet screen content, user behavior, interaction results, etc.); the bullet screen production and consumption process refers to the whole process from the generation of bullet screens to the processing and storage of the bullet screens; the notification message queue refers to tools such as RocketMQ and Kafka, which are used to temporarily store and distribute bullet screen data; different topics refer to message channels in the message queue divided according to room IDs, which are used to isolate bullet screens of different live rooms; the bullet screen consumer refers to a service node that processes bullet screen data in the message queue; and storing into the distributed cache service (redis) refers to writing the processed bullet screen data into the distributed cache for the master business node to quickly acquire.

[0061] Specifically, after the master service node becomes the master node, the current live room business logic (such as "count the number of voting bullet screen in 1 minute") is loaded; at the same time, the business data (such as the real-time bullet screen of the live room) that has been processed by the bullet screen consumer is read from the distributed cache service (redis); the master service node processes these data according to the business logic (such as analyzing the bullet screen content and counting the voting result); for data that needs to be saved for a long time (such as special gift records and key interaction results), the master service node interacts with the database (mysql) to write the data into the database (mysql) to realize persistence; for data that needs to be used in real time (such as the current voting progress), the data is updated to the distributed cache service (redis); wherein the source of these business data is that the bullet screen producer distributes the bullet screen of different rooms according to the theme to the notification message queue, the bullet screen consumer obtains the bullet screen from the corresponding theme and processes (such as filtering sensitive words and format conversion), and then stores the processed bullet screen in the distributed cache service (redis).

[0062] Please refer to Figure 4 and Figure 5 , Figure 4 is a schematic diagram of a bullet screen service collection process in the method of bullet screen live interaction in the embodiments of the present application; Figure 5 is a schematic diagram of a bullet screen service pushing process in the method of bullet screen live interaction in the embodiments of the present application; Among them, the bullet screen production and consumption process specifically includes: S1061, each bullet screen producer node establishes a long connection with the bullet screen service of one or more third-party live platforms through a protocol, and receives bullet screen data containing user ID, room ID and bullet screen content in real time; Among them, the bullet screen producer node refers to a service node specially used for obtaining bullet screen data from an external platform, and multiple nodes are deployed to improve reliability; the protocol refers to the rules followed by data transmission (such as WebSocket protocol); the bullet screen service of the third-party live platform refers to the interface service provided by platforms such as Bilibili and Tiktok for distributing bullet screen data externally; the long connection refers to the persistent network connection established between the client (SDK) and the server for real-time data transmission; the user ID refers to the unique identifier of the user sending the bullet screen; the room ID refers to the unique identifier of the live room; the bullet screen content refers to the interactive information such as text and expression sent by the user; the bullet screen data refers to the structured data (such as JSON format) containing user ID, room ID and bullet screen content.

[0063] Specifically, before the live broadcast starts, the system starts multiple danmaku producer nodes, each of which is connected to the danmaku service of one or more third-party live broadcast platforms according to the configuration; a long connection is established with the danmaku service through the WebSocket protocol, and identity verification (such as platform API key verification) is completed; after the connection is established, the danmaku producer node continuously listens to the data stream from the platform, and when the user sends a danmaku on the third-party platform, the danmaku service will push the danmaku data containing the user ID, the room ID where the user is located, and the danmaku content to the corresponding producer node in real time; after the producer node receives the data, it is temporarily stored in the local buffer area to prepare for subsequent room distribution.

[0064] S1062, after receiving the danmaku data, the danmaku producer node writes the danmaku data as a message body into a specific topic in a message queue service corresponding to the room ID according to the room ID to which the danmaku data belongs; Among them, the specific topic (Topic) refers to a message channel in the message queue divided according to business dimensions, which is used here to isolate the danmaku data of different live broadcast rooms according to the room ID (such as topic_danmaku_1001 corresponding to the live broadcast room with room ID 1001).

[0065] In some embodiments, after receiving the danmaku data in S1061, the danmaku producer node needs to store it immediately according to the room to avoid confusion of the danmaku of different live broadcast rooms.

[0066] Specifically, the danmaku producer node takes out the received danmaku data from the local buffer area, parses the room ID in it, generates the corresponding message queue topic name according to the room ID, then calls the message sending interface of the message queue service, and writes the danmaku data as a message body into the topic; after receiving the message, the message queue service stores it in the partition of the corresponding topic, and returns the confirmation information of successful sending.

[0067] S1063, deploy multiple danmaku consumer nodes, each of which subscribes and consumes the danmaku data of one or more specific topics in the message queue service; Among them, subscription refers to the registration of the consumer node to the message queue service to listen to a specific topic, so as to receive the messages under the topic; consumption refers to the process of the consumer node obtaining messages from the message queue and processing them.

[0068] Specifically, the system deploys multiple barrage consumer nodes, each of which is assigned one or more topics corresponding to room IDs according to a load balancing strategy; when a consumer node starts, it sends a subscription request to the message queue service, specifying the topics it needs to consume; the message queue service assigns each consumer node a corresponding message partition and maintains the consumption progress (such as the offset); when new barrage data is written to a topic, the message queue service will push the data to the consumer nodes that subscribe to the topic; after receiving the data, the consumer nodes process it in order to avoid data loss or duplicate consumption.

[0069] S1064, the consumer node uses the publish / subscribe feature of the distributed cache service (redis) to listen to business data collection notifications to determine the current business logic that needs to be processed; Among them, the publish / subscribe feature of the distributed cache service (redis) refers to the PUB / SUB function of Redis, which supports one node publishing messages and multiple nodes subscribing to receive messages; the business data collection notification refers to the message published by the business service cluster (business) containing the current business rule that needs to be processed; the business logic refers to the processing rule of the barrage data.

[0070] After the barrage consumer node starts, it needs to obtain the current business processing rule in real time to ensure that the barrage processing meets the live interaction requirements. When the barrage consumer node starts, it subscribes to a preset business notification channel through the subscription function of the distributed cache service (redis); when the live scene or interaction rules change, the business service cluster (business) will publish a business data collection notification to the channel, and the notification contains the business logic identifier that needs to be executed; after receiving the notification, the consumer node parses the business logic identifier and loads the corresponding processing rule from the local configuration or distributed storage, preparing for subsequent processing of barrage data.

[0071] S1065, the consumer node processes the consumed barrage data according to the business state; Specifically, after the barrage consumer node obtains the barrage data from the message queue, it first parses the user ID, room ID, and barrage content; according to the business logic determined in S1064 and the current business state, the barrage content is processed: for example, if it is in the filtering stage, it will detect whether the content contains sensitive words and replace them with "*"; if it is in the statistical stage, it will extract the key information in the content; after processing, structured data containing the original data and the processing result is generated, preparing for the subsequent judgment of the storage method.

[0072] S1066, in the case of matching the current business logic, the bullet screen content is stored in the distributed cache service (redis) for the main business node; wherein, for special bullet screen that needs to be saved for a long time, it is stored in the database (mysql); Wherein, special bullet screen refers to bullet screen with commemorative significance or post-analysis (such as bullet screen with gift value exceeding threshold, host reply bullet screen); database (mysql) refers to relational database (mysql) such as MySQL for long-term data storage.

[0073] The bullet screen consumer node judges whether the processed bullet screen data matches the current business logic; if it matches, the data is first stored in the specified key of the distributed cache service (redis) to ensure that the main business node can quickly read; at the same time, check whether the bullet screen belongs to special bullet screen; if it is special bullet screen, it is additionally written into the database (mysql) to record user ID, room ID, content, timestamp and other information for subsequent playback or statistics.

[0074] S1067, in the case of not matching the current business logic, the bullet screen data is written into the local log file; Wherein, not matching refers to the fact that the bullet screen content does not meet the requirements of the current business logic; local log file refers to the file stored in the server where the consumer node is located, which is used to record the bullet screen data that is not processed by the business.

[0075] Specifically, the bullet screen consumer node judges that the processed bullet screen data does not match the current business logic; in order to avoid these data occupying distributed cache or database (mysql) resources, the consumer node writes it into the local log file; the log file is named by date, and each log contains timestamp, room ID, user ID, original bullet screen content and mismatch reason; at the same time, set the rolling strategy of the log file to prevent disk space overflow.

[0076] It can be seen that the producer node writes the room ID of the barrage as a message body into the corresponding specific topic in the message queue service, and uses the message queue to store the data by topic, which realizes the isolation and preliminary arrangement of different live room barrage data, and makes the subsequent processing more targeted. Deploy multiple barrage consumer nodes to subscribe and consume the barrage data of these specific topics, and listen to business data collection notifications through the publish / subscribe feature of the distributed cache service to determine the processing logic, so that the consumer node can process the barrage data flexibly according to different business states. The barrage that matches the business logic is stored in the distributed cache service, which facilitates the main business node to quickly obtain hot data for real-time processing, and the special barrage is stored in the database to ensure long-term storage requirements, and the unmatched is written to the local log file to avoid invalid data interference. The buffering capacity of the message queue effectively handles the barrage flood peak, prevents the backend service from being directly impacted by high concurrency, sets the topic by room ID to achieve parallel processing of barrage in different live rooms, and the consumer architecture of multiple nodes plus reasonable data hierarchical storage improves the horizontal expansion capability and processing efficiency of the system, so that the main business node can always obtain key data with low delay, and ensure that the entire barrage live interaction is efficient and orderly.

[0077] In actual use, how to improve the accuracy of the effective barrage pushed to thousands of online users after being processed by the service side business logic.

[0078] In some embodiments, after step S106, further comprising: S1068, the main business node is embedded with a timer, which actively sends a request to the distributed cache service (redis) at a preset cycle period to obtain the set of effective barrage data stored in the distributed cache service (redis) after being processed by the consumer node and related to the current business logic Wherein, the timer refers to a timing task component embedded in the main business node, used to trigger data acquisition operation periodically; the preset cycle period is the time interval (such as 500ms) for the timer to execute, used to control the frequency of data acquisition; the distributed cache service (redis) refers to a service such as Redis cluster for storing temporary data; the set of effective barrage data refers to the barrage data that meets the current business logic requirements after being processed by the consumer node.

[0079] Specifically, the main business node initializes the timer when starting, and sets the cycle period; each time the timer triggers, the main business node constructs a cache query Key according to the current business logic; sends a batch acquisition request to the distributed cache service (redis), and acquires the barrage data set under the specified Key; the acquired data contains user ID, barrage content, processing time and other information, and the main business node performs format checking (such as JSON parsing) and integrity checking (such as checking whether it contains necessary fields) on the data to ensure that the data is available; if the acquisition fails (such as cache service timeout), an error log is recorded and the next cycle is retried.

[0080] S1069, after the main business node acquires the barrage data set, the data set is cached to one or more barrage push service nodes Among them, the barrage push service node refers to a service cluster specially responsible for pushing the barrage data to the client (SDK).

[0081] S10610, the barrage push service node is responsible for efficiently distributing the barrage data to all clients (SDK) connected to the synchronization service; wherein the leader node of the barrage push is generated through the election mechanism of the distributed coordination service (etcd), and the other push nodes are backup Among them, the barrage push service node refers to a service cluster responsible for pushing the barrage to the client (SDK); the leader node refers to the master node generated by election, responsible for coordinating the push task; the backup node refers to the slave node that takes over the work of the leader node when the leader node fails; the election mechanism of the distributed coordination service (etcd) refers to mechanisms such as the distributed lock of etcd and the Leader election of ZooKeeper, which are used to select a unique leader.

[0082] Specifically, the barrage push service node competes to become a leader node through the election mechanism of the distributed coordination service (etcd) (such as etcd); the leader node is responsible for receiving the barrage data cached by the main business node, and distributing the data to the corresponding push service node according to the client (SDK) connection distribution (such as sharding by room ID); each push service node pushes the barrage data to the corresponding client (SDK) through the maintained WebSocket connection; at the same time, the leader node sends a heartbeat to the distributed coordination service (etcd) regularly, and if the heartbeat times out, other nodes re-elect the leader to ensure high availability; the backup node synchronizes the state of the leader in real time, and quickly takes over when the leader fails.

[0083] It can be seen that the main business node embeds a timer to actively send a request to the distributed cache service at a preset cycle period. The setting of the timer enables the main business node to actively acquire data, acquire the required barrage data set at a predetermined pace, and ensure the timeliness and regularity of data acquisition, thereby avoiding the delay caused by passive waiting. After the main business node acquires the barrage data set, the data set is cached to one or more barrage push service nodes. In this way, a data buffer zone is built between the main business node and the client, which not only reduces the direct distribution pressure of the main business node, but also facilitates subsequent unified management and push. The barrage push service node is responsible for efficiently distributing the barrage data to all clients connected to the synchronization service. The leader node of the barrage push is generated through the election mechanism of the distributed coordination service, and the other push nodes serve as backups. The election mechanism ensures the authority and representativeness of the leader node, enabling it to reasonably coordinate the backup nodes and jointly complete the efficient data distribution task. Thus, an end-to-end, robust and efficient barrage push link is built to ensure that users can timely and smoothly receive barrage information.

[0084] In actual use, there is a special scenario - multi-person joint live streaming. This live streaming is not multi-person interaction in a single live streaming room, but joint live streaming cooperatively developed by multiple independent live streaming rooms. In this scenario, the core problem is: how to accurately and timely affect other live streaming rooms participating in joint live streaming to realize cross-room interaction and linkage.

[0085] In some embodiments, step S106 specifically includes: S10611, when the main business node calculates the next state change instruction according to the business logic; the main business node sends the state change instruction to the synchronization service cluster (pushserver) The state change instruction refers to an instruction generated by the main business node according to the business logic (such as live streaming interaction rules, voting results, etc.) for changing the system state (such as "switching live streaming room picture" and "updating voting progress").

[0086] Specifically, the main business node calculates the next state change instruction according to the preset business logic, and the instruction contains the target state (such as "scene switching to A camp victory picture"), related room ID and timestamp. The main business node sends the instruction to the entry node of the synchronization service cluster (pushserver) through an internal communication protocol (such as RPC and message queue). After the entry node receives the instruction, it performs legality verification (such as verifying the instruction signature and checking the validity of the room ID), and forwards the instruction to other synchronization service nodes in the cluster after the verification is passed, to ensure that all nodes in the cluster can receive the instruction.

[0087] S10612、After receiving the state change instruction, the synchronization service cluster (pushserver) broadcasts in a full-connection communication mode; wherein each synchronization service node that receives the instruction synchronizes the instruction to all service-side interactive video instances connected thereto without distinction, and all service-side interactive video instances connected thereto belong to different live rooms or different anchor teams The full-connection communication mode refers to that each node in the synchronization service cluster (pushserver) establishes a direct communication link with all other nodes to ensure that the instruction is delivered to each node in the cluster; and the different live rooms or different anchor teams refer to the business scenarios to which the service-side interactive video instances belong, which can belong to different live rooms or opposing anchor teams.

[0088] After receiving the state change instruction in S10611, the synchronization service cluster (pushserver) needs to synchronize the instruction to all related service-side interactive video instances to ensure state consistency in multiple scenarios. Specifically, after receiving the state change instruction, the synchronization service cluster (pushserver) broadcasts the instruction to all synchronization service nodes in the cluster through full-connection communication; after each synchronization service node receives the instruction, it traverses the service-side interactive video instance connection list it maintains (these instances can belong to different live rooms or anchor teams); the instruction is sent to each connected instance without distinction, regardless of the scenario to which the instance belongs; after the service-side interactive video instance receives the instruction, it adjusts its state according to the instruction content (such as updating picture rendering parameters, synchronizing interactive progress), ensuring that all instances display consistent states.

[0089] As can be seen, through such a broadcast mechanism, all instances participating in interaction can simultaneously receive uniform state change instructions in a complex multi-live room, multi-anchor team environment, ensuring the consistency of the states of all parts of the system. Although full-connection broadcasting increases network traffic, this "centralized decision, full-connection broadcast" synchronization strategy fundamentally solves the problem of multi-party state synchronization, allowing all different live viewers to see the same state, providing real-time synchronization experience for multi-person live, greatly improving the playability and fairness of multi-person live, and ensuring that live interaction can be orderly and coordinated between different teams and different live rooms, avoiding confusion and disputes caused by inconsistent states.

[0090] S107、After the main business node completes processing, the result state is updated, and the processing result is pushed to all related clients (SDK) through the synchronization service cluster (pushserver).

[0091] The processing completion refers to that the main business node completes the processing of the business data according to the business logic (such as the end of voting statistics, completion of interactive tasks, etc.); the result state refers to the final result of the business processing (such as voting results, interactive reward list, etc.); the updating refers to writing the result state into a distributed cache service (redis) or a distributed coordination service (etcd), to ensure the consistency of the system state; the processing result refers to data containing the result state, timestamp, room ID and the like, which is used to inform the client (SDK) of the progress of the business; and the related client (SDK) refers to all watching clients (SDK) in the current live room.

[0092] After the main business node completes the processing of the business data in S106, the result needs to be fed back to the user to realize the closed loop of live interaction. Specifically, after the main business node completes the business processing, the processing result containing the result state, processing timestamp and room ID is generated; then, the main business node updates the result state to the distributed cache service (redis) or the distributed coordination service (etcd) for other nodes to obtain; at the same time, the main business node sends the processing result to the synchronization service cluster (pushserver); the synchronization service cluster (pushserver) pushes the processing result to all related clients (SDK) in the current live room through the long connection (such as WebSocket) with the client (SDK); after the client (SDK) receives the result, the result is displayed on the interface (such as displaying a voting result animation), and the whole interactive process is completed.

[0093] It can be seen that the high concurrency bottleneck that is prone to occur in the centralized service architecture is dispersedly processed, and a single server is no longer relied on. A synchronization service cluster is synchronized, which is only responsible for data synchronization and state synchronization between the client and the server, maintains long connection communication between the client and the server, but does not execute specific business logic; a business service cluster is responsible for processing all back-end business logic, decouples connection maintenance and business processing, and avoids the problem of long connection interruption of all users caused by business service restart or failure. When the node in the synchronization service cluster receives a client synchronization instruction, node condition data containing multiple key information is written to a distributed coordination service. The synchronization service node publishes a notification message by means of the publish / subscribe mechanism of the distributed cache service, and all nodes of the business service cluster listen to and receive, thereby establishing a message transmission link. The business service cluster node accesses the distributed coordination service to obtain the synchronized component state and compares it with the number of push node, and this comparison link uses the centralized control advantage of the distributed coordination service to filter out the appropriate opportunity. Then, the distributed lock feature is used to preempt the business lock to select the main business node, avoid confusion caused by simultaneous operation of multiple nodes, and ensure the orderliness of business processing. The main business node consumes business data from the distributed cache service, which acts as an efficient data staging and sharing space. The main business node then interacts with the database to complete storage or reading, realizes persistent management and real-time calling of data. Finally, the main business node updates the result state and pushes it to the client through the synchronization service cluster, disperses the high concurrency bottleneck that is prone to occur in the centralized service architecture, no longer relies on a single server, solves the performance problem caused by a large number of read and write requests, thereby improves the system service stability and high availability in the multi-person live broadcast scene, and makes the user unaware of abnormal conditions during live broadcast, improving the user experience.

[0094] In some embodiments, after step S107, the method further comprises: S108, storing business data strongly related to real-time business in a distributed cache service (redis), the business data including barrage statistical results, valid business barrages to be pushed, and business intermediate state data requiring fast reading and writing; and starting a snapshot storage mechanism; S109, storing saved data requiring permanent saving, low-frequency access but high consistency in a database (mysql); the saved data including user basic information, special barrage data required for subsequent playback, and complete business flow records.

[0095] It can be seen that the hierarchical heterogeneous storage architecture using Redis+MySQL gives full play to the advantages of different storage media, realizes the separation of hot and cold data, hot data quickly flows in the cache, and cold data is safely stored in the database, achieves the best balance of cost and performance, effectively supports the real-time interaction of the front-end business, and makes the user experience smooth and instant service, and provides a solid and reliable data foundation for long-term operation and data analysis of the back-end, and ensures that the entire live broadcast interaction system can stably and efficiently run at different business demand levels.

[0096] The following describes an example live broadcast interaction server 700 provided by an embodiment of the application. Figure 7 FIG. 1 is an example hardware structure schematic diagram of the live broadcast interaction server 700 provided by an embodiment of the application.

[0097] In some embodiments, the live broadcast interaction server 700 is a computer device or includes a computer device in the live broadcast interaction server 700. The computer device includes a processor, a memory, and a network interface connected through a system bus. The processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for running the operating system and the computer program in the non-volatile storage medium. The database of the computer device is configured to store data. The network interface of the computer device is configured to communicate with other terminals or servers outside through a network connection. In some embodiments, the network interface can be a wired network interface, and in some embodiments, the network interface can also be a wireless network interface. The computer program is executed by the processor to implement the method in the embodiments of the application.

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

[0099] The above-described embodiments are only used to illustrate the technical solutions of the present application, but not limit them; although the foregoing embodiments of the present application have been described in detail, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for some technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

[0100] In the above embodiments, the term "when" can be interpreted as meaning "if" or "after" or "in response to determining" or "in response to detecting" depending on the context. Similarly, the phrase "upon determining" or "if detecting (the stated condition or event)" can be interpreted as meaning "if determining" or "in response to determining" or "upon detecting (the stated condition or event)" or "in response to detecting (the stated condition or event)" depending on the context.

[0101] In the above embodiments, all or part of the methods can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the methods can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) manner. The computer readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be magnetic media (such as floppy disk, hard disk, magnetic tape), optical media (such as DVD), or semiconductor media (such as solid state disk), etc.

[0102] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by a computer program to instruct the relevant hardware to complete, and the program can be stored in a computer readable storage medium, and the program can include the processes of the above-mentioned method embodiments when executed. The aforementioned storage medium includes ROM or random access memory (RAM), magnetic disk or optical disk, and various media that can store program codes.

Claims

1. A method for bullet screen live broadcast interaction, characterized in that, The steps include: After receiving the synchronization instruction from the client, the node in the synchronization service cluster writes the node condition data containing the current component ID, state, timestamp and room ID into the distributed coordination service for state recording; The synchronization service node publishes a notification message to the preset notification node through the publish / subscribe mechanism of the distributed cache service; All nodes in the business service cluster listen to the notification node of the distributed cache service receiving the notification message; After receiving the notification message, the nodes in the business service cluster access the distributed coordination service to obtain the current state of all synchronized components and compare it with the preset number of push nodes; When the number matches, the business service cluster uses the distributed lock feature provided by the distributed coordination service to occupy the preset business lock, and the business service node that successfully obtains the lock becomes the master business node, and the remaining business service nodes enter the waiting state; The master business node consumes business data from the distributed cache service according to business logic and interacts with the database to complete persistent storage or reading; the business data comes from the bullet screen production and consumption process, in which the bullet screen data in the business data is distributed to different topics of the notification message queue according to the room, and then stored in the distributed cache service after being processed by the bullet screen consumer; After the master business node completes processing, it updates the result state and pushes the processing result to all related clients through the synchronization service cluster.

2. The method of claim 1, wherein, The bullet screen production and consumption process specifically includes: Each bullet screen producer node establishes a long connection with the bullet screen service of one or more third-party live streaming platforms through a protocol and receives bullet screen data containing user ID, room ID and bullet screen content in real time; After receiving the bullet screen data, the bullet screen producer node writes the bullet screen data as a message body into a specific topic corresponding to the room ID in a message queue service according to the room ID to which it belongs; Deploy multiple bullet screen consumer nodes, each of which subscribes and consumes bullet screen data in one or more specific topics of the message queue service; The consumer node listens to the business data collection notification using the publish / subscribe feature of the distributed cache service to determine the current business logic that needs to be processed; The consumer node processes the consumed bullet screen data according to the business state; In the case that the bullet screen content matches the current business logic, it is stored in the distributed cache service for the master business node to use; for special bullet screens that need to be saved for a long time, they are stored in the database; In the case that the bullet screen content does not match the current business logic, the bullet screen data is written into a local log file.

3. The method of claim 1, wherein, After receiving the notification message, the nodes in the business service cluster access the distributed coordination service to obtain the current state of all synchronized components and compare it with the preset number of push nodes, specifically including: After listening to the notification of the distributed cache service, the business service node in the business service cluster obtains all key-value pairs with the preset prefix in batches through the command of the distributed coordination service; By parsing the key-value pair, the business service node counts the total number of component instances that have completed synchronization preparation; The business service node compares the total number with the total number of push nodes required in the current business scenario; When the total number matches the preset total number of push nodes, the current business service node is allowed to participate in the election process of the master business node; If the numbers do not match, the business service node continues to wait.

4. The method of claim 3, wherein, After the step of the business service cluster using the distributed lock feature provided by the distributed coordination service to seize the preset business lock, and the business service node that successfully acquires the lock becomes the master business node, and the remaining business service nodes enter a waiting state, the method further comprises: When the master business node loses contact with the distributed coordination service, the lock it holds will be automatically released by the distributed coordination service after the lease expires; all other business service nodes in the waiting state can immediately perceive the event of the lock being released because they continuously monitor the state of the lock; When one or more waiting business service nodes detect that the lock is released, they reattempt to acquire the distributed lock, thereby triggering a new round of election; The node that successfully acquires the lock becomes the new master business node; Before starting to process the business, the new master business node first checks the completion status marker of the business; if the marker is not completed, the new master node re-executes the business logic from the last breakpoint or from the beginning; if the marker is completed, the new node directly returns and does not repeat the execution.

5. The method of claim 2, wherein, After the step of the master business node consuming business data from the distributed cache service according to the business logic and interacting with the database for persistent storage or reading, the method further comprises: The master business node embeds a timer to actively send requests to the distributed cache service at a preset cycle period to obtain the set of valid barrage data stored therein that has been processed by the consumer node and is related to the current business logic; After the master business node obtains the set of barrage data, it caches the data set to one or more barrage push service nodes; The barrage push service nodes are responsible for efficiently distributing the barrage data to all clients connected to the synchronization service; the leader node of the barrage push is generated through the election mechanism of the distributed coordination service, and the other push nodes serve as backups.

6. The method of claim 1, wherein, After the step of the master business node updating the result state and pushing the processing result to all related clients through the synchronization service cluster, the method further comprises: Storing business data that is strongly related to real-time business in the distributed cache service, including barrage statistical results, valid business barrages to be pushed, and business intermediate state data that needs to be quickly read and written; at the same time, a snapshot storage mechanism is started; Storing saved data that needs to be permanently saved, accessed at low frequency, but requires high consistency in the database; the saved data includes user basic information, special barrage data needed for after-playback, and complete business flow records.

7. The method of claim 1, wherein, The master business node consumes business data from the distributed cache service according to business logic, and interacts with the database to complete persistent storage or reading; the business data is derived from a barrage production and consumption process, wherein the barrage data in the business data is distributed to different topics of a notification message queue according to room, and then stored in the distributed cache service after being processed by a barrage consumer, and the steps specifically include: When the master business node calculates the next state change instruction according to the business logic; the master business node sends the state change instruction to the synchronization service cluster; After receiving the state change instruction, the synchronization service cluster broadcasts in a full connection communication mode; wherein each synchronization service node receiving the instruction will synchronize the instruction to all server-side interactive video instances connected thereto without distinction, and all server-side interactive video instances connected thereto belong to different live rooms or different anchor camps.

8. A service end for bullet screen live broadcast interaction, characterized in that, The server-side of the barrage live interaction comprises one or more processors and a memory; the memory is coupled with the one or more processors, the memory is used to store computer program code, the computer program code comprises computer instructions, and the one or more processors invoke the computer instructions to enable the server-side of the barrage live interaction to perform the method of any one of claims 1-7.

9. A computer program product comprising instructions, characterized in that, When the computer program product runs on the server-side of the barrage live interaction, the server-side of the barrage live interaction performs the method of any one of claims 1-7.

10. A computer-readable storage medium comprising instructions, characterized in that, When the instruction runs on the server-side of the barrage live interaction, the server-side of the barrage live interaction performs the method of any one of claims 1-7.

Images