Methods and tools for processing requests, computing equipment, and storage media.

Abstract

Invention details;

Description

Request processing method, device, computing device and storage medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on August 30, 2021, with application number 2021110037642 and application name “Request processing method, device, computing device and storage medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of database technology, and in particular to request processing technology. Background Art

[0003] With the advancement of database technology, traditional stand-alone databases are increasingly unable to adapt to business scenarios such as big data and cloud computing, and clustered databases are becoming increasingly popular. Currently, both stand-alone databases like MySQL and PostgreSQL and cluster databases like IBM and Oracle use concurrency control methods based on strong synchronization lock mechanisms. Strong synchronization lock mechanisms require that a process requesting a lock must obtain locks of the corresponding level on all computing devices in the cluster to be considered successful. Otherwise, the lock application must wait. If any computing device in the cluster fails to apply for a lock or the wait timeout occurs, the process will not be able to successfully apply for the lock.

[0004] In cluster databases, strong synchronization lock mechanisms require all computing devices in the cluster to obtain locks of the corresponding level. As the number of computing devices in the cluster increases, the overhead of obtaining locks also increases significantly, resulting in poor processing power of the cluster database system. Therefore, a method to improve the processing power of cluster database systems is urgently needed.

[0005] Summary of the Invention

[0006] The present application provides a request processing method, apparatus, computing device, and storage medium that can improve the processing capabilities of a cluster database system. The technical solution is as follows:

[0007] In one aspect, a request processing method is provided, which is executed by a first computing device in a cluster database, the method comprising:

[0008] In response to a data request, determining a lock synchronization mode of the cluster database;

[0009] When the lock synchronization mode is a weak synchronization mode, locking the data resource corresponding to the data request and executing the data request;

[0010] When the lock synchronization mode is not a weak synchronization mode, locking feedback information of the data resource by at least one second computing device in the cluster database is obtained, and the locking feedback information is used to indicate whether the second computing device has successfully locked the data resource; when the obtained locking feedback information meets the target condition corresponding to the lock synchronization mode, the data resource corresponding to the data request is locked, and the data request is executed.

[0011] In one aspect, a request processing method is provided, which is executed by a second computing device in a cluster database, the method comprising:

[0012] In response to a lock request associated with the data request, adding the lock request to a lock waiting queue; the lock request is sent by the first computing device in the cluster database when the lock synchronization mode is not a weak synchronization mode;

[0013] Processing the lock request in the lock waiting queue to obtain lock feedback information;

[0014] The locking feedback information is sent to the first computing device.

[0015] In one aspect, a request processing device is provided, the device comprising:

[0016] A determination module, configured to determine a lock synchronization mode of the cluster database in response to a data request;

[0017] a lock execution module, configured to lock the data resource corresponding to the data request and execute the data request when the lock synchronization mode is a weak synchronization mode;

[0018] a first acquisition module, configured to, when the lock synchronization mode is not the weak synchronization mode, acquire locking feedback information of the data resource by at least one second computing device in the cluster database, wherein the locking feedback information is used to indicate whether the second computing device has successfully locked the data resource;

[0019] The lock execution module is further configured to lock the data resource corresponding to the data request and execute the data request when the acquired lock feedback information meets the target condition corresponding to the lock synchronization mode.

[0020] In one aspect, a request processing device is provided, the device comprising:

[0021] an adding module configured to, in response to a lock request associated with a data request, add the lock request to a lock waiting queue; the lock request is sent by a first computing device in the cluster database when the lock synchronization mode is not a weak synchronization mode;

[0022] A processing module, configured to process the lock request in the lock waiting queue and obtain lock feedback information;

[0023] A sending module is used to send the locking feedback information to the first computing device.

[0024] On the one hand, a computing device is provided, which includes one or more processors and one or more memories, wherein the one or more memories store at least one computer program, and the at least one computer program is loaded and executed by the one or more processors to implement a request processing method as any possible implementation method described above.

[0025] On the one hand, a storage medium is provided, in which at least one computer program is stored. The at least one computer program is loaded and executed by a processor to implement the request processing method as any possible implementation manner described above.

[0026] In one aspect, a computer program product or computer program is provided, comprising one or more program codes stored in a computer-readable storage medium. One or more processors of a computing device are capable of reading the one or more program codes from the computer-readable storage medium, and executing the one or more program codes by the one or more processors, so that the computing device can perform the request processing method of any possible embodiment described above.

[0027] The beneficial effects of the technical solutions provided in the embodiments of the present application include at least:

[0028] By setting multiple flexible levels of lock synchronization mode, in weak synchronization mode, the data resource corresponding to the data request is directly locked and the data request is executed, which can ensure that the data request is prioritized without waiting for the response of the second computing device. In non-weak synchronization mode, the locking feedback information of each second computing device is obtained. Only when the obtained locking feedback information meets the target conditions, the data resource is locked and the data request is executed. Different lock synchronization modes are supported in different business scenarios, thereby ensuring that the cluster database can meet the processing requirements of different business scenarios and improving the processing capacity of the cluster database system. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] FIG1 is a schematic diagram of an implementation environment of a request processing method provided in an embodiment of the present application;

[0030] FIG2 is a schematic diagram showing a principle of a lock synchronization mechanism model provided in an embodiment of the present application;

[0031] FIG3 is a flowchart of a request processing method provided in an embodiment of the present application;

[0032] FIG4 is an interactive flow chart of a request processing method provided in an embodiment of the present application;

[0033] FIG5 is a schematic diagram showing a principle of a locking process provided in an embodiment of the present application;

[0034] FIG6 is a schematic diagram showing a principle of a lock release process according to an embodiment of the present application;

[0035] FIG7 is a schematic diagram of a deadlock detection process according to an embodiment of the present application;

[0036] FIG8 is a schematic diagram of the structure of a request processing device provided in an embodiment of the present application;

[0037] FIG9 is a schematic structural diagram of a request processing device provided in an embodiment of the present application;

[0038] FIG10 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0039] FIG11 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0041] In this application, the terms "first", "second", etc. are used to distinguish identical or similar items with substantially the same effects and functions. It should be understood that there is no logical or temporal dependency between "first", "second", and "nth", nor is there any limitation on the quantity and execution order.

[0042] In the present application, the term "at least one" means one or more, and the term "plurality" means two or more. For example, a plurality of first positions means two or more first positions.

[0043] Before introducing the embodiments of the present application, it is necessary to introduce some basic concepts in the field of cloud technology.

[0044] Cloud Technology: refers to a hosting technology that unifies hardware, software, network and other resources within a wide area network or local area network to achieve data computing, storage, processing and sharing. It is a general term for network technology, information technology, integration technology, management platform technology, application technology, etc. based on the cloud computing business model. It can form a resource pool that can be used on demand and is flexible and convenient. Cloud computing technology is an important support for the field of cloud technology. The backend services of technical network systems require a large amount of computing and storage resources, such as video websites, image websites and more portals. With the rapid development and application of the Internet industry, every item may have its own identification mark in the future, and all of them need to be transmitted to the backend system for logical processing. Data of different levels will be processed separately. All kinds of industry data require strong system backend support, which can be achieved through cloud computing.

[0045] Cloud Storage: A new concept that extends and develops from the concept of cloud computing. A distributed cloud storage system (hereinafter referred to as a storage system) refers to a storage system that uses cluster applications, grid technology, and distributed storage file systems to bring together 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 to work together and provide external data storage and business access functions.

[0046] Database: Simply put, it can be thought of as a digital filing cabinet—a place where electronic files are stored, where users can add, query, update, and delete data. A database is a collection of data stored in a specific way, shared by multiple users, with minimal redundancy, and independent of applications.

[0047] The following explains the terms involved in the embodiments of the present application.

[0048] Computing device: also known as a computing node, refers to a node device in a database (usually a cluster database; for a stand-alone database, the stand-alone device itself is a computing device) used to process user-specific computing requests and is primarily responsible for executing user requests. It can also be called an SQL engine (SQLEngine). The full English name of SQL is Structured Query Language, and the full Chinese name is Structured Query Language.

[0049] Locking mechanism: During the operation of a cluster database, different processes or threads may need to modify the same data resource (e.g., database, data table, data column, data index, etc.) simultaneously on different computing devices or on the same computing device. The locking mechanism ensures the correctness of modifications to this data resource across different concurrent processes or threads. Cluster databases can be divided into centralized cluster databases and distributed cluster databases. Centralized cluster databases refer to cluster databases with a centralized control module, while distributed cluster databases refer to decentralized cluster databases.

[0050] Strong synchronization lock mechanism: The process applying for a lock must obtain locks of the corresponding level on all computing devices in the cluster to successfully apply for the lock. Otherwise, it needs to wait. As long as any computing device in the cluster fails to apply for the lock or the wait times out, the process cannot successfully apply for the lock.

[0051] Strong synchronization locks require extremely high inter-node (i.e., inter-computing device) communication performance. A single unresponsive or faulty computing device can easily block the execution of other computing devices in the cluster, significantly reducing the overall cluster's business processing capabilities. For example, the entire cluster's business processing is blocked (hung). Strong synchronization locks are typically used in standalone databases and centralized cluster database scenarios.

[0052] Weak synchronization lock mechanism: When certain processes or threads (for example, those requesting data definition language (DDL)) need to lock certain data resources during execution, they can proceed directly without requesting locks from other computing devices. The correctness of the operation is ensured by a specific mechanism called a writing barrier. This mechanism allows the DDL requesting process or thread to proceed directly without requesting a lock and applies the write barrier. This ensures that other business processes or threads, when operating on data, must compare the write barrier version they are using with the latest version stored in the data store. If they are inconsistent, the business transaction corresponding to the business process or thread must be rolled back to ensure the correctness and consistency of data processing.

[0053] In a sense, the weak synchronization lock mechanism prioritizes DDL requests. Once a write barrier is applied, the corresponding Data Manipulation Language (DML) request may be rolled back. In other words, the weak synchronization lock mechanism is not very friendly to DML requests. This weak synchronization lock mechanism can be viewed as prioritizing certain types of processes or threads (such as those requesting DDL). This weak synchronization mode requires auxiliary measures (such as write barriers or lease mechanisms) to ensure the correct implementation of the entire mechanism. While suitable for distributed cluster database scenarios, this weak synchronization mode presents user behavior that is inconsistent with the execution behavior of traditional databases and is not friendly to DML requests. Furthermore, because DDL processes or threads in weak synchronization mode are assumed to have acquired locks, this can cause a large number of transactions executed by other types of DML processes or threads to be rolled back.

[0054] Semi-strong synchronization: A compromise between the two aforementioned locking mechanisms (strong and weak synchronization). Because each mechanism has distinct advantages and disadvantages, their use in distributed cluster databases presents significant performance challenges. Therefore, the concept of a semi-strong synchronization mechanism is essential for high-performance user business processing in large-scale distributed clusters. Specifically, when a process or thread requests a lock on a specific data resource, it sends a lock request to all computing devices, starts a timer, and waits for a period of time. The lock request is then determined based on feedback (such as lock feedback) from a specified target number of computing devices to determine if the lock has been successfully requested. This semi-strong synchronization mode prevents the processing power of the entire cluster from being significantly reduced or even completely lost due to unresponsive computing devices. It also prevents other DML requests (often user business transactions, a key indicator of database service quality and performance) from being unfairly rolled back due to the assumption that a process or thread inherently holds the lock.

[0055] DDL (Data Definition Language) request: DDL statement operation is a modification operation statement used to modify the definition of data objects (such as databases, data tables, data columns, data indexes, etc.) in the database.

[0056] DML (Data Manipulate Language) requests: DML statement operations refer to operation statements used to modify user data stored in the database. They usually correspond to user business transactions. In other words, DML requests are usually business requests, often user business transactions, and are an important indicator for measuring the quality and performance of data services provided by the database.

[0057] The embodiments of the present application are applied to cluster databases (i.e., cluster database systems), which include central cluster databases and distributed cluster databases. A central cluster database refers to a cluster database with a centralized control module, in which a central node is configured within the cluster to deploy a global transaction manager and a global lock management module, while a distributed cluster database refers to a decentralized cluster database, in which there is no central node within the cluster to deploy a global transaction manager and a global lock management module, and global transactions and global locks are achieved by all computing nodes within the cluster through a certain algorithm. For example, a distributed cluster database is a distributed database system, a distributed big data processing system, and a distributed database management system with a similar architecture.

[0058] The cluster database may include at least one computing device (i.e., computing node), and the database of each computing device may store multiple data tables, each of which may be used to store one or more data rows (records), wherein each data row is composed of a set of fields arranged according to a specific position index, i.e., data field columns. The database of the computing device may be any type of cluster database, and may include at least one of a relational database or a non-relational database, such as a SQL (Structured Query Language) database, MySQL, NoSQL, NewSQL (a general term for various new scalable / high-performance databases), etc. In the embodiments of this application, the type of database is not specifically limited.

[0059] In some embodiments, the embodiments of the present application can also be applied to a database system based on blockchain technology (hereinafter referred to as the "blockchain system"). The above-mentioned blockchain system is essentially a decentralized distributed database system, which uses a consensus algorithm to maintain the consistency of the ledger data recorded by different computing devices on the blockchain, and uses a cryptographic algorithm to ensure the encrypted transmission and non-tamperability of the ledger data between different computing devices. The script system is used to expand the ledger function, and network routing is used to connect different computing devices to each other.

[0060] A blockchain system may include one or more blockchains. A blockchain is a string of related data blocks generated using cryptographic methods. Each data block includes information about a batch of network transactions, which is used to verify the validity of the information (anti-counterfeiting) and generate the next block.

[0061] Computing devices in a blockchain system can form a peer-to-peer (P2P) network. The P2P protocol is an application-layer protocol that runs on top of the Transmission Control Protocol (TCP). Within a blockchain system, any computing device can possess the following functions: 1) Routing, a basic computing device function that supports communication between computing devices; 2) Applications, deployed within the blockchain to implement specific services based on actual business needs. These applications record data related to these services as ledger data, carry digital signatures to indicate the data's origin, and transmit this data to other computing devices within the blockchain system. Upon successful verification of the data's origin and integrity, these devices add the data to a temporary block. Applications can implement services such as wallets, shared ledgers, and smart contracts; 3) Blockchain, comprising a series of sequentially connected blocks. Once a new block is added to the blockchain, it cannot be removed. Blocks record the ledger data submitted by computing devices within the blockchain system.

[0062] In some embodiments, each block may include a hash value of the transaction record stored in the block (the hash value of the block) and a hash value of the previous block. Each block is connected through the hash value to form a blockchain. In addition, the block may also include information such as the timestamp when the block was generated.

[0063] The following describes the system architecture of the embodiment of the present application.

[0064] Figure 1 is a schematic diagram of an implementation environment for a request processing method provided in an embodiment of the present application. Referring to Figure 1 , a distributed cluster database is used as an example for illustration. The distributed cluster database system includes an application client 101, a gateway server 102, and a distributed storage cluster 103. Distributed storage cluster 103 includes one or more computing devices.

[0065] The application client 101 refers to a client installed and running on the terminal on the user side that can initiate a data request. The data request can be a DDL request or a DML request, etc., and this embodiment of the application does not specifically limit this. Optionally, the type of application client 101 includes but is not limited to: payment applications, social applications, audio and video applications, live broadcast applications, shopping applications, food delivery applications or taxi applications, etc., and this embodiment of the application does not specifically limit the type of application client 101. In some embodiments, the terminal on the user side is also referred to as a user device, terminal device, user terminal, mobile terminal, smart terminal, communication device, etc. Optionally, the device type of the terminal includes: smart phones, tablet computers, laptops, desktop computers, smart speakers, smart watches, car terminals, smart home appliances, smart voice interaction devices, etc., but is not limited to this.

[0066] The application client 101 and the gateway server 102 can be connected directly or indirectly through wired or wireless communication, and this application does not impose any restrictions on this.

[0067] The gateway server 102 is used to receive external data requests and distribute the read and write transactions corresponding to the data requests to the distributed storage cluster 103. Schematically, the user logs in to the application client 101 on the terminal, triggering the application client 101 to generate a DDL request. For example, the DDL request is to modify the table name of data table A. Then, 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 can be a MySQL API (an API provided by a relational database system). For another example, in a smart transportation scenario, a request to add a new parking space is a DDL request, while a request to query an existing parking space is a DML request.

[0068] In some embodiments, the gateway server 102 may be combined with any computing device in the distributed storage cluster 103 on the same physical machine, that is, a computing device in the distributed storage cluster 103 may serve as the gateway server 102 .

[0069] The distributed storage cluster 103 includes one or more computing devices. For some data requests, such as DDL requests, it is necessary to add a global lock to the DDL request when executing the DDL request to ensure the operational correctness 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 computing devices other than the first computing device are called the second computing devices. Optionally, the division of the first computing device and the second computing device is for different DDL requests, and the number of the second computing devices can be one or more. The embodiment of the present application does not specifically limit the number of computing devices in the distributed storage cluster 103. For example, the number of computing devices is m, and m is an integer greater than or equal to 1.

[0070] Optionally, each computing device adopts a master-slave structure (that is, a one-master and multiple-slave cluster), as shown in Figure 1. Taking the computing device as a one-master and two-slave cluster as an example, each computing device includes a host and two backup machines. Optionally, each host or backup machine is configured with an agent device. The agent device can be physically independent of the host or backup machine. Of course, the agent device can also serve as an agent module on the host or backup machine. Taking computing device 1 as an example, computing device 1 includes a master database and an agent device (master database + agent, referred to as master DB + agent), and also includes two backup databases and agent devices (backup database + agent, referred to as backup DB + agent).

[0071] In an exemplary scenario, the set of database instances of the host or standby corresponding to each computing device is called a SET (set). For example, assuming that a computing device is a stand-alone device, then the SET of the computing device is only the database instance of the stand-alone device. Assuming that a computing device is a one-master and two-standby cluster, then the SET of the computing device is the set of the host database instance and the two standby database instances.

[0072] In some embodiments, the distributed cluster database system composed of the above-mentioned gateway server 102 and the distributed storage cluster 103 can be regarded as a server that provides data services to user terminals. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can 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), and big data and artificial intelligence platforms.

[0073] The following takes the cluster database as a distributed cluster database as an example to introduce a lock synchronization mechanism model provided by an embodiment of the present application. Figure 2 is a schematic diagram of the principle of a lock synchronization mechanism model provided by an embodiment 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. Assuming that the first computing device receives a DDL request at a certain moment, the DDL request needs to be locked in the distributed cluster database to ensure the correctness of the operation. Taking the strong synchronization mode as an example, in the strong synchronization mode, it is necessary to apply for a lock on the data resource corresponding to the DDL request on the first computing device and the second computing device A, B, and C. After all computing devices have successfully applied for the lock, the processing logic of the DDL request is executed, that is, the corresponding DDL transaction is completed, and then the first computing device releases the lock of this DDL request, and notifies the second computing devices A, B, and C to also release the lock of this DDL request. The overall lock synchronization process will be described in detail below:

[0074] Step 1: The first computing device starts processing the DDL request.

[0075] Step 2: The first computing device performs DDL preparation, for example, locally completing a local lock request for the data resource that needs to be locked.

[0076] Step 3: The first computing device sends a lock request to the second computing devices A, B, and C respectively through the lock module or lock function. The second computing devices A, B, and C each process the lock request and return lock feedback information to the first computing device.

[0077] Step 4: The first computing device executes the DDL processing logic, for example, executes the DDL transaction corresponding to the DDL request.

[0078] Step 5: The first computing device sends a lock release request to the second computing devices A, B, and C respectively through the lock release module or lock release function. The second computing devices A, B, and C each process the lock release request and return lock release feedback information to the first computing device.

[0079] Step 6: The first computing device ends the processing process of the DDL request (referred to as DDL process for short).

[0080] In the above process, it can be seen that it is only necessary to add a locking module or locking function in the first computing device to ensure that the lock of a certain DDL request can be synchronized to other second computing devices in this cluster. For example, after each second computing device receives the lock request, it will take the lead in applying for the lock locally and return the lock feedback information to the remote node that applied for the lock (that is, the first computing device). At the same time, the lock release process is also carried out by the lock holder (that is, the first computing device that initiates the lock request) first sending a lock release request to other second computing devices in this cluster. After each second computing device receives the lock release request, it releases the corresponding lock locally and returns the lock release feedback information to the remote node (that is, the first computing device).

[0081] The above embodiment briefly introduces the general framework of the lock synchronization mechanism model. In this embodiment, the various operations of the first computing device during the locking process are described. Figure 3 is a flowchart of a request processing method provided by this embodiment. Referring to Figure 3, this embodiment is executed by the first computing device in the cluster database and includes the following steps:

[0082] 301. A first computing device determines a lock synchronization mode of a cluster database in response to a data request.

[0083] Optionally, the cluster database can be a central cluster database or a distributed cluster database, both of which are applicable to the request processing method. This embodiment of the application uses a distributed cluster database as an example. The cluster database includes a first computing device and a second computing device. The first computing device is the computing device used to process the data request, and all computing devices in the cluster other than the first computing device are referred to as second computing devices.

[0084] In some embodiments, a user may log in to an application client on a terminal, triggering 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, a DDL request is used as an example. For example, the DDL request is to modify the name of Table A. After generating the data request, the application client may call an API to send the data request to the first computing device.

[0085] In some embodiments, the first computing device receives the data request, parses a header field of the data request, and determines a lock synchronization mode of the cluster database when the header field indicates that the data request is a request of a specified type, such as a DDL request.

[0086] In some embodiments, the lock synchronization mode may be indicated by a lock synchronization mode parameter lock_level_mode configured by the database system (or database engine). The lock synchronization mode parameter lock_level_mode is used to characterize the lock synchronization mode currently in which the cluster database is located. The lock synchronization mode includes, but is not limited to, strong synchronization mode (Strong), semi-strong synchronization mode (Middle), and weak synchronization mode (Feak). The first computing device may query 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 semi-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.

[0087] In some embodiments, the lock synchronization mode parameter lock_level_mode as described above is added to the configuration file. When the cluster database is started, the database engine of each computing device in the cluster will load the configuration file.

[0088] In some embodiments, the lock synchronization mode parameter lock_level_mode can also be randomly modified by the computing device while the entire cluster is running. After the computing device completes the modification of the lock synchronization mode parameter lock_level_mode, it will automatically synchronize the modified lock synchronization mode parameter lock_level_mode to all computing devices in the cluster.

[0089] In some embodiments, if the lock synchronization mode determined by the first computing device is a weak synchronization mode, the following step 302 is executed; if the lock synchronization mode determined by the first computing device is a strong synchronization mode or a semi-strong synchronization mode, the following steps 303-304 are executed.

[0090] In other embodiments, after the first computing device completes the local lock application locally to the data resource that needs to be locked, it enters the locking process, and then determines whether the lock synchronization mode is a weak synchronization mode. If the lock synchronization mode is a weak synchronization mode, execute the following step 302; if the lock synchronization mode is not a weak synchronization mode, execute the following steps 303-304.

[0091] 302. When 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.

[0092] If the lock synchronization mode is weak, the first computing device can directly proceed with the current data request, such as a DDL request, without requesting a lock from the second computing device. The correctness of the operation is ensured by a specific mechanism called a writing fence. This mechanism ensures that in a multi-core, multi-threaded environment, only one thread can enter the critical section at a time, thereby ensuring the consistency of the data being operated on in the critical section.

[0093] It should be noted that the "lock" involved in the embodiments of the present application can be understood as a memory status parameter in the memory. For example, the memory status parameter can be an integer. The memory status parameter is associated with a data resource and represents whether the associated data resource is locked.

[0094] Optionally, this memory status parameter has two states: idle and locked. When locking, the lock is checked to see if it is idle. If so, the lock is changed to locked, the lock holder is transformed into the lock holder, and a lock request success message is returned. If already locked, a lock request failure message is returned. When unlocking, the locked state is changed to idle.

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

[0096] In weak synchronization mode, due to the guarantee of the write barrier mechanism, the first computing device can directly consider that the lock has been obtained after the local lock application is successful, that is, the first computing device becomes the lock holder, without sending lock applications to other second computing devices, and can determine that the data resource corresponding to the data request is locked successfully. The locking process ends, and then the database transaction corresponding to the data request can be executed, for example, the DDL transaction corresponding to the DDL request is executed through the DDL thread.

[0097] 303. When the lock synchronization mode is not a weak synchronization mode, the first computing device obtains locking feedback information of the data resource from at least one second computing device in the cluster database, where the locking feedback information is used to indicate whether the second computing device has successfully locked the data resource.

[0098] If the lock synchronization mode is not a weak synchronization mode, then the lock synchronization mode may be a strong synchronization mode or a semi-strong synchronization mode. In the above-mentioned strong synchronization mode or semi-strong synchronization mode, the first computing device needs to apply for a lock from each remote second computing device. The only difference is that the two modes have different target conditions for determining whether the lock application is successful. In the strong synchronization mode, all second computing devices must successfully apply for a lock before the global application for the lock of the data resource is considered successful. In the semi-strong synchronization mode, only a number of second computing devices, not less than the target number, need to successfully apply for a lock before the global application for the lock of the data resource is considered successful.

[0099] In some embodiments, the first computing device applies for a lock from each second computing device to obtain locking feedback information from each second computing device. Optionally, the locking feedback information includes: locking success and locking failure. The reasons for locking failure are usually various, such as waiting timeout, deadlock, etc.

[0100] In some embodiments, the above-mentioned process of applying for locks from each second computing device includes: the first computing device sends a lock request associated with the data request to the at least one second computing device; the first computing device receives the lock feedback information returned by the at least one second computing device based on the lock request.

[0101] Optionally, a message processing thread can be created in the background on the first computing device and each second computing device. The message processing thread can be specifically used to process various messages related to the locking mechanism, such as monitoring lock requests, lock release requests, lock feedback information, lock release feedback information, etc. from other computing devices, and timely sending and receiving various messages related to the locking mechanism to ensure communication performance between computing devices.

[0102] Based on the above situation, when the first computing device sends a lock request, it can use the message processing thread on the first computing device to send the lock request to the message processing thread on the at least one second computing device. Similarly, when the first computing device receives lock feedback information, it can use the message processing thread on the first computing device to receive the lock feedback information returned by the message processing thread on the at least one second computing device. The lock request process of the second computing device will be described in detail in the next embodiment and is not described in detail here.

[0103] In some embodiments, since the first computing device sends the lock request to each second computing device in the cluster, and the time when the lock feedback information of each second computing device is returned to the first computing device may be different, in some exemplary scenarios, if the processing process of the data request on the first computing device (such as the DDL process) crashes, then after the DDL process crashes, the first computing device should, depending on the situation, promptly instruct the second computing device that has successfully locked the lock to release the corresponding lock for the lock feedback information it receives, so as to avoid blocking other DML processes on the data resource, so as to optimize the processing performance of the cluster database.

[0104] In response to the above situation, the first computing device can respond to receiving the locking feedback information from any second computing device and, if the data request is in an active state, send the locking feedback information to the lock application thread of the data request through the message processing thread; if the data request is not in an active state and the locking feedback information indicates that the locking is successful, send a lock release request to the second computing device, and the lock release request is used to instruct the second computing device to release the data resources corresponding to the data request.

[0105] Optionally, after receiving any lock feedback information through the message processing thread, the first computing device determines whether the local data request is active. Taking the DDL request as an example, it can determine whether the DDL process corresponding to the DDL request exists. Since there may be multiple DDL requests reusing the same DDL process, the DDL process may still exist even if the current DDL request has failed (for example, the target condition is not met and the DDL transaction is rolled back). Therefore, there may be some misjudgment when judging whether the DDL request is active for the DDL process. Optionally, it is also possible to directly determine whether the DDL transaction corresponding to the DDL request is in an active state, which can effectively reduce the above-mentioned misjudgment and improve the accuracy of the judgment.

[0106] If the data request is not active, that is, the data request is not in an active state, determine whether the locking feedback information indicates that the locking is successful. If the locking feedback information indicates that the locking is successful, it means that the local DDL request has ended, but the lock of the corresponding data resource has been successfully applied for on the remote second computing device. At this time, it is necessary to instruct the second computing device to release the lock of the corresponding data resource in time. Therefore, the first computing device can send 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 an idle state; in addition, if the locking feedback information indicates that the locking failed, it means that the remote end does not need to release the data resource in time, so no processing is required.

[0107] If the data request is active, that is, the data request is in an active state, then the lock feedback information can be sent to the lock application thread of the data request through the message processing thread, so that the lock application thread records the lock feedback information received this time, and determines whether it meets the target conditions based on the following step 304, thereby facilitating the lock application thread to timely count whether the received lock feedback information meets the target conditions corresponding to the current lock synchronization mode.

[0108] In some embodiments, the first computing device may also start timing after sending a lock request to each second computing device. This timing statistics the waiting time for each lock feedback information, and the first waiting threshold corresponding to the strong synchronization mode and the second waiting threshold corresponding to the semi-strong synchronization mode may be set in the configuration file. The first waiting threshold is used to characterize the maximum waiting time of the computing device for the lock feedback information in the strong synchronization mode. If the waiting time in the strong synchronization mode exceeds the first waiting threshold, it can be directly regarded as a failure of this lock, and a release lock request is sent to each second computing device that successfully applies for the lock, to instruct the second computing device to release the data resource corresponding to the data request, and then end the locking process, wherein the first waiting threshold is any value greater than 0, for example, the first waiting threshold is 15 seconds. The second waiting threshold is used to characterize the maximum waiting time of the computing device for locking feedback information in the semi-strong synchronization mode. If the waiting time in the semi-strong synchronization mode exceeds the second waiting threshold, it can be directly regarded as a failure of this locking, and a release lock request is sent to each second computing device that successfully applies for the lock to instruct the second computing device to release the data resource corresponding to the data request, and then the locking process is ended. The second waiting threshold is any value greater than 0, for example, the second waiting threshold is 10 seconds. It should be noted that the first waiting threshold and the second waiting threshold can be the same or different, and the embodiment of the present application is not limited to this.

[0109] In the above process, by configuring the first waiting threshold and the second waiting threshold, and starting the timing after sending the lock request, the first computing device can be prevented from waiting for the lock feedback information of the other second computing device for a long time. For example, if packet loss occurs during the transmission of the lock feedback information, then the waiting time of the first computing device in the strong synchronization mode can reach the first waiting threshold at most, and the waiting time in the semi-strong synchronization mode can reach the second waiting threshold at most. Then, the processing of subsequent other data requests can be promoted, which can improve the performance of the cluster database.

[0110] 304. When the acquired locking feedback information satisfies the target condition corresponding to the lock synchronization mode, the first computing device locks the data resource corresponding to the data request and executes the data request.

[0111] The target condition corresponding to the lock synchronization mode is used to measure whether to lock the data resource corresponding to the data request based on the obtained lock feedback information. Generally, the target condition corresponding to the strong synchronization mode has higher requirements than the target condition corresponding to the semi-strong synchronization mode.

[0112] In some embodiments, if the cluster database does not set a timeout mechanism, 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 that the locking is successful; when the lock synchronization mode is a semi-strong synchronization mode, the target condition is that the locking feedback information of no less than the target number of second computing devices among the at least one second computing device indicates that the locking is successful.

[0113] In some embodiments, if the cluster database is set with a timeout mechanism, in addition to meeting the above basic conditions, it is also necessary to ensure that the waiting time in the strong synchronization mode does not exceed the first waiting threshold, and the waiting time in the semi-strong synchronization mode does not exceed the second waiting threshold, that is, when the lock synchronization mode is the strong synchronization mode, the target condition is that the waiting time does not exceed the first waiting threshold, and the locking feedback information of the at least one second computing device all indicates that the locking is successful; when the lock synchronization mode is the semi-strong synchronization mode, the target condition is that the waiting time does not exceed the second waiting threshold, and the locking feedback information of no less than the target number of second computing devices in the at least one second computing device indicates that the locking is successful. Wherein, the first waiting threshold and the second waiting threshold are both values ​​greater than 0, and the first waiting threshold and the second waiting threshold can be added to the configuration file and loaded by the database engine of each computing device when the cluster database is started.

[0114] In some embodiments, the target number can be indicated by the lock pass probability parameter lock_succ_node_num configured by the database engine. The lock pass probability parameter lock_succ_node_num is used to characterize how many computing devices in the cluster database need to successfully apply for the lock in semi-strong synchronization mode in order to be considered as a global lock application success. Optionally, the lock pass probability parameter lock_succ_node_num is equal to the target number plus one, where the target number represents the total number of second computing devices required to successfully apply for the lock, and the target number plus the first computing device itself is equal to the total number of computing devices in the cluster that need to successfully apply for the lock. The valid value range of the lock pass 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 pass probability parameter lock_succ_node_num is less than 1 or greater than the number of all computing devices in the cluster, it means that the cluster's lock pass probability parameter lock_succ_node_num is not within the valid value range. In this case, it can be considered that strong synchronization mode or weak synchronization mode (set by the administrator) is adopted to ensure the normal operation of the cluster when the lock pass probability parameter lock_succ_node_num is illegal. For example, strong synchronization mode is adopted for all.

[0115] Optionally, the lock can also be added to the configuration file through the probability parameter lock_succ_node_num, and when the cluster database is started, the database engine of each computing device in the cluster will load the configuration file.

[0116] Optionally, the lock pass probability parameter lock_succ_node_num can also be randomly modified by the computing device while the entire cluster is running. After the computing device has modified the lock pass probability parameter lock_succ_node_num, it will automatically synchronize the modified lock pass probability parameter lock_succ_node_num to all computing devices in the cluster.

[0117] In some embodiments, the first computing device obtains the target number when the lock synchronization mode is a semi-strong synchronization mode; and switches the lock synchronization mode to the strong synchronization mode when the target number is less than one or greater than the number of all second computing devices in the cluster database.

[0118] In the above process, the first computing device can query the value of the lock pass probability parameter lock_succ_node_num from the configuration file, and determine the value obtained by subtracting one from the value of the lock pass probability parameter lock_succ_node_num as the target number. Further, it is determined whether the target number is legal, that is, if the target number is greater than or equal to 1 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, then the lock synchronization mode judges the target condition according to the semi-strong synchronization mode, and if the target number is less than 1, or greater than the number of all second computing devices in the cluster database, it means that the target number is illegal, then the lock synchronization mode can be forced to switch to the strong synchronization mode. In some embodiments, the lock synchronization mode can also be forced to switch to the weak synchronization mode, and the embodiments of the present application are not limited to this.

[0119] In other embodiments, after the first computing device obtains the value of the lock pass probability parameter lock_succ_node_num by querying the configuration file, it determines whether the value of the lock pass probability parameter lock_succ_node_num is legal. If the lock pass 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), then it means that the target number is also legal. If the lock pass 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), then it means that the target number is also illegal, and the lock synchronization mode needs to be forcibly switched to strong synchronization mode or weak synchronization mode. In the embodiments of the present application, only the example of switching the lock synchronization mode to strong synchronization mode is used for illustration.

[0120] In some embodiments, if the lock synchronization mode parameter lock_level_mode≠Feak, indicating that the lock synchronization mode is not a weak synchronization mode, a lock request is sent to each second computing device via the message processing thread, a timer is started, and lock feedback information returned by each second computing device is received via the message processing thread. Optionally, if the lock synchronization mode parameter lock_level_mode=Strong, indicating that the lock synchronization mode is a strong synchronization mode, then it is determined whether the lock feedback information of all second computing devices indicates that the lock is successful. This can be discussed in three cases: 1) If the waiting timeout has not yet occurred, that is, the waiting time does not exceed the first waiting threshold, and the lock feedback information received from all second computing devices indicates that the lock is successful, then the target condition is met and it is considered that the global lock is successful; 2) If the lock feedback information received from any second computing device indicates that the lock fails, then the target condition is not met and it is considered that the global lock fails; 3) If the waiting timeout exceeds the first waiting threshold and there is still a second computing device that has not returned lock feedback information, it means that the waiting timeout has occurred, then the target condition is not met and it is considered that the global lock fails.

[0121] Optionally, if the lock synchronization mode parameter lock_level_mode = Middle, the lock synchronization mode is determined to be the semi-strong synchronization mode, and the lock pass probability parameter lock_succ_node_num is read from the configuration file to determine whether the lock pass probability parameter lock_succ_node_num is legal. If the lock pass 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, the lock pass probability parameter lock_succ_node_num is legal, then continue processing according to the semi-strong synchronization mode; if the lock pass probability parameter lock_succ_node_num is less than 1, or greater than the number of all computing devices in the cluster, then continue processing according to the strong synchronization mode. In the semi-strong synchronization mode, it can also be discussed in three situations: A) If the waiting timeout has not yet occurred, that is, the waiting time does not exceed the second waiting threshold, and the received locking feedback information indicates that the number of second computing devices that have successfully locked is greater than or equal to the target number, then the target condition is met and it is regarded as a global lock success; in another possible implementation, if the received locking feedback information indicates that the number of second computing devices that have successfully locked plus one is greater than or equal to the lock pass probability parameter lock_succ_node_num, it is also determined that the target condition is met and it is regarded as a global lock success; B) If the received locking feedback information indicates that the number of second computing devices that have failed to lock is greater than the total number of second computing devices in the cluster, then the target condition is met and it is regarded as a global lock success. If the value obtained by subtracting the target number from the number of the second computing devices does not meet the target condition, it is regarded as a global lock failure; in another possible implementation, if the received lock feedback information indicates that the value obtained by adding one to the number of second computing devices that failed to lock is greater than the value obtained by subtracting the lock pass probability parameter lock_succ_node_num from all computing devices in the cluster, it is also determined that the target condition is not met and it is regarded as a global lock failure; C) If the waiting time exceeds the second waiting threshold and there are still a large number of second computing devices that have not returned the lock feedback information, resulting in neither situation A) nor situation B) being met, it means that the waiting has timed out, and the target condition is not met, and it is regarded as a global lock failure.

[0122] In some embodiments, if it is determined that the acquired locking feedback information meets the target condition, an operation similar to the above step 302 is performed, that is, the data resource corresponding to the data request is locked and the data request is executed, which is not repeated here.

[0123] In some embodiments, when the acquired locking feedback information does not meet the target condition or the data request is executed, a lock release request is sent to the at least one second computing device, and the lock release request is used to instruct the second computing device to release the data resources corresponding to the data request.

[0124] In the above process, if the obtained lock feedback information does not meet the target conditions, then the global lock fails. However, it is very likely that the current data request has already successfully applied for a lock on some second node devices. Therefore, the first computing device needs to promptly send a lock release request to each second computing device whose lock feedback information indicates a successful lock, thereby promptly releasing the lock on the corresponding data resource. Optionally, the lock release request can be directly broadcast to all second computing devices. The second computing devices that successfully locked the data resource will release the lock on the corresponding data resource, but the second computing devices that failed to lock the data resource will not perform any processing.

[0125] Optionally, the first computing device does not need to wait for each second computing device to return feedback information on the lock release. This is ensured by the detection mechanism in the following embodiment to improve the request processing efficiency of the system. Of course, the first computing device can also wait for each second computing device to return feedback information on the lock release before completing the locking process, so as to timely detect whether some second computing devices have failed to receive the lock release request due to network packet loss. The embodiment of the present application does not limit this. In another scenario, if the obtained locking feedback information meets the target conditions, after the first computing device successfully globally locks and completes the execution of the data request such as the DDL request, it is also necessary to notify the other second computing devices to release the lock of the corresponding data resource in a timely manner. The method of sending the lock release request is similar to the above case and will not be repeated here.

[0126] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present disclosure, and will not be described in detail here.

[0127] The method provided in the embodiment of the present application sets multiple flexible levels of lock synchronization modes. In weak synchronization mode, the data resource corresponding to the data request is directly locked and the data request is executed, thereby ensuring that the data request is prioritized without waiting for the response of the second computing device. In non-weak synchronization mode, the locking feedback information of each second computing device is obtained. Only when the obtained locking feedback information meets the target conditions is the data resource locked and the data request executed, so that different lock synchronization modes are selected in different business scenarios, thereby ensuring that the cluster database can meet the processing requirements of different business scenarios and improving the processing capability of the cluster database system.

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

[0129] FIG4 is an interactive flow chart of a request processing method provided in an embodiment of the present application. As shown in FIG4 , this embodiment is applied to a cluster database. The cluster database includes a first computing device and at least one second computing device. The first computing device is a computing device for processing the data request. All computing devices in the cluster except the first computing device are referred to as second computing devices. This embodiment includes the following steps:

[0130] 401. The application client sends a data request to a first computing device in a cluster database.

[0131] Optionally, the cluster database is a central cluster database or a distributed cluster database, both of which are applicable to the request processing method. The embodiment of the present application only takes the distributed cluster database as an example for description.

[0132] In some embodiments, a user logs in to an application client on a terminal, triggering the application client to generate the data request. Optionally, the data request is a DDL request, or the data request is a DML request. In the embodiments of the present application, the data request is a DDL request 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 can call an API to send the data request to the first computing device.

[0133] 402. The first computing device determines a lock synchronization mode of the cluster database in response to the data request.

[0134] The above step 402 is similar to the above step 301 and will not be described in detail here.

[0135] 403. When 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.

[0136] The above step 403 is similar to the above step 302 and will not be described in detail here.

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

[0138] If the lock synchronization mode is not a weak synchronization mode, then the lock synchronization mode may be a strong synchronization mode or a semi-strong synchronization mode. In the above-mentioned strong synchronization mode or semi-strong synchronization mode, the first computing device needs to apply for a lock from each remote second computing device, but the target conditions for determining the success of the lock application are different. In the strong synchronization mode, all second computing devices must apply for a lock successfully before the global lock application for the data resource is considered successful. In the semi-strong synchronization mode, only a number of second computing devices, not less than the target number, need to apply for a lock successfully before the global lock application for the data resource is considered successful.

[0139] In some embodiments, the first computing device applies for a lock from each second computing device to obtain locking feedback information from each second computing device. Optionally, the locking feedback information includes: locking success and locking failure. The reasons for locking failure are usually various, such as waiting timeout, deadlock, etc.

[0140] Optionally, a message processing thread can be created in the background on the first computing device and each second computing device. The message processing thread can be specifically used to process various messages related to the locking mechanism, such as monitoring lock requests, lock release requests, lock feedback information, lock release feedback information, etc. from other computing devices, and timely sending and receiving various messages related to the locking mechanism to ensure communication performance between computing devices.

[0141] Based on the above situation, when sending a lock request, the first computing device may send the lock request to the message processing thread on the at least one second computing device through the message processing thread on the first computing device.

[0142] 405. For any second computing device, in response to a lock request associated with the data request, add the lock request to a lock waiting queue.

[0143] The lock request is sent by the first node device in the cluster database when the lock synchronization mode is not a weak synchronization mode.

[0144] In some embodiments, the second computing device receives the lock request via a message processing thread; initiates a lock proxy thread corresponding to the lock request via the message processing thread; and adds the lock request to the lock wait queue via the lock proxy thread. Optionally, each lock request corresponds to a lock proxy thread to reduce the waiting delay of each lock request. Optionally, multiple lock requests can reuse the same lock proxy thread. In this case, the later-arriving lock request needs to be stored in the lock wait queue, and the lock proxy thread processes each lock request stored in the lock wait queue in sequence.

[0145] In the above process, by configuring a message processing thread specifically responsible for sending and receiving lock-related messages on both the first computing device and the second computing device, the message processing thread can start a lock proxy thread during the lock application process to maintain the life cycle of the remote lock on each second computing device. In addition, it is possible that when the lock feedback information of the second computing device reaches the first computing device, the lock application thread on the first computing device has already exited. In this case, due to the configuration of the message processing thread, the message processing thread of the first computing device can determine whether the current data request is active and whether the lock feedback information indicates that the lock is successful through the operation in the following step 408. In the event that the data request is not active, a lock release request is returned to the second computing device that has successfully locked, triggering the release of the remote lock that has been successfully applied for, so as to achieve the purpose of not blocking the business on the second computing device.

[0146] 406. The second computing device processes the lock request in the lock waiting queue and obtains lock feedback information, where the lock feedback information is used to indicate whether the second computing device successfully locks the data resource.

[0147] In some embodiments, the second computing device starts a local lock proxy thread and calls the local lock application logic to process each lock request cached in the lock waiting queue. The lock proxy thread traverses the lock waiting queue. If the data resource corresponding to the data request sent by the first computing device is locked, it means that the lock request has been processed and the lock feedback information is determined to be a successful lock; otherwise, it is necessary to continue waiting in the lock waiting queue until the wait times out or a deadlock occurs, and the lock feedback information is determined to be a lock failure. That is to say, if the waiting time of the lock request in the lock waiting queue exceeds a third waiting threshold, or the deadlock detection fails, the lock feedback information is determined to be a lock failure. The third waiting threshold is any value greater than 0, for example, the third waiting threshold is 5 seconds. The third waiting threshold can also be added to the configuration file and loaded by the database engine of each computing device when the cluster database is started.

[0148] In the above process, it can be seen that there are at least two situations in which locking fails: a) waiting timeout, that is, the cache length of the lock request in the lock waiting queue exceeds the third waiting threshold, then it can be considered that the lock has failed; b) deadlock detection fails, indicating that a deadlock is found in the deadlock detection, and the second computing device itself is selected as the deadlock victim, then the lock application cannot be completed.

[0149] In some embodiments, the deadlock detection process 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 a local deadlock detection on the lock request; if the local deadlock detection fails, it is determined that the deadlock detection fails; if the local deadlock detection passes, the lock wait chain of the lock request is determined, and the lock wait chain includes lock information that has a dependency relationship with the lock request; if the lock wait chain includes a remote lock, a deadlock detection message is sent to a third computing device that initiates the remote lock, and the remote lock is lock information that has been registered in the second computing device but not initiated 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.

[0150] Alternatively, a deadlock detection message can be initiated by the first computing device. For example, if the first computing device has not received lock feedback information from the second computing device after a relatively long period of time, but has not yet timed out, the message processing thread of the first computing device can send a deadlock detection message to the message processing thread of the second computing device. Upon receiving the deadlock detection message, the second computing device first performs a local deadlock check. If the local deadlock check fails, it does not need to traverse the lock wait chain and directly returns a lock feedback message to the first computing device. This lock feedback message indicates that the lock failed, and the failure type is that the device was selected as the deadlock victim. If the local deadlock check passes, it is still not completely certain that a deadlock does not exist. Therefore, it is necessary to traverse the corresponding lock wait chain and determine whether each lock in the lock wait chain is a remote lock. If it is a remote lock, a deadlock detection message is sent to the lock holder of the remote lock (i.e., a third computing device), triggering the third computing device to execute a deadlock detection process similar to that of the second computing device. That is, the third computing device first performs a local deadlock check, then traverses the remote locks in the lock wait chain and sends a deadlock detection message again. If any computing device, as the sender of a deadlock detection message, receives the same deadlock detection message from another computing device, indicating that it is in a deadlock, then this computing device returns a locking feedback message to the first computing device, indicating that the locking failed, and the failure type is that it was selected as the deadlock victim. For example, the first computing device sends a deadlock detection message to the second computing device, and the second computing device has a remote lock on the lock waiting chain, and the lock holder of the remote lock is the first computing device. Then the second computing device sends a deadlock detection message to the first computing device. At this time, a dependency loop phenomenon occurs, that is, lock A waits for lock B, and lock B waits for lock A. That is, the first computing device, as the sender of the deadlock detection message, receives the same deadlock detection message sent by the second computing device, indicating that a deadlock has been found and the current locking failed.

[0151] In some embodiments, if the second computing device successfully locks, then when the data resource corresponding to the data request is locked, the lock proxy thread of the second computing device registers the lock information corresponding to the data request in the message processing thread; at each target interval, it is determined whether the registered lock information is active lock information; if the lock information is active lock information and the locking duration of the data resource corresponding to the data request exceeds the detection threshold, a detection request is sent to the first computing device, the detection request being used to request the first computing device to indicate whether to release the data resource locked by the active lock information. The detection threshold can be any value greater than 0, for example, the detection threshold is 20 seconds.

[0152] In the above process, if the lock is successfully acquired, the lock proxy thread registers the corresponding lock information in the message processing thread to facilitate the message processing thread to manage the various locks that have been successfully applied locally, and the message processing thread can periodically check the active lock information in the registration table. If the active lock information is still not released when the detection threshold is exceeded, for example, there are the following possibilities at this time: i) the data request of the first computing device is executed, but the released lock request sent results in packet loss; ii) the lock application thread of the first computing device crashes; iii) the first computing device processes normally, but this data request, such as the DDL transaction itself, takes a long time. At this time, if it belongs to the above situations i) and ii), by sending the detection request, it can trigger the first computing device to send the release lock message again, instructing the second computing device to release the corresponding lock. If it belongs to the above situation iii), then the second computing device cannot release the corresponding lock and still needs to continue to hold the corresponding lock.

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

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

[0155] The above steps 405-407 introduce the process of applying for a remote lock by taking a single second computing device as an example. Similar operations as steps 405-407 can be performed on each second computing device in the cluster, and are not described in detail here.

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

[0157] Optionally, when receiving the locking feedback information, the first computing device may receive the locking feedback information returned by the message processing thread on the at least one second computing device through the message processing thread on the first computing device.

[0158] In some embodiments, since the first computing device sends the lock request to each second computing device in the cluster, and the time when the lock feedback information of each second computing device is returned to the first computing device may be different, in some exemplary scenarios, if the processing process of the data request on the first computing device (such as the DDL process) crashes, after the DDL process crashes, the first computing device should, depending on the situation, promptly instruct the second computing device that has successfully locked the lock to release the corresponding lock for the lock feedback information it receives, so as to avoid blocking other DML processes on the data resource, so as to optimize the processing performance of the cluster database.

[0159] In response to the above situation, the first computing device can respond to receiving the locking feedback information from any second computing device, and when the data request is in an active state, send the locking feedback information to the lock application thread of the data request through the message processing thread; when the data request is not in an active state and the locking feedback information indicates that the locking is successful, send a lock release request to the second computing device, and the lock release request is used to instruct the second computing device to release the data resources corresponding to the data request.

[0160] Optionally, after receiving any lock feedback information through the message processing thread, the first computing device determines whether the local data request is active. Taking the DDL request as an example, it can determine whether the DDL process corresponding to the DDL request exists. Since there may be multiple DDL requests reusing the same DDL process, the DDL process may still exist even if the current DDL request has failed (for example, the target condition is not met and the DDL transaction is rolled back). Therefore, there is a certain degree of misjudgment when judging whether the DDL request is active based on the DDL process. Optionally, it is also possible to directly determine whether the DDL transaction corresponding to the DDL request is in an active state, which can effectively reduce the above-mentioned misjudgment and improve the accuracy of the judgment.

[0161] If the data request is not active, that is, the data request is not in an active state, determine whether the locking feedback information indicates that the locking is successful. If the locking feedback information indicates that the locking is successful, it means that the local DDL request has ended, but the lock of the corresponding data resource has been successfully applied for on the remote second computing device. At this time, it is necessary to instruct the second computing device to release the lock of the corresponding data resource in time. Therefore, the first computing device can send 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 an idle state; in addition, if the locking feedback information is a locking failure, it means that there is no data resource that needs to be released in time on the remote end, so no processing is required.

[0162] If the data request is active, that is, the data request is in an active state, then the lock feedback information can be sent to the lock application thread of the data request through the message processing thread, so that the lock application thread records the lock feedback information received this time, and judges whether it meets the target conditions based on the following step 409, thereby facilitating the lock application thread to timely count whether the received lock feedback information meets the target conditions corresponding to the current lock synchronization mode.

[0163] In the above steps 404-408, it is shown how the first computing device obtains the locking feedback information of the data resource from at least one second computing device in the cluster database. In some embodiments, the first computing device can also directly send the locking request in a broadcast or multicast manner in the cluster database, and receive the locking feedback information returned by each second computing device. It is also possible not to set up a dedicated message processing thread, but for the lock application thread on the first computing device and the lock proxy thread on the second computing device to communicate directly, which can reduce the communication overhead between threads.

[0164] 409. When the acquired locking feedback information satisfies the target condition corresponding to the lock synchronization mode, the first computing device locks the data resource corresponding to the data request and executes the data request.

[0165] The above step 409 is similar to the above step 304 and will not be described in detail here.

[0166] 410. When the acquired lock feedback information does not meet the target condition or the data request is executed, the first computing device sends a lock release request to the at least one second computing device.

[0167] The lock release request is used to instruct the second computing device to release the data resource corresponding to the data request.

[0168] Optionally, the message processing thread of the first computing device sends a lock release request to the message processing threads of each second computing device. The process of sending the lock release request is similar to the process of sending the lock request, and will not be described in detail here.

[0169] 411. For any second computing device, in response to a lock release request associated with the data request, release the data resource corresponding to the data request.

[0170] Optionally, the message processing thread of the second computing device receives the lock release request and notifies the lock proxy thread to release the corresponding data resources. For example, the lock proxy thread modifies the memory state parameter of the lock to the idle state and clears the corresponding lock information in the registry. At this point, the message processing is completed, and the received messages can be discarded to save storage space.

[0171] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present disclosure, and will not be described in detail here.

[0172] The method provided in the embodiment of the present application sets multiple flexible levels of lock synchronization modes. In weak synchronization mode, the data resource corresponding to the data request is directly locked and the data request is executed, thereby ensuring that the data request is prioritized without waiting for the response of the second computing device. In non-weak synchronization mode, the locking feedback information of each second computing device is obtained. Only when the obtained locking feedback information meets the target conditions is the data resource locked and the data request executed, so that different lock synchronization modes are selected in different business scenarios, thereby ensuring that the cluster database can meet the processing requirements of different business scenarios and improving the processing capability of the cluster database system.

[0173] FIG5 is a schematic diagram illustrating a locking process according to an embodiment of the present application. As shown in FIG500 , a cluster database includes compute node 1 and compute node 2. Compute node 1 is a first computing device, on which a lock application thread and a message processing thread are running. Compute node 2 is a second computing device, on which a message processing thread and a lock proxy thread are running. Taking a DDL request as an example, after the lock application thread of compute node 1 successfully applies for a lock locally, it enters the global locking process. The global locking process is described in detail below:

[0174] Step 1: Complete the local lock application first, then enter the locking process.

[0175] Step 2: The lock request thread of computing node 1 determines whether it is in weak synchronization mode. If it is, there is no need to send a lock request to other nodes. It is directly considered that the lock has been acquired (correctness is guaranteed by the write barrier mechanism) and jumps to step 28. If it is not in weak synchronization mode, go to step 3.

[0176] Step 3: If the weak synchronization mode is not in effect, a lock request is sent to other nodes, and the process goes to step 4, and then to step 26 to start timing.

[0177] Step 4: The message processing thread of computing node 2 receives the lock request.

[0178] Among them, the message processing thread specifically monitors the lock requests, lock release requests and lock feedback information of other nodes in the background, and is responsible for sending and receiving various lock-related messages. In the lock application stage, the message processing thread acts as the message receiving end and calls the lock proxy thread to maintain the life cycle of the remote lock on computing node 2. In the lock feedback information return stage, it may happen that when the lock feedback information reaches the application end (computing node 1), the lock application thread of the application end has crashed or exited. In this case, the message processing thread on computing node 1 will determine whether it is necessary to send a lock release request to computing node 2 to release the remote lock that has been successfully applied for by the remote end based on whether the lock application thread has exited and whether the lock feedback information indicates that the lock is successfully acquired.

[0179] Step 5: Compute node 2 starts the local lock agent thread and calls the local lock application logic.

[0180] Step 6: Determine whether the lock corresponding to the DDL request has been successfully applied. If so, proceed to Step 8. If not, the application may fail in the following situations: 6.1) The lock request is still waiting in the lock waiting queue. In this case, continue waiting and proceed to Step 7 to determine whether it has timed out; 6.2) A deadlock is detected during deadlock detection, and the system is selected as the deadlock victim. Proceed to Step 8.

[0181] Step 7: Determine whether the remote lock request has timed out. If not, continue waiting. If not, proceed to step 8.

[0182] For example, when determining whether a timeout occurs, it is determined whether the waiting time exceeds a third waiting threshold.

[0183] Step 8: Send locking feedback information to the message processing thread of computing node 1, and proceed to step 10.

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

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

[0186] Step 9: The message feedback interface of the message processing thread of computing node 2 mainly processes the liveness detection request triggered by the liveness detection mechanism of steps 10-13 and sends the liveness detection request to the message processing thread of computing node 1.

[0187] The liveness check request is used in a distributed environment when the lock application thread on the lock application end (compute node 1) has exited, but the remote lock on compute node 2 has not been released. If the remote lock remains unreleased after a certain period of time (such as the liveness check threshold), a liveness check request is sent to the lock application end (i.e., the lock holder) to perform a liveness check.

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

[0189] Lock information includes but is not limited to: lock type (read lock, write lock, update lock, etc.), data resource targeted by the lock (such as database name, data table name, data index ID, data column name, etc.), lock time, etc.

[0190] Lock status includes but is not limited to: active state, inactive state, etc.

[0191] Step 11: The message processing thread of computing node 2 periodically checks the active locks in each remote lock in the registry.

[0192] For example, traverse each lock information in the registry and query the remote locks that are in active state.

[0193] Step 12: Determine whether there is a remote active lock that exceeds the detection threshold. If so, proceed to step 13. If not, continue to periodically monitor the lock information in the registry.

[0194] Step 13: Prepare to respond to the liveness request and proceed to step 9.

[0195] Step 14: The message processing thread of computing node 1 receives the lock feedback information and the liveness detection request.

[0196] Step 15: Determine whether the local lock request thread is active. If not, proceed to step 16; if active, proceed to step 21.

[0197] Among them, in the active case, it can be divided into three situations: 15.1) The current lock application thread is active and is in the lock application stage, then the corresponding lock application structure data is updated and sent to the lock application thread for processing; 15.2) The current lock application thread has reached the target condition for successful lock application in semi-strong synchronization mode, and the corresponding lock application structure data is updated to complete the operation; 15.3) The current lock application thread is in lock exit, or the lock application fails to exit (for example, it has been determined that the target condition is not met in semi-strong synchronization mode), the corresponding lock application structure data is updated to complete the operation.

[0198] Optionally, the lock application structure data is used to record the locking feedback information of each computing node 2, for example, in the form of a hash table, array, set, vector, etc., such as a set form, where each element in the set represents whether a computing node is locked successfully or failed. An element of 0 represents a locking failure, an element of 1 represents a locking success, and an element that is empty (null) represents that no locking feedback information has been received.

[0199] Step 16: If the locking feedback information indicates that the locking is successful, or the received message is a liveness detection request, proceed to step 17; otherwise, no processing is performed, proceed to step 32, i.e., the message processing is completed, and the received message is discarded.

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

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

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

[0203] Step 20: The lock agent thread of computing node 2 releases the lock.

[0204] Step 21: The lock application thread of computing node 1 receives the lock feedback information sent by the message processing thread, which includes several types of lock feedback information involved in step 8.

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

[0206] Step 23: Check whether the lock pass 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 in semi-strong synchronization mode; if it is not a valid value, proceed to step 25 in strong synchronization mode.

[0207] Step 24: Determine whether the number of remote nodes that have successfully locked plus the number of local nodes exceeds the lock pass probability parameter lock_succ_node_num. If so, proceed to step 28. If not, determine whether the lock application has timed out, that is, whether the waiting time exceeds the second waiting threshold. If the waiting has not timed out, continue waiting. If the waiting has timed out, the lock fails. If the feedback shows that the number of remote nodes that have failed to lock exceeds the value obtained by subtracting the lock pass probability parameter lock_succ_node_num from the total number of nodes in the cluster, it is determined that the lock has failed, and proceed to step 29.

[0208] Step 25: In the strong synchronization mode, it is necessary to determine whether all nodes have reported a successful lock. If the above conditions are met, proceed to step 28; if not, but the waiting time has not yet timed out, that is, the waiting time does not exceed the first waiting threshold, then continue waiting; if any node reports a lock failure, it is determined that the lock has failed, and proceed to step 29.

[0209] Step 26: Start calculating the lock application time.

[0210] Step 27, determine whether the lock application time has timed out. If so, proceed to step 29, i.e., locking fails; if not, continue to return to step 21 to check the logic.

[0211] Optionally, the timeout threshold in the strong synchronization mode is the first waiting threshold, and the timeout threshold in the semi-strong synchronization mode is the second waiting threshold, and the two values ​​may be the same or different.

[0212] Step 28: Global locking is successful.

[0213] Step 29: Global locking failed.

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

[0215] Optionally, since the liveness detection logic of steps 11-20 exists on other nodes, computing node 1 can end the process without waiting for other nodes to return lock release feedback information after sending the lock release request.

[0216] Step 31: Complete the locking process.

[0217] Step 32: After the message is processed, discard the message.

[0218] In the embodiments of this application, a locking process is described in detail, enabling the implementation of a flexible locking mechanism in a distributed database to ensure the correctness of operations when each process or thread modifies a specific data resource. Furthermore, through the implementation of this flexible locking mechanism, flexible switching between weak synchronization mode, semi-strong synchronization mode, and strong synchronization mode is possible, allowing the distributed database cluster to select different levels of locking mechanisms based on the needs of its own database application scenarios to meet the business needs of users in different business scenarios.

[0219] Figure 6 is a schematic diagram of a lock release process provided by an embodiment of the present application. As shown in 600, the cluster database includes computing node 1 and computing node 2. Computing node 1 is a first computing device, and computing node 2 is a second computing device. Computing node 2 runs a message processing thread and a lock proxy thread. After computing node 1 successfully locks the global lock, it executes the corresponding data request, such as a DDL request. After the local DDL transaction processing logic is completed, the lock release process can be entered. The lock release process is described in detail below:

[0220] Step 1: After the local processing logic of the DDL transaction is completed, the lock release process begins.

[0221] After compute node 1, which holds the lock, completes the computational logic for the DDL transaction, it needs to release the lock globally. In this embodiment, the global lock release process is described using the sequence of releasing the remote lock first and then the local lock as an example. In this case, the overall lock acquisition and release process is: local lock → remote lock → remote lock release → local lock release.

[0222] Step 2: Determine whether it is weak synchronization mode. If it is weak synchronization mode, proceed to step 10 without releasing the remote lock. If it is not weak synchronization mode, proceed to step 3.

[0223] Step 3: Send a lock release request to other nodes.

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

[0225] Step 5: The message processing thread starts the lock proxy thread to release the corresponding remote lock locally.

[0226] For example, if the lock proxy thread is in a suspended state, the message processing thread wakes up the lock proxy thread and performs a lock release operation.

[0227] Step 6: The lock proxy thread releases the corresponding remote lock locally. If the release is successful, go to step 7. If the release fails, release it again.

[0228] Step 7: Prepare to clean the corresponding lock information in the registry.

[0229] Step 8. Clear the registered lock information in the registry.

[0230] Step 9: The lock agent thread exits.

[0231] Step 10: Release the lock successfully.

[0232] Step 11: The lock release process ends.

[0233] In the embodiment of the present application, a detailed description is given of how to release the lock after the DDL request is executed. It should be noted that if the detection mechanism detects that the DDL thread has crashed or does not meet the target conditions in the lock synchronization mode, the triggered lock release process is similar to the embodiment of the present application and will not be repeated here.

[0234] FIG7 is a schematic diagram of a deadlock detection process according to an embodiment of the present application. As shown in 700, the cluster database includes computing node 1 and computing node 2. Computing node 1 is a first computing device, computing node 2 is a second computing device, and a message processing thread is running on computing node 2. The deadlock detection process is described below:

[0235] Step 1: Compute node 1 wants to lock data resource A.

[0236] Step 2: Send a deadlock detection message to other nodes and proceed to step 3 and step 10.

[0237] Step 3: The message processing thread of computing node 2 receives the deadlock detection message.

[0238] For example, a deadlock detection message includes relevant lock information.

[0239] Step 4: Apply 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 it has been selected as the deadlock victim.

[0240] Step 5: Traverse the lock wait chain.

[0241] Step 6: Determine whether the current lock in the lock waiting chain is a remote lock. If it is a remote lock, proceed to step 7; if it is not a remote lock, traverse the next lock on the lock waiting chain.

[0242] Step 7: Send a deadlock detection message to the lock holder.

[0243] In the embodiment of the present application, the lock holder is taken as computing node 1 as an example.

[0244] Step 8: Receive a deadlock detection message.

[0245] Step 9: If it is found that the deadlock detection message forms a closed loop, a deadlock occurs.

[0246] Step 10: Register lock information with the local message processing thread.

[0247] In the embodiment of the present application, not only is local deadlock detection logic required, but it is also adapted to the distributed database. When traversing the lock wait chain, it is determined whether it is a remote lock. If it is not a remote lock, then the local deadlock detection logic can detect whether a deadlock occurs. If it is a remote lock, then a deadlock detection message is sent to the lock holder (that is, the computing node where the lock holding thread is located). If the lock holding node and the computing node that initiates the deadlock detection are the same node, then it means that a closed loop is formed, that is, a deadlock occurs. For example, in the embodiment 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. In the event of a deadlock, the current lock application operation will be rejected. At this time, the database engine can automatically retry after a period of time, or return a rejection message to the user, allowing the user to actively initiate a retry after waiting for a period of time.

[0248] The locking process, lock release process, and deadlock detection process in the distributed database are introduced in detail in the above embodiments. In the embodiments of this application, the performance of this lock synchronization mechanism in abnormal scenarios will be analyzed in detail to illustrate how the above lock synchronization mechanism copes with abnormal scenarios such as network partitioning, network instability, network latency, or network packet loss of computing nodes in the distributed scenario.

[0249] If the administrator selects the weak synchronization mode, since the weak synchronization mode does not require applying for a lock from the remote end, the correctness of resource operations is guaranteed by the write barrier mechanism. Therefore, it is equivalent to having a higher priority for DDL transactions that need to apply for a lock. However, as the DDL transaction progresses, it may roll back the user's DML transaction. Usually, the DML transaction is the key business of the user. Therefore, in some scenarios, the user experience is poor, but it is suitable for application scenarios with more DDL transactions.

[0250] If the administrator selects the strong synchronization mode, it can ensure equal treatment of DDL transactions and DML transactions. However, in the case of poor network conditions, since the DDL transaction needs to apply for a global lock and has to wait for all other nodes in the cluster to return the lock application feedback information, if one or several nodes have partitioning or network latency and the lock application feedback information is not returned in a timely manner, during this waiting period, the execution of DML transactions will be rejected by other nodes in the entire distributed cluster because the lock has been successfully granted, ultimately resulting in a slow response speed of the entire cluster and a poor user experience that the entire cluster cannot provide services. Therefore, in the case of poor network conditions, the strong synchronization mode also has a poor user experience.

[0251] If the administrator selects the semi-strong synchronization mode, it can provide a compromise option, that is, it provides a flexible and configurable cluster operation mode between the impact brought by the network problems in the above distributed system and the user's high demand for the successful execution of the business. The semi-strong synchronization mode needs to set a lock pass probability parameter lock_succ_node_num to determine how many nodes' returns are considered a successful global lock application: If lock_succ_node_num = 0, it is actually equivalent to the weak synchronization mode; if lock_succ_node_num = n, where n is the total number of nodes (i.e., computing devices) in the cluster, it is actually equal to the strong synchronization mode; if 0 < lock_succ_node_num < n, it is the semi-strong synchronization mode.

[0252] By providing the lock pass probability parameter lock_succ_node_num, the administrator can set a reasonable value according to the network conditions of his own cluster, ensuring fair treatment between the user's DML transactions and DDL transactions to the greatest extent, and at the same time, the entire cluster will not become unavailable, such as being hung up, due to the non-response of one or more nodes.

[0253] In addition, steps 10-20 in the above locking process also provide a liveness detection mechanism to ensure that if the lock holder (owner) of a lock fails to send a lock release request to other nodes for some reason, the remote node can actively detect the liveness through the liveness detection mechanism and release the remote lock.

[0254] In an embodiment of the present application, a flexible locking mechanism is provided to provide administrators with a flexible adjustment method for determining the lock synchronization mode according to the network environment in which the distributed database cluster operates and the requirements for the success rate of DML transactions. This can maximize the use of the computing power of the distributed cluster by users, and at the same time, it can also make the external performance of each node of the distributed cluster during operation consistent with the performance of a single-node database system.

[0255] FIG8 is a schematic diagram of the structure of a request processing device provided in an embodiment of the present application. Referring to FIG8 , the device includes:

[0256] Determining module 801, configured to determine a lock synchronization mode of a cluster database in response to a data request;

[0257] The lock execution module 802 is used to lock the data resource corresponding to the data request and execute the data request when the lock synchronization mode is the weak synchronization mode;

[0258] A first acquisition module 803 is configured to, when the lock synchronization mode is not the weak synchronization mode, acquire locking feedback information of the data resource from at least one second computing device in the cluster database, the locking feedback information being used to indicate whether the second computing device has successfully locked the data resource;

[0259] The lock execution module 802 is further configured to lock the data resource corresponding to the data request and execute the data request when the acquired lock feedback information meets the target condition corresponding to the lock synchronization mode.

[0260] The device provided in the embodiment of the present application sets multiple flexible levels of lock synchronization modes. In weak synchronization mode, the data resource corresponding to the data request is directly locked and the data request is executed, thereby ensuring that the data request is prioritized without waiting for the response of the second computing device. In non-weak synchronization mode, the locking feedback information of each second computing device is obtained. When the obtained locking feedback information meets the target condition, the data resource is locked and the data request is executed, so that different lock synchronization modes are selected in different business scenarios, thereby ensuring that the cluster database can meet the processing requirements of different business scenarios and improving the processing capability of the cluster database system.

[0261] In one possible implementation, based on the apparatus composition of FIG8 , the first acquisition module 803 includes:

[0262] a sending unit, configured to send a lock request associated with the data request to the at least one second computing device;

[0263] A receiving unit is configured to receive the locking feedback information returned by the at least one second computing device based on the locking request.

[0264] In one possible implementation, the sending unit is configured to: send the lock request to the message processing thread on the at least one second computing device respectively through the message processing thread on the first computing device;

[0265] The receiving unit is configured to receive, through the message processing thread on the first computing device, the locking feedback information returned by the message processing thread on the at least one second computing device.

[0266] In one possible implementation, based on the device composition of FIG8 , the device further includes:

[0267] a sending module, configured to, in response to receiving locking feedback information from any second computing device, send the locking feedback information to the lock application thread of the data request through the message processing thread when the data request is in an active state;

[0268] The sending module is further configured to send a lock release request to the second computing device when the data request is not in an active state and the locking feedback information indicates that the locking is successful. The lock release request is configured to instruct the second computing device to release the data resource corresponding to the data request.

[0269] In one possible implementation, 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 that the locking is successful; when the lock synchronization mode is a semi-strong synchronization mode, the target condition is that the locking feedback information of no less than a target number of second computing devices among the at least one second computing device indicates that the locking is successful.

[0270] In one possible implementation, when the lock synchronization mode is a strong synchronization mode, the target condition is that the waiting time does not exceed the first waiting threshold, and the locking feedback information of the at least one second computing device all indicates that the locking is successful; when the lock synchronization mode is a semi-strong synchronization mode, the target condition is that the waiting time does not exceed the second waiting threshold, and the locking feedback information of no less than the target number of second computing devices among the at least one second computing device indicates that the locking is successful.

[0271] In one possible implementation, based on the device composition of FIG8 , the device further includes:

[0272] A second acquisition module is used to acquire the target number when the lock synchronization mode is a semi-strong synchronization mode;

[0273] The switching module is configured to switch the lock synchronization mode to the strong synchronization mode when the target number is less than one or greater than the number of all second computing devices in the cluster database.

[0274] In one possible implementation, based on the device composition of FIG8 , the device further includes:

[0275] The sending module is used to send a lock release request to the at least one second computing device when the obtained locking feedback information does not meet the target condition or the data request is executed. The lock release request is used to instruct the second computing device to release the data resource corresponding to the data request.

[0276] In one possible implementation, the data request is a data definition language DDL request.

[0277] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present disclosure, and will not be described in detail here.

[0278] It should be noted that the request processing device provided in the above embodiment only uses the division of the above functional modules as an example to illustrate the processing of data requests. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computing device can be divided into different functional modules to complete all or part of the functions described above. In addition, the request processing device provided in the above embodiment and the request processing method embodiment are based on the same concept. The specific implementation process is detailed in the request processing method embodiment and will not be repeated here.

[0279] FIG9 is a schematic diagram of the structure of a request processing device provided in an embodiment of the present application. Referring to FIG9 , the device includes:

[0280] An adding module 901 is configured to, in response to a lock request associated with a data request, add the lock request to a lock waiting queue; the lock request is sent by a first computing device in the cluster database when the lock synchronization mode is not a weak synchronization mode;

[0281] Processing module 902, configured to process the lock request in the lock waiting queue and obtain lock feedback information;

[0282] The sending module 903 is configured to send the locking feedback information to the first computing device.

[0283] The apparatus provided in the embodiment of the present application sets multiple flexible levels of lock synchronization modes. Only when the first computing device is not in weak synchronization mode will it send a lock request, so that in response to the lock request, corresponding lock feedback information is returned, triggering the first computing device to lock the data resource and execute the data request when the acquired lock feedback information meets the target conditions, so that the cluster database supports the selection of different lock synchronization modes in different business scenarios, thereby ensuring that the cluster database can meet the processing requirements of different business scenarios and improving the processing capability of the cluster database system.

[0284] In one possible implementation, the processing module 902 is configured to:

[0285] Locking the data resource corresponding to the data request, and determining the locking feedback information as indicating successful locking;

[0286] If the waiting time of the lock request in the lock waiting queue exceeds a third waiting threshold, or the deadlock detection fails, the lock feedback information is determined as indicating a lock failure.

[0287] In one possible implementation, based on the device composition of FIG9 , the device further includes:

[0288] a detection module, configured to perform a local deadlock detection on the lock request in response to a deadlock detection message from the first computing device;

[0289] A first determining module, configured to determine that the deadlock detection fails when the local deadlock detection fails;

[0290] A second determining module is configured to determine a lock waiting chain of the lock request if the local deadlock detection passes, the lock waiting chain including lock information having a dependency relationship with the lock request;

[0291] The sending module 903 is further configured to send a deadlock detection message to a third computing device that initiated the remote lock when the lock waiting chain includes a remote lock, where the remote lock is lock information that has been registered in the second computing device but not initiated by the second computing device;

[0292] The first determining module is further configured to determine that the deadlock detection fails when any computing device that sends the deadlock detection message receives the deadlock detection message again.

[0293] In one possible implementation, the adding module 901 is used to:

[0294] Receiving the lock request through a message processing thread on the second computing device;

[0295] Start the lock proxy thread corresponding to the lock request through the message processing thread;

[0296] The lock request is added to the lock waiting queue through the lock proxy thread.

[0297] In one possible implementation, based on the device composition of FIG9 , the device further includes:

[0298] A registration module, configured to register lock information corresponding to the data request when the data resource corresponding to the data request is locked;

[0299] a third determining module, configured to determine whether the lock information is active lock information at intervals of a target duration;

[0300] The sending module 903 is further configured to send a detection request to the first computing device when the lock information is active lock information and the lock duration of the data resource corresponding to the data request exceeds the detection threshold. The detection request is configured to request the first computing device to indicate whether to release the data resource.

[0301] In one possible implementation, based on the device composition of FIG9 , the device further includes:

[0302] The release module is configured to release the data resource corresponding to the data request in response to a lock release request associated with the data request.

[0303] All the above optional technical solutions can be arbitrarily combined to form optional embodiments of the present disclosure, and will not be described in detail here.

[0304] It should be noted that the request processing device provided in the above embodiment only uses the division of the above functional modules as an example to illustrate the processing of data requests. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computing device can be divided into different functional modules to complete all or part of the functions described above. In addition, the request processing device provided in the above embodiment and the request processing method embodiment are based on the same concept. The specific implementation process is detailed in the request processing method embodiment and will not be repeated here.

[0305] FIG10 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application, using a terminal 1000 as an example. Optionally, the terminal 1000 may be a smartphone, a tablet computer, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 player (Moving Picture Experts Group Audio Layer IV), a laptop computer, or a desktop computer. Terminal 1000 may also be referred to as a user device, a portable terminal, a laptop terminal, a desktop terminal, or other similar names.

[0306] Typically, the terminal 1000 includes a processor 1001 and a memory 1002 .

[0307] Optionally, the processor 1001 includes one or more processing cores, such as a 4-core processor, an 8-core processor, etc. Optionally, the processor 1001 is 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 main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 1001 is integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 1001 also includes an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.

[0308] In some embodiments, the memory 1002 includes one or more computer-readable storage media, optionally, the computer-readable storage medium is non-transitory. Optionally, the memory 1002 also includes a high-speed random access memory and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in the memory 1002 is used to store at least one program code, and the at least one program code is used to be executed by the processor 1001 to implement the request processing method provided in each embodiment of the present application.

[0309] In some embodiments, terminal 1000 may optionally include a peripheral device interface 1003 and at least one peripheral device. Processor 1001, memory 1002, and peripheral device interface 1003 may be connected via a bus or signal lines. Each peripheral device may be connected to peripheral device interface 1003 via a bus, signal lines, or circuit boards. Specifically, the peripheral device may include at least one of a radio frequency circuit 1004, a display screen 1005, a camera assembly 1006, an audio circuit 1007, a positioning assembly 1008, and a power supply 1009.

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

[0311] Those skilled in the art will appreciate that the structure shown in FIG10 does not limit the terminal 1000 , and the terminal 1000 may include more or fewer components than shown, or combine certain components, or adopt a different component arrangement.

[0312] FIG11 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application. The computing device 1100 may have relatively large differences due to different configurations or performances. The computing device 1100 includes one or more processors (Central Processing Units, CPU) 1101 and one or more memories 1102, wherein the memory 1102 stores at least one computer program, and the at least one computer program is loaded and executed by the one or more processors 1101 to implement the request processing methods provided in the above-mentioned embodiments. Optionally, the computing device 1100 also has components such as a wired or wireless network interface, a keyboard, and an input and output interface for input and output. The computing device 1100 also includes other components for implementing device functions, which will not be described in detail here.

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

[0314] In an exemplary embodiment, a computer program product or computer program is also provided, including one or more program codes stored in a computer-readable storage medium. One or more processors of a computing device can read the one or more program codes from the computer-readable storage medium, and the one or more processors can execute the one or more program codes, so that the computing device can perform the request processing method of the above embodiment.

[0315] Those skilled in the art will understand that all or part of the steps to implement the above embodiments can be completed by hardware, or can be completed by instructing relevant hardware through a program. Optionally, the program is stored in a computer-readable storage medium. Optionally, the above-mentioned storage medium is a read-only memory, a disk or an optical disk, etc.

[0316] The above description is merely an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

DEPCT6726 / 10 / 25661. The request processing method is performed by one computing device in a clustered database and includes: determining the locking synchronization mode of the clustered database in response to the data request; locking the data resource corresponding to the data request and executing the data request if the locking synchronization mode is a non-strict synchronization mode; obtaining locking feedback information of the data resource by at least one second computing device in the clustered database; if the locking synchronization mode is not a non-strict synchronization mode, the locking feedback information indicates whether the second computing device successfully locked the data resource; and locking if the received locking feedback information meets the target condition corresponding to the locking synchronization mode of the data resource corresponding to the data request and performing actions on the data request.2.The method of Claim 1, in which the receipt of data resource locking feedback information by at least one second computing device in the clustered database, comprises: sending a lock request associated with a data request to at least one second computing device and receiving locking feedback information returned by at least one second computing device on the basis of the lock request.

3. The method of Claim 2, in which the sending of a lock request associated with a data request to at least one second computing device comprises: sending a lock request to at least one message processing thread on each second computing device via the message processing thread on the first computing device, and in which the receipt of locking feedback information returned by at least one second computing device on the basis of the lock request, comprises: receiving locking feedback information returned by at least one message processing thread on each first computing device via the message processing thread. 4.The method of claim 3 further comprises: sending in response to the receipt of at least one lock feedback information of the second computing device, lock feedback information to the thread, using the data request lock through the message processing thread if the data request is in an active state, and sending an unlock request to the second computing device if the data request is not in an active state, and lock feedback information indicates that the lock was successful, the unlock request is used to instruct the second computing device to release the data resource corresponding to the data request.

5. The method of claim 1, where if the lock synchronization mode is strict synchronization mode, the target condition is that at least one lock feedback information of each second computing device indicates that the lock was successful, and where the lock synchronization mode is semi-strict synchronization mode, the target condition is that at least one lock feedback information of each target number or more second computing devices in the second computing device indicates that the lock was successful. 6.The method according to claim 1, where in the case where the lock synchronization mode is strict synchronization mode, the target condition is that the waiting time does not exceed the first waiting threshold and the lock feedback information of at least one second computing device indicates that the lock was successful; and in the case where the lock synchronization mode is strict synchronization mode, the target condition is that the waiting time does not exceed the second waiting threshold and the lock feedback information of each target number or at least one second computing device indicates that the lock was successful.

7. The method according to claim 5 or 6 also includes: obtaining the target number in the case where the lock synchronization mode is semi-strict synchronization mode; and switching the lock synchronization mode to strict synchronization mode in the case where the target number is less than or greater than the total number of second computing devices in the clustered database. 8.The method under Claim 1 also includes: sending a lock request to at least one second computing device if the received lock feedback information does not meet the target condition or the request execution is complete; the lock request is used to instruct the second computing device to publish the data resource corresponding to the data request.

9. The method under Claim 1 where the data request is a Data Definition Language (DDL) request.

10. The method of processing the request is performed by the second computing device in the clustered database and includes: adding, in response to the lock request related to the data request, the lock request to the lock queue where the lock request is sent by the first computing device in the clustered database if the lock synchronization mode is not a non-strict synchronization mode; processing the lock request in the lock queue to receive lock feedback information and sending the lock feedback information to the first computing device. 11.The procedure under Claim 10, which involves processing lock requests in the lock queue to obtain lock feedback information, includes: locking the data resource corresponding to the data request and determining whether the lock feedback information indicates successful locking; and, in the event that the wait time of a lock request in the lock queue exceeds the third waiting limit or dead lock detection fails, determining whether the lock feedback information indicates lock failure.12.The methods under claim 10 also include: performing a localized deadlock detection in a lock request in response to a deadlock detection message from the first computing device; in the event of a locklock deadlock detection failure, determining the lock waiting chain of the lock request; in the event of a successful locklock deadlock detection, establishing the lock waiting chain which includes lock information that is dependent on the lock request; transmitting the lock waiting chain in the event that includes a remote lock; sending a deadlock detection message to a third computing device that initiates a remote lock; the remote lock representing lock information registered on the second computing device but not initiated by the second computing device; and in the event that the computing device that sent the deadlock detection message receives a deadlock detection message which is considered to be a deadlock detection failure.13.The method under claim 10, which involves adding a lock request to the lock queue in response to a lock request associated with a data request, includes: receiving the lock request via the message processing thread on the second computing device; initiating the lock agent thread corresponding to the lock request via the message processing thread; and adding the lock request to the lock queue via the lock agent thread.

14. The method under claim 10 further includes: registering the lock information corresponding to the data request if the data resource corresponding to the data request is locked; determining whether the lock information is active lock information for a target period; and sending a keepalive request to the first computing device if the lock information is active lock information and the lock period of the data resource corresponding to the data request exceeds the keepalive threshold; and the keepalive request used for the first computing device to indicate whether to release the data resource.15.The request processing tools consist of: the assignment module, which is configured to determine the lock synchronization mode of the clustered database in response to data requests; the lock execution module, which is configured to lock the data resource corresponding to the data request and execute the data request if the lock synchronization mode is a non-strict synchronization mode; and the first reception module, which is configured to receive lock feedback information of the data resource from at least one second processing device in the clustered database. If the lock synchronization mode is not a non-strict synchronization mode, the lock feedback information indicates that the second processing device successfully locked the data resource. And where the lock action module is also configured to lock the data resource corresponding to the data request if the received lock feedback information meets the target condition corresponding to the lock synchronization mode and execute the data request.16.The request processing equipment comprises: an add module configured to add, in response to a lock request associated with a lock request data request, to the lock waiting queue where the presence of a lock request is sent by the first computing device in the clustered database in the event that the lock synchronization mode is not a non-strict synchronization mode; a processing module configured to process lock requests in the lock waiting queue to receive lock feedback information; and a send module configured to send lock feedback information to the first computing device.

17. The computing device comprises: one or more processors and one or more memory units, one or more memory units storing at least one computer program, and at least one computer program, when loaded and executed by one or more processors, shall be implemented in the request processing method according to either Claims 1 through 9 or Claims 10 through 14.18.Storage media that contains: at least one computer program and at least one computer program, and at least one computer program, when loaded and executed by one or more processors of the computing device, uses any one of the request processing methods under Claims 1 through 9 or Claims 10 through 14; 19. Computer readable storage media that contains: at least one computer program and at least one computer program, and at least one computer program, when loaded and executed by one or more processors of the computing device, uses any one of the request processing methods under Claims 1 through 9 or Claims 10 through 14;

Images