Claim processing method, apparatus, computing device, and computer program

Abstract

A request processing method, apparatus, computing device and storage medium, belonging to the technical field of database, provides flexible multiple levels for lock synchronization mode, in weak synchronization mode, directly locks a data resource corresponding to a data request to execute the data request, thereby ensuring that the data request is prioritized and does not need to wait for a response from a second computing device, in non-weak synchronization mode, obtains locking feedback information of each second computing device, and if the obtained locking feedback information meets a target condition, locks the data resource to execute the data request, supporting selecting different lock synchronization modes in different traffic scenarios, for example, in a smart traffic scenario, based on the weak synchronization mode, the request for adding a parking space can be prioritized but the request for sharing a journey does not need to be prioritized, ensuring that the cluster database can meet the processing needs of different traffic scenarios and improving the processing capacity of the cluster database system.

Description

Technical Field

[0001] This application claims the priority of a Chinese patent application filed with the China National Patent Office on August 30, 2021, with an application number of 2021110037642 and an application title of "Request Processing Method, Apparatus, Computing Device, and Storage Medium", and all of its contents are incorporated herein by reference.

[0002] This application relates to the technical field of databases, and particularly to request processing technology.

Background Art

[0003] With the development of database technology, traditional stand-alone databases are increasingly unable to adapt to traffic scenarios such as big data and cloud computing, and cluster databases are becoming more and more popular. Currently, whether it is a stand-alone database such as MySQL or PostgreSQL, or a cluster database such as IBM or Oracle, they all adopt a parallel control method based on a strong synchronization lock mechanism. The strong synchronization lock mechanism is as follows: the lock request process succeeds only when all computing devices in the cluster obtain the corresponding level of lock. Otherwise, it waits. If the lock request of any one computing device in the cluster fails, or the waiting times out, the process cannot successfully request the lock.

Summary of the Invention

Problems to be Solved by the Invention

[0004] In a cluster database, a strong synchronization lock mechanism requires all computing devices in the cluster to acquire locks at the corresponding level. As the number of computing devices in the cluster increases, the overhead of lock requests also increases significantly, and furthermore, the processing capacity of the cluster database system deteriorates. Therefore, a method for improving the processing capacity of the cluster database system is needed.

[0005] Embodiments of the present application provide a request processing method, apparatus, computing device, and storage medium that can improve the processing capacity of a cluster database system. The technical solution is as follows.

Means for Solving the Problem

[0006] According to one aspect, a request processing method executed by a first computing device in a cluster database is provided. Determining a lock synchronization mode of the cluster database in response to a data request; When the lock synchronization mode is a weak synchronization mode, locking a data resource corresponding to the data request and executing the data request; When the lock synchronization mode is not a weak synchronization mode, obtaining locking feedback information of at least one second computing device in the cluster database with respect to the data resource, where the locking feedback information indicates whether the locking of the data resource by the second computing device is successful. When the obtained locking feedback information meets a target condition corresponding to the lock synchronization mode, locking a data resource corresponding to the data request and executing the data request.

[0007] According to one aspect, a request processing method executed by a second computing device in a cluster database is provided, and the method In response to a locking request associated with a data request, adding the locking request to a locking queue, wherein the locking request is sent by a first computing device in the cluster database when the lock synchronization mode is not a weak synchronization mode; Processing the locking request in the locking queue to obtain locking feedback information; Sending the locking feedback information to the first computing device. The method includes the above steps.

[0008] According to one aspect, a request processing apparatus is provided. A determination module that determines a lock synchronization mode of a cluster database in response to a data request; A locking execution module that locks a data resource corresponding to the data request and executes the data request when the lock synchronization mode is a weak synchronization mode; A first acquisition module that acquires locking feedback information of at least one second computing device in the cluster database with respect to the data resource, wherein the locking feedback information is for indicating whether the locking of the data resource by the second computing device is successful, when the lock synchronization mode is not a weak synchronization mode. The apparatus includes the first acquisition module. The locking execution module further locks the data resource corresponding to the data request and executes the data request when the acquired locking feedback information meets a target condition corresponding to the lock synchronization mode.

[0009] According to one aspect, a request processing apparatus is provided. An additional module that adds the locking request to a locking queue in response to a locking request associated with a data request, where the locking request is sent by a first computing device in the cluster database when the lock synchronization mode is not a weak synchronization mode. A processing module that processes the locking request in the locking queue to obtain locking feedback information. A sending module that sends the locking feedback information to the first computing device, and includes.

[0010] According to one aspect, a computing device is provided, which includes one or more processors and one or more memories. At least one computer program is stored in the one or more memories, and the at least one computer program is read and executed by the one or more processors to implement the request processing method of any one of the above possible implementation forms.

[0011] According to one aspect, a storage medium is provided, in which at least one computer program is stored, and the at least one computer program is read and executed by a processor to implement the request processing method of any one of the above possible implementation forms.

[0012] According to one aspect, a computer program product or a computer program is provided, the computer program product or the computer program includes one or more program codes, and the one or more program codes are stored in a computer-readable storage medium. One or more processors of a computing device read the one or more program codes from the computer-readable storage medium, and the one or more processors execute the one or more program codes to cause the computing device to execute the request processing method of any one of the above possible embodiments.

Advantages of the Invention

[0013] The beneficial effects of the technical solution provided by the embodiments of this application include at least the following: A plurality of flexible levels are set for the lock synchronization mode. In the weak synchronization mode, the data resources corresponding to the data requests are directly locked, and by executing the data requests, it is guaranteed that the data requests can be preferentially promoted, without the need to wait for the response of the second computing device. In the non-weak synchronization mode, the locking feedback information of each second computing device is obtained, and the data resource is locked and the data request is executed only when the obtained locking feedback information meets the target conditions. It supports selecting different lock synchronization modes in different traffic scenarios, ensuring that the cluster database can meet the processing needs of different traffic scenarios, and improving the processing capacity of the cluster database system.

Brief Description of the Drawings

[0014]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Embodiments for Carrying Out the Invention

[0015] In order to make the purpose, technical solution and advantages of the present application clearer, the embodiments of the present application will be described in more detail below in conjunction with the drawings.

[0016] Terms such as "first" and "second" in the present application are terms for distinguishing the same item or similar items whose functions and functions are basically the same. Here, there is no logical or sequential dependence between "first", "second", and "nth", and the number and execution order are not limited.

[0017] The term "at least one" in the present application refers to one or more, and the meaning of "a plurality" is two or more. For example, a plurality of first positions refers to two or more first positions.

[0018] Before introducing the embodiments of the present application, some basic concepts in the field of cloud technology are introduced.

[0019] Cloud Technology: It is a hosting technology that integrates a series of resources such as hardware, software, and networks within a wide - area communication network or a local network to realize data computing, storage, processing, and sharing. It is a general term for network technology, information technology, integration technology, platform management technology, application technology, etc. applied based on the cloud computing business model. It can form a resource pool, be used according to needs, and is flexible and convenient. In the field of cloud technology, cloud computing technology plays an important supporting role. The background services of the technology network system require a large amount of computing and storage resources, such as video websites, picture websites, and more portal websites. With the highly developed and applied Internet industry, in the future, each item may have its own identification mark and needs to be transmitted to the background system for logical processing. Different levels of data need to be processed separately, and various types of industry data all require strong system background support, which can be realized by cloud computing.

[0020] Cloud Storage: It is a new concept developed by extending based on the cloud computing concept. A distributed cloud storage system (hereinafter abbreviated as the storage system) is a storage system that integrates a large number of different types of storage devices (storage devices are also called storage nodes) in the network through application software or application interfaces by functions such as cluster applications, grid technology, and distributed file storage systems, and makes them cooperate to jointly provide external data storage and traffic access functions.

[0021] Database: In short, it is an electronic file cabinet, a place to store electronic files, and users can perform operations such as adding, searching, updating, and deleting data in the files. A "database" is a data set that is stored in a certain way, can be shared by multiple users, has as little redundancy as possible, and is independent of application programs.

[0022] Hereinafter, the terms related to the embodiments of the present application will be interpreted and described.

[0023] Computing device: That is, a computing node, which processes specific computing requests of users for a database (generally a cluster database, and for a stand-alone database, the stand-alone device itself is a computing device), and is mainly a node device that executes user requests. It is also called an SQL Engine. The full English name of SQL is Structured Query Language, and the full Chinese name is Structured Query Language.

[0024] Lock mechanism: During the operation of a cluster database, there is a phenomenon that different or the same computing devices have different processes or threads modifying the same type of data resources (such as databases, data tables, data columns, data data tables, etc.) at the same time. The lock mechanism can ensure the accuracy of the modification of the data resources in different parallel processes or threads. Cluster databases are divided into central cluster databases and distributed cluster databases. A central cluster database is a cluster database with a centralized control module, and a distributed cluster database is a decentralized cluster database.

[0025] Strong synchronization lock mechanism: That is, the lock request process is successful only when the corresponding level of locks are acquired from all computing devices in the cluster. Otherwise, it waits. If the lock request of any one computing device in the cluster fails, or the wait times out, the process cannot successfully request the lock.

[0026] The requirements for the communication performance between nodes (i.e., between computing devices) of the strong synchronization lock mechanism are very high. Due to the non - response or failure of a single computing device, the execution of other computing devices in the cluster is blocked by this computing device, and the traffic processing capacity of the entire cluster seems to decrease significantly. For example, the traffic processing of the entire cluster is blocked (Hung (hung up)). Generally, the strong synchronization lock mechanism is mainly applied to stand - alone database and central cluster database scenarios.

[0027] Weak synchronization lock mechanism: During the execution process, when some processes or threads (e.g., processes or threads of data definition language DDL requests) attempt to lock a certain type of data resource, they do not need to request a lock from other computing devices and can directly proceed. The accuracy of the operation is guaranteed by a specific mechanism, the Writing Fence (write barrier). With the guarantee of the write barrier mechanism, the process or thread of the DDL request does not need to request a lock and can directly proceed with the execution. And by advancing the write barrier, when other traffic processes or threads operate on the data, they all compare whether the write barrier version of the current operation is consistent with the write barrier version stored in the latest data. If they are inconsistent, to ensure the accuracy and consistency of data processing, the traffic transaction corresponding to the traffic process or thread is rolled back.

[0028] The weak synchronization lock mechanism, to some extent, guarantees the priority of DDL requests because, once the write barrier is advanced, the data manipulation language (DML) requests corresponding to the operations may be rolled back. That is, the weak synchronization lock mechanism is not friendly to DML requests. The above-mentioned weak synchronization lock mechanism may be regarded as the preferential execution of a certain type of process or thread (such as the process of DDL requests). Such a weak synchronization mode needs to use auxiliary means (such as write barriers or lease mechanisms) to ensure the accuracy of the overall mechanism's advancement. Such a weak synchronization mode is suitable for distributed cluster database scenarios, but there are situations where the user's representation behavior does not match the execution behavior of traditional databases and it is not friendly to DML requests. Also, since the DDL process or thread in the weak synchronization mode is defaulted to have acquired a lock, the transactions executed by a large number of other types of DML processes or threads will be rolled back.

[0029] Semi-strong synchronization lock mechanism: That is, it is a compromise implementation of the above two lock mechanisms (strong synchronization lock mechanism and weak synchronization lock mechanism). Since both of the above two lock mechanisms have significant advantages and disadvantages, when applied to a distributed cluster database, they face great challenges. Therefore, the concept of a semi-strong synchronization lock mechanism is very necessary for the high-performance processing of a large-scale distributed cluster with respect to user traffic. That is, when a certain process or thread requests a lock on a certain data resource, it adopts a method of sending lock requests to all computing devices, starts timing, waits for a while, and then determines whether the lock request is successful based on the feedback status (such as locking feedback information) of a specified target number of computing devices. Such a semi-strong synchronization mode does not cause the overall processing capacity of the cluster to be significantly reduced due to the non-response of some computing devices, and thus does not render the overall processing capacity of the cluster ineffective. Since a certain process or thread has an inherent lock, other DML (generally, a user traffic transaction, which is an important indicator for evaluating the quality and performance of data services provided by the database) requests will not be improperly rolled back.

[0030] DDL (Data Definition Language) request: That is, a DDL statement operation, which is a modification operation statement for modifying the definition of data objects (such as objects like databases, data tables, data columns, data indexes, etc.) in a database.

[0031] DML (Data Manipulate Language, Data Manipulation Language) requirements: That is, it is a DML statement operation, which is an operation statement for modifying user data stored in a database. Generally, it corresponds to user traffic transactions. That is, DML requirements are generally traffic requirements and user traffic transactions, and they are important indicators for evaluating the quality and performance of data services provided by a database.

[0032] The embodiments of this application are applicable to a cluster database (i.e., a cluster database system). A cluster database includes a central cluster database and a distributed cluster database. The central cluster database is a cluster database with a centralized control module. In the cluster, a central node for arranging a global transaction manager and a global lock management module is provided. The distributed cluster database is a decentralized cluster database. In the cluster, there is no central node for arranging a global transaction manager and a global lock management module. All computing nodes in the cluster achieve the realization of global transactions and global locks through a certain algorithm. For example, the distributed cluster database is a distributed database management system using a distributed database system, a distributed big data processing system, and similar architectures.

[0033] The cluster database includes at least one computing device (i.e., a computing node). In the database of each computing device, a plurality of data tables are stored. Each data table stores (records) one or more data rows, and each data row is composed of a set of field sets arranged according to a specific position index, that is, a data field column. Note that the database of the computing device is any type of cluster database, including at least one of a relational database or a non-relational database, such as an SQL (Structured Query Language) database, MySQL, NoSQL, NewSQL (generally, various new extensible / high-performance databases), etc. In the embodiments of the present application, the type of the database is not specifically limited.

[0034] In some embodiments, the embodiments of the present application can further be applied to a database system based on blockchain technology (hereinafter abbreviated as "blockchain system"). The above blockchain system is essentially a decentralized distributed database system. It uses a consensus algorithm to maintain the consistency of the ledger data described in different computing devices on the blockchain, and uses an encryption algorithm to ensure the encrypted transmission and non-tampering of the ledger data between different computing devices. It extends the ledger function through a script system and connects different computing devices to each other through network routing.

[0035] The blockchain system includes one or more blockchains. A blockchain is a series of associated data blocks generated by an encryption method. Each data block contains information on a batch of network transactions, thereby verifying the validity (counterfeit prevention) of the information and generating the next block.

[0036] In a blockchain system, computing devices form a peer-to-peer (P2P) network among themselves, and the P2P protocol is an application layer protocol operating on top of the Transmission Control Protocol (TCP). In a blockchain system, any one computing device has the following functions: 1) Routing, which is a basic function of a computing device and supports communication between computing devices. 2) Application, which is deployed on the blockchain, realizes specific traffic based on actual traffic needs, records data associated with the specific traffic to form ledger data, and the ledger data is digitally signed to indicate the data origin. By sending the ledger data to other computing devices in the blockchain system, when other computing devices successfully verify the origin and integrity of the ledger data, they add the ledger data to a temporary block. The traffic realized by the application includes wallets, shared ledgers, smart contracts, etc. 3) Blockchain, which includes a series of blocks connected to each other in chronological order. Once a new block is added to the blockchain, it cannot be deleted, and the block records the ledger data submitted by computing devices in the blockchain system.

[0037] In some embodiments, each block includes a hash value (the hash value of the block) for storing the transaction record of the block and the hash value of the previous block. Each block forms a blockchain through hash value connection. Also, the block further includes information such as a timestamp when the block was generated.

[0038] The system architecture of the embodiments of the present application will be described below.

[0039] FIG. 1 is a schematic diagram of an implementation environment of a request processing method provided by an embodiment of the present application. Referring to FIG. 1, taking the case where the cluster database is a distributed cluster database as an example, the distributed cluster database system includes an application client 101, a gateway server 102, and a distributed storage cluster 103, and the distributed storage cluster 103 includes one or more computing devices.

[0040] The application client 101 is installed and executed on a user-side terminal and is a client that can initiate a data request. The data request may be a DDL request or a DML request, etc., and the embodiments of the present application do not specifically limit this. Optionally, the type of the application client 101 includes, but is not limited to, a payment application, a social application, an audio / video application, a live streaming application, an e-commerce application, a delivery application, a taxi application, etc., and the embodiments of the present application do not specifically limit the type of the application client 101. In some embodiments, the user-side terminal is also referred to as a user device, a terminal device, a user terminal, a mobile terminal, a smart terminal, a communication device, etc. Optionally, the type of the terminal device includes, but is not limited to, a smartphone, a tablet, a notebook computer, a desktop computer, a smart speaker, a smart watch, an in-vehicle terminal, a smart appliance, a smart voice interaction device, etc.

[0041] The application client 101 and the gateway server 102 are directly or indirectly connected by a wired or wireless communication method, and the present application does not limit this.

[0042] The gateway server 102 receives external data requests and distributes read / write transactions corresponding to the data requests to the distributed storage cluster 103. Generally, a user logs in to the application client 101 on a terminal and triggers the application client 101 to generate a DDL request. For example, the DDL request modifies the table name of data table A, and the application client 101 calls the API (Application Programming Interface) provided by the distributed cluster database system to send the DDL request to the gateway server 102. For example, the API is a MySQL API (an API provided by a relational database system). Also, for example, in a smart traffic scenario, a request to add a parking space is a DDL request, and a request to search for existing parking spaces is a DML request.

[0043] In some embodiments, the gateway server 102 is coupled to any one of the computing devices in the distributed storage cluster 103 on the same physical machine, that is, a certain computing device in the distributed storage cluster 103 serves as the gateway server 102.

[0044] The distributed memory cluster 103 includes one or more computing devices. When executing some data requests, such as DDL requests, it is necessary to add a global lock to the DDL request to ensure the accuracy of the operations of the DDL transaction corresponding to the DDL request. The computing device that processes the DDL request is called the first computing device, and the other computing devices other than the first computing device are called the second computing devices. Optionally, the distinction between the first computing device and the second computing device targets different DDL requests, and the number of the second computing devices may be one or more. The embodiments of this application do not specifically limit the number of computing devices in the distributed memory cluster 103. For example, the number of computing devices is m, and m is an integer greater than or equal to 1.

[0045] Optionally, each computing device adopts a master / slave configuration (i.e., one master / multiple slaves cluster). As shown in FIG. 1, taking the computing device as an example of one master / two slaves cluster, each computing device includes one master device and two slave devices. Optionally, a proxy (Agent) device is arranged corresponding to each master device or slave device. The proxy device and the master device or slave device may be physically independent. Of course, the proxy device may also be a proxy module of the master device or slave device. Taking computing device 1 as an example, computing device 1 includes one master database and a proxy device (abbreviated as master database + agent, master DB + agent), and also includes two slave databases and proxy devices (abbreviated as slave database + agent, slave DB + agent).

[0046] In an exemplary scenario, the set of database instances of the master device or slave device corresponding to each computing device is called one SET. For example, if a certain computing device is a stand-alone device, the SET of the computing device is the database instance of the stand-alone device. If a certain computing device is a 1 master / 2 slave cluster, the SET of the computing device is a set of the master device database instance and two slave device database instances.

[0047] In some embodiments, the distributed cluster database system composed of the above gateway server 102 and distributed storage cluster 103 is regarded as a server that provides data services to user terminals. The server may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. Furthermore, it may also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), big data, and artificial intelligence platforms.

[0048] The following takes the case where the cluster database is a distributed cluster database as an example to introduce the lock synchronization mechanism model provided by the embodiments of the present application. FIG. 2 is a schematic diagram of the principle of the lock synchronization mechanism model provided by the embodiments of the present application. As shown in 200, the distributed cluster database includes a first computing device and three second computing devices A, B, and C. Assume that the first computing device receives a DDL request at a certain point in time. The DDL request can ensure the accuracy of the operation only when it is locked in the distributed cluster database. Taking the strong synchronization mode as an example, in the strong synchronization mode, the first computing device and the second computing devices A, B, and C all request locks on the data resources corresponding to the DDL request. After all computing devices successfully request locks, the processing logic of the DDL request is executed, that is, the corresponding DDL transaction is completed. The first computing device releases the lock of the DDL request and notifies the second computing devices A, B, and C to release the lock of the DDL request. The following details the entire lock synchronization process: Step 1: The first computing device starts to process the DDL request. Step 2: The first computing device performs DDL preparation, for example, locally completes a local lock request for the data resources that require locking. Step 3: The first computing device sends locking requests to the second computing devices A, B, and C respectively through a locking module or a locking function. The second computing devices A, B, and C process the respective locking requests and return locking feedback information to the first computing device. Step 4: The first computing device executes the DDL processing logic, for example, executes the DDL transaction corresponding to the DDL request. Step 5: The first computing device sends unlock requests to the second computing devices A, B, and C respectively through an unlock module or an unlock function, and the second computing devices A, B, and C process the unlock requests respectively and return unlock feedback information to the first computing device. Step 6: The first computing device ends the DDL request processing process (abbreviated as the DDL process).

[0049] As can be seen from the above process, if a locking module or a locking function is added to the first computing device, it can be guaranteed that the lock of a certain DDL request is synchronized to other second computing devices in the cluster. For example, after each second computing device receives a locking request, it requests a lock locally and returns the locking feedback information to the remote node that requests the lock (i.e., the first computing device). Also, in the unlock process, the unlock request is sent from the lock owner side (i.e., the first computing device that starts the locking request) to other second computing devices in the cluster. After each second computing device receives the unlock request, it unlocks the corresponding lock locally and returns the unlock feedback information to the remote node (i.e., the first computing device).

[0050] In the above embodiment, the general framework of the lock synchronization mechanism model is briefly introduced. In the embodiment of the present application, each operation of the first computing device during the locking process is described. FIG. 3 is a flowchart of the request processing method provided by the embodiment of the present application. Referring to FIG. 3, the embodiment is executed by the first computing device in the cluster database, and the embodiment includes the following steps: 301: In response to a data request, the first computing device determines the lock synchronization mode of the cluster database.

[0051] Optionally, the cluster database is a central cluster database or a distributed cluster database, both of which can be applied to the claim processing method. In the embodiments of the present application, only the distributed cluster database will be described as an example. The cluster database includes a first computing device and a second computing device. The first computing device is the computing device that processes the data request, and all computing devices in the cluster except the first computing device in the cluster are called the second computing device.

[0052] In some embodiments, the user logs in to the application client on the terminal and triggers the application client to generate the data request. Optionally, the data request is a data definition language (DDL) request or a data manipulation language (DML) request. In the embodiments of the present application, the case where the data request is a DDL request will be described as an example. For example, the DDL request is to modify the table name of data table A. After generating the data request, the application client calls an API to send the data request to the first computing device.

[0053] In some embodiments, the first computing device receives the data request and analyzes the header field of the data request. When the header field indicates that the data request is a request of a specified type, for example, a DDL request, the lock synchronization mode of the cluster database is determined.

[0054] In some embodiments, the lock synchronization mode is indicated by a lock synchronization mode parameter lock_level_mode disposed in a database system (or a database engine), and the lock synchronization mode parameter lock_level_mode represents the lock synchronization mode in which the cluster database is located. The lock synchronization mode includes, but is not limited to, a strong synchronization mode (Strong), a quasi-strong synchronization mode (Middle), and a weak synchronization mode (Feak). The first computing device searches for the value of the lock synchronization mode parameter lock_level_mode from the configuration file. If the lock synchronization mode parameter lock_level_mode = Strong, the lock synchronization mode is determined to be the strong synchronization mode. If the lock synchronization mode parameter lock_level_mode = Middle, the lock synchronization mode is determined to be the quasi-strong synchronization mode. If the lock synchronization mode parameter lock_level_mode = Feak, the lock synchronization mode is determined to be the weak synchronization mode.

[0055] In some embodiments, the lock synchronization mode parameter lock_level_mode is added to the configuration file. When the cluster database is started, the configuration file is loaded into the database engines of all computing devices in the cluster.

[0056] In some embodiments, when the entire cluster is operating, the lock synchronization mode parameter lock_level_mode may be randomly modified by a computing device. After modifying the lock synchronization mode parameter lock_level_mode, the computing device automatically synchronizes the modified lock synchronization mode parameter lock_level_mode to all computing devices in the cluster.

[0057] In some embodiments, if the first computing device determines that the lock synchronization mode is the weak synchronization mode, it executes the following step 302. If the first computing device determines that the lock synchronization mode is the strong synchronization mode or the quasi-strong synchronization mode, it executes the following steps 303-304.

[0058] In some other embodiments, the first computing device is local. After completing the local lock request for the data resources that require locking, it proceeds to the locking flow, and determines whether the lock synchronization mode is the weak synchronization mode. If the lock synchronization mode is the weak synchronization mode, it executes the following step 302. If the lock synchronization mode is not the weak synchronization mode, it executes the following steps 303-304.

[0059] 302: If the lock synchronization mode is the weak synchronization mode, the first computing device locks the data resources corresponding to the data request and executes the data request.

[0060] If the lock synchronization mode is the weak synchronization mode, the first computing device can directly advance the current data request, such as a DDL request, and there is no need to request a lock from other second computing devices. Note that the accuracy of the operation is guaranteed by a specific mechanism, the Writing Fence (write barrier). By the above mechanism, in a multi-core multi-thread environment, it is guaranteed that only one thread can enter the critical section code at a certain point in time, and the consistency of the operation data in the critical section is guaranteed.

[0061] Here, the "lock" according to the embodiments of the present application is a memory state parameter in the memory. For example, the memory state parameter may be an integer, and the memory state parameter is related to the data resource and indicates whether to lock the related data resource.

[0062] Optionally, the memory state parameter includes two states: an idle state and a locked state. When locking, it is determined whether the lock is idle. If it is idle, it is modified to the locked state, and itself is converted to the lock owner side, returning a successful lock request. If it is already locked, a failed lock request is returned. When unlocking, the locked state is modified to the idle state.

[0063] Optionally, the memory state parameter includes two or more states: an idle state, a read lock (i.e., a shared lock, an S lock), a write lock (i.e., an exclusive lock, an X lock), and an update lock. The read lock, write lock, and update lock distinguish the executable operations of other DML requests on the locked data resource in the locked state. For example, if a DDL request adds T1_lock to the user table T1 and T1_lock is a read lock, other DML requests cannot perform write operations on the user table T1, but still can normally read the data items in the user table T1.

[0064] In the weak synchronization mode, for the guarantee of the write barrier mechanism, after the first computing device successfully requests a lock locally, it may be considered that the lock is directly acquired, that is, the first computing device is converted to the lock owner side, and there is no need to send a locking request to each other second computing device. It is determined that the data resource corresponding to the data request is successfully locked, the locking flow ends, and the database transaction corresponding to the data request may be executed, for example, the DDL transaction corresponding to the DDL request is executed by the DDL thread.

[0065] 303: When the lock synchronization mode is not the weak synchronization mode, the first computing device acquires the locking feedback information of at least one second computing device in the cluster database with respect to the data resource, and the locking feedback information indicates whether the locking of the second computing device with respect to the data resource is successful.

[0066] If the lock synchronization mode is not the weak synchronization mode, it may be the strong synchronization mode or the quasi-strong synchronization mode. In the above strong synchronization mode or quasi-strong synchronization mode, the first computing device requests a lock from each distal second computing device, and the target conditions for determining the success of the lock request are different for the two modes. In the strong synchronization mode, the global lock request for the data resource is considered successful only when all the second computing devices have successfully requested a lock. In the quasi-strong synchronization mode, if more than the target number of second computing devices successfully request a lock, the global lock request for the data resource is considered successful.

[0067] In some embodiments, the first computing device requests a lock from each second computing device to obtain the locking feedback information of each second computing device. Optionally, the locking feedback information includes locking success and locking failure. Usually, the causes of locking failure are diverse, for example, the waiting times out, a deadlock is reached, etc.

[0068] In some embodiments, the process of requesting a lock for each of the above second computing devices includes: the first computing device sending a locking request associated with the data request to the at least one second computing device; and the first computing device receiving the locking feedback information returned from the at least one second computing device based on the locking request.

[0069] Optionally, in the first computing device and each second computing device, a message processing thread is established in the background, and the message processing thread is dedicated to processing various messages related to the lock mechanism. For example, it monitors locking requests, unlocking requests, locking feedback information, unlocking feedback information, etc. from other computing devices, and ensures the communication performance between computing devices by immediately sending and receiving various messages related to the lock mechanism.

[0070] Based on the above situation, when sending a locking request, the first computing device sends the locking request to the message processing thread on the at least one second computing device through its own message processing thread. Similarly, when receiving locking feedback information, the first computing device receives the locking feedback information returned from the message processing thread on the at least one second computing device through the message processing thread of the first computing device. The lock request flow of the second computing device will be described in detail in the following embodiments, and will not be elaborated here.

[0071] In some embodiments, the first computing device sends the locking request to each second computing device in the cluster respectively. The time for the locking feedback information of each second computing device to return to the first computing device may be different. In some exemplary scenarios, when the processing process of the data request (e.g., DDL process) crashes on the first computing device, after the DDL process crashes, for the received locking feedback information, the first computing device immediately instructs the second computing device that has successfully locked to release the corresponding lock according to the situation, so as to avoid blocking other DML processes on the data resource and optimize the processing performance of the cluster database.

[0072] Regarding the above situation, in response to receiving the locking feedback information of any one of the second computing devices, when the data request is in an active state, the message processing thread sends the locking feedback information to the lock request thread of the data request. When the data request is in an inactive state and the locking feedback information indicates successful locking, a lock release request is sent to the second computing device, and the lock release request instructs the second computing device to release the data resource corresponding to the data request.

[0073] Optionally, after receiving any one of the locking feedback information by the message processing thread, the first computing device determines whether the local data request is active, and takes the DDL request as an example to determine whether there is a DDL process corresponding to the DDL request. Since there may be a situation where multiple DDL requests multiplex the same DDL process, even if the current DDL request fails (for example, it does not meet the target conditions and the DDL transaction is rolled back), the DDL process may still exist. Therefore, determining whether the DDL request is active for the DDL process may have a certain situation of misjudgment. Optionally, directly determining whether the DDL transaction corresponding to the DDL request is in an active state may effectively reduce the above misjudgment situation and improve the determination accuracy.

[0074] If the data request is inactive, that is, if the data request is in an inactive state, the locking feedback information determines whether it represents a successful lock. If the locking feedback information represents a successful lock, it means that the local DDL request has already ended, but the second computing device at the distal end has successfully requested a lock on the data resource. In this case, it is necessary to instruct the second computing device to immediately release the lock corresponding to the data resource. The first computing device sends a lock release request to the message processing thread of the second computing device through the message processing thread to instruct the second computing device to release the data resource corresponding to the data request. For example, modify the memory state parameter of the lock corresponding to the data resource to the idle state. Also, if the locking feedback information represents a failed lock, it indicates that there is no need to immediately release the data resource at the distal end, and then no processing is required.

[0075] When the data request is active, that is, when the data request is in an active state, the message processing thread sends the locking feedback information to the lock request thread of the data request. The lock request thread records the received locking feedback information and determines whether it meets the target conditions based on the following step 304. As a result, the lock request thread immediately counts whether the received locking feedback information meets the target conditions corresponding to the current lock synchronization mode.

[0076] In some embodiments, after the first computing device sends a locking request to each second computing device, it starts timing. This timing counts the waiting period for each locking feedback information and sets a first waiting threshold corresponding to the strong synchronization mode and a second waiting threshold corresponding to the quasi-strong synchronization mode in the configuration file. The first waiting threshold represents the maximum waiting period for the locking feedback information of the computing device in the strong synchronization mode. When the waiting period in the strong synchronization mode exceeds the first waiting threshold, it is considered that the current locking has failed. By sending a lock release request to each second computing device for which the lock request has succeeded, the second computing device is instructed to release the data resource corresponding to the data request, and the locking flow is terminated. The first waiting threshold is a value greater than zero, for example, 15 seconds. The second waiting threshold represents the maximum waiting period for the locking feedback information of the computing device in the quasi-strong synchronization mode. When the waiting period in the quasi-strong synchronization mode exceeds the second waiting threshold, it is considered that the current locking has failed. By sending a lock release request to each second computing device for which the lock request has succeeded, the second computing device is instructed to release the data resource corresponding to the data request, and the locking flow is terminated. The second waiting threshold is a value greater than zero, for example, 10 seconds. Here, the first waiting threshold and the second waiting threshold may be the same or different, and the embodiments of the present application do not limit this.

[0077] In the above process, by arranging the first waiting threshold and the second waiting threshold and starting to time after sending a locking request, the first computing device can be avoided from waiting for the locking feedback information of other second computing devices for a long time. For example, if a packet loss situation occurs during the process of transmitting the locking feedback information, in the strong synchronization mode, the waiting period of the first computing device is at most the first waiting threshold, and in the quasi-strong synchronization mode, when the waiting period reaches the second waiting threshold, the processing of subsequent other data requests can be promoted, and the performance of the cluster database can be improved.

[0078] 304: When the obtained locking feedback information meets the target conditions corresponding to the lock synchronization mode, the first computing device locks the data resources corresponding to the data request and executes the data request.

[0079] The target conditions corresponding to the lock synchronization mode are the conditions for determining whether to lock the data resources corresponding to the data request based on the obtained locking feedback information. Generally, the target conditions corresponding to the strong synchronization mode are higher than the target condition requirements corresponding to the quasi-strong synchronization mode.

[0080] In some embodiments, if there is no timeout mechanism arranged in the cluster database, when the lock synchronization mode is the strong synchronization mode, the target condition is that the locking feedback information of all the at least one second computing device indicates successful locking, and when the lock synchronization mode is the quasi-strong synchronization mode, the target condition is that the locking feedback information of the second computing devices with a number greater than or equal to the target number among the at least one second computing device indicates successful locking.

[0081] In some embodiments, when a timeout mechanism is arranged in the cluster database, it is necessary to satisfy the above basic conditions, and it is necessary to ensure that the waiting period in the strong synchronization mode is below the first waiting threshold and the waiting period in the quasi-strong synchronization mode is below the second waiting threshold. That is, when the lock synchronization mode is the strong synchronization mode, the target condition is that the waiting period is below the first waiting threshold and the locking feedback information of all of the at least one second computing device indicates locking success. When the lock synchronization mode is the quasi-strong synchronization mode, the target condition is that the waiting period is below the second waiting threshold and the locking feedback information of more than the target number of the second computing devices among the at least one second computing device indicates locking success. Both the first waiting threshold and the second waiting threshold are numerical values greater than 0, both the first waiting threshold and the second waiting threshold can be added to the configuration file, and when the cluster database is started, they are loaded from the database engine of each computing device.

[0082] In some embodiments, the target number is indicated by the lock success probability parameter lock_succ_node_num disposed in the database engine. The lock success probability parameter lock_succ_node_num represents whether, in the quasi-strong synchronization mode, when several computing devices in the cluster database request a lock successfully, the global lock request is considered successful. Optionally, the lock success probability parameter lock_succ_node_num is a numerical value obtained by adding 1 to the target number. The target number indicates the number of the second computing devices whose lock requests are successful. When the first computing device itself is added to the target number, it is the total number of computing devices in the cluster whose lock requests are successful. The valid value range of the lock success probability parameter lock_succ_node_num is greater than or equal to 1 and less than or equal to the number of all computing devices in the cluster. If the lock success probability parameter lock_succ_node_num is less than 1 or exceeds the number of all computing devices in the cluster, the lock success probability parameter lock_succ_node_num of the cluster is not within the valid value range. In either case, by adopting the strong synchronization mode or the weak synchronization mode (set by the administrator), when the lock success probability parameter lock_succ_node_num is illegal, the normal operation of the cluster can be guaranteed. For example, the strong synchronization mode is adopted in either case.

[0083] Optionally, the lock success probability parameter lock_succ_node_num may be added to the configuration file. When the cluster database is started, the database engines of each computing device in the cluster all load the configuration file.

[0084] Optionally, when the entire cluster is operating, the lock success probability parameter lock_succ_node_num may be randomly modified by the computing device. After modifying the lock success probability parameter lock_succ_node_num, the computing device automatically synchronizes the modified lock success probability parameter lock_succ_node_num to all computing devices within the cluster.

[0085] In some embodiments, when the lock synchronization mode is the semi-strong synchronization mode, the first computing device obtains the target number. If the target number is less than 1, or exceeds the number of all second computing devices in the cluster database, the lock synchronization mode is switched to the strong synchronization mode.

[0086] In the above process, the first computing device searches for the value of the lock success probability parameter lock_succ_node_num from the configuration file, and determines the target number as the numerical value obtained by subtracting 1 from the value of the lock success probability parameter lock_succ_node_num. Further, it is determined whether the target number is legal, that is, if the target number is 1 or more and less than or equal to the number of all second computing devices in the cluster database, it means that the target number is legal. In this case, the lock synchronization mode determines the target condition according to the semi-strong synchronization mode. If the target number is less than 1, or exceeds the number of all second computing devices in the cluster database, it means that the target number is illegal. In this case, the lock synchronization mode is forcibly switched to the strong synchronization mode. In some embodiments, the lock synchronization mode may be forcibly switched to the weak synchronization mode, and the embodiments of the present application are not limited thereto.

[0087] In some other embodiments, after retrieving the value of the lock success probability parameter lock_succ_node_num from the configuration file, the first computing device determines whether the value of the lock success probability parameter lock_succ_node_num is legal. If the lock success probability parameter lock_succ_node_num is legal (i.e., greater than or equal to 1 and less than or equal to the number of all computing devices in the cluster), it indicates that the target number is also legal. If the lock success probability parameter lock_succ_node_num is illegal (i.e., less than 1 or greater than the number of all computing devices in the cluster), it indicates that the target number is also illegal, and it is necessary to forcibly switch the lock synchronization mode to a strong synchronization mode or a weak synchronization mode. In the embodiments of the present application, taking the switching of the lock synchronization mode to a strong synchronization mode as an example for explanation.

[0088] In some embodiments, if the lock synchronization mode parameter lock_level_mode ≠ Feak, it indicates that the lock synchronization mode is not a weak synchronization mode. In this case, the message processing thread sends a locking request to each second computing device and starts timing, and receives the locking feedback information returned from each second computing device by the message processing thread. Optionally, if the lock synchronization mode parameter lock_level_mode = Strong, the lock synchronization mode is determined to be a strong synchronization mode, and it is determined whether the locking feedback information of all second computing devices all indicates locking success. In this case, it is discussed in three situations: 1) If the wait has not timed out yet, that is, the wait period is below the first wait threshold and the locking feedback information of all received second computing devices all indicates locking success, it is considered that the global locking has succeeded as it meets the target conditions. 2) If the locking feedback information of any one of the received second computing devices indicates locking failure, it does not meet the target conditions and is considered that the global locking has failed. 3) When the wait period exceeds the first wait threshold and the second computing device still has not returned the locking feedback information, it indicates that the wait has already timed out, does not meet the target conditions, and is considered that the global locking has failed.

[0089] Optionally, if the lock synchronization mode parameter lock_level_mode = Middle, the lock synchronization mode is determined to be the quasi-strong synchronization mode. Read the lock success probability parameter lock_succ_node_num from the configuration file, and determine whether the lock success probability parameter lock_succ_node_num is legal. If the lock success probability parameter lock_succ_node_num is greater than or equal to 1 and less than or equal to the number of all computing devices in the cluster, that is, if the lock success probability parameter lock_succ_node_num is legal, continue to process according to the quasi-strong synchronization mode. If the lock success probability parameter lock_succ_node_num is less than 1 or exceeds the number of all computing devices in the cluster, continue to process according to the strong synchronization mode. In the quasi-strong synchronization mode, it is also divided into three situations for discussion: A) If the waiting has not timed out yet, that is, the waiting period is less than or equal to the second waiting threshold, and the received locking feedback information indicates that the number of the second computing devices that have successfully locked is greater than or equal to the target number, then it meets the target conditions and is considered that the global locking has succeeded. In another possible embodiment, if the received locking feedback information indicates that the numerical value obtained by adding 1 to the number of the second computing devices that have successfully locked is greater than or equal to the lock success probability parameter lock_succ_node_num, then similarly, it is determined that it meets the target conditions and is considered that the global locking has succeeded. B) If the received locking feedback information indicates that the number of the second computing devices that have failed to lock exceeds the numerical value obtained by subtracting the target number from the number of all second computing devices in the cluster, then it does not meet the target conditions and is considered that the global locking has failed.In another possible embodiment, if the received locking feedback information indicates that the numerical value obtained by adding 1 to the number of second computing devices for which the locking has failed exceeds the numerical value obtained by subtracting the lock success probability parameter lock_succ_node_num from all the computing devices in the cluster, then similarly, it is determined that the target condition is not met and the global locking is considered to have failed. C) Even when the waiting period exceeds the second waiting threshold and many second computing devices still have not returned the locking feedback information and neither situation A) nor situation B) is satisfied, it indicates that the waiting has already timed out. In this case, it is considered that the target condition is not met and the global locking has failed.

[0090] In some embodiments, when it is determined that the obtained locking feedback information meets the target condition, an operation similar to step 302 above is performed, that is, the data resource corresponding to the data request is locked and the data request is executed, which will not be elaborated here.

[0091] In some embodiments, when it is determined that the obtained locking feedback information does not meet the target condition or the data request has been completed, a lock release request is sent to the at least one second computing device, and the lock release request instructs the second computing device to release the data resource corresponding to the data request.

[0092] In the above process, if the obtained locking feedback information does not meet the target conditions, global locking fails. However, there is also a possibility that the current data request has already successfully requested locks on several second node devices. Therefore, the first computing device immediately sends a lock release request to each second computing device for which the locking feedback information indicates successful locking, thereby immediately releasing the lock corresponding to the data resource. Optionally, directly broadcast the lock release request to all second computing devices. The second computing device for which locking is successful releases the lock corresponding to the data resource, while the second computing device for which locking fails does not perform any processing.

[0093] Optionally, the first computing device does not need to wait until each second computing device returns lock release feedback information, which is guaranteed by the alive and dead monitoring mechanism in the following embodiments, improving the system's request processing efficiency. Of course, after each second computing device returns the lock release feedback information, the first computing device completes the locking flow, and may immediately detect whether some second computing devices have not received the lock release request due to network packet loss. The embodiments of the present application do not limit this. In another scenario, if the obtained locking feedback information meets the target conditions, after the first computing device successfully performs global locking and executes a data request, such as a DDL request, it similarly notifies each other second computing device to immediately release the lock corresponding to the data resource. Since the transmission method of the lock release request is similar to the above situation, it will not be elaborated here.

[0094] For all the above preferred technical solutions, any combination can be adopted to form a preferred embodiment of the present disclosure, and details will not be elaborated here.

[0095] According to the method provided by the embodiment of the present application, a plurality of levels flexible for the lock synchronization mode are set up. In the weak synchronization mode, the data resource corresponding to the data request is directly locked to execute the data request, which can ensure that the data request is preferentially promoted, without the need to wait for the response of the second computing device. In the non-weak synchronization mode, the locking feedback information of each second computing device is obtained, and the data resource is locked to execute the data request only when the obtained locking feedback information meets the target conditions. Different lock synchronization modes are selected in different traffic scenarios to ensure that the cluster database meets the processing needs of different traffic scenarios, thereby improving the processing capacity of the cluster database system.

[0096] In the above embodiment, during the request processing process, how the first computing device starts the locking request and determines whether it meets the target conditions based on the locking feedback information is introduced. In the embodiment of the present application, the message interaction during the locking process of the first computing device and the second computing device, as well as their respective local locking logics, are described in detail.

[0097] FIG. 4 is an interaction flowchart of the request processing method provided by the embodiment of the present application. As shown in FIG. 4, this embodiment is applied to a cluster database, which includes a first computing device and at least one second computing device. The first computing device is the computing device that processes the data request. All computing devices in the cluster except the first computing device are called second computing devices. This embodiment includes the following steps: 401: The application client sends a data request to the first computing device in the cluster database.

[0098] Optionally, the cluster database is a central cluster database or a distributed cluster database, both of which are applicable to the claim processing method. The embodiments of the present application will be described by taking the distributed cluster database as an example.

[0099] In some embodiments, the user logs in to the application client on the terminal and triggers the application client to generate the data request. Optionally, the data request is a DDL request or a DML request. In the embodiments of the present application, the case where the data request is a DDL request will be described as an example. For example, the DDL request modifies the table name of data table A. After generating the data request, the application client calls an API to send the data request to the first computing device.

[0100] 402: In response to the data request, the first computing device determines the lock synchronization mode of the cluster database.

[0101] Since step 402 above is similar to step 301 above, no further elaboration will be provided here.

[0102] 403: If the lock synchronization mode is a weak synchronization mode, the first computing device locks the data resource corresponding to the data request and executes the data request.

[0103] Since step 403 above is similar to step 302 above, no further elaboration will be provided here.

[0104] 404: If the lock synchronization mode is not a weak synchronization mode, the first computing device sends a locking request associated with the data request to at least one second computing device in the cluster database.

[0105] If the lock synchronization mode is not a weak synchronization mode, it may be a strong synchronization mode or a quasi-strong synchronization mode. In the above strong synchronization mode or quasi-strong synchronization mode, each first computing device needs to request a lock from each distal second computing device. The target conditions for determining the success of the lock request for both are different. In the strong synchronization mode, the global lock request for the data resource is considered successful only when all second computing devices have successfully requested a lock. In the quasi-strong synchronization mode, if more than the target number of second computing devices successfully request a lock, the global lock request for the data resource is considered successful.

[0106] In some embodiments, the first computing device requests a lock from each second computing device to obtain the locking feedback information of each second computing device. Optionally, the locking feedback information includes locking success and locking failure. Usually, the causes of locking failure are diverse. For example, the waiting times out and a deadlock is reached.

[0107] Optionally, in the first computing device and each second computing device, a message processing thread is established in the background. The message processing thread specifically processes various messages related to the lock mechanism, such as monitoring locking requests, unlocking requests, locking feedback information, unlocking feedback information, etc. from other computing devices, and immediately sending and receiving various messages related to the lock mechanism to ensure the communication performance between computing devices.

[0108] Based on the above situation, when sending a locking request, the first computing device sends the locking request to the message processing thread on at least one second computing device through its message processing thread.

[0109] 405: In response to a locking request associated with the data request, add the locking request to a locking queue for any one of the second computing devices.

[0110] Note that when the lock synchronization mode is not a weak synchronization mode, the locking request is sent by the first node device in the cluster database.

[0111] In some embodiments, the second computing device receives the locking request by a message processing thread, starts a lock proxy thread corresponding to the locking request by the message processing thread, and adds the locking request to the locking queue by the lock proxy thread. Optionally, each locking request corresponds to one lock proxy thread to reduce the waiting latency of each locking request. Optionally, multiple locking requests multiplex the same lock proxy thread, and the later-arriving locking requests are stored in the locking queue, and the lock proxy thread processes each locking request stored in the locking queue in order.

[0112] In the above process, in both the first computing device and the second computing device, a message processing thread for sending and receiving lock-related messages is arranged. In the process of a lock request, the lock proxy thread is started by the message processing thread to maintain the life cycle of the distal lock on each second computing device. Also, when the locking feedback information of the second computing device reaches the first computing device, there may be a situation where the lock request thread on the first computing device has already ended. In this case, because the message processing thread is arranged, the message processing thread of the first computing device determines whether the current data request is active through the operation of step 408 below, and determines whether the locking feedback information indicates locking success. When the data request is inactive, an unlock request is immediately sent back to the second computing device that has successfully locked, and a trigger is issued to unlock the lock for which the distal request has succeeded, thereby achieving the purpose of not blocking the traffic on the second computing device.

[0113] 406: The second computing device processes the locking request in the locking queue, obtains locking feedback information, and the locking feedback information indicates whether the locking of the second computing device to the data resource has succeeded.

[0114] In some embodiments, the second computing device invokes the local lock request logic to start a local lock proxy thread to process each locking request cached in the locking queue. The lock proxy thread traverses the locking queue. If it locks the data resource corresponding to the data request sent from the first computing device this time, it indicates that the processing of the locking request is completed, determines the locking feedback information as a locking success. Otherwise, it continues to wait in the locking queue until a timeout or a deadlock occurs, and determines the locking feedback information as a locking failure, that is, when the waiting period of the locking request in the locking queue exceeds the third waiting threshold or the deadlock detection fails, the locking feedback information is determined as a locking failure. The third waiting threshold is any value greater than 0, for example, 5 seconds. The third waiting threshold may be added to the configuration file and loaded by the database engine of each computing device when the cluster database is started.

[0115] As can be seen from the above process, there are at least two situations where the locking fails: a) If the waiting times out, that is, when the cache period of the locking request in the locking queue exceeds the third waiting threshold, the locking is considered to have failed. b) If the deadlock detection fails, it explains that a deadlock is found from the deadlock detection and the second computing device itself is selected as the deadlock victim, and then the lock request cannot be completed.

[0116] In some embodiments, the deadlock detection flow of the second computing device is as follows. In response to the deadlock detection message of the first computing device, the second computing device performs local deadlock detection on the locking request. If the local deadlock detection fails, it is determined that the deadlock detection fails. If the local deadlock detection passes, the lock waiting link of the locking request is determined. The lock waiting link includes lock information having a dependency relationship with the locking request. If the lock waiting link includes a distal lock, a deadlock detection message is sent to a third computing device that issues the distal lock. The distal lock is lock information registered in the second computing device, but not lock information issued by the second computing device. If any computing device that sends the deadlock detection message receives the deadlock detection message again, it is determined that the deadlock detection fails.

[0117] Optionally, the deadlock detection message may be sent from the first computing device. For example, even if the first computing device has not received the locking feedback information of the second computing device for a long time but the waiting has not timed out yet, the message processing thread of the first computing device will send a deadlock detection message to the message processing thread of the second computing device. When receiving the deadlock detection message, the second computing device first detects a local deadlock. If the local deadlock detection fails, there is no need to traverse the lock wait link, and directly return the locking feedback information to the first computing device. The locking feedback information indicates a locking failure, and the failure type is that it is selected as the deadlock victim itself. If the local deadlock detection passes, but in this case, it cannot be fully ensured that there is no deadlock, so traverse the corresponding lock wait link, determine for each lock on the lock wait link whether it is a distal lock. If it is a distal lock, send a deadlock detection message to the lock owner side of the distal lock (i.e., the third computing device) to trigger the third computing device to execute a similar deadlock detection flow as the second computing device, that is, the third computing device first detects a local deadlock and then traverses the distal lock on the lock wait link to send the deadlock detection message again. When any computing device itself is the sender of the deadlock detection message and receives the same deadlock detection message sent from another computing device, it indicates that a deadlock has been reached. Then, the computing device returns the locking feedback information to the first computing device. The locking feedback information indicates a locking failure, and the failure type is that it is selected as the deadlock victim itself.For example, the first computing device sends a deadlock detection message to the second computing device. If there is a distal lock in the lock wait link in the second computing device and the lock owner side of the distal lock is the first computing device, then the second computing device sends a deadlock detection message to the first computing device. In this case, a dependency loop phenomenon appears, that is, lock A waits for lock B and lock B waits for lock A. That is, when the first computing device, as the sender of the deadlock detection message, receives the same deadlock detection message sent from the second computing device, it discovers a deadlock, explaining that the current locking has failed.

[0118] In some embodiments, when the locking of the second computing device is successful and the data resource corresponding to the data request is locked, in the message processing thread, the lock proxy thread of the second computing device registers the lock information corresponding to the data request, and for each target period, determines whether the already registered lock information is active lock information. If the lock information is active lock information and the locking period of the data resource corresponding to the data request exceeds the survival monitoring threshold, a survival monitoring request is sent to the first computing device, and the survival monitoring request requests the first computing device to indicate whether to release the data resource locked by the active lock information. The survival monitoring threshold is any value greater than 0, for example, 20 seconds.

[0119] In the above process, if the locking is successful, the lock proxy thread registers the corresponding lock information in the message processing thread, so that the message processing thread can conveniently manage each lock for which the local request has been successful. The message processing thread can periodically check the active lock information in the registry. Even if the active lock information has not been released when the survival monitoring threshold is exceeded, for example, there are several possibilities as follows: i) The execution of the data request of the first computing device is completed, but the sent unlock request has packet loss. ii) The lock request thread of the first computing device crashes. iii) The first computing device processes normally, but the time taken for this data request, for example, the DDL transaction itself, is long. In the case of the above situations i) and ii), by sending a survival monitoring request, the first computing device is triggered to resend the unlock message, and the second computing device is instructed to release the corresponding lock. In the case of the above situation iii), the second computing device cannot release the corresponding lock and still continuously holds the corresponding lock.

[0120] 407: The second computing device sends the locking feedback information to the first computing device.

[0121] In some embodiments, the message processing thread of the second computing device sends the locking feedback information to the message processing thread of the first computing device.

[0122] In the above steps 405 - 407, taking a single second computing device as an example, the request flow of the distal lock is introduced. Each second computing device in the cluster can perform operations similar to steps 405 - 407, which will not be elaborated here.

[0123] 408: The first computing device receives the locking feedback information returned from the at least one second computing device based on the locking request.

[0124] Optionally, when receiving the locking feedback information, the first computing device receives, by its message processing thread, the locking feedback information returned from the message processing thread on the at least one second computing device.

[0125] In some embodiments, the first computing device sends the locking request to each second computing device in the cluster respectively, and the time for the locking feedback information of each second computing device to return to the first computing device may be different. In some exemplary scenarios, when the processing process of the data request (e.g., DDL process) crashes on the first computing device, after the DDL process crashes, for the received locking feedback information, the first computing device immediately instructs the second computing device with successful locking to release the corresponding lock according to the situation, so as to avoid blocking other DML processes on the data resource and optimize the processing performance of the cluster database.

[0126] In response to receiving the locking feedback information of any second computing device for the above situation, when the data request is in an active state, the first computing device sends the locking feedback information to the lock request thread of the data request by its message processing thread. When the data request is in an inactive state and the locking feedback information indicates successful locking, the first computing device sends a lock release request to the second computing device, and the lock release request instructs the second computing device to release the data resource corresponding to the data request.

[0127] Optionally, after receiving any locking feedback information by the message processing thread, the first computing device determines whether the local data request is active, taking the DDL request as an example, determines whether there is a DDL process corresponding to the DDL request. Since there may be a situation where multiple DDL requests multiplex the same DDL process, even if the current DDL request fails (for example, it does not meet the target conditions and the DDL transaction is rolled back), the DDL process may still exist. Therefore, determining whether the DDL request is active for the DDL process may have a certain situation of misjudgment. Optionally, directly, it may also be determined whether the DDL transaction corresponding to the DDL request is in an active state, thereby effectively reducing the above misjudgment situation and improving the determination accuracy.

[0128] When it is determined that the data request is inactive, that is, when the data request is in an inactive state, it is determined whether the locking feedback information indicates successful locking. If the locking feedback information indicates successful locking, it means that the local DDL request has already ended, but the second computing device at the distal end has successfully requested a lock on the data resource. In this case, it is necessary to instruct the second computing device to immediately release the lock corresponding to the data resource. Therefore, the first computing device sends a lock release request to the message processing thread of the second computing device through the message processing thread to instruct the second computing device to release the data resource corresponding to the data request. For example, the memory state parameter of the lock corresponding to the data resource is modified to the idle state. Also, if the locking feedback information indicates a locking failure, it indicates that there is no data resource that needs to be immediately released at the distal end, and then no processing is required.

[0129] When the data request is active, that is, when the data request is in an active state, the message processing thread sends the locking feedback information to the lock request thread of the data request, and the lock request thread records the received locking feedback information and determines whether it meets the target conditions based on the following step 409. As a result, the lock request thread immediately counts whether the received locking feedback information meets the target conditions corresponding to the current lock synchronization mode.

[0130] In the above steps 404 to 408, it shows how the first computing device obtains the locking feedback information of at least one second computing device in the cluster database for the data resource. In some embodiments, the first computing device may further directly send the locking request in a broadcast or multicast manner in the cluster database and receive the locking feedback information returned from each second computing device, or without arranging a dedicated message processing thread, directly communicate through both the lock request thread on the first computing device and the lock proxy thread on the second computing device, thereby reducing the communication overhead between threads.

[0131] 409: If the obtained locking feedback information meets the target conditions corresponding to the lock synchronization mode, the first computing device locks the data resource corresponding to the data request and executes the data request.

[0132] Since the above step 409 is similar to the above step 304, no redundant description is given here.

[0133] 410: If the obtained locking feedback information does not meet the target conditions or the execution of the data request is completed, the first computing device sends a unlock request to the at least one second computing device.

[0134] The unlock request instructs the second computing device to release the data resource corresponding to the data request.

[0135] Optionally, the message processing thread of the first computing device sends an unlock request to the message processing thread of each second computing device. Since the process of sending the unlock request is the same as the process of sending the locking request, it will not be elaborated here.

[0136] 411: In response to the unlock request associated with the data request for any one of the second computing devices, the data resource corresponding to the data request is released.

[0137] Optionally, the message processing thread of the second computing device receives the unlock request and notifies the lock proxy thread to release the corresponding data resource. For example, the lock proxy thread modifies the memory state parameter of the lock to the idle state and removes the corresponding lock information in the registry. In this way, if the message processing is completed and each received message is discarded, memory space can be saved.

[0138] For all the above preferred technical solutions, any combination can be adopted to form a preferred embodiment of the present disclosure, which will not be elaborated here.

[0139] According to the method provided by the embodiments of the present application, a plurality of levels flexible for the lock synchronization mode are set. In the weak synchronization mode, the data resource corresponding to the data request is directly locked to execute the data request, and it is guaranteed to preferentially promote the data request, without the need to wait for the response of the second computing device. In the non-weak synchronization mode, the locking feedback information of each second computing device is obtained, and the data resource is locked and the data request is executed only when the obtained locking feedback information meets the target conditions. Different lock synchronization modes are selected in different traffic scenarios to ensure that the cluster database meets the processing needs of different traffic scenarios and improve the processing capacity of the cluster database system.

[0140] FIG. 5 is a schematic diagram of the principle of the locking flow provided by the embodiments of the present application. As shown in 500, the cluster database includes a computing node 1 and a computing node 2. The computing node 1 is a first computing device, and a lock request thread and a message processing thread are executed on the computing node 1. The computing node 2 is a second computing device, and a message processing thread and a lock proxy thread are executed on the computing node 2. Taking the data request as a DDL request as an example, after the lock request thread of the computing node 1 successfully requests a lock locally, it proceeds to the global locking flow. The global locking flow is described in detail below: Step 1: After completing the local lock request, proceed to the locking flow. Step 2: The lock request thread of the computing node 1 determines whether it is in the weak synchronization mode. If it is in the weak synchronization mode, there is no need to send a locking request to other nodes, and it is considered that the lock is directly obtained (the accuracy is guaranteed by the write barrier mechanism), and jump to step 28. If it is not in the weak synchronization mode, proceed to step 3. Step 3: If it is not in the weak synchronization mode, send a locking request to other nodes, proceed to Step 4, and proceed to Step 26 to start timing. Step 4: The message processing thread of Computing Node 2 receives the locking request. Note that the message processing thread specifically monitors the locking requests, unlocking requests, and locking feedback information of other nodes in the background, and sends and receives various types of lock-related messages. In the locking request stage, as the message receiving side, the message processing thread calls the lock proxy thread to maintain the life cycle of the distal lock on Computing Node 2. In the stage of returning the locking feedback information, when the locking feedback information reaches the requesting side (Computing Node 1), the lock request thread on the requesting side may have already crashed or ended. If so, the message processing thread on Computing Node 1 determines whether the lock request thread has ended and whether the locking feedback information indicates a successful lock, and then sends an unlocking request to Computing Node 2 to determine whether to release the distal lock for which the distal request was successful. Step 5: Computing Node 2 starts a local lock proxy thread and calls the local lock request logic. Step 6: Determine whether the lock request corresponding to the DDL request has succeeded. If the request has succeeded, proceed to Step 8. If the request has not succeeded, it includes the following situations. 6.1) The locking request is still located in the locking queue, waiting in line. In this case, continue to wait, proceed to Step 7, and determine whether a timeout has occurred. 6.2) Discover a deadlock from deadlock detection and itself is selected as the deadlock victim, and proceed to Step 8. Step 7: Determine whether the distal lock request has timed out. If it has not timed out, continue to wait. If it has timed out, proceed to Step 8. For example, when determining whether a timeout has occurred, it is determined whether the waiting period has exceeded a third waiting threshold value. Step 8: Send locking feedback information to the message processing thread of computing node 1 and proceed to step 10.

[0141] Optionally, the locking feedback information can be divided into three categories: locking success, lock waiting timeout, and deadlock victim.

[0142] Optionally, the locking feedback information can be divided into two categories: locking success and locking failure. Locking failure includes lock waiting timeout and deadlock victim.

[0143] Step 9: Feedback the message of the message processing thread of computing node 2 to the interface. Here, mainly process the life and death monitoring requirements by the life and death monitoring mechanism in steps 10 to 13, and send the life and death monitoring requirements to the message processing thread of computing node 1.

[0144] The life and death monitoring requirement corresponds to a situation where the lock request thread of the lock request side (computing node 1) in a distributed environment has already ended, but the remote lock of computing node 2 has not been released all the time. If the remote lock is still not released even after exceeding a certain period (for example, the life and death monitoring threshold value), send the life and death monitoring requirement to the lock request side, that is, the lock owner, to perform life and death monitoring.

[0145] Step 10: The lock proxy thread of computing node 2 registers the lock information and lock status of all remote locks with the message processing thread.

[0146] The lock information includes, but is not limited to, a lock type (such as a read lock, a write lock, an update lock, etc.), a data resource to be locked (such as a database name, a data table name, a data index ID, a data column name, etc.), a locking time, and the like.

[0147] The lock state includes, but is not limited to, an active state, an inactive state, and the like.

[0148] Step 11: The message processing thread of computing node 2 periodically checks the active locks among the respective remote locks in the registry.

[0149] For example, traverse each lock information in the registry to search for a remote lock in the active state.

[0150] Step 12: Determine whether there is a remote active lock that exceeds the alive / dead monitoring threshold. If YES, proceed to Step 13; if NO, continuously and periodically monitor the lock information in the registry.

[0151] Step 13: Prepare to feedback the alive / dead monitoring request and proceed to Step 9.

[0152] Step 14: The message processing thread of computing node 1 receives the locking feedback information and the alive / dead monitoring request.

[0153] Step 15: Determine whether the local lock request thread is active. If YES, proceed to Step 16; if NO, proceed to Step 21.

[0154] When it is active, it can be divided into three situations: 15.1) If the current lock request thread is active and located on the lock request staircase, update the corresponding lock request structure data and send it to the lock request thread for processing. 15.2) In the quasi-strong synchronization mode, if the current lock request thread reaches the target condition for successful lock request, update the corresponding lock request structure data to complete the operation. 15.3) If the current lock request thread has ended the lock or the lock request has failed and ended (for example, in the quasi-strong synchronization mode, it is determined that the target condition is not met), update the corresponding lock request structure data to complete the operation.

[0155] Optionally, the lock request structure data records the locking feedback information of each computing node 2, and adopts forms such as a hash table, an array, a set, a vector, etc. For example, if the set form is adopted, each element in the set indicates whether the locking of a computing node is successful or failed. If the element is 0, it indicates that the locking has failed. If the element is 1, it indicates that the locking has been successful. If the element is null, it indicates that the locking feedback information has not been received yet.

[0156] Step 16: In this case, if the locking feedback information indicates successful locking or a liveness monitoring request is received, proceed to Step 17; otherwise, do no processing and proceed to Step 32, that is, the message processing is completed and the received message is discarded.

[0157] Step 17: The message processing thread of computing node 1 sends a lock release request to the message processing thread of computing node 2.

[0158] Step 18: The message processing thread of computing node 2 receives the lock release request.

[0159] Step 19: The message processing thread of computing node 2 notifies the lock proxy thread to release the lock.

[0160] Step 20: The lock proxy thread of computing node 2 releases the lock.

[0161] Step 21: The lock request thread of computing node 1 receives the locking feedback information sent from the message processing thread. Here, it includes some locking feedback information related to Step 8.

[0162] Step 22: Determine the current lock synchronization mode. If it is the strong synchronization mode, proceed to Step 25; if it is the quasi-strong synchronization mode, proceed to Step 23.

[0163] Step 23: Check whether the lock success probability parameter lock_succ_node_num is set to a valid value (i.e., greater than or equal to 1 and less than or equal to the number of all computing devices in the cluster). If it is a valid value, proceed to Step 24 according to the quasi-strong synchronization mode; if it is not a valid value, proceed to Step 25 according to the strong synchronization mode.

[0164] Step 24: Determine whether the number of local nodes added to the distal nodes that have fed back locking success exceeds the lock success probability parameter lock_succ_node_num. If YES, proceed to Step 28; if NO, determine whether the lock request has timed out, i.e., whether the waiting period exceeds the second waiting threshold. If it has not timed out yet, continue to wait. If it has timed out, the locking fails. If the number of distal nodes that have fed back locking failure exceeds the value obtained by subtracting the lock success probability parameter lock_succ_node_num from the total number of nodes in the cluster, it is determined that the locking has failed, and proceed to Step 29.

[0165] Step 25: In the strong synchronization mode, determine whether all nodes have fed back successful locking. If the above conditions are met, proceed to Step 28. If the conditions are not met but the timeout has not occurred yet, that is, the waiting period has not exceeded the first waiting threshold, continue to wait. If any one node feeds back a locking failure, it is determined that the locking has failed, and proceed to Step 29.

[0166] Step 26: Start calculating the lock request time.

[0167] Step 27: Determine whether the lock request time has timed out. If YES, proceed to Step 29, that is, the locking has failed. If NO, continue to return to Step 21 to check the logic.

[0168] Optionally, in the strong synchronization mode, the timeout threshold is the first waiting threshold. In the semi-strong synchronization mode, the timeout threshold is the second waiting threshold. Their values may be the same or different.

[0169] Step 28: Global locking is successful.

[0170] Step 29: Global locking fails.

[0171] Step 30: Send a lock release request to all other nodes.

[0172] Optionally, since there is a life and death monitoring logic in Steps 11 - 20 for other nodes, after sending the lock release request, Computing Node 1 does not need to wait until other nodes return lock release feedback information and can end the flow.

[0173] Step 31: Complete the locking flow.

[0174] Step 32: After the message processing is completed, the message can be discarded.

[0175] In the embodiments of the present application, the locking flow is introduced in detail. In a distributed database, by implementing a flexible locking mechanism, the accuracy of operations can be ensured when each process or thread modifies a certain data resource. Also, by implementing such a flexible locking mechanism, flexible switching can be realized in the weak synchronization mode, quasi-strong synchronization mode, and strong synchronization mode. The distributed database cluster can select different levels of locking mechanisms according to the needs of its own database application scenarios to meet the traffic needs in different traffic scenarios of users.

[0176] FIG. 6 is a schematic diagram of the principle of the unlocking flow provided by the embodiments of the present application. As shown in 600, the cluster database includes a computing node 1 and a computing node 2. The computing node 1 is a first computing device, and the computing node 2 is a second computing device. A message processing thread and a lock proxy thread are executed in the computing node 2. After the global locking of the computing node 1 is successful, the corresponding data request, such as a DDL request, is executed. After the local DDL transaction processing logic is completed, the unlocking flow is entered. The unlocking flow is described in detail below: Step 1: After the local processing logic of the DDL transaction is completed, enter the unlocking flow. After the computing node 1 with the lock completes the computing logic of the DDL transaction, the lock is released globally. In the embodiments of the present application, taking the order of releasing the remote lock first and then the local lock as an example, the global unlocking flow is introduced. In this case, the overall process of locking and unlocking is as follows: local locking → remote locking → remote unlocking → local unlocking. Step 2: Determine whether it is in the weak synchronization mode. If it is in the weak synchronization mode, proceed to Step 10, where there is no need to release the distal lock. If it is not in the weak synchronization mode, proceed to Step 3. Step 3: Send a lock release request to other nodes. Step 4: The message processing thread of Computing Node 2 receives the lock release request. Step 5: The message processing thread starts the lock proxy thread to release the corresponding local distal lock. For example, if the lock proxy thread is in a suspended state, the message processing thread wakes up the lock proxy thread to perform the lock release operation. Step 6: The lock proxy thread releases the corresponding local distal lock. If the release is successful, proceed to Step 7. If the release fails, release it again. Step 7: Prepare to clean the corresponding lock information in the registry. Step 8: Clean the registered lock information in the registry. Step 9: The lock proxy thread ends. Step 10: The lock release is successful. Step 11: The lock release flow ends.

[0177] In the embodiments of the present application, after the execution of the DDL request is completed, how to perform the lock release flow is introduced in detail. Here, the liveness monitoring mechanism triggers a lock release flow similar to the embodiments of the present application when it detects that the DDL thread has crashed or does not meet the target conditions in the lock synchronization mode, so no further elaboration is provided here.

[0178] Figure 7 is a schematic diagram of the principle of the deadlock detection flow provided by the embodiments of the present application. As shown in 700, the cluster database includes computing node 1 and computing node 2. Computing node 1 is the first computing device, and computing node 2 is the second computing device. A message processing thread is executed on computing node 2. The deadlock detection flow is described below: Step 1: Computing node 1 intends to lock data resource A. Step 2: Send a deadlock detection message to other nodes and proceed to Step 3 and Step 10. Step 3: The message processing thread of computing node 2 receives the deadlock detection message. For example, the deadlock detection message includes relevant lock information. Step 4: Use the local deadlock detection logic to perform local deadlock detection. If the deadlock detection passes, proceed to Step 5. If the deadlock detection fails, return a message indicating that itself has been selected as the deadlock victim. Step 5: Traverse the lock wait link. Step 6: Determine whether the current lock in the lock wait link is a distal lock. If yes, proceed to Step 7. If no, traverse the next lock on the lock wait link. Step 7: Send a deadlock detection message to the lock owner. In the embodiments of the present application, taking the lock owner being computing node 1 as an example for explanation. Step 8: Receive the deadlock detection message. Step 9: When it is discovered that the deadlock detection message forms a closed loop, a deadlock occurs. Step 10: Register the lock information in the local message processing thread.

[0179] In the embodiments of the present application, while performing local deadlock detection logic, a distributed database is arranged. When traversing the lock wait link, it is determined whether it is a distal lock. If the answer is NO, it can be discovered from the local deadlock detection logic whether a deadlock has occurred. If the answer is YES, a deadlock detection message is sent to the lock owner (i.e., the computing node where the lock-owning thread is located). If the computing node owning the lock node is the same node as the computing node that starts deadlock detection, a closed loop is formed, that is, it indicates that a deadlock has occurred. For example, in the embodiments of the present application, computing node 1 waits for computing node 2, and computing node 2 waits for computing node 1, forming a closed loop. When a deadlock occurs, the current lock request operation is rejected. In this case, after a certain period of time, the database engine automatically retries, or rejects returning a message to the user. The user waits for a while and then actively starts a retry.

[0180] Each of the above embodiments details the locking flow, unlocking flow, and deadlock detection flow in a distributed database. In the embodiments of the present application, the expressions in abnormal scenarios of the lock synchronization mechanism are analyzed in detail, and it is explained how the above lock synchronization mechanism copes with abnormal scenarios such as partitioning of the computing node network, network instability, network delay, or network packet loss in a distributed scenario.

[0181] When the administrator selects the weak synchronization mode, the weak synchronization mode does not need to request a lock distally, and the accuracy of resource operations is guaranteed by the write barrier mechanism. Therefore, it has a high priority for DDL transactions that require lock requests. As the DDL transaction progresses, the user's DML transaction may be rolled back. Generally, the DML transaction is the main traffic of the user. Therefore, in some scenarios, the user experience is poor, but it is applicable to application scenarios with many DDL transactions.

[0182] When the administrator selects the strong synchronization mode, it can ensure that DDL transactions and DML transactions are treated equally. However, when the network situation is poor, the DDL transaction needs to request a global lock. Therefore, all other nodes in the cluster have to wait until they return the locking feedback information. Due to partition or network delay, one or some nodes do not return the locking feedback information immediately. During this waiting period, other nodes in the entire distributed cluster reject the execution of the DML transaction due to the success of lock granting. As a result, the response speed of the entire cluster becomes slow, and the user experience is that the entire cluster cannot provide services. Therefore, when the network situation is poor, the user experience of the strong synchronization mode is also poor.

[0183] When the administrator selects the semi-strong synchronization mode, a compromise choice is provided, that is, a flexible and installable cluster operation mode is provided between the impact caused by the above distributed system network problem and the high need for the success of the user's traffic execution. The semi-strong synchronization mode sets the lock success probability parameter lock_succ_node_num to determine the number of nodes that need to be returned in order to determine that the global lock request is successful. If lock_succ_node_num = 0, it corresponds to the weak synchronization mode. If lock_succ_node_num = n, where n is the number of nodes in the cluster, that is, the total number of computing devices, it corresponds to the strong synchronization mode. If 0 < lock_succ_node_num < n, it is the semi-strong synchronization mode.

[0184] By providing the lock success probability parameter lock_succ_node_num, the administrator can set a reasonable value based on the network situation of its own cluster to ensure the most equitable treatment between user DML transactions and DDL transactions, and also ensure that the entire cluster does not become invalid due to one or more nodes not responding, for example, it will not hang.

[0185] In addition, steps 10-20 in the above locking flow further provide a survival monitoring mechanism. When the lock owner of a lock does not send a lock release request to other nodes for some reason, the remote node ensures that it actively performs survival monitoring through the survival monitoring mechanism to release the remote lock.

[0186] In the embodiments of the present application, by providing a flexible locking mechanism, a flexible adjustment method for determining the lock synchronization mode is provided to the administrator based on the network environment in which the distributed database cluster is executed and the requirements for the DML transaction success rate. Users can make the most of the computing power of the distributed cluster, and during the execution process, the overall representation of each node of the distributed cluster to the outside is consistent with the representation of a single-node database system.

[0187] FIG. 8 is a schematic structural diagram of a request processing apparatus provided by an embodiment of the present application. Referring to FIG. 8, the apparatus includes: a determination module 801 that determines a lock synchronization mode of a cluster database in response to a data request; a locking execution module 802 that locks a data resource corresponding to the data request and executes the data request when the lock synchronization mode is a weak synchronization mode; a first acquisition module 803 that acquires locking feedback information of at least one second computing device in the cluster database with respect to the data resource when the lock synchronization mode is not a weak synchronization mode, where the locking feedback information is for indicating whether the locking of the data resource by the second computing device is successful. The locking execution module 802 further locks the data resource corresponding to the data request and executes the data request when the acquired locking feedback information meets target conditions corresponding to the lock synchronization mode.

[0188] According to the apparatus provided by the embodiment of the present application, a plurality of flexible levels are set for the lock synchronization mode. In the weak synchronization mode, the data resource corresponding to the data request can be directly locked to execute the data request, which can guarantee the priority promotion of the data request and eliminate the need to wait for the response of the second computing device. In the non-weak synchronization mode, the locking feedback information of each second computing device is acquired, and when the acquired locking feedback information meets the target conditions, the data resource is locked and the data request is executed. Different lock synchronization modes can be selected in different traffic scenarios to ensure that the cluster database can meet the processing needs of different traffic scenarios, thereby improving the processing capacity of the cluster database system.

[0189] In a possible embodiment, based on the device structure of FIG. 8, the first acquisition module 803 includes a transmission unit that transmits a locking request associated with the data request to the at least one second computing device, and a reception unit that receives the locking feedback information returned based on the locking request from the at least one second computing device.

[0190] In a possible embodiment, the transmission unit transmits the locking request to a message processing thread on the at least one second computing device by a message processing thread on the first computing device, and the reception unit receives the locking feedback information returned by a message processing thread on the at least one second computing device by a message processing thread on the first computing device.

[0191] In a possible embodiment, based on the device structure of FIG. 8, the device further includes a transmission module that, in response to receiving the locking feedback information of any one of the second computing devices, when the data request is in an active state, transmits the locking feedback information to a lock request thread of the data request by the message processing thread, and when the data request is in an inactive state and the locking feedback information indicates successful locking, the transmission module further transmits a lock release request to the second computing device, and the lock release request instructs the second computing device to release the data resource corresponding to the data request.

[0192] In a possible embodiment, when the lock synchronization mode is a strong synchronization mode, the target condition is that all the locking feedback information of the at least one second computing device indicates successful locking. When the lock synchronization mode is a semi-strong synchronization mode, the target condition is that the locking feedback information of at least the target number or more of the second computing devices among the at least one second computing device indicates successful locking.

[0193] In a possible embodiment, when the lock synchronization mode is a strong synchronization mode, the target condition is that the waiting period is below a first waiting threshold and all the locking feedback information of the at least one second computing device indicates successful locking. When the lock synchronization mode is a semi-strong synchronization mode, the target condition is that the waiting period is below a second waiting threshold and the locking feedback information of at least the target number or more of the second computing devices among the at least one second computing device indicates successful locking.

[0194] In a possible embodiment, based on the device structure of FIG. 8, the device When the lock synchronization mode is a semi-strong synchronization mode, a second acquisition module for acquiring the target number, And a switching module for switching the lock synchronization mode to the strong synchronization mode when the target number is less than 1 or exceeds the number of all second computing devices in the cluster database.

[0195] In a possible embodiment, based on the device structure of FIG. 8, the device A transmission module that, when the obtained locking feedback information does not meet the target condition or the execution of the data request is completed, sends a lock release request to the at least one second computing device, the lock release request being to the second computing device so as to release the data resource corresponding to the data request. The transmission module further includes an instruction to the second computing device.

[0196] In a possible embodiment, the data request is a data definition language (DDL) request.

[0197] For all of the above preferred technical solutions, any combination can be adopted to form a preferred embodiment of the present disclosure, which will not be elaborated here.

[0198] Here, when the request processing device provided by the above embodiment processes a data request, examples are given for the partitioning of each of the above function modules. However, in actual applications, based on needs, the above functions are allocated to be completed by different function modules, that is, the internal structure of the computing device is partitioned into different function modules to complete all or some of the functions described above. In addition, since the request processing device provided by the above embodiment belongs to the same concept as the embodiment of the request processing method, for the specific implementation process, reference may be made to the embodiment of the request processing method, which will not be elaborated here.

[0199] FIG. 9 is a schematic structural diagram of a request processing device provided by an embodiment of the present application. Referring to FIG. 9, the device includes: An adding module 901 that, in response to a locking request associated with a data request, adds the locking request to a locking queue, the locking request being sent by a first computing device in the cluster database when the lock synchronization mode is not a weak synchronization mode. A processing module 902 that processes the locking request in the locking queue to obtain locking feedback information. A transmission module 903 that transmits the locking feedback information to the first computing device is included.

[0200] According to the device provided by the embodiments of the present application, a plurality of flexible levels are set for the lock synchronization mode. As long as it is not in the weak synchronization mode, the first computing device sends a locking request. In response to the locking request, corresponding locking feedback information is returned. When the obtained locking feedback information meets the target conditions, the first computing device is triggered to lock the data resource and execute the data request, so that the cluster database supports selecting different lock synchronization modes in different traffic scenarios, ensuring that the cluster database can meet the processing needs of different traffic scenarios, and improving the processing capacity of the cluster database system.

[0201] In a possible implementation manner, the processing module 902 locks the data resource corresponding to the data request, and the locking feedback information is determined to indicate successful locking. When the waiting period of the locking request in the locking queue exceeds a third waiting threshold or the deadlock detection fails, the locking feedback information is determined to indicate locking failure.

[0202] In a possible implementation manner, based on the device structure of FIG. 9, the device includes a detection module that performs local deadlock detection on the locking request in response to the deadlock detection message of the first computing device. When the local deadlock detection fails, a first determination module that determines that the deadlock detection fails. When the local deadlock detection is qualified, a second decision module for determining a lock wait link for the locking request, where the lock wait link includes lock information having a dependency relationship with the locking request, and further includes a second decision module; When the lock wait link includes a distal lock, the transmission module 903 further sends a deadlock detection message to a third computing device that issues the distal lock, where the distal lock is lock information registered in the second computing device but not lock information issued by the second computing device; When any one of the computing devices that send the deadlock detection message receives the deadlock detection message again, the first decision module determines that the deadlock detection is unqualified.

[0203] In a possible embodiment, the additional module 901 receives the locking request by a message processing thread on the second computing device, activates a lock proxy thread corresponding to the locking request by the message processing thread, and adds the locking request to the locking queue by the lock proxy thread.

[0204] In a possible embodiment, based on the device structure of FIG. 9, the device further includes a registration module for registering lock information corresponding to the data request when locking a data resource corresponding to the data request; and a third decision module for determining whether the lock information is active lock information for each target period. When the sending module 903 further determines that the lock information is active lock information and the locking period of the data resource corresponding to the data request exceeds the life-and-death monitoring threshold, it sends a life-and-death monitoring request to the first computing device, and the life-and-death monitoring request requests the first computing device to indicate whether to release the data resource.

[0205] In a possible embodiment, based on the device structure of FIG. 9, the device further includes a release module that releases the data resource corresponding to the data request in response to a lock release request associated with the data request.

[0206] For all of the above preferred technical solutions, any combination can be adopted to form a preferred embodiment of the present disclosure, which will not be elaborated here.

[0207] Here, when the request processing device provided in the above embodiment processes a data request, the partitioning of each of the above function modules is described by way of example. However, in actual applications, based on needs, the above functions are allocated to be completed by different function modules, that is, the internal structure of the computing device is partitioned into different function modules to complete all or part of the functions described above. In addition, since the request processing device provided in the above embodiment belongs to the same concept as the embodiment of the request processing method, for its specific implementation process, reference may be made to the embodiment of the request processing method, which will not be elaborated here.

[0208] FIG. 10 is a schematic structural diagram of a computing device provided by an embodiment of the present application. Taking the computing device as the terminal 1000 as an example for explanation. Optionally, the device type of the terminal 1000 includes a smartphone, a tablet computer, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 (Moving Picture Experts Group Audio Layer IV) player, a notebook computer, or a desktop computer. The terminal 1000 may also be referred to by other names such as a user device, a portable terminal, a laptop terminal, or a desktop terminal.

[0209] Generally, the terminal 1000 includes a processor 1001 and a memory 1002.

[0210] Optionally, the processor 1001 includes one or more processing cores, such as a 4-core processor, an 8-core processor, etc. Preferably, the processor 1001 may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), or PLA (Programmable Logic Array). In some embodiments, the processor 1001 includes a processor that processes data in the wake-up state, a main processor also called a CPU (Central Processing Unit), and a coprocessor that is a low-power consumption processor that processes data in the standby state. In some embodiments, a GPU (Graphics Processing Unit) is integrated into the processor 1001, and the GPU performs rendering and drawing of the content to be displayed on the display. In some embodiments, the processor 1001 further includes an AI (Artificial Intelligence) processor, and the AI processor processes computing operations related to machine learning.

[0211] In some embodiments, the memory 1002 includes one or more computer-readable storage media. Preferably, the computer-readable storage media is non-transitory. Preferably, the memory 1002 may further include a high-speed random access memory and non-volatile memory, such as one or more magnetic disk storage devices and flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1002 stores at least one program code, and the at least one program code is executed by the processor 1001 to implement the claim processing method provided by each embodiment in the present application.

[0212] In some embodiments, the terminal 1000 further includes a peripheral device interface 1003 and at least one peripheral device. The processor 1001, the memory 1002, and the peripheral device interface 1003 are connected via a bus or signal lines. Each peripheral device is connected to the peripheral device interface 1003 via a bus, signal lines, or a circuit board. Specifically, the peripheral device includes at least one of a radio frequency circuit 1004, a display 1005, a camera component 1006, an audio circuit 1007, a positioning component 1008, and a power supply 1009.

[0213] In some embodiments, the terminal 1000 further includes one or more sensors 1010. The one or more sensors 1010 include, but are not limited to, an acceleration sensor 1011, a gyro sensor 1012, a pressure sensor 1013, a fingerprint sensor 1014, an optical sensor 1015, and a proximity sensor 1016.

[0214] As can be understood by those skilled in the art, the structure of FIG. 10 does not limit the terminal 1000, and it may include more or fewer components than shown, or some components may be combined, or different components may be used and arranged.

[0215] FIG. 11 is a schematic structural diagram of a computing device provided by an embodiment of the present application. Due to its arrangement or performance, there may be a significant difference in the computing device 1100. The computing device 1100 includes one or more central processing units (CPUs) 1101 and one or more memories 1102. At least one computer program is stored in the memory 1102, and the at least one computer program is read and executed by the one or more processors 1101 to implement the request processing method provided by each of the above embodiments. Optionally, the computing device 1100 further includes components such as a wired or wireless network interface, a keyboard, and an input / output interface for input / output. The computing device 1100 further includes other components for realizing device functions, which will not be elaborated here.

[0216] In an exemplary embodiment, a computer-readable storage medium, such as a memory including at least one computer program, is further provided. The at least one computer program is executed by a processor in a terminal to complete the request processing method in each of the above embodiments. For example, the computer-readable storage medium includes a ROM (Read-Only Memory), a RAM (Random-Access Memory), a CD-ROM (Compact Disc Read-Only Memory), a magnetic tape, a flexible disk, and an optical data storage device, etc.

[0217] In an exemplary embodiment, a computer program product or a computer program is further provided, which includes one or more program codes, and the one or more program codes are stored in a computer-readable storage medium. One or more processors of a computing device read the one or more program codes from the computer-readable storage medium, and the one or more processors execute the one or more program codes to cause the computing device to execute and complete the request processing method in the above embodiment.

[0218] As can be understood by those skilled in the art, the realization of all or some of the steps of the above embodiments may be completed by hardware, or may be completed by a program by instructing the relevant hardware, and optionally, the program is stored in a computer-readable storage medium, and optionally, the storage medium mentioned above is a read-only memory, a magnetic disk or an optical disk, etc.

[0219] The above does not limit the present application, but is only a preferred embodiment of the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present application are all included within the protection scope of the present application.

Claims

1. A method for request processing executed by a first computing device in a cluster database, comprising: determining a lock synchronization mode of the cluster database in response to a data request; when the lock synchronization mode is a weak synchronization mode, locking a data resource corresponding to the data request and executing the data request; when the lock synchronization mode is not the weak synchronization mode, obtaining locking feedback information of at least one second computing device in the cluster database with respect to the data resource, where the locking feedback information indicates whether the locking of the data resource by the second computing device is successful, and when the obtained locking feedback information meets a target condition corresponding to the lock synchronization mode, locking the data resource corresponding to the data request and executing the data request, when the lock synchronization mode is a strong synchronization mode, the target condition is that the locking feedback information of all of the at least one second computing device indicates successful locking; when the lock synchronization mode is a quasi-strong synchronization mode, the target condition is that the locking feedback information of at least a target number of the at least one second computing device indicates successful locking, the method comprising the steps.

2. The step of obtaining the locking feedback information of at least one second computing device in the cluster database with respect to the data resource comprises: sending a locking request associated with the data request to the at least one second computing device; receiving, from the at least one second computing device, the locking feedback information returned based on the locking request, the method according to claim 1.

3. the step of sending, to the at least one second computing device, a locking request associated with the data request includes the step of respectively sending, by a message processing thread on the first computing device, the locking request to a message processing thread on the at least one second computing device the step of receiving, from the at least one second computing device, the locking feedback information returned based on the locking request includes the step of receiving, by a message processing thread on the first computing device, the locking feedback information returned from a message processing thread on the at least one second computing device, the method according to claim 2.

4. the method in response to receiving the locking feedback information of any one of the second computing devices, when the data request is in an active state, sending, by the message processing thread, the locking feedback information to a lock request thread of the data request when the data request is in an inactive state and the locking feedback information indicates successful locking, sending a unlock request to the second computing device, the unlock request being for instructing the second computing device to release a data resource corresponding to the data request, the method according to claim 3 further including.

5. When the lock synchronization mode is the strong synchronization mode, the target condition is further that the waiting period is equal to or less than a first waiting threshold. When the lock synchronization mode is the semi-strong synchronization mode, the target condition is further that the waiting period is equal to or less than a second waiting threshold. The method according to claim 1.

6. The method includes: When the lock synchronization mode is the semi-strong synchronization mode, the step of obtaining the target number; When the target number is less than 1 or exceeds the number of all second computing devices in the cluster database, the step of switching the lock synchronization mode to the strong synchronization mode. The method according to claim 1.

7. The method includes: When the obtained locking feedback information does not meet the target condition or the execution of the data request is completed, the step of sending a lock release request to the at least one second computing device, where the lock release request is for instructing the second computing device to release the data resource corresponding to the data request. The method according to claim 1.

8. The data request is a data definition language DDL request. The method according to claim 1.

9. A request processing method executed by a second computing device in a cluster database, In response to a locking request associated with a data request, the step of adding the locking request to a locking queue, where the locking request is sent by a first computing device in the cluster database when the lock synchronization mode is not the weak synchronization mode; The step of processing the locking request in the locking queue to obtain locking feedback information, Lock the data resource corresponding to the data request, and determine that the locking feedback information represents successful locking. If the waiting period of the locking request in the locking queue exceeds a third waiting threshold or the deadlock detection fails, determine that the locking feedback information represents a locking failure. This is a step. A method including the step of sending the locking feedback information to the first computing device.

10. The method In response to a deadlock detection message of the first computing device, perform local deadlock detection on the locking request. If the local deadlock detection fails, determine that the deadlock detection fails. If the local deadlock detection passes, determine the lock waiting link of the locking request, where the lock waiting link includes lock information having a dependency relationship with the locking request. If the lock waiting link includes a distal lock, send a deadlock detection message to a third computing device that issues the distal lock, where the distal lock is lock information registered in the second computing device but not lock information issued from the second computing device. If any one of the computing devices that sent the deadlock detection message receives the deadlock detection message again, determine that the deadlock detection fails. The method according to claim 9 further includes this step.

11. In response to a locking request associated with the data request, the step of adding the locking request to the locking queue Receiving the locking request by a message processing thread on the second computing device; Starting, by the message processing thread, a lock proxy thread corresponding to the locking request; Adding, by the lock proxy thread, the locking request to the locking queue, the method according to claim 9.

12. The method is When locking a data resource corresponding to the data request, registering lock information corresponding to the data request; Determining, for each target period, whether the lock information is active lock information; When the lock information is active lock information and the locking period of the data resource corresponding to the data request exceeds a life and death monitoring threshold, sending a life and death monitoring request to the first computing device, the life and death monitoring request being for requesting the first computing device to indicate whether to release the data resource, the method according to claim 9.

13. A request processing apparatus, comprising: A determination module that determines a lock synchronization mode of a cluster database in response to a data request; A locking execution module that locks a data resource corresponding to the data request and executes the data request when the lock synchronization mode is a weak synchronization mode; A first acquisition module that acquires locking feedback information of at least one second computing device in the cluster database with respect to the data resource when the lock synchronization mode is not the weak synchronization mode, the locking feedback information being for indicating whether the locking of the data resource by the second computing device is successful. When the obtained locking feedback information satisfies the target conditions corresponding to the lock synchronization mode, the locking execution module further locks the data resource corresponding to the data request and executes the data request. When the lock synchronization mode is a strong synchronization mode, the target condition is that the locking feedback information of the at least one second computing device all indicates successful locking. When the lock synchronization mode is a quasi-strong synchronization mode, the target condition is that the locking feedback information of the target number or more of the at least one second computing device indicates successful locking. The device.

14. An addition module that responds to a locking request associated with a data request and adds the locking request to a locking queue. The locking request is transmitted by a first computing device in a cluster database when the lock synchronization mode is not a weak synchronization mode. An addition module. A processing module that processes the locking request in the locking queue to obtain locking feedback information. Lock the data resource corresponding to the data request, and determine the locking feedback information to indicate successful locking. When the waiting period of the locking request in the locking queue exceeds a third waiting threshold or the deadlock detection fails, determine the locking feedback information to indicate locking failure. A processing module. A request processing device including a transmission module that transmits the locking feedback information to the first computing device.

15. A computing device, the computing device including one or more processors and one or more memories, at least one computer program being stored in the one or more memories, the at least one computer program being read and executed by the one or more processors to implement the claim processing method according to any one of claims 1 to 8 or claims 9 to 12.

16. A computer program, which when read and executed by one or more processors of a computing device, implements the claim processing method according to any one of claims 1 to 8 or claims 9 to 12.

Images