Method, apparatus, device and storage medium for allocating resource targets by live streaming room

Abstract

In the embodiments of the present application, a method, an apparatus, a device and a storage medium for allocating resource objects by a live streaming room are disclosed, which includes: obtaining synchronization data and local data corresponding to pre-defined resource objects in a target live streaming room by a master node of a service side, where the synchronization data is synchronously stored in a master node and a slave node, and includes a queue of waiting users who have applied to occupy the pre-defined resource objects but have not yet occupied them, the queue includes first user data of all waiting users, and the local data is stored in a master node and includes second user data of already invited users corresponding to the pre-defined resource objects, determining a target user according to the queue, and for the target user, matching the synchronization data with the local data, obtaining a current status of the target user, and determining whether to send an invitation to allocate the pre-defined resource object to the target user.

Description

[Technical field]

[0001] This application claims priority to a Chinese patent application with application number 202111483594.2 filed with the China Patent Office on December 7, 2021, the entire contents of which are incorporated herein by reference.

[0002] The embodiments of the present application relate to the technical field of live broadcasting, for example, to a method, an apparatus, a device and a storage medium for allocating resource targets by a live streaming room. [Background technology]

[0003] A live streaming room (also known as a live streaming room) is a virtual space in a live broadcast application (APP) product, and is the main gathering place for users. One of its core functions is that users can interact based on resource objects such as microphone positions in the live streaming room according to the terminal devices they use, and the microphone position can be understood as the position of a microphone in the room. Since many users can exist simultaneously in a live streaming room, the resource object belongs to a scarce resource, that is, when multiple people request to occupy a resource object in a live streaming room, a scene will occur in which multiple people simultaneously seize the same resource object. In order to avoid the problem of a high failure rate of requests to occupy a resource object due to such resource occupancy and a poor user experience, it is necessary to maintain many states (including resource object states and user states, etc.) on the user side (e.g., the user's mobile terminal) and the service end (background), for example, after a resource object is occupied by a user, the state of the resource object changes to ensure that multiple users do not occupy the same resource object. At the same time, live broadcast platforms are generally applied to microservice architecture, and state synchronization is required between master nodes and slave nodes, thereby ensuring high availability of the entire service.

[0004] In the related technology, a live streaming room generally has a caster installed, and the caster is a direct participant in state maintenance and state synchronization. Without the caster, the user cannot complete the occupation of the resource object. Thus, the caster side can perform many tasks and needs to constantly interact with the background, and thus needs to introduce a state machine to achieve the purpose of maintaining various states, which makes the caster side APP heavy and consumes a lot of energy, and when an abnormality occurs on the caster side, the entire business process cannot be carried out. Therefore, the resource object allocation method in the live streaming room of the related technology is not sufficient and needs to be improved. Summary of the Invention [Means for solving the problem]

[0005] In the embodiments of the present application, a method, apparatus, device and storage medium for allocating resource objects by a live streaming room are provided, which can optimize the resource object allocation method by a live streaming room in the related art and improve the allocation efficiency.

[0006] In a first aspect, the present embodiment comprises: An allocation method applied to a service-side master node, Obtaining synchronization data and local data corresponding to a preset resource object in a target live streaming room, where the synchronization data is synchronously stored between the master node and the slave node of the service side, and includes a queue of waiting users who have applied to occupy the preset resource object but have not yet occupy it, and the queue includes first user data of all waiting users; The first user data includes a first user identifier and a first queue joining time; The local data is stored in the master node and includes second user data of already-invited users corresponding to the preset resource object. The second user data includes a second user identifier, a most recent invitation time, and a second queue joining time recorded when the second user is most recently invited. And, determining a target user according to the front-back order of each waiting user in the queue; matching the synchronized data with the local data for the target user to obtain a current state of the target user; determining whether to send an invitation to allocate the preset resource object to the target user according to the current state; Including, A method for allocating resource targets by live streaming rooms is provided.

[0007] In a second aspect, the present embodiment comprises: An allocation device disposed in a master node on a service side, The method includes: a data acquisition module; a target user determination module; a status determination module; and an invitation module; The data acquisition module is configured to acquire synchronous data and local data corresponding to a preset resource object in a target live streaming room, where the synchronous data is synchronously stored between the master node and the slave node of the service side, and includes a queue of waiting users who have applied to occupy the preset resource object but have not yet occupy it, and the queue includes first user data of all waiting users; The first user data includes a first user identifier and a first queue joining time; The local data is stored in the master node and includes second user data of already-invited users corresponding to the preset resource object; The second user data includes a second user identifier, a most recent invitation time, and a second queue joining time recorded when the second user is most recently invited; The target user determination module is configured to determine a target user according to a front-back order of each waiting user in the queue; the state determination module is configured to match, for the target user, the synchronized data and the local data to obtain a current state of the target user; The invitation module is configured to determine whether to send an invitation to allocate the preset resource object to the target user according to the current state. An apparatus for allocating resource targets by live streaming room is provided.

[0008] In a third aspect, an embodiment of the present application provides a computer device including a memory, a processor, and a computer program stored in the memory and running on the processor, the computer device realizing a method for allocating resource targets by a live streaming room provided in the embodiment of the present application when the processor executes the computer program.

[0009] A fourth aspect, an embodiment of the present application, is a computer program product stored on a non-temporary A computer-readable storage medium, the computer program being configured to, when executed by a processor, realize a method for allocating resource targets by a live streaming room as provided in an embodiment of the present application; non-temporary A computer readable storage medium is provided. [Brief description of the drawings]

[0010] [Figure 1] FIG. 2 is a scene architecture diagram of an application scene to which the resource object allocation method by live streaming room provided in an embodiment of the present application is applied. [Diagram 2] FIG. 2 is a schematic diagram of a flow chart of a resource target allocation method by a live streaming room provided in an embodiment of the present application; [Diagram 3] FIG. 2 is a schematic diagram of a flow for accessing a microphone provided in an embodiment of the present application. [Figure 4] FIG. 2 is a schematic diagram of a flow chart of another live streaming room resource object allocation method provided in an embodiment of the present application; [Diagram 5]FIG. 2 is a structural block diagram of a resource object allocation device according to a live streaming room provided in an embodiment of the present application; [Figure 6] FIG. 2 is a structural block diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, the present application will be described in conjunction with the drawings and embodiments. It should be understood that the embodiments described herein are only used to describe the present application. For ease of description, the drawings only show parts related to the present application.

[0012] FIG. 1 is a scene architecture diagram of an application scenario in which a resource target allocation method according to a live streaming room provided in an embodiment of the present application is applied. Illustratively, referring to FIG. 1, in the application scenario, a service side corresponding to a live broadcast platform can include a master node 101, a first slave node 102, and a second slave node 103. It should be noted that the number of slave nodes may be more or less, and FIG. 1 is only a schematic description. A client (live broadcast APP) corresponding to the live broadcast platform is installed on a terminal device used by a user, and can communicate with at least one of the master node and the slave node. The master node 101, the first slave node 102, and the second slave node 103 synchronously store synchronous data, and the master node 101 also stores local data.

[0013] 2 is a schematic diagram of a flow of a method for allocating resource objects by a live streaming room provided in an embodiment of the present application, the method can be performed by a device for allocating resource objects by a live streaming room, where the device can be realized by software and / or hardware, and can be generally integrated into a computer device as a master node, such as a server. Here, the master node can be understood as a node whose current identity is a master node. As shown in FIG. 2, the method includes: Step 201: adopting a preset timing strategy to obtain synchronization data and local data corresponding to a preset resource object in a target live streaming room, where the synchronization data is synchronously stored between a master node and a slave node on a service side, and includes a queue of waiting users who have applied to occupy but have not occupy the preset resource object, where the queue includes first user data of all waiting users; and the local data is stored in the master node, and includes second user data of already-invited users corresponding to the preset resource object.

[0014] In the embodiment of the present application, the target live streaming room may be a live streaming room that currently needs to be allocated by the service side to a preset resource object, may be an unmanned operation type live streaming room, or may be a live streaming room that is set in a state where the user side does not need to determine the state of the allocation process. For example, there is no anchor in the target anchor room, that is, there is no anchor user in the current user in the target live streaming room; or, for example, there is an anchor in the target live streaming room, but the current setting of the target live streaming room is that the anchor does not have the authority to allocate the preset resource object, or the anchor is set up to automatically allocate the resource object preset by the service side instead of the anchor, thereby reducing the operation of the anchor.

[0015] Exemplarily, the type of the pre-defined resource object may relate to the type or supporting function of the target live streaming room. For example, the target live streaming room is a live streaming room in the form of voice communication, and the pre-defined resource object may be a microphone position, and the microphone position may be understood as the microphone position present in the room, and the number of microphone positions may be set according to actual needs. Also, for example, the target live streaming room supports a game function, and the pre-defined resource object may be a qualification to participate in a game, etc.

[0016] In the embodiment of the present application, the synchronization data can be understood as data synchronized between the master node and the slave node of the service side, and to a certain extent, ensures the consistency of the synchronization data stored in the master node and the slave node. The synchronization data can include a queue of waiting users who have already applied to occupy the pre-set resource object but have not yet done so, and the queue includes the first user data of all waiting users. Here, the waiting users can be understood as users who have already applied to occupy the pre-set resource object but are currently unable to occupy the pre-set resource object. The first user data can include an indicator used to indicate the identity of the user, which is described as a first user indicator, and can further include other related data, such as an application time or a time to join the queue (which can be described as a first queue joining time).

[0017] For example, when a first user in a target live streaming room wants to occupy a preset resource object, he / she can send an application to the service side through the live broadcasting app he / she uses, requesting to join the queue, and the node receiving the application can add the first user to the queue, generally to the end of the queue, for example, add the first user data of the first user to the queue according to the data storage order, and then synchronize the first user data of the first user to other nodes on the service side, ensuring the consistency of the synchronized data between nodes. Ensure that the queue is not lost when an abnormality occurs in the current master node and the master node and the slave node are switched.

[0018] For example, if a second user in a target live streaming room is already in queue, and the second user leaves the room, or the second user cancels the queue (for example, by triggering a control to cancel the application in the interface of the live streaming app, or by rejecting an invitation to allocate a pre-set resource target sent by the master node), the second user has already successfully occupied the pre-set resource target, the second user will be removed from the queue, and the changes in the queue caused by the removal operation can be synchronized with other nodes on the service side, to ensure the consistency of the synchronization data between nodes.

[0019] In the embodiment of the present application, the local data may be understood as data stored locally in the master node, for example, in the internal memory of the master node. The local data includes second user data of an already invited user corresponding to a pre-configured resource object. The already invited user may be understood as a user to whom an invitation to allocate a pre-configured resource object from the master node has already been sent. The second user data may include an identifier used to indicate the identity of the user, and is described herein as a second user identifier for ease of distinction from the first user data. Note that the user identifier is globally unique on the service side, and for the same user, the corresponding first user identifier and second user identifier are consistent. The second user data may further include other related data, such as the time of invitation (e.g., the time of the most recent invitation), the number of times of invitation, and the time of joining the queue recorded when invited (e.g., the second queue joining time recorded when invited most recently).

[0020] For example, after the master node sends an invitation to allocate a preset resource target to a third user in the target live streaming room, the master node stores the second user data corresponding to the third user locally, and the data is not synchronized between the master node and the slave node. Even if an abnormality occurs in the master node, if the master node and the slave node are switched, in an extreme case, the same user may be invited multiple times, but this problem does not have a large impact. The impact can be eliminated by processing the duplicate invitations received by the user side, for example, if two invitations are received consecutively, the new invitation can be ignored.

[0021] In the embodiment of the present application, queues are synchronized between the master node and the slave node, and local data is not synchronized, which reduces background load without causing expansion of synchronized data and an increase in the number of synchronizations, and automatically allocates pre-defined resource targets by comparing the synchronized data with local data.

[0022] For example, when a preset resource object allocation event is triggered, the synchronous data and the local data are acquired. As an option, a preset timing strategy is adopted to trigger the preset resource object allocation event. Here, the preset timing strategy can be set by a timer, for example, can be acquired once every preset time interval. The preset time interval can be set according to the actual situation, for example, 5 seconds.

[0023] As an option, the number of pre-defined resource targets in the target live streaming room is generally limited, and if there are free pre-defined resource targets, a timer can be started, and it can also be checked whether there are free pre-defined resource targets after the timer is triggered.

[0024] In step 202, a target user is determined according to the front-back position of each waiting user in the queue.

[0025] For example, the first user to enter the queue will be placed at the front of the queue, and in this case, the user currently at the head of the queue can be determined as the target user, i.e., the waiting user corresponding to the first user data at the front of the queue is determined as the target user.

[0026] In step 203, for the target user, the synchronized data is matched with the local data to obtain the current state of the target user.

[0027] For example, the current status of the target user may include not being invited after joining the queue (i.e., no invitation has been sent to the target user after the target user joined the queue) and being invited (i.e., an invitation has already been sent to the target user, but the target user has not yet succeeded in occupying the pre-set resource object), etc.

[0028] For example, when the first user data includes a first user identifier and the second user data includes a second user identifier, for the target user, it can be determined whether the local data includes a second user identifier that matches the first user identifier of the target user, and if so, the current state can be considered to be inviting, and if not, the current state can be considered to be not invited after joining the queue.

[0029] For example, when the first user data and the second user data each contain richer user-related information, the current state can be divided into more fine parts, thereby more accurately determining the current state of the target user (e.g., invitation timeout, rejoining the queue but not being invited, etc.).

[0030] In step 204, it is determined whether to send an invitation to allocate the pre-defined resource object to the target user according to the current state.

[0031] For example, if the current state is not invited after joining the queue, an invitation to allocate pre-set resource objects to the target user can be sent, and if the current state is inviting, sending an invitation to allocate pre-set resource objects to the target user can be prohibited, thereby avoiding the occurrence of repeated invitation situations and reducing unnecessary interaction.

[0032] The resource object allocation method for a live streaming room provided in the embodiment of the present application adopts the above technical solution, so that the service side can automatically realize reasonable allocation of resource objects in the live streaming room, without the need for manual allocation by the anchor, and the anchor's terminal does not need to maintain a lot of status data related to the resource objects, and does not need to perform a lot of interactive operations due to resource object allocation with the service side, thereby reducing the burden on the anchor's terminal, improving the allocation efficiency, and helping to improve the utilization rate of resource objects in the live streaming room and the activity of the live streaming room; and the solution does not need to introduce specialized components such as a data aggregation layer for data synchronization, does not increase the background burden, and ensures that the service side has relatively high performance.

[0033] In some embodiments, after sending an invitation to allocate a predetermined resource object to the target user side, the method may further include: if returning invitation confirmation information is received from the target user side, sending a confirmation request to the target user side; if the target user side receives a request according to a predetermined resource object occupancy protocol (e.g., a protocol for accessing a microphone) initiated by the confirmation request, processing the protocol request, and returning the protocol request processing result to the target user side, thereby completing the entire process of occupying the predetermined resource object.

[0034] 3 is a schematic diagram of a flow of accessing a microphone provided in an embodiment of the present application, in which the preset resource object is a microphone position as an example, and accessing a microphone can be understood as an operation of a user occupying a microphone position in a live streaming room. The background (service side) sends an invitation to a user to access a microphone, and the user (user side) checks the invitation. If the user fails to check the invitation, the flow ends. If the user successfully checks the invitation, the background continues to check the user, and after the user checks and initiates the protocol for accessing the microphone, the background processes the process of accessing the microphone, and returns the processing result to the user, and then the background can automatically trigger the next invitation flow.

[0035] As an option, the service side in the embodiments of the present application may be a microservice architecture, and the service used to initiate an invitation to allocate a pre-configured resource object and the service used to process the flow occupying the pre-configured resource object may be the same service or different services.

[0036] In some embodiments, the current state includes not being invited after joining the queue. For the target user, matching the synchronized data with the local data to obtain the current state of the target user includes determining that the current state of the target user is not invited after joining the queue if a corresponding target first user identifier in the synchronized data of the target user is not found in the local data. Determining whether to send an invitation to allocate the pre-configured resource object to the target user side according to the current state includes sending an invitation to allocate the pre-configured resource object to the target user side if it is determined that the current state of the target user is not invited after joining the queue. It can be seen that by matching the user identifier, it can be quickly determined whether the target user has already been invited, and if not invited, quickly sending an invitation to the target user can improve the utilization rate of the pre-configured resource object.

[0037] In some embodiments, the current state includes being invited. For the target user, matching the synchronization data with the local data to obtain the current state of the target user includes searching for a matching second user identifier in the local data by a corresponding target first user identifier in the synchronization data of the target user, and determining that the current state of the target user is being invited if a difference value between a current time and a most recent invited time corresponding to the searched second user identifier is within a preset time length range, and a second queue joining time corresponding to the searched second user identifier matches a first queue joining time corresponding to the target first user identifier. Determining whether to send an invitation to allocate the preset resource object to the target user side according to the current state includes prohibiting sending an invitation to allocate the preset resource object to the target user side when it is determined that the current state of the target user is being invited. It can be understood that it is possible to more accurately identify whether the target user is in the process of occupying a preset resource object. As described above, after sending an invitation to the target user, a complex interactive process such as two confirmations may be performed before the target user successfully occupies the preset resource object. During this process, the duration of the process may not be determined due to factors such as an unstable network state. Therefore, by setting a preset time length range, it is possible to avoid the target user having to wait a long time until the entire process of successfully occupying the preset resource object is completed, thereby improving the utilization rate of the preset resource object.

[0038] For example, finding a second user identifier of the target user in the local data indicates that an invitation has already been sent to the target user, the difference between the current time and the time of the previous invitation does not exceed a preset time length range indicates that the target user is likely to be in the process of normal processing flow, and the queue joining time of the target user does not change indicates that the target user is in the process of waiting, the previous invitation is still valid, and there is no need to send an invitation again.

[0039] In some embodiments, the current state includes not being invited after rejoining the queue. For the target user, matching the synchronization data with the local data to obtain the current state of the target user includes searching for a matching second user identifier in the local data by a corresponding target first user identifier in the synchronization data of the target user, and determining that the current state of the target user is a state of not being invited after rejoining the queue if a difference value between a current time and a most recent invited time corresponding to the searched second user identifier is within a preset time length range but does not match the second queue joining time corresponding to the searched second user identifier and the first queue joining time corresponding to the target first user identifier. Determining whether to send an invitation to allocate the preset resource object to the target user side according to the current state includes sending an invitation to allocate the preset resource object to the target user side if it is determined that the current state of the target user is a state of not being invited after rejoining the queue. It can be seen that the situation in which the target user rejoins the queue within a short period of time can be accurately identified, and the current state is erroneously determined to be inviting, thereby avoiding missing an invitation.

[0040] For example, within the time interval range in which the master node acquires the synchronization data and the local data every two times, the first queue joining time is dynamically synchronized and updated between the master node and the slave node, and the second queue joining time is the queue joining time recorded when the user is invited, and if the user rejoins the queue after being invited, the first queue joining time changes but the second queue joining time does not change, and by comparing the first queue joining time with the second queue joining time, the user can confirm whether to continue waiting for the occupancy process of the resource object preset within the time interval range or to leave the queue and rejoin. When rejoining the user queue, it is necessary to indicate that the previous invitation has already been discarded and to send a new invitation to the user.

[0041] In some embodiments, the current state includes an invitation timeout. For the target user, matching the synchronization data with the local data to obtain the current state of the target user includes: searching for a matching second user identifier in the local data by a corresponding target first user identifier in the synchronization data of the target user, and determining whether a second queue joining time corresponding to the searched second user identifier matches a first queue joining time corresponding to the target first user identifier when a difference value between a current time and a most recent invitation time corresponding to the searched second user identifier exceeds a preset time length range; and determining that the current state of the target user is an invitation timeout when the second queue joining time corresponding to the searched second user identifier matches a first queue joining time corresponding to the target first user identifier. Here, determining whether to send an invitation to allocate the preset resource object to the target user side according to the current state includes prohibiting sending an invitation to allocate the preset resource object to the target user side and deleting the first user data corresponding to the target user from the queue when it is determined that the current state of the target user is an invitation timeout. It can be seen that it is possible to accurately identify users who have already been invited but have not been successful in occupying the pre-set resource objects for a long time, thereby securing opportunities for other users and avoiding the waste of free pre-set resource objects.

[0042] For example, finding a second user identifier of the target user in the local data indicates that an invitation has already been sent to the target user; the difference between the current time and the time of the last invitation has exceeded a preset time length range, indicating that the target user is likely in a bad network condition and cannot occupy the preset resource object; and the queue joining time recorded when the target user was most recently invited is consistent with the latest queue joining time, indicating that the target user has been in the process of waiting and there is no situation to rejoin the queue, so as to prohibit sending an invitation and remove the target user from the queue to avoid being determined to be the target user again.

[0043] In some embodiments, after determining whether the second queue joining time corresponding to the searched second user identifier is consistent with the first queue joining time corresponding to the target first user identifier, the method further includes determining that the current state of the target user is a state of not being invited after rejoining the queue if the second queue joining time corresponding to the searched second user identifier is not consistent with the first queue joining time corresponding to the target first user identifier. Determining whether to send an invitation to allocate the pre-configured resource object to the target user side according to the current state includes sending an invitation to allocate the pre-configured resource object to the target user side if it is determined that the current state of the target user is a state of not being invited after rejoining the queue. It indicates that the target user cannot successfully occupy the pre-configured resource object for a relatively long time, but the target user rejoins the queue, and the situation such as a network abnormality may be alleviated, and this process may be difficult for the target user to perceive, and more intuitively, the target user may feel that he has been waiting for a relatively long time after confirming that the pre-configured resource object is occupied, and it can be understood that the invitation is sent again to the target user to avoid confusion of the target user, and a chance for the target user to try again can be given.

[0044] In some embodiments, when it is determined that the current state of the target user is an uninvited state after joining the queue, sending an invitation to the target user to allocate the pre-configured resource object includes sending an invitation to the target user to allocate the pre-configured resource object based on a determination result that the target second user identifier in the local data does not match the first user identifier in the synchronization data when it is determined that the current state of the target user is an uninvited state after joining the queue. It can be understood that the user corresponding to the target second user identifier in the local data is a user to be invited recently (described as a fourth user), and the absence of the fourth user in the queue indicates that it has already succeeded in occupying one pre-configured resource object or has already left, and at this time, an invitation can be sent to the target user. The still-existence of the fourth user in the queue indicates that the fourth user may re-apply to join the queue in a short time after leaving the queue, and the previous invitation qualification of the fourth user can be suspended, and the target user is temporarily not invited, and the fourth user is re-determined as the target user after waiting for the next timer trigger time.

[0045] In some embodiments, when it is determined that the current state of the target user is a state of not being invited after joining the queue, sending an invitation to the target user side to allocate the pre-set resource object includes: when it is determined that the current state of the target user is a state of not being invited after joining the queue, searching for a matching first user identifier in the synchronization data based on a target second user identifier existing in the local data, but when the first queue joining time corresponding to the searched first user identifier and the second queue joining time corresponding to the target second user identifier do not match, sending an invitation to the target user side to allocate the pre-set resource object. As described above, it can be understood that if the fourth user is still in the queue, it can be checked whether the fourth user's queue joining time has changed; if the fourth user's queue joining time has changed, it indicates that the fourth user will rejoin the queue and an invitation is sent to the target user; if the fourth user's queue joining time does not change, it indicates that there is a problem in the target user determination stage, or that the fourth user has been erroneously removed from the queue and then failed to occupy the pre-set resource object, thereby causing the fourth user to be put back into the queue (e.g., placed at the top); at this time, the target user can be temporarily not invited, and the fourth user can be re-determined as the target user by waiting for the next timer trigger time.

[0046] FIG. 4 is a schematic flow diagram of another method for allocating a resource object according to a live streaming room provided in an embodiment of the present application, which is modified on the basis of the above-mentioned alternative embodiments. For convenience of explanation, the preset resource object is taken as an example of a microphone. The method includes the following steps: Step 401 includes detecting that a timer of a microphone invitation event in a target live streaming room is triggered.

[0047] For example, the timer can be configured according to actual business needs, for example, triggered once every 5 seconds. The master node can constantly scan the queue for synchronous data by the timer and determine the user status by comparing the synchronous data with local data.

[0048] In step 402, synchronous data and local data corresponding to microphone positions in a target live streaming room are obtained.

[0049] The synchronous data is synchronously stored between the master node and the slave node on the service side, and includes a queue of waiting users who have applied to occupy a microphone position but have not yet occupied it, and the queue includes first user data of all waiting users, and the first user data includes a first user identifier and a first queue joining time. The local data is stored in the master node, and includes second user data of already invited users corresponding to the microphone positions, and the second user data includes a second user identifier, a most recent invitation time, and a second queue joining time recorded when most recently invited.

[0050] In step 403, it is determined whether the queue is empty, and in response to the determination result that the queue is not empty, a target user is determined according to the queue, and step 404 is executed; in response to the determination result that the queue is empty, it goes back and executes step 401.

[0051] For example, if the queue is empty, the target user cannot be determined and the result is a failure; if the queue is not empty, the target user is determined based on the front-to-back order of each waiting user in the queue, for example, the user corresponding to the first user data at the top of the queue is determined as the target user.

[0052] For example, assume that user A, user B and user C sequentially send requests to access the microphone. The queue includes first queue joining times Ta1, Tb1 and Tc1 corresponding to first user markers a, b and c corresponding to user A, user B and user C, respectively, and since user A is first in line, the current target user is user A.

[0053] In step 404, it is determined whether or not a vacant microphone position exists. If a vacant microphone position exists, step 405 is executed; if not, the process returns to step 401 and the vacant microphone position exists.

[0054] In step 405, it is determined whether the target user is the first invitee; if the target user is the first invitee, execute step 412; if not, execute step 406;

[0055] For example, the first invitation is relative to the target live streaming room, for example, the first invitation of a user to access a microphone after the target live streaming room is established or opened at this time is regarded as the first invitation.

[0056] For example, assuming that an invitation to access the microphone is initiated, as in the above example, if user A is the first target user, since it is the first invitation, it can directly execute step 412, send an invitation to access the microphone to user A, and update local data, i.e., store in the internal memory of the master node the second user identifier a corresponding to user A, the most recent invitation time Ta, and the second queue joining time Ta2 recorded when most recently invited.

[0057] In step 406, it is determined whether the difference between the current time and the most recent invitation time in the local data is within a preset time length range. If it is within the preset time length range, execute step 407; if not, execute step 410.

[0058] Exemplarily, when the local data includes a plurality of sets of second user data, the most recent invitation time among them from the current time may be used to calculate the difference value.

[0059] For example, assume that the preset time length range is less than or equal to 20 seconds, that is, determine whether the current time has already exceeded 20 seconds since the most recent invitation to access the microphone was sent.

[0060] In step 407, it is determined whether the target user and the previous invited user in the local data match, and if they match, execute step 408; if not, execute step 409.

[0061] For example, the target user's corresponding target first user identifier in the sync data is used to search for a matching second user identifier in the local data, and if so, it is deemed that an invitation has already been sent to the target user, and step 408 is executed for further determination. If not, the target user is deemed to be a new user waiting for an invitation.

[0062] In step 408, determine whether the first queue joining time and the second queue joining time corresponding to the target user are consistent; if they are consistent, go back and execute step 401; if not, execute step 412.

[0063] In step 409, it is determined whether the previous invited user leaves the queue or whether the first queue joining time and the second queue joining time corresponding to the previous invited user are consistent with each other, and if so, execute step 412; if not, go back and execute step 401.

[0064] In step 410, it is determined whether the time length that the target user has been in the queue exceeds a preset time length range, and if so, execute step 411; if not, execute step 412.

[0065] In step 411, if it is determined that the current state of the target user is an invitation timeout, prohibit sending an invitation to allocate a microphone position to the target user, and remove the first user data corresponding to the target user from the queue.

[0066] In step 412, an invitation to allocate a microphone position is sent to the target user.

[0067] In addition, the execution order of each of the above steps can be adjusted according to actual needs. For example, execute step 404 and then execute step 403, that is, determine first whether there is an available microphone position, and if there is an available microphone position, determine the target user again.

[0068] For example, referring to the above steps, if user A is the first invited user and successfully accesses the microphone, the first user data of user A can be deleted from the queue. In an embodiment, after sending an invitation to user A to access the microphone, if the first user data of user A still exists in the queue at the next timer trigger time, i.e., 5 seconds later, still determine user A as the target user, and continue to determine the current status of user A to determine whether it is necessary to send an invitation to user A to access the microphone. At this time, the second user data corresponding to user A already exists in the local data, and the difference between the current time and Ta (for example, it can be regarded as approximately 5 seconds) is calculated. If it is within the preset time length range and matches the previous invited user, it can be continuously judged whether Ta1 and Ta2 are consistent. If they are consistent, it indicates that user A does not leave the queue, so it can wait for the next timer trigger and there is no need to send an invitation to A; if they are not consistent, it indicates that user A leaves the queue and re-enters within two timer trigger intervals (for example, A goes offline due to network reasons and then goes online and then re-applies to access the microphone, and if users B and C have already left before user A re-applies to access the microphone, A can be determined as the current target user), so it is necessary to send an invitation to user A. If user A is unsuccessful in accessing the microphone for a long time, he / she may remain in the queue for a long time, and after triggering the timer multiple times, the difference value between the current time and Ta may be greater than 20 seconds. At this time, it is determined whether the time length that user A remains in the queue is also greater than 20 seconds. If it is, it is considered as an invitation timeout and it is removed from the queue, providing the user behind with a chance to access the microphone. If the time length that user A remains in the queue is less than 20 seconds, it indicates that user A is in a state to rejoin the queue, and at this time, an invitation can be sent to user A again.

[0069] For example, after the timer is triggered, assuming that the determined target user is user B and this is not the first invitation, it can be continuously determined whether the current time exceeds 20 seconds from the previous invitation time, if not, it can be continuously determined that user B is different from the previous invited user A, at this time it can be determined whether user A has indeed already left the queue, if so, send an invitation to user B, if user A is still in the queue, it can be continuously determined whether user A's Ta1 and Ta2 are consistent, if they are not consistent, it can be determined that user A will re-enter the queue, and an invitation can be sent to user B, if they are consistent, temporarily not send the invitation to user B, wait for the next timer to be triggered, and re-determine the target user.

[0070] In the embodiment of the present application, the resource object allocation method for a live streaming room is provided by applying for microphone access through the way that a user applies to join a queue, and the master node on the service side automatically completes the microphone access; that is, after the user joins the queue, the user waits for the microphone access, and finally completes the microphone access. The whole process does not require manual intervention, and reduces the burden on the anchor side. The method can be applied to business scenarios including rooms without anchors and other unmanned work rooms. And the service side can be a microservice architecture. By adopting the above solution, there is no need to introduce components such as a data aggregation layer, and only the internal memory and limited synchronization mechanism in the background of the microservice architecture can solve the problem of large amount of state changes and data synchronization, without incurring the expansion of synchronization data of the master node and the slave node, and without increasing the burden on the background, ensuring that the service side has relatively high performance; at the same time, the background is responsible for all state maintenance and synchronization, and releases the mobile terminal, reducing the business flow borne by the mobile terminal, and making the APP lighter, so that the mobile terminal can participate in more complex business, and improving the performance of the entire live broadcast system.

[0071] 5 is a structural block diagram of a resource object allocation device according to a live streaming room provided in an embodiment of the present application, the device is disposed in a master node of a service side, can be realized by software and / or hardware, can be generally integrated in a computer device, and can perform resource object allocation by executing a resource object allocation method according to a live streaming room. As shown in FIG. 5, the device includes a data acquisition module 501, a target user determination module 502, a status determination module 503 and an invitation module 504.

[0072] The data acquisition module 501 is configured to acquire synchronization data and local data corresponding to a pre-configured resource object in a target live streaming room, where the synchronization data is synchronously stored between the master node and the slave node on the service side, and includes a queue of waiting users who have applied to occupy the pre-configured resource object but have not yet occupy it, and the queue includes first user data of all waiting users; and the local data is stored in the master node, and includes second user data of already-invited users corresponding to the pre-configured resource object.

[0073] The target user determination module 502 is configured to determine a target user according to the front-back order of each waiting user in the queue.

[0074] A status determination module 503 is configured to match the synchronized data and the local data for the target user to obtain a current status of the target user.

[0075] The invitation module 504 is configured to determine whether to send an invitation to allocate the preset resource target to the target user according to the current state.

[0076] In the embodiment of the present application, a computer device is provided, which can integrate the resource object allocation device according to the live streaming room provided in the embodiment of the present application. Figure 6 is a structural block diagram of the computer device provided in the embodiment of the present application. The computer device 600 includes a memory 601, a processor 602, and a computer program stored in the memory 601 and operable on the processor 602, and when the processor 602 executes the computer program, the method for allocating resource object according to the live streaming room provided in the embodiment of the present application is realized.

[0077] Embodiments of the present application include computer executable instructions. Non-transitory computer readable A storage medium is also provided, the computer executable instructions being used, when executed by a computer processor, to perform the method for allocating resource targets by a live streaming room as provided in the embodiments of the present application.

[0078] The resource object allocation apparatus, device and storage medium provided in the above embodiments can execute the resource object allocation method according to a live streaming room provided in any embodiment of the present application, and have modules that perform the corresponding functions and beneficial effects of the method. For technical details not described in detail in the above embodiments, please refer to the resource object allocation method according to a live streaming room provided in any embodiment of the present application. [Explanation of symbols]

[0079] 101 Masternodes 102 First slave node 103 Second slave node 501 Data Acquisition Module 502 Target User Determination Module 503 State Decision Module 504 Invitation Module 600 Computer Devices 601 Memory 602 Processor

Claims

1. An allocation method applied to a service-side master node, Obtain synchronization data and local data corresponding to a pre-defined resource object in a target live streaming room, where the synchronization data is synchronously stored between the master node and the slave node of the service side, and includes a queue of waiting users who have applied to occupy the pre-defined resource object but have not yet occupy it, the queue including first user data of all waiting users, the first user data including a first user identifier and a first queue joining time; the local data is stored in the master node, and includes second user data of already invited users corresponding to the pre-defined resource object, the second user data including a second user identifier, a most recent invite time, and a second queue joining time recorded when most recently invited; determining a target user according to the front-back order of each waiting user in the queue; matching the synchronized data with the local data for the target user to obtain a current state of the target user; determining whether to send an invitation to allocate the preset resource object to the target user according to the current state; Including, How resource targets are allocated by live streaming rooms.

2. Matching the synchronized data with the local data for the target user to obtain a current state of the target user includes: determining whether there is a second user identifier in the local data that matches the target first user identifier according to a corresponding target first user identifier in the synchronized data for the target user; in response to determining that there is no second user identifier in the local data that matches the target first user identifier, determining that a current state of the target user is an uninvited state after joining a queue; Including, determining whether to send an invitation to allocate the preset resource object to the target user according to the current state; In response to determining that a current state of the target user is an uninvited state after joining a queue, sending an invitation to the target user to allocate the predetermined resource object. The method of claim 1.

3. Matching the synchronized data with the local data for the target user to obtain a current state of the target user includes: determining whether there is a second user identifier in the local data that matches the target first user identifier according to a corresponding target first user identifier in the synchronized data for the target user; In response to a determination result that a second user identifier that matches the target first user identifier exists in the local data and a difference value between a current time and a most recent invitation time corresponding to the searched second user identifier is within a preset time length range, determining whether a second queue joining time corresponding to the searched second user identifier matches a first queue joining time corresponding to the target first user identifier; In response to a determination result that the second queue joining time corresponding to the found second user identifier matches the first queue joining time corresponding to the target first user identifier, determining that the current state of the target user is invited; Including, determining whether to send an invitation to allocate the preset resource object to the target user according to the current state; In response to determining that a current state of the target user is inviting, prohibiting sending an invitation to the target user to allocate the predetermined resource object. The method of claim 1.

4. Matching the synchronized data with the local data for the target user to obtain a current state of the target user includes: determining whether there is a second user identifier in the local data that matches the target first user identifier according to a corresponding target first user identifier in the synchronized data for the target user; In response to a determination result that a second user identifier that matches the target first user identifier exists in the local data and a difference value between a current time and a most recent invitation time corresponding to the searched second user identifier is within a preset time length range, determining whether a second queue joining time corresponding to the searched second user identifier matches a first queue joining time corresponding to the target first user identifier; In response to a determination result that the second queue joining time corresponding to the found second user identifier does not match the first queue joining time corresponding to the target first user identifier, determining that the current state of the target user is a state of not being invited after rejoining the queue; Including, determining whether to send an invitation to allocate the preset resource object to the target user according to the current state; In response to determining that the current status of the target user is an uninvited status after rejoining the queue, sending an invitation to the target user to allocate the preset resource object. The method of claim 1.

5. Matching the synchronized data with the local data for the target user to obtain a current state of the target user includes: determining whether there is a second user identifier in the local data that matches the target first user identifier according to a corresponding target first user identifier in the synchronized data for the target user; in response to a determination result that a second user identifier that matches the target first user identifier exists in the local data and a difference value between a current time and a most recent invitation time corresponding to the searched second user identifier exceeds a preset time length range, determining whether a second queue joining time corresponding to the searched second user identifier matches a first queue joining time corresponding to the target first user identifier; In response to a determination result that the second queue joining time corresponding to the found second user identifier matches the first queue joining time corresponding to the target first user identifier, determining that the current state of the target user is an invitation timeout; Including, determining whether to send an invitation to allocate the preset resource object to the target user according to the current state; In response to determining that a current state of the target user is an invitation timeout, prohibiting sending an invitation to the target user for allocating the predetermined resource object, and deleting first user data corresponding to the target user from the queue. The method of claim 1.

6. After determining whether the second matrix addition time corresponding to the found second user identifier matches the first matrix addition time corresponding to the target first user identifier, the method includes: and determining, in response to a determination result that the second queue joining time corresponding to the found second user identifier does not match the first queue joining time corresponding to the target first user identifier, that the current state of the target user is an uninvited state after rejoining the queue; determining whether to send an invitation to allocate the preset resource object to the target user according to the current state; In response to determining that the current status of the target user is an uninvited status after rejoining the queue, sending an invitation to the target user to allocate the preset resource object. The method according to claim 5.

7. An allocation device disposed in a master node on a service side, The method includes: a data acquisition module; a target user determination module; a status determination module; and an invitation module; The data acquisition module is configured to acquire synchronization data and local data corresponding to a pre-defined resource object in a target live streaming room, where the synchronization data is synchronously stored between the master node and the slave node of the service side, and includes a queue of waiting users who have applied to occupy the pre-defined resource object but have not yet occupy it, and the queue includes first user data of all waiting users, and the first user data includes a first user identifier and a first queue joining time; the local data is stored in the master node, and includes second user data of already invited users corresponding to the pre-defined resource object, and the second user data includes a second user identifier, a most recent invitation time, and a second queue joining time recorded when most recently invited; The target user determination module is configured to determine a target user according to a front-back order of each waiting user in the queue; the state determination module is configured to match, for the target user, the synchronized data and the local data to obtain a current state of the target user; The invitation module is configured to determine whether to send an invitation to allocate the preset resource object to the target user according to the current state. Resource target allocation device by live streaming room.

8. A computer program comprising a memory, a processor, and a computer program stored in the memory and running on the processor, The processor, when executing the computer program, implements the method according to any one of claims 1 to 6. Allocation of resources target computer devices by live streaming room.

9. A non-transitory computer-readable storage medium on which a computer program is stored, The computer program, when executed by a processor, causes the method according to any one of claims 1 to 6 to be implemented. A non-transitory computer-readable storage medium.

Images