WO2023207082A1

WO2023207082A1 - Load balance method and apparatus, and electronic device

Info

Publication number: WO2023207082A1
Application number: PCT/CN2022/135418
Authority: WO
Inventors: 林鹏; 邓福喜
Original assignee: 蚂蚁区块链科技(上海)有限公司
Priority date: 2022-04-29
Filing date: 2022-11-30
Publication date: 2023-11-02
Also published as: CN114884962A; CN114884962B

Abstract

A load balance method and apparatus, and an electronic device. The method comprises: receiving a transaction request submitted by a user; in response to the received transaction request submitted by the user, determining the type of the transaction request; and, if the transaction request is a transaction request related to a blockchain transaction, allocating, on the basis of a load balance policy corresponding to a consensus algorithm supported by a blockchain, the transaction request a target node device amongst node devices in the blockchain participating in a consensus, and sending to the allocated target node device the transaction request to be processed, consensus algorithms of different types supported by the blockchain respectively corresponding to different load balance policies.

Description

Load balancing method and device and electronic equipment

This application claims priority to the Chinese patent application filed with the China Patent Office on April 29, 2022, with application number 202210473991. in this application.

Technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a load balancing method and device and electronic equipment.

Background technique

Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" and jointly maintain a complete distributed database. Because blockchain technology is decentralized, open and transparent, each computing device can participate in database records, and data can be synchronized quickly between computing devices, blockchain technology has been widely used in many fields. Apply.

Contents of the invention

The embodiments of this specification provide a method, device and electronic equipment for improving information security.

According to a first aspect of the embodiments of this specification, a load balancing method is provided, applied to an access program corresponding to a blockchain, and the method includes:

Receive transaction requests submitted by users;

In response to receiving a transaction request submitted by the user, determining the type of the transaction request;

If the transaction request is a transaction request related to a blockchain transaction, based on the load balancing strategy corresponding to the consensus algorithm supported by the blockchain, the node device participating in the consensus in the blockchain provides the transaction with Request allocation of target node equipment, and send the transaction request to the allocated target node equipment for processing; wherein, different types of consensus algorithms supported by the blockchain respectively correspond to different load balancing strategies.

Optionally, the method also includes:

If the transaction request is a transaction request that is not related to the blockchain transaction, based on the preset load balancing strategy, allocate the node device with the optimal load to the transaction request from the node devices that do not participate in the consensus in the blockchain. , and send the transaction request to the node device for processing.

Optionally, the consensus algorithm supported by the blockchain includes an asynchronous consensus algorithm; the transaction requests related to blockchain transactions include blockchain transactions and query requests for blockchain transactions;

The method of allocating a target node device to the transaction request from the node devices participating in the consensus in the blockchain based on the load balancing strategy corresponding to the consensus algorithm supported by the blockchain includes:

If the transaction request is a blockchain transaction, based on the load balancing strategy corresponding to the asynchronous consensus algorithm, the target of allocating the optimal load to the blockchain transaction from the node devices participating in the consensus in the blockchain Node equipment, and establish a binding relationship between the blockchain transaction and the target node equipment;

If the transaction request is a query request corresponding to a blockchain transaction, based on the load balancing strategy corresponding to the asynchronous consensus algorithm, the binding relationship is queried, and the target node device bound to the blockchain transaction is assigned to the query request.

Optionally, the consensus algorithm supported by the blockchain also includes a synchronous consensus algorithm;

Based on the load balancing strategy corresponding to the synchronous consensus algorithm, the target node device with the optimal load is allocated to the transaction request from the node devices participating in the consensus in the blockchain.

Optionally, the optimally loaded node device includes a randomly designated node device.

Optionally, the synchronous consensus algorithm includes the pbft consensus algorithm; the asynchronous consensus algorithm includes the honeybadger consensus algorithm.

Optionally, the access program includes an SDK program for accessing the blockchain.

Optionally, the SDK program includes an SDK access program installed on the user client;

The reception of transaction requests submitted by users includes:

Obtain the transaction request initiated by the user on the user client.

Optionally, the SDK program includes an SDK access service program corresponding to the user client mounted on the blockchain service platform;

The reception of transaction requests submitted by users includes:

Receive a transaction request submitted by the user client by calling a service interface deployed on the blockchain service platform corresponding to the SDK access service program.

Optionally, the access program maintains a first connection pool based on connections with each node device that participates in consensus in the blockchain; and, based on connections with nodes that do not participate in consensus in the blockchain A second connection pool composed of connections between various node devices;

Allocating a target node device to the transaction request from the node devices participating in the consensus in the blockchain, and sending the transaction request to the assigned target node device for processing, including:

Allocate a target connection to the transaction request from the first connection pool, and send the transaction request to the target node device corresponding to the target connection for processing based on the target connection;

Allocating the node device with the optimal load to the transaction request from the node devices that do not participate in the consensus in the blockchain, and sending the transaction request to the node device for processing includes:

Allocate a target connection to the transaction request from the second connection pool, and send the transaction request to a target node device corresponding to the target connection for processing based on the target connection.

Optionally, the method also includes:

Timing detection determines whether the connections in the first connection pool and the second connection pool are available, and based on the detection results, adds an indication that the connection is available to the connections in the first connection pool and the second connection pool. available tags;

Allocating a target connection for the transaction request from the first connection pool includes:

Allocate available target connections for the transaction request from the connections added with available tags in the first connection pool;

Allocating a target connection for the transaction request from the second connection pool includes:

Allocate available target connections for the transaction request from connections added with available tags in the second connection pool.

Optionally, the timing to determine whether connections in the first connection pool and the second connection pool are available includes:

Regularly sending asynchronous query requests to node devices corresponding to connections in the first connection pool and the second connection pool;

If the response data returned by the node device is received within the preset timestamp range, it is determined that the connection is available;

If the response data returned by the node device is not received within the preset timestamp range, it is determined that the connection is unavailable.

Optionally, the preset timestamp range includes a timestamp range corresponding to a specified block in the blockchain.

According to the second aspect of the embodiment of this specification, a load balancing device is provided, which is applied to the access program corresponding to the blockchain. The device includes:

The receiving unit receives transaction requests submitted by users;

a determining unit that determines the type of the transaction request in response to the received transaction request submitted by the user;

A balancing unit, when the transaction request is a transaction request related to a blockchain transaction, based on the load balancing strategy corresponding to the consensus algorithm supported by the blockchain, from the node devices participating in the consensus in the blockchain Allocate a target node device to the transaction request, and send the transaction request to the assigned target node device for processing; wherein, the different types of consensus algorithms supported by the blockchain respectively correspond to different load balancing strategies. .

Optionally, the balancing unit is also configured to remove node devices that do not participate in the consensus from the blockchain based on a preset load balancing strategy when the transaction request is a transaction request that is not related to a blockchain transaction. Allocate the node device with the optimal load to the transaction request, and send the transaction request to the node device for processing.

The balancing unit is also configured to, when the transaction request is a blockchain transaction, based on the load balancing strategy corresponding to the asynchronous consensus algorithm, from the node devices participating in the consensus in the blockchain, provide the balance for the zone. The block chain transaction allocates the target node device with the optimal load, and establishes a binding relationship between the block chain transaction and the target node device; and, when the transaction request is a query request corresponding to the block chain transaction, based on The load balancing strategy corresponding to the asynchronous consensus algorithm queries the binding relationship, and allocates the target node device bound to the blockchain transaction to the query request.

The balancing unit is also configured to allocate the target node device with the optimal load to the transaction request from the node devices participating in the consensus in the blockchain based on the load balancing strategy corresponding to the synchronous consensus algorithm.

The receiving unit is also used to obtain the transaction request initiated by the user on the user client.

The receiving unit is also configured to receive a transaction request submitted by the user client by calling the service interface deployed on the blockchain service platform and corresponding to the SDK access service program.

The balancing unit allocates a target node device for the transaction request from the node devices participating in the consensus in the blockchain, and sends the transaction request to the assigned target node device for processing, including:

The balancing unit allocates the node device with the optimal load for the transaction request from the node devices in the blockchain that do not participate in the consensus, and sends the transaction request to the node device for processing, including:

Optionally, the device also includes:

A detection unit that periodically detects and determines whether the connections in the first connection pool and the second connection pool are available, and adds the indication to the connections in the first connection pool and the second connection pool based on the detection results. Connect to available tags available;

The balancing unit allocates a target connection for the transaction request from the first connection pool, including:

The balancing unit allocates a target connection for the transaction request from the second connection pool, including:

Optionally, the detection unit is also configured to regularly send an asynchronous query request to the node device corresponding to the connection in the first connection pool and the second connection pool; if the request is received within the preset timestamp range, If the response data returned by the node device is received, it is determined that the connection is available; if the response data returned by the node device is not received within the preset timestamp range, the connection is determined to be unavailable.

According to a third aspect of the embodiments of this specification, an electronic device is provided, including:

processor;

Memory used to store instructions executable by the processor;

Wherein, the processor is configured for any one of the above load balancing methods.

The embodiment of this specification provides a load balancing solution that sets different load balancing strategies for different types of consensus algorithms supported by the blockchain to adapt to the load differences caused by different types of consensus algorithms; in this way, for users The submitted transaction request related to the blockchain transaction can be assigned a target from the node devices participating in the consensus in the blockchain according to the load balancing strategy corresponding to the consensus algorithm for the transaction request. node device for processing. Since the load balancing strategy takes into account the load difference of the consensus algorithm, the allocated target node device is the current optimal node device. Based on the target node device, the transaction request can be quickly responded to, thereby avoiding the problem of slow response caused by excessive load on some node devices. .

Description of drawings

Figure 1 is a flow chart of a load balancing method provided by an exemplary embodiment;

Figure 2 is a system architecture diagram of load balancing provided by an exemplary embodiment;

Figure 3 is a schematic structural diagram of an electronic device provided by an exemplary embodiment;

Figure 4 is a block diagram of a load balancing device provided by an exemplary embodiment.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, methods may include more or fewer steps than described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. describe.

Since blockchain has certain particularities compared to non-blockchain scenarios, existing load balancing algorithms or strategies in non-blockchain scenarios have unsatisfactory load balancing effects and cannot meet the load balancing needs of blockchain. For example, since the blockchain has a consensus mechanism that requires consensus on different transaction types, the blockchain usually supports a variety of different consensus algorithms, and the load results caused by different consensus algorithms are not the same.

Existing load balancing solutions do not consider the load balancing differences of blockchains under different consensus algorithms and still use a unified load balancing solution. This may easily lead to excessive load pressure on local node devices in the blockchain. The local node equipment is in idle state. In this way, it is easy to cause the overall processing efficiency of the blockchain to be low and unable to respond to transaction requests in a timely manner.

To this end, this manual provides a load balancing solution specifically suitable for blockchain scenarios, which can efficiently allocate transaction requests, enable node devices in the blockchain to process transaction requests in a balanced manner, and solve the load of each node device. Problem of imbalance.

Please refer to Figure 1 below, which is a flow chart of a load balancing method provided by an exemplary embodiment. The method can be applied to the access program corresponding to the blockchain; the method can include the following steps:

Step 110: Receive the transaction request submitted by the user;

Step 120: In response to the received transaction request submitted by the user, determine the type of the transaction request;

Step 130: If the transaction request is a transaction request related to a blockchain transaction, based on the load balancing strategy corresponding to the consensus algorithm supported by the blockchain, from the node devices participating in the consensus in the blockchain, The transaction request is assigned to a target node device, and the transaction request is sent to the assigned target node device for processing; wherein, different types of consensus algorithms supported by the blockchain respectively correspond to different load balancing strategies.

The blockchain described in this manual can specifically include any type of blockchain network; in practical applications, any one of public blockchain, private blockchain and consortium blockchain can be used. kind. In addition, there can also be a combination of the above types, such as private chain + alliance chain, alliance chain + public chain, etc.

Among them, the public chain is the most decentralized. Participants who join the public chain (also called node devices in the blockchain) can read data records on the chain, participate in transactions, and compete for the accounting rights of new blocks, etc. Moreover, each node device can freely join or exit the network and perform related operations.

On the contrary, the private chain has the writing permission of the network controlled by an organization or institution, and the data reading permission is regulated by the organization. Simply put, a private chain can be a weakly centralized system with strict restrictions on node equipment and a small number of node equipment. This type of blockchain is more suitable for internal use within specific organizations.

The alliance chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization". Each node device in the alliance chain usually has a corresponding entity or organization; the node device joins the network through authorization and forms an alliance of stakeholders to jointly maintain the operation of the blockchain.

Figure 2 is a load balancing system architecture diagram described in this manual. The load balancing system may include a user client, an access program and a blockchain.

The above-mentioned user client (such as an APP application) can provide users with a service portal of the blockchain. Users can submit transaction requests to the access program through the service portal shown above, and the access program will transfer all transactions based on the load balancing strategy. The transaction request is sent to the target node device with the optimal load in the blockchain, so that the target node device processes the transaction request.

The above-mentioned access program may refer to the intermediate system between the blockchain and the user client, which does not belong to the blockchain. The access program can maintain a connection pool that connects each user client to each node device in the blockchain. That is, the access program maintains a corresponding connection pool for each user client.

In this specification, the above-mentioned access program may specifically include an SDK (Software Development Kit) program for accessing the blockchain.

In this example, the load balancing implementation code provided in this manual can be integrated into the SDK program to achieve the load balancing goal of the blockchain based on the SDK program.

In one implementation, the SDK program may include an SDK access program installed on the user client;

Accordingly, the above step 110 may include obtaining the transaction request initiated by the user on the user client.

In one implementation, the SDK program includes an SDK access service program corresponding to the user client mounted on the blockchain service platform;

Accordingly, the above step 110 may include receiving a transaction request submitted by the user client by calling a service interface deployed on the blockchain service platform corresponding to the SDK access service program.

In the application, any transaction request submitted by a user client will first be sent to the access program; then the access program will confirm an optimal load target node device from the connection pool corresponding to the user client; then the access program will The entry program sends the transaction request to the target node device in the blockchain; finally, the target node device in the blockchain responds and processes the transaction request submitted by the user client.

In this way, based on the actual load status of the node equipment in the blockchain, the access program performs load balancing in advance before submitting transaction requests to the blockchain, so that the target node equipment responsible for processing the transaction request is optimal each time. Loaded node equipment; in this way, it avoids the problem of load imbalance such that some node equipment is overloaded but has to process more transaction requests, while some node equipment is underloaded but has no transaction requests to process. And after load balancing, the processing capabilities of node devices that are originally idle and have no transaction requests can be reasonably utilized, thereby improving the overall processing efficiency of the blockchain and reducing the response time of blockchain processing requests.

A transaction request for the blockchain may refer to a request produced in a standard transaction format supported by the blockchain, and the request contains the data required for the business to be performed by the blockchain. In other words, any real data generated in the physical world can be constructed into a standard transaction format supported by the blockchain, and then published to the blockchain and received by the node pairs in the blockchain. The transaction is processed, and the node in the blockchain, which is the accounting node, packages the transaction into a block and makes a persistent certificate in the blockchain.

Generally, transaction requests can be divided into transaction requests related to blockchain transactions and transaction requests unrelated to blockchain transactions. Among them, the transaction request requires consensus before execution. That is, after receiving the transaction request, the node device participating in the consensus in the blockchain first needs to perform consensus processing on the transaction request. After the consensus is passed, the transaction request will be processed. The block The node in the chain, which serves as the accounting node, packages the transaction into a block and stores it permanently in the blockchain. Transaction requests do not require consensus before execution.

For the transaction request, since the node equipment participating in the consensus needs to reach consensus, the aforementioned step 230 can be performed. That is, if the transaction request is a transaction request related to a blockchain transaction, based on the consensus algorithm corresponding to the blockchain support The load balancing strategy is to allocate target node equipment for the transaction request from the node equipment participating in the consensus in the blockchain, and send the transaction request to the allocated target node equipment for processing; wherein, the zone The different types of consensus algorithms supported by the blockchain correspond to different load balancing strategies.

For transaction requests, since consensus is not required, step 240 can be performed:

The node device that does not participate in consensus may be a light node. Light nodes do not store blockchain ledgers locally, so transaction requests related to blockchain transactions cannot be sent to such node devices for processing.

Through the above embodiments, taking into account the differences in the types of transaction requests and combining the differences in node equipment in the blockchain, different load balancing strategies are provided for transaction requests and transaction requests to achieve node equipment balancing in the blockchain. Process transaction requests efficiently and solve the problem of unbalanced load of equipment on each node.

Furthermore, since the blockchain can support different consensus algorithms, this manual also provides different load balancing strategies for different consensus algorithms to further improve the performance and efficiency of load balancing.

Generally, publishing a transaction is divided into two steps. The first step is to publish the transaction request to the blockchain. The second step is to query the blockchain based on the transaction hash to execute the transaction execution result generated after the first step of the transaction request. . For the blockchain, it will first receive the transaction request and then the transaction query, so the transaction request and transaction execution result need to be combined into a response result and returned to the user client.

In an exemplary embodiment, if the consensus algorithm supported by the blockchain includes an asynchronous consensus algorithm; the transaction request related to the blockchain transaction includes a blockchain transaction and a query request for the blockchain transaction;

Correspondingly, in the above step 230, based on the load balancing strategy corresponding to the consensus algorithm supported by the blockchain, the target node device is allocated to the transaction request from the node devices participating in the consensus in the blockchain. Further, it can be include:

In this example, since the asynchronous consensus algorithm will not broadcast the transaction execution result generated after the blockchain executes the first step transaction request to each node device, only the current node device that accepted the first step transaction request and executed the transaction request itself has the certificate. There are transaction execution results. Therefore, when performing the second step, except for the current node device, other node devices do not have a certificate of transaction execution results, so they cannot query the transaction execution results when performing the second step. Therefore, for the asynchronous consensus algorithm, the binding relationship between the blockchain transaction and the target node device can be established when performing the first step, and then the query transaction is also forced to be loaded to the target of the first step when performing the second step. on the node device. In this way, there will be no problem of not being able to query the transaction execution results. Wherein, the asynchronous consensus algorithm may include the honeybadger consensus algorithm.

In an exemplary embodiment, if the consensus algorithm supported by the blockchain also includes a synchronous consensus algorithm;

Correspondingly, in the above step 230, based on the load balancing strategy corresponding to the consensus algorithm supported by the blockchain, allocating the target node device for the transaction request from the node devices participating in the consensus in the blockchain may include :

In this example, the synchronous consensus algorithm will broadcast the transaction execution result generated after the blockchain executes the first step of the transaction request to each node device, so that each node device can locally store the transaction execution result. Therefore, for the synchronous consensus algorithm, any node device that receives the transaction execution result can be used as the node device that receives the transaction query in the second step. Based on this, when doing load balancing, the target node device with the optimal load for the transaction request can be allocated from the node devices participating in the consensus in the blockchain. The synchronous consensus algorithm may include a PBFT (Practical Byzantine Fault Tolerance, Practical Byzantine Fault Tolerance) consensus algorithm.

In the above example of the synchronous consensus algorithm or the asynchronous consensus algorithm, the node device with the optimal load may include a randomly designated node device.

It is worth mentioning that in a blockchain using an asynchronous consensus algorithm, although the optimal load node device is a randomly designated node device, due to the introduction of the mandatory load balancing of transaction requests and transaction result query requests to the same node The load balancing mechanism of equipment processing can ensure that when the blockchain supports asynchronous consensus algorithms, the business system can obtain the transaction execution results in real time.

As mentioned before, the connection pool maintained in the access program is used to maintain the connection between the user client and the node device in the blockchain, and records the load status of each node device.

Transaction requests can be divided into transaction requests related to blockchain transactions and transaction requests unrelated to blockchain transactions. Among them, the transaction request requires consensus before execution. That is, after receiving the transaction request, the node device participating in the consensus in the blockchain first needs to perform consensus processing on the transaction request. After the consensus is passed, the transaction request will be processed. The block The node in the chain, which serves as the accounting node, packages the transaction into a block and stores it permanently in the blockchain. Transaction requests do not require consensus before execution.

To this end, connection pools can also be classified in this specification. Specifically, the access program can maintain a first connection pool based on connections with each node device participating in the consensus in the blockchain; And, a second connection pool based on connections with various node devices in the blockchain that do not participate in consensus;

Correspondingly, in step 130, a target node device is assigned to the transaction request from the node devices participating in the consensus in the blockchain, and the transaction request is sent to the assigned target node device for processing, Further can include:

In addition, in step 140, the node device with the optimal load is allocated to the transaction request from the node devices in the blockchain that do not participate in the consensus, and the transaction request is sent to the node device for processing, and further Can include:

The following describes the establishment and update of the connection pool:

For each user client, establish a first connection pool between the user client and the node device participating in the consensus in the blockchain, and the user client and the node device in the blockchain that do not participate in the consensus. The second connection pool for connections between node devices;

Timing detection determines whether the connections in the first connection pool and the second connection pool are available, and based on the detection results, adds an indication that the connection is available to the connections in the first connection pool and the second connection pool. Available tags to update the connection pool corresponding to the user client.

Generally, when the user client is started, it can create a connection with each node device based on the configured IP and port of each node on the blockchain, and it is managed by the connection pool. At the same time, you can set up a scheduled task to detect the connections in the connection pool. Scheduled tasks can send asynchronous query requests to all connections, and each node device can return response data after receiving the asynchronous query request. In this way, the scheduled task can update the connection pool based on whether the connection corresponding to each node device returns response data.

Correspondingly, the aforementioned allocating a target connection for the transaction request from the first connection pool may include:

Correspondingly, the aforementioned allocating a target connection for the transaction request from the second connection pool may include:

In an exemplary embodiment, the timing to determine whether connections in the first connection pool and the second connection pool are available includes:

If the response data returned by the node device is received within the preset timestamp range, determine that the connection is available (mark the connection between the connection pool and the node device as available);

If no response data returned by the node device is received within a preset timestamp range, it is determined that the connection is unavailable (the connection between the connection pool and the node device is marked as unavailable).

In this embodiment, if there is a node device in the blockchain that does not return response data, the timeout mechanism of the scheduled task will automatically confirm the timeout, thereby marking the connection with the node device as unavailable. During load balancing, unavailable node devices obviously cannot be used, and the target node device can only be determined from the available connections in the connection pool. In addition, since the load status of node equipment in the blockchain often changes, the connection pool can be updated periodically through scheduled tasks to update the latest load status of each node equipment.

Wherein, the preset timestamp range includes a timestamp range corresponding to a specified block in the blockchain. For example, the timestamp range corresponding to the latest block in the blockchain, or the timestamp range corresponding to the most recent blocks in the blockchain.

To sum up, this specification provides a load balancing solution that adapts to the load differences caused by different types of consensus algorithms by setting different load balancing strategies for different types of consensus algorithms supported by the blockchain; thus, For a transaction request related to a blockchain transaction submitted by a user, the transaction request can be processed from the node devices participating in the consensus in the blockchain according to the load balancing strategy corresponding to the consensus algorithm for the transaction request. Assign target node devices for processing. Since the load balancing strategy takes into account the load difference of the consensus algorithm, the allocated target node device is the current optimal node device. Based on the target node device, the transaction request can be quickly responded to, thereby avoiding the problem of slow response caused by excessive load on some node devices. .

Corresponding to the above method embodiments, this specification also provides an embodiment of a load balancing device.

The embodiments of the load balancing device in this specification can be applied to electronic equipment. The device embodiments may be implemented by software, or may be implemented by hardware or a combination of software and hardware. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory and running them through the processor of the electronic device where it is located.

From the hardware level, as shown in Figure 3, it is a hardware structure diagram of the electronic equipment where the load balancing device of this specification is located. In addition to the processor, memory, network interface, and non-volatile memory shown in Figure 3 In addition, the electronic device where the device in the embodiment is located may also include other hardware according to the actual functions of the electronic device, which will not be described again.

FIG. 4 is a block diagram of a load balancing device according to an exemplary embodiment of this specification. The load balancing device can be applied to the access program corresponding to the blockchain, and the device includes:

The receiving unit 410 receives the transaction request submitted by the user;

The determining unit 420 determines the type of the transaction request in response to the received transaction request submitted by the user;

The balancing unit 430, when the transaction request is a transaction request related to a blockchain transaction, based on the load balancing strategy corresponding to the consensus algorithm supported by the blockchain, node devices participating in the consensus from the blockchain Allocate target node equipment to the transaction request in , and send the transaction request to the allocated target node equipment for processing; wherein, the different types of consensus algorithms supported by the blockchain respectively correspond to different load balancing Strategy.

Optionally, the balancing unit 430 is also configured to remove nodes from the blockchain that do not participate in the consensus based on a preset load balancing strategy when the transaction request is a transaction request that is not related to a blockchain transaction. The device allocates the node device with the optimal load for the transaction request, and sends the transaction request to the node device for processing.

The balancing unit 430 is also configured to, when the transaction request is a blockchain transaction, based on the load balancing strategy corresponding to the asynchronous consensus algorithm, from the node devices participating in the consensus in the blockchain, for the The blockchain transaction allocates the target node device with the optimal load, and establishes a binding relationship between the blockchain transaction and the target node device; and, when the transaction request is a query request corresponding to the blockchain transaction, Based on the load balancing strategy corresponding to the asynchronous consensus algorithm, the binding relationship is queried, and the target node device bound to the blockchain transaction is assigned to the query request.

The balancing unit 430 is also configured to allocate the target node device with the optimal load for the transaction request from the node devices participating in the consensus in the blockchain based on the load balancing strategy corresponding to the synchronous consensus algorithm.

The receiving unit 410 is also used to obtain the transaction request initiated by the user on the user client.

The receiving unit 410 is also configured to receive a transaction request submitted by the user client by calling the service interface deployed on the blockchain service platform and corresponding to the SDK access service program.

The balancing unit 430 allocates a target node device for the transaction request from the node devices participating in the consensus in the blockchain, and sends the transaction request to the assigned target node device for processing, including:

The balancing unit 430 allocates the node device with the optimal load for the transaction request from the node devices that do not participate in the consensus in the blockchain, and sends the transaction request to the node device for processing, including:

Optionally, the device also includes:

The balancing unit 430 allocates a target connection for the transaction request from the first connection pool, including:

The balancing unit 430 allocates a target connection for the transaction request from the second connection pool, including:

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, a laptop, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, or a game controller. desktop, tablet, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. Information may be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory. (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape cartridges, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium, can be used to store information that can be accessed by computing devices. As defined in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprises," or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements not only includes those elements, but also includes Other elements are not expressly listed or are inherent to the process, method, article or equipment. Without further limitation, an element defined by the statement "comprises a..." does not exclude the presence of additional identical elements in a process, method, article, or device that includes the stated element.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desired results. Additionally, the processes depicted in the figures do not necessarily require the specific order shown, or sequential order, to achieve desirable results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the one or more embodiments of this specification. As used in one or more embodiments of this specification and the appended claims, the singular forms "a," "the" and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although one or more embodiments of this specification may use the terms first, second, third, etc. to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be called second information, and similarly, the second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "when" or "in response to determining."

The above are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Within the spirit and principles of one or more embodiments of this specification, Any modifications, equivalent substitutions, improvements, etc. shall be included in the scope of protection of one or more embodiments of this specification.

Claims

A load balancing method, applied to the access program corresponding to the blockchain, the method includes:

Receive transaction requests submitted by users;

In response to receiving a transaction request submitted by the user, determining the type of the transaction request;

If the transaction request is a transaction request related to a blockchain transaction, based on the load balancing strategy corresponding to the consensus algorithm supported by the blockchain, the node device participating in the consensus in the blockchain provides the transaction with Request allocation of target node equipment, and send the transaction request to the allocated target node equipment for processing; wherein, different types of consensus algorithms supported by the blockchain respectively correspond to different load balancing strategies.
The method of claim 1, further comprising:

If the transaction request is a transaction request that is not related to the blockchain transaction, based on the preset load balancing strategy, allocate the node device with the optimal load to the transaction request from the node devices that do not participate in the consensus in the blockchain. , and send the transaction request to the node device for processing.
According to the method of claim 1, the consensus algorithm supported by the blockchain includes an asynchronous consensus algorithm; the transaction request related to the blockchain transaction includes a blockchain transaction and a query request for the blockchain transaction;

The method of allocating a target node device to the transaction request from the node devices participating in the consensus in the blockchain based on the load balancing strategy corresponding to the consensus algorithm supported by the blockchain includes:

If the transaction request is a blockchain transaction, based on the load balancing strategy corresponding to the asynchronous consensus algorithm, the target of allocating the optimal load to the blockchain transaction from the node devices participating in the consensus in the blockchain Node equipment, and establish a binding relationship between the blockchain transaction and the target node equipment;

If the transaction request is a query request corresponding to a blockchain transaction, based on the load balancing strategy corresponding to the asynchronous consensus algorithm, the binding relationship is queried, and the target node device bound to the blockchain transaction is assigned to the query request.
According to the method of claim 3, the consensus algorithm supported by the blockchain further includes a synchronous consensus algorithm;

The method of allocating a target node device to the transaction request from the node devices participating in the consensus in the blockchain based on the load balancing strategy corresponding to the consensus algorithm supported by the blockchain includes:

Based on the load balancing strategy corresponding to the synchronous consensus algorithm, the target node device with the optimal load is allocated to the transaction request from the node devices participating in the consensus in the blockchain.
According to the method of any one of claims 2-4, the optimally loaded node device includes a randomly designated node device.
According to the method of claim 4, the synchronous consensus algorithm includes the pbft consensus algorithm; the asynchronous consensus algorithm includes the honeybadger consensus algorithm.
According to the method of claim 1, the access program includes an SDK program for accessing the blockchain.
According to the method of claim 7, the SDK program includes an SDK access program installed on the user client;

The reception of transaction requests submitted by users includes:

Obtain the transaction request initiated by the user on the user client.
According to the method of claim 7, the SDK program includes an SDK access service program corresponding to the user client mounted on the blockchain service platform;

The reception of transaction requests submitted by users includes:

Receive a transaction request submitted by the user client by calling a service interface deployed on the blockchain service platform corresponding to the SDK access service program.
According to the method of claim 2, the access program maintains a first connection pool based on connections with each node device participating in consensus in the blockchain; and, based on connections with the blockchain A second connection pool composed of connections between node devices that do not participate in the consensus; the method also includes:

Timing detection determines whether the connections in the first connection pool and the second connection pool are available, and based on the detection results, adds an indication that the connection is available to the connections in the first connection pool and the second connection pool. available tags;

Allocating a target connection for the transaction request from the first connection pool includes:

Allocate available target connections for the transaction request from the connections added with available tags in the first connection pool;

Allocating a target connection for the transaction request from the second connection pool includes:

Allocate available target connections for the transaction request from connections added with available tags in the second connection pool.
The method according to claim 10, the timing of determining whether connections in the first connection pool and the second connection pool are available includes:

Regularly sending asynchronous query requests to node devices corresponding to connections in the first connection pool and the second connection pool;

If the response data returned by the node device is received within the preset timestamp range, it is determined that the connection is available;

If the response data returned by the node device is not received within the preset timestamp range, it is determined that the connection is unavailable.
According to the method of claim 11, the preset timestamp range includes a timestamp range corresponding to a specified block in the blockchain.
A load balancing device, applied to the access program corresponding to the blockchain, the device includes:

The receiving unit receives transaction requests submitted by users;

a determining unit that determines the type of the transaction request in response to the received transaction request submitted by the user;

A balancing unit, when the transaction request is a transaction request related to a blockchain transaction, based on the load balancing strategy corresponding to the consensus algorithm supported by the blockchain, from the node devices participating in the consensus in the blockchain Allocate a target node device to the transaction request, and send the transaction request to the assigned target node device for processing; wherein, different types of consensus algorithms supported by the blockchain correspond to different load balancing strategies. .
An electronic device including:

processor;

Memory used to store instructions executable by the processor;

Wherein, the processor implements the method according to any one of claims 1-12 by running the executable instructions.