HK40052748B - Data processing method, device and storage medium based on cache queue - Google Patents

Description

Data processing methods, devices, and storage media based on cache queues

Technical Field

This application relates to the field of computer technology, and in particular to a data processing method, apparatus and storage medium based on a cache queue.

Background Technology

Online games, also known as network games, generally refer to video games where multiple players interact and enjoy entertainment via computer internet. Massive Multiplayer Online Role-Playing Games (MMORPGs) are a type of video role-playing game categorized by the number of players. Players can assume the role of one or more virtual characters and control their actions and behaviors within the game's virtual world. MMORPGs experience numerous offline events, such as deleting offline friends, kicking offline members from guilds, and sending emails to offline members. Due to limited server memory and the massive number of players, server memory typically only loads data related to online players. Therefore, when these numerous offline events occur, the server cannot directly modify offline player data.

The inventors of this application discovered during their research and practice that existing technologies typically load offline player data from a database (DB) into memory after an offline event occurs, process the data in memory, and then update it back to the database. This method is equivalent to directly modifying the offline player's data, ignoring the user experience of privileged players. Furthermore, due to the wide variety of offline events, if the database is accessed and data is modified for each offline event, it will affect the database access performance for other online events, resulting in a poor user experience, low applicability, and poor reliability.

Summary of the Invention

This application provides a data processing method, apparatus, and storage medium based on a cache queue, which can improve the reliability of the target application, enhance user stickiness of the target application, and is simple to operate and highly applicable.

The first aspect of this application provides a data processing method based on a cache queue, including:

When offline event interaction data of the target application is detected, the offline event interaction data is stored, wherein the target application is an application interacted by multiple users, and the offline event interaction data is the offline data of the users of the target application, wherein the offline data of any user is the operation data generated by other users in the target application initiating offline events for any user when any user is offline;

When it is detected that a target user of the target application has logged into the target application, the target offline data corresponding to the target user is determined from the stored offline event interaction data.

Based on the aforementioned target offline data and the target user's historical user data in the aforementioned target application, the target offline event corresponding to the aforementioned target offline data is responded to to generate the target user's online user data. The aforementioned target offline event is an offline event initiated by other users in the aforementioned target application against the aforementioned target user when the target user is offline.

In conjunction with the first aspect, in one possible implementation, storing the aforementioned offline event interaction data includes:

Store the aforementioned offline event interaction data in a cache queue;

The target offline data corresponding to the target user determined from the stored offline event interaction data includes:

The target offline data corresponding to the target user is determined from the offline event interaction data stored in the aforementioned cache queue.

In conjunction with the first aspect, in one possible implementation, before storing the aforementioned offline event interaction data into the cache queue, the method further includes:

A portion of the shared memory is identified from the application server's shared memory, and this portion of shared memory is designated as the aforementioned cache queue.

In conjunction with the first aspect, in one possible implementation, after storing the aforementioned offline event interaction data in a cache queue, the method further includes:

When the data update cycle arrives, the aforementioned offline event interaction data will be read from the cache queue and stored in the target database;

The target offline data corresponding to the target user determined from the stored offline event interaction data includes:

Based on the time when the target user logs into the target application and the time when the data update cycle arrives, the target offline data corresponding to the target user is determined from the offline event interaction data stored in the cache queue and/or the target database.

In conjunction with the first aspect, in one possible implementation, after storing the aforementioned offline event interaction data in a cache queue, the method further includes:

When the above cache queue storage space is full, the offline event interaction data with the earliest storage time in the above cache queue is read out and stored in the target database;

The target offline data corresponding to the target user determined from the stored offline event interaction data includes:

The target offline data corresponding to the target user is determined from the offline event interaction data stored in the aforementioned cache queue and/or the aforementioned target database.

In conjunction with the first aspect, in one possible implementation, after reading the aforementioned offline event interaction data from the cache queue and storing it in the target database, the method further includes:

Delete the aforementioned offline event interaction data from the aforementioned cache queue; or

Mark the above offline event interaction data as stored data.

In conjunction with the first aspect, in one possible implementation, before responding to the target offline event corresponding to the target offline data based on the target offline data and the target user's historical user data in the target application, the method further includes:

Send offline event handling requests to the aforementioned target users;

When the offline event handling response sent by the target user is received, the event handling logic of the target offline event corresponding to the target offline data is determined based on the target offline data, and the target offline event is executed based on the event handling logic, the target offline data, and the target user's historical user data in the target application to respond to the target offline event.

The aforementioned online user data refers to user data generated after the aforementioned target user logs into the aforementioned target application and responds to the aforementioned target offline event.

In conjunction with the first aspect, in one possible implementation, executing the target offline event based on the aforementioned event processing logic, the target offline data, and the target user's historical user data in the target application includes:

Based on the above event processing logic and the above target offline data, the online event logic interface of the above target application is called to modify the historical user data of the above target user in the above target application through the above online event logic interface to generate the online user data of the above target user. The above online event logic interface is the processing logic interface for online events in the above target application.

Secondly, this application provides a data processing apparatus based on a cache queue, the apparatus comprising:

The first storage module is used to store the offline event interaction data when the offline event interaction data of the target application is detected, wherein the target application is an application interacted by multiple users, the offline event interaction data is the offline data of the users of the target application, and the offline data of any user is the operation data generated by other users in the target application initiating offline events for any user when any user is offline.

The first determining module is used to determine the target offline data corresponding to the target user from the stored offline event interaction data when it is detected that the target user of the target application has logged into the target application.

The first response module is used to respond to the target offline event corresponding to the target offline data based on the target offline data and the target user's historical user data in the target application to generate the target user's online user data. The target offline event is an offline event initiated by other users in the target application against the target user when the target user is offline.

In conjunction with the second aspect, in one possible implementation, the first storage module is further configured to:

Store the aforementioned offline event interaction data in a cache queue;

The aforementioned first determining module is also used for:

The target offline data corresponding to the target user is determined from the offline event interaction data stored in the aforementioned cache queue.

In conjunction with the second aspect, in one possible implementation, the above-described apparatus further includes:

The second determining module is used to determine a portion of the shared memory from the shared memory of the application server, and to determine the aforementioned portion of the shared memory as the aforementioned cache queue.

In conjunction with the second aspect, in one possible implementation, the above-described apparatus further includes:

The second storage module is used to read the aforementioned offline event interaction data from the cache queue and store it in the target database when the data update cycle arrives;

The aforementioned first determining module is also used for:

Based on the time when the target user logs into the target application and the time when the data update cycle arrives, the target offline data corresponding to the target user is determined from the offline event interaction data stored in the cache queue and/or the target database.

In conjunction with the second aspect, in one possible implementation, the second storage module is further configured to:

When the above cache queue storage space is full, the offline event interaction data with the earliest storage time in the above cache queue is read out and stored in the target database;

The aforementioned first determining module is also used for:

The target offline data corresponding to the target user is determined from the offline event interaction data stored in the aforementioned cache queue and/or the aforementioned target database.

In conjunction with the second aspect, in one possible implementation, the above-described apparatus further includes:

The deletion module is used to read the offline event interaction data from the cache queue and store it in the target database, and then delete the offline event interaction data from the cache queue.

The marking module is used to mark the offline event interaction data as stored data after reading it from the cache queue and storing it in the target database.

In conjunction with the second aspect, in one possible implementation, the above-described apparatus further includes:

The sending module is used to send offline event processing requests to the aforementioned target users;

The third determining module is used to determine the event processing logic of the target offline event corresponding to the target offline data based on the target offline data when the offline event processing response sent by the target user is received.

The aforementioned first response module is also used for:

Based on the above event handling logic, the above target offline data, and the above target user's historical user data in the above target application, execute the above target offline event to respond to the above target offline event;

The aforementioned online user data refers to user data generated after the aforementioned target user logs into the aforementioned target application and responds to the aforementioned target offline event.

In conjunction with the second aspect, in one possible implementation, the first response module further includes:

The calling unit is used to call the online event logic interface of the target application based on the above event processing logic and the above target offline data;

The generation unit is used to modify the historical user data of the target user in the target application through the online event logic interface to generate the online user data of the target user, wherein the online event logic interface is the processing logic interface for online events in the target application.

Thirdly, this application provides a computer device, including: a processor, a transceiver, a memory, and a network interface; the processor is connected to the memory, the transceiver, and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store program code, and the processor and the transceiver are used to call the program code to execute the method performed by the first aspect and any possible implementation of the first aspect of this application.

Fourthly, this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor, perform the methods described in the first aspect of this application and any possible implementation thereof.

In this application, when offline event interaction data of a target application is detected, the offline event interaction data is stored. This offline event interaction data comprises the offline data of a user of the target application, and the offline data of any user is the operation data generated when other users in the target application initiate offline events for that user while the user is offline. When a target user of the target application is detected to have logged into the target application, the target offline data corresponding to the target user is determined from the stored offline event interaction data. The stored offline event interaction data is then processed after the target user logs into the target application, improving the user experience. After determining the target offline data corresponding to the target user, based on the target offline data and the target user's historical user data in the target application, a target offline event corresponding to the target offline data is responded to to generate the target user's online user data. The target offline event is an offline event initiated by other users in the target application for the target user while the target user is offline. By adopting this application, the problem of accessing the database to modify data for each offline event, which affects the database access performance of other online events, can be alleviated when there are many types of offline events. It also improves the user experience of the target application, is simple to operate, and has high applicability.

Attached Figure Description

To more clearly illustrate the technical solutions in this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

Figure 1 is a schematic diagram of the network architecture provided in an embodiment of this application;

Figure 2 is a schematic diagram of a scenario for a data processing method based on a cache queue provided in an embodiment of this application;

Figure 3 is a flowchart illustrating a data processing method based on a cache queue provided in an embodiment of this application.

Figure 4 is an interactive schematic diagram of the offline event processing method provided in an embodiment of this application;

Figure 5 is another interactive schematic diagram of the offline event processing method provided in the embodiment of this application;

Figure 6 is an interactive schematic diagram of the offline event processing method after introducing a request queue provided in an embodiment of this application;

Figure 7 is another flowchart illustrating the data processing method based on a cache queue provided in an embodiment of this application.

Figure 8 is an interactive schematic diagram of the data processing method based on a cache queue provided in an embodiment of this application;

Figure 9 is another interactive schematic diagram of offline event processing provided in an embodiment of this application;

Figure 10 is a schematic diagram of a data processing device based on a cache queue provided in an embodiment of this application;

Figure 11 is another structural schematic diagram of the data processing device based on a cache queue provided in an embodiment of this application;

Figure 12 is a schematic diagram of the structure of the computer device provided in an embodiment of this application.

Detailed Implementation

The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

The data processing method based on a cache queue provided in this application belongs to the field of cloud technology (CT) within the computer technology field. Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, and application technology applied based on the cloud computing business model. It refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to achieve the computing, storage, processing, and sharing of big data. It can form resource pools, be used on demand, and is flexible and convenient. Cloud computing technology will become an important support. The back-end services of technical network systems require a large amount of computing and storage resources, such as video websites, image websites, and more portal websites. With the rapid development and application of the Internet industry, in the future, every item may have its own identification mark, which will need to be transmitted to the back-end system for logical processing. Data of different levels will be processed separately, and various industry data will all require strong system support, which can only be achieved through cloud computing. Among them, big data (BD) refers to data sets that cannot be captured, managed, and processed by conventional software tools within a certain time frame. It is a massive, high-growth, and diverse information asset that requires new processing models to achieve stronger decision-making, insight discovery, and process optimization capabilities. With the advent of the cloud era, big data has attracted increasing attention. Big data requires specialized technologies to effectively process large amounts of data over a short period. Technologies suitable for big data include massively parallel processing databases, data mining, distributed file systems, distributed databases, cloud computing platforms, the Internet, and scalable storage systems.

Please refer to Figure 1, which is a network architecture diagram provided in an embodiment of this application. As shown in Figure 1, the network architecture diagram may include a service server 100 and a user terminal cluster. The user terminal cluster may include user terminal 10a, user terminal 10b, ..., user terminal 10n. There may be communication connections between the user terminal cluster members. For example, there may be a communication connection between user terminal 10a and user terminal 10b, and a communication connection between user terminal 10b and user terminal 10n. Any user terminal in the user terminal cluster may have a communication connection with the service server 100. For example, there may be a communication connection between user terminal 10a and service server 100, and a communication connection between user terminal 10b and service server 100.

The aforementioned user terminal cluster (including user terminal 10a, user terminal 10b, and user terminal 10n) can all integrate and install the target application. Optionally, the target application can include a user interaction application with the function of displaying data information such as text, images, and videos. For example, the target application can be a social application, which can be used to initiate offline operations (such as kicking out of a chat group) for any user when any user is offline. When the target user is detected to be logged in in the social application, the application responds to the offline operations (such as kicking out of a chat group) initiated by other users for the target user, and displays the account information corresponding to the target user after responding to the offline operation (such as information that the target user does not belong to the chat group) on the display interface of the user terminal (such as user terminal 10b). Alternatively, the target application can be a massively multiplayer online role-playing game (MMORPG) application, which can be used to allow other users in the game application to initiate offline operations (such as removing the target user from the game friends list) when any user is offline. When the target user is detected to be logged in, the application responds to the offline operations (such as removing the target user from the game friends list) initiated by other users and displays the account information of the target user after responding to the offline operation (such as information that a player is not a game friend of the target user) on the display interface of the user terminal (such as user terminal 10b). The business server 100 in this application can collect offline event interaction data in these applications. Here, the offline event interaction data is the offline data of users in the target application (i.e., the operation data generated by other users initiating offline events for any user when any user is offline). When the business server 100 detects the offline event interaction data of the target application, it stores the offline event interaction data, and when it detects that the target user is logged into the target application, it determines the target offline data corresponding to the target user from the stored offline event interaction data. Subsequently, based on the aforementioned target offline data and the target user's historical data in the aforementioned target application, the service server 100 responds to the target offline event corresponding to the aforementioned target offline data to generate the target user's online user data, and returns the account information corresponding to the target user's online user data to the user terminal. Optionally, the aforementioned user terminal can be any user terminal selected in the user terminal cluster of the embodiment corresponding to Figure 1 above. For example, the user terminal can be the aforementioned user terminal 10b, and the user can view the account information corresponding to the response to the aforementioned target offline event on the display page of user terminal 10b.

It is understood that the methods provided in this application embodiment can be executed by computer devices, including but not limited to terminals or servers. The business server 100 in this application embodiment can be a computer device, and the user terminals in the user terminal cluster can also be computer devices; this is not limited here. The aforementioned business server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The aforementioned terminals can include, but are not limited to, smart terminals such as smartphones, tablets, laptops, desktop computers, smart TVs, smart speakers, desktop computers, and smartwatches. The user terminals and the business server can be directly or indirectly connected via wired or wireless communication; this application does not impose any restrictions on this connection.

Please refer to Figure 2, which is a schematic diagram of a data processing method based on a cache queue provided in this application embodiment. As shown in Figure 2, when the business server 100 detects offline event interaction data in a target application (such as a massively multiplayer online role-playing game application), it first stores the offline event interaction data. This offline event interaction data consists of the offline data of users in the target application (such as a massively multiplayer online role-playing game application). The offline data of any user is the operation data generated when other users in the target application initiate offline events (such as kicking out of a guild) against that user while the user is offline. When the business server 100 detects that a target user (such as user A) has logged into the target application (such as a massively multiplayer online role-playing game application), it determines the target offline data corresponding to the target user (such as user A) from the stored offline event interaction data. Then, based on the aforementioned target offline data and the target user's (e.g., user A's) historical user data in the aforementioned target application, the business server 100 responds to the target offline event (e.g., being kicked out of the guild) corresponding to the aforementioned target offline data to generate the target user's online user data. The aforementioned target offline event (e.g., being kicked out of the guild) is an offline event initiated by other users in the aforementioned target application against the target user when the target user (e.g., user A) is offline. The updated account information corresponding to the target user's online user data is then returned to the user terminal. User A can then view the updated account information after responding to the aforementioned target offline event on the display page 20 of the user terminal 10b. As shown on display page 20, when user A, whose player name is "闻人夜思", logs in, it can be seen that after responding to the aforementioned target offline event (e.g., being kicked out of the guild), the player's guild title has changed to "Temporary Guild Member".

Further, for ease of understanding, please refer to Figure 3, which is a flowchart illustrating a data processing method based on a cache queue provided in an embodiment of this application. This method can be executed by a user terminal (e.g., the user terminal shown in Figure 1 or Figure 2 above), or it can be jointly executed by the user terminal and a business server (e.g., the business server 100 in the embodiment corresponding to Figure 1 or Figure 2 above). For ease of understanding, this embodiment will be described using the method executed by the aforementioned user terminal as an example. The data processing method based on a cache queue may include at least the following steps S101-S104:

S101, when offline event interaction data of the target application is detected, the aforementioned offline event interaction data is stored.

In some feasible implementations, when offline event interaction data of a target application is detected, the offline event interaction data is stored. The target application is an application with multiple user interactions, and the offline event interaction data consists of the offline data of the users of the target application. Furthermore, the offline data of any user is the operation data generated by other users in the target application initiating offline events for that user when that user is offline. It can be understood that when the target application is a large-scale multiplayer online role-playing game application, its corresponding offline events could be events such as deleting offline friends, kicking members from a guild, or sending emails to offline members. When the aforementioned offline event occurs, the target user being operated on is offline. Due to the large number of users and the limited memory of the business server, the business server cannot load all user data into memory. Therefore, offline users are usually not stored in the business server's memory; only the relevant data of online users are loaded into the business server's memory. Therefore, when the aforementioned offline event occurs, the business server cannot directly modify the user's historical data. If it is necessary to modify the user's historical data of offline users, the user's historical data of offline users can be loaded from the database (DB) into the business server's memory, processed, and then updated back to the database. In short, a database can be viewed as an electronic filing cabinet—a place to store electronic files, where users can perform operations such as adding, querying, updating, and deleting data. A "database" is a collection of data stored together in a certain way, shared by multiple users, with minimal redundancy, and independent of applications. Please refer to Figure 4, which is an interactive schematic diagram of the offline event processing method provided in this application embodiment. As shown in Figure 4, the target database stores user history data for user A, user history data for user B, user history data for user C, etc. When an offline event occurs, the business server requests the target user's user history data from the target database to modify the target user's user history data based on the offline interaction data corresponding to the offline event. After the modified user A's user history data is updated in the target database, the business server memory deletes the user A's user history data loaded from the target database to free up memory. For example, when the offline event is user A being kicked out of a guild, the business server memory requests user A's user history data from the target database, and then the target database loads user A's user history data into the business server memory. The business server then invokes the offline event logic to respond to the aforementioned offline event, modifying user A's user history data to update it, and sending the updated user A's user history data to the target database. Once the data update is successful, the business server's memory deletes user A's user history data to free up memory for online users. However, during the modification of user A's user history data, after an offline event occurs, the business server's memory directly loads user A's user history data from the target database for modification. This is a forced action that ignores user A's player experience. Furthermore, in current user interaction applications, various data processing logics are complex, with numerous data dependencies. For example, when an offline user is kicked from a guild, surrounding systems (guild chat channels, guild statues, etc.) need to be notified for data updates. Therefore, directly modifying data in the database also requires processing dependent data from these surrounding systems. A large amount of dependent data can easily lead to data omissions and application vulnerabilities. Moreover, in current user interaction applications, with a large number of players and an increasing variety of offline events, accessing the database for each offline event would put significant pressure on the database, impacting the database access performance for other online events. Please refer to Figure 5, which is another interactive schematic diagram of the offline event processing method provided in this application embodiment. As shown in Figure 5, the target database stores user history data of user A, user history data of user B, user history data of user C, etc. When an offline event occurs, the business server memory needs to load the target user's user history data into memory to modify the target user's user history data based on the offline interaction data corresponding to the offline event. However, when the business server modifies the target user's user history data, it also needs to modify complex dependency data of surrounding systems (such as chat channels, guild channels, and guild activity). It can be understood that the dependency data here is one form of the target user's user history data. When there are too many offline events, when the business server obtains user history data of user N from the database and accesses the database to update user N's user history data, the target database may fail to update due to performance pressure. In this case, the business server can only retry periodically to update user N's historical data in the target database, which has low applicability and reliability. In an optional embodiment of this application, when the business server detects offline event interaction data, it first stores the offline event interaction data until it detects that the target user is logged in before performing subsequent operations. This not only improves the user's gaming experience but also solves the database performance problem.

S102, when it is detected that the target user of the target application has logged into the target application, the target offline data corresponding to the target user is determined from the stored offline event interaction data.

In some feasible implementations, when offline event interaction data of the target application is detected, storing the offline event interaction data can be done by storing the offline event interaction data in a cache queue. This cache queue accesses data by pre-allocating a specified memory space. In optional embodiments of this application, all data is stored in the shared memory built into the application server. Therefore, before storing the offline event interaction data in the cache queue, a portion of the shared memory can be determined from the application server's shared memory and designated as the cache queue. Here, the application server can be understood as a business server that provides data computation, data verification, data storage, and data forwarding services for the target application. Storing the offline event interaction data in the cache queue reduces the number of database reads by caching data in shared memory, thereby improving database performance. To improve the reliability of the queue, in optional embodiments of this application, the cache queue is allocated from the application server's shared memory. This is because shared memory is not automatically cleaned up after the application server crashes; therefore, the shared memory can be re-associated with the new process by restarting the application server's process, thereby restoring the offline event interaction data in the cache queue. Here, a process is a running activity of a program with a certain independent function on a certain data set. It is the basic unit of dynamic execution of the operating system. In traditional operating systems, a process is both a basic allocation unit and a basic execution unit. In an optional embodiment of this application, in order to solve the database performance problem, a request queue can be introduced to place the offline events that need to be processed in the queue, and process the offline events in the queue one by one at regular intervals to alleviate the database performance problem caused by centralized processing of offline events. Please refer to Figure 6, which is an interactive schematic diagram of the offline event processing method after introducing a request queue provided in an embodiment of this application. As shown in Figure 6, the target database stores the user history data of user A, user history data of user B, user history data of user C, etc. The request queue stores the data modification items corresponding to each offline event, such as modifying the user history data of user A, modifying the user history data of user B, etc. When modifying the user history data of the target user, the dependent data of the target user can also be modified at the same time, and the modified user history data of the target user is updated to the target database to prevent data loss. When an offline event occurs, each offline event is added to the request queue for processing one by one. When the offline event being processed corresponds to modifying user A's historical data, the request queue loads user A's historical data from the database and modifies it based on the offline event. This modification includes changing user A's dependent data (such as chat channels, guild statues, guild activity, etc.), and then updates the database with the modified historical data. While this approach solves the performance problem caused by excessive database pressure, the request queue length is limited, and it still directly modifies user historical data after an offline event occurs, neglecting user experience. Furthermore, this approach allocates the request queue from server memory; if there are a large number of offline events, this requires significant memory space, and if the server crashes, all data in the request queue will be lost. Therefore, if a portion of the application server's shared memory is designated as a cache queue, and offline event interaction data is stored in this cache queue, when a target user is detected logging into the target application, the target offline data corresponding to that user can be determined from the offline event interaction data stored in the cache queue. This avoids directly modifying data after an offline event occurs and also solves the problem of storing the queue data on disk. This is because shared memory here is a storage area for data sharing and transfer between two or more running processes. Since shared memory is not automatically cleaned up after the application server process crashes, offline event interaction data is stored in a cache queue until the target user is detected to be logged in before subsequent operations are performed. This not only improves the user's gaming experience but also solves the database performance problem.

S103, based on the aforementioned target offline data and the aforementioned target user's historical user data in the target application, respond to the target offline event corresponding to the aforementioned target offline data to generate the aforementioned target user's online user data.

In some feasible implementations, based on the aforementioned target offline data and the target user's historical user data in the target application, a target offline event corresponding to the aforementioned target offline data is responded to to generate the target user's online user data. The aforementioned target offline event is an offline event initiated by other users in the target application against the target user when the target user is offline. Optionally, when a target user is detected to have logged into the target application, the online event logic interface of the target application is called based on the event processing logic and the aforementioned target offline data. This allows modification of the target user's historical user data in the target application through the aforementioned online event logic library to generate the target user's online user data. The aforementioned online event logic interface is the online event processing logic interface in the target application, and the aforementioned online user data is the user data generated after the target user logs into the target application and responds to the aforementioned target offline event. In an optional embodiment of this application, when a target user logs into the target application, the user's historical data needs to be loaded into memory. Therefore, executing offline events at the moment the user's historical data is loaded into memory allows reuse of the event handling logic when the user is online. This prevents logical omissions when processing dependent data from surrounding systems (such as guild chat channels, guild statues, etc.) and avoids data inaccuracies caused by data logic omissions when repeatedly developing offline event handling logic. Because existing online event handling logic can perform more comprehensive logical processing on offline event interaction data and the target user's historical data, reusing existing online event handling logic is safe and reliable, and will not omit the processing logic of dependent data.

In this application, when offline event interaction data of a target application is detected, the offline event interaction data is stored. This offline event interaction data comprises the offline data of a user of the target application, and the offline data of any user is the operation data generated when other users in the target application initiate offline events for that user while the user is offline. When a target user of the target application is detected to have logged into the target application, the target offline data corresponding to the target user is determined from the stored offline event interaction data. The stored offline event interaction data is then processed after the target user logs into the target application, improving the user experience. After determining the target offline data corresponding to the target user, based on the target offline data and the target user's historical user data in the target application, a target offline event corresponding to the target offline data is responded to to generate the target user's online user data. The target offline event is an offline event initiated by other users in the target application for the target user while the target user is offline. By adopting this application, the problem of accessing the database to modify data for each offline event, which affects the database access performance of other online events, can be alleviated when there are many types of offline events. It also improves the user experience of the target application, is simple to operate, and has high applicability.

In some feasible implementations, please refer to Figure 7 as well. Figure 7 is another flowchart illustrating the data processing method based on a cache queue provided in this application embodiment. This method can be executed by a user terminal (e.g., the user terminal shown in Figure 1 or Figure 2 above), or it can be jointly executed by the user terminal and a service server (e.g., the service server 100 in the embodiment corresponding to Figure 1 or Figure 2 above). For ease of understanding, this embodiment will be described using the method executed by the aforementioned user terminal as an example. The data processing method based on a cache queue may include at least the following steps S201-S205:

S201, When offline event interaction data of the target application is detected, the aforementioned offline event interaction data is stored in the cache queue.

In some feasible implementations, when offline event interaction data of the target application is detected, a portion of shared memory is determined from the shared memory of the application server, and this portion of shared memory is designated as the cache queue. The offline event interaction data is then stored in the cache queue. The target application is an application with multiple user interactions, and the offline event interaction data consists of the offline data of the users of the target application. Furthermore, the offline data of any user is the operation data generated when other users in the target application initiate an offline event targeting that user while that user is offline. In optional embodiments of this application, the offline event interaction data stored in the cache queue differs from the user data corresponding to the offline event stored in the request queue in Figure 6. The main difference lies in memory usage. The user data corresponding to the offline event is typically in the megabyte (MByte, MB) range, while the offline event interaction data, which is the operation data generated when other users in the target application initiate an offline event targeting that user while that user is offline (e.g., if the offline event is the aforementioned gang kicking event, then the operation data here could be the relevant data corresponding to the operation of modifying the target user's gang name), is typically in the kilobyte (KB) range. The difference between the two is approximately 1000 orders of magnitude. Therefore, storing the aforementioned offline event interaction data in a cache queue can also save shared memory space and improve the operating efficiency of the cache queue.

S202, when the data update cycle arrives, the above offline event interaction data is read from the cache queue and stored in the target database.

In some feasible implementations, to address the memory consumption issue in the cache queue, the offline event interaction data in the cache queue can be periodically stored in the target database to free up storage space for other offline event interaction data. Therefore, when the data update cycle arrives, reading the offline event interaction data from the cache queue and storing it in the target database can prevent the loss of offline event interaction data in the event of a business server crash. In an optional embodiment of this application, if the data update cycle has not yet arrived, but the storage space in the cache queue is full, the offline event interaction data with the earliest storage time in the cache queue is read out and stored in the target database to free up storage space for other offline event interaction data. Optionally, after reading and storing the offline event interaction data from the cache queue in the target database, the offline event interaction data can be deleted from the cache queue or marked as stored data. Please refer to Figure 8, which is an interactive schematic diagram of the data processing method based on the cache queue provided in an embodiment of this application. As shown in Figure 8, the target database stores offline event 1 interaction data, offline event 2 interaction data, and offline event 3 interaction data updated from the cache queue. The cache queue stores offline event interaction data (excluding offline event 1, offline event 2, and offline event 3), as well as offline event interaction data (including offline event 4 and offline event 5). As shown in Figure 8, when offline event interaction data of the target application is detected, offline event N interaction data is stored in the cache queue. This allows for the processing of offline events corresponding to the offline event interaction data in the cache queue one by one, alleviating database pressure. When the data update cycle arrives, the offline event interaction data (including offline event 1, offline event 2, and offline event 3 interaction data) in the cache queue are stored one by one into the target database. Then, the offline event interaction data (including offline event 1, offline event 2, and offline event 3 interaction data) in the cache queue are deleted to free up storage space for other offline event interaction data.

S203, when it is detected that a target user of the target application has logged into the target application, the target offline data corresponding to the target user is determined from the offline event interaction data stored in the above-mentioned cache queue and/or the above-mentioned target database.

In some feasible implementations, when a target user is detected logging into the target application, if a portion of the offline event interaction data corresponding to the target user is in the cache queue and a portion has been stored in the target database, then the target offline data corresponding to the target user is determined from the cache queue and the target database; if all the offline event interaction data corresponding to the target user has been stored in the target database, then the target offline data of the target user is determined from the target database; if the offline event interaction data corresponding to the target user has not yet been stored in the target database, then the target offline data of the target user is determined from the cache queue. When the target user logs into the target application, the user's historical data stored in the target database is first loaded into memory, and the determined target offline data of the target user is also loaded into memory for subsequent operations.

S204, Send an offline event handling request to the aforementioned target user.

In some feasible implementations, upon detecting that a target user has logged into the target application, an offline event processing request is sent to the target user. Optionally, if the target application is a massively multiplayer online role-playing game (MMORPG), the target user is a privileged user, and the offline event is a guild kicking event, an offline event processing request is sent to the target user. It can be understood that sending an offline event processing request to the target user here could be a request to the privileged user to confirm or deny leaving the guild.

S205, when the offline event processing response sent by the target user is received, based on the target offline data and the target user's historical user data, the target offline event corresponding to the target offline data is responded to to generate the target user's online user data.

In some feasible implementations, upon receiving the offline event processing response sent by the target user, based on the target offline data and the target user's historical user data, the target offline event corresponding to the target offline data is responded to to generate the target user's online user data. Optionally, when receiving the offline event processing response sent by the target user, if the offline event processing response carries event consent information (such as consent to leave a guild), the event processing logic of the target offline event corresponding to the target offline data is determined based on the target offline data, and the online event logic interface of the target application is called based on the event processing logic and the target offline data. This allows modification of the target user's historical user data in the target application through the online event logic interface to generate the target user's online user data. The online event logic interface is the online event processing logic interface in the target application, and the online user data is the user data generated after the target user logs into the target application and responds to the target offline event. Please refer to Figure 9, which is another interactive schematic diagram of offline event processing provided in this application embodiment. As shown in Figure 9, the target database stores offline event 1 interaction data, offline event 2 interaction data, and offline event 3 interaction data updated from the cache queue. The business server loads the target user's historical data and offline event 1, offline event 2, and offline event 3 interaction data from the target database. When the target application is a large-scale multiplayer online role-playing game, the peripheral systems may include guild systems, reward systems, email systems, event systems, task systems, and home systems. When a target user logs into the target application and receives an offline event handling response from the target user carrying event consent information, if all the offline event interaction data corresponding to the target user has been stored in the target database, the target offline data (such as offline event 1, offline event 2, and offline event 3 interaction data) of the target user is determined from the target database. The target offline data (such as offline event 1, offline event 2, and offline event 3 interaction data) and the target user's historical user data are loaded into the business server's memory. Then, based on the target offline data and the event handling logic corresponding to the target offline events determined based on the target offline data, the online event logic interface of the target application is called to modify the target user's historical user data in the target application and generate the target user's online user data. Optionally, as shown in Figure 9, if the target application is a massively multiplayer online role-playing game (MMORPG), and its peripheral systems include guild systems, reward systems, mail systems, event systems, quest systems, and home systems, after the target user logs into the MMORPG, the logic interface of online events can be reused to modify the dependent data involved in the peripheral systems. This ensures that the behavior of a user being kicked out of a guild when offline is consistent with the behavior of a user being kicked out of a guild when online, without any logical omissions and thus guaranteeing the accuracy of the data in the peripheral systems.

In this application, when offline event interaction data of a target application is detected, a portion of shared memory is determined from the shared memory of the application server and designated as the cache queue. The aforementioned offline event interaction data is stored in the cache queue. To address the memory consumption issue in the cache queue, when the data update cycle arrives, the aforementioned offline event interaction data is read from the cache queue and stored in the target database, freeing up storage space for other offline event interaction data. When a target user of the target application is detected logging into the target application, the target offline data corresponding to the target user is determined from the offline event interaction data stored in the aforementioned cache queue and/or the aforementioned target database. An offline event processing request is sent to the target user. Upon receiving the offline event processing response from the target user, based on the target offline data and the target user's historical user data, the target offline event corresponding to the target offline data is responded to to generate the target user's online user data. By using this application, offline event interaction data can be stored in a cache queue to alleviate database pressure. At the same time, it solves the problem of insufficient user experience caused by directly modifying data in the database. It can also reuse the user's online event logic interface, thereby ensuring that offline events and online events behave consistently, preventing data loss caused by repeated development of offline event processing logic. It is simple to operate and highly applicable.

Further, please refer to Figure 10, which is a schematic diagram of a data processing device based on a cache queue provided in this application. This data processing device based on a cache queue can be a computer program (including program code) running on a computer device; for example, it can be an application software. The device can be used to execute the corresponding steps in the method provided in this application. As shown in Figure 10, the data processing device based on a cache queue includes: a first storage module 10, a first determination module 20, and a first response module 30.

The first storage module 10 is used to store the offline event interaction data when the offline event interaction data of the target application is detected, wherein the target application is an application interacted by multiple users, the offline event interaction data is the offline data of the users of the target application, and the offline data of any user is the operation data generated by other users in the target application initiating an offline event for any user when any user is offline.

The first determining module 20 is used to determine the target offline data corresponding to the target user from the stored offline event interaction data when it is detected that the target user of the target application has logged into the target application.

The first response module 30 is used to respond to the target offline event corresponding to the target offline data based on the target offline data and the target user's historical user data in the target application to generate the target user's online user data. The target offline event is an offline event initiated by other users in the target application against the target user when the target user is offline.

In one possible implementation, the first storage module 10 is further configured to:

Store the aforementioned offline event interaction data in a cache queue;

The aforementioned first determining module 20 is also used for:

The target offline data corresponding to the target user is determined from the offline event interaction data stored in the aforementioned cache queue.

In one possible implementation, please refer to FIG11, which is another structural schematic diagram of a data processing apparatus based on a cache queue provided in an embodiment of this application. As shown in FIG11, the apparatus further includes:

The second determining module 40 is used to determine a portion of the shared memory from the shared memory of the application server and to determine the aforementioned portion of the shared memory as the aforementioned cache queue.

In one possible implementation, the above-described apparatus further includes:

The second storage module 50 is used to read the aforementioned offline event interaction data from the cache queue and store it in the target database when the data update cycle arrives;

The aforementioned first determining module 20 is also used for:

Based on the time when the target user logs into the target application and the time when the data update cycle arrives, the target offline data corresponding to the target user is determined from the offline event interaction data stored in the cache queue and/or the target database.

In one possible implementation, the second storage module 50 is further configured to:

When the above cache queue storage space is full, the offline event interaction data with the earliest storage time in the above cache queue is read out and stored in the target database;

The aforementioned first determining module 20 is also used for:

The target offline data corresponding to the target user is determined from the offline event interaction data stored in the aforementioned cache queue and/or the aforementioned target database.

In one possible implementation, the above-described apparatus further includes:

The deletion module 60 is used to read the offline event interaction data from the cache queue and store it in the target database, and then delete the offline event interaction data from the cache queue.

The marking module 70 is used to mark the offline event interaction data as stored data after reading it from the cache queue and storing it in the target database.

In one possible implementation, the above-described apparatus further includes:

Sending module 80 is used to send offline event processing requests to the aforementioned target users;

The third determining module 90 is used to determine the event processing logic of the target offline event corresponding to the target offline data based on the target offline data when it receives the offline event processing response sent by the target user.

The aforementioned first response module 30 is also used for:

Based on the above event handling logic, the above target offline data, and the above target user's historical user data in the above target application, execute the above target offline event to respond to the above target offline event;

The aforementioned online user data refers to user data generated after the aforementioned target user logs into the aforementioned target application and responds to the aforementioned target offline event.

In one possible implementation, the first response module 30 further includes:

Calling unit 301 is used to call the online event logic interface of the target application based on the above event processing logic and the above target offline data;

The generation unit 302 is used to modify the historical user data of the target user in the target application through the online event logic interface to generate the online user data of the target user, wherein the online event logic interface is the processing logic interface for online events in the target application.

Further, please refer to Figure 12, which is a schematic diagram of the structure of a computer device provided in an embodiment of this application. As shown in Figure 12, the computer device 2000 can be applied to a server, which can be the business server 100 in the embodiment corresponding to Figure 1 above; the computer device 2000 can be applied to a terminal, which can be user terminal 10a, user terminal 10b, ..., user terminal 10n in the embodiment corresponding to Figure 1 above; the computer device 2000 can also be the computer device in the embodiment corresponding to Figure 3 above. The computer device 2000 may include: a processor 2001, a network interface 2004, and a memory 2005. In addition, the computer device 2000 also includes: a transceiver 2003, and at least one communication bus 2002. The communication bus 2002 is used to realize the connection and communication between these components. The network interface 2004 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface). The memory 2005 may be a high-speed RAM memory or a non-volatile memory, such as at least one disk storage device. Alternatively, the memory 2005 may be at least one storage device located remotely from the aforementioned processor 2001. As shown in FIG12, the memory 2005, as a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

In the computer device 2000 shown in Figure 12, the network interface 2004 provides network communication functionality; the processor 2001 and transceiver 2003 can be used to call the device control application stored in the memory 2005 to achieve:

The processor 2001 is configured to store the offline event interaction data when offline event interaction data of a target application is detected, wherein the target application is an application interacted by multiple users, the offline event interaction data is the offline data of the users of the target application, and the offline data of any user is the operation data generated by other users in the target application initiating an offline event for any user when any user goes offline.

The processor 2001 is further configured to determine the target offline data corresponding to the target user from the stored offline event interaction data when it is detected that the target user of the target application has logged into the target application.

The processor 2001 is further configured to, based on the target offline data and the target user's historical user data in the target application, respond to the target offline event corresponding to the target offline data to generate the target user's online user data, wherein the target offline event is an offline event initiated by other users in the target application against the target user when the target user is offline.

In one possible implementation, the processor 2001 is further configured to:

Store the aforementioned offline event interaction data in a cache queue;

The target offline data corresponding to the target user is determined from the offline event interaction data stored in the aforementioned cache queue.

In one possible implementation, before storing the offline event interaction data into the cache queue, the processor 2001 is further configured to:

A portion of the shared memory is identified from the application server's shared memory, and this portion of shared memory is designated as the aforementioned cache queue.

In one possible implementation, after storing the aforementioned offline event interaction data in a cache queue, the processor 2001 is further configured to:

When the data update cycle arrives, the aforementioned offline event interaction data will be read from the cache queue and stored in the target database;

Based on the time when the target user logs into the target application and the time when the data update cycle arrives, the target offline data corresponding to the target user is determined from the offline event interaction data stored in the cache queue and/or the target database.

In one possible implementation, after storing the aforementioned offline event interaction data in a cache queue, the processor 2001 is further configured to:

When the above cache queue storage space is full, the offline event interaction data with the earliest storage time in the above cache queue is read out and stored in the target database;

The target offline data corresponding to the target user is determined from the offline event interaction data stored in the aforementioned cache queue and/or the aforementioned target database.

In one possible implementation, after reading the offline event interaction data from the cache queue and storing it in the target database, the processor 2001 is further configured to:

Delete the aforementioned offline event interaction data from the aforementioned cache queue; or

Mark the above offline event interaction data as stored data.

In one possible implementation, before responding to the target offline event corresponding to the target offline data based on the target offline data and the target user's historical user data in the target application, the transceiver 2003 is configured to:

Send offline event handling requests to the aforementioned target users;

When the transceiver 2003 receives the offline event processing response sent by the target user, the processor 2001 is further configured to determine the event processing logic of the target offline event corresponding to the target offline data based on the target offline data, and execute the target offline event based on the event processing logic, the target offline data and the target user's historical user data in the target application to respond to the target offline event.

The aforementioned online user data refers to user data generated after the aforementioned target user logs into the aforementioned target application and responds to the aforementioned target offline event.

In one possible implementation, the processor 2001 is further configured to:

Based on the above event processing logic and the above target offline data, the online event logic interface of the above target application is called to modify the historical user data of the above target user in the above target application through the above online event logic interface to generate the online user data of the above target user. The above online event logic interface is the processing logic interface for online events in the above target application.

Furthermore, it should be noted that this application also provides a computer-readable storage medium storing a computer program executed by the aforementioned path fusion-based image recognition device. This computer program includes program instructions, which, when executed by the processor, enable the execution of the path fusion-based image recognition method described in the embodiments corresponding to Figures 3 and/or 7. Therefore, these descriptions will not be repeated here. Additionally, the beneficial effects of using the same method will not be repeated here either. For technical details not disclosed in the computer-readable storage medium embodiments of this application, please refer to the description of the method embodiments of this application. As an example, the program instructions may be deployed to execute on a single computing device or on multiple computing devices located in one location.

Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The computer-readable storage medium can be a control device for a power converter provided in any of the foregoing embodiments, or an internal storage unit of the device, such as a hard disk or memory of an electronic device. The computer-readable storage medium can also be an external storage device of the electronic device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device. The computer-readable storage medium can also include magnetic disks, optical disks, read-only memory (ROM), or random access memory, etc. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of the electronic device. The computer-readable storage medium is used to store the computer program and other programs and data required by the electronic device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

The terms "first," "second," etc., used in the claims, description, and drawings of this invention are used to distinguish different objects, not to describe a particular order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that comprises a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses. References to "embodiment" herein mean that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The presentation of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments. The term "and/or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Those skilled in the art can implement the described functions using different methods for each specific application, but such implementations should not be considered beyond the scope of this invention.

The circuits and methods disclosed in the embodiments provided in this application can also be implemented in other ways. For example, the device embodiments described above are illustrative. For example, the division of circuit modules is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed.

In the various embodiments of this application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims (9)

1. A data processing method based on a cache queue, characterized in that it is applied to a business server, the method comprising: When offline event interaction data of a target application is detected, the offline event interaction data is stored in a cache queue. The target application is an application interacted by multiple users, and the offline event interaction data is the offline data of the users of the target application. The offline data of any user is the operation data generated by other users in the target application initiating offline events for any user when that user is offline. When a target user of the target application is detected to have logged into the target application, the target offline data corresponding to the target user is determined from the stored offline event interaction data; The event handling logic for determining the target offline event corresponding to the target offline data is based on the target offline data. The target offline event is an offline event initiated by other users in the target application against the target user when the target user is offline. Based on the event processing logic and the target offline data, the online event logic interface of the target application is called to modify the historical user data of the target user in the target application through the online event logic interface to generate the online user data of the target user. The online user data is the user data generated after the target user logs into the target application and responds to the target offline event. 2. The method according to claim 1, wherein determining the target offline data corresponding to the target user from the stored offline event interaction data includes: The target offline data corresponding to the target user is determined from the offline event interaction data stored in the cache queue. 3. The method according to claim 1, characterized in that, before storing the offline event interaction data in the cache queue, the method further includes: A portion of the shared memory is identified from the application server's shared memory, and this portion of shared memory is designated as the cache queue. 4. The method according to claim 1, characterized in that, after storing the offline event interaction data in a cache queue, the method further includes: When the data update cycle arrives, the offline event interaction data is read from the cache queue and stored in the target database; Determining the target offline data corresponding to the target user from the stored offline event interaction data includes: Based on the time when the target user logs into the target application and the time when the data update cycle arrives, the target offline data corresponding to the target user is determined from the offline event interaction data stored in the cache queue and/or the target database. 5. The method according to claim 4, characterized in that, after storing the offline event interaction data in a cache queue, the method further includes: When the cache queue storage space is full, the offline event interaction data with the earliest storage time in the cache queue is read out and stored in the target database; Determining the target offline data corresponding to the target user from the stored offline event interaction data includes: The target offline data corresponding to the target user is determined from the offline event interaction data stored in the cache queue and/or the target database. 6. The method according to claim 4, characterized in that, after reading the offline event interaction data from the cache queue and storing it in the target database, the method further includes: Delete the offline event interaction data from the cache queue; or The offline event interaction data is marked as stored data. 7. The method according to any one of claims 1-6, characterized in that, before determining the event processing logic of the target offline event corresponding to the target offline data based on the target offline data, the method further includes: Send an offline event processing request to the target user; When the offline event handling response sent by the target user is received, the event handling logic for determining the target offline event corresponding to the target offline data based on the target offline data is executed. 8. A computer device, characterized in that it comprises: a processor, a transceiver, a memory, and a network interface; The processor is connected to a memory, a transceiver, and a network interface, wherein the network interface is used to provide data communication functions, the memory is used to store program code, and the transceiver and the processor are used to call the program code to execute the method according to any one of claims 1-7. 9. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program, the computer program including program instructions, which, when executed by a processor, perform the method according to any one of claims 1-7.