Business logic processing method and device, computer device and storage medium

Abstract

The application relates to a business logic processing method and device, computer equipment, a storage medium and a computer program product. The method sets a focus event, and then drives business logic through the event based on an event management thread, while object attribute requirements dependent on the business logic are abstracted and written into an attribute requirement thread to realize synchronous processing of attribute information. The application can realize double decoupling of business logic and attribute information, and effectively achieve the purpose of service splitting.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a business logic processing method, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0002] With the development of computer technology, computer-based business processing has become increasingly important. However, coupling is a common phenomenon in computer-based business logic processing. Coupling refers to the degree of association between two subsystems (or classes). When a change in one subsystem (or class) has little impact on another, they are said to be loosely coupled; conversely, if the impact of the change is significant, they are said to be tightly coupled. The strength of coupling depends on the complexity between modules, the location of referencing modules, and the data transmission method. During design, the coupling between modules should be minimized, as it directly affects the system's understandability, testability, reliability, and maintainability.

[0003] In some technical scenarios, such as the business logic of games using traditional technologies, the coupling phenomenon is very serious. Games contain a large amount of logical coupling and contextual information coupling, making it impossible to achieve service decomposition. Summary of the Invention

[0004] Therefore, it is necessary to provide a business logic processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can effectively decouple business logic and split services to address the above-mentioned technical problems.

[0005] Firstly, this application provides a business logic processing method. The method includes:

[0006] Respond to the login event of the target object to determine the main business service process and the subordinate business service process;

[0007] The subordinate business service process is used to obtain the attention events and object attribute requirements corresponding to the target object, and to construct the attention event processing set and the attribute requirement set respectively.

[0008] The set of events to be monitored is written to the event management thread in the main business service process, and the set of attribute requirements is written to the attribute management thread in the main business service process.

[0009] When the event of interest is detected by the event management thread, the predefined processing logic corresponding to the event of interest is executed in the subordinate business service process based on the triggered event of interest.

[0010] When a change in attribute information is detected by the attribute management thread, the attribute information synchronization processing corresponding to the changed attribute subset information is performed in the subordinate business service process based on the changed attribute subset information.

[0011] Secondly, this application also provides a business logic processing apparatus. The apparatus includes:

[0012] The login response module is used to respond to login events of the target object and determine the main business service process and the subordinate business service process;

[0013] The collection construction module is used to obtain the attention events and object attribute requirements corresponding to the target object through the subordinate business service process, and construct the attention event processing set and the attribute requirement set respectively.

[0014] The event writing module is used to write the set of events of interest to the event management thread in the main business service process, and to write the set of attribute requirements to the attribute management thread in the main business service process.

[0015] The event-driven module is used to execute the predefined processing logic corresponding to the event of interest in the subordinate business service process when the event management thread identifies that the event of interest has been triggered.

[0016] The attribute synchronization module is used to perform attribute information synchronization processing corresponding to the changed attribute subset information in the subordinate business service process when the attribute management thread detects a change in attribute information.

[0017] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0018] Respond to the login event of the target object to determine the main business service process and the subordinate business service process;

[0019] The subordinate business service process is used to obtain the attention events and object attribute requirements corresponding to the target object, and to construct the attention event processing set and the attribute requirement set respectively.

[0020] The set of events to be monitored is written to the event management thread in the main business service process, and the set of attribute requirements is written to the attribute management thread in the main business service process.

[0021] When the event of interest is detected by the event management thread, the predefined processing logic corresponding to the event of interest is executed in the subordinate business service process based on the triggered event of interest.

[0022] When a change in attribute information is detected by the attribute management thread, the attribute information synchronization processing corresponding to the changed attribute subset information is performed in the subordinate business service process based on the changed attribute subset information.

[0023] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0024] Respond to the login event of the target object to determine the main business service process and the subordinate business service process;

[0025] The subordinate business service process is used to obtain the attention events and object attribute requirements corresponding to the target object, and to construct the attention event processing set and the attribute requirement set respectively.

[0026] The set of events to be monitored is written to the event management thread in the main business service process, and the set of attribute requirements is written to the attribute management thread in the main business service process.

[0027] When the event of interest is detected by the event management thread, the predefined processing logic corresponding to the event of interest is executed in the subordinate business service process based on the triggered event of interest.

[0028] When a change in attribute information is detected by the attribute management thread, the attribute information synchronization processing corresponding to the changed attribute subset information is performed in the subordinate business service process based on the changed attribute subset information.

[0029] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0030] Respond to the login event of the target object to determine the main business service process and the subordinate business service process;

[0031] The subordinate business service process is used to obtain the attention events and object attribute requirements corresponding to the target object, and to construct the attention event processing set and the attribute requirement set respectively.

[0032] The set of events to be monitored is written to the event management thread in the main business service process, and the set of attribute requirements is written to the attribute management thread in the main business service process.

[0033] When the event of interest is detected by the event management thread, the predefined processing logic corresponding to the event of interest is executed in the subordinate business service process based on the triggered event of interest.

[0034] When a change in attribute information is detected by the attribute management thread, the attribute information synchronization processing corresponding to the changed attribute subset information is performed in the subordinate business service process based on the changed attribute subset information.

[0035] The aforementioned business logic processing methods, devices, computer equipment, storage media, and computer program products determine the main business service process and subordinate business service processes by responding to the login event of the target object; through the subordinate business service process, they obtain the attention events and object attribute requirements corresponding to the target object, and construct attention event processing sets and attribute requirement sets respectively; the attention event processing sets are written to the event management thread in the main business service process, and the attribute requirement sets are written to the attribute management thread in the main business service process; when the event management thread identifies that an attention event has been triggered, the predefined processing logic corresponding to the attention event is executed in the subordinate business service process based on the triggered attention event; when the attribute management thread identifies that attribute information has changed, the attribute information synchronization process corresponding to the changed attribute subset information is executed in the subordinate business service process based on the changed attribute subset information. This application achieves dual decoupling of business logic and attribute information by setting attention events and then using the event management thread to drive business logic through events, while extracting the object attribute requirements that the business logic depends on and writing them to the attribute requirement thread to achieve synchronous processing of attribute information. This application can achieve dual decoupling of business logic and attribute information, and can effectively achieve the purpose of service decomposition. Attached Figure Description

[0036] Figure 1 This is an application environment diagram of a business logic processing method in one embodiment;

[0037] Figure 2 This is a flowchart illustrating a business logic processing method in one embodiment;

[0038] Figure 3 This is a flowchart illustrating the steps for identifying and determining events of interest based on event determination attribute information in one embodiment.

[0039] Figure 4 This is a flowchart illustrating the step of writing event resource update data into a preset business resource database in one embodiment.

[0040] Figure 5 This is a flowchart illustrating the cross-process event handling steps in one embodiment;

[0041] Figure 6This is a flowchart illustrating the event resending process in one embodiment;

[0042] Figure 7 This is a flowchart illustrating a scenario in which the event resending process step is not executed in the prior art of one embodiment.

[0043] Figure 8 This is a flowchart illustrating the execution of the event resending process in one embodiment.

[0044] Figure 9 This is a schematic diagram illustrating the coupling of game business logic in one embodiment;

[0045] Figure 10 This is a schematic diagram illustrating the decoupling approach for business logic processing in one embodiment;

[0046] Figure 11 This is a schematic diagram illustrating the principle of event-driven and property synchronization in one embodiment;

[0047] Figure 12 This is a schematic diagram illustrating the principle of the token bucket rate limiting algorithm in one embodiment;

[0048] Figure 13 This is a structural block diagram of a business logic processing device in one embodiment;

[0049] Figure 14 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] The business logic processing method provided in this application embodiment can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104, or it can be located in the cloud or on another network server. The target object can process business on terminal 102, while server 104 provides the environment for business processing. When server 104 detects that the business service provided to the target object has entered the login state, it can determine the main business service process and the subordinate business service process by responding to the target object's login event. Through the subordinate business service process, it obtains the attention events and object attribute requirements corresponding to the target object, and constructs the attention event processing set and the attribute requirement set respectively. The attention event processing set is written to the event management thread in the main business service process, and the attribute requirement set is written to the attribute management thread in the main business service process. When the event management thread detects that an attention event has been triggered, the predefined processing logic corresponding to the attention event is executed in the subordinate business service process based on the triggered attention event. When the attribute management thread detects that attribute information has changed, the attribute information synchronization processing corresponding to the attribute subset information is executed in the subordinate business service process based on the changed attribute subset information. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0052] In this article, it is important to understand the following terms:

[0053] GameSvr: A service process that implements the core game logic.

[0054] PvpSvr: A service process that implements gameplay in specific scenarios.

[0055] TaskSvr: The service process that implements the game task system.

[0056] DB: Database service for storing game data.

[0057] In one embodiment, such as Figure 2 As shown, a business logic processing method is provided, which is applied to... Figure 1 Taking server 104 as an example, the following steps are included:

[0058] Step 201: Respond to the login event of the target object and determine the main business service process and the subordinate business service process.

[0059] Step 203: Obtain the attention events and object attribute requirements corresponding to the target object through the subordinate business service process, and construct the attention event processing set and attribute requirement set respectively.

[0060] Specifically, the target object refers to a user who performs business processing through the business system provided by server 104. Server 104 can remotely provide business system services to the target object through the target object's terminal 102. When the target object logs into the business system through the terminal to perform business processing, the server can recognize that the business service provided to the target object has entered the login state. The main business service process refers to the process used to implement the core business logic. The subordinate business service process specifically refers to the process in the server used to implement various auxiliary businesses. In one embodiment, the main business service process specifically refers to the service process GameSvr that implements the core game logic. The subordinate business service processes specifically include the service process PvpSvr that implements specific scene gameplay and the service process TaskSvr that implements the game task system, etc., which are set according to the needs of the game logic. The subordinate business service processes can interact with the main business service process. In the existing business logic processing, the functions implemented by the subordinate business service processes may be highly coupled with the main business logic. At this time, it is difficult to separate the functions implemented by them into independent modules. The purpose of this application is to decouple the subordinate business service processes from the main business service processes, thereby realizing service splitting. In this embodiment, the use of a subordinate business service process to implement business logic is merely an example of a single service process. In practical applications, multiple different subordinate business service processes can be simultaneously started on server 104 to interact with the main business service process, thereby realizing the business logic processing of this application. The attention events corresponding to the target object are closely related to the subordinate business service process. Server 104 can trigger business logic through changes in the attention events. The attention event processing set is a set constructed based on the attention events, which enables event management for the target object. For example, in one embodiment, the subordinate business service process is used to implement the gameplay of a game. In this case, the attention events corresponding to the target object are the events bound to the task being executed by the target object, and the attention event processing set is the event conditions bound to the task being executed by the target object. Similarly, object attribute requirements are the attributes of the target object needed to implement business logic. By combining all attribute requirements, an attribute requirement set can be constructed. When the subordinate business service process is used to implement the gameplay of a game, the attribute requirement set is the attribute requirement set that players need to use in the task system.

[0061] Specifically, this application is used to decouple the main business service process and the subordinate business service process in business logic. Therefore, when it is detected that the business service provided to the target object has entered the login state, it can be determined that the business service corresponding to the target object needs to be provided, and business logic processing can be performed. At this time, each service process can be driven by events. Taking a specific subordinate business service process as an example, the subordinate business service process first collects the events and corresponding attribute requirements that the target object needs to pay attention to during the process of providing business services to the target object, thereby constructing a set of attention event processing and a set of attribute requirements. In one embodiment, the subordinate business service process is specifically the service process TaskSvr that implements the game task system. When the target object logs into the game, TaskSvr collects the set of event processing that the player needs to pay attention to in the task system (i.e., the event conditions bound to the currently executing task), and sends the collected set of event processing to the service process GameSvr that implements the core game logic, thereby starting the processing of the game business logic.

[0062] Step 205: Write the set of events to be handled to the event management thread in the main business service process, and write the set of attribute requirements to the attribute management thread in the main business service process.

[0063] The event management thread refers to the thread within the main business service process that manages events and implements event-driven operations. The attribute management thread, on the other hand, refers to the thread within the main business service process that manages attributes and implements attribute synchronization.

[0064] Specifically, after constructing the set of events to be handled and the set of attribute requirements, the subordinate business service process can send this data to the main business service process. The main business service process then registers the set of events to be handled with the event management thread of the target object, thereby enabling event-driven management within the main business service process. Simultaneously, the main business service process registers the set of attribute requirements with the attribute management thread of the target object, thereby enabling attribute synchronization management within the main business service process.

[0065] Step 207: When the event management thread identifies that a concern event has been triggered, the predefined processing logic corresponding to the concern event is executed in the subordinate business service process based on the triggered concern event.

[0066] Step 209: When a change in attribute information is detected by the attribute management thread, the attribute information corresponding to the changed attribute subset information is synchronized in the subordinate business service process based on the changed attribute subset information.

[0067] Specifically, the predefined processing logic refers to the pre-set operations based on the subordinate business service process. For example, in one embodiment, if the subordinate business service process is a service process that implements the game task system, then the predefined processing logic may include changing the task state.

[0068] Specifically, when a target object performs business processing on terminal 102, it can trigger events of interest during the processing. The main business service process can then identify the target object's actions that trigger these events through the event management thread. For example, when the target object is playing an in-game task, if it meets the task completion conditions, it can submit the task by clicking on the game interface. The main business service process can then identify this task submission and forward the event to the subordinate business service process. The subordinate business service process then completes the business logic processing after the task is triggered. In one embodiment, before forwarding the event to the subordinate business service process, the main business service process can execute event processing logic once more to filter the event. Only filtered, useful events will be forwarded to the subordinate business service process. For instance, the attribute management thread can determine whether the user has met the task conditions. Only after the task conditions are met will the main business service process forward the event to the subordinate business service process. Meanwhile, server 104 can also synchronize attribute information. When the target object is playing a game, the attributes within the attribute management thread will change according to the player's progress. Whenever some attributes within the attribute management thread change, the main business service process will synchronize this changed information to the subordinate business service process. Thus, the subordinate business service process will possess a subset of the attributes from the main business service process's complete attribute set. Since the complete attribute set contains a lot of information, while the subordinate business service process only needs a smaller subset, unnecessary network consumption is reduced.

[0069] The aforementioned business logic processing method determines the main business service process and subordinate business service processes by responding to the login event of the target object. Through the subordinate business service process, it obtains the attention events and object attribute requirements corresponding to the target object, and constructs attention event processing sets and attribute requirement sets respectively. The attention event processing sets are written to the event management thread in the main business service process, and the attribute requirement sets are written to the attribute management thread in the main business service process. When the event management thread identifies that an attention event has been triggered, the predefined processing logic corresponding to the attention event is executed in the subordinate business service process based on the triggered attention event. When the attribute management thread identifies a change in attribute information, the attribute information synchronization process corresponding to the changed attribute subset information is executed in the subordinate business service process based on the changed attribute subset information. This application achieves dual decoupling of business logic and attribute information by setting attention events and then using the event management thread to drive business logic through events. Simultaneously, it extracts the object attribute requirements that the business logic depends on and writes them to the attribute requirement thread to achieve synchronous processing of attribute information. This application can achieve dual decoupling of business logic and attribute information, effectively achieving the purpose of service decomposition.

[0070] In one embodiment, such as Figure 3 As shown, step 205 includes:

[0071] Step 302: When the event management thread identifies that an event of interest has been triggered, the event judgment attribute information corresponding to the target object is read from the attribute management thread.

[0072] Step 304: When the event of interest is determined to be a useful event based on the event determination attribute information and the preset event triggering processing logic, the predefined processing logic corresponding to the event of interest is executed in the subordinate business service process based on the triggered event of interest.

[0073] The event determination attribute information is used for event determination. The main business service process in server 104 can use this attribute information to determine whether the currently triggered event of interest needs processing, thus filtering out useless events that do not require handling. Useful events are the opposite of useless events. Useful events are those that can be used to execute predefined processing logic in subordinate business service processes, while useless events are those that cannot be used to execute predefined processing logic in subordinate business service processes. For example, in a game's task completion mechanism, if the target object has already met the task completion conditions, then the user-triggered task completion operation is a useful event; if the target object has not met the task completion conditions, then the user-triggered task completion operation is a useless event.

[0074] Specifically, to ensure that only useful events are pushed to subordinate business service processes, guaranteeing the accuracy and timeliness of business logic processing, server 104 can add corresponding event judgment and processing logic before event forwarding. When the event management thread identifies a triggered event, it will not directly send the event to the subordinate business service process. Instead, it will first determine whether the triggered event is a useful event. Only useful events will be forwarded to the subordinate business service process to drive the corresponding game business processing. The judgment can be made using the attribute information corresponding to the target object. Therefore, after a target object triggers a useful event, the main business service process can read the event judgment attribute information corresponding to the target object from the attribute management thread. Based on the event judgment attribute information, the type of the triggered useful event is determined. Only when the useful event is determined will the main business service process forward the event to the subordinate business service process; otherwise, the event will be discarded. In this embodiment, by reading the event determination attribute information to determine the triggered events of interest, it is possible to identify whether the user-triggered events are useful before event-driven forwarding, thereby avoiding the forwarding of useless events to subordinate business service processes and ensuring the processing efficiency of game business logic.

[0075] In one embodiment, step 302 includes: when the event management thread identifies that an event of interest has been triggered, reading the event judgment attribute information corresponding to the target object from the attribute management thread based on the token bucket rate limiting algorithm.

[0076] The token bucket algorithm is a common rate limiting algorithm, and its general process includes the following steps: 1) All requests need a usable token before being processed; 2) Tokens are added to the bucket at a certain rate based on the rate limiting size; 3) The bucket has a maximum limit on the number of tokens it can hold; when the bucket is full, newly added tokens are discarded or rejected; 4) Upon arrival, a request must first obtain a token from the bucket before proceeding with other business logic. After processing the business logic, the token is deleted; 5) The token bucket has a minimum limit. When the number of tokens in the bucket reaches the minimum limit, tokens will not be deleted after the request is processed, thus ensuring sufficient rate limiting. For example, in a game scenario, a large number of events may occur instantaneously, but as long as events are not continuously generated, the total number of events within a certain period may not be high, and there is no need to enable filtering. Other rate limiting algorithms (counters, leaky bucket algorithms) do not satisfy this characteristic. Therefore, this application uses token bucket rate limiting to optimize the timing of event filtering.

[0077] Specifically, since this application adopts an event-driven approach for business logic processing, and the biggest difference between events and messages lies in the publish-subscribe capability of events, in addition to decoupling through event-driven processing, it can also effectively filter useless events and reduce network asynchronous overhead. Because different stages of a task are concerned with different events and have conditional judgment logic, when the event volume (instantaneous) is relatively large, more granular pre-filtering logic can be enabled. Events that do not meet the conditions are not sent to subordinate business service processes. The timing optimization for event filtering can be achieved through token bucket rate limiting. Rate limiting is only enabled when the event traffic is large and all tokens in the token bucket are used up. Useless events are filtered out by reading the event judgment attribute information corresponding to the target object from the attribute management thread. In this embodiment, optimizing the timing of event filtering through token bucket rate limiting can effectively ensure event processing efficiency when the event traffic is large.

[0078] In one embodiment, step 205 includes: when a concern event is detected to be triggered by the event management thread, based on the triggered concern event, executing the predefined processing logic corresponding to the concern event through cross-process event processing in the subordinate business service process.

[0079] Cross-process event handling refers to a special event handling logic that allows the main business service process to complete the event handling logic the moment it receives an event, and can immediately handle subsequent events without waiting for them.

[0080] Specifically, in current business logic processing, the main business service process typically uses a blocking asynchronous model to handle event interactions with multiple different service processes. For example, if a game contains three different processes: Client, DS, and PvpSvr, when all these processes are active, and each process simultaneously generates an event and sends it to the main business service process for processing, and the main business service process itself also generates an event to process, Client's event 1 arrives first. With a blocking asynchronous model, the main business service process needs time to process event 1, so when DS's event 2 arrives, it must first queue in the event queue, waiting for event 1 to be processed before event 2 can be processed. As unprocessed events increase, the event queue accumulates many cached events, and if the main business service process malfunctions, all events in the event queue may be lost. However, if a non-blocking, immediate cross-process event handling model is adopted, the main business service process can complete its event handling logic the instant it receives event 1, and can immediately process event 2 upon receiving it, without waiting or needing an event queue. In this embodiment, the event processing of different service processes is carried out through cross-process event processing, which can effectively avoid event blocking caused by abnormal service processes of core logic and improve the processing efficiency of business logic.

[0081] In one embodiment, such as Figure 4 As shown, step 205 includes:

[0082] Step 401: Obtain event resource update data by executing the predefined processing logic corresponding to the event of interest through cross-process event handling in the subordinate business service process.

[0083] Step 403: Write the event resource update data to the preset business resource database and execute the next event to be monitored corresponding to the currently triggered event.

[0084] Step 405: Obtain the data write result message from the preset business resource database.

[0085] Step 407: When the data write result message is a data write failure message, rewrite the event resource update data to the preset business resource database.

[0086] Specifically, if cross-process event handling is used in the service process, event blocking may occur due to read / write operations on the business resource database. To avoid this blocking, during the execution of predefined processing logic, server 104 first executes the predefined processing logic corresponding to the event of interest. Upon receiving the event resource update data, if it is necessary to save the data to the business resource database (DB), this event resource update data can be directly written to the business resource database without waiting for a response from the game resource data. It is then assumed that the event resource update data has been successfully written, and the next event of interest corresponding to the currently triggered event of interest is executed directly, thus avoiding blocking. However, when a data write failure message is received from the preset business resource database, a retry is required. In this case, the event resource update data needs to be rewritten to the preset business resource database. In one embodiment, the application of cross-process event handling of this application can be referred to... Figure 5 As shown, Figure 5 As shown in the top left diagram, under the existing event queue processing method, if the main business service process GameSvr encounters an error, all events in the event queue may be lost. However, when performing cross-process event processing, GameSvr can process events directly upon receipt without waiting, effectively preventing event loss. When processing events in subordinate business service processes, such as... Figure 5 As shown in the middle and lower left figures, concurrent processing may result in out-of-order processing, while... Figure 5 As shown in the lower middle diagram, serial processing is less efficient, while... Figure 5 As shown in the lower right figure, the processing method in this embodiment is non-blocking and highly efficient. It eliminates the need for an event queue, ensuring high reliability. In this embodiment, by directly writing event resource update data to a preset business resource database without waiting for feedback from the preset business resource database, asynchronous blocking caused by responses from the preset business resource database can be effectively avoided, thus improving event processing efficiency.

[0087] In one embodiment, such as Figure 6 As shown, after executing the predefined processing logic corresponding to the event of interest in the subordinate business service process, the following is also included:

[0088] Step 601: Read the event processing result message returned by the subordinate business service process.

[0089] Step 603: Extract the updated data of the attention event handling set from the event handling result message.

[0090] Step 605: Update the event management thread of the target object based on the update data of the event handling set.

[0091] Step 607: Perform event resending processing based on the event management thread of the updated target object.

[0092] In this process, after executing predefined processing logic, the subordinate business service process can generate corresponding event processing results. These results are then fed back to the main business service process. The event processing result message contains the processing results of the predefined processing logic for the events of interest. Furthermore, the event processing result message also includes updated data for the events of interest, used to update the events of interest within the event management thread of the main business service process.

[0093] Specifically, this application also includes an event resending process between event processing steps. Event resending is mainly used to promptly resend events after changes occur in events of interest, thereby preventing event loss. In one specific embodiment, such as... Figure 7 As shown, the main business service process is GameSvr, and the subordinate business service process is TaskSvr. In the initial game business processing process, the events of interest for the target object only include events 1 and 5. If a new event, event 3, is generated, but GameSvr generates event 3 before the new event is passed to GameSvr, GameSvr, unaware that event 3 needs to be monitored, filters it out. This results in the loss of event 3, which should have been triggered by the subordinate business service process TaskSvr. In this case, the loss of event 3 can be avoided through event resending, such as... Figure 8 As shown, an index is added to the event, and both Gemsvr and TaskSvr maintain the current processing index. When GameSvr generates event 1, it sets the index seq of event 1 to 1, and the index curseq of the currently processed events in GameSvr is 0. After receiving event 1, TaskSvr finds that the filter set is empty, so it immediately processes event 1 and sets its own processed index m_CurSeq to the value of event 1's index 1. Simultaneously, in the reply message, it notifies GameSvr that the event with index seq=1 has been processed, i.e., AckSeq=1. Before receiving this reply, GameSvr had already generated event 3 with index seq=101 and cached this event in the queue. Then, event number 5 with seq=201 was generated. When event number 5 was sent to TaskSvr, the event set in the cache queue was also included as a filter set. When TaskSvr received event number 5 with seq=201, it found that the filter set included the newly added event number 3, so it suspended the processing logic of event number 5 and waited for GameSvr to resend event number 3, thus preventing event loss. In this embodiment, by adding an event resending mechanism, event loss during event processing can be effectively prevented, ensuring the accuracy of business logic processing.

[0094] This application also provides an application scenario in which the above-described business logic processing method is applied. Specifically, the application of the business logic processing method in this scenario is as follows:

[0095] When users play mobile games via mobile devices, the business logic processing methods described in this application can be used to implement the mobile game's business logic. For example, regarding gameplay mechanics in mobile games, such as... Figure 9 As shown in the left-middle figure, in a solution without this technology enabled, the task and context information are highly coupled, making it difficult to separate the task gameplay from the core game business logic. However... Figure 9 The diagram in the middle section shows the solution used in this application to decompose the logic using an event and attribute system. Figure 9 The diagram on the right shows a further microservice breakdown based on the event and attribute system decomposition logic. The task system is split into independent TaskSvr instances, which store data in a database, achieving stateless clustering of the TaskSvr service. The decoupling approach for business logic processing in this application can be referenced. Figure 10 As shown, the specific principles of event-driven and attribute synchronization in business logic processing can be found in [reference needed]. Figure 11As shown, after a player logs into the game, TaskSvr collects a set of event handling rules that the player needs to follow in the task system (i.e., the event conditions bound to the currently executing task). The collected event handling rules are then sent to GameSvr, which registers them with the player event management thread. When a player's event is triggered on GameSvr, the corresponding event handling logic 1 is executed (this logic can be filtered or not, and the event is directly forwarded to TaskSvr for processing). This event handling logic can use the player's attribute information for judgment. If the event handling logic fails the judgment, the event is discarded (i.e., useless events are filtered). If the judgment passes, the event is sent to TaskSvr. TaskSvr also has a player event management thread that has registered the event handling logic 2. Handling logic 2 can perform some custom operations, including changing the task status, and can also use some attribute information synchronized from GameSvr. After a player logs into the game, TaskSvr, in addition to collecting event handling logic, also collects the set of attributes the player needs in the task system. It sends this required attribute set to GameSvr, which registers it in the attribute system. Initially, all registered attributes are sent to TaskSvr at once. Subsequently, whenever these attributes change, GameSvr synchronizes the change information to TaskSvr. Thus, TaskSvr will possess a subset of the attributes from GameSvr's complete attribute set. The complete attribute set contains a lot of information, while the subset of attributes needed by TaskSvr is relatively small, reducing unnecessary network consumption. Furthermore, this application's solution employs cross-process event handling to prevent event loss due to event queue congestion. When storing data in the database (DB), to avoid blocking, the data is considered successfully written without waiting for a response from the DB. If the data write fails, it is rewritten later. In addition, this application effectively filters unnecessary events, thereby reducing asynchronous network overhead. During filtering, conditional judgment logic can be implemented. When the event volume (instantaneous) is large, more granular pre-filtering logic can be enabled, and events that do not meet the conditions will not be sent to TaskSvr. This application specifically optimizes the timing of event filtering based on the token bucket rate limiting algorithm; for details, please refer to [reference needed]. Figure 12As shown, TaskSvr is the service process implementing the game task system, and GameSvr is the service process implementing the core game logic. First, TaskSvr sets up a set of all events it is interested in, {1, 3, 5}, based on its configuration. When the filtering mechanism is not enabled, all events are not stored in the cache queue; they are either sent immediately or discarded directly, and invalid events not in the event set are discarded. When a large number of invalid events deplete the token bucket, it switches to more granular time-based filtering. During this process, most of the conditions for event 5 are not met, so they are filtered and added to the cache queue. Simultaneously, the conditions for event 3 are also not met, so they are filtered and added to the cache queue. After TaskSvr processes event 1, it can add the condition ackseq=1 for event 3 to allow for a resend operation for event 1 in GameSvr. The condition filtering confirmation mechanism is only disabled when the token bucket capacity is full, the ackseq of the previous time is received, and the queue for discarding time caches is empty.

[0096] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to 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 flowcharts of the above embodiments 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 of other steps.

[0097] Based on the same inventive concept, this application also provides a business logic processing apparatus for implementing the business logic processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more business logic processing apparatus embodiments provided below can be found in the limitations of the business logic processing method described above, and will not be repeated here.

[0098] In one embodiment, such as Figure 13 As shown, a business logic processing device is provided, including: a collection construction module, an event registration module, and a logic processing module, wherein:

[0099] The login response module 1302 is used to respond to login events of the target object and determine the main business service process and the subordinate business service process.

[0100] The collection construction module 1304 is used to obtain the attention events and object attribute requirements corresponding to the target object through the subordinate business service process, and construct the attention event processing set and the attribute requirement set respectively.

[0101] The event writing module 1306 is used to write the set of events of interest to the event management thread in the main business service process, and to write the set of attribute requirements to the attribute management thread in the main business service process.

[0102] The event-driven module 1308 is used to execute the predefined processing logic corresponding to the event of interest in the subordinate business service process when the event management thread identifies that an event of interest has been triggered.

[0103] The attribute synchronization module 1310 is used to perform attribute information synchronization processing corresponding to the changed attribute subset information in the subordinate business service process when the attribute management thread detects a change in attribute information.

[0104] In one embodiment, the event-driven module 1308 is specifically used to: when the event management thread identifies that a focus event has been triggered, read the event judgment attribute information corresponding to the target object from the attribute management thread; when the focus event is determined to be a useful event based on the event judgment attribute information and the preset event triggering processing logic, execute the predefined processing logic corresponding to the focus event in the subordinate business service process based on the triggered focus event.

[0105] In one embodiment, the event-driven module 1308 is further configured to: when the event management thread identifies that an event of interest has been triggered, read the event judgment attribute information corresponding to the target object from the attribute management thread based on the token bucket rate limiting algorithm.

[0106] In one embodiment, the event-driven module 1308 is further configured to: when a concerned event is detected by the event management thread, execute the predefined processing logic corresponding to the concerned event in the subordinate business service process through cross-process event processing based on the triggered concerned event.

[0107] In one embodiment, the event-driven module 1308 is further configured to: obtain event resource update data by executing predefined processing logic corresponding to the event of interest through cross-process event processing in the subordinate business service process; write the event resource update data to a preset business resource database; execute the next event of interest corresponding to the currently triggered event of interest; obtain the data writing result message fed back by the preset business resource database; and when the data writing result message is a data writing failure message, rewrite the event resource update data to the preset business resource database.

[0108] In one embodiment, an event resending module is further included, which is used to: read the event processing result message fed back by the subordinate business service process; extract the update data of the attention event processing set from the event processing result message; update the event management thread based on the update data of the attention event processing set; and perform event resending processing according to the updated event management thread.

[0109] Each module in the aforementioned business logic processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0110] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 14 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data generated during business logic processing. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a business logic processing method.

[0111] Those skilled in the art will understand that Figure 14 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0112] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0113] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0114] In one embodiment, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, causing the computer device to perform the steps in the above method embodiments.

[0115] It should 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 analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0116] 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 computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0117] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0118] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A business logic processing method, characterized in that, The method includes: Respond to the login event of the target object to determine the main business service process and the subordinate business service process; The subordinate business service process is used to obtain the attention events and object attribute requirements corresponding to the target object, and to construct the attention event processing set and the attribute requirement set respectively. The set of events to be monitored is written to the event management thread in the main business service process, and the set of attribute requirements is written to the attribute management thread in the main business service process. When the event management thread identifies that the event of interest has been triggered, the event judgment attribute information corresponding to the target object is read from the attribute management thread; when the event of interest is determined to be a useful event based on the event judgment attribute information and the preset event triggering processing logic, the predefined processing logic corresponding to the event of interest is executed in the subordinate business service process based on the triggered event of interest. When a change in attribute information is detected by the attribute management thread, the attribute information synchronization processing corresponding to the changed attribute subset information is performed in the subordinate business service process based on the changed attribute subset information.

2. The method according to claim 1, characterized in that, The step of reading the event determination attribute information corresponding to the target object from the attribute management thread when the event management thread identifies that the event of interest has been triggered includes: When the event of interest is detected by the event management thread, the event judgment attribute information corresponding to the target object is read from the attribute management thread based on the token bucket rate limiting algorithm.

3. The method according to claim 1, characterized in that, When the event of interest is determined to be a useful event based on the event determination attribute information and the preset event triggering processing logic, the execution of the predefined processing logic corresponding to the event of interest in the subordinate business service process based on the triggered event of interest includes: When the event of interest is determined to be a useful event based on the event determination attribute information and the preset event triggering processing logic, the predefined processing logic corresponding to the event of interest is executed in the subordinate business service process through cross-process event processing based on the triggered event of interest.

4. The method according to claim 3, characterized in that, The execution of the predefined processing logic corresponding to the event of interest through cross-process event handling in the subordinate business service process includes: By executing the predefined processing logic corresponding to the event of interest through cross-process event processing in the subordinate business service process, event resource update data is obtained; Write the event resource update data to the preset business resource database, and execute the next attention event corresponding to the currently triggered attention event; Retrieve the data write result message from the preset business resource database; When the data write result message is a data write failure message, the event resource update data is rewritten to the preset business resource database.

5. The method according to any one of claims 1 to 4, characterized in that, After executing the predefined processing logic corresponding to the attention event in the subordinate business service process, the process further includes: Read the event handling result messages returned by the subordinate business service process; Extract the updated data of the attention event processing set from the event processing result message; The event management thread is updated based on the updated data of the event handling set. The updated event management thread will perform event resending processing.

6. A business logic processing device, characterized in that, The device includes: The login response module is used to respond to login events of the target object and determine the main business service process and the subordinate business service process; The collection construction module is used to obtain the attention events and object attribute requirements corresponding to the target object through the subordinate business service process, and construct the attention event processing set and the attribute requirement set respectively. The event writing module is used to write the set of events of interest to the event management thread in the main business service process, and to write the set of attribute requirements to the attribute management thread in the main business service process. The event-driven module is used to read the event judgment attribute information corresponding to the target object from the attribute management thread when the event management thread identifies that the event of interest has been triggered; and to execute the predefined processing logic corresponding to the event of interest in the subordinate business service process based on the event judgment attribute information and the preset event triggering processing logic when the event of interest is determined to be a useful event based on the triggered event of interest. The attribute synchronization module is used to perform attribute information synchronization processing corresponding to the changed attribute subset information in the subordinate business service process when the attribute management thread detects a change in attribute information.

7. The apparatus according to claim 6, characterized in that, The event-driven module is specifically used to: when the event management thread identifies that the event of interest has been triggered, read the event judgment attribute information corresponding to the target object from the attribute management thread based on the token bucket rate limiting algorithm.

8. The apparatus according to claim 6, characterized in that, The event-driven module is further configured to: when the event of interest is determined to be a useful event based on the event determination attribute information and the preset event triggering processing logic, execute the predefined processing logic corresponding to the event of interest in the subordinate business service process through cross-process event processing based on the triggered event of interest.

9. The apparatus according to claim 8, characterized in that, The event-driven module is also used to: execute the predefined processing logic corresponding to the event of interest through cross-process event processing in the subordinate business service process to obtain event resource update data; write the event resource update data to a preset business resource database and execute the next event of interest corresponding to the currently triggered event of interest; Retrieve the data write result message from the preset business resource database; When the data write result message is a data write failure message, the event resource update data is rewritten to the preset business resource database.

10. The apparatus according to any one of claims 6 to 9, characterized in that, It also includes an event resending module, used to: read event processing result messages fed back by subordinate business service processes; and extract update data of the attention event processing set from the event processing result messages; The event management thread is updated based on the updated data of the event handling set. The updated event management thread will perform event resending processing.

11. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

Images