A request processing method, device, storage medium and computer program product

Abstract

Embodiments of the present application provide a request processing method, the method comprising: obtaining a to-be-processed service request; determining a first target node corresponding to the to-be-processed service request from a plurality of candidate nodes based on request information carried in the to-be-processed service request and an identifier of each candidate node in a distributed system; the request information representing a source and a type of a service corresponding to the to-be-processed service request; the request information of a plurality of service requests belonging to a same transaction being the same; and sending the to-be-processed service request to the first target node, so that the first target node processes the to-be-processed service request, thereby solving the problem in the related art that a plurality of service requests belonging to a same transaction are distributed to different data centers, resulting in inconsistency between a processing order and an occurrence order of the service requests, and further resulting in inconsistency of data between the data centers. Embodiments of the present application also provide a request processing device, a storage medium and a computer program product.

Description

Technical Field

[0001] This application relates to the field of big data, and in particular to a request processing method, device, storage medium, and computer program product. Background Technology

[0002] In distributed systems, "active-active architecture across different locations" has become a key technology for ensuring business continuity. Currently, in active-active architecture across different locations, all pending business requests are typically aggregated to a global load balancing module, which then uses a round-robin approach to evenly distribute multiple business requests to multiple data centers within the active-active structure for processing. However, this approach can lead to multiple business requests belonging to the same transaction (e.g., transfer) being distributed to multiple different data centers (e.g., deduction and crediting). This cannot guarantee that the processing order of these business requests is consistent with their order of occurrence (e.g., deduction before crediting), thus disrupting the sequentiality of transactions, resulting in data inconsistencies between data centers and ultimately causing data chaos. Summary of the Invention

[0003] To address the aforementioned technical problems, this application aims to provide a request processing method, device, storage medium, and computer program product, which solves the problem in the related art where multiple business requests belonging to the same transaction are assigned to different data centers, resulting in an inconsistency between the processing order and the occurrence order of the business requests, and consequently, data inconsistency between the data centers.

[0004] To achieve the above objectives, the technical solution of this application embodiment is implemented as follows: A request processing method, applied to an edge node in a distributed system, the method comprising: Get pending business requests; Based on the request information carried in the pending business request and the identifier of each candidate node in the distributed system, the first target node corresponding to the pending business request is determined from multiple candidate nodes; wherein, the request information represents the source and type of the business corresponding to the pending business request; the request information of multiple business requests belonging to the same transaction is the same; The pending service request is sent to the first target node so that the first target node can process the pending service request.

[0005] In the above scheme, determining the first target node corresponding to the service request to be processed from multiple candidate nodes based on the request information carried in the service request to be processed and the identifier of each candidate node in the distributed system includes: Perform a hash operation on the request information to obtain a hash value; The target value is determined based on the hash value and the number of candidate nodes. Based on the target value and the number of each candidate node, the first target node is determined from the plurality of candidate nodes; wherein the identifier includes the number.

[0006] A request processing method, applied to a first target node in a distributed system, the method comprising: Receive pending service requests sent by edge nodes; wherein, the first target node is determined by the edge node based on the request information carried in the pending service request and the identifier of each candidate node; the request information characterizes the source and type of the service corresponding to the pending service request; multiple service requests belonging to the same transaction have the same request information; Process the pending service requests; If the pending service request is successfully processed and the first service data stored in the first target node has changed, a synchronization request carrying the first change information of the first service data is sent to the second target node, so that the second target node can perform change processing on the second service data stored in the second target node based on the first change information; wherein, the second target node is a node other than the first target node among a plurality of candidate nodes.

[0007] In the above scheme, sending a synchronization request carrying change information of the first business data in the first target node to the second target node includes: Invoke the target interface of the second target node and send the synchronization request to the second target node.

[0008] The method in the above scheme further includes: Retrieve baseline business data from the target database; According to the target error correction cycle, the target data error correction algorithm is used to perform error correction processing on the first business data based on the benchmark business data.

[0009] The method in the above scheme further includes: If the first target node is the master node of the distributed system, and the first service configuration data stored in the first target node has changed, the second service configuration data stored in the second target node is modified using one-way synchronization technology.

[0010] A request processing method, applied to a second target node in a distributed system, the method comprising: Receive a synchronization request sent by a first target node; wherein, the first target node is determined by the edge node based on the request information carried in the pending service request and the identifier of each candidate node; the request information represents the source and type of the service corresponding to the pending service request; the request information of multiple service requests belonging to the same transaction is the same; the second target node is a node other than the first target node among multiple candidate nodes; Based on the first change information carried in the synchronization request, the second business data in the second target node is modified; wherein, the first change information is the change information of the first business data stored in the first target node.

[0011] The method in the above scheme further includes: Retrieve baseline business data from the target database; According to the target error correction cycle, the target data error correction algorithm is used to perform error correction processing on the second business data based on the benchmark business data.

[0012] The method in the above scheme further includes: If the second target node is the master node of the distributed system, and the second service configuration data stored in the second target node has changed, the first service configuration data stored in the first target node is modified using one-way synchronization technology.

[0013] A first request processing apparatus, the apparatus comprising: The acquisition unit is used to acquire business requests to be processed. The first determining unit is configured to determine the first target node corresponding to the business request to be processed from multiple candidate nodes based on the request information carried in the business request to be processed and the identifier of each candidate node in the distributed system; wherein, the request information represents the source and type of the business corresponding to the business request to be processed; and the request information of multiple business requests belonging to the same transaction is the same. The first sending unit is used to send the pending service request to the first target node so that the first target node can process the pending service request.

[0014] A second request processing apparatus, the apparatus comprising: The first receiving unit is used to receive pending service requests sent by edge nodes; wherein, the first target node is determined by the edge node based on the request information carried in the pending service request and the identifier of each candidate node; the request information characterizes the source and type of the service corresponding to the pending service request; the request information of multiple service requests belonging to the same transaction is the same. The first processing unit is used to process the pending service request.

[0015] The second sending unit is configured to, if the pending service request is successfully processed and the pending service request is a data change request, send a synchronization request carrying first change information of the first service data in the first target node to the second target node, so that the second target node performs change processing on the second service data in the second target node based on the first change information; wherein, the second target node is a node other than the first target node among a plurality of candidate nodes.

[0016] A third request processing apparatus, the apparatus comprising: The second receiving unit is used to receive a synchronization request sent by the first target node; wherein, the first target node is determined by the edge node based on the request information carried in the service request to be processed and the identifier of each candidate node; the request information represents the source and type of the service corresponding to the service request to be processed; the request information of multiple service requests belonging to the same transaction is the same; the second target node is a node other than the first target node among multiple candidate nodes; The second processing unit is used to perform change processing on the second business data in the second target node based on the first change information carried in the synchronization request; wherein, the first change information is the change information of the first business data stored in the first target node.

[0017] A request processing device, the device comprising: a processor, a memory, and a communication bus; The communication bus is used to realize the communication connection between the processor and the memory; The processor is used to execute the request processing program in the memory to implement the steps of the request processing method described above.

[0018] A storage medium storing one or more programs that can be executed by one or more processors to implement the steps of the request processing method described above.

[0019] A computer program product comprising a computer program that, when executed by a processor, implements the above-described request processing method.

[0020] The request processing method, apparatus, device, storage medium, and computer program product provided in this application can obtain a pending business request and determine the first target node corresponding to the pending business request from multiple candidate nodes based on the request information carried in the pending business request and the identifier of each candidate node in the distributed system. The request information represents the source and type of the business corresponding to the pending business request; multiple business requests belonging to the same transaction have identical request information; the pending business request is sent to the first target node so that the first target node processes the pending business request. Thus, since the request information of multiple business requests belonging to the same transaction is identical, it can be guaranteed that the final determined target node belongs to the same... Multiple business requests within a transaction share the same primary target node. This means that multiple business requests belonging to the same transaction will be assigned to the same node (the primary target node). The primary target node can then process these requests sequentially according to their order of occurrence, ensuring the transaction's orderliness. This solves the problem in related technologies where multiple business requests belonging to the same transaction are assigned to different data centers, leading to inconsistencies between the processing order and the order of occurrence, and consequently, data inconsistencies between data centers. It also prevents data chaos across data centers. Attached Figure Description

[0021] Figure 1 This is a first flowchart illustrating a request processing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the architecture corresponding to a request processing method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the architecture of an existing off-site active-active disaster recovery system in a request processing method provided in an embodiment of this application; Figure 4 This is a second flowchart illustrating a request processing method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the third process of a request processing method provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating the interaction between an edge node, a first target node, and a second target node in a request processing method provided in an embodiment of this application. Figure 7 This is a schematic diagram of the structure of a first request processing device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a second request processing device provided in an embodiment of this application; Figure 9This is a schematic diagram of the structure of a third request processing device provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of an edge node in a distributed system provided in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of a first target node in a distributed system provided in an embodiment of this application; Figure 12 This is a schematic diagram of the structure of a second target node in a distributed system provided in an embodiment of this application. Detailed Implementation

[0022] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0023] It should be understood that the phrases "embodiments of this application" or "foreign embodiments" throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, "embodiments of this application" or "in the foreign embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0024] Unless otherwise specified, any step in the embodiments of this application performed by the electronic device may be executed by the processor of the electronic device. It is also worth noting that the embodiments of this application do not limit the order in which the electronic device performs the following steps. Furthermore, the methods used to process data in different embodiments may be the same or different methods. It should also be noted that any step in the embodiments of this application can be executed independently by the electronic device; that is, when the electronic device performs any step in the following embodiments, it may not depend on the execution of other steps.

[0025] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0026] This application provides a request processing method, which can be applied to edge nodes in a distributed system. (Refer to...) Figure 1 As shown, the method may include the following steps: Step 101: Obtain pending business requests.

[0027] In this embodiment of the application, the distributed system may include a master node, slave nodes, and edge nodes. Typically, there is only one master node; there may be one or more slave nodes; and there may also be one or more edge nodes.

[0028] It should be noted that edge nodes are oriented towards business nodes (i.e., the nodes that initiate business requests), and one edge node typically corresponds to multiple business nodes. These business nodes can be devices such as mobile phones, computers, and servers.

[0029] In this embodiment, the master node and slave node form a geographically dispersed active-active architecture by being deployed in different geographic locations. In one possible implementation, such as... Figure 2 As shown, there is only one master node and one slave node. In this case, the geographically distributed active-active architecture includes one master node and one slave node (also called a backup node). It should be noted that in the geographically distributed active-active architecture, both the master node and the backup node can provide services normally, that is, they can process the received business requests normally, rather than only the master node being able to provide services.

[0030] It should be noted that a node can refer to a data center or a server room.

[0031] In this embodiment, the pending business request refers to a business request initiated by a business node for a currently pending business. These pending business requests can be categorized into two types: "change type" requests (requiring changes to data stored in the data center) and "read type" requests (requiring queries for required data from the data center's storage). It should be noted that change type requests can include write, delete, and modify types.

[0032] In one feasible approach, if this application is applied to a live streaming distribution business scenario for audio and video streams, then the business can refer to the live streaming business, and the pending business requests can refer to push streaming requests, stream information query requests, end push streaming requests, etc.

[0033] Step 102: Based on the request information carried in the pending business request and the identifier of each candidate node in the distributed system, determine the first target node corresponding to the pending business request from multiple candidate nodes.

[0034] The request information represents the source and type of the business corresponding to the business request to be processed; the request information of multiple business requests belonging to the same transaction is the same.

[0035] In this embodiment, the source of the business (which can be simply referred to as the business source) can refer to the platform that initiates the business, and the type of business (which can be simply referred to as the business type) can refer to what the business specifically does. In one possible implementation, if this application is applied to a live streaming distribution business scenario, the business source can include various short video platforms and video playback platforms, while the business type can include selling clothing, selling snacks, etc. In this case, the request information can include the domain name information of the platform that initiates the business, a first identifier of the business type, and a second identifier of the live stream. The second identifier is used to identify the live streaming room on the video platform; that is, different live streaming rooms have different second identifiers.

[0036] It should be noted that the same request information for multiple business requests belonging to the same transaction means that if multiple business requests belong to the same transaction, then the domain name information of the platform initiating the business, the first identifier of the business type, and the second identifier of the live stream are all the same.

[0037] In this embodiment, a transaction is typically treated as an indivisible unit of work to perform a series of operations. One business operation corresponds to multiple transactions, and one transaction corresponds to multiple business requests. It should be noted that the multiple business requests corresponding to a transaction either all succeed or all fail; there is no intermediate state where some succeed and some fail.

[0038] For example, if this application is applied to a live streaming distribution business scenario, then the business can refer to the live streaming business, and the transaction can refer to a live stream of a certain type conducted in a certain live streaming room on a certain platform (for example, a live streaming of clothing sales conducted in a live streaming room B on a short video platform A). Then, the multiple business requests corresponding to the transaction can include push streaming requests, product listing requests, user order placement requests, inventory query requests, product price update requests, and push streaming termination requests, etc. At this time, the request information of the multiple business requests corresponding to the transaction is the same, that is, the domain name information is the domain name of the short video platform A, the first identifier is the identifier of the clothing sales business type, and the second identifier is the identifier of the live streaming room B (i.e., the ID of the live streaming room B).

[0039] In this embodiment, the candidate nodes may include all primary and backup nodes in a geographically distributed active-active architecture; the first target node may refer to... It should be noted that there are at least two candidate nodes in the distributed system.

[0040] In one feasible approach, if the geographically distributed active-active architecture has only one primary node and one backup node, then there are only two candidate nodes.

[0041] It should be noted that since multiple business requests belonging to the same transaction have the same request information, if it is determined that multiple pending business requests have the same request information, it means that these multiple pending business requests belong to the same transaction. At this time, there is only one first target node determined based on the request information and the identifier of the candidate node, that is, the first target node corresponding to the multiple pending business requests belonging to the same transaction is the same.

[0042] In the embodiments of this application, the first target node can be a master node or a backup node.

[0043] Step 103: Send the pending business request to the first target node so that the first target node can process the pending business request.

[0044] In this embodiment of the application, after determining the first target node corresponding to the service request to be processed, the service request to be processed can be sent to the first target node so that the first target node can process the service request to be processed.

[0045] It should be noted that multiple pending business requests belonging to the same transaction will be assigned to the first target node, rather than as in related technologies (such as...). Figure 3 As shown in the diagram, the global load balancing module uses a round-robin approach to distribute multiple business requests to the first and second data centers. This is to prevent the "global load balancing module" from becoming a single point of bottleneck, and to ensure that a group of business requests "belonging to the same transaction" can be processed sequentially by the same data center according to the order in which they occur.

[0046] The request processing method provided in this application embodiment ensures that the first target node corresponding to the multiple business requests belonging to the same transaction is the same because the request information of multiple business requests belonging to the same transaction is identical. In other words, the nodes to which the multiple business requests belonging to the same transaction are assigned are consistent, thus guaranteeing that the multiple business requests belonging to the same transaction will be assigned to the same node (i.e., the first target node). In this way, the first target node can process the multiple business requests sequentially according to the order in which the business requests occur, thereby ensuring the order of transactions. This solves the problem in related technologies where multiple business requests belonging to the same transaction are assigned to different data centers, resulting in an inconsistency between the processing order and the order in which the business requests occur, and thus causing data inconsistency between data centers. At the same time, it can avoid the problem of data chaos in each data center.

[0047] Based on the foregoing embodiments, embodiments of this application provide a request processing method, which can be applied to a first target node in a distributed system, referring to... Figure 4 As shown, the method may include the following steps: Step 201: Receive pending service requests sent by edge nodes.

[0048] The first target node is determined by the edge node based on the request information carried in the business request to be processed and the identifier of each candidate node; the request information represents the source and type of the business corresponding to the business request to be processed; business requests belonging to the same transaction have the same request information.

[0049] In this embodiment of the application, the first target node may refer to the node to which the pending service request, as determined by the edge node, is to be assigned. Specifically, as shown below... Figure 2 As shown, the active-active core module in the first target node can receive pending service requests sent by the edge node.

[0050] Step 202: Process the business requests to be processed.

[0051] In this embodiment of the application, after receiving the business request to be processed, the first target node will process the business request to be processed according to the preset business logic.

[0052] Specifically, if the type of the business request to be processed is a change type, then when the first target node processes the business request, it will simultaneously change the business data related to that business stored in its own first database.

[0053] In one feasible approach, if this application is applied to a live streaming distribution business scenario and the business request to be processed is a push stream request, then its type is the write type in the change type. In the process of processing the push stream request, the first target node will synchronously store the stream information of the live stream in the first database, that is, perform stream registration. If the business request to be processed is to end the push stream, then its type is the modification type in the change type. At this time, it is necessary to change the status of the stream in the first database.

[0054] Correspondingly, if the business request to be processed is a stream information query, then its type is a read type (also known as a query type). After receiving the business request to be processed sent by the edge node, the active-active core module in the first target node can obtain the corresponding stream information from the first database according to the request information carried in the request, and the active-active core module will return the queried stream information to the edge node.

[0055] In this embodiment of the application, when the first target node processes multiple pending business requests belonging to the same transaction, it will process them in the order in which they occur to ensure the order of the transactions.

[0056] Step 203: If the pending business request is successfully processed and the first business data stored in the first target node has changed, send a synchronization request carrying the first change information of the first business data to the second target node so that the second target node can change the second business data stored in the second target node based on the first change information.

[0057] The second target node is a node other than the first target node among multiple candidate nodes.

[0058] In this embodiment, the second target node can refer to any node in the geographically distributed active-active architecture other than the first target node. It should be noted that the first target node can be either a primary node or a backup node; similarly, the second target node can be either a primary node or a backup node.

[0059] In this embodiment of the application, the first business data may refer to the business-related data stored in the first database of the first target node; successfully processing the pending business request may mean that the pending business request has been successfully executed, which means that the business data in the first database has been successfully modified, or the corresponding information has been retrieved from the first database; if the first business data stored in the first database has been modified, it indicates that the type of the pending business request is a change type.

[0060] In one possible implementation, if this application is applied to a live streaming distribution business scenario, the first business data can refer to the streaming information mentioned in step 202. Specifically, if the pending business request is successfully processed and the streaming information stored in the first database has changed (i.e., the type of the pending business request is a changed type), further data synchronization is required. That is, a synchronization request carrying the first change information of the first business data is sent to other nodes (i.e., the second target node) through the dual-active core module, so that the second target node can synchronize and change the second business data stored in its own database according to the first change information.

[0061] It should be noted that in a geographically distributed active-active architecture, each node serves as a backup for the other. This means that the data stored on each node is identical, i.e., the data stored in the databases of each node is the same.

[0062] In the embodiments of this application, such as Figure 3As shown, in related technologies, middleware modules are typically used to write data to both the first and second nodes simultaneously. For example, after a business request is assigned to the first node, the middleware module in the first node will simultaneously write business data to both the first node's own database and the database of the second node. Only when the business data is successfully written to both databases can the business request be considered successfully processed. Otherwise, if the write fails in either database, the business request is considered to have failed, and the corresponding error handling logic is executed. In other words, in related technologies, a node needs to be responsible for writing business data to itself and other nodes simultaneously. This cross-datacenter writing method will significantly increase the node's own load and network latency, thereby affecting the processing time of business requests and resulting in poor processing efficiency. The "dual-active core module" introduced in this application only needs to write business data to its own node's database, without having to write business data to other nodes across data centers. This is equivalent to multiple nodes in a geographically distributed dual-active architecture having the same logic for handling successful / failed writes. Each node is only responsible for handling successful / failed writes to its own database, without having to consider the logic for handling successful / failed writes to databases in other data centers. This avoids the time-consuming and complex fault-tolerance logic of related technologies that write data to the databases of two nodes simultaneously, thereby improving the processing efficiency of business requests.

[0063] The request processing method provided in the embodiments of this application ensures that the first target node corresponding to the multiple business requests belonging to the same transaction is the same because the request information of multiple business requests belonging to the same transaction is identical. In other words, the nodes to which the multiple business requests belonging to the same transaction are assigned are consistent, thus ensuring that the multiple business requests belonging to the same transaction will be assigned to the same node (i.e., the first target node). In this way, the first target node can process the multiple business requests sequentially according to the order in which the business requests occur, thereby ensuring the order of transactions. This solves the problem in related technologies where multiple business requests belonging to the same transaction are assigned to different data centers, resulting in an inconsistency between the processing order and the order in which the business requests occur, and thus causing data inconsistency between data centers. At the same time, it can avoid the problem of data chaos in each data center. In addition, when the data in the first database changes, a synchronization request carrying the first change information can be sent to the second target node in a timely manner to achieve data synchronization between nodes.

[0064] Based on the foregoing embodiments, embodiments of this application provide a request processing method, which can be applied to a second target node in a distributed system, with reference to... Figure 5 As shown, the method may include the following steps: Step 301: Receive the synchronization request sent by the first target node.

[0065] The first target node is determined by the edge node based on the request information carried in the business request to be processed and the identifier of each candidate node; the request information represents the source and type of the business corresponding to the business request to be processed; the request information of business requests belonging to the same transaction is the same; the second target node is the node other than the first target node among multiple candidate nodes.

[0066] In the embodiments of this application, such as Figure 2 As shown, the synchronization request sent by the first target node can be received through the dual-active core module in the second target node. It should be noted that the synchronization request carries the change information of the first business data stored in the first database of the first target node, and the synchronization request is sent to the second target node after the first target node has successfully processed the pending business request and the first business data has changed.

[0067] Step 302: Based on the first change information carried in the synchronization request, perform change processing on the second business data in the second target node. Among them, the first change information is the change information of the first business data stored in the first target node.

[0068] Specifically, after receiving the synchronization request, the second target node can modify the second business data stored in the second database of the second target node according to the first change information. Since the data stored in the databases of each node is the same, the dual-active core module in the second target node only needs to make the same changes to the corresponding parts of the second business data according to the first change information.

[0069] It should be noted that the first and second business data are the same regardless of whether the change was made or not.

[0070] The request processing method provided in the embodiments of this application ensures that the first target node corresponding to the multiple business requests belonging to the same transaction is the same because the request information of multiple business requests belonging to the same transaction is identical. In other words, the nodes to which the multiple business requests belonging to the same transaction are assigned are consistent, thus guaranteeing that the multiple business requests belonging to the same transaction will be assigned to the same node (i.e., the first target node). In this way, the first target node can process the multiple business requests sequentially according to the order in which the business requests occurred, thereby ensuring the order of the transaction. This solves the problem in related technologies where multiple business requests belonging to the same transaction are assigned to different data centers, resulting in an inconsistency between the processing order and the order in which the business requests occurred, and thus causing data inconsistency between data centers. It also avoids the problem of data chaos between data centers. At the same time, after receiving the synchronization request from the first target node, the second target node can promptly perform the same change processing on the data stored in its own database, thereby keeping the data between the nodes synchronized.

[0071] Based on the foregoing embodiments, embodiments of this application provide a request processing method, which can be applied to a distributed system, see below. Figure 6 As shown, the method may include the following steps: Step 401: Edge nodes obtain pending business requests.

[0072] In this embodiment, the pending service request may refer to one sent by a terminal device. The terminal device may include a server, a personal computer, or a mobile phone, etc.

[0073] Step 402: Based on the request information carried in the pending business request and the identifier of each candidate node in the distributed system, the edge node determines the first target node corresponding to the pending business request from multiple candidate nodes.

[0074] The request information represents the source and type of the business corresponding to the business request to be processed; the request information of multiple business requests belonging to the same transaction is the same.

[0075] In this embodiment, the number of all candidate nodes in the distributed system, i.e., the number of nodes in the geographically dispersed active-active architecture, can be obtained. Then, based on the request information, the number, and the identifier of each candidate node, the first target node corresponding to the business request to be processed can be determined from the multiple candidate nodes. The identifier of a candidate node can refer to its number.

[0076] It should be noted that the entire process of determining the first target node can be executed by the dual-active core model in the first target node.

[0077] In one feasible way, such as Figure 2 As shown, if there is only one primary node and one backup node in the off-site active-active architecture, the probability of the pending business request being assigned to the primary node or the backup node is 50%.

[0078] In the embodiments of this application, step 402 can be implemented by steps 402a to 402c.

[0079] Step 402a: The edge node performs a hash operation on the request information to obtain a hash value.

[0080] In this embodiment of the application, the edge node can concatenate multiple pieces of information in the request information (including the domain name information of the platform that initiated the business, the first identifier of the business type and the second identifier of the live stream) into a string. Then, the string can be used as the input of the hash algorithm to obtain a hash value.

[0081] Step 402b: The edge node determines the target value based on the hash value and the number of multiple candidate nodes.

[0082] In this embodiment of the application, the number of multiple candidate nodes can be used as the modulus of the modulo operation. Then, the hash value can be divided by the number of multiple candidate nodes, that is, the modulo operation is performed on the hash value and the number to obtain a remainder, which is the target value.

[0083] It should be noted that each pending business request corresponds to a target value.

[0084] In this embodiment of the application, if the number of candidate nodes is 2, that is, there are two candidate nodes, then the target value can be 0 or 1. If the number of candidate nodes is 3, that is, there are 3 candidate nodes, then the target value can be 0, 1 or 2.

[0085] Step 402c: Based on the target value and the number of each candidate node, the edge node determines the first target node from multiple candidate nodes.

[0086] The identifier includes a number.

[0087] In this embodiment, the candidate node's number can be used to uniquely identify the candidate node; that is, each candidate node has a unique number, and different candidate nodes have different numbers. In one possible implementation, each candidate node can be numbered starting from 0 and in ascending order. That is, the first candidate node can be numbered 0, the second candidate node can be numbered 1, and so on, until the Nth candidate node is numbered N-1. Here, N is a positive integer greater than 1.

[0088] In this embodiment of the application, step 402c can be implemented by steps 402c1 to 402c2.

[0089] Step 402c1: The edge nodes perform matching processing on the target value and the number of each candidate node, and determine the target number that matches the target value from multiple numbers based on the matching results.

[0090] In this embodiment of the application, the target value can be matched with the number of each candidate node. If the matching result indicates that the target value matches the number of a candidate node, then the number of the candidate node can be determined as the target number that matches the target value.

[0091] It should be noted that the target value is actually the same as the target number.

[0092] Step 402c2: Determine the candidate node corresponding to the target number as the first target node.

[0093] In this embodiment, the candidate node corresponding to the target number can be directly determined as the first target node corresponding to the service request to be processed. It should be noted that one service request to be processed corresponds to only one first target node, that is, one service request to be processed will only be assigned to one first target node.

[0094] In this embodiment, since the request information of multiple pending business requests belonging to the same transaction is the same, the hash value obtained after hash operation will necessarily be the same. Since the number of multiple candidate nodes is constant, the target value corresponding to each pending business request is also the same, that is, the first target node determined in the end is also the same. In this way, multiple pending business requests belonging to the same transaction will be assigned to the same node (i.e., the first target node). That is, by "performing a hash modulo operation based on the request information and the number of multiple candidate nodes", it can be ensured that a group of business requests "belonging to the same transaction" are assigned to the same data center for processing according to the order in which they occur.

[0095] In this embodiment of the application, the edge node will perform a hash modulo operation based on the "request information" and the "number of candidate nodes" to determine whether to send the pending business request to the primary node or the backup node. In this way, business requests belonging to the same "transaction" will be sent to the same node in the same order as their occurrence.

[0096] Step 403: The edge node sends the pending service request to the first target node.

[0097] In this embodiment of the application, if there are multiple pending business requests belonging to the same transaction, these multiple pending business data will be sent to the first target node in sequence by the dual-active core module according to the order in which they occur.

[0098] In one feasible way, such as Figure 2 As shown, when the first target node is the master node, the request allocation process can be represented by a solid line, while when the first target node is the backup node, the request allocation process can be represented by a dashed line.

[0099] It should be noted that if this application is applied to a live streaming distribution business scenario, there are usually multiple edge nodes, which are responsible for distributing multiple live streams.

[0100] Step 404: The first target node receives the pending service request sent by the edge node.

[0101] The first target node is determined by the edge node based on the request information carried in the business request to be processed and the identifier of each candidate node; the request information represents the source and type of the business corresponding to the business request to be processed; business requests belonging to the same transaction have the same request information.

[0102] In this embodiment of the application, if there are multiple pending business requests belonging to the same transaction, the first target node will also receive these multiple pending business requests in the order they were sent.

[0103] Step 405: The first target node processes the business request to be processed.

[0104] In this embodiment, the active-active core module in the first target node can process the pending business request directly according to the preset business logic after receiving it.

[0105] It should be noted that if the type of the business request to be processed is a change type, then the first business data in the first database needs to be changed during the process of processing the business request.

[0106] In one feasible approach, if this application is applied to a live streaming distribution business scenario, the first business data can be data with a high modification frequency in the first database. Specifically, the first business data can refer to streaming information, and such as... Figure 2 As shown, stream information can include a stream table and a stream history table. The stream table records information about ongoing streams (i.e., live streams), while the stream history table records historical information about completed streams.

[0107] It should be noted that the stream table can record metadata representing the status and attributes of an ongoing stream, specifically the stream identifier (i.e., the second identifier), the business type identifier (i.e., the first identifier), the domain name information of the business platform, the stream status, the live stream start time, the live stream end time, the number of viewers, etc.; the stream history table can record metadata representing the status and attributes of a completed stream (i.e., a historical stream), specifically the historical stream identifier, the historical business type identifier, the historical domain name information of the historical business platform, the historical stream status, the historical live stream start time corresponding to the historical stream, the historical live stream end time, the historical number of viewers, etc.

[0108] Step 406: If the pending business request is successfully processed and the first business data stored in the first target node has changed, the first target node sends a synchronization request carrying the first change information of the first business data to the second target node, so that the second target node can perform change processing on the second business data stored in the second target node based on the first change information.

[0109] The second target node is a node other than the first target node among multiple candidate nodes.

[0110] In this embodiment of the application, after the first target node successfully processes the pending business request and determines that the first business data stored in the first database has changed, it can directly remotely call the target interface on the first target node to send a synchronization request to the second target node, so that the second business data stored in the second target node changes with the change of the first business data, that is, to ensure that the first business data and the second business data are synchronized, that is, the same.

[0111] In this embodiment of the application, the step 406, "the first target node sends a synchronization request carrying the first change information of the first service data to the second target node", can be implemented through step 406a.

[0112] Step 406a: The first target node calls the target interface of the second target node and sends a synchronization request to the second target node.

[0113] In this embodiment, the target interface can be an Application Programming Interface (API) set on the second target node for receiving data synchronization requests. It should be noted that this API is pre-configured.

[0114] Specifically, synchronization requests can be sent to the second target node through its target interface (i.e., API interface). It should be noted that each node in a geographically distributed active-active architecture has a pre-configured target interface, and multiple nodes use these API interfaces to synchronize business data.

[0115] In this embodiment, the method of achieving data synchronization by remotely calling the API interface of the second target node is essentially a "relay" approach to achieve the goal of "dual writing to the database" of business data, without relying on the middleware module in related technologies. That is, each node is only responsible for the data stored in its own database and does not care whether the data of other nodes has been successfully written / deleted / modified.

[0116] In other embodiments of this application, since there may be cases where changes to the first business data stored in the first database fail, in order to ensure the accuracy of the first business data, the first business data can be corrected in the following manner.

[0117] A1. The first target node obtains the baseline business data from the target database.

[0118] In this embodiment, the target database can be used to store all business data of the entire business system, and it is typically located in a separate device. Specifically, the baseline business data can be obtained from the target database through the dual-active auxiliary error correction module in the first target node.

[0119] A2. The first target node performs error correction on the first business data based on the baseline business data by adopting the target data error correction algorithm according to the target error correction cycle.

[0120] In this embodiment, the target error correction period can be an empirical value set based on the number of business requests; essentially, it is a numerical value. In one possible implementation, the target error correction period can be set between 1 minute and 10 minutes. It should be noted that the target error correction period is not static. If the number of business requests surges within a certain period, the target error correction period can be shortened accordingly to ensure the accuracy of the first business data stored in the first database.

[0121] In the embodiments of this application, the target data error correction algorithm may refer to an existing data error correction algorithm, the specific principle of which will not be elaborated here.

[0122] In this embodiment of the application, the target data error correction algorithm can be used to perform error correction processing on the first business data stored in the first database, based on the baseline business data, according to the preset target error correction cycle.

[0123] In other embodiments of this application, if the first target node is the master node of the distributed system, the first target node can monitor the first business configuration data in the first database in real time. If the configuration data changes, it needs to synchronize the data with the second target node in the following way.

[0124] B1. If the first target node is the master node of the distributed system, and the first business configuration data stored in the first target node has changed, the first target node uses one-way synchronization technology to change the second business configuration data stored in the second target node.

[0125] In this embodiment, the first service configuration data may refer to data with a low modification frequency stored in the first database of the first target node. For example, Figure 2 As shown, the first service configuration data may include certificate data table, authentication data table, and domain name data table, etc.

[0126] It's important to note that typically only the business configuration data stored on the primary node (if the first target node is the primary node, then this business configuration data is the first business configuration data) can be rewritten. The business configuration data stored on the backup node cannot be directly rewritten; only the primary node is allowed to perform data synchronization and read operations. Furthermore, in emergency situations (e.g., a primary node failure requiring a failover), the administrator can manually interrupt the data synchronization operation and rewrite the backend logic to allow the business configuration data stored on the backup node to be directly rewritten.

[0127] In this embodiment, if the first target node is the master node and it determines that the first service configuration data stored in its first database has changed, then one-way synchronization technology can be directly used to synchronize the second service configuration data stored in the second database of the backup node (i.e., the second target node), so that the service configuration data stored in the master node and the backup node are consistent. The method of using one-way synchronization technology for data synchronization between nodes is prior art and will not be elaborated here.

[0128] It should be noted that business configuration data can only be synchronized unidirectionally from the primary node to the backup data center, and the business configuration data in the backup node cannot be directly rewritten.

[0129] In one feasible way, such as Figure 2 As shown, business configuration data can be modified through the configuration management / auxiliary service module.

[0130] In this embodiment, for frequently modified business data in a node, a dual-active core module can be used to "dual-write" the data to the databases of both nodes. A dual-active auxiliary error correction module is then used to compare and correct the written data in both nodes. For less frequently modified business configuration data in a node, a one-way data synchronization is implemented from the primary node to the backup node. This one-way data synchronization technology is mature and stable, ensuring the consistency of the business configuration data stored and referenced by both nodes. This method of classifying and processing data effectively saves traffic and time associated with cross-node data synchronization, while also effectively ensuring data consistency between the two data centers (i.e., the two nodes).

[0131] Step 407: The second target node receives the synchronization request sent by the first target node.

[0132] The first target node is determined by the edge node based on the request information carried in the business request to be processed and the identifier of each candidate node; the request information represents the source and type of the business corresponding to the business request to be processed; the request information of business requests belonging to the same transaction is the same; the second target node is the node other than the first target node among multiple candidate nodes.

[0133] In this embodiment of the application, the second target node can receive the synchronization request sent by the first target node through its own pre-configured API interface (i.e., the target interface).

[0134] Step 408: The second target node performs change processing on the second business data in the second target node based on the first change information of the first business data carried in the synchronization request.

[0135] The first business data is the business data stored in the first target node.

[0136] In this embodiment of the application, since the business data stored in the first target node and the second target node are the same, after receiving the first change information of the first business data sent by the first target node, the second target node can directly determine the changed part of the first business data based on the first change information, and make the same modification to the corresponding part in its own second database accordingly, thereby ensuring that the modified business data in the second database is completely consistent with the modified business data in the first database.

[0137] It should be noted that all data in all nodes of the geographically distributed active-active architecture is completely consistent. That is, all data (not only business data, but also business configuration data) in the first target node and the second target node are completely consistent. In other words, the first business data is completely consistent with the second business data, and the first business configuration data is also completely consistent with the second business configuration data.

[0138] In other embodiments of this application, since there may be cases where changes to the second business data stored in the second database fail, in order to ensure the accuracy of the second business data, the second business data can be corrected in the following manner.

[0139] C1. The second target node obtains baseline business data from the target database.

[0140] In this embodiment of the application, the baseline service data obtained by the second target node is the same as the baseline service data obtained by the first target node.

[0141] C2. The second target node performs error correction on the first business data based on the baseline business data by adopting the target data error correction algorithm according to the target error correction cycle.

[0142] In this embodiment, the target error correction period can be an empirical value set based on the number of business requests; it is essentially a numerical value. It should be noted that the target error correction periods for the first target node and the second target node are the same. However, if the target error correction period changes, it is equivalent to a change in the data error correction periods for both the first and second target nodes. For example, the data error correction may change from being performed once every 3 minutes to once every 5 minutes.

[0143] In one feasible approach, the target error correction cycle can be set between 1 minute and 10 minutes.

[0144] In the embodiments of this application, the target data error correction algorithm may refer to an existing data error correction algorithm, the specific principle of which will not be elaborated here.

[0145] In this embodiment of the application, the target data error correction algorithm can be used to perform error correction processing on the second business data stored in the second database, based on the baseline business data, according to the preset target error correction cycle.

[0146] It should be noted that since the first target node and the second target node have the same target error correction cycle, it is equivalent to these nodes performing synchronous error correction.

[0147] In this embodiment, by deploying a "dual-write auxiliary error correction module" in each of the two data centers (i.e., nodes), the data in each data center can be periodically compared and corrected. This avoids the problems of easy interruption and instability of the "two-way database synchronization" technology in related technologies, and also avoids the relatively complex fault tolerance processing logic of the cross-node database writing method. At the same time, by using the "dual-write auxiliary error correction module" deployed independently on the primary and backup nodes to periodically execute the "data comparison and error correction" task to correct the data in the databases of the primary and backup nodes respectively, it can effectively ensure that the data in the databases of the two data centers remains consistent, and ultimately achieve the data consistency goal of the primary and backup nodes.

[0148] In other embodiments of this application, if the first target node is the master node of the distributed system, the first target node can monitor the first business configuration data in the first database in real time. If the configuration data changes, it needs to synchronize the data with the second target node in the following way.

[0149] D1. If the second target node is the master node of the distributed system, and the second service configuration data stored in the second target node has changed, the second target node uses one-way synchronization technology to change the first service configuration data stored in the first target node.

[0150] In this embodiment of the application, if the second target node is the master node, then the first target node is the backup node among the backup nodes. At this time, if the second target node determines that the second service configuration data stored in its own second target database has changed, it can also directly use one-way synchronization technology to change the first service configuration data stored in the first database of the first target node.

[0151] It should be noted that the first business configuration data stored in the first database is exactly the same as the second business configuration data stored in the second database, and the two must remain completely consistent after one-way synchronization.

[0152] In the embodiments of this application, such as Figure 2 As shown, the configuration management / auxiliary service module in the second target node can be used to modify the configuration data of the second business.

[0153] The request processing method provided in this application embodiment ensures that the first target node corresponding to the multiple business requests belonging to the same transaction is the same because the request information of multiple business requests belonging to the same transaction is identical. In other words, the nodes to which the multiple business requests belonging to the same transaction are assigned are consistent, thus guaranteeing that the multiple business requests belonging to the same transaction will be assigned to the same node (i.e., the first target node). In this way, the first target node can process the multiple business requests sequentially according to the order in which the business requests occur, thereby ensuring the order of transactions. This solves the problem in related technologies where multiple business requests belonging to the same transaction are assigned to different data centers, resulting in an inconsistency between the processing order and the order in which the business requests occur, and thus causing data inconsistency between data centers. At the same time, it can avoid the problem of data chaos in each data center.

[0154] Based on the foregoing embodiments, embodiments of this application provide a first request processing apparatus, which can be applied to... Figure 1 In the request processing method provided in the corresponding embodiment, refer to Figure 7 As shown, the first request processing device 5 may include: an acquisition unit 51, a first determination unit 52, and a first sending unit 53, wherein: Acquisition unit 51 is used to acquire pending business requests; The first determining unit 52 is used to determine the first target node corresponding to the business request to be processed from multiple candidate nodes based on the request information carried in the business request to be processed and the identifier of each candidate node in the distributed system; wherein, the request information represents the source and type of the business corresponding to the business request to be processed; the request information of multiple business requests belonging to the same transaction is the same. The first sending unit 53 is used to send the pending service request to the first target node so that the first target node can process the pending service request.

[0155] In other embodiments of this application, the first determining unit 52 is further configured to perform the following steps: Perform a hash operation on the request information to obtain a hash value; The target value is determined based on the hash value and the number of candidate nodes; Based on the target value and the number of each candidate node, the first target node is determined from multiple candidate nodes; wherein, the identifier includes the number.

[0156] It should be noted that the specific implementation process of the steps performed by each unit in the embodiments of this application can be referred to Figure 1 The implementation process of the request processing method provided in the corresponding embodiment will not be described in detail here.

[0157] The first request processing device provided in this application embodiment ensures that the first target node corresponding to the multiple business requests belonging to the same transaction is the same because the request information of multiple business requests belonging to the same transaction is identical. In other words, the nodes to which the multiple business requests belonging to the same transaction are assigned are consistent, thus ensuring that the multiple business requests belonging to the same transaction will be assigned to the same node (i.e., the first target node). In this way, the first target node can process the multiple business requests sequentially according to the order in which the business requests occur, thereby ensuring the order of transactions. This solves the problem in related technologies where multiple business requests belonging to the same transaction are assigned to different data centers, resulting in an inconsistency between the processing order and the order in which the business requests occur, and thus causing data inconsistency between data centers. At the same time, it can avoid the problem of data chaos in each data center.

[0158] Based on the foregoing embodiments, embodiments of this application provide a second request processing apparatus, which can be applied to... Figure 4 In the request processing method provided in the corresponding embodiment, refer to Figure 8 As shown, the second request processing device 6 may include: a first receiving unit 61, a first processing unit 62, and a second sending unit 63, wherein: The first receiving unit 61 is used to receive pending service requests sent by edge nodes; wherein, the first target node is determined by the edge node based on the request information carried in the pending service request and the identifier of each candidate node; the request information represents the source and type of the service corresponding to the pending service request; the request information of multiple service requests belonging to the same transaction is the same. The first processing unit 62 is used to process the business requests to be processed.

[0159] The second sending unit 63 is configured to send a synchronization request carrying first change information of first service data in the first target node to the second target node if the pending service request is successfully processed and the pending service request is a data change request, so that the second target node can perform change processing on the second service data in the second target node based on the first change information; wherein, the second target node is a node other than the first target node among a plurality of candidate nodes.

[0160] In other embodiments of this application, the second sending unit 63 is further configured to perform the following steps: Call the target interface of the second target node and send a synchronization request to the second target node.

[0161] In other embodiments of this application, the first processing unit 62 is further configured to perform the following steps: Retrieve baseline business data from the target database; According to the target error correction cycle, the target data error correction algorithm is adopted to perform error correction processing on the first business data based on the benchmark business data.

[0162] In other embodiments of this application, the first processing unit 62 is further configured to perform the following steps: If the first target node is the master node of the distributed system, and the first business configuration data stored in the first target node has changed, the one-way synchronization technology is used to change the second business configuration data stored in the second target node.

[0163] The second request processing device provided in the embodiments of this application ensures that the first target node corresponding to the multiple business requests belonging to the same transaction is the same because the request information of multiple business requests belonging to the same transaction is identical. In other words, the nodes to which the multiple business requests belonging to the same transaction are assigned are consistent, thus ensuring that the multiple business requests belonging to the same transaction will be assigned to the same node (i.e., the first target node). In this way, the first target node can process the multiple business requests sequentially according to the order in which the business requests occur, thereby ensuring the order of transactions. This solves the problem in related technologies where multiple business requests belonging to the same transaction are assigned to different data centers, resulting in an inconsistency between the processing order and the order in which the business requests occur, and thus causing data inconsistency between data centers. At the same time, it can avoid the problem of data chaos in each data center. In addition, when the data in the first database changes, a synchronization request carrying the first change information can be sent to the second target node in a timely manner to achieve data synchronization between nodes.

[0164] Based on the foregoing embodiments, embodiments of this application provide a third request processing apparatus, which can be applied to... Figure 5 In the request processing method provided in the corresponding embodiment, refer to Figure 9 As shown, the third request processing device 7 may include: a second receiving unit 71 and a second processing unit 72, wherein: The second receiving unit 71 is used to receive a synchronization request sent by the first target node; wherein, the first target node is determined by the edge node based on the request information carried in the service request to be processed and the identifier of each candidate node; the request information represents the source and type of the service corresponding to the service request to be processed; the request information of multiple service requests belonging to the same transaction is the same; the second target node is a node other than the first target node among multiple candidate nodes. The second processing unit 72 is used to perform change processing on the second business data in the second target node based on the first change information carried in the synchronization request; wherein, the first change information is the change information of the first business data stored in the first target node.

[0165] In other embodiments of this application, the second processing unit 72 is further configured to perform the following steps: Retrieve baseline business data from the target database; According to the target error correction cycle, the target data error correction algorithm is used to perform error correction processing on the second business data based on the baseline business data.

[0166] In other embodiments of this application, the second processing unit 72 is further configured to perform the following steps: If the second target node is the master node of the distributed system, and the second business configuration data stored in the second target node has changed, the one-way synchronization technology is used to process the change of the first business configuration data stored in the first target node.

[0167] The third request processing device provided in the embodiments of this application ensures that the first target node corresponding to the multiple business requests belonging to the same transaction is the same because the request information of multiple business requests belonging to the same transaction is identical. In other words, the nodes to which the multiple business requests belonging to the same transaction are assigned are consistent, thus ensuring that the multiple business requests belonging to the same transaction will be assigned to the same node (i.e., the first target node). In this way, the first target node can process the multiple business requests sequentially according to the order in which the business requests occur, thereby ensuring the order of transactions. This solves the problem in related technologies where multiple business requests belonging to the same transaction are assigned to different data centers, resulting in an inconsistency between the processing order and the order in which the business requests occur, and thus causing data inconsistency between data centers. At the same time, it can avoid the problem of data chaos between data centers. In addition, after receiving the synchronization request from the first target node, the second target node can promptly perform the same change processing on the data stored in its own database, thereby keeping the data between the nodes synchronized.

[0168] Based on the foregoing embodiments, embodiments of this application provide a request processing device, which includes a processor, a memory, and a communication bus. The request processing device may include an edge node 8, the processor may include a first processor 81, the memory may include a first memory 82, and the communication bus may include a first communication bus 83. The edge node 8 can be applied to... Figure 1 In the request processing method provided in the corresponding embodiment, refer to Figure 10 As shown, where: The first communication bus 83 is used to realize the communication connection between the first processor 81 and the first memory 82; The first processor 81 is used to execute the request handling program in the first memory 82 to perform the following steps: Get pending business requests; Based on the request information carried in the pending business request and the identifier of each candidate node in the distributed system, the first target node corresponding to the pending business request is determined from multiple candidate nodes; wherein, the request information represents the source and type of the business corresponding to the pending business request; the request information of multiple business requests belonging to the same transaction is the same. Send the pending business request to the first target node so that the first target node can process the pending business request.

[0169] In other embodiments of this application, the first processor 81 is used to execute a request handler in the first memory 82 to perform the following steps: Perform a hash operation on the request information to obtain a hash value; The target value is determined based on the hash value and the number of candidate nodes; Based on the target value and the number of each candidate node, the first target node is determined from multiple candidate nodes; wherein, the identifier includes the number.

[0170] It should be noted that a detailed description of the steps performed by the first processor can be found in [reference needed]. Figure 1 The request processing methods provided in the corresponding embodiments will not be described in detail here.

[0171] The edge nodes provided in the embodiments of this application ensure that the first target nodes corresponding to the multiple business requests belonging to the same transaction are the same because the request information of the multiple business requests belonging to the same transaction is identical. In other words, the nodes to which the multiple business requests belonging to the same transaction are assigned are consistent, which guarantees that the multiple business requests belonging to the same transaction will be assigned to the same node (i.e., the first target node). In this way, the first target node can process the multiple business requests in the order in which the business requests occur, thereby ensuring the order of transactions. This solves the problem in related technologies where multiple business requests belonging to the same transaction are assigned to different data centers, resulting in an inconsistency between the processing order and the order of occurrence of the business requests, and thus causing data inconsistency between data centers. At the same time, it can avoid the problem of data chaos between data centers.

[0172] Based on the foregoing embodiments, embodiments of this application provide a request processing device, which includes a processor, a memory, and a communication bus. The request processing device may include a first target node 9, the processor may include a second processor 91, the memory may include a second memory 92, and the communication bus may include a second communication bus 93. The first target node 9 can be applied to... Figure 4 In the request processing method provided in the corresponding embodiment, refer to Figure 11 As shown, where: The second communication bus 93 is used to realize the communication connection between the second processor 91 and the second memory 92; The second processor 91 is used to execute the request handling program in the second memory 92 to perform the following steps: Receive pending service requests sent by edge nodes; wherein, the first target node is determined by the edge node based on the request information carried in the pending service request and the identifier of each candidate node; the request information represents the source and type of the service corresponding to the pending service request; the request information of service requests belonging to the same transaction is the same; Process the pending business requests; If the pending business request is successfully processed and the first business data stored in the first target node has changed, a synchronization request carrying the first change information of the first business data is sent to the second target node so that the second target node can perform change processing on the second business data stored in the second target node based on the first change information; wherein, the second target node is a node other than the first target node among multiple candidate nodes.

[0173] In other embodiments of this application, the second processor 91 is used to execute a request handler in the second memory 92 to perform the following steps: Call the target interface of the second target node and send a synchronization request to the second target node.

[0174] In other embodiments of this application, the second processor 91 is used to execute a request handler in the second memory 92 to perform the following steps: Retrieve baseline business data from the target database; According to the target error correction cycle, the target data error correction algorithm is adopted to perform error correction processing on the first business data based on the benchmark business data.

[0175] In other embodiments of this application, the second processor 91 is used to execute a request handler in the second memory 92 to perform the following steps: If the first target node is the master node of the distributed system, and the first business configuration data stored in the first target node has changed, the one-way synchronization technology is used to change the second business configuration data stored in the second target node.

[0176] It should be noted that a detailed description of the steps performed by the second processor can be found in [reference needed]. Figure 4 The request processing methods provided in the corresponding embodiments will not be described in detail here.

[0177] The first target node provided in the embodiments of this application ensures that the first target node corresponding to the multiple business requests belonging to the same transaction is the same because the request information of the multiple business requests belonging to the same transaction is identical. In other words, the nodes to which the multiple business requests belonging to the same transaction are assigned are consistent, which guarantees that the multiple business requests belonging to the same transaction will be assigned to the same node (i.e., the first target node). In this way, the first target node can process the multiple business requests in the order in which the business requests occur, thereby ensuring the order of the transaction. This solves the problem in related technologies where multiple business requests belonging to the same transaction are assigned to different data centers, resulting in a discrepancy between the processing order and the order in which the business requests occur, and thus causing data inconsistency between data centers. At the same time, it can avoid the problem of data chaos in each data center. In addition, when the data in the first database changes, a synchronization request carrying the first change information can be sent to the second target node in a timely manner to achieve data synchronization between nodes.

[0178] Based on the foregoing embodiments, embodiments of this application provide a request processing device, which includes a processor, a memory, and a communication bus. The request processing device may include a neighbor node 10, the processor may include a third processor 101, the memory may include a third memory 102, and the communication bus may include a third communication bus 103. The neighbor node 10 can be applied to… Figure 5 In the request processing method provided in the corresponding embodiment, refer to Figure 12 As shown, where: The third communication bus 103 is used to realize the communication connection between the third processor 101 and the third memory 102; The third processor 101 is used to execute the request handler in the third memory 102 to perform the following steps: Receive a synchronization request sent by the first target node; wherein, the first target node is determined by the edge node based on the request information carried in the service request to be processed and the identifier of each candidate node; the request information represents the source and type of the service corresponding to the service request to be processed; the request information of service requests belonging to the same transaction is the same; the second target node is a node other than the first target node among multiple candidate nodes; Based on the first change information carried in the synchronization request, the second business data in the second target node is modified; wherein, the first change information is the change information of the first business data stored in the first target node.

[0179] In other embodiments of this application, the third processor 101 is used to execute a request handler in the third memory 102, and may also implement the following steps: Retrieve baseline business data from the target database; According to the target error correction cycle, the target data error correction algorithm is used to perform error correction processing on the second business data based on the baseline business data.

[0180] In other embodiments of this application, the third processor 101 is used to execute a request handler in the third memory 102, and may also implement the following steps: If the second target node is the master node of the distributed system, and the second business configuration data stored in the second target node has changed, the one-way synchronization technology is used to process the change of the first business configuration data stored in the first target node.

[0181] It should be noted that a detailed explanation of the steps performed by the third processor can be found in [reference needed]. Figure 5 The request processing methods provided in the corresponding embodiments will not be described in detail here.

[0182] The neighboring nodes provided in the embodiments of this application ensure that the first target node corresponding to the multiple business requests belonging to the same transaction is the same, since the request information of multiple business requests belonging to the same transaction is identical. In other words, the nodes to which multiple business requests belonging to the same transaction are assigned are consistent, thus guaranteeing that multiple business requests belonging to the same transaction will be assigned to the same node (i.e., the first target node). In this way, the first target node can process multiple business requests sequentially according to the order in which the business requests occur, thereby ensuring the order of transactions. This solves the problem in related technologies where multiple business requests belonging to the same transaction are assigned to different data centers, resulting in an inconsistency between the processing order and the order in which the business requests occur, and thus causing data inconsistency between data centers. It also avoids the problem of data chaos between data centers. At the same time, after receiving the synchronization request from the first target node, the second target node can promptly perform the same change processing on the data stored in its own database, thereby keeping the data between the nodes synchronized.

[0183] Based on the foregoing embodiments, this application provides a storage medium that is a computer-readable storage medium, and the computer-readable storage medium stores one or more programs that can be executed by one or more processors to achieve... Figure 1 ,as well as Figures 4 to 6 The steps of the request processing method provided in the corresponding embodiment.

[0184] Based on the foregoing embodiments, this application provides a computer program product, including a computer program that can be executed by a first processor 81, a second processor 91, and a third processor 101 to perform... Figure 1 ,as well as Figures 4 to 6The steps of the request processing method provided in the corresponding embodiment.

[0185] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A request processing method, characterized in that, The method is applied to edge nodes in a distributed system, and the method includes: Get pending business requests; Based on the request information carried in the pending business request and the identifier of each candidate node in the distributed system, the first target node corresponding to the pending business request is determined from multiple candidate nodes; wherein, the request information represents the source and type of the business corresponding to the pending business request; the request information of multiple business requests belonging to the same transaction is the same; The pending service request is sent to the first target node so that the first target node can process the pending service request.

2. The method according to claim 1, characterized in that, The step of determining the first target node corresponding to the service request to be processed from multiple candidate nodes based on the request information carried in the service request to be processed and the identifier of each candidate node in the distributed system includes: Perform a hash operation on the request information to obtain a hash value; The target value is determined based on the hash value and the number of candidate nodes. Based on the target value and the number of each candidate node, the first target node is determined from the plurality of candidate nodes; wherein the identifier includes the number.

3. A request processing method, characterized in that, The method is applied to the first target node in a distributed system, and the method includes: Receive pending service requests sent by edge nodes; wherein, the first target node is determined by the edge node based on the request information carried in the pending service request and the identifier of each candidate node; the request information characterizes the source and type of the service corresponding to the pending service request; multiple service requests belonging to the same transaction have the same request information; Process the pending service requests; If the pending service request is successfully processed and the first service data stored in the first target node has changed, a synchronization request carrying the first change information of the first service data is sent to the second target node, so that the second target node can perform change processing on the second service data stored in the second target node based on the first change information; wherein, the second target node is a node other than the first target node among a plurality of candidate nodes.

4. The method according to claim 3, characterized in that, Sending a synchronization request carrying change information of the first service data in the first target node to the second target node includes: Invoke the target interface of the second target node and send the synchronization request to the second target node.

5. The method according to claim 3, characterized in that, The method further includes: Retrieve baseline business data from the target database; According to the target error correction cycle, the target data error correction algorithm is used to perform error correction processing on the first business data based on the benchmark business data; Accordingly, the method further includes: If the first target node is the master node of the distributed system, and the first service configuration data stored in the first target node has changed, the second service configuration data stored in the second target node is modified using one-way synchronization technology.

6. A request processing method, characterized in that, The method is applied to the second target node in a distributed system, and the method includes: Receive a synchronization request sent by a first target node; wherein, the first target node is determined by the edge node based on the request information carried in the pending service request and the identifier of each candidate node; the request information represents the source and type of the service corresponding to the pending service request; the request information of multiple service requests belonging to the same transaction is the same; the second target node is a node other than the first target node among multiple candidate nodes; Based on the first change information carried in the synchronization request, the second business data in the second target node is modified; wherein, the first change information is the change information of the first business data stored in the first target node.

7. The method according to claim 6, characterized in that, The method further includes: Retrieve baseline business data from the target database; According to the target error correction cycle, the target data error correction algorithm is used to perform error correction processing on the second business data based on the benchmark business data; Accordingly, the method further includes: If the second target node is the master node of the distributed system, and the second service configuration data stored in the second target node has changed, the first service configuration data stored in the first target node is modified using one-way synchronization technology.

8. A request processing device, characterized in that, The device includes: a processor, a memory, and a communication bus; The communication bus is used to realize the communication connection between the processor and the memory; The processor is configured to execute a request handler in memory to implement the steps of the request handling method as described in any one of claims 1 to 2, 3 to 5, or 6 to 7.

9. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the steps of the request processing method as described in any one of claims 1 to 2, 3 to 5, or 6 to 7.

10. A computer program product, the computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the request processing method according to any one of claims 1 to 2, 3 to 5, or 6 to 7.

Images