State processing method and device of interactive task, electronic equipment and storage medium

Abstract

The present disclosure relates to a state processing method and device of an interactive task, an electronic device and a storage medium. The method comprises: in response to an invitation request for an interactive task sent by a first account for a second account, creating a task entity in a task entity table; receiving an acceptance of the invitation request sent by the second account, and transferring the state of the task entity to an acceptance state; calling a timing task to read the task entity table to obtain the task entity in the acceptance state; when it is determined through the timing task that the dependent resources of the interactive task are ready, the state of the task entity is transferred to a proceeding state; calling the timing task to read the task entity table to obtain the task entity in the proceeding state; and when the interactive task meets an end condition, the state of the task entity is transferred to an end state. According to the scheme of the present disclosure, by deploying an independent timing task, the state transition in the interactive process is converged in the timing task, the maintainability of the project is improved, and the IO pressure is reduced.

Description

Technical Field

[0001] This disclosure relates to the field of Internet technology, and in particular to a method, apparatus, electronic device, computer-readable storage medium, and computer program product for handling the state of interactive tasks. Background Technology

[0002] Currently, various live streaming platforms achieve strong social interaction by providing interactive tasks that require multiple players to team up or compete, such as multiplayer team-based PvP (combat) games. Interactive tasks in live streaming scenarios involve multiple state transitions. For example, a first account might invite a second account to participate in an interactive task. If the second account accepts the invitation, the task state transitions to "Accept Invitation"; if the second account declines, the task state transitions to "Decline Invitation." If the second account accepts the invitation, the interactive task between the first and second accounts then sequentially transitions to the interaction stage, resource distribution stage, and so on.

[0003] In related technologies, these state transitions can be handled by combining API (Application Programming Interface) calls with countdowns. However, in live streaming scenarios, interactive tasks are a mechanism where user experience is strongly correlated with state transitions. Distributing state transitions across various APIs can easily increase the complexity of engineering maintenance. Summary of the Invention

[0004] This disclosure provides a method, apparatus, electronic device, computer-readable storage medium, and computer program product for handling the state of interactive tasks, to at least solve the problem of high complexity in the engineering maintenance of the state handling mechanism for interactive tasks in related technologies. The technical solution of this disclosure is as follows:

[0005] According to a first aspect of the present disclosure, a method for handling the state of an interactive task is provided, comprising:

[0006] In response to the invitation request sent by the first account for an interactive task for the second account, a task entity corresponding to the interactive task is created in the task entity table;

[0007] Upon receiving the invitation request sent by the second account, the status of the task entity is changed to the accept status;

[0008] The scheduled task is invoked to read the task entity table and obtain the task entity in the accept state;

[0009] In response to determining that the dependent resources of the interactive task are ready through the timed task, the state of the task entity in the accept state is changed to the in progress state.

[0010] The scheduled task is invoked to read the task entity table and obtain the task entity that is in progress.

[0011] In response to the interaction task meeting the termination condition, the state of the task entity in the in-process state is changed to the terminated state.

[0012] In one embodiment, before transitioning the state of the task entity in the in-process state to the completed state, the method further includes:

[0013] The state of the task entity in the in-process state is transitioned to a pre-end state, which is used to indicate the cleanup of the associated data of the interactive task.

[0014] The scheduled task determines that the associated data has been cleaned up.

[0015] In one embodiment, after the state of the task entity in the accept state is transitioned to the proceeding state, the method further includes:

[0016] The scheduled task is invoked to read the task entity table to obtain the task entity in the early termination state. The early termination state is obtained in response to an early termination request sent by the first account or the second account.

[0017] The state of the task entity is transitioned to the pre-termination state.

[0018] In one embodiment, the step of transitioning the state of the task entity in the in-process state to the terminated state in response to the interaction task meeting the termination condition includes:

[0019] The scheduled task records key time nodes of the interaction task in the task entity table. The key time nodes are used to determine the stage of the interaction task. The stage includes a first stage and a second stage. The first stage is the stage in which the first account and the second account interact. The second stage is the remaining stage after the interaction between the first account and the second account ends.

[0020] When the interaction task is determined to be in the second stage based on the key time node, it is determined that the interaction task meets the termination condition, and the state of the task entity in the in-process state is changed to the terminated state.

[0021] In one embodiment, the stage further includes an intermediate stage between the first stage and the second stage; the method further includes:

[0022] The scheduled task is invoked to read the task entity table to obtain the task entity in the intermediate stage;

[0023] Acquire and cache the first virtual resource obtained by the first account performing the interactive task, and the second virtual resource obtained by the second account performing the interactive task;

[0024] The first virtual resource and the second virtual resource are sent to the live streaming rooms corresponding to the first account and the second account respectively via a long connection.

[0025] In one embodiment, the method further includes:

[0026] The task entity in the first stage is obtained by reading the task entity table through the scheduled task;

[0027] For the task entity in the first stage, the third virtual resource obtained by the first account in executing the interactive task and the fourth virtual resource obtained by the second account in executing the interactive task are continuously obtained through the timed task.

[0028] The third and fourth virtual resources are continuously sent to the live streaming rooms corresponding to the first and second accounts using a long connection.

[0029] In one embodiment, the step of calling the scheduled task to read the task entity table and obtain the task entity in the accept state includes:

[0030] The scheduled task is invoked to read the task entity table page by page to obtain the task entity to be processed, and the task entity to be processed is stored in the buffer.

[0031] The task entity in the accept state is obtained from the buffer.

[0032] In one embodiment, the method further includes:

[0033] The query interface receives query requests sent by the first account and / or the second account. The query request is initiated by the client of the first account or the second account when it detects an abnormal status.

[0034] The query interface is invoked to retrieve the task status of the task entity from the task entity table, and the task status is returned to the first account and / or the second account.

[0035] In one embodiment, the step of responding to the invitation request for an interactive task sent by the first account for the second account, and creating a task entity corresponding to the interactive task in the task entity table, includes:

[0036] In response to the invitation request sent by the first account for an interactive task targeting the second account, both the first account and the second account are locked.

[0037] After successfully locking the first account and the second account, if it is determined that there is no task identifier corresponding to the first account and the second account in the cached mapping relationship between account and task identifier, a task entity corresponding to the interactive task is created in the task entity table.

[0038] In one embodiment, locking the first account and the second account includes:

[0039] The locking order is determined based on the numerical values ​​of the first account and the second account, and the first account and the second account are locked sequentially according to the locking order.

[0040] In one embodiment, the method further includes:

[0041] If it is determined that locking the first account and / or the second account has failed, a message indicating that interaction is in progress will be returned to the first account and the second account, and the held lock will be released.

[0042] In one embodiment, after creating the task entity corresponding to the interactive task in the task entity table, the method further includes:

[0043] The mapping relationship between the first account, the second account, and the task identifier of the interactive task is cached.

[0044] In one embodiment, receiving the acceptance invitation request sent by the second account and transitioning the status of the task entity to an acceptance status includes:

[0045] Upon receiving the invitation request sent by the second account, the database lock mechanism is used to change the state of the task entity to the accept state.

[0046] According to a second aspect of the present disclosure, an apparatus for processing the state of an interactive task is provided, comprising:

[0047] The entity creation module is configured to execute an invitation request sent by the first account for an interactive task targeting the second account, and create a task entity corresponding to the interactive task in the task entity table;

[0048] The state transition module is configured to receive the invitation request sent by the second account and transition the state of the task entity to the acceptance state;

[0049] The task invocation module is configured to execute a scheduled task to read the task entity table and obtain the task entity in the accept state;

[0050] The state transition module is further configured to, in response to determining through the timed task that the dependent resources of the interactive task are ready, transition the state of the task entity in the accepting state to the proceeding state.

[0051] The task invocation module is also configured to execute the scheduled task to read the task entity table and obtain the task entity in the in-process state;

[0052] The state transition module is further configured to, in response to the interaction task meeting the termination condition, transition the state of the task entity in the in-process state to the terminated state.

[0053] In one embodiment, the state transition module is further configured to transition the state of the task entity in the in progress state to a pre-end state, the pre-end state being used to indicate the clearing of associated data of the interactive task;

[0054] The device further includes a data cleaning module, configured to execute a timed task to determine that the associated data has been cleaned up.

[0055] In one embodiment, the task invocation module is further configured to execute the invocation of the timed task to read the task entity table to obtain the task entity in the early termination state, wherein the early termination state is obtained in response to an early termination request sent by the first account or the second account;

[0056] The state transition module is also configured to transition the state of the task entity to the pre-end state.

[0057] In one embodiment, the state transition module is configured to execute the timed task to record key time nodes of the interaction task in the task entity table. The key time nodes are used to determine the stage of the interaction task. The stage includes a first stage and a second stage. The first stage is the stage in which the first account and the second account interact. The second stage is the remaining stage after the interaction between the first account and the second account ends.

[0058] When the interaction task is determined to be in the second stage based on the key time node, it is determined that the interaction task meets the termination condition, and the state of the task entity in the in-process state is changed to the terminated state.

[0059] In one embodiment, the stage further includes an intermediate stage between the first stage and the second stage; the task invocation module is further configured to execute an invocation of the timed task to read the task entity table to obtain the task entity in the intermediate stage;

[0060] The device further includes:

[0061] The first acquisition module is configured to acquire and cache the first virtual resource obtained by the first account performing the interactive task, and the second virtual resource obtained by the second account performing the interactive task;

[0062] The first sending module is configured to send the first virtual resource and the second virtual resource to the live streaming rooms corresponding to the first account and the second account respectively via a long connection.

[0063] In one embodiment, the task invocation module is further configured to execute the task entity in the first stage by reading the task entity table through the timed task;

[0064] The device further includes:

[0065] The second acquisition module is configured to continuously acquire, through the timed task, the third virtual resource obtained by the first account in performing the interactive task and the fourth virtual resource obtained by the second account in performing the interactive task for the task entity in the first stage.

[0066] The second sending module is configured to continuously send the third and fourth virtual resources to the live streaming rooms corresponding to the first and second accounts via a long connection.

[0067] In one embodiment, the task invocation module includes:

[0068] The paging reading unit is configured to execute the scheduled task to read the task entity table in pages, obtain the task entity to be processed, and store the task entity to be processed in the buffer.

[0069] The acquisition unit is configured to retrieve the task entity in the accepting state from the buffer.

[0070] In one embodiment, the device further includes:

[0071] The receiving module is configured to receive query requests sent by the first account and / or the second account through a query interface. The query request is initiated by the client of the first account or the second account when it detects an abnormal status.

[0072] The query module is configured to call the query interface to retrieve the task status of the task entity from the task entity table, and return the task status to the first account and / or the second account.

[0073] In one embodiment, the entity creation module includes:

[0074] The locking unit is configured to lock the first account and the second account in response to an invitation request sent by the first account for an interactive task targeting the second account.

[0075] The entity creation unit is configured to, after successfully locking the first account and the second account, if it is determined that there is no task identifier corresponding to the first account and the second account in the cached mapping relationship between account and task identifier, create a task entity corresponding to the interactive task in the task entity table.

[0076] In one embodiment, the locking unit is configured to determine the locking order based on the numerical values ​​of the first account and the second account, and lock the first account and the second account sequentially according to the locking order.

[0077] In one embodiment, the device further includes:

[0078] The prompt module is configured to, if it is determined that locking the first account and / or the second account has failed, return a prompt message indicating that interaction is in progress to the first account and the second account, and release the lock already held.

[0079] In one embodiment, the device further includes:

[0080] The caching module is configured to cache the mapping relationship between the first account, the second account, and the task identifier of the interactive task.

[0081] In one embodiment, the state transition module is configured to receive an acceptance invitation request sent by the second account and use a database lock mechanism to transition the state of the task entity to an acceptance state.

[0082] According to a third aspect of the present disclosure, an electronic device is provided, comprising:

[0083] processor;

[0084] Memory used to store the processor's executable instructions;

[0085] The processor is configured to execute the instructions to implement the state processing method for the interactive task as described in any of the first aspects above.

[0086] According to a second aspect of the present disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform a state processing method for an interactive task as described in any of the first aspects above.

[0087] According to a second aspect of the present disclosure, a computer program product is provided, the computer program product including instructions that, when executed by a processor of an electronic device, enable the electronic device to perform a state processing method for an interactive task as described in any of the first aspects above.

[0088] The technical solutions provided by the embodiments of this disclosure have at least the following beneficial effects:

[0089] In response to an invitation request from the first account for an interactive task targeting the second account, a task entity corresponding to the interactive task is created in the task entity table. This separate task entity table stores the task entities corresponding to the interactive tasks, decoupling the interactive task from intruding on the live stream entity and facilitating centralized management of associated data for the interactive tasks. Upon receiving an acceptance invitation request from the second account, the task entity's state transitions to the accepted state; a scheduled task is invoked to read the task entity table, obtaining the task entity in the accepted state; if the scheduled task determines that the interactive task's dependent resources are ready, the task entity in the accepted state transitions to the in progress state; another scheduled task is invoked to read the task entity table, obtaining the task entity in the in progress state; finally, if the interactive task meets the termination conditions, the task entity in the in progress state transitions to the terminated state. By deploying a separate scheduled task, the state transitions during the interaction process are consolidated within the scheduled task, improving maintainability and reducing I / O (input / output) pressure. Furthermore, using a scheduled task to uniformly manage the state transitions of interactive tasks ensures the consistency of state transition timeliness, thereby ensuring the accuracy of state transitions.

[0090] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0091] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0092] Figure 1This is an application environment diagram illustrating a state processing method for an interactive task according to an exemplary embodiment.

[0093] Figure 2 This is a flowchart illustrating a state processing method for an interactive task according to an exemplary embodiment.

[0094] Figure 3 This is an interactive flowchart illustrating the creation of a task entity during the invitation phase, according to an exemplary embodiment.

[0095] Figure 4 This is an exemplary embodiment illustrating a state processing flowchart for accepting an invitation during the invitation phase.

[0096] Figure 5 This is an exemplary embodiment illustrating a state handling flowchart for rejecting an invitation during the invitation phase.

[0097] Figure 6 This is an interactive flowchart illustrating the state processing of an interactive phase according to an exemplary embodiment.

[0098] Figure 7 This is an interactive flowchart illustrating the state processing of an end phase according to an exemplary embodiment.

[0099] Figure 8 This is a block diagram illustrating a state processing apparatus for an interactive task according to an exemplary embodiment.

[0100] Figure 9 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0101] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0102] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0103] It should also be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties.

[0104] The state handling method for interactive tasks provided in this disclosure can be applied to, for example... Figure 1 The application environment shown includes a first terminal 110, a second terminal 120, and a server 130. The number of first terminals 110 and second terminals 120 can be one or more. The first terminals 110 and 120 interact with the server 130 via a network. Both the first and second terminals 110 and 120 have applications installed to perform interactive tasks. These applications can be the same or different applications; for example, the application in the first terminal 110 might be a short video application, while the application in the second terminal 120 might be a mini-program bundled with an instant messaging application. The server 130 has pre-deployed independently running scheduled tasks to control the interaction status of the interactive tasks between the first and second terminals 110.

[0105] Specifically, in response to an invitation request sent by the first account in the first terminal 110 for an interactive task to the second account in the second terminal 120, server 130 creates a task entity corresponding to the interactive task in the task entity table. Upon receiving an acceptance request from the second account, server 130 transitions the state of the task entity to the accept state. Server 130 invokes a scheduled task to read the task entity table and obtains the task entity in the accept state; in response to the result that the dependent resources of the interactive task are ready as determined by the scheduled task, the state of the task entity in the accept state transitions to the in progress state. Server 130 invokes a scheduled task to read the task entity table and obtains the task entity in the in progress state; in response to the result that the interactive task meets the termination condition, the state of the task entity in the in progress state transitions to the terminated state.

[0106] The first terminal 110 and the second terminal 120 can be, but are not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. The server 130 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0107] Figure 2This is a flowchart illustrating a state processing method for an interactive task according to an exemplary embodiment, such as... Figure 2 As shown, the state processing method for interactive tasks is used in server 130 and includes the following steps S210 to S260.

[0108] In step S210, in response to the invitation request sent by the first account for the interactive task of the second account, a task entity corresponding to the interactive task is created in the task entity table.

[0109] The first account can uniquely identify the first live stream room currently broadcasting; for example, it could be the streamer's account or the live stream room identifier for the first streamer. The second account can uniquely identify the second live stream room currently broadcasting; for example, it could be the streamer's account or the live stream room identifier for the second streamer. The second account can be a random account, such as one randomly pushed to the first live stream room by the server from among currently broadcasting live stream rooms; it can also be an account matching the first account, such as an account corresponding to a live stream room with the same broadcast type as the first live stream room; or it can be an account designated by the first streamer.

[0110] An interactive task can refer to a challenge initiated by a first streamer to a second streamer through a first live streaming room. In one embodiment, the state of an interactive task in a live streaming scenario may include, but is not limited to, states such as initiating an invitation, accepting an invitation, rejecting an invitation, interaction in progress, and ending.

[0111] The task entity table can be stored in a relational database (e.g., MySQL) or a non-relational database (e.g., Redis). The task entity table stores the task entity and its current state corresponding to each interactive task. The task entity records the associated data of the interactive task, which may include, but is not limited to, the streamer's account, live stream identifier, time information, etc.

[0112] Specifically, the invitation request for an interactive task can be sent based on a triggering action taken by the first streamer on the live stream page. In one example, this triggering action can be achieved, but is not limited to, clicking a preset control, voice instructions, gesture instructions, visual controls, etc. For example, clicking a PK control displayed on the live stream page, or entering the voice data "challenge the second account," etc. Upon receiving the invitation request for an interactive task from the first account targeting the second account, the server creates a task entity corresponding to that interactive task in the task list.

[0113] In step S220, the invitation request sent by the second account is received, and the status of the task entity is changed to the accept status.

[0114] Specifically, in response to an invitation request sent by the first account for an interactive task targeting the second account, the server sends an invitation request to the second account to confirm whether to engage in the interaction. If the server detects that the second account has sent an acceptance request via the API, it can change the status of the task entity in the task entity table to the accepted state through the API. If the server detects that the second account has sent an invitation rejection request via the API, it can change the status of the task entity in the task entity table to the completed state through the API.

[0115] In one embodiment, once it is determined that the current state of the task entity has transitioned to the accept state, the server can request dependent resources from the dependent services of the interactive task through an interface to support the normal operation of the interactive task. In one example, the dependent services could be video services, image services, live streaming information services, etc.

[0116] In step S230, a scheduled task is invoked to read the task entity table and obtain the task entity in the accept state.

[0117] Scheduled tasks can run as independent services, complementing the interactive task system. They can be called synchronously or asynchronously.

[0118] Specifically, the server periodically calls a scheduled task to scan the task entity table and obtain the current status of each task entity in the table. The scheduled task can obtain all task entities with the same status. If, among all task entities with the same status of "accept", there is a task entity corresponding to both the first and second accounts, steps S240 to S250 are executed for that task entity.

[0119] In step S240, in response to determining that the dependent resources of the interactive task are ready through a timed task, the state of the task entity in the accept state is changed to the process state.

[0120] Specifically, the server invokes a scheduled task to poll whether the resources dependent on the interactive task are ready. Once it is determined that the dependent services of the interactive task are ready, the scheduled task transitions the task entity from the accepting state to the proceeding state, instructing the first and second accounts to interact.

[0121] In step S250, a scheduled task is invoked to read the task entity table and obtain the task entity in the in-process state.

[0122] Specifically, the server continues to periodically call a scheduled task to scan the task entity table and obtain the current status of each task entity in the table. The scheduled task can obtain all task entities with the same status. If, among all task entities with the same status (in progress), there is a task entity corresponding to both the first and second accounts, step S260 is executed for that task entity.

[0123] In step S260, in response to the interactive task meeting the termination condition, the state flow of the task entity in the in-process state is changed to the terminated state.

[0124] The termination condition is used to indicate that the interactive task can be terminated. This can be, but is not limited to, the current interaction duration meeting the preset duration, the first account and / or the second account actively triggering the termination request, or the first account and / or the second account experiencing connection errors.

[0125] Specifically, the server uses a scheduled task to determine whether the interactive task meets the termination conditions. If it does, the task entity corresponding to the interactive task that is in progress is transitioned to the terminated state. If it does not meet the conditions, the first account and the second account are allowed to continue interacting.

[0126] In the aforementioned method for handling the state of interactive tasks, a task entity corresponding to the interactive task is created in the task entity table. This separate task entity table stores the task entities corresponding to the interactive tasks, decoupling the interactive tasks from the live stream entity and facilitating centralized management of associated data for the interactive tasks. By deploying independent scheduled tasks, the state transitions during the interaction process are converged within these scheduled tasks, improving maintainability and reducing I / O pressure. Furthermore, using scheduled tasks to uniformly manage the state transitions of interactive tasks ensures the consistency of state transition timeliness, thereby guaranteeing the accuracy of the state transitions.

[0127] In an exemplary embodiment, the state processing of the interactive task may include, but is not limited to, an invitation phase, a process phase, and an end phase. In this embodiment, one method of creating a task entity during the invitation phase is described. In step S210, in response to an invitation request sent by a first account for an interactive task to a second account, a task entity corresponding to the interactive task is created in the task entity table. This includes: locking the first account and the second account in response to the invitation request sent by the first account for an interactive task to the second account; and after successfully locking the first account and the second account, when it is determined that there is no task identifier corresponding to the first account and the second account in the cached mapping relationship between account and task identifiers, creating a task entity corresponding to the interactive task in the task entity table.

[0128] The task identifier is used to uniquely represent the interactive task.

[0129] Specifically, concurrency may occur during the invitation phase of an interactive task, meaning the same account may be in the invitation phase of two different interactive tasks simultaneously. Therefore, in this embodiment, a distributed lock can be used to control concurrency during the invitation phase. In one example, the distributed lock can be a Redis-based distributed lock. The Redis lock command tables include INCR (incremental), SETNX (SET if Not exists, only set if it doesn't exist), and SET (set). This embodiment can use any of the above-mentioned lock command tables. In the specific implementation, the server responds to the invitation request for an interactive task sent by the first account for the second account, and locks both the first and second accounts. If the server successfully locks both the first and second accounts, it checks the cached mapping relationship between accounts and task identifiers to see if there is a task identifier corresponding to the first account and / or a task identifier corresponding to the second account. If they exist, a message indicating that interaction is in progress is returned to both the first and second accounts, and the held locks are released; if they do not exist, a task entity corresponding to the interactive task is created in the task entity table to allow the first and second accounts to perform subsequent operations.

[0130] In one embodiment, after creating the task entity corresponding to the interactive task, the server can also generate and cache the mapping relationship between the first account, the second account, and the task identifier of the interactive task. By caching the mapping relationship between accounts and task identifiers in real time, the server can easily verify subsequent invitation requests, thereby ensuring the exclusivity of the interactive task without locking.

[0131] In one embodiment, if locking the first account and / or the second account fails (taking INCR as an example), if the server obtains a lock greater than 1 corresponding to the first account, it is determined that locking the first account has failed. The server can return a message indicating that interaction is in progress to both the first and second accounts and release the locks it already holds.

[0132] In this embodiment, since interactive tasks in live streaming scenarios are usually exclusive, meaning that an account can only be in one interactive task at a time, by using account locking to verify the invitation request in the invitation phase, it is ensured that the same account will not be in the invitation phase of multiple interactive tasks at the same time, thus ensuring the exclusivity of the interactive tasks.

[0133] In an exemplary embodiment, the first account and the second account can be locked sequentially. Specifically, the server can determine the locking order based on the numerical values ​​of the first and second accounts, locking them in descending or ascending order of value. By locking the first and second accounts sequentially, the possibility of both accounts failing to lock due to repeated attempts to lock the same account can be avoided, thus ensuring the effective operation of the locking mechanism.

[0134] In one exemplary embodiment, another implementation of creating a task entity during the invitation phase is described. Figure 3 An example flowchart illustrates the interaction process of creating a task entity during the invitation phase. For example... Figure 3 As shown, this can be achieved through steps S302 to S322.

[0135] In step S302, the first account calls the interface to send an invitation request to the server for the interactive task of the second account.

[0136] In step S304, the server calls the interface in response to the invitation request and locks the account with the smaller value between the first account and the second account.

[0137] In step S306, the server calls the interface to lock the account with the larger value between the first account and the second account.

[0138] In step S308, the server calls an interface to determine whether there is a task identifier corresponding to the first account and / or the second account in the cached mapping relationship between account and task identifier.

[0139] In step S310, the server calls the interface to verify the dependent services of the interactive tasks corresponding to the first account and the second account.

[0140] In step S312, if both the first account and the second account are successfully locked, there is no task identifier corresponding to the first account and / or the second account in the cached mapping relationship between account and task identifier, and the dependent service verification is passed, the server creates a task entity corresponding to the interactive task in the task entity table.

[0141] In step S314, the server calls the interface to cache the mapping relationship between the first account, the second account and the task identifier of the interactive task.

[0142] In step S316, the server invokes a long connection to send an invitation message for the interactive task to the second account.

[0143] In step S318, the invitation information for the interactive task is sent to the second account asynchronously via a long connection.

[0144] In step S320, the server calls the interface to release the distributed lock.

[0145] In step S322, a successful API call notification is returned to the first account.

[0146] In an exemplary embodiment, the server can process the acceptance request sent by the second account based on a database locking mechanism. The database lock can be, but is limited to, any one of pessimistic locking, optimistic locking, etc. In this case, receiving the acceptance request sent by the second account and transitioning the task entity's state to an accept state in step S220 can be achieved in the following way.

[0147] Specifically, after receiving the acceptance invitation request from the second account via the interface, the server locks the task entity table using a database lock and changes the status of the task entity in the table to the accept state. In one example, using optimistic locking, after receiving the acceptance invitation request from the second account via the interface, the server obtains the current version number of the task entity table. The server changes the status of the interactive task in the task entity table to the accept state. When submitting the update, the server obtains the current version number of the task entity table again. If the two obtained current version numbers are the same, the status transition for the interactive task is considered successful. If the two obtained current version numbers are different, the status transition is considered to have failed, and a status change notification message is sent to both the first and second accounts.

[0148] In this embodiment, a database locking mechanism is used to process requests sent by the client, which can control concurrent modifications to the database and ensure the accuracy of modifications to the task entity table under concurrent conditions, thereby ensuring the consistency and uniformity of the task entity table.

[0149] Figure 4 An example flowchart illustrates the status processing interaction during the invitation phase. For example... Figure 4 As shown, this can be achieved through steps S402 to S430.

[0150] In step S402, the second account calls the interface to send an invitation acceptance request to the server.

[0151] In step S404, in response to the invitation acceptance request, the server changes the current state of the task entity in the task entity table to the acceptance state based on the database lock mechanism.

[0152] In step S406, a long connection is invoked to send a notification prohibiting the cancellation of invitations to the first account.

[0153] In step S408, a notification prohibiting the cancellation of invitations is sent asynchronously to the first account via a long connection.

[0154] In step S410, the server calls the interface to request dependent resources from the dependent service.

[0155] In step S412, the server invokes a scheduled task to poll whether the dependent services are ready.

[0156] In step S414, if the dependent resources are determined to be ready by the timed task, the state of the task entity is changed from the accept state to the process state.

[0157] In step S416, a timed task is used to send interaction start information to the first account and the second account via a long connection.

[0158] In step S418, the interaction status information used for push in the cache is updated.

[0159] In step S420, the interaction start information is asynchronously pushed to the first account via a long connection.

[0160] In step S422, the interaction start information is asynchronously pushed to the second account via a long connection.

[0161] In step S424, it is detected that the first account calls the interface to request other dependent clothing.

[0162] In step S426, resources are requested from other dependent services through this interface.

[0163] In step S428, it was detected that the second account called the interface to request other dependent clothing.

[0164] In step S430, resources are requested from other dependent services through this interface.

[0165] In an exemplary embodiment, the server can handle the rejection request sent by the second account based on a database locking mechanism. In this case, after receiving the rejection request from the second account through the interface, the server uses a database lock to lock the task entity table, changing the state of the task entity in the table to the "complete" state. In one example, using optimistic locking, after receiving the rejection request from the second account through the interface, the server obtains the current version number of the task entity table. The server changes the state of the interactive task in the task entity table to the "complete" state. When submitting an update, the server obtains the current version number of the task entity table again. If the two obtained current version numbers are the same, the state transition for the interactive task is considered successful. If the two obtained current version numbers are different, the state transition is considered to have failed, and a status change notification message is sent to both the first and second accounts.

[0166] In one embodiment, the server can handle requests sent by the first or second account that would cause a state change in the interactive task, such as the aforementioned accept invitation request, reject invitation request, or early termination request, based on a database locking mechanism. The processing principles are similar for different requests and will not be elaborated upon here.

[0167] In this embodiment, a database locking mechanism is used to process requests sent by the client, which can control concurrent modifications to the database and ensure the accuracy of data modified in the task entity table under concurrent conditions, thereby ensuring the consistency and uniformity of the task entity table.

[0168] Figure 5 An example flowchart illustrates the interaction process for handling the rejection of an invitation during the invitation phase. Figure 5 As shown, this can be achieved through steps S502 to S516:

[0169] In step S502, the second account calls the interface to send a request to the server to refuse the invitation.

[0170] In step S504, in response to the invitation rejection request, the server uses optimistic locking to change the state of the task entity in the task entity table to the end state.

[0171] In step S506, the server invokes a long connection to send interaction termination information to the first account and the second account.

[0172] In step S508, the interaction status information used for push in the cache is updated.

[0173] In step S510, the server calls the interface to clear the cached mapping relationship between the first account, the second account and the task identifier of the interactive task.

[0174] In step S512, the server calls the interface to clean up the dependent resources in the dependent services.

[0175] In step S514, the interaction end information is asynchronously pushed to the first account via a long connection.

[0176] In step S516, the interaction end information is asynchronously pushed to the second account via a long connection.

[0177] In an exemplary embodiment, before the state flow of the task entity in the in-process state is changed to the end state in step S260, the method further includes: changing the state flow of the task entity in the in-process state to the pre-end state; and determining that the associated data has been cleaned up by a timed task.

[0178] The pre-end status indicates the need to clean up associated data of the interaction task. Associated data may include resources that the interaction task depends on, and related data generated during the interaction process.

[0179] Specifically, when the scheduled task determines that the current interactive task meets the termination conditions, it can first transition the state of the task entity to a pre-termination state and start cleaning up the associated data of the interactive task. The scheduled task polls to see if the associated data has been cleaned up. If it determines that the associated data has been cleaned up, it transitions the current state of the interactive task in the task entity table to a termination state, thereby ending the interactive task.

[0180] In this embodiment, by setting a pre-termination state, the server has sufficient time to clean up the associated data of interactive tasks that meet the termination conditions, thereby ensuring the integrity of invalid data cleanup, reducing data space occupation, and reducing the impact on subsequently created interactive tasks.

[0181] In one exemplary embodiment, determining that the interaction task meets the termination condition includes: determining that the live broadcast room corresponding to the first account and / or the second account is in a closed broadcast state; or, determining that the connection of the first account and / or the second account is abnormal.

[0182] Specifically, during the interaction between the first and second accounts, the server continuously and periodically calls a scheduled task to scan the task entity table and obtain the current status of each task entity. The scheduled task can obtain all task entities with the same status. If among all task entities with the same status (in progress) there is a task entity corresponding to the first and second accounts, the scheduled task determines whether the live stream room corresponding to the first and / or second accounts is in a closed state, confirms whether the first and / or second accounts have a connection error, and confirms that the current progress time of the interaction task has reached the end time. If the scheduled task determines that the live stream room corresponding to any one or more of the first and second accounts is in a closed state, or that either the first or second account has a connection error, or that the current progress time of the interaction task has reached the end time, then it can be determined that the interaction task between the first and second accounts meets the termination conditions.

[0183] In this embodiment, during the interaction between the first account and the second account, a scheduled task periodically checks whether there are any abnormalities in the first account and the second account. If there are any abnormalities, the scheduled task automatically transitions the state of the task entity to the terminated state, which can reduce and simplify the state transition process and ensure the real-time nature of the state transition.

[0184] In an exemplary embodiment, determining that the current time point of the interactive task has reached the end time point includes: recording key time nodes of the interactive task in the task entity table through a scheduled task; and determining that the interactive task is in the second stage based on the key time nodes, that the current time point has reached the end time point.

[0185] Key time nodes are used to determine the stage of the interaction task, and may include, but are not limited to, the interaction start node and the virtual resource recording end node. The stage includes a first stage and a second stage. The first stage is the stage of interaction between the first account and the second account; the second stage is the remaining stage after the interaction between the first account and the second account ends, such as the display stage for the party that failed in the interaction task.

[0186] Specifically, during the interaction between the first and second accounts, the server invokes a scheduled task to record key time points of the interaction task in the task entity table. The server periodically invokes the scheduled task to scan the task entity table. If a key time point corresponding to a task entity indicates the second stage, it determines whether the duration of the second stage meets the preset duration. If it does, it determines that the time point has reached the end time point and transitions the task entity's state to the end state. If not, the interaction between the first and second accounts continues.

[0187] In this embodiment, in a live interactive scenario, there is usually a display phase for the party that failed the interaction task after the interaction between the two parties is completed. In this embodiment, a timed task is used to control the duration of the penalty phase, thereby reducing the complexity of state handling.

[0188] In an exemplary embodiment, the stage further includes a brief intermediate stage between the first stage and the second stage. When the server invokes a scheduled task to scan the task entity table and determines that the task entity corresponding to the interactive task is in this intermediate stage, it retrieves and caches the first virtual resource obtained by the first account performing the interactive task, and the second virtual resource obtained by the second account performing the interactive task, as finally statistically determined. The virtual resources can be represented using points, virtual items (such as props or points), etc. The first and second virtual resources are sent to the respective live streaming rooms of the first and second accounts via a persistent connection.

[0189] In this embodiment, by retaining a brief intermediate stage, during which the timed task broadcasts the first virtual resource obtained by the first account and the second virtual resource obtained by the second account to both live streaming rooms, it is convenient for the anchor and the audience to understand the interaction between the two live streaming rooms; by broadcasting the first and second virtual resources in a long connection manner, the audience who enters the live streaming room can also learn about the interaction, which helps to improve the audience's perception and ensure the global consistency of the status information.

[0190] In one exemplary embodiment, when the server invokes a scheduled task to scan the task entity table and determines that the interactive task is in the first stage, it continuously acquires and caches the third virtual resource obtained by the first account and the fourth virtual resource obtained by the second account in executing the interactive task through the scheduled task. The acquired third and fourth virtual resources are then sent to the respective live streaming rooms of the first and second accounts using a long-lived connection.

[0191] In this embodiment, by caching the currently obtained third and fourth virtual resources, the latest state of the interactive task in the cache is refreshed. Whenever a new account connects to the live broadcast room, the long connection can push the latest data to the audience, thereby making it easier for the audience to perceive.

[0192] In one exemplary embodiment, the state processing procedure during the interaction phase is described. Figure 6 An example is shown in the interaction flowchart for state processing during the interaction phase. For example... Figure 6 As shown, it includes steps S602 to S626.

[0193] In step S602, the server periodically calls a scheduled task to scan the task entity table and retrieves task entities with a status of not finished (including those in progress).

[0194] In step S604, the timed task detects whether the live broadcast room corresponding to the first account and / or the second account is in a closed broadcast state, and detects whether the first account and / or the second account has a connection error.

[0195] In step S606, if the scheduled task determines that the live stream room corresponding to the first account and / or the second account is in a closed state, or detects an abnormal connection of the first account and / or the second account, then the state of the task entity is changed to a pre-termination state, and steps S608 to S616 continue to be executed. If the scheduled task determines that the live stream room corresponding to the first account and the second account is in a live state, and detects that the connection of the first account and / or the second account is normal, then steps S618 to S626 are executed.

[0196] In step S608, a timed task is used to call a long connection to send an interaction end message to the live streaming rooms corresponding to the first account and the second account, respectively.

[0197] In step S610, the interaction status information used for pushing in the cache is updated.

[0198] In step S612, a scheduled task instructs the dependent service to clean up dependent resources.

[0199] In step S614, the interaction end information is asynchronously pushed to the first account via a long connection.

[0200] In step S616, the interaction end information is asynchronously pushed to the second account via a long connection.

[0201] In step S618, the server time and the key time points recorded in the task entity table are compared by a scheduled task.

[0202] In step S620, when it is determined that the current stage is intermediate between the first and second stages, a long connection is invoked to send the current interaction information to the respective live streaming rooms of the first and second accounts. The current interaction information includes the aforementioned third and fourth virtual resources.

[0203] In step S622, the interaction status information used for push in the cache is updated.

[0204] In step S624, the current interaction information is asynchronously pushed to the first account via a long connection.

[0205] In step S626, the current interaction information is asynchronously pushed to the second account via a long connection.

[0206] In an exemplary embodiment, after the state of the task entity is changed from the accept state to the in progress state in step S240, the method further includes: calling a timed task to read the task entity table to obtain the task entity in the early termination state; and changing the state of the task entity to the pre-termination state.

[0207] The early termination status is obtained in response to an early termination request sent by the first or second account. The early termination request can be triggered in response to the broadcaster's click operation, voice instruction, gesture instruction, visual control, etc.

[0208] Specifically, during the interaction between the first and second accounts, if the server receives an early termination request from either the first or second account via an interface, it can change the current state of the task entity corresponding to the interaction task in the task entity table from the "in progress" state to the "early termination" state. The server continuously and periodically calls a scheduled task to scan the task entity table and obtain the current state of each task entity. The scheduled task can retrieve all task entities with the same state. If, among all task entities with the same "early termination" state, there is a task entity corresponding to both the first and second accounts, the current state of that task entity is changed from the "early termination" state to the "pre-termination" state, and the cleanup of associated data for the interaction task is initiated. The scheduled task polls to see if the associated data has been cleaned up. If it determines that the associated data has been cleaned up, it changes the current state of the interaction task in the task entity table to the "terminated" state, thus ending the interaction task.

[0209] In this embodiment, by adding intermediate states (e.g., early termination states), the states actively triggered by the broadcaster are converged into an independent timed task, which facilitates unified management with the states generated by interactive tasks. This ensures the real-time efficiency and data consistency of state processing and also improves the maintainability of the code project.

[0210] In one exemplary embodiment, the state handling method of the end phase is described. Figure 7 An example is shown in the interactive flowchart of state processing in the end phase. Figure 7 As shown, it includes steps S702 to S732.

[0211] In step S702, the first account calls the interface to send an early termination request to the server.

[0212] In step S704, the server calls the interface and uses optimistic locking to change the task entity flow in the task entity table to an early termination state.

[0213] In step S706, the server calls a scheduled task to scan the task entity table and obtain unfinished task entities.

[0214] In step S708, the server calls the scheduled task to retrieve task entities that have exceeded the second stage or whose status is prematurely terminated from the unfinished task entities.

[0215] In step S710, a timed task is used to call a long connection to send an interaction end message to the live streaming rooms corresponding to the first account and the second account, respectively.

[0216] In step S712, the interaction status information used for push in the cache is updated.

[0217] In step S712, the task entity in the task entity table is switched to an early termination state by a timed task.

[0218] In step S716, a scheduled task instructs the dependent service to clean up dependent resources.

[0219] In step S718, the interaction end information is asynchronously pushed to the first account via a long connection.

[0220] In step S720, the interaction end information is asynchronously pushed to the second account via a long connection.

[0221] In step S722, the server calls a scheduled task to scan the task entity table and obtain task entities in the pre-completion state.

[0222] In step S724, a scheduled task polls to check whether the dependent resources have been cleaned up.

[0223] In step S726, if the dependent resources have been cleaned up, the state of the task entity is transferred to the end state.

[0224] In step S728, the server time is compared with the duration of the second phase by a scheduled task.

[0225] In step S730, if the duration of the second stage is too long, the state of the task entity is transitioned to the end state.

[0226] In step S732, the mapping relationship between the first account, the second account, and the task identifier in the cache is cleared by a scheduled task.

[0227] In an exemplary embodiment, the timed task reads the task entity table to obtain the task entity in the accept state, including: calling the timed task to read the task entity table page by page to obtain the task entity to be processed, storing the task entity to be processed in a buffer; and obtaining the task entity in the accept state from the buffer.

[0228] Specifically, the server periodically invokes a scheduled task, which reads pages from the task entity table to obtain a set of task entities to be processed, and stores these entities in a buffer. The scheduled task then retrieves task entities with the same state from the buffer. If, among the task entities in the "accept" state, there is a task entity corresponding to both the first and second accounts, the task entity in the "accept" state is retrieved.

[0229] In this embodiment, the scheduled task uses a combination of paging and buffering for batch reading, which keeps the amount of data processed by the scheduled task at a time within a reasonable range, thus ensuring that the scheduled task is in a better running state.

[0230] In an exemplary embodiment, a scheduled task can process task entities in the same state using a batch processing approach. For all task entities in the same state obtained at the same time, a batch processing interface can be called to process them in batches. After processing, the required status information is then sent to the relevant live streaming rooms in batches through the batch processing interface. Taking the same state as the receiving state as an example, the scheduled task can use the batch processing interface to poll whether the dependent resources required by the interactive tasks corresponding to all task entities in the receiving state are ready. If ready, the state of these task entities is then transitioned from the receiving state to the proceeding state through the batch processing interface. By deploying a batch processing interface to process task entities in the same state in batches, the number of I / O operations can be reduced, and the efficiency of state processing can be improved.

[0231] In one exemplary embodiment, a fallback query interface is reserved in advance, allowing clients to proactively obtain the required data through the query interface when they detect an anomaly (e.g., not receiving a push notification for the long-lived connection after a local countdown ends, or when reconnecting to the network). Specifically, when the server receives a query request initiated by the client of the first account and / or the second account upon detecting an anomaly, it calls the query interface to retrieve the task status of the task entity from the task entity table and returns the task status to the first account and / or the second account.

[0232] In this embodiment, since state transitions rely on interaction state information pushed via long-lived connections, the loss of this information could prevent normal state transitions. By retaining a fallback query interface, the client can proactively initiate a query request when it detects an anomaly, thus ensuring the normal progress and correctness of state transitions.

[0233] It should be understood that although the steps in the flowchart above are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0234] It is understood that the same / similar parts between the various embodiments of the methods described above in this specification can be referred to each other. Each embodiment focuses on the differences from other embodiments, and relevant parts can be referred to the description of other method embodiments.

[0235] Figure 8 This is a block diagram of an interactive task state processing apparatus X00 according to an exemplary embodiment. (Refer to...) Figure 8 The device includes an entity creation module X02, a state transition module X04, and a task invocation module X06.

[0236] The entity creation module X02 is configured to respond to an invitation request sent by the first account for an interactive task targeting the second account, and create a task entity corresponding to the interactive task in the task entity table. The state transition module X04 is configured to receive an acceptance request sent by the second account and transition the state of the task entity to the acceptance state. The task invocation module X06 is configured to execute a scheduled task to read the task entity table and obtain the task entity in the acceptance state. The state transition module X04 is also configured to respond to the timed task determining that the dependent resources of the interactive task are ready, and transition the state of the task entity in the acceptance state to the progress state. The task invocation module X06 is also configured to execute a scheduled task to read the task entity table and obtain the task entity in the progress state. The state transition module X04 is also configured to respond to the interactive task meeting the termination condition and transition the state of the task entity in the progress state to the termination state.

[0237] In one exemplary embodiment, the state transition module X04 is further configured to transition the state of a task entity in the in progress state to a pre-end state, the pre-end state being used to indicate the cleanup of associated data of the interactive task; the device X00 further includes a data cleanup module configured to determine, through a timed task, that the cleanup of associated data is complete.

[0238] In one exemplary embodiment, the task invocation module X06 is further configured to execute the invocation of a timed task to read the task entity table and obtain a task entity in an early termination state, the early termination state being obtained in response to an early termination request sent by a first account or a second account; the state transition module X04 is further configured to execute the transition of the state of the task entity to a pre-termination state.

[0239] In an exemplary embodiment, the state transition module is configured to record key time nodes of the interaction task in the task entity table via a timed task. The key time nodes are used to determine the stage of the interaction task. The stage includes a first stage and a second stage. The first stage is the stage of interaction between the first account and the second account, and the second stage is the remaining stage after the interaction between the first account and the second account ends. When it is determined that the interaction task is in the second stage according to the key time nodes, it is determined that the interaction task meets the termination condition, and the state of the task entity in the in-process state is transitioned to the terminated state.

[0240] In an exemplary embodiment, the stage further includes an intermediate stage between the first stage and the second stage; the task invocation module X06 is further configured to execute a scheduled task to read the task entity table to obtain the task entity in the intermediate stage; the device X00 further includes: a first acquisition module configured to acquire and cache the first virtual resource obtained by the first account performing the interactive task, and the second virtual resource obtained by the second account performing the interactive task; and a first sending module configured to send the first virtual resource and the second virtual resource to the live broadcast room corresponding to the first account and the second account respectively via a long connection.

[0241] In an exemplary embodiment, the task invocation module X06 is further configured to read the task entity table through a timed task to obtain the task entity in the first stage; the device X00 further includes: a second acquisition module configured to continuously acquire, through a timed task, the third virtual resource obtained by the current first account in performing the interactive task and the fourth virtual resource obtained by the current second account in performing the interactive task for the task entity in the first stage; and a second sending module configured to continuously send the third virtual resource and the fourth virtual resource to the live broadcast rooms corresponding to the first account and the second account respectively in a long connection.

[0242] In an exemplary embodiment, the task invocation module X06 includes: a page reading unit configured to execute a scheduled task to perform page reading of the task entity table, obtain the task entity to be processed, and store the task entity to be processed in a buffer; and an retrieval unit configured to retrieve the task entity in the accept state from the buffer.

[0243] In an exemplary embodiment, the apparatus X00 further includes: a receiving module configured to receive a query request sent by a first account and / or a second account through a query interface, wherein the query request is an active request initiated by the client of the first account or the second account when it detects an abnormal status; and a query module configured to call the query interface to query the task status of the task entity from the task entity table and return the task status to the first account and / or the second account.

[0244] In an exemplary embodiment, the entity creation module X02 includes: a locking unit configured to lock the first account and the second account in response to an invitation request sent by the first account for an interactive task for the second account; and an entity creation unit configured to, after successfully locking the first account and the second account, create a task entity corresponding to the interactive task in the task entity table when it is determined that there is no task identifier corresponding to the first account and the second account in the cached mapping relationship between account and task identifier.

[0245] In one exemplary embodiment, the locking unit is configured to determine the locking order based on the numerical values ​​of the first account and the second account, and lock the first account and the second account sequentially according to the locking order.

[0246] In one exemplary embodiment, the device X00 further includes: a prompting module configured to, upon determining that locking the first account and / or the second account has failed, return a prompt message indicating that interaction is in progress to the first account and the second account, and release the held lock.

[0247] In one exemplary embodiment, the device X00 further includes a caching module configured to perform a mapping relationship between the first account, the second account, and the task identifier of the interactive task.

[0248] In one exemplary embodiment, the state transition module X04 is configured to receive an acceptance invitation request sent by a second account and use a database lock mechanism to transition the state of the task entity to an acceptance state.

[0249] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0250] Figure 9 This is a block diagram illustrating an electronic device S00 for processing the state of an interactive task according to an exemplary embodiment. For example, the electronic device S00 can be a server. (Refer to...) Figure 9 The electronic device S00 includes a processing component S20, which further includes one or more processors, and memory resources represented by a memory S22 for storing instructions, such as application programs, that can be executed by the processing component S20. The application programs stored in the memory S22 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component S20 is configured to execute instructions to perform the methods described above.

[0251] The electronic device S00 may further include: a power supply component S24 configured to perform power management of the electronic device S00, a wired or wireless network interface S26 configured to connect the electronic device S00 to a network, and an input / output (I / O) interface S28. The electronic device S00 can operate on an operating system stored in memory S22, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, or similar.

[0252] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory S22 including instructions, which can be executed by a processor of an electronic device S00 to perform the above-described method. The storage medium can be a computer-readable storage medium, for example, a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0253] In an exemplary embodiment, a computer program product is also provided, the computer program product including instructions that can be executed by a processor of an electronic device S00 to perform the above method.

[0254] It should be noted that the above-mentioned apparatus, electronic equipment, computer-readable storage medium, computer program product, etc., may also include other implementation methods according to the description of the method embodiments. For specific implementation methods, please refer to the description of the relevant method embodiments, which will not be elaborated here.

[0255] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0256] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for handling the state of an interactive task, characterized in that, include: In response to the invitation request sent by the first account for an interactive task for the second account, a task entity corresponding to the interactive task is created in the task entity table; the task entity is used to record the associated data of the interactive task, including the anchor account, the live room identifier, and the time information; Upon receiving the invitation request sent by the second account, the status of the task entity is changed to the accept status. The scheduled task is invoked to read the task entity table and obtain the task entity in the accept state; In response to determining that the dependent resources of the interactive task are ready through the timed task, the state of the task entity in the accept state is changed to the in progress state. The scheduled task is invoked to read the task entity table and obtain the task entity that is in progress. In response to the interaction task meeting the termination condition, the state of the task entity in the in-process state is changed to the terminated state; The step of responding to the interaction task meeting the termination condition by changing the state of the task entity in the in-process state to the terminated state includes: recording key time nodes of the interaction task in the task entity table through the timed task; the key time nodes are used to determine the stage of the interaction task; the stage includes a first stage and a second stage; the first stage is the stage of interaction between the first account and the second account; the second stage is the remaining stage after the interaction between the first account and the second account ends; when it is determined that the interaction task is in the second stage according to the key time nodes, it is determined that the interaction task meets the termination condition, and the state of the task entity in the in-process state is changed to the terminated state. Before transitioning the state of the task entity in the ongoing state to the completed state, the method further includes: transitioning the state of the task entity in the ongoing state to a pre-completed state, wherein the pre-completed state is used to indicate the clearing of associated data of the interactive task; and determining that the clearing of associated data is completed through the timed task.

2. The state processing method for interactive tasks according to claim 1, characterized in that, After the state of the task entity in the accept state is transitioned to the proceeding state, the process further includes: The scheduled task is invoked to read the task entity table to obtain the task entity in the early termination state. The early termination state is obtained in response to an early termination request sent by the first account or the second account. The state of the task entity is transitioned to the pre-termination state.

3. The state processing method for interactive tasks according to claim 1, characterized in that, The stage further includes an intermediate stage between the first stage and the second stage; the method further includes: The scheduled task is invoked to read the task entity table to obtain the task entity in the intermediate stage; Acquire and cache the first virtual resource obtained by the first account performing the interactive task, and the second virtual resource obtained by the second account performing the interactive task; The first virtual resource and the second virtual resource are sent to the live streaming rooms corresponding to the first account and the second account respectively via a long connection.

4. The state processing method for interactive tasks according to claim 1, characterized in that, The method further includes: The task entity in the first stage is obtained by reading the task entity table through the scheduled task; For the task entity in the first stage, the third virtual resource obtained by the first account in executing the interactive task and the fourth virtual resource obtained by the second account in executing the interactive task are continuously obtained through the timed task. The third and fourth virtual resources are continuously sent to the live streaming rooms corresponding to the first and second accounts using a long connection.

5. The state processing method for interactive tasks according to claim 1, characterized in that, The step of calling a scheduled task to read the task entity table and obtain the task entity in the accept state includes: The scheduled task is invoked to read the task entity table page by page to obtain the task entity to be processed, and the task entity to be processed is stored in the buffer. The task entity in the accept state is obtained from the buffer.

6. The state processing method for interactive tasks according to claim 1, characterized in that, The method further includes: The query interface receives query requests sent by the first account and / or the second account. The query request is initiated by the client of the first account or the second account when it detects an abnormal status. The query interface is invoked to retrieve the task status of the task entity from the task entity table, and the task status is returned to the first account and / or the second account.

7. The state processing method for interactive tasks according to claim 1, characterized in that, The step of responding to the invitation request for an interactive task sent by the first account for the second account, and creating a task entity corresponding to the interactive task in the task entity table, includes: In response to the invitation request sent by the first account for an interactive task targeting the second account, both the first account and the second account are locked. After successfully locking the first account and the second account, if it is determined that there is no task identifier corresponding to the first account and the second account in the cached mapping relationship between account and task identifier, a task entity corresponding to the interactive task is created in the task entity table.

8. The state processing method for interactive tasks according to claim 7, characterized in that, The locking of the first account and the second account includes: The locking order is determined based on the numerical values ​​of the first account and the second account, and the first account and the second account are locked sequentially according to the locking order.

9. The state processing method for interactive tasks according to claim 7, characterized in that, The method further includes: If it is determined that locking the first account and / or the second account has failed, a message indicating that interaction is in progress will be returned to the first account and the second account, and the held lock will be released.

10. The state processing method for interactive tasks according to claim 7, characterized in that, After creating the task entity corresponding to the interactive task in the task entity table, the process further includes: The mapping relationship between the first account, the second account, and the task identifier of the interactive task is cached.

11. The state processing method for interactive tasks according to claim 1, characterized in that, The step of receiving the acceptance invitation request sent by the second account and changing the status of the task entity to an acceptance status includes: Upon receiving the invitation request sent by the second account, the database lock mechanism is used to change the state of the task entity to the accept state.

12. A state processing device for an interactive task, characterized in that, include: The entity creation module is configured to respond to an invitation request sent by the first account for an interactive task targeting the second account, and create a task entity corresponding to the interactive task in the task entity table; the task entity is used to record the associated data of the interactive task, including the anchor account, the live room identifier, and time information; The state transition module is configured to receive the invitation request sent by the second account and transition the state of the task entity to the acceptance state; The task invocation module is configured to execute a scheduled task to read the task entity table and obtain the task entity in the accept state; The state transition module is further configured to, in response to determining through the timed task that the dependent resources of the interactive task are ready, transition the state of the task entity in the accepting state to the proceeding state. The task invocation module is also configured to execute the scheduled task to read the task entity table and obtain the task entity in the in-process state; The state transition module is also configured to, in response to the interaction task meeting the termination condition, transition the state of the task entity in the in-process state to the terminated state. The state transition module is configured to record key time nodes of the interaction task in the task entity table via the timed task. The key time nodes are used to determine the stage of the interaction task. The stage includes a first stage and a second stage. The first stage is the stage in which the first account and the second account interact. The second stage is the remaining stage after the interaction between the first account and the second account ends. When the interaction task is determined to be in the second stage according to the key time nodes, the interaction task is determined to meet the termination condition, and the state of the task entity in the in-process state is transitioned to the terminated state. The state transition module is further configured to transition the state of the task entity in the in progress state to a pre-end state, the pre-end state being used to indicate the cleanup of associated data of the interactive task; the device further includes: a data cleanup module, configured to determine that the associated data cleanup is complete through the timed task.

13. The state processing device for interactive tasks according to claim 12, characterized in that, The task invocation module is also configured to execute the invocation of the scheduled task to read the task entity table to obtain the task entity in the early termination state, wherein the early termination state is obtained in response to an early termination request sent by the first account or the second account. The state transition module is also configured to transition the state of the task entity to the pre-end state.

14. The state processing device for interactive tasks according to claim 12, characterized in that, The stage also includes an intermediate stage between the first stage and the second stage; the task invocation module is further configured to execute the invocation of the timed task to read the task entity table to obtain the task entity in the intermediate stage; The device further includes: The first acquisition module is configured to acquire and cache the first virtual resource obtained by the first account performing the interactive task, and the second virtual resource obtained by the second account performing the interactive task; The first sending module is configured to send the first virtual resource and the second virtual resource to the live streaming rooms corresponding to the first account and the second account respectively via a long connection.

15. The state processing device for interactive tasks according to claim 12, characterized in that, The task invocation module is also configured to read the task entity table through the timed task to obtain the task entity in the first stage; The device further includes: The second acquisition module is configured to continuously acquire, through the timed task, the third virtual resource obtained by the first account in performing the interactive task and the fourth virtual resource obtained by the second account in performing the interactive task for the task entity in the first stage. The second sending module is configured to continuously send the third and fourth virtual resources to the live streaming rooms corresponding to the first and second accounts via a long connection.

16. The state processing device for interactive tasks according to claim 12, characterized in that, The task invocation module includes: The paging reading unit is configured to execute the scheduled task to read the task entity table in pages, obtain the task entity to be processed, and store the task entity to be processed in the buffer. The acquisition unit is configured to retrieve the task entity in the accepting state from the buffer.

17. The state processing device for interactive tasks according to claim 12, characterized in that, The device further includes: The receiving module is configured to receive query requests sent by the first account and / or the second account through a query interface. The query request is initiated by the client of the first account or the second account when it detects an abnormal status. The query module is configured to call the query interface to retrieve the task status of the task entity from the task entity table, and return the task status to the first account and / or the second account.

18. The state processing device for interactive tasks according to claim 12, characterized in that, The entity creation module includes: The locking unit is configured to lock the first account and the second account in response to an invitation request sent by the first account for an interactive task targeting the second account. The entity creation unit is configured to, after successfully locking the first account and the second account, if it is determined that there is no task identifier corresponding to the first account and the second account in the cached mapping relationship between account and task identifier, create a task entity corresponding to the interactive task in the task entity table.

19. The state processing device for interactive tasks according to claim 18, characterized in that, The locking unit is configured to determine the locking order based on the numerical values ​​of the first account and the second account, and lock the first account and the second account sequentially according to the locking order.

20. The state processing device for interactive tasks according to claim 18, characterized in that, The device further includes: The prompt module is configured to, if it is determined that locking the first account and / or the second account has failed, return a prompt message indicating that interaction is in progress to the first account and the second account, and release the lock already held.

21. The state processing device for interactive tasks according to claim 18, characterized in that, The device further includes: The caching module is configured to cache the mapping relationship between the first account, the second account, and the task identifier of the interactive task.

22. The state processing device for interactive tasks according to claim 12, characterized in that, The state transition module is configured to receive the invitation request sent by the second account and use a database lock mechanism to transition the state of the task entity to the accept state.

23. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the state processing method for the interactive task as described in any one of claims 1 to 11.

24. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is enabled to perform the state processing method for the interactive task as described in any one of claims 1 to 11.

25. A computer program product, the computer program product comprising instructions, characterized in that, When the instruction is executed by the processor of the electronic device, the electronic device is able to perform the state processing method for the interactive task as described in any one of claims 1 to 11.

Images