Business processing methods, apparatus, computer equipment and business processing systems

Abstract

This application relates to a business processing method, apparatus, computer equipment, computer-readable storage medium, computer program product, and business processing system. The method includes: receiving a business processing request sent by a first business server, the business processing request carrying a client identifier and a target scene identifier; determining a second business server associated with the target scene identifier; if the second business server is different from the first business server, feeding back a first link relationship modification instruction to a first access layer of the first business server, and feeding back a second link relationship modification instruction to a second intermediary layer of the second business server; and migrating business information corresponding to the client identifier to the target scene through a data path between the first and second business servers. Using this method, cross-server migration of business information can be achieved while improving machine utilization and reducing costs.

Description

Technical Field

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

[0002] With the development of computer technology, online games have developed rapidly, giving rise to genres such as racing games, shooting games, strategy games, and action role-playing games. In massively multiplayer online role-playing games (MMORPGs), new gameplay modes and scenarios are often introduced to increase the novelty of gameplay, leading to the emergence of cross-server gameplay.

[0003] In traditional technologies, migrating client-identified business information across servers to new business scenarios requires adding a dedicated cross-server server to handle cross-server business, as well as a dedicated data path between the cross-server server and the original business server, on top of the existing game server architecture. The new business scenario is then established on the dedicated cross-server server, and the client-identified business information is migrated across servers to the new business scenario via the dedicated data path. On the one hand, adding a dedicated cross-server server and dedicated data path increases costs. On the other hand, since the newly added dedicated cross-server server is idle when there is no cross-server gameplay, its utilization rate is low, which is not conducive to saving resources and energy. Therefore, the traditional business processing method has the disadvantage of high cost. Summary of the Invention

[0004] Therefore, it is necessary to provide a business processing method, apparatus, computer equipment, computer-readable storage medium, computer program product, and business processing system that can reduce costs in response to the above-mentioned technical problems.

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

[0006] Receive a service processing request sent by the first service server, the service processing request carrying a client identifier and a target scene identifier;

[0007] Identify the second service server associated with the target scene identifier;

[0008] If the second service server is different from the first service server, a first link relationship modification instruction is fed back to the first access layer of the first service server, and a second link relationship modification instruction is fed back to the second intermediary layer of the second service server. The first link relationship modification instruction is used to instruct the first access layer to modify the first link relationship corresponding to the client identifier from the first access layer and the first intermediary layer of the first service server to the first access layer and the second intermediary layer. The second link relationship modification instruction is used to instruct the second intermediary layer to add a second link relationship corresponding to the client identifier. The second link relationship is a link between the second intermediary layer and the second service component associated with the target scene identifier of the second service server.

[0009] The business information corresponding to the client identifier is migrated to the target scenario through the data path between the first business server and the second business server.

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

[0011] If the second business server is the same as the first business server, a third link relationship modification instruction is sent to the first intermediary layer. The third link relationship modification instruction is used to instruct the first intermediary layer to modify the third link relationship corresponding to the client identifier from the first business component link associated with the first scene identifier of the first intermediary layer and the first business server to the third business component link associated with the target scene identifier of the first intermediary layer.

[0012] In one embodiment, there are two or more business components corresponding to the target scene identifier; before receiving the business processing request sent by the first business server, the method further includes:

[0013] When the preset opening conditions of the target scene associated with the target scene identifier are met, the scene opening interface is displayed to the client corresponding to the client identifier according to the attribute feature information corresponding to the client identifier; the second business component associated with the scene opening interface matches the attribute feature information.

[0014] In one embodiment, the method for determining the load weight of the service server includes:

[0015] Obtain business scenario information for each business scenario associated with the business server, and determine the scenario load weight for each business scenario based on the business scenario information.

[0016] The load weight of the business server is determined based on the scenario load weight of each business scenario.

[0017] In one embodiment, the business scenario information includes the maximum number of concurrently existing NPCs (non-player characters) and the maximum number of participants. The scenario load weight is determined based on the business scenario information, including:

[0018] Multiply the maximum number of NPCs that can exist simultaneously by the NPC correlation coefficient to obtain the NPC load, and multiply the maximum number of participants by the number of participants correlation coefficient to obtain the number of participants load;

[0019] Based on the NPC load and the number of users load, determine the scenario load weight of the business scenario associated with the business scenario information.

[0020] In one embodiment, the service processing request carries a timestamp; migrating the service information corresponding to the client identifier to the target scenario through the data path between the first service server and the second service server further includes:

[0021] Based on the order of the timestamps carried in the business processing requests, a jump-out request is sent to the first business server, and a jump-in request is sent to the second business server.

[0022] In one embodiment, the method further includes: adding the business processing request to a business request queue in a first-in-first-out order; migrating the business information corresponding to the client identifier to the target scenario through the data path between the first business server and the second business server, and further includes:

[0023] The service processing requests are retrieved sequentially from the service request queue;

[0024] Based on the business processing request, in the order of first-in-first-out, add the jump-in request corresponding to the business processing request to the jump-in request queue; in the order of first-in-first-out, add the jump-out request corresponding to the business processing request to the jump-out request queue.

[0025] The jump request is retrieved from the jump request queue and sent to the first service server. The jump request is retrieved from the jump request queue and sent to the second service server.

[0026] Secondly, this application also provides an object processing apparatus. The apparatus includes:

[0027] The business processing request receiving module is used to receive a business processing request sent by the first business server, wherein the business processing request carries a client identifier and a target scenario identifier.

[0028] The business server determination module is used to determine the second business server associated with the target scene identifier;

[0029] The link relationship modification module is used to, if the second business server determined by the business server determination module is different from the first business server, feed back a first link relationship modification instruction to the first access layer of the first business server and a second link relationship modification instruction to the second intermediary layer of the second business server; the first link relationship modification instruction is used to instruct the first access layer to modify the first link relationship corresponding to the client identifier from the first access layer and the first intermediary layer of the first business server to the first access layer and the second intermediary layer; the second link relationship modification instruction is used to instruct the second intermediary layer to add a second link relationship corresponding to the client identifier, the second link relationship being a link between the second intermediary layer and the second business component associated with the target scene identifier of the second business server;

[0030] The business information migration module is used to migrate the business information corresponding to the client identifier to the target scenario through the data path between the first business server and the second business server.

[0031] 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:

[0032] Receive a service processing request sent by the first service server, the service processing request carrying a client identifier and a target scene identifier;

[0033] Identify the second service server associated with the target scene identifier;

[0034] If the second service server is different from the first service server, a first link relationship modification instruction is fed back to the first access layer of the first service server, and a second link relationship modification instruction is fed back to the second intermediary layer of the second service server. The first link relationship modification instruction is used to instruct the first access layer to modify the first link relationship corresponding to the client identifier from the first access layer and the first intermediary layer of the first service server to the first access layer and the second intermediary layer. The second link relationship modification instruction is used to instruct the second intermediary layer to add a second link relationship corresponding to the client identifier. The second link relationship is a link between the second intermediary layer and the second service component associated with the target scene identifier of the second service server.

[0035] The business information corresponding to the client identifier is migrated to the target scenario through the data path between the first business server and the second business server.

[0036] 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:

[0037] Receive a service processing request sent by the first service server, the service processing request carrying a client identifier and a target scene identifier;

[0038] Identify the second service server associated with the target scene identifier;

[0039] If the second service server is different from the first service server, a first link relationship modification instruction is fed back to the first access layer of the first service server, and a second link relationship modification instruction is fed back to the second intermediary layer of the second service server. The first link relationship modification instruction is used to instruct the first access layer to modify the first link relationship corresponding to the client identifier from the first access layer and the first intermediary layer of the first service server to the first access layer and the second intermediary layer. The second link relationship modification instruction is used to instruct the second intermediary layer to add a second link relationship corresponding to the client identifier. The second link relationship is a link between the second intermediary layer and the second service component associated with the target scene identifier of the second service server.

[0040] The business information corresponding to the client identifier is migrated to the target scenario through the data path between the first business server and the second business server.

[0041] 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:

[0042] Receive a service processing request sent by the first service server, the service processing request carrying a client identifier and a target scene identifier;

[0043] Identify the second service server associated with the target scene identifier;

[0044] If the second service server is different from the first service server, a first link relationship modification instruction is fed back to the first access layer of the first service server, and a second link relationship modification instruction is fed back to the second intermediary layer of the second service server. The first link relationship modification instruction is used to instruct the first access layer to modify the first link relationship corresponding to the client identifier from the first access layer and the first intermediary layer of the first service server to the first access layer and the second intermediary layer. The second link relationship modification instruction is used to instruct the second intermediary layer to add a second link relationship corresponding to the client identifier. The second link relationship is a link between the second intermediary layer and the second service component associated with the target scene identifier of the second service server.

[0045] The business information corresponding to the client identifier is migrated to the target scenario through the data path between the first business server and the second business server.

[0046] Sixthly, this application also provides a business processing system. The system includes: a global server and a business server, the global server being communicatively connected to the business server, and the business server including at least a first business server and a second business server;

[0047] The first service server receives a service processing request sent by the client. The service processing request carries a client identifier and a target scene identifier. If the first scene identifier of the service scene received by the first service server is different from the target scene identifier, the service processing request is forwarded to the global server.

[0048] The global server receives the service processing request and determines the second service server associated with the target scene identifier; it feeds back a first link relationship modification instruction to the first access layer of the first service server and a second link relationship modification instruction to the second intermediary layer of the second service server; the first link relationship modification instruction is used to instruct the first access layer to modify the first link relationship corresponding to the client identifier from the first access layer and the first intermediary layer of the first service server to the first access layer and the second intermediary layer; the second link relationship modification instruction is used to instruct the second intermediary layer to add a second link relationship corresponding to the client identifier, the second link relationship being a link between the second intermediary layer and the second service component associated with the target scene identifier of the second service server;

[0049] The global server also migrates the business information corresponding to the client identifier to the target scenario through the data path between the first business server and the second business server.

[0050] In one embodiment, the service server further includes a central control node, which is linked to the communication layer of the service server; the central control node is used to receive the service processing request, and is also used to determine whether the first scene identifier and the target scene identifier are associated with the same service server, and when the first scene identifier and the target scene identifier are associated with different service servers, forward the service processing request to the global server.

[0051] When the aforementioned business processing method, apparatus, computer equipment, storage medium, computer program product, and business processing system need to migrate business information corresponding to a client identifier across servers, it sends a first link relationship modification instruction to the first access layer of the first business server connected to the client. This instruction instructs the first access layer to change the first link relationship corresponding to the client identifier from a link between the first access layer and the first intermediary layer of the first business server to a link between the first access layer and the second intermediary layer of the second business server. It then sends a second link relationship modification instruction to the second intermediary layer of the second business server, instructing the second intermediary layer to add a second link relationship corresponding to the client identifier. This second link relationship is a link between the second intermediary layer and the second business component associated with the target scene identifier of the second business server. After the link relationship is modified, the client can sequentially link to the second business component associated with the target scene identifier through the first access layer and the second intermediary layer. This is equivalent to changing the business component linked to the client without adding additional data paths, allowing the client to access the target scene on the second business server, which is different from the first business server. Furthermore, by migrating the business information corresponding to the client identifier to the target scene through the data path between the first and second business servers, cross-server migration of business information can be achieved without adding additional servers. The above technical solutions work together to achieve cross-server migration of business information, improve machine utilization, and help reduce costs. Attached Figure Description

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

[0053] Figure 2 This is a structural block diagram of a business processing system in one embodiment;

[0054] Figure 3 This is a block diagram of the business processing system in another embodiment;

[0055] Figure 4 This is a flowchart illustrating a business processing method in one embodiment;

[0056] Figure 5 This is a flowchart illustrating the process of creating a new business scenario in one embodiment;

[0057] Figure 6 This is a flowchart illustrating how the load weight of a service server is determined in one embodiment.

[0058] Figure 7 This is a schematic diagram of the process for determining the scenario load weight of a business scenario based on business scenario information in one embodiment.

[0059] Figure 8 This is a flowchart illustrating how the load weight of the service server is determined in another embodiment.

[0060] Figure 9 This is a schematic diagram of a process in one embodiment to migrate business information corresponding to a client identifier to a target scenario through a data path between a first business server and a second business server.

[0061] Figure 10 This is a schematic diagram of a weight reporting mechanism in one embodiment;

[0062] Figure 11 This is a schematic diagram of a bidirectional jump server queue in one embodiment;

[0063] Figure 12 This is a schematic diagram of the service jump request processing sequence in one embodiment;

[0064] Figure 13 This is a structural block diagram of a service processing device in one embodiment;

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

[0066] 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.

[0067] The business processing method provided in this application embodiment can be applied to, for example, Figure 1The application environment is shown. Terminal 102 communicates with the business processing system 104 via a network. A data storage system can store the data that the business processing system 104 needs to process. This data storage system can be integrated into a server within the business processing system 104, or it can be located in the cloud or on other servers. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. The business processing system 104 is implemented by a server cluster consisting of multiple servers.

[0068] In one embodiment, a business processing system is provided. For example... Figure 2 As shown, the system includes a global server 210 and a business server 220. The global server 210 and the business server 220 are communicatively connected. The business server 220 includes at least a first business server 221 and a second business server 222.

[0069] During the execution of the business processing method: First business server 221 receives a business processing request sent by a client. This request carries a client identifier and a target scenario identifier. If the first scenario identifier of the business scenario received by first business server 221 differs from the target scenario identifier, the request is forwarded to global server 210. Global server 210 receives the business processing request and determines the second business server 222 associated with the target scenario identifier. If the second business server 222 differs from first business server 221, it sends a first link relationship modification instruction to the first access layer of first business server 221 and sends a second intermediary instruction to the second business server 222. The first access layer provides feedback on the second link relationship modification instruction; the first link relationship modification instruction is used to instruct the first access layer to modify the first link relationship corresponding to the client identifier, from the first access layer linking with the first intermediary layer of the first service server 221, to the first access layer linking with the second intermediary layer; the second link relationship modification instruction is used to instruct the second intermediary layer to add a second link relationship corresponding to the client identifier, the second link relationship being a link between the second intermediary layer and the target scene identifier of the second service server 222 as a second service component link; the global server 210 also migrates the service information corresponding to the client identifier to the target scene through the data path between the first service server 221 and the second service server 222.

[0070] In this system, the terminal connects to the business scenario on the business server 220 via the client. The global server 210 is responsible for processing the business of multiple business servers 220, such as distributing benefits and notifications to all client players. The first business server 221 is the business server where the business scenario currently connected to by the client resides, and the second business server 222 is the business server where the target scenario requested by the client resides. The data path between the first business server 221 and the second business server 222 refers to the data path from the first business server 221 to the second business server 222 via the global server 210.

[0071] Specifically, each business server 220 carries a business scenario, and each business scenario can be implemented through a corresponding core gameplay logic process. The client terminal communicates with the business server where the business scenario resides through the business scenario linked to the client. The business processing requests sent by the client to the currently linked business scenario include requests within the business logic scope of the first business server 221, such as processing requests that conform to the gameplay logic of the currently linked business scenario. For this type of business processing request, the first business server 221 directly responds to the business processing request. The business processing requests sent by the client to the first business server 221 where the currently linked business scenario resides also include requests that exceed the business logic scope of the first business server 221, such as requests to join a target scenario in the second business server 222. For this type of business processing request, the first business server 221 forwards the business processing request to the global server 210, and then the global server 210 processes the request.

[0072] When the aforementioned business processing system needs to migrate business information corresponding to a client identifier across servers, it sends a first link relationship modification instruction to the first access layer connected to the client. This instruction instructs the first access layer to change the first link relationship corresponding to the client identifier from a first intermediary layer linking the first access layer to the first business server to a second intermediary layer linking the first access layer to the second business server. Simultaneously, it sends a second link relationship modification instruction to the second intermediary layer of the second business server, instructing the second intermediary layer to add a second link relationship corresponding to the client identifier. This second link relationship links the second intermediary layer to the second business component associated with the target scenario identifier on the second business server. After this link relationship modification, the client can sequentially connect to the second business component associated with the target scenario identifier through the first access layer and the second intermediary layer. This is equivalent to changing the business component linked to the client without adding additional data paths, allowing the client to access the target scenario on the second business server, which is different from the first business server. Furthermore, the business information corresponding to the client identifier is migrated to the target scenario through the data path between the first and second business servers, effectively achieving cross-server migration of business information without adding additional servers. The combined technical solutions can improve machine utilization and reduce costs while achieving cross-server migration of business information.

[0073] In one embodiment, such as Figure 3 As shown, the first service server 221 includes a first access layer 311, a first intermediary layer 312, a first service layer 313, and a first communication layer 314 linked in sequence; the second service server 222 includes a second access layer 321, a second intermediary layer 322, a second service layer 323, and a second communication layer 324 linked in sequence; the first service layer 313 and the second service layer 323 are used to carry service scenarios; the first communication layer 314 and the second communication layer 324 are linked to the global server 210. The first access layer 311 is also used to link the client and the second intermediary layer 322; the second access layer 321 is also used to link the client and the first intermediary layer 312.

[0074] The access layer handles access authentication; the intermediary layer handles message forwarding and decoupling; the business layer handles the implementation of core logic; and the communication layer is responsible for message forwarding, which can be implemented through a stateless forwarding process. The first access layer 311 and the second access layer 321 each include at least one access component, and the client connects to the business server through one of these access components. Figure 3 In this context, the client can connect to the service server through the second access component in the first access layer 311. Furthermore, the first service layer 313 and the second service layer 323 each include at least one service component, each carrying a corresponding service scenario, and the gameplay logic of each service scenario can be the same or different. For example... Figure 3 In the first business layer 313, a first business component and a third business component may be included, and the second business layer 323 may include a second business component and a fourth business component.

[0075] Specifically, each access component in the access layer can connect to the intermediary layer of all business servers, such as... Figure 3 In this system, the access components in the first access layer 311 form an access component cluster. Each access component in the cluster can connect to the first intermediary layer 312 of the first service server 221 and the second intermediary layer 322 of the second service server 222. Each service component in the service layer of the service server can connect to the intermediary layer and communication layer of that service server. The client sends service processing requests to the service scenarios carried in the service components linked by the intermediary layer through its connected access layer and intermediary layer. Each service scenario only processes requests within its corresponding business logic scope and forwards requests outside the business logic scope through the communication layer.

[0076] Taking the first service layer 313 of the first service server 221 as an example, which includes two service components, and the client connects to the first service scenario within the first service component. The service processing request forwarded by the first service scenario to the first communication layer 314 includes a target scenario identifier that is different from the first scenario identifier of the first service scenario. For example... Figure 3 As shown, the business component where the target scenario is located, corresponding to the target scenario identifier, falls into one of the following three categories: First, the target scenario is associated with the same business component as the first business scenario, both being the first business component; Second, the target scenario is associated with the same business server as the first business scenario, but the business components are different, for example, the business component where the target scenario is located is the third business component of the first business server 221; Third, the target scenario is associated with a different business server than the first business scenario, for example, the business component where the target scenario is located is the second business component of the second business server 222.

[0077] Therefore, the forwarding object of the service processing request in the communication layer is not unique.

[0078] In one embodiment, the forwarding object for the service processing request in the communication layer includes the global server 210. For example... Figure 3 As shown, the communication layer forwards the service processing request to the global communication layer 214 of the global server 210, and then the service layer in the global server 210 obtains the service processing request from the global communication layer 214 and responds to the service processing request after obtaining it.

[0079] In the first case, the global server 210 migrates the business information corresponding to the client identifier from the first business scenario of the first business component to the target scenario in the first business component through the first communication layer 314.

[0080] In response to the second scenario, on the one hand, the global server 210 sends a third link relationship modification instruction to the first intermediary layer 312. This instruction instructs the first intermediary layer 312 to modify the third link relationship corresponding to the client identifier from the first service component link associated with the first scenario identifier of the first intermediary layer 312 to the third service component link associated with the target scenario identifier. On the other hand, the global server 210 migrates the service information corresponding to the client identifier from the first service scenario in the first service component to the target scenario in the third service component through the first communication layer 314.

[0081] Regarding the third scenario, on one hand, the global server 210 sends a first link relationship modification instruction to the first access layer 311 and a second link relationship modification instruction to the second intermediary layer 322. The first link relationship modification instruction instructs the first access layer 311 to modify the first link relationship corresponding to the client identifier from a link between the first access layer 311 and the first intermediary layer 312 to a link between the first access layer 311 and the second intermediary layer 322. The second link relationship modification instruction instructs the second intermediary layer 322 to add a second link relationship corresponding to the client identifier, which is a link between the second intermediary layer 322 and the second business component associated with the target scenario. On the other hand, the global server 210 also migrates the business information corresponding to the client identifier from the first business scenario in the first business component to the target scenario in the second business component through the data path between the first business component and the second business component. For example... Figure 3 As shown, the data path between the first service component and the second service component is, in sequence, the first service component, the first communication layer 314, the global communication layer 214, the second communication layer 324, and the second service component.

[0082] In one embodiment, the service server may further include a central control node, which is linked to the communication layer of the service server. The central control node is used to receive service processing requests and to determine whether the first scene identifier and the target scene identifier are associated with the same service server. If the first scene identifier and the target scene identifier are associated with different service servers, the central control node forwards the service processing request to the global server.

[0083] It is understood that, in this embodiment, the forwarding object of the service processing request in the communication layer includes the central control node. The central control node possesses the status information of each service component in the same service server's service layer, including the service scenarios carried by each component and the operational logic of each service scenario. For example... Figure 3In the first business server 221, there is a first central control node 315 that is linked to the first communication layer 314. The first central control node 315 knows the scene identifiers of each business scenario carried in the first business component and the third business component in the first business layer 313, as well as the gameplay logic corresponding to each scene identifier.

[0084] Specifically, the first communication layer 314 first forwards the service processing request to the first central control node 315. The first central control node 315 can compare the service scenario identifier corresponding to each service scenario with the target scenario identifier based on the service scenarios carried by each service component in the first service server 221. It then determines whether the service server associated with the target scenario identifier carried in the service processing request is the first service server 221 associated with the first scenario identifier of the service scenario receiving the service processing request. If there is a service scenario identifier in the first service server 221 that matches the target scenario identifier, then the service server associated with the target scenario identifier is the first service server 211, corresponding to the first and second cases mentioned above. If there is no service scenario identifier in the first service server 221 that matches the target scenario identifier, then the service server associated with the target scenario identifier is not the first service server 211, corresponding to the third case mentioned above. In the third scenario, the first central control node 315 returns the service processing request to the first communication layer 314, which then forwards the service processing request to the global server 210. The specific process of the global server 210 responding to the service processing request is described above and will not be repeated here.

[0085] In the first case, the first central control node 315 can use the first communication layer 314 to migrate the service information corresponding to the client identifier from the first service scenario in the first service component to the target scenario in the first service component.

[0086] In response to the second scenario, on the one hand, the first central control node 315 sends a third link relationship modification instruction to the first intermediary layer 312. This instruction instructs the first intermediary layer 312 to modify the third link relationship corresponding to the client identifier from the first service component link associated with the first scenario identifier of the first service server 221 to the third service component link associated with the target scenario identifier. On the other hand, the first central control node 315 migrates the service information corresponding to the client identifier from the first service scenario in the first service component to the target scenario in the third service component through the first communication layer 314.

[0087] It should be noted that, to facilitate interaction between the client and other clients, such as... Figure 3 As shown, the business server may also include a dialogue process control component, such as... Figure 3The first dialogue process control component 316 and the second dialogue process control component 326 are included. Correspondingly, the access layer of the service server may also include a dialogue access component, such as... Figure 3 The first dialogue access component 317 and the second dialogue access component 327 are used to link the client with the dialogue process control component. For example... Figure 3 In this context, the first dialogue access component 317 is used to link the client with the first dialogue process control component 316.

[0088] Furthermore, the communication methods between the components in the business server can be based on TCP (Transmission Control Protocol) or shared memory, such as... Figure 3 Communication based on TBUS.

[0089] In the above embodiments, by improving the architecture of the business service system, hardware and process reuse can be achieved. That is, front-end access layer server skipping and back-end business information cross-server migration can be realized without adding new machines, which helps to reduce costs. Furthermore, configuring a communication layer in each business server to handle message forwarding between different business components within the same business server, and configuring a global communication layer 214 in the global server to handle message forwarding between business servers, forms a star network topology, which can reduce the connection coupling between processes and improve work efficiency.

[0090] In one embodiment, such as Figure 4 As shown, a business processing method is provided. This method can also be applied to a global server, or it can be implemented through the interaction between the global server and the business server. This method is applied to... Figure 2 Taking global server 210 as an example, the following steps are included:

[0091] Step S402: Receive the service processing request sent by the first service server.

[0092] The service processing request carries a client identifier and a target scene identifier. The client identifier is information that uniquely identifies the client initiating the service processing request. Specifically, this client identifier can be the device ID of the client's terminal or the player identifier associated with the client. The target scene identifier is information that uniquely identifies the target scene the client is applying to join. Specifically, this target scene identifier can be the scene identifier of the target scene.

[0093] Specifically, the prerequisite for the global server to receive a business processing request can be that the first scenario identifier of the business scenario receiving the request in the first business server is different from the target scenario identifier; or that the first scenario identifier is different from the target scenario identifier, and the second business server associated with the target scenario identifier is different from the first business server associated with the first scenario identifier. For the message forwarding path of the business processing request in the first business server under the above circumstances, please refer to the business processing system embodiment above, which will not be repeated here. For ease of understanding, the following explanation will use the case where the prerequisite for the global server to receive the business processing request is that the first scenario identifier is different from the target scenario identifier as an example.

[0094] Furthermore, the specific method by which the global server receives business processing requests can be either proactive acquisition or passive reception.

[0095] Step S404: Determine the second service server associated with the target scene identifier.

[0096] Specifically, the global server has a grasp of the status information of all business servers connected to it, including the business scenarios carried by each business server. Based on this, the global server can determine the second business server associated with the target scenario identifier according to the target scenario identifier carried in the business processing request and the pre-stored correspondence between business scenarios and business servers.

[0097] Step S406: If the second service server is different from the first service server, a first link relationship modification instruction is fed back to the first access layer of the first service server, and a second link relationship modification instruction is fed back to the second intermediary layer of the second service server.

[0098] Specific limitations regarding the first access layer and the second intermediary layer are described in the service processing system embodiment and will not be repeated here. Specifically, the first link relationship modification instruction instructs the first access layer to modify the first link relationship corresponding to the client identifier, changing it from a link between the first access layer and the first intermediary layer of the first service server to a link between the first access layer and the second intermediary layer; the second link relationship modification instruction instructs the second intermediary layer to add a second link relationship corresponding to the client identifier, whereby the second link relationship is a link between the second intermediary layer and the second service component associated with the target scenario identifier of the second service server.

[0099] It is understandable that while adding the second link, the global server can also send a link deletion command to the first intermediary layer to instruct the first intermediary layer to disconnect from the first business component. Specifically, after the first access layer and the second intermediary layer respond to the corresponding link modification commands, the client can sequentially connect to the second business component associated with the target scenario identifier through the first access layer and the second intermediary layer.

[0100] In step S408, the business information corresponding to the client identifier is migrated to the target scenario through the data path between the first business server and the second business server.

[0101] The business information corresponding to the client identifier can include player status information, such as character, level, and items. As mentioned earlier, the first and second business servers are respectively connected to the global server. Therefore, the data path between the first and second business servers refers to the data path from the first business server to the second business server via the global server. The data path for migrating the business information corresponding to the client identifier to the target scene is as follows: the business component containing the first business scene in the first business server, the communication layer of the first business server, the communication layer of the global server, the communication layer of the second business server, and the business component containing the target scene in the second business server.

[0102] Specifically, the global server can migrate the business information corresponding to the client identifier to the target scenario through mirror migration or other data migration methods, based on its own links with the first and second business servers.

[0103] The above-described business processing method, when requiring cross-server migration of business information corresponding to a client identifier, based on the architecture of the business processing system, feeds back a first link relationship modification instruction to the first access layer of the first business server connected to the client, and a second link relationship modification instruction to the second intermediary layer of the second business server. This allows the client to sequentially connect to the second business component associated with the target scenario identifier through the first access layer and the second intermediary layer. Essentially, this changes the business component linked to the client without adding additional data pathways, enabling the client to access the target scenario on the second business server, which is different from the first business server. Furthermore, through the data pathway between the first and second business servers, the business information corresponding to the client identifier is migrated to the target scenario, achieving cross-server migration of business information without adding additional servers. The above technical solutions work together to improve machine utilization and reduce costs while achieving cross-server migration of business information.

[0104] It is understood that the second business server associated with the target scenario identifier is not necessarily different from the first business server. In one embodiment, the business processing method further includes: if the second business server is the same as the first business server, then sending a third link relationship modification instruction to the first intermediary layer.

[0105] The third link relationship modification instruction instructs the first intermediary layer to modify the third link relationship corresponding to the client identifier, changing it from a link between the first intermediary layer and the first service component associated with the first scenario identifier of the first service server to a link between the first intermediary layer and the second service component associated with the target scenario identifier. In this embodiment, the service information corresponding to the client identifier is migrated to the target scenario through the data path between the first service component and the second service component of the first service server. Specifically, the service information corresponding to the client identifier is migrated from the first service scenario in the first service component to the target scenario in the second service component through the first communication layer of the first service server.

[0106] In the above embodiments, when the second business server is the same as the first business server, a third link relationship modification instruction is fed back to the first intermediary layer, so that the client can link to the target scenario through the first intermediary layer. This enables data migration between different business scenarios on the same server, which is beneficial for expanding the application scenarios of the business processing method.

[0107] It should be noted that, given the target scenario is a large-scale cross-server scenario, on the one hand, concentrating all players in the same business component would place excessively high performance demands on that component; on the other hand, since different players have different attribute characteristics, concentrating all players in the same business component would be detrimental to improving user experience. Taking a battle game as an example, a significant disparity in strength between the two sides would inevitably reduce the intensity of the battle, leading to a decline in user experience. Therefore, in one embodiment, a target scenario identifier corresponds to multiple target scenario instances, and each target scenario instance is associated with at least two business components. The gameplay logic of each target scenario instance is identical. Under this premise, there may be more than two business components corresponding to the target scenario identifier, and correspondingly, there may also be more than two business servers associated with the target scenario identifier. Furthermore, in this case, the specific method for determining the second business server associated with the target scenario identifier is not unique.

[0108] In one embodiment, determining the second business server associated with the target scene identifier includes: selecting a business component that matches the attribute feature information from each business component corresponding to the target scene identifier as the second business component based on the attribute feature information corresponding to the client identifier, and determining the business server where the second business component is located as the second business server.

[0109] The attribute information can include the player's level and clan attributes corresponding to the client identifier. The player corresponding to the client identifier is a virtual character in the game. The player's level attribute is used to differentiate the combat power and frequency of action of different players, and can be determined by the player's experience points. For example, players can be divided into a novice group and an expert group based on their level attribute, with the expert group having higher combat power and frequency of action than the novice group. The player's clan attribute is used to differentiate the groups to which different players belong. For example, in a nation-war game, the clan attribute can specifically refer to the player's faction or alliance.

[0110] Specifically, multiple target scenario replicas can be established on different business components, each corresponding to different attribute feature information. Upon receiving a business processing request, the global server can, based on the attribute feature information corresponding to the client identifier and the pre-stored correspondence between attribute feature information and business components, select the business component matching the attribute feature information from among the candidate business components as the second business component, and determine the business server containing the second business component as the second business server. Alternatively, upon receiving a business processing request, the global server can, based on the attribute feature information corresponding to the client identifier carried in the business processing request, filter out the target scenario replicas matching the attribute feature information from among the candidate target scenario replicas included in each candidate business component, then select the business component carrying the target scenario replica as the second business component, and determine the business server containing the second business component as the second business server.

[0111] In another embodiment, before receiving the service processing request sent by the first service server, the method further includes: when the preset opening conditions of the target scene associated with the target scene identifier are met, displaying the scene opening interface to the client corresponding to the client identifier based on the attribute feature information corresponding to the client identifier.

[0112] The preset opening conditions for the target scene can refer to a preset time or a preset plot development. Specifically, the client responds to the business processing operation triggered by the scene opening interface by sending a business processing request to the first business server. Since the attribute feature information corresponding to the scene opening interface matches the client's identifier, the second business component associated with the scene opening interface also matches the attribute feature information corresponding to the client's identifier. Therefore, the target scene identifier carried in the business processing request sent by the client in response to the scene opening interface can be used to identify a copy of the target scene matching the attribute feature information corresponding to the client's identifier. Based on this, the scene opening interface directly associates with the second business component matching the attribute feature information corresponding to the client's identifier. According to the business processing request, a unique second business component can be associated, thereby determining the second business server. Furthermore, the scene opening interface can be displayed via a pop-up or overlay. The scene opening interface can trigger the business processing operation automatically after the preset conditions are met, or it can be triggered after the user clicks.

[0113] In the above embodiments, when there are two or more business components corresponding to the target scene identifier, the business component that matches the attribute feature information corresponding to the client identifier is used as the second business component. This can balance the load pressure of each business component, improve the user experience, and help improve the scientific nature of the business processing method.

[0114] As mentioned earlier, to increase the novelty of gameplay, new gameplay and scenarios are usually developed for users to choose from, which requires the creation of new business scenarios. In one embodiment, such as Figure 5 As shown, the business processing method also includes steps S502 to S506.

[0115] Step S502: Obtain the load weight of each business server.

[0116] The load weights of each business server can be obtained either actively or passively. Specifically, the load weights of each business server can be obtained sequentially based on its identification information.

[0117] Furthermore, the central control node of each business server can determine the load weight of the corresponding business server, and then send the load weight to the global server through the communication layer; alternatively, the main business server can be determined based on the server identifier of each business server, and the central control node of each business server can determine the load weight of the corresponding business server and send it to the central control node of the main business server, and then the central control node of the main business server can send the load weight of each business server to the global server through the communication layer; alternatively, the global server can directly determine the load weight of each business server.

[0118] Furthermore, there is no single way to determine the load weight of each business server.

[0119] In one embodiment, such as Figure 6 As shown, the method for determining the load weight of the business server includes steps S602 to S604.

[0120] Step S602: Obtain the business scenario information of each business scenario associated with the business server, and determine the scenario load weight of each business scenario based on the business scenario information.

[0121] The business scenario information is determined by the gameplay logic of the business scenario. This information may include the maximum number of NPCs that can exist simultaneously and the maximum number of participants. Scenario load weight refers to the resource consumption of the business server hosting the business scenario during its operation. The higher the scenario load weight, the greater the resource consumption of the corresponding business server. Specifically, different weight correlation coefficients can be assigned to different business scenario information, and the scenario load weight of that business scenario can be determined based on the weight correlation coefficients and their corresponding business scenario information.

[0122] In one embodiment, the business scenario information includes the maximum number of NPCs that can exist simultaneously and the maximum number of participants. In this embodiment, as... Figure 7 As shown, the scenario load weight of the business scenario is determined based on the business scenario information, including steps S702 and S704.

[0123] Step S702: Multiply the maximum number of NPCs that can exist at the same time by the NPC correlation coefficient to obtain the NPC load, and multiply the maximum number of participants by the number of participants correlation coefficient to obtain the number of participants load.

[0124] In this context, NPCs are a general term for all characters in the game, distinct from player characters. The maximum number of participants refers to the maximum number of players a game scene can accommodate simultaneously. The NPC correlation coefficient can be determined based on the impact of NPCs on scene load; similarly, the player load coefficient can be determined based on the impact of the number of participating players on scene load. A game scene can have multiple NPCs with different roles, such as non-aggressive NPCs, aggressive NPCs, and group-attack NPCs. The more types of NPCs and the more complex their action logic, the greater their impact on scene load, and the higher their NPC correlation coefficient. For example, in one embodiment, the NPC correlation coefficient is 10, and the player correlation coefficient is 1. Furthermore, when determining the NPC correlation coefficient and player correlation coefficient, whether the business scenario supports player-versus-player combat can also be considered. If so, the player correlation coefficient is increased while keeping the NPC correlation coefficient unchanged. For example, in one embodiment, the NPC correlation coefficient is 10; if player-versus-player combat is supported, the player correlation coefficient is 2; if player-versus-player combat is not supported, the player correlation coefficient is 1.

[0125] It's understandable that the larger the maximum number of NPCs that can exist simultaneously, the larger the maximum number of participants, the more intense the gameplay, and the greater the scene load. Specifically, multiplying the maximum number of NPCs that can exist simultaneously by the NPC correlation coefficient yields the NPC load; multiplying the maximum number of participants by the number correlation coefficient yields the number of participants load.

[0126] Step S704: Determine the scenario load weight of the business scenario associated with the business scenario information based on the NPC load and the number of users load.

[0127] Specifically, the NPC load and the number of users load can be superimposed to obtain the scenario load weight of the business scenario associated with the business scenario information. Alternatively, the average or larger value of the NPC load and the number of users load can be used as the scenario load weight of the business scenario associated with the business scenario information.

[0128] Step S604: Determine the load weight of the business server based on the scenario load weight of each business scenario.

[0129] Specifically, the load weight of a business server can be determined by summing the load weights of each business scenario within the same business server.

[0130] In another embodiment, the service server includes at least two service components, such as Figure 8 As shown, the method for determining the load weight of the business server includes steps S802 to S806.

[0131] Step S802: Obtain business scenario information of each business scenario associated with each business component included in the business server, and determine the scenario load weight of each business scenario based on the business scenario information.

[0132] In this context, a single business component can be associated with multiple business scenarios. Specifically, based on the business scenario information of each scenario, the scenario load weight can be determined for each scenario. For specific limitations regarding scenario load weights, please refer to the above text; they will not be repeated here.

[0133] Step S804: Determine the business load weight of each business component based on the scenario load weight of the business scenarios associated with each business component.

[0134] The business load weight of a business component refers to the resource consumption of the business server hosting that business component during the operation of the business scenarios associated with that component. Specifically, the business load weight of a business component is determined by combining the scenario load weights of each business scenario on the same business component.

[0135] Step S806: Determine the load weight of the business server based on the business load weight of each business component.

[0136] As mentioned above, the business server comprises multiple business components. These components execute the core logic of the game and are the most resource-intensive parts of the business server. Therefore, the business load weight of each business component on the business server represents the overall load weight of the business server. Specifically, by summing the business load weights of each business component on the business server, we can obtain the total load weight of the business server.

[0137] Step S504: The business server with the lowest load weight is identified as the target server.

[0138] Specifically, based on the load weight of each business server, the business server with the lowest load weight can be identified as the target server.

[0139] Step S506: Create a new business scenario on the target server.

[0140] Specifically, a data reference can be established based on the source data of the new business scenario, and a new business scenario can be created on the target server based on the data reference; alternatively, a data copy of the source data of the new business scenario can be established and sent to the target server to create a new business scenario on the target server.

[0141] It is understandable that when multiple scenario replicas need to be created to create new business scenarios, after the creation of one scenario replica is completed, the load weight of each business server is obtained again, and based on the load weight, the business server with the lowest load weight is determined as the new target server, and the next scenario replica is created on the new target server, and so on, until all scenario replicas are created.

[0142] In the above embodiments, the business server with the smallest load weight is identified as the target server, and a new business scenario is created on the target server. This can balance the load of each business server and improve the performance stability of the business processing system.

[0143] It is understandable that the specific component on the target server that carries the new business scenario is a business component. However, the number of business components on the target server is not unique. Therefore, in the process of creating a new business scenario on the target server, it is necessary to select the target business component that carries the new business scenario from among the various business components.

[0144] In one embodiment, the target server includes only one business component. In this embodiment, step S506 includes creating a new business scenario on the business component of the target server. The business component of the target server is the only business component uniquely associated with the target server; therefore, creating a new business scenario on the target server can be achieved simply by creating a new business scenario on this business component.

[0145] In another embodiment, the target server includes at least two business components. In this embodiment, step S506 includes: obtaining the business load weight of each business component of the target server, determining the business component with the smallest business load weight in the target server as the target business component, and creating a new business scenario on the target business component.

[0146] The specific limitations regarding workload weights are detailed above and will not be repeated here. Specifically, the workload weights of each workload component can be obtained by sorting the components according to their identifiers on the target server.

[0147] Specifically, the target business component is the business component with the lowest business load weight in the target server. Based on the business load weight of each business component in the target server, the business component with the lowest business load weight can be identified as the target business component, and a new business scenario is created on the target business component.

[0148] Furthermore, the central control node of the target server can determine the service load weights of each service component in the target server, and then send these service load weights to the global server through the communication layer; alternatively, the global server can determine the service load weights of each service component in the target server. Similarly, the target service components can be determined by either the central control node of the target server or the global server.

[0149] It is understandable that when multiple scenario replicas need to be created to create new business scenarios, after the creation of one scenario replica is completed, the load weight of each business server is re-acquired, and based on the load weight, the business server with the lowest load weight is determined as the new target server. Based on the business load weight of each business component in the new target server, the business component with the lowest business load weight is determined as the target business component, and the next scenario replica is created on the target business component. This process continues until all scenario replicas are created.

[0150] In the above embodiments, creating new business scenarios on the business component with the lowest business load weight in the business server with the lowest load weight can balance the load of each business component in the same business server while ensuring load balancing among business servers, which is beneficial to further improve the performance stability of the business processing system.

[0151] In one embodiment, step S408, which involves migrating the business information corresponding to the client identifier to the target scenario through the data path between the first business server and the second business server, includes sending an exit request to the first business server and an entry request to the second business server.

[0152] The jump-out request is used to instruct the first business server to move the business information corresponding to the client identifier out of the first business component associated with the first scenario identifier; the jump-in request is used to instruct the second business server to move the business information corresponding to the client identifier into the second business component associated with the target scenario identifier.

[0153] Furthermore, the exit request can also be used to instruct the first access layer of the first service server to modify the first link relationship corresponding to the client identifier, changing it from a link between the first access layer and the first intermediary layer of the first service server to a link between the first access layer and the second intermediary layer. The entry request can also be used to instruct the second intermediary layer of the second service server to add a second link relationship corresponding to the client identifier. This second link relationship is a link between the second intermediary layer and the second service component associated with the target scenario identifier of the second service server. In other words, the processing of both exit and entry requests can include two parts: link relationship modification and business information migration.

[0154] At the moment a large-scale cross-server scenario is launched, a batch of server-hopping requests may be generated, with a large number of players simultaneously requesting to leave their original service scenario and join a new one. At this time, the global server will receive a large number of server-hopping requests, and the same service server will receive a large number of outgoing and / or incoming requests. Due to its own performance limitations, if the server processes all requests simultaneously, it may cause performance spikes in the server's CPU, resulting in lag and impacting user experience. Therefore, a request queue is introduced to process requests in a first-in-first-out order, thus smoothing out peak and trough periods and reducing the impact of performance bottlenecks.

[0155] In one embodiment, the business processing request carries a timestamp; step S408 further includes: sending a jump-out request to the first business server and a jump-in request to the second business server according to the order of the timestamps carried by the business processing requests.

[0156] It's understandable that since business processing requests carry timestamps, the order in which they are sent (based on the timestamps) also carries timestamps, corresponding to the moment the business server receives the request. Specifically, the first business server can add outgoing requests to its own queue based on the order of their received timestamps; similarly, the second business server can add incoming requests to its own queue based on the order of their received timestamps. Then, following a first-in-first-out (FIFO) order, the corresponding outgoing and incoming requests are retrieved from the request queues and responded to, migrating the corresponding business information identified by the client and reducing the impact of numerous server-side business processing requests on the business server. It should be noted that when multiple target scenario replicas exist, the same business server may receive both outgoing and incoming requests simultaneously. In this case, separate queues for incoming and outgoing requests can be established on the server, and requests in each queue can be retrieved and responded to in a FIFO order.

[0157] In one embodiment, the business processing method further includes adding business processing requests to a business request queue in a first-in, first-out (FIFO) order. In this embodiment, as... Figure 9 As shown, step S408 further includes:

[0158] Step S902: Take out business processing requests sequentially from the business request queue.

[0159] Specifically, when the global server receives a large number of business processing requests, it can first add the business processing requests to the business request queue in a first-in-first-out order, and then retrieve the business processing requests from the business request queue one by one.

[0160] Step S904: Based on the business processing request, add the jump-in request corresponding to the business processing request to the jump-in request queue in a first-in-first-out order; add the jump-out request corresponding to the business processing request to the jump-out request queue in a first-in-first-out order.

[0161] Specifically, the global server can add incoming requests corresponding to business processing requests to the incoming request queue and outgoing requests corresponding to business processing requests to the outgoing request queue, in a first-in-first-out order, based on the business processing requests.

[0162] Step S906: Take out the exit requests sequentially from the exit request queue and send them to the first business server; take out the entry requests sequentially from the entry request queue and send them to the second business server.

[0163] Specifically, the global server can retrieve outbound requests from the outbound request queue and send them to the first business server in a first-in-first-out (FIFO) order; it can also retrieve inbound requests from the inbound request queue and send them to the second business server. It can be understood that outbound and inbound requests associated with the same business processing request have the same order in the outbound and inbound request queues. Therefore, following the FIFO order, the paired outbound and inbound requests retrieved must also be associated with the client identifier that sent the business processing request.

[0164] Furthermore, the sending and response frequencies of bounce and bounce requests can be determined based on the number of requests the server receives simultaneously. The more requests received at the same time, the heavier the server load, and the response frequency can be lowered to avoid lag.

[0165] In the above embodiments, by introducing a request queue and processing requests in a first-in-first-out order, the impact of batch server jump requests on server performance can be reduced, which is beneficial to improving the stability of the business processing system.

[0166] As mentioned above, the business processing system architecture design enables cross-server business operations without adding machines or processes. Building upon this solution, load balancing and performance smoothing mechanisms are also needed to ensure the stability of the business processing system. For ease of understanding, the following section will combine... Figures 10 to 12 This application provides a detailed description of the load balancing and performance smoothing mechanisms involved.

[0167] The load balancing mechanism is explained below. Under the premise of gameplay logic in large-scale cross-server scenarios, on the one hand, concentrating all players on the same business component would place excessively high performance demands on that component. On the other hand, since different players have different attribute characteristics, concentrating all players on the same business component would be detrimental to improving user experience. Taking a battle game as an example, a significant disparity in strength between the two sides would inevitably reduce the intensity of the battle, leading to a decline in user experience. Therefore, when creating a new cross-server scenario, multiple cross-server scenario instances are created, and these instances are distributed across business components in various business service areas.

[0168] Specifically, when each cross-server instance is created, each business server calculates the scene load weight for each business scene based on the maximum number of NPCs that can exist simultaneously, the maximum number of participants, and whether player-versus-player combat is supported in the original business scenario of the business component. The higher the maximum number of NPCs that can exist simultaneously, the more participants there are, and the more intense the gameplay logic, the higher the scene load weight. Then, the scene load weights of related business scenes on the same business component are summed to obtain the business load weight of each business component. Finally, the business load weights of all business components on the same business server are summed to obtain the load weight of that business server. These load weights are managed by the business server itself. Figure 10 As shown, the load weight can be managed by the central control node of the business server. Each central control node can obtain the load weight of its own server and the business load weight of each business component of the server.

[0169] Furthermore, such as Figure 10 As shown, the master business server can be determined based on the server identifier of each business server. The central control node of each business server then determines the load weight of its corresponding business server and reports this information to the central control node of the master business server. This two-layer weight reporting mechanism allows the master business server to monitor the load of all business servers. It can then create cross-server scenario replicas on the least loaded business components within the least loaded business servers. This ensures load balancing across business servers while also balancing the load of business components within the same business server, thus improving the performance and stability of the business processing system.

[0170] It is understandable that after creating a cross-server scenario replica, the load weight of each business server is re-acquired, and based on the load weight, the business server with the lowest load weight is determined as the new target server. Based on the business load weight of each business component in the new target server, the business component with the lowest business load weight is determined as the target business component, and the next cross-server scenario replica is created on the target business component. This process continues until all cross-server scenario replicas are created.

[0171] The performance smoothing mechanism is explained below. At the moment a large-scale cross-server scenario begins, a batch of server-hopping requests may occur, with many players simultaneously requesting to leave their original service scenario and join a new one. At this time, the global server will receive a large number of server-hopping requests, and the same service server will receive a large number of outgoing and / or incoming requests. Due to its own performance limitations, if the server processes all requests simultaneously, it may cause performance spikes in the server's CPU, resulting in lag and impacting user experience. Therefore, a request queue is introduced to process requests in a first-in-first-out order, smoothing out peak and valley loads and reducing the impact of performance bottlenecks.

[0172] In one embodiment, such as Figure 11 As shown, a bidirectional service jump queue is introduced to smooth out peak traffic and fill in valleys. Specifically, business processing requests carry timestamps. Global server 210 sends jump-out requests to the first business server 221 and jump-in requests to the second business server 222 according to the order of the timestamps carried by the business processing requests.

[0173] It's understandable that since business processing requests carry timestamps, the exit and entry requests sent in the order of their timestamps also carry timestamps, corresponding to the moment the business server receives the request. Specifically, the first business server 221 can add exit requests to its exit request queue based on the order of the received exit requests; the second business server 222 can add entry requests to its entry request queue based on the order of the received entry requests. It should be noted that in the case of multiple cross-server scenario replicas, the same business server may receive both exit and entry requests simultaneously. In this case, if... Figure 11 As shown, jump-in request queues and jump-out request queues can be established in this server.

[0174] The business server retrieves and responds to corresponding bounce requests and bounce requests sequentially from the request queue in a first-in, first-out (FIFO) order. This migrates the business information corresponding to the client identifier, reducing the impact of a large number of server-hopping requests on the business server. Specifically, for example... Figure 12As shown, the client, via the first business component and global server 210, sends a jump request to the second business component. The second business component, based on the current jump request queue, returns the jump sequence number to the first business component via global server 210 and adds the jump request to the queue. Following a first-in, first-out order, when the jump request can be responded to, the first business component notifies the first access layer to jump to a different server via global server 210. After the front-end jump is successful, the back-end data is migrated across servers using mirrored players. After successfully entering the instance, the player object and session corresponding to the client identifier on the first business component are deleted, and the online server of the client identifier is updated.

[0175] Furthermore, the sending and response frequencies of bounce and bounce requests can be determined based on the number of requests the server receives simultaneously. The more requests received at the same time, the heavier the server load, and the response frequency can be lowered to avoid lag.

[0176] By adopting the above-mentioned business processing system and methods, cross-service business can reuse the machines and processes of existing business servers, making fuller use of existing resources, saving machine operating costs and reducing maintenance workload, which is conducive to reducing costs and improving the scientific nature of business processing methods.

[0177] It should be understood that although the steps in the flowcharts of the embodiments described above 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 embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0178] Based on the same inventive concept, this application also provides a business processing apparatus for implementing the business 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 processing apparatus embodiments provided below can be found in the limitations of the business processing method described above, and will not be repeated here.

[0179] In one embodiment, such as Figure 13As shown, a service processing apparatus 1300 is provided, including: a service processing request receiving module 1302, a service server determining module 1304, a link relationship modification module 1306, and a service information migration module 1308, wherein:

[0180] The business processing request receiving module 1302 is used to receive a business processing request sent by the first business server, which carries a client identifier and a target scene identifier.

[0181] The business server determination module 1304 is used to determine the second business server associated with the target scene identifier;

[0182] The link relationship modification module 1306 is used to, if the second business server determined by the business server determination module 1304 is different from the first business server, feed back a first link relationship modification instruction to the first access layer of the first business server and a second link relationship modification instruction to the second intermediary layer of the second business server; the first link relationship modification instruction is used to instruct the first access layer to modify the first link relationship corresponding to the client identifier from the first access layer and the first intermediary layer of the first business server to the first access layer and the second intermediary layer; the second link relationship modification instruction is used to instruct the second intermediary layer to add a second link relationship corresponding to the client identifier; the second link relationship is a link between the second intermediary layer and the target scenario identifier of the second business server.

[0183] The business information migration module 1308 is used to migrate the business information corresponding to the client identifier to the target scenario through the data path between the first business server and the second business server.

[0184] In one embodiment, the link relationship modification module 1306 is further configured to: if the second service server is consistent with the first service server, send a third link relationship modification instruction to the first intermediary layer; the third link relationship modification instruction is used to instruct the first intermediary layer to modify the third link relationship corresponding to the client identifier, from the first service component link associated with the first scene identifier of the first intermediary layer and the first service server, to the second service component link associated with the target scene identifier of the first intermediary layer.

[0185] In one embodiment, there are two or more business components corresponding to the target scene identifier. The business server determination module 1304 is specifically used to: select the business component that matches the attribute feature information from the business components corresponding to the target scene identifier as the second business component, based on the attribute feature information corresponding to the client identifier, and determine the business server where the second business component is located as the second business server.

[0186] In one embodiment, there are two or more business components corresponding to the target scene identifier; the business processing device further includes: a scene open interface display module, used to display the scene open interface to the client corresponding to the client identifier according to the attribute feature information corresponding to the client identifier when the preset open conditions of the target scene associated with the target scene identifier are met; the second business component associated with the scene open interface matches the attribute feature information.

[0187] In one embodiment, the attribute feature information includes level attributes and family attributes.

[0188] In one embodiment, the business processing apparatus further includes: a server load weight acquisition module for acquiring the load weight of each business server; a target server determination module for determining the business server with the lowest load weight as the target server; and a new business scenario creation module for creating a new business scenario on the target server.

[0189] In one embodiment, the server load weight acquisition module includes: a scenario load weight acquisition unit, used to acquire business scenario information of each business scenario associated with the business server, and determine the scenario load weight of each business scenario according to the scenario scenario information; and a server load weight acquisition unit, used to determine the load weight of the business server according to the scenario load weight of each business scenario.

[0190] In one embodiment, the business server includes at least two business components. In this embodiment, the scenario load weight acquisition unit is specifically used to acquire business scenario information of each business scenario associated with each business component included in the business server, and determine the scenario load weight of each business scenario based on the scenario scenario information. The server load weight acquisition module further includes: a business load weight determination unit, used to determine the business load weight of each business component based on the scenario load weight of the business scenarios associated with each business component. The server load weight acquisition unit is specifically used to determine the load weight of the business server based on the business load weight of each business component.

[0191] In one embodiment, the business scenario information includes the upper limit of the number of NPCs that can exist at the same time and the upper limit of the number of participants. The scenario load weight acquisition unit is specifically used to: multiply the upper limit of the number of NPCs that can exist at the same time by the NPC association coefficient to obtain the NPC load, and multiply the upper limit of the number of participants by the number association coefficient to obtain the number load; and determine the scenario load weight of the business scenario associated with the business scenario information based on the NPC load and the number load.

[0192] In one embodiment, the business server includes at least two business components, and the new business scenario creation module is specifically used to: obtain the business load weight of each business component of the target server, determine the business component with the smallest business load weight in the target server as the target business component, and create a new business scenario on the target business component.

[0193] In one embodiment, the business processing request carries a timestamp; the business information migration module 1308 is specifically used to: send an exit request to the first business server and a jump-in request to the second business server according to the order of the timestamps carried by the business processing requests.

[0194] In one embodiment, the business processing method further includes: adding business processing requests to a business request queue in a first-in-first-out (FIFO) order. In this embodiment, the business information migration module includes: a business processing request retrieval unit, configured to sequentially retrieve business processing requests from the business request queue; a jump-in / jump-out request addition unit, configured to add jump-in requests corresponding to the business processing requests to the jump-in request queue in a FIFO order; and add jump-out requests corresponding to the business processing requests to the jump-out request queue in a FIFO order; and a jump-in / jump-out request sending unit, configured to sequentially retrieve jump-out requests from the jump-out request queue and send them to a first business server, and sequentially retrieve jump-in requests from the jump-in request queue and send them to a second business server.

[0195] Each module in the aforementioned business 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 in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0196] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 14As shown, this computer device includes a processor, memory, input / output interfaces (I / O), 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 operating system and computer programs stored in the non-volatile storage media. The database stores the operational logic for various business scenarios and business information data associated with the client identifiers of the computer device. 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 processing method.

[0197] 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.

[0198] In one embodiment, a computer device is 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-described method embodiments.

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

[0200] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0201] 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 the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0202] 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, and when executed, it 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.

[0203] 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.

[0204] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent 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 processing method, characterized in that, The method is applied to a global server, which is communicatively connected to at least two business servers. Each business server includes at least an access layer, an intermediary layer, and a business layer. The business layer includes at least one business component that carries a business scenario. The method includes: Receive a service processing request sent by the first service server, the service processing request carrying a client identifier and a target scene identifier; Identify the second service server associated with the target scene identifier; If the second service server is different from the first service server, a first link relationship modification instruction is fed back to the first access layer of the first service server, and a second link relationship modification instruction is fed back to the second intermediary layer of the second service server. The first link relationship modification instruction is used to instruct the first access layer to modify the first link relationship corresponding to the client identifier from the first access layer and the first intermediary layer of the first service server to the first access layer and the second intermediary layer. The second link relationship modification instruction is used to instruct the second intermediary layer to add a second link relationship corresponding to the client identifier. The second link relationship is a link between the second intermediary layer and the second service component associated with the target scene identifier of the second service server. If the second business server is the same as the first business server, then a third link relationship modification instruction is sent to the first intermediary layer; the third link relationship modification instruction is used to instruct the first intermediary layer to modify the third link relationship corresponding to the client identifier from the first business component link associated with the first scene identifier in the first business server to the third business component link associated with the target scene identifier in the first business server. The business information corresponding to the client identifier is migrated to the target scenario through the data path between the first business server and the second business server.

2. The method according to claim 1, characterized in that, There are two or more business components corresponding to the target scene identifier; determining the second business server associated with the target scene identifier includes: Based on the attribute feature information corresponding to the client identifier, select the business component that matches the attribute feature information from each of the business components corresponding to the target scene identifier as the second business component, and determine the business server where the second business component is located as the second business server.

3. The method according to claim 1, characterized in that, There are two or more business components corresponding to the target scene identifier; before receiving the business processing request sent by the first business server, the process further includes: When the preset opening conditions of the target scene associated with the target scene identifier are met, the scene opening interface is displayed to the client corresponding to the client identifier according to the attribute feature information corresponding to the client identifier; the second business component associated with the scene opening interface is matched with the attribute feature information.

4. The method according to claim 1, characterized in that, The method further includes: Obtain the load weight of each business server; The server with the lowest load weight is identified as the target server. Create a new business scenario on the target server.

5. The method according to claim 4, characterized in that, The service server includes at least two service components, and the method for determining the load weight of the service server includes: Obtain business scenario information of each business scenario associated with each business component included in the business server, and determine the scenario load weight of each business scenario based on the business scenario information. The business load weight of each business component is determined based on the scenario load weight of the business scenarios associated with each business component. The load weight of the business server is determined based on the business load weight of each of the business components.

6. The method according to claim 5, characterized in that, The business scenario information includes the maximum number of NPCs that can exist simultaneously and the maximum number of participants. Based on this information, the scenario load weight is determined, including: Multiply the maximum number of NPCs that can exist simultaneously by the NPC correlation coefficient to obtain the NPC load, and multiply the maximum number of participants by the number of participants correlation coefficient to obtain the number of participants load; Based on the NPC load and the number of users load, determine the scenario load weight of the business scenario associated with the business scenario information.

7. The method according to claim 4, characterized in that, The process of creating a new business scenario on the target server includes: Obtain the business load weights of each business component of the target server, determine the business component with the smallest business load weight in the target server as the target business component, and create a new business scenario on the target business component.

8. The method according to any one of claims 1 to 7, characterized in that, Migrating the business information corresponding to the client identifier to the target scenario through the data path between the first business server and the second business server includes: A jump-out request is sent to the first service server, and a jump-in request is sent to the second service server; the jump-out request is used to instruct the first service server to move the service information corresponding to the client identifier out of the first service component associated with the first scene identifier; the jump-in request is used to instruct the second service server to move the service information corresponding to the client identifier into the target service component associated with the target scene identifier.

9. The method according to any one of claims 1 to 7, characterized in that, The business processing request carries a timestamp; the business information corresponding to the client identifier is migrated to the target scenario through the data path between the first business server and the second business server, and the process further includes: Based on the order of the timestamps carried in the business processing requests, a jump-out request is sent to the first business server, and a jump-in request is sent to the second business server.

10. The method according to any one of claims 1 to 7, characterized in that, The method further includes adding the business processing request to the business request queue in a first-in-first-out order; The step of migrating the business information corresponding to the client identifier to the target scenario through the data path between the first business server and the second business server includes: The service processing requests are retrieved sequentially from the service request queue; Based on the business processing request, in the order of first-in-first-out, add the jump-in request corresponding to the business processing request to the jump-in request queue; in the order of first-in-first-out, add the jump-out request corresponding to the business processing request to the jump-out request queue. The jump request is retrieved from the jump request queue and sent to the first service server. The jump request is retrieved from the jump request queue and sent to the second service server.

11. An object processing apparatus, characterized in that, An apparatus applied to a global server, which is communicatively connected to at least two business servers, each of which includes at least an access layer, an intermediary layer, and a business layer, wherein the business layer includes at least one business component carrying a business scenario, the apparatus comprising: A business processing request receiving module is used to receive a business processing request sent by a first business server, wherein the business processing request carries a client identifier and a target scenario identifier; The business server determination module is used to determine the second business server associated with the target scene identifier; The link relationship modification module is used to, if the second business server determined by the business server determination module is different from the first business server, feed back a first link relationship modification instruction to the first access layer of the first business server and a second link relationship modification instruction to the second intermediary layer of the second business server; the first link relationship modification instruction is used to instruct the first access layer to modify the first link relationship corresponding to the client identifier from the first access layer and the first intermediary layer of the first business server to the first access layer and the second intermediary layer; the second link relationship modification instruction is used to instruct the second intermediary layer to add a second link relationship corresponding to the client identifier, the second link relationship being a link between the second intermediary layer and the second business component associated with the target scene identifier of the second business server; The link relationship modification module is further configured to: if the second business server is the same as the first business server, then send a third link relationship modification instruction to the first intermediary layer; the third link relationship modification instruction is configured to instruct the first intermediary layer to modify the third link relationship corresponding to the client identifier from the first business component link associated with the first scene identifier in the first business server to the third business component link associated with the target scene identifier in the first business server. The business information migration module is used to migrate the business information corresponding to the client identifier to the target scenario through the data path between the first business server and the second business server.

12. The apparatus according to claim 11, characterized in that, There are two or more business components corresponding to the target scene identifier; the business server determination module is specifically used for: Based on the attribute feature information corresponding to the client identifier, select the business component that matches the attribute feature information from each of the business components corresponding to the target scene identifier as the second business component, and determine the business server where the second business component is located as the second business server.

13. The apparatus according to claim 11, characterized in that, The device also includes a scene open interface display module, used for: When the preset opening conditions of the target scene associated with the target scene identifier are met, the scene opening interface is displayed to the client corresponding to the client identifier according to the attribute feature information corresponding to the client identifier; the second business component associated with the scene opening interface is matched with the attribute feature information.

14. The apparatus according to claim 11, characterized in that, The device method also includes: The server load weight acquisition module is used to obtain the load weight of each business server. The target server determination module is used to identify the business server with the lowest load weight as the target server. The new business scenario creation module is used to create new business scenarios on the target server.

15. The apparatus according to claim 14, characterized in that, The business server includes at least two business components, and the server load weight acquisition module includes: The scenario load weight acquisition unit is used to acquire the business scenario information of each business scenario associated with each business component included in the business server, and determine the scenario load weight of each business scenario according to the business scenario information. The business load weight determination unit is used to determine the business load weight of each business component based on the scenario load weight of the business scenario associated with each business component. The server load weight acquisition unit is used to determine the load weight of the business server based on the business load weight of each business component.

16. The apparatus according to claim 15, characterized in that, The business scenario information includes the maximum number of NPCs that can exist simultaneously and the maximum number of participants. The scenario load weight acquisition unit is specifically used for: Multiply the maximum number of NPCs that can exist simultaneously by the NPC correlation coefficient to obtain the NPC load, and multiply the maximum number of participants by the number of participants correlation coefficient to obtain the number of participants load; Based on the NPC load and the number of users load, determine the scenario load weight of the business scenario associated with the business scenario information.

17. The apparatus according to claim 14, characterized in that, The new business scenario creation module is specifically used for: Obtain the business load weights of each business component of the target server, determine the business component with the smallest business load weight in the target server as the target business component, and create a new business scenario on the target business component.

18. The apparatus according to any one of claims 11 to 17, characterized in that, The business information migration module is specifically used for: A jump-out request is sent to the first service server, and a jump-in request is sent to the second service server; the jump-out request is used to instruct the first service server to move the service information corresponding to the client identifier out of the first service component associated with the first scene identifier; the jump-in request is used to instruct the second service server to move the service information corresponding to the client identifier into the target service component associated with the target scene identifier.

19. The apparatus according to any one of claims 11 to 17, characterized in that, The business processing request carries a timestamp; the business information migration module is specifically used for: Based on the order of the timestamps carried in the business processing requests, a jump-out request is sent to the first business server, and a jump-in request is sent to the second business server.

20. The apparatus according to any one of claims 11 to 17, characterized in that, The business information migration module is specifically used for: The business processing request is added to the business request queue in a first-in, first-out order. The service processing requests are retrieved sequentially from the service request queue; Based on the business processing request, in the order of first-in-first-out, add the jump-in request corresponding to the business processing request to the jump-in request queue; in the order of first-in-first-out, add the jump-out request corresponding to the business processing request to the jump-out request queue. The jump request is retrieved from the jump request queue and sent to the first service server. The jump request is retrieved from the jump request queue and sent to the second service server.

21. 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 10.

22. 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 10.

23. 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 10.

24. A business processing system, characterized in that, The system includes: a global server and a business server, the global server being communicatively connected to the business server, and the business server including at least a first business server and a second business server; each business server including at least an access layer, an intermediary layer and a business layer, the business layer including at least one business component carrying a business scenario; The first service server receives a service processing request sent by the client. The service processing request carries a client identifier and a target scene identifier. If the first scene identifier of the service scene received by the first service server is different from the target scene identifier, the service processing request is forwarded to the global server. The global server receives the service processing request and determines the second service server associated with the target scene identifier. If the second service server is different from the first service server, it sends a first link relationship modification instruction to the first access layer of the first service server and sends a second link relationship modification instruction to the second intermediary layer of the second service server. If the second service server is the same as the first service server, it sends a third link relationship modification instruction to the first intermediary layer of the first service server. The first link relationship modification instruction is used to instruct the first access layer to modify the first link relationship corresponding to the client identifier from a link between the first access layer and the first intermediary layer to a link between the first access layer and the second intermediary layer. The second link relationship modification instruction is used to instruct the second intermediary layer to add a second link relationship corresponding to the client identifier. The second link relationship is a link between the second intermediary layer and the second business component associated with the target scene identifier of the second business server. The third link relationship modification instruction is used to instruct the first intermediary layer to modify the third link relationship corresponding to the client identifier from a link between the first intermediary layer and the first business component associated with the first scene identifier in the first business server to a link between the first intermediary layer and the third business component associated with the target scene identifier in the first business server. The global server also migrates the business information corresponding to the client identifier to the target scenario through the data path between the first business server and the second business server.

25. The business processing system according to claim 24, characterized in that, The first service server includes a first access layer, a first intermediary layer, a first service layer, and a first communication layer linked in sequence; the second service server includes a second access layer, a second intermediary layer, a second service layer, and a second communication layer linked in sequence; the first service layer and the second service layer are used to carry service scenarios; the first communication layer and the second communication layer are linked to the global server; The first access layer is also used to connect the client and the second intermediary layer; the second access layer is also used to connect the client and the first intermediary layer.

26. The business processing system according to claim 24, characterized in that, The service server further includes a central control node, which is linked to the communication layer of the service server. The central control node is used to receive the service processing request and to determine whether the first scene identifier and the target scene identifier are associated with the same service server. When the first scene identifier and the target scene identifier are associated with different service servers, the central control node forwards the service processing request to the global server.

Images