Business processing system and method based on a distributed computing framework

Abstract

The application discloses a kind of business processing systems and methods based on distributed computing framework, it is related to data processing field, especially it is related to cloud computing field etc.. Specific implementation scheme is: the business processing system includes at least one parasitic server, host global server, service registration center ETCD and data structure server Redis, wherein, host global server is used to load at least one global service;Each global service is registered to ETCD, and obtains the business data of each other from Redis;Parasitic server is used to obtain the host global server information where the business is located from ETCD, and initiates the first operation request to target global service based on the host global server information where the business is located;Wherein, the first operation request is used to indicate target global service to execute corresponding operation, and the latest global service data after operation is synchronized to each parasitic server subscribing target global service.The application can improve the performance and efficiency of business processing system.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data processing, especially to the field of cloud computing, and particularly relates to a business processing system and method based on a distributed computing framework. BACKGROUND

[0002] With the continuous development of global information industry, network resources and data scale are also growing, especially in the field of Internet application, e-commerce, etc., the data volume shows a rapid growth trend. In order to solve these data-intensive computing problems, cloud computing emerges as the times require. Cloud computing is usually implemented based on a distributed computing framework. In the distributed structure function, a part needs to store global data or global logic. SUMMARY

[0003] The present application provides a business processing system and method based on a distributed computing framework.

[0004] According to a first aspect of the present application, a business processing system based on a distributed computing framework is provided, comprising: at least one parasite server, a host global server, a service registration center ETCD and a data structure server Redis, wherein,

[0005] The host global server is configured to load at least one global business; each global business is registered with the ETCD, and obtains its own business data from the Redis;

[0006] The parasite server is configured to obtain the host global server information of the business from the ETCD, and initiate a first operation request for the target global business based on the host global server information of the business; wherein the first operation request is used to instruct the target global business to execute the corresponding operation, and synchronize the latest global business data after operation to each parasite server subscribing to the target global business.

[0007] According to a second aspect of the present application, a business processing method based on a distributed computing framework is provided, applied to the business processing system of the first aspect, wherein the method comprises:

[0008] Loading at least one global business; each global business is registered with the service registration center ETCD, and obtains its own business data from the data structure server Redis;

[0009] Obtaining the host global server information of the business from the ETCD, and initiating a first operation request for the target global business based on the host global server information of the business; wherein the first operation request is used to instruct the target global business to execute the corresponding operation, and synchronize the latest global business data after operation to each parasite server subscribing to the target global business.

[0010] According to the technical solution of the present application, the global data of the service can be stored and global logic can be performed based on the global server, the availability and feasibility of the service processing system are ensured, and the performance and efficiency of the service processing system are improved.

[0011] It should be understood that the content described in this part is not intended to identify the key or important features of the embodiments of the present application, nor to limit the scope of the present application. Other features of the present application will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0012] The accompanying drawings are used to better understand the present application, and do not constitute a limitation of the present application. Among them:

[0013] Figure 1 is a structural block diagram of a service processing system based on a distributed computing framework provided by an embodiment of the present application;

[0014] Figure 2 is an example of global service logic and data processing flow according to an embodiment of the present application Figure 1 ;

[0015] Figure 3 is an example of global service logic and data processing flow according to an embodiment of the present application Figure 2 ;

[0016] Figure 4 is an example of a simple player kicking service logic processing flow provided by an embodiment of the present application;

[0017] Figure 5 is an example of a simple non-player character (NPC) refreshing service logic processing flow provided by an embodiment of the present application;

[0018] Figure 6 is an example of an NPC refreshing interaction logic flow provided by an embodiment of the present application;

[0019] Figure 7 is an example of a server registration query connection request process provided by an embodiment of the present application;

[0020] Figure 8 is a flowchart of a service processing method based on a distributed computing framework provided by an embodiment of the present application. DETAILED DESCRIPTION

[0021] Exemplary embodiments of the present application are described herein with reference to the accompanying drawings, which are cited by way of example only. The various details of the embodiments of the present application are described herein in order to provide what is considered to be a thorough description of the present application. It should be understood to those of ordinary skill in the art that the details given herein are not intended to limit the scope of the present application. It should also be understood that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Also, for the sake of brevity and clarity, any description of well-known functions and constructions will be omitted when such descriptions will be deemed to obscure the key meanings of the present application.

[0022] It should be noted that the acquisition, storage and application of the user personal information in the technical solutions of the present application comply with the relevant laws and regulations and do not violate public order and good customs. The user personal information is acquired, stored and applied with the consent of the user.

[0023] It should also be noted that in the embodiments of the present application, the term "host global server" can be understood as a server for processing global services. The host global server has the following functions and characteristics: 1) stateless; 2) for server discovery; 3) can guide the establishment of a connection between servers (such as establishing a connection only when needed); 4) can distribute service logic for distributed deployment (such as player online information and non-player character NPC refresh can be started in two host global servers, respectively); 5) can query or send instructions to other servers.

[0024] The business processing system and method based on the distributed computing framework of the embodiments of the present application are described below with reference to the accompanying drawings.

[0025] Figure 1 is a structural block diagram of a business processing system based on a distributed computing framework provided by the embodiments of the present application. As shown in Figure 1 the business processing system based on the distributed computing framework 100 can include at least one parasite server 110, a host global server 120, a service registration center ETCD 130 and a data structure server Redis 140. Wherein, the meaning of "at least one" is one or more, and the meaning of "multiple" is at least two, such as two, three, etc., unless otherwise explicitly specified.

[0026] The host global server 120 is used to load at least one global service. In the embodiments of the present application, each global service can register with the ETCD 130 and obtain its own service data from the Redis 140.

[0027] The parasitic server 110 is used to obtain the global server information of the host where the service resides from the ETCD 130, and initiate a first operation request for the target global service based on the global server information of the host where the service resides. The first operation request is used to instruct the target global service to perform the corresponding operation, and synchronize the latest global service data after the operation is performed to each parasitic server that subscribes to the target global service.

[0028] It should be noted that, in the embodiments of this application, the external interfaces of the host global server 120 are organized by global business modules. These global business logics can reside on one host global server or on different host global servers. Each global business logic has its own set of interface protocols, which are encapsulated using a protocol buffer (Protobuf) for external applications to call.

[0029] For example, the host global server 120 can provide an interface for the parasitic server. This interface is organized in the form of global business modules. Taking global business 1 and global business 2 as examples, the global business logic of global business 1 and global business 2 can be organized by the host global server 120. Figure 2 As shown, the global business logic and data processing flow are as follows: ETCD 130 has a registration function; Redis 140 can provide extended storage for server memory data and can also store global business data. First, the host global server can load global business 1 (S21) and global business 2 (S22). Global business 1 can send registration configuration information from ETCD 130. Global business 1 can send a registration request to ETCD 130 to register its own information on ETCD 130 (S23). Upon receiving the registration request from global business 1, ETCD 130 obtains the information of global business 1 from the registration request, such as the identifier of global business 1 and the identifier of the host global server to which global business 1 is loaded, and registers the information of global business 1 on ETCD 130. When global business 1 receives the registration success information returned by ETCD 130, it can request the data of global business 1 from Redis 140. When Redis 140 receives a data retrieval request from Global Business 1, it can return the data from Global Business 1 to Global Business 1, allowing Global Business 1 to pull data from Redis 140 (S24).

[0030] like Figure 2As shown, the global service 2 can also register with the ETCD 130, for example, the global service 2 can send registration configuration information from the ETCD 130, the global service 2 can send a registration request to the ETCD 130 to register the information of the global service 2 itself on the ETCD 130 (S25). The ETCD 130 receives the registration request sent by the global service 2, obtains the information of the global service 2 from the registration request, such as the identifier of the global service 2, the identifier of the host global server on which the global service 2 is loaded, and the like, and registers the information of the global service 2 on the ETCD 130. When the global service 2 receives the registration success information returned by the ETCD 130, the global service 2 can request the Redis 140 to obtain the data of the global service 2. The Redis 140 receives the data obtaining request of the global service 2, and returns the data of the global service 2 to the global service 2, so that the global service 2 can pull the service 2 data from the Redis 140 (S26). Wherein, the registration process of the global service 1 and the global service 2 described above can be performed simultaneously or separately, which is not limited here.

[0031] It should be noted that when the parasitic server operates a certain global service, it needs to know which global services are loaded on the host global server. Since the registration information of the global service is recorded in the ETCD 130, the registration information can include the identifier of the global service, and the identifier of the host global server on which the global service is loaded, and the like, so that the parasitic server can inform the host global server based on the registration information of the global service in the ETCD 130 which global services the parasitic server needs to pay attention to. For example, taking the parasitic server 110 as the server B and the server A as an example, as shown in Figure 2 The server A can obtain the host global server information of the global service 1 and the global service 2 from the ETCD 130 (S27), and send a communication message to the corresponding host global server 120 based on the host global server information (such as identifier information) to inform the host global server 120 that the server A pays attention to the global service 1 and the global service 2 (S28). The server B can obtain the host global server information of the global service 1 from the ETCD 130 (S29), and send a communication message to the corresponding host global server 120 based on the host global server information (such as identifier information) to inform the host global server 120 that the server B pays attention to the global service 1 (S210).

[0032] When the parasitic server operates the global service loaded on the host global server, after the global service completes the operation, the latest data of the global service can be synchronized to all parasitic servers paying attention to the global service in a cache manner. For example, as shown in Figure 2As shown, server B can initiate an operation request for global service 1 based on the host global server information of global service 1 (S211). Upon receiving the operation request, global service 1 can perform a corresponding operation based on the operation request, and update the latest global service data after the operation to Redis 140 (S212). Redis 140 receives and stores the latest global service data sent by global service 1. In order to improve real-time performance, each parasitic server that focuses on global service 1 can save a copy of the latest global service data of global service 1. Upon completion of the operation, global service 1 can send an operation completion notification to the host global server. Upon receiving the notification, the host global server can notify global service 1 to synchronize the latest global service data to the parasitic servers connected to the host global server and focusing on global service 1. For example, global service 1 can synchronize the latest global service data after the operation to server A that subscribes (or focuses on) global service 1 (S213), and can synchronize the latest global service data after the operation to server B that focuses on global service 1 (S214), so that each parasitic server saves a copy of the latest global service data, realizes a cache type process of global service logic and data processing, and is suitable for a case where the amount of business data is small and the real-time requirement is high.

[0033] In some embodiments of the present application, parasitic server 110 can also obtain global service data corresponding to a second operation request for a target global service from the target global service based on an asynchronous callback mechanism when initiating the second operation request based on the host global server information of the target global service. That is, for a case where the amount of business data is large and the real-time requirement is not high, a non-cache type process of global service logic and data processing can be realized.

[0034] For example, host global server 120 can provide an interface for parasitic servers, which is organized in the form of global service modules. Taking global service 1 and global service 2 as examples, the global service logic of global service 1 and global service 2 can be organized by host global server 120. As shown in FIG. 2, the interface provided by host global server 120 can include global service 1 and global service 2. Figure 3As shown, the non-cached flow of the global business logic and data processing is as follows: ETCD 130 has a registration function; Redis 140 can provide extended storage for server memory data and can also store global business data. First, the host global server can load global business 1 (S31) and global business 2 (S32). Global business 1 can send registration configuration information from ETCD 130. Global business 1 can send a registration request to ETCD 130 to register its own information on ETCD 130 (S33). Upon receiving the registration request from global business 1, ETCD 130 obtains the information of global business 1 from the registration request, such as the identifier of global business 1 and the identifier of the host global server to which global business 1 is loaded, and registers the information of global business 1 on ETCD 130. When global business 1 receives the registration success information returned by ETCD 130, it can request Redis 140 to retrieve its data. When Redis 140 receives a data retrieval request from Global Business 1, it can return the data from Global Business 1 to Global Business 1, allowing Global Business 1 to pull data from Redis 140 (S34).

[0035] like Figure 3 As shown, Global Service 2 can also register with ETCD 130. For example, Global Service 2 can send registration configuration information from ETCD 130, or send a registration request to ETCD 130 to register its own information on ETCD 130 (S35). Upon receiving the registration request from Global Service 2, ETCD 130 obtains information about Global Service 2 from the request, such as its identifier and the identifier of the host global server to which it is loaded, and registers this information on ETCD 130. When Global Service 2 receives a registration success message from ETCD 130, it can request data from Redis 140. Upon receiving this data retrieval request, Redis 140 can return the data to Global Service 2, allowing Global Service 2 to pull its data from Redis 140 (S26). The registration processes for Global Service 1 and Global Service 2 can be carried out simultaneously or separately, without any specific restrictions.

[0036] It should be noted that when a parasitic server operates a certain global service, it needs to first understand which global services the host global server has loaded. Since ETCD 130 records the registration information of global services, this registration information may include the identifier of the global service and the identifier of the host global server to which the global service is loaded. Therefore, the parasitic server can use the global service registration information in ETCD 130 to inform the host global server which global services it needs to monitor. For example, taking parasitic server 110 as server B and server A, if... Figure 3 As shown, server A can obtain the host global server information of global service 1 and global service 2 from ETCD 130 (S37), and send a communication message to the corresponding host global server 120 based on the host global server information (such as identification information) to notify the host global server 120 that server A has paid attention to global service 1 and global service 2. Server B can obtain the host global server information of global service 1 from ETCD 130 (S38), and send a communication message to the corresponding host global server 120 based on the host global server information (such as identification information) to notify the host global server 120 that server B has paid attention to global service 1.

[0037] When a parasitic server operates on global services loaded by the host global server, after the global service completes its operation, it saves the latest data of the global service to Redis. Each server does not store the latest data of the global service locally; instead, it retrieves the latest data asynchronously each time it is needed. For example, ... Figure 3As shown, server B can initiate an operation request for global business 1 based on the global server information of the host of global business 1 (S39). When global business 1 receives the operation request, it can perform the corresponding operation based on the operation request and update the latest global business data after the operation is executed to Redis 140 (S310). Redis 140 receives and stores the latest global business data sent by global business 1. When server B needs to use the latest global business data of global business 1, it can use an asynchronous callback mechanism to obtain the latest global business data of global business 1 (S311). Global business 1 queries the latest global business data of global business 1 based on the asynchronous callback retrieval request sent by server B (S312) and returns the query result to server B. When server A needs to use the latest global business data of global business 1, it can use an asynchronous callback mechanism to obtain the latest global business data of global business 1 (S313). Global business 1 queries the latest global business data of global business 1 based on the asynchronous callback retrieval request sent by server A (S314) and returns the query result to server A. Therefore, each parasitic server does not store global business data locally. Data can be obtained through asynchronous calls each time it is used, realizing a non-cached process for global business logic and data processing. This is suitable for situations where the amount of business data is large and the real-time requirements are not high.

[0038] It should be noted that, in the embodiments of this application, the global business logic in the host global server 120 provides a control interface to the outside world through the definition of the Protocol Buffer (Protobuf). In other words, the global business logic in the host global server 120 provides a series of control interfaces to the outside world through the definition of Protobuf, through which the behavior or state of some system objects can be directly controlled.

[0039] For example, suppose the business processing system in this application embodiment implements a multi-user real-time simultaneous screen scenario, processing is performed on multiple threads based on the same map or the same scene. Figure 4 As shown, taking a simple player-kicking business logic as an example, assuming the external application is a game application, when a player A is kicked offline, since ETCD 130 records the registration information of each server, the external application can query ETCD 130 for the host global server (S41) of the corresponding global business (such as the player-kicking business). The external application, after querying the host global server of the corresponding global business (such as... Figure 4When a player manages the host global server, a request to kick player A offline can be sent to the host global server (S42). The player management host global server sends this request to the proxy server (S43). When the proxy server receives the request to kick player A offline from the player management host global server, it can kick player A off the server based on the request, thus putting player A in an offline state, and return the execution result to the external application through the player management host global server (S44), thereby completing a simple player kicking operation.

[0040] For example, such as Figure 5 As shown, taking a simple business logic of refreshing a non-player character NPC as an example, assuming the external application is a game application, when it needs to refresh an NPC in the game, it first needs to query the ETCD 130 for the host global server corresponding to the NPC refresh business. Since the ETCD 130 records the registration information of each server, the external application can query the ETCD 130 for the host global server corresponding to the global business (such as refreshing the NPC) (S51). The external application, after querying the host global server corresponding to the global business (such as refreshing the NPC),... Figure 5 When the NPC management host global server is in use, it can send a request to create an NPC to the host global server (S52). The NPC management host global server sends the request to the NPC server (S53). When the NPC server receives the request from the host global server, it can create an NPC based on the request and return the NPC creation result to the external application through the NPC management host global server (S54), thereby completing a simple NPC refresh operation.

[0041] It's important to note that the host global server can be implemented as a stateless server, supporting recovery after any normal or illegal shutdown. All data after recovery must be consistent with the data before recovery. To achieve this stateless and recoverable requirement, Redis is needed as an extension of the server's in-memory data storage. After the host global server is shut down, it can be restored via Redis. Therefore, when implementing the business logic of the host global server, it's necessary to ensure that after each atomic operation, at least the data in Redis will not be in a dirty state. The following section provides a detailed explanation of the NPC refresh logic.

[0042] For example, such as Figure 6As shown, the NPC refreshing interaction logic in the host global server is as follows: when the host global server receives a request for creating an NPC sent by an external application, the host global server can call the marker symbol "*" and send an NPC refreshing service state to Redis to mark the service state as 1 (S61). After sending the NPC refreshing service state to Redis to mark the service state as 1, the host global server can send a request for refreshing an NPC to the scene server (S62). When the scene server receives the request for refreshing an NPC, the scene server creates an NPC (S63) and returns a successful creation to the host global server and saves the created NPC to the cache server (S64). The cache server stores the NPC created by the scene server, where the stored content can be background information of the NPC. When the host global server receives the NPC creation success returned by the scene server, the host global server can store NPC creation information to the cache server (S65), so that the cache server stores the NPC creation information, where the NPC creation information can be understood as existence time, location, service correlation, disappearance time, and the like of the NPC, and the marker symbol "*" is called to send an NPC refreshing service state to Redis to mark the service state as complete (S66).

[0043] It should be noted that Redis can record the current progress and the context of the operation. If the host global server is closed at any time point between the two "*" s, the context information saved on Redis can be used to complete the entire operation again after the host global server is started again, so as to maintain the consistency of the data.

[0044] It should be further noted that, due to the Redis in the business processing system of the embodiment of the present application, the memory data of a single host global server can be changed into a network form. Therefore, the host global server can be clustered regardless of the type. The Redis includes multiple shards, and each shard independently stores different global data through a name naming manner. That is, the Redis of different businesses is completely independent in the name space, and different business logics can use the same Redis or completely independent different Redis.

[0045] In an implementation manner, the name space of Redis can adopt a form of "business name.data name" to independently store different global data. The host global server accesses the business data in the Redis space of the host global server, and the host global server or other servers are prohibited from directly accessing the Redis data not belonging to the host global server. After the data is divided by using the name space, the Redis can be more conveniently scattered or stored in a centralized manner.

[0046] It is worth noting that, in designing specific business processes, the host global server in this application embodiment needs to consider the consistency issue of multiple global servers simultaneously writing data. The host global server can use multiple threads and coroutines to independently process global business logic simultaneously. This global business logic supports multi-threaded processing and can support cluster solutions. After startup, servers within the cluster establish permanent TPC (Transmission Control Protocol) connections with other servers in the cluster. When a server completes a write operation and updates Redis, it needs to broadcast the updated data to other servers for synchronization. During data synchronization, the data to be synchronized is not read from Redis.

[0047] It should be noted that both the parasitic server and the host global server in this application embodiment register on ETCD upon startup, writing their own information, such as server ID, IP port, etc. In some embodiments of this application, the host global server is also used to obtain first registration configuration information from ETCD and register on ETCD based on the first registration configuration information; the parasitic server is also used to obtain second registration configuration information from ETCD and register on ETCD based on the second registration configuration information; the parasitic server is also used to obtain first connection information of the host global server from ETCD and establish a connection with the host global server based on the first connection information; the parasitic server is also used to obtain second connection information of other parasitic servers from ETCD and establish connections with other parasitic servers based on the second connection information.

[0048] For example, such as Figure 7 As shown, taking server B and server A as examples of parasitic servers, the server registration query connection request process can be as follows: The host global server obtains registration configuration information from ETCD (S71), and registers on ETCD based on the registration configuration information, writing its own information, such as server ID, IP port, etc. (S72). Server B obtains registration configuration information from ETCD (S73), and registers on ETCD based on the registration configuration information, writing its own information, such as server ID, IP port, etc. (S74). Server A obtains registration configuration information from ETCD (S75), and registers on ETCD based on the registration configuration information, writing its own information, such as server ID, IP port, etc. (S76).

[0049] like Figure 7As shown, after both the host global server and server B have registered on ETCD, server B can send a request to ETCD to obtain the host global server connection information, so that server B can establish a connection with the host global server based on this connection information. ETCD can send the host global server connection information (such as the host global server's identifier ID, IP port, etc.) to the server based on server B's request, thereby enabling server B to obtain the host global server connection information from ETCD (S77). When server B obtains the host global server connection information, it can establish a connection between server B and the host global server based on this connection information (S78). After both the host global server and server A have registered on ETCD, server A can send a request to ETCD to obtain the host global server connection information, so that server A can establish a connection with the host global server based on this connection information. ETCD can send the host global server connection information (such as the host global server's identifier ID, IP port, etc.) to server A based on server A's request, thereby enabling server A to obtain the host global server connection information from ETCD (S79). When server A obtains the connection information of the host global server, it can establish a connection between server A and the host global server based on the connection information (S710).

[0050] Optionally, server A and server B can establish a connection to enable interaction between them. For example... Figure 7 As shown, when server A needs to interact with server B, a connection between server A and server B must first be established. The connection can be established as follows: Server A can send a request to ETCD to obtain server B's connection information, allowing server A to establish a connection based on this information. ETCD can then send server B's connection information (such as server B's ID, IP address, and port) to server A based on the request, enabling server A to obtain server B's connection information from ETCD (S711). Upon obtaining server B's connection information, server A can establish a connection between server A and server B based on this information (S712) and send request data to server B based on this connection (S713). Server B processes the request data accordingly and returns the result to server A (S714). If the connection between server A and server B is not used for a certain period, the connection is closed. For example, if server A and server B do not interact for a certain period, the connection is closed (S715). Therefore,Figure 7 A complete process of starting and establishing a connection between servers is shown. All the connections between the parasitic servers and the host global server are long connections. The connections between the parasitic servers can be semi-long connections (e.g., disconnected if not used for a certain time). It should be noted that the parasitic servers have no other configuration information except the connection information of ETCD, and these configuration information are pulled from the ETCD server.

[0051] According to the business processing system based on the distributed computing framework, the global data of the business can be stored and the global logic can be performed based on the global server, the availability and feasibility of the business processing system are guaranteed, and the performance and efficiency of the business processing system are improved.

[0052] In order to realize the above-mentioned embodiments, the application further provides a business processing method based on a distributed computing framework. The method can be applied to the business processing system of any one of the above-mentioned embodiments. As shown in the method can include but is not limited to the following steps. Figure 8

[0053] In step 801, at least one global business is loaded; each global business is registered with the service registration center ETCD, and the respective business data is obtained from the data structure server Redis.

[0054] For example, the host global server can provide an interface for the parasitic server, the interface is organized in the form of a global business module, for example, global business 1 and global business 2, the global business logic of global business 1 and global business 2 can be organized by the host global server. Global business 1 is registered with ETCD, and the business data of global business 1 is obtained from Redis. Global business 2 is registered with ETCD, and the business data of global business 2 is obtained from Redis. The host global server 120 loads global business 1 and global business 2 respectively.

[0055] In step 802, the host global server information of the business is obtained from ETCD, and a first operation request for the target global business is initiated based on the host global server information of the business; wherein the first operation request is used to instruct the target global business to perform the corresponding operation, and the latest global business data after the operation is synchronized to each parasitic server subscribing to the target global business.

[0056] Optionally, as Figure 2 ​As shown, server B can obtain the host global server information where global service 1 is located from ETCD, and notify the host global server that server B is interested in the global service 1. Server A can obtain the host global server information where global service 1 and global service 2 are located from ETCD, and notify the host global server that server A is interested in the global service 1 and global service 2. Server B can initiate an operation request for global service 1 based on the host global server information where global service 1 is located. Global service 1 performs corresponding operation based on the operation request, and updates the latest global service data after operation to Redis. Global service 1 can also synchronize the latest global service data after operation to server A and server B which subscribe (or are interested in) the global service 1, so that each parasitic server saves a copy of the latest global service data, realizing a cache type process of global service logic and data processing, which is suitable for the case of small amount of business data and high real-time requirement.

[0057] It should be noted that for the case of large amount of business data and low real-time requirement, a non-cache type process of global service logic and data processing can be realized. Alternatively, the parasitic server can obtain the global service data corresponding to the second operation request from the target global service based on the asynchronous callback mechanism when initiating the second operation request for the target global service based on the host global server information where the business is located.

[0058] For example, taking server B and server A as the parasitic server, as shown in Figure 3 The non-cache type process of global service logic and data processing is as follows: global service 1 registers with ETCD, and obtains the business data of global service 1 from Redis. Global service 2 registers with ETCD, and obtains the business data of global service 2 from Redis. Host global server 120 loads global service 1 and global service 2 respectively.

[0059] Server B can obtain the host global server information where global service 1 is located from ETCD. Server A can obtain the host global server information where global service 1 and global service 2 are located from ETCD. Server B can initiate an operation request for global service 1 based on the host global server information where global service 1 is located. Global service 1 performs corresponding operation based on the operation request, and updates the latest global service data after operation to Redis. Server B can obtain the global service data corresponding to the operation request from global service 1 based on the asynchronous callback mechanism. Server A can obtain the global service data corresponding to the operation request from global service 1 based on the asynchronous callback mechanism. As can be seen, each parasitic server does not save the global service data locally, and obtains the data through synchronous call each time, realizing a non-cache type process of global service logic and data processing, which is suitable for the case of large amount of business data and low real-time requirement.

[0060] It's important to note that the host global server can be implemented as a stateless server, supporting recovery after any normal or illegal shutdown. All data after recovery must be consistent with the data before recovery. To achieve this stateless and recoverable requirement, Redis is needed as an extension of the server's in-memory data storage. After the host global server is shut down, it can be restored via Redis. Therefore, when implementing the business logic of the host global server, it's necessary to ensure that after each atomic operation, at least the data in Redis will not be in a dirty state. The following section provides a detailed explanation of the NPC refresh logic.

[0061] For example, such as Figure 6 As shown, the NPC refresh interaction logic in the host global server is as follows: The host global server can call the marker symbol "*" to send the NPC refresh business status to Redis, marking the business status as 1. The host global server sends a refresh NPC request to the scene server. The scene server creates the NPC based on the request, returns a success message to the host global server, and saves the created NPC to the cache server. When the host global server receives the NPC creation success message from the scene server, it can store the NPC creation information in the cache server and call the marker symbol "*" to send the NPC refresh business status to Redis, marking the business status as complete.

[0062] It should be noted that Redis can record the current progress and the context of the operation. If the host global server shuts down at any point between the two "*", it can be restarted and the entire operation can be completed using the context information saved on Redis, thus maintaining the consistency of the state and keeping the data consistent.

[0063] It should also be noted that, because the business processing system in this embodiment of the application uses Redis, the in-memory data of a single host global server can be transformed into a network format. Therefore, the host global server, regardless of its type, can be clustered. Redis includes multiple shards, each shard using a naming convention to independently manage different global data. In other words, the Redis instances for different services are completely independent in namespace; different business logics can use the same Redis instance or completely independent different Redis instances.

[0064] In one implementation, Redis namespaces can be structured as "business name.data name" to isolate different global data. The host global server accesses business data within its own Redis namespace, preventing the host global server or other servers from directly accessing Redis data that doesn't belong to them. Using namespaces to partition data makes it easier to implement distributed or centralized Redis storage.

[0065] It should also be noted that both the parasitic server and the host global server in this application embodiment register on ETCD upon startup, writing their own information, such as server ID, IP port, etc. In some embodiments of this application, the host global server can also obtain the first registration configuration information of the host global server from ETCD, and register the host global server on ETCD based on the first registration configuration information; obtain the second registration configuration information of the parasitic server from ETCD, and register the parasitic server on ETCD based on the second registration configuration information; obtain the first connection information of the host global server from ETCD, and establish a connection between the parasitic server and the host global server based on the first connection information; obtain the second connection information of other parasitic servers from ETCD, and establish connections between the parasitic server and other parasitic servers based on the second connection information.

[0066] For example, such as Figure 7 As shown, taking server B and server A as examples of parasitic servers, the server registration query connection request process can be as follows: The host global server obtains registration configuration information from ETCD and registers on ETCD based on this registration configuration information, writing its own information, such as server ID, IP port, etc. Server A obtains registration configuration information from ETCD and registers on ETCD based on this registration configuration information, writing its own information, such as server ID, IP port, etc. Server B obtains registration configuration information from ETCD and registers on ETCD based on this registration configuration information, writing its own information, such as server ID, IP port, etc.

[0067] like Figure 7 As shown, after both the host global server and server B have registered on ETCD, server B can obtain the connection information of the host global server from ETCD and establish a connection between server B and the host global server based on this connection information. Similarly, after both the host global server and server A have registered on ETCD, server A can obtain the connection information of the host global server from ETCD and establish a connection between server A and the host global server based on this connection information.

[0068] Optional, such asFigure 7 As shown, server A can also obtain the connection information of server B from ETCD, and establish a connection between server A and server B based on the connection information, and send request data to server B based on the connection. Server B performs corresponding processing based on the request data, and returns the processing result to server A. If the connection between server A and server B is not used for a certain period of time, the connection between server A and server B is disconnected. As can be seen, Figure 7 A complete process of starting and establishing a connection between servers is shown. The connection between all parasitic servers and the host global server is a long connection. The connection between parasitic servers can be a semi-long connection (e.g., the connection is disconnected if it is not used for a certain period of time). It should be noted that the parasitic server has no other configuration information except the connection information of ETCD, and these configuration information are pulled from the ETCD server.

[0069] According to the business processing method based on the distributed computing framework, the global data of the business can be stored and global logic can be performed based on the global server, the availability and feasibility of the business processing system are guaranteed, and the performance and efficiency of the business processing system are improved.

[0070] It should be understood that various forms of the above-described processes can be used to reorder, add or delete steps. For example, the steps described in the present application can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solutions disclosed in the present application can be achieved, which are not limited herein.

[0071] The above specific embodiments do not constitute a limitation on the scope of protection of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modifications, equivalent replacements and improvements made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A service processing system based on a distributed computing framework, comprising: at least one parasite server, a host global server, an ETCD service registry, and a Redis data structure server, wherein, the host global server is configured to load at least one global service; each global service is registered with the ETCD and obtains respective service data from the Redis; the parasite server is configured to obtain host global server information of a target global service from the ETCD and initiate a first operation request for the target global service based on the host global server information; the first operation request is used to instruct the target global service to perform a corresponding operation and synchronize latest global service data after the operation to each parasite server that subscribes to the target global service; the host global server is further configured to obtain first registration configuration information from the ETCD and register on the ETCD based on the first registration configuration information; the parasite server is further configured to obtain second registration configuration information from the ETCD and register on the ETCD based on the second registration configuration information; the parasite server is further configured to obtain first connection information of the host global server from the ETCD and establish a connection with the host global server based on the first connection information; the parasite server is further configured to obtain second connection information of other parasite servers from the ETCD and establish a connection with the other parasite servers based on the second connection information.

2. The system of claim 1, wherein, the parasite server is further configured to obtain global service data corresponding to a second operation request from the target global service based on an asynchronous callback mechanism when initiating the second operation request for the target global service based on the host global server information.

3. The system of claim 1, wherein, the target global service is further configured to update the latest global service data to the Redis.

4. The system of claim 1, wherein, Global service logic in the host global server provides a control interface to the outside through a definition of a protocol buffer (Protobuf).

5. The system of claim 1, wherein, the Redis is further configured to: after the host global server is closed and started again, complete the entire operation of the host global server based on recorded context information to maintain data consistency.

6. The system of claim 1, wherein, The host global server uses a combination of multiple threads and coroutines to simultaneously and independently process global service logic.

7. The system of claim 1, wherein, The Redis includes multiple shards, each of which independently stores different global data through a name naming method.

8. The system of claim 1, wherein, The connection established between the at least one parasite server is a semi-long connection; and the connection established between each parasite server and the host global server is a long connection.

9. A method of business processing based on a distributed computing framework, the method being applied to the business processing system according to any one of claims 1 to 8, wherein, The method comprises: loading at least one global service; each global service is registered with an ETCD service registry and obtains respective service data from a Redis data structure server; Obtaining host global server information of a service from the ETCD, and initiating a first operation request for a target global service based on the host global server information of the service; wherein the first operation request is used to instruct the target global service to perform a corresponding operation, and synchronize the latest global service data after operation to each parasitic server subscribing to the target global service.

10. The method of claim 9, further comprising: When initiating a second operation request for the target global service based on the host global server information of the service, obtaining global service data corresponding to the second operation request from the target global service based on an asynchronous callback mechanism.

11. The method of claim 9, further comprising: After the host global server is closed and started again, the entire operation of the host global server is completed according to the context information recorded in the Redis, so as to maintain the consistency of data.

12. The method of claim 9, further comprising: Obtaining first registration configuration information of the host global server from the ETCD, and registering the host global server on the ETCD based on the first registration configuration information; Obtaining second registration configuration information of the parasitic server from the ETCD, and registering the parasitic server on the ETCD based on the second registration configuration information; Obtaining first connection information of the host global server from the ETCD, and establishing a connection between the parasitic server and the host global server based on the first connection information; Obtaining second connection information of other parasitic servers from the ETCD, and establishing a connection between the parasitic server and the other parasitic servers based on the second connection information.

13. The method of claim 12, wherein, The connection established between the at least one parasitic server is a semi-long connection; and the connection established between each parasitic server and the host global server is a long connection.

Images