A distributed table lock application method and device, a storage medium and an electronic device

Abstract

The specification discloses a distributed table lock application method and device, a storage medium and an electronic device. The distributed table lock application method comprises the following steps: a master node receives a data processing request, determines a data table where to-be-processed data corresponding to the data processing request is located, generates a table lock for the data table, performs a lock operation on the data table, generates lock state information corresponding to the data table, writes the lock state information into a log in the master node, synchronizes the log to a slave node, so that the slave node saves the log, and after the master node restarts, judges whether the master node stores the log, and if yes, according to the lock state information recorded in the log, the lock operation on the data table is restored.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a distributed table lock application method, apparatus, storage medium, and electronic device. Background Technology

[0002] In distributed data systems, the task being processed is typically broken down into multiple subtasks, which are then distributed to different computers for processing to improve efficiency. During this process, to prevent multiple processes from simultaneously operating on a single piece of data in the database (such as modifying data), which could lead to database read / write failures, the data in the database is usually locked. That is, when one process operates on data in the database, the database locks that data to prevent other processes from operating on it at the same time.

[0003] However, current data locking mechanisms cannot effectively guarantee data locking operations, which may cause database read / write failures and prevent data processing tasks from proceeding smoothly. Summary of the Invention

[0004] This specification provides a distributed table-locking application method, apparatus, storage medium, and electronic device, thereby effectively ensuring data locking operations.

[0005] The following technical solution is adopted in this specification:

[0006] This specification provides a distributed table locking application method, which is applied to the master node of a distributed database, including:

[0007] The master node receives a data processing request and determines the data table containing the data to be processed corresponding to the data processing request;

[0008] Generate a table lock for the data table, the table lock including a table-level lock and a partition-level lock, the table-level lock being used to lock the data table in response to a Data Definition Language (DDL) operation, and the partition-level lock being used to lock a partition of the data table in response to a Data Manipulation Language (DML) operation.

[0009] The table lock is used to perform a locking operation on the data table and generate lock status information corresponding to the data table.

[0010] The lock state information is written to the local log of the master node, and the log is synchronized to the slave node so that the slave node saves the log.

[0011] After the master node restarts, determine whether the master node stores the logs;

[0012] If so, the lock operation on the data table is restored according to the lock status information recorded in the log.

[0013] Optionally, the method further includes:

[0014] A table lock generation instruction is sent to the slave node, so that the slave node generates a table lock for a replica of the data table locally according to the table lock generation instruction, and after the slave node is elected as the master node, it performs a lock operation on the replica according to the table lock generated locally on the slave node and the log synchronized to the slave node by the master node.

[0015] This specification provides a distributed table lock application method, which is applied to slave nodes in a distributed database, including:

[0016] The receiving module receives and saves the logs synchronized by the master node. The logs contain lock status information. The lock status information is generated by the master node after performing a locking operation on the data table containing the data to be processed by generating a table lock. The table lock is generated by the master node for the data table containing the data to be processed after receiving the data processing request. The table lock includes table-level locks and partition-level locks. The table-level lock is used to lock the data table in response to a DDL operation, and the partition-level lock is used to lock the partitions of the data table in response to a DML operation.

[0017] Upon receiving a log retrieval request from the master node, the master node sends the log to the master node so that the master node can restore the lock operation on the data table based on the lock status information recorded in the log. The log retrieval request is sent by the master node to the slave node after restarting and determining that the log is not stored locally.

[0018] Optionally, the method further includes:

[0019] Receive the table lock generation command sent by the master node;

[0020] According to the table lock generation instruction, a table lock for a copy of the data table is generated locally on the slave node;

[0021] After the master node fails, it sends an election request to the other nodes, in which the slave node itself can elect itself as the master node.

[0022] In response to the slave node electing itself as the master node, the master node performs a lock operation on the replica of the data table based on the table lock generated by the slave node and the lock status information recorded in the master node's synchronization log.

[0023] This specification provides a distributed table-locking application device, including:

[0024] The receiving module receives a data processing request and determines the data table containing the data to be processed corresponding to the data processing request.

[0025] The generation module generates table locks for the data table, including table-level locks and partition-level locks. The table-level locks are used to lock the data table in response to DDL operations, and the partition-level locks are used to lock partitions of the data table in response to DML operations.

[0026] The operation module performs a locking operation on the data table through the table lock and generates lock status information corresponding to the data table;

[0027] The synchronization module writes the lock state information to the local log of the master node and synchronizes the log to the slave node so that the slave node can save the log.

[0028] The judgment module determines whether the master node stores the log after the master node restarts.

[0029] If so, the recovery module restores the lock operation on the data table based on the lock status information recorded in the log.

[0030] Optionally, the generation module is specifically configured to send a table lock generation instruction to the slave node, so that the slave node generates a table lock for a replica of the data table locally according to the table lock generation instruction, and after the slave node is elected as the master node, it performs a lock operation on the replica according to the table lock generated locally on the slave node and the log synchronized to the slave node by the master node.

[0031] This specification provides a distributed table-locking application device, including:

[0032] The receiving module receives and saves the logs synchronized by the master node. The logs contain lock status information. The lock status information is generated by the master node after performing a locking operation on the data table containing the data to be processed by generating a table lock. The table lock is generated by the master node for the data table containing the data to be processed after receiving the data processing request. The table lock includes table-level locks and partition-level locks. The table-level lock is used to lock the data table in response to a DDL operation, and the partition-level lock is used to lock the partitions of the data table in response to a DML operation.

[0033] When the sending module receives a log retrieval request from the master node, it sends the log to the master node so that the master node can resume the locking operation on the data table based on the lock status information recorded in the log. The log retrieval request is sent by the master node to the slave node after it has completed a restart and determined that the log is not stored locally.

[0034] Optionally, the receiving module is further configured to: receive a table lock generation instruction sent by the master node; generate a table lock for a replica of the data table locally on the slave node according to the table lock generation instruction; after the master node fails, send an election request to the other nodes for the slave node to become the master node; and in response to the slave node being elected as the master node, perform a lock operation on the replica of the data table according to the table lock generated by the slave node and the lock status information recorded in the log synchronized by the master node.

[0035] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described distributed table-locking application method.

[0036] This specification provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described distributed table-locking application method.

[0037] The above-mentioned technical solutions adopted in this specification can achieve the following beneficial effects:

[0038] In this scheme, the master node receives a data processing request, determines the data table containing the data to be processed, generates a table lock for the data table, performs a locking operation on the data table, generates lock status information for the data table, writes the lock status information to the master node's local log, and synchronizes the log to the slave nodes so that the slave nodes can save the log. After the master node restarts, it checks whether the master node has stored the log. If so, it restores the locking operation on the data table based on the lock status information recorded in the log.

[0039] As can be seen from the above method, during the data processing process, the master node generates a table lock on the data table containing the data to be processed and synchronizes the lock status information during the data processing process to the log. In this way, even if the master node restarts or the table lock in the master node is lost, the previous lock operation status can be restored according to the stored log. This avoids the inability to guarantee the locking operation of the data due to the master node restart or the loss of the table lock in the master node. As a result, the data to be processed will not be called by multiple processes during subsequent data processing, ensuring the smooth progress of the data processing task. Attached Figure Description

[0040] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings:

[0041] Figure 1 This is a flowchart illustrating a distributed table-locking application method provided in this specification.

[0042] Figure 2 This is a flowchart illustrating a distributed table-locking application method provided in this specification.

[0043] Figure 3 This is a schematic diagram of a distributed table lock application device provided in this specification;

[0044] Figure 4 This is a schematic diagram of a distributed table lock application device provided in this specification;

[0045] Figure 5 The one provided in this specification corresponds to Figure 1 or Figure 2 A schematic diagram of an electronic device. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0047] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0048] Figure 1 This document provides a flowchart illustrating a distributed table-locking application method, which includes the following steps:

[0049] S100: The master node receives a data processing request and determines the data table containing the data to be processed corresponding to the data processing request.

[0050] In distributed database systems, the task being processed is typically broken down into multiple subtasks, which are then distributed to different computers for processing. This improves processing efficiency and ensures data privacy and security. In this process, the data system can distribute data related to the current data processing task across multiple nodes, allowing multiple nodes to jointly execute the task.

[0051] In the actual execution of data processing tasks, if two or more processes are simultaneously processing data assigned to one of the nodes (such as deleting and modifying the data at the same time), the data will lose consistency, causing database errors.

[0052] Typically, data in a database is stored in the form of tables. However, if data distributed to different nodes is stored in the same table, conflicts can occur between the processes of these two nodes (such as one node modifying data in the table while the other node deletes data from the table), leading to data inconsistency and database errors.

[0053] To avoid the aforementioned situation, data locks are typically used to prevent multiple threads or processes from simultaneously accessing a specific piece of data or the table containing that data in the database, thus ensuring data consistency and preventing database errors. However, because the previous lock operation state (such as the locked location and locking method) cannot be saved, if the node storing the data lock restarts, the data lock cannot restore the locking operations on the data or table before the restart. This means that the restarted node cannot effectively prevent multiple processes from operating on the same data simultaneously. Furthermore, if the node storing the data lock fails, the database data lock will be lost, thus compromising data consistency during subsequent data processing.

[0054] Based on this, this specification provides a distributed table lock application method to avoid the inability to guarantee data consistency in the database during subsequent data processing due to the restart of the node storing the data lock or the loss of the data lock. Specifically, the master node can determine the data table containing the data to be processed when it receives a data processing request.

[0055] In a distributed database system, multiple nodes are configured. These nodes can be designated devices such as computers or servers deployed within the system. This allows the distributed database system to distribute copies of the data to be processed across different nodes. During data processing, a node can be elected as the master node, and the other nodes can be designated as slave nodes. The master node is used to allocate and manage the other slave nodes to ensure global data consistency and to perform read and write operations on the database. Slave nodes are used to synchronize data with the master node, handle non-transactional data operations, forward transactional data operations to the master node, and perform read operations on the database, but not write operations. When the master node fails and goes down, a new master node can be elected from among the slave nodes. The election method can be set according to the actual situation, and this manual does not specify a particular method.

[0056] Furthermore, the aforementioned data processing requests can be data processing requests corresponding to different processes of the same client, or data processing requests corresponding to different processes of different clients. Of course, they can also be data processing requests corresponding to other objects or processes. Data processing requests can be requests to perform operations such as deleting, modifying, and adding data, or requests to perform operations such as deleting data from a data table, setting restrictions, and creating a data table. This specification does not specifically limit these requests.

[0057] S102: Generate a table lock for the data table.

[0058] Data processing typically involves multiple phases, such as the Prepare phase and the Commit phase. To ensure data consistency, during the Prepare phase, the master node can generate a table lock on the table containing the data to be processed. Alternatively, the master node can generate a table lock on the table immediately after acquiring the data to be processed.

[0059] Specifically, after the master node obtains the data to be processed, it can first generate a table lock for the data table locally, and then send a table lock generation instruction to multiple slave nodes. After receiving the table lock generation instruction, the slave nodes can generate a table lock for a copy of the data table locally for backup of the table lock in the master node.

[0060] Furthermore, the master node can send the table lock generation command to each slave node, so that each node (including the master node and slave nodes) has a corresponding table lock. Of course, it can also send the table lock generation command to only some specified slave nodes, so that the table lock is only saved in these slave nodes.

[0061] In this specification, the aforementioned table locks can include table-level locks and partition-level locks. Table-level locks are used to lock a data table in response to Data Definition Language (DDL) operations, while partition-level locks are used to lock partitions of a data table in response to Data Manipulation Language (DML) operations. DDL operations are typically used for defining or changing the structure, data types, links, and constraints between tables during initialization, mostly during table creation. After table creation, DDL operations can also be used to modify table attributes or create indexes. DML operations are used to manipulate data in the database, such as inserting or deleting data into a table; they can be understood as primarily used to modify data in a table. For example, SQL commands such as CREATE, ALTER, and DROP are DDL operations, while commands such as SELECT, UPDATE, INSERT, and DELETE are DML operations.

[0062] In this specification, the content of a distributed data table can be divided into multiple partitions, each containing only a portion of the table's content. Some overlap in content is allowed between different data table partitions. A distributed database system has multiple nodes, and these partitions of the data table are distributed across these nodes. Typically, without considering disaster recovery, each partition of the data table resides on a different node. With disaster recovery in mind, the same partition of the data table has a primary replica and a secondary replica, each residing on a different node, and the two maintain dynamic data consistency through data synchronization.

[0063] In practical applications, DDL operations are typically low-frequency operations, targeting the entire data table and occurring relatively infrequently, while DML operations are high-frequency operations, targeting local partitions within the data table and occurring more frequently. To address these characteristics, this application also divides table locks into a two-level structure: table-level locks and partition-level locks. Based on the triggering of different operations, differentiated locking procedures are provided to achieve more reasonable mutual exclusion of operations with a wider impact. Therefore, when the server receives an operation targeting a distributed data table, it will determine the type of operation to decide which locking procedure to use next.

[0064] S104: Using the table lock, perform a locking operation on the data table and generate lock status information corresponding to the data table.

[0065] Specifically, after generating a table lock for a data table, this table lock can be used to lock the data table, preventing other processes from accessing or performing operations on the locked data to be processed, except for the process corresponding to the current data processing request. For example, if the process corresponding to the current data processing request is performing a modification operation on the data to be processed, the master node will lock the corresponding data table in the database using the table lock. In this way, other processes cannot simultaneously perform operations such as deletion, modification, or setting constraints on the corresponding data table and the data in the table.

[0066] If the master node detects that the current process has finished executing the data processing operation on the data to be processed, it can unlock the previously locked data table through table lock, thereby enabling other processes to perform subsequent operations on the data to be processed and the data table containing the data to be processed.

[0067] Taking the above example again, when the master node detects that the current process has completed the modification of the data to be processed, it can unlock the data table containing the data to be processed through table lock, so that other processes can perform operations such as deletion, modification, and setting constraints on the data table containing the data to be processed and the data in the data table.

[0068] Typically, when a node storing a table lock restarts or the table lock is lost, the data table will often revert to its state before the table lock operation was performed. For example, when processing data to be processed, the data table containing that data is in a locked state. However, when the node storing the table lock restarts, the data table containing the data to be processed will revert to its unlocked state when there was no table lock. This makes it impossible to prevent other processes from accessing the data to be processed, causing data processing to be unable to continue.

[0069] Therefore, to avoid this situation, after the master node performs a locking operation on the data table containing the data to be processed through the table lock, it can generate lock status information corresponding to the table lock. This lock status information may include the location of the data table locked by the table lock in the database, its current status (such as locked status or unlocked status), and the locking method. Of course, it may also include other status information, which is not specifically limited in this specification.

[0070] S106: Write the lock state information to the local log of the master node, and synchronize the log to the slave node so that the slave node saves the log.

[0071] After the master node determines the lock status information corresponding to the data table, it can write the lock status information to the master node's local log and synchronize the log to the slave nodes, so that the slave nodes can store the synchronized log.

[0072] In this specification, the master node can carry the table lock generation instruction in the aforementioned log and synchronize it to the slave node. The slave node can then generate table locks for a copy of the data table based on the table lock generation instruction recorded in the log.

[0073] S108: After the master node restarts, determine whether the master node stores the log.

[0074] S110: If so, then restore the lock operation on the data table according to the lock status information recorded in the log.

[0075] In practical applications, when the master node restarts, previous table locks are lost. To restore the previous lock operation state, the lock operations on the data table need to be restored using the lock state information recorded in the logs. There are several reasons why a node might restart. When the master node receives a restart command and performs a normal restart operation, the logs stored locally are not lost. However, if the master node restarts due to some faults (such as memory failures), these faults may lead to the loss of locally stored logs.

[0076] Therefore, after the master node restarts, it is necessary to determine whether the master node still stores logs. If it is determined that the master node still stores logs, the master node can directly restore the lock operation on the data table containing the data to be processed based on the lock status information recorded in the local logs.

[0077] If it's determined that the master node does not store logs, it means the logs have been lost. In this case, the master node can send a log retrieval request to the slave node. Upon receiving the request, the slave node can return the locally stored logs to the master node. This allows the master node to restore the lock operations on the table containing the data to be processed based on the lock status information recorded in the logs. For example, if the table containing the data to be processed was locked by a table lock before the master node restarted, the master node can restore the locking operations on the table containing the data to be processed before the restart by using the table lock based on the lock status information recorded in the logs sent by the slave node.

[0078] If the logs in the master node are lost during this process, the master node can regenerate new table locks based on the lock status information recorded in the logs synchronized to the master node, and restore the corresponding lock operation state of the data table before the table locks were lost.

[0079] When the master node fails and becomes permanently down, it means that the master node can no longer execute subsequent data processing tasks. Therefore, one of the slave nodes can send an election request to the other nodes to become the master node. If the slave node is elected successfully, it can respond to the master node election by performing locking operations on the replica of the data table based on the table locks generated by the slave node and the lock status information recorded in the master node's synchronization log. In a distributed database system, when the master node processes data in a data table, the slave nodes also generate replicas of that data table. In this way, when the master node fails and a slave node is elected as the master node, processing of the replica of the data table can continue.

[0080] The remaining nodes mentioned above can be other slave nodes in the distributed database system. If the master node is found to be in an unresponsive state for a preset time, it can be considered that the master node has suffered a permanent failure. At this time, a request can be sent to the other slave nodes in the distributed database system to elect it as the master node. The preset time can be set according to the actual situation, and this specification does not make a specific limitation on it.

[0081] In other words, if the data table is locked by a table lock before the master node crashes, then after the master node fails, when one of the slave nodes is elected as the master node, the lock on the copy of the data table can be restored based on the logs synchronized to the local machine.

[0082] It should be noted that this manual can also generate other types of data locks, such as data locks only for the data to be processed, row locks for the data row containing the data to be processed, and page locks for the data page containing the data to be processed. When the data lock is only for the data to be processed, the lock operation can be performed only on the data to be processed. When the data lock is a row lock, the lock operation can be performed on the data row containing the data to be processed. When the data lock is a page lock, the lock operation can be performed on the data page containing the data to be processed. The method for restoring the lock operation is the same as the method for restoring the lock operation on the data table described above, and this manual does not make specific limitations on this.

[0083] The above describes the distributed table lock application method provided in this manual from the perspective of the master node. For ease of understanding, the following explanation will describe the distributed table lock application method from the perspective of one of the slave nodes in a distributed database system. Figure 2 As shown.

[0084] Figure 2 This is a flowchart illustrating a data processing method provided in this specification, including the following steps:

[0085] S200: The slave node receives and saves the log synchronized from the master node. The log contains lock status information. The lock status information is generated by the master node after performing a locking operation on the data table containing the data to be processed by generating a table lock. The table lock is generated by the master node for the data table containing the data to be processed after receiving the data processing request. The table lock includes table-level locks and partition-level locks. The table-level lock is used to lock the data table in response to a DDL operation, and the partition-level lock is used to lock the partition of the data table in response to a DML operation.

[0086] After receiving a data processing request, the master node will determine the data table containing the data to be processed corresponding to the data processing request, and then generate a table lock for the data table containing the data to be processed. The master node can then use the table lock to perform locking operations (such as locking and unlocking) on ​​the data table containing the data to be processed, and generate the lock status information corresponding to the data table.

[0087] S202: Upon receiving a log retrieval request from the master node, the master node sends the log to the master node so that the master node can restore the lock operation on the data table based on the lock status information recorded in the log. The log retrieval request is sent by the master node to the slave node after the master node completes a restart and determines that the log is not stored locally.

[0088] When the master node restarts, if it still stores logs, it can restore the lock operations on the table containing the data to be processed based on the lock status information recorded in the logs. If the master node does not store logs, it can send a log retrieval request to the slave node. Upon receiving this request, the slave node can return its locally stored logs to the master node, allowing the master node to restore the lock operations on the table based on the lock status information recorded in those logs.

[0089] As can be seen from the above method, during the data processing process, the master node generates a table lock on the data table containing the data to be processed and synchronizes the lock status information during the data processing process to the log. In this way, even if the master node restarts or the table lock in the master node is lost, the previous lock operation state can be restored according to the stored log. This avoids the inability to guarantee the locking operation of the data due to the master node restart or the loss of the table lock in the master node, so that the data to be processed will not be called by multiple processes during subsequent data processing, ensuring the smooth progress of the data processing task.

[0090] The above describes one or more methods for implementing distributed table locking in this specification. Based on the same approach, this specification also provides corresponding distributed table locking application devices, such as... Figure 3 or Figure 4 As shown.

[0091] Figure 3 A schematic diagram of a distributed table-locking application device provided in this specification includes:

[0092] The receiving module 300 is used to receive a data processing request and determine the data table where the data to be processed corresponds to the data processing request.

[0093] The generation module 302 generates a table lock for the data table. The table lock includes a table-level lock and a partition-level lock. The table-level lock is used to lock the data table in response to a Data Definition Language (DDL) operation, and the partition-level lock is used to lock a partition of the data table in response to a Data Manipulation Language (DML) operation.

[0094] The operation module 304 is used to perform a locking operation on the data table through the table lock and generate lock status information corresponding to the data table;

[0095] The synchronization module 306 is used to write the lock state information into the local log of the master node and synchronize the log to the slave node so that the slave node can save the log;

[0096] The judgment module 308 is used to determine whether the master node stores the log after the master node restarts;

[0097] The recovery module 310 is used to, if so, restore the lock operation on the data table according to the lock status information recorded in the log.

[0098] Optionally, the generation module 302 is specifically configured to send a table lock generation instruction to the slave node, so that the slave node generates a table lock for a replica of the data table locally according to the table lock generation instruction, and after the slave node is elected as the master node, it performs a lock operation on the replica according to the table lock generated locally on the slave node and the log synchronized to the slave node by the master node.

[0099] Figure 4 A schematic diagram of a distributed table-locking application device provided in this specification includes:

[0100] The receiving module 400 is used to receive and save the logs synchronized by the master node. The logs contain lock status information. The lock status information is generated by the master node after performing a locking operation on the data table where the data to be processed is located by generating a table lock. The table lock is generated by the master node for the data table where the data to be processed is located after receiving the data processing request. The table lock includes table-level locks and partition-level locks. The table-level lock is used to lock the data table in response to a DDL operation, and the partition-level lock is used to lock the partition of the data table in response to a DML operation.

[0101] The sending module 402 is used to send the log to the master node when it receives a log retrieval request from the master node, so that the master node can resume the lock operation on the data table according to the lock status information recorded in the log. The log retrieval request is sent by the master node to the slave node after it has completed a restart and determined that the log is not stored locally.

[0102] Optionally, the receiving module 400 is further configured to: receive a table lock generation instruction sent by the master node; generate a table lock for a replica of the data table locally on the slave node according to the table lock generation instruction; after the master node fails, send an election request to the other nodes for the slave node to become the master node; and in response to the slave node being elected as the master node, perform a lock operation on the replica of the data table according to the table lock generated by the slave node and the lock status information recorded in the log synchronized by the master node.

[0103] This specification also provides a computer-readable storage medium storing a computer program that can be used to execute the above-described... Figure 1 or Figure 2 This provides a distributed table locking application method.

[0104] This instruction manual also provides Figure 5 One of the corresponding Figure 1 or Figure 2 A schematic diagram of the structure of an electronic device. (e.g.) Figure 5 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for the business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to achieve the above-mentioned functions. Figure 1 or Figure 2 The distributed table lock application method described above. Of course, in addition to the software implementation method, this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. In other words, the execution subject of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0105] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0106] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0107] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0108] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0109] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0110] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0111] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0112] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0113] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0114] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0115] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0116] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0117] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0118] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0119] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0120] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A distributed table lock application method, applied to a master node in a distributed database, comprising: receiving, by the master node, a data processing request and determining a data table where data to be processed is located corresponding to the data processing request; generating a table lock for the data table, the table lock comprising a table level lock and a partition level lock, the table level lock being used to lock the data table after responding to a data definition language (DDL) operation, and the partition level lock being used to lock a partition of the data table after responding to a data manipulation language (DML) operation; performing a lock operation on the data table through the table lock and generating lock state information corresponding to the data table; writing the lock state information into a log locally stored in the master node and synchronizing the log to a slave node so that the slave node saves the log; after the master node restarts, determining whether the master node stores the log; if yes, resuming the lock operation on the data table according to the lock state information recorded in the log. 2.The method of claim 1, further comprising: sending a table lock generation instruction to the slave node so that the slave node generates a table lock for a copy of the data table according to the table lock generation instruction, and after the slave node competes to become a master node, performing a lock operation on the copy according to the table lock generated locally in the slave node and the lock state information recorded in the log synchronized from the master node to the slave node. 3.A distributed table lock application method, applied to a slave node in a distributed database, comprising: receiving and saving a log synchronized from a master node, the log containing lock state information, the lock state information being generated by the master node after performing a lock operation on a data table where data to be processed is located through a table lock, the table lock being generated by the master node for the data table where the data to be processed is located after receiving a data processing request, the table lock comprising a table level lock and a partition level lock, the table level lock being used to lock the data table after responding to a DDL operation, and the partition level lock being used to lock a partition of the data table after responding to a DML operation; after receiving a log acquisition request sent by the master node, sending the log to the master node so that the master node resumes the lock operation on the data table according to the lock state information recorded in the log, wherein the log acquisition request is sent by the master node to the slave node after completing a restart and determining that the log is not stored locally. 4.The method of claim 3, further comprising: receiving a table lock generation instruction sent by the master node; generating a table lock for a copy of the data table locally in the slave node according to the table lock generation instruction; after the master node fails, sending a competition request to other nodes that the slave node competes to become a master node; after the slave node competes to become a master node, performing a lock operation on the copy of the data table according to the table lock generated in the slave node and the lock state information recorded in the log synchronized from the master node.

5. A distributed table lock application apparatus, comprising: a receiving module configured to receive a data processing request and determine a data table where data to be processed corresponding to the data processing request is located; a generating module configured to generate a table lock for the data table, the table lock comprising a table level lock and a partition level lock, the table level lock being used to lock the data table after responding to a DDL operation, and the partition level lock being used to lock a partition of the data table after responding to a DML operation; an operating module configured to perform a lock operation on the data table through the table lock and generate lock state information corresponding to the data table; a synchronizing module configured to write the lock state information into a log locally stored in a master node and synchronize the log to a slave node so that the slave node stores the log; a judging module configured to determine whether the master node stores the log after the master node restarts; and a recovering module configured to recover the lock operation on the data table according to the lock state information recorded in the log if the master node stores the log.

6. The apparatus of claim 5, wherein the generating module is specifically configured to send a table lock generation instruction to the slave node so that the slave node generates a table lock for a copy of the data table according to the table lock generation instruction, and the slave node performs a lock operation on the copy according to the table lock generated locally in the slave node and the log synchronized from the master node to the slave node after the slave node competes to become the master node.

7. A distributed table lock application apparatus, comprising: a receiving module configured to receive a log synchronized by a master node and store the log, the log containing lock state information generated by the master node through a table lock generated by the master node for a data table where data to be processed is located after the master node performs a lock operation on the data table, the table lock being generated by the master node for the data table where the data to be processed is located after the master node receives a data processing request, the table lock comprising a table level lock and a partition level lock, the table level lock being used to lock the data table after responding to a DDL operation, and the partition level lock being used to lock a partition of the data table after responding to a DML operation; a sending module configured to send the log to the master node when receiving a log acquisition request sent by the master node so that the master node recovers the lock operation on the data table according to the lock state information recorded in the log, wherein the log acquisition request is sent by the slave node to the master node when the master node determines that the log is not stored locally after completing a restart. 8.The apparatus of claim 7, wherein the receiving module is further configured to receive a table lock generation instruction sent by the master node, and generate a table lock for the copy of the data table locally at the slave node according to the table lock generation instruction. after a failure of the master node, sending a competition request to other nodes so that the slave node competes to become the master node; in response to the slave node competing to become the master node, performing a lock operation on a copy of the data table according to the table lock generated by the slave node and the lock state information recorded in the log synchronized by the master node.

9. A computer readable storage medium, the storage medium storing a computer program, the computer program being executed by a processor to implement the method of any one of claims 1-4.

10. An electronic device comprising a memory, a processor, and a computer program stored on the memory and loadable on the processor, the processor implementing the method of any one of claims 1 to 4 when executing the program.

Images