Distributed thread management methods, systems and electronic devices

Abstract

This application relates to a distributed thread management method, system, and electronic device. The method includes: a requesting worker node sending a lock request initiated by its corresponding thread to a coordinating node; the lock request includes a lock ID; the coordinating node retrieves target lease information matching the lock ID from a global lock registry; the target lease information includes the lock state; when the lock state is idle, the coordinating node generates a lock token and issues it to the requesting worker node, updating the lock state to non-idle; the lock token includes a lease ID and a lease expiration time; the requesting worker node responds to the lock token, generates a permission instruction, and issues it to the corresponding thread, instructing the corresponding thread to perform a corresponding operation on the shared resource associated with the lock ID; after the lease expiration time, if no renewal request is received from the requesting worker node, the coordinating node determines that the lease ID has expired and releases the lock corresponding to the lease ID. The solution provided in this application ensures eventual consistency of the lock state, guaranteeing construction safety.

Description

Technical Field

[0001] This application relates to the field of smart construction site technology, and in particular to a distributed thread management method, system and electronic device. Background Technology

[0002] In a smart construction site system, tower cranes, hoists, sensors, and other equipment constitute a distributed system that requires real-time data exchange to ensure collaborative operations. The accuracy and efficiency of thread synchronization and communication directly affect construction safety.

[0003] In related technologies, lock management is implemented through third-party middleware (such as Redis (Remote DictionaryServer, an open-source high-performance key-value database) SETNX (SET if Not eXists, a commonly used command for Redis distributed locks) and ZooKeeper (a distributed coordination service) ephemeral nodes). However, threads need to frequently communicate with the middleware to confirm the lock status, which poses a middleware dependency risk. For example, if the middleware cluster experiences a network partition when relying on third-party middleware, it may lead to a "split-brain" situation, where multiple nodes hold the lock simultaneously, which can easily cause security incidents. Summary of the Invention

[0004] To address or partially address the problems existing in related technologies, this application provides a distributed thread management method, system, and electronic device that can ensure eventual consistency of lock states and guarantee construction safety.

[0005] The first aspect of this application provides a distributed thread management method applied to a distributed thread management system, the distributed thread management system including a coordinating node and multiple worker nodes, the coordinating node maintaining a global lock registry, the global lock registry including lease information for all locks; the method includes: The requesting worker node sends the lock request initiated by the corresponding thread to the coordinating node; the requesting worker node is the worker node among the plurality of worker nodes that receives the lock request, and the lock request includes a lock ID; The coordinating node obtains target lease information matching the lock ID from the global lock registry; the target lease information includes the lock status; When the lock is in an idle state, the coordinating node generates a lock token and sends it to the requesting worker node, and updates the lock state to a non-idle state; the lock token includes a lease ID and a lease expiration time; The requesting worker node responds to the lock token by generating an permission instruction and sending it to the corresponding thread; the permission instruction is used to instruct the corresponding thread to perform a corresponding operation on the shared resource associated with the lock ID; If no renewal request is received from the requesting worker node after the lease expires, the coordinating node determines that the lease ID is invalid and releases the lock corresponding to the lease ID.

[0006] In one embodiment, the lock request further includes a thread ID and a request version number; the request worker node locally caches multiple lock states within a first time period; the request worker node sends the lock request initiated by the corresponding thread to the coordinating node, including: After receiving a lock request initiated by the corresponding thread, the request worker node queries the local cache to see if the lock state matching the lock ID is in an idle state. When the local query finds that the lock is in a non-idle state, the requesting worker node encapsulates the lock ID, its own node ID, the thread ID, the request version number, and the first timestamp into a request message, and sends the request message to the coordinating node through the NIO channel; wherein, the NIO channel is a non-blocking I / O channel built on JavaNIO.

[0007] In one embodiment, the coordinating node generates a lock token and issues it to the requesting worker node, and updates the lock state to a non-idle state, including: The coordinating node updates the target lease information using the request message, so that the lock state is updated to a non-idle state in the target lease information; the target lease information also includes a lease ID and a lease expiration time, the lease expiration time being generated based on the current time and the valid time; The coordinating node encapsulates the lease ID and the lease expiration time into a lock token and returns it to the requesting worker node via the NIO channel.

[0008] In one embodiment, the target lease information further includes a holding version number; after the coordinating node obtains the target lease information matching the lock ID from the global lock registry, the method further includes: When the lock is in a non-idle state, the coordinating node compares the held version number with the requested version number; If the held version number is less than the requested version number, the coordinating node will sort the request message according to the first timestamp and store it in a waiting queue, and generate queuing notification information to return to the requesting worker node through the NIO channel; the queuing notification information is used to instruct the requesting worker node to wait in the queue; or... If the held version number is greater than or equal to the requested version number, the coordinating node generates a version error message to return to the requesting worker node through the NIO channel; the version error message is used to instruct the requesting worker node to reject the lock request of the corresponding thread.

[0009] In one embodiment, the method further includes: If a release message is received from the requesting worker node during the lease expiration period, the coordinating node uses the release message to update the target lease information so that the lock state is updated to an idle state in the target lease information; the release message is used to indicate that the corresponding thread has completed the operation on the shared resource.

[0010] In one embodiment, the method further includes: If, during the lease expiration period, an operation log generated by the corresponding thread after completing the operation is received, the requesting worker node will broadcast the operation log to other worker nodes via a message queue; the operation log includes the lock ID, new data, the request version number, the second timestamp, and the node ID; The other working nodes compare their local version number with the requested version number; If the local version number is less than the requested version number, then the other worker nodes update the locally cached resource data and the local version number based on the operation log; or, If the local version number is greater than or equal to the requested version number, then the other working nodes discard the operation log; The other working nodes generate confirmation information and send it to the coordinating node through the NIO channel for recording; the confirmation information is used to indicate that the other working nodes have performed local updates based on the operation log or have discarded the operation log.

[0011] In one embodiment, the coordinating node further maintains a node topology table, which includes thread state data; the method further includes: Each of the aforementioned working nodes periodically sends a heartbeat detection message to the coordinating node; If the coordinating node fails to receive a heartbeat detection message from the same working node for M consecutive times, it will determine the working node as an abnormal working node in an offline state; where M is an integer greater than 1. The coordinating node extracts the lock ID associated with the abnormal worker node from the global lock registry, and extracts the thread status data associated with the abnormal worker node from the node topology table; the thread status data includes the thread ID and execution progress. The coordinating node determines the target worker node from the plurality of worker nodes based on the consistent hashing algorithm, so as to migrate the extracted lock ID and thread state data to the target worker node through the NIO channel; wherein, the hash factor of the consistent hashing algorithm is the lock ID and the thread ID; The target worker node uses the thread state data to reconstruct the thread in order to restore the execution progress; The target working node generates a takeover request and sends it to the coordinating node via the NIO channel; In response to the takeover request, the coordinating node updates the information of the abnormal worker node in the global lock registry to the information of the target worker node, and updates the information of the abnormal worker node in the node topology table to the information of the target worker node.

[0012] In one embodiment, the coordinating node also maintains a node topology table; the method further includes: When the coordinating node receives a registration message from a new worker node, it synchronizes the global lock registry and multiple historical operation logs within the second time period with the new worker node; the new worker node is a worker node newly added to the distributed thread management system, and the registration message includes node ID, number of CPU cores, remaining memory, and device type; The new worker node initializes the local lock manager to cache the global lock registry; and, The new worker node initializes a message queue to cache the multiple historical operation logs. After receiving the synchronization completion message sent by the new worker node, the coordinating node updates the node topology table using the registration message and broadcasts the online information of the new worker node to other worker nodes to trigger the establishment of NIO connections between the new worker node and the other worker nodes.

[0013] A second aspect of this application provides a distributed thread management system, including a coordinating node and multiple worker nodes. The coordinating node maintains a global lock registry, which includes lease information for all locks, wherein: A requesting worker node is used to send a lock request initiated by the corresponding thread to the coordinating node; the requesting worker node is the worker node among the plurality of worker nodes that receives the lock request, and the lock request includes a lock ID; The coordination node is used to obtain target lease information matching the lock ID from the global lock registry; the target lease information includes the lock status; The coordinating node is also configured to generate a lock token and send it to the requesting worker node when the lock state is in an idle state, and update the lock state to a non-idle state; the lock token includes a lease ID and a lease expiration time; The requesting worker node is also configured to, in response to the lock token, generate an permission instruction and send it to the corresponding thread; the permission instruction is configured to instruct the corresponding thread to perform a corresponding operation on the shared resource associated with the lock ID; The coordinating node is also configured to determine that the lease ID has expired if it does not receive a renewal request from the requesting worker node after the lease expires, and release the lock corresponding to the lease ID.

[0014] A third aspect of this application provides an electronic device, comprising: Processor; and A memory that stores executable code, which, when executed by the processor, causes the processor to perform the method described above.

[0015] The technical solution provided in this application may include the following beneficial results: The solution provided in this application is applied to a distributed thread management system, which includes a coordinating node and multiple worker nodes. The coordinating node maintains a global lock registry, which includes lease information for all locks. The solution includes: a requesting worker node sending a lock request initiated by a corresponding thread to the coordinating node; the requesting worker node is the worker node among multiple worker nodes that receives the lock request, and the lock request includes a lock ID; the coordinating node obtains target lease information matching the lock ID from the global lock registry; the target lease information includes the lock state; when the lock state is idle, the coordinating node generates a lock token and issues it to the requesting worker node, and updates the lock state to non-idle; the lock token includes a lease ID and a lease expiration time; the requesting worker node responds to the lock token, generates an allow instruction and issues it to the corresponding thread; the allow instruction instructs the corresponding thread to perform a corresponding operation on the shared resource associated with the lock ID; after the lease expiration time, if no renewal request is received from the requesting worker node, the coordinating node determines that the lease ID has expired and releases the lock corresponding to the lease ID. This application designs a custom distributed lock with a lease, binds the lease term to the lock token, and coordinates nodes to monitor the lease status of requesting worker nodes in real time. In this way, even if a network partition occurs, the lock is automatically released if the lease expires and is not renewed, ensuring the lock state is eventually consistent and guaranteeing construction safety.

[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0017] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.

[0018] Figure 1 This is a flowchart illustrating the distributed thread management method shown in an embodiment of this application; Figure 2 This is another flowchart illustrating the distributed thread management method shown in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the distributed thread management system shown in the embodiments of this application; Figure 4 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0019] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0020] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0021] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0022] In related technologies, lock management is implemented through third-party middleware (such as Redis's SETNX and ZooKeeper's ephemeral nodes). Taking ZooKeeper's distributed lock as an example, its typical process is as follows: multiple nodes compete for the lock by creating ephemeral ordered nodes, and the node with the smallest sequence number obtains the lock; when the lock is released, the node is deleted, and subsequent nodes detect and compete for the lock through the Watcher mechanism (ZooKeeper event listening mechanism).

[0023] It is evident that threads on each node need to frequently communicate with the middleware to confirm the lock status, which poses a middleware dependency risk. For example, when relying on third-party middleware, if the middleware cluster experiences a network partition (network partition: the cluster is split into multiple unconnected zones due to network failure), it may lead to "split-brain" (split-brain: each zone elects its own master node, and different master nodes issue the same lock at the same time), resulting in multiple nodes holding the lock simultaneously, which can easily cause security incidents.

[0024] To address the aforementioned issues, this application provides a distributed thread management method. By designing a custom distributed lock with a lease and binding the lease term to the lock token, the method coordinates nodes to monitor the lease status of requesting worker nodes in real time. In this way, even if a network partition occurs, the lock is automatically released if the lease expires and is not renewed, ensuring that the lock state is eventually consistent and guaranteeing construction safety.

[0025] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.

[0026] Figure 1 This is a flowchart illustrating a distributed thread management method according to an embodiment of this application. The method is applied to a distributed thread management system, which includes a coordinating node and multiple worker nodes. The coordinating node maintains a global lock registry, which includes lease information for all locks.

[0027] See Figure 1 The distributed thread management method of this application may include: S110, requesting the worker node to send the lock request initiated by the corresponding thread to the coordinating node; the requesting worker node is the worker node that received the lock request among multiple worker nodes, and the lock request includes the lock ID.

[0028] In this embodiment, the system can be applied to a distributed thread management system (hereinafter referred to as the "management system"). The management system is a distributed system composed of multiple nodes, which may include N worker nodes and one coordinator node, where N is an integer greater than 1. Worker nodes are responsible for executing specific business threads and include a local lock manager, thread state cache, NIO communication module, and message queue. Different worker nodes establish TCP (Transmission Control Protocol) connections through JavaNIO's SocketChannel. The coordinator node is responsible for maintaining the global lock state, managing node topology, and making migration decisions. It includes a global lock registry and a node state monitoring module. The coordinator node listens for worker node registration requests through a ServerSocketChannel. All lock messages and thread state data are transmitted through an NIO buffer, and read / write events are uniformly scheduled by a Selector.

[0029] In the specific implementation, firstly, the coordinating node is initialized: The ServerSocketChannel is started and bound to a port; a Selector is created to listen for connection events; the global lock registry is initialized, containing lease information for all locks (key: lock ID, value: holding node ID, holding version number, lease ID, lease expiration time); the node topology table is initialized, including node status data (such as node ID, IP, CPU / memory resources, online status) and thread status data (such as thread ID, execution progress, request version number, lease ID). Then, worker nodes register: The SocketChannel is started to connect to the coordinating node, sending a registration message (including node ID, number of CPU cores, remaining memory, and device type such as "tower crane / elevator"); upon receiving the registration message, the coordinating node updates the node topology table and broadcasts the worker node's online information to other worker nodes, triggering the establishment of NIO connections between the worker node and other worker nodes. Next, the worker node is initialized locally: a message queue is created. The message queue is a FIFO (First In First Out) structure used to cache lock requests, release messages, and thread state data to avoid out-of-order communication across nodes. In this embodiment, the capacity of the message queue can be set to 10,000 messages; the NIO processing thread is started (bound to the Selector); the local lock manager is initialized. The local lock manager is equivalent to the local cache of the worker node and can cache multiple lock states within a first time period (such as caching the most recent 100 lock states).

[0030] It should be noted that both the coordinating node and the worker nodes are servers. The worker nodes are used to control the construction site equipment (such as tower cranes, elevators, sensors, etc.), while the coordinating node is used to uniformly manage the execution order of threads on different worker nodes, thereby ensuring the atomicity and consistency of shared resource operations.

[0031] Each piece of equipment on the construction site is an independent shared resource. To ensure construction safety, any piece of equipment on the construction site can only be operated by one thread at a time. If a thread of a certain work node wants to operate a piece of equipment on the construction site, the thread can initiate a lock request to apply for the lock of the equipment. The lock is equivalent to the operating license of the equipment on the construction site, and each lock corresponds to one piece of equipment on the construction site.

[0032] Taking thread T1 on worker node A as an example: If thread T1 on worker node A needs to operate on shared resource R, then thread T1 initiates a lock request to the local lock manager of worker node A. The parameters of the lock request may include: lock ID=R, thread ID=T1, operation type=write, and request version number=V3. For ease of distinction, the worker node that receives the lock request (such as worker node A) can be defined as the requesting worker node. The requesting worker node A can forward the lock request to the coordinating node, or it can encapsulate the request message based on the lock request and then forward it to the coordinating node. The parameters of the request message may include: lock ID=R, node ID=WorkerA, thread ID=T1, request version number=V3, and first timestamp.

[0033] S120, the coordinating node obtains the target lease information matching the lock ID from the global lock registry; the target lease information includes the lock status.

[0034] After receiving a lock request or a request message encapsulated based on a lock request, the coordinating node extracts the target lease information with lock ID=R from the global lock registry. The parameters of the target lease information may include: lock ID (key), holding node ID (value), holding version number, lease ID, and lease expiration time. Among them, the holding node ID (value) can reflect the lock status (idle state / non-idle state).

[0035] S130, when the lock is in an idle state, the coordinating node generates a lock token and sends it to the requesting worker node, and updates the lock state to a non-idle state; the lock token includes the lease ID and the lease expiration time.

[0036] If the value of the target lease information (holding node ID) is empty, it means that the lock (lock ID=R) is not currently held by any worker node, and the lock is determined to be in an idle state. The coordinating node can generate a signature, lease ID (such as Lease001), and lease expiration time for the requesting worker node A. The signature can be generated based on the lock ID and node ID, and the lease expiration time = current time + TTL (Time To Live). The coordinating node encapsulates the signature, lease ID, and lease expiration time into a lock token, and then sends the lock token to the requesting worker node A. At the same time, the coordinating node updates the value of the target lease information (holding node ID) to the node ID (WorkerA) of worker node A, so that the lock state is updated to a non-idle state in the target lease information.

[0037] S140, the requesting worker node responds to the lock token, generates an allow instruction, and sends it to the corresponding thread; the allow instruction is used to instruct the corresponding thread to perform the corresponding operation on the shared resource associated with the lock ID.

[0038] After receiving the lock token in the message queue of the requesting worker node A, the requesting worker node A responds to the lock token by marking the lock with lock ID=R as "held" through the local lock manager, and then generates an allow instruction and sends it to thread T1, enabling thread T1 to perform the corresponding operation on the shared resource R associated with the lock ID. This operation matches the operation type in the lock request.

[0039] S150: If no renewal request is received from the requesting worker node after the lease expires, the coordinating node determines that the lease ID is invalid and releases the lock corresponding to the lease ID.

[0040] This application provides a custom distributed lock with version control and lease, including functions such as lock request priority sorting, automatic lock timeout release, and lock conflict detection, and realizes cross-node lock state synchronization based on message queue.

[0041] The automatic release function for lock timeout involves a lease mechanism. This mechanism mainly binds the TTL (e.g., 30s) to the lock token. The requesting worker node needs to send a renewal request to the coordinating node every 10s to maintain the validity of the lock. When the lease expires but is not renewed, the coordinating node automatically releases the lock, thereby avoiding lock resource leakage or long-term occupation.

[0042] In the specific implementation, when requesting worker node A marks the lock with lock ID=R as "held", it can start a lease renewal thread. Requesting worker node A infers the TTL based on the lease expiration time and the current time, and determines the sending frequency of renewal requests based on the TTL. For example, if TTL=30s, the sending frequency is determined to be 10s. Therefore, requesting worker node A can send a renewal request to the coordinating node every 10s. The parameters of the renewal request can include: lock ID=R, lease ID=Lease001. Whenever the coordinating node receives a renewal request, it can determine that lease ID=Lease001 is valid, thus maintaining the lock corresponding to lease ID=Lease001 (lock ID=R).

[0043] If the coordinating node does not receive a renewal request from the requesting worker node A for three consecutive times (with an interval of 10 seconds), or if the coordinating node does not receive a renewal request from the requesting worker node A after the lease expires, the coordinating node determines that ID=Lease001 is invalid and releases the lock corresponding to ID=Lease001 (lock ID=R).

[0044] As can be seen from this example, the solution provided in this application designs a custom distributed lock with a lease, binds the lease term to the lock token, and coordinates the nodes to monitor the lease status of the requesting worker nodes in real time. In this way, even if a network partition occurs, the lock is automatically released if the lease expires and is not renewed, ensuring that the lock state is eventually consistent and guaranteeing construction safety.

[0045] Figure 2 This is another flowchart illustrating the distributed thread management method shown in this application. The method is applied to a distributed thread management system, which includes a coordinating node and multiple worker nodes. The coordinating node maintains a global lock registry, which includes lease information for all locks.

[0046] See Figure 2 The distributed thread management method of this application may include: S210: After receiving a lock request initiated by the corresponding thread, the requesting worker node queries its local cache to see if the lock state matching the lock ID is in an idle state. The requesting worker node is the worker node that received the lock request among multiple worker nodes. The lock request includes the lock ID, thread ID, and request version number.

[0047] This step can be found in the description in S110, and will not be repeated here.

[0048] It should be noted that in this embodiment, the lock status can be queried directly by the coordinating node, or the lock status can be queried first by the requesting worker node and then by the coordinating node. This embodiment does not limit this.

[0049] For the method of directly querying the lock status by the coordinating node, please refer to the description in S110~S120, which will not be repeated here.

[0050] Specifically, for the method where the requesting worker node first queries the lock status and then the coordinating node queries the lock status, the following steps are taken: During the worker node registration phase, the coordinating node can issue a global lock registry to the worker node. The global lock registry includes lease information for all locks (key: lock ID, value: holding node ID, holding version number, lease ID, lease expiration time). The holding node ID (value) can reflect the lock status (idle state / non-idle state). The worker node can cache multiple lock states within a first time period in the local lock manager (such as caching the most recent 100 lock states). In practical applications, after the requesting worker node receives a lock request initiated by the corresponding thread, it can first query the local lock manager to see if the lock state matching the lock ID is in an idle state.

[0051] S220: When the local query finds that the lock is in a non-idle state, the requesting worker node encapsulates the lock ID, its own node ID, thread ID, request version number, and first timestamp into a request message, and sends the request message to the coordinating node through the NIO channel; where the NIO channel is a non-blocking I / O channel built on JavaNIO.

[0052] A lock request can include a lock ID, a thread ID, an operation type, and a request version number. When the lock status is found to be non-idle locally, the requesting worker node can extract the lock ID, thread ID, and request version number from the lock request. At the same time, it generates a first timestamp based on the current time so that the lock ID, its own node ID, thread ID, request version number, and first timestamp can be encapsulated into a request message.

[0053] It should be noted that the related technologies are extensions of the traditional Java synchronization mechanism. They extend synchronized (Java's built-in lock) / ReentrantLock (Java's explicit lock) to distributed scenarios via the network, but rely on blocking I / O. However, cross-node communication based on blocking I / O will generate a large number of thread blocks in high-concurrency scenarios, resulting in increased lock contention response latency (usually on the order of 100ms). Therefore, the response latency of the related technologies is significant under high concurrency.

[0054] In this application, embodiments provide a non-blocking lock message transmission layer (or cross-node non-blocking communication layer) built on JavaNIO (Java Non-blocking Input / Output). JavaNIO is a non-blocking I / O programming interface provided by the Java language. It uses a Selector to enable a single thread to listen to and manage multiple nodes' Channels, supports non-blocking read and write operations, reduces thread blocking overhead, and, combined with a message queue buffer lock request with a capacity of 10,000, reduces the average latency to less than 35ms.

[0055] In practical applications, request worker nodes can send request messages (including lock ID, node ID, thread ID, request version number, and first timestamp) to the coordinating node through NIO channels (non-blocking I / O channels built on Java NIO).

[0056] In one embodiment, after querying the local cache to see if the lock state matching the lock ID is in an idle state, the method may further include: When the local query finds that the lock is in an idle state, the request worker node directly generates an allow command and sends it to the corresponding thread.

[0057] When a local query indicates that the lock is idle, the requesting worker node can mark the lock associated with the lock ID as "held" through the local lock manager, and simultaneously synchronize lock messages with the coordinating node so that the coordinating node updates the target lease information. The requesting worker node can directly generate a permission command and issue it to the corresponding thread, enabling that thread to perform the appropriate operation on the shared resource associated with the lock ID.

[0058] Due to certain circumstances (such as network fluctuations), worker nodes and coordinating nodes may lose connection, leading to inconsistencies in the lock states maintained by both sides. To maximize lock state consistency, after a requesting worker node locally queries and finds the lock state to be idle, it can encapsulate the lock ID, node ID, and request version number into a verification request and send it to the coordinating node via the NIO channel. The coordinating node responds to the verification request by verifying whether the lock state is idle in the target lease information. If the verification confirms that the lock state is idle in the target lease information, the coordinating node updates the target lease information and generates a verification success message, which is returned to the requesting worker node via the NIO channel. In response to the verification success message, the requesting worker node marks the lock associated with the lock ID as "held" through its local lock manager, then generates an allow command and sends it to the corresponding thread, enabling that thread to perform the corresponding operation on the shared resource associated with the lock ID.

[0059] S230, the coordinating node obtains the target lease information matching the lock ID from the global lock registry; the target lease information includes the lock status.

[0060] This step can be found in the description in S120, and will not be repeated here.

[0061] S240, when the lock is in an idle state, the coordinating node generates a lock token and sends it to the requesting worker node, and updates the lock state to a non-idle state; the lock token includes the lease ID and the lease expiration time.

[0062] This step can be found in the description in S130, and will not be repeated here.

[0063] In one implementation, the coordinating node generates a lock token and issues it to the requesting worker nodes, and updates the lock state to a non-idle state, which may include: The coordinating node updates the target lease information using a request message so that the lock state is updated to non-idle in the target lease information; the target lease information also includes a lease ID and a lease expiration time, the lease expiration time being generated based on the current time and the valid time; the coordinating node encapsulates the lease ID and lease expiration time into a lock token and returns it to the requesting worker node through the NIO channel.

[0064] After the coordinating node finds that the lock is in an idle state, it can generate a lease ID (e.g., Lease001) for the requesting worker node and generate a lease expiration time based on the current time and validity period (e.g., TTL=30s). Then, it updates the target lease information using the request message, lease ID, and lease expiration time. For example, the coordinating node updates the value (holding node ID) in the target lease information to the node ID (e.g., WorkerA) in the request message, so that the lock state is updated to non-idle in the target lease information. It also updates the holding version number in the target lease information to the request version number (e.g., V3) in the request message, updates the lease ID in the target lease information to the currently generated lease ID (e.g., Lease001), and updates the lease expiration time in the target lease information to the currently generated lease expiration time. The parameters of the updated target lease information can be, for example: key: lock ID=R, value: holding node ID=WorkerA, holding version number=V3, lease ID=Lease001, lease expiration time=current time+30s.

[0065] The coordinating node can generate a signature based on the lock ID and node ID, and then encapsulate the signature, lease ID, and lease expiration time into a lock token, so that the lock token can be returned to the requesting worker node through the NIO channel.

[0066] In one embodiment, the target lease information further includes a holding version number; after the coordinating node obtains the target lease information matching the lock ID from the global lock registry, the method may further include: When the lock is in a non-idle state, the coordinating node compares the held version number with the requested version number. If the held version number is less than the requested version number, the coordinating node sorts the request message according to the first timestamp and stores it in the waiting queue, and generates a queuing notification message to return to the requesting worker node through the NIO channel. The queuing notification message is used to instruct the requesting worker node to wait in the queue. Alternatively, if the held version number is greater than or equal to the requested version number, the coordinating node generates a version error message to return to the requesting worker node through the NIO channel. The version error message is used to instruct the requesting worker node to reject the lock request of the corresponding thread.

[0067] As mentioned above, the custom distributed lock provided in this application embodiment has a lock conflict detection function. The core of this function is to solve the lock state conflict problem by introducing a version number mechanism. Specifically, after the coordinating node detects that the lock state is not idle, to avoid lock state conflicts caused by dirty writes, the coordinating node can compare the holding version number in the target lease information with the request version number in the request message: If the holding version number is less than the request version number (for example, the request version number is V3 and the holding version number is V2), the coordinating node can sort the request message according to the first timestamp and store it in the waiting queue, then generate a queuing notification message and return the queuing notification message to the requesting worker node through the NIO channel to notify the requesting worker node to wait in the queue until the coordinating node detects that the lock state has switched to the idle state and the request message of the requesting worker node is in the queue. Then the coordinating node returns to execute step S240 to complete the lock transfer; or, if the holding version number is greater than or equal to the request version number (for example, the request version number is V1 and the holding version number is V2; or the request version number is V3 and the holding version number is also V3), the coordinating node generates a version error message and returns the version error message to the requesting worker node through the NIO channel to notify the requesting worker node to reject the lock request of the corresponding thread.

[0068] S250, the requesting worker node responds to the lock token, generates an allow instruction, and sends it to the corresponding thread; the allow instruction is used to instruct the corresponding thread to perform the corresponding operation on the shared resource associated with the lock ID.

[0069] This step can be found in the description in S140, and will not be repeated here.

[0070] In one embodiment, the method may further include: If a release message is received from a requesting worker node during the lease expiration period, the coordinating node updates the target lease information using the release message so that the lock state is updated to the idle state in the target lease information; the release message is used to indicate that the corresponding thread has completed the operation on the shared resource.

[0071] During the lease expiration period, if a thread completes its operation on the shared resource, it can send a release message (containing the lock ID, request version number, and lease ID) to the requesting worker node. The requesting worker node will then forward the release message to the coordinating node via the NIO channel.

[0072] The coordinating node updates the target lease information using a release message, causing the lock state to be updated to the idle state in the target lease information, and deletes the corresponding lease record. For example, the coordinating node updates the value (holding node ID) in the target lease information to null, thus updating the lock state to the idle state in the target lease information, and also updates the lease ID and lease expiration time in the target lease information to null. The parameters of the updated target lease information can be, for example: key: lock ID=R, value: holding node ID=NULL, holding version number=V3, lease ID=NULL, lease expiration time=NULL.

[0073] At this point, the coordinating node can retrieve the next requesting worker node (such as worker node B) from the waiting queue, return to step S240, and complete the lock transfer.

[0074] In one embodiment, the method may further include: Within the lease expiration period, if an operation log generated after the corresponding thread completes its operation is received, the requesting worker node broadcasts the operation log to other worker nodes via a message queue. The operation log includes the lock ID, new data, request version number, second timestamp, and node ID. Other worker nodes compare their local version number with the request version number. If the local version number is less than the request version number, the other worker nodes update their locally cached resource data and the local version number based on the operation log. Alternatively, if the local version number is greater than or equal to the request version number, the other worker nodes discard the operation log. Other worker nodes generate confirmation information and send it to the coordinating node for recording via an NIO channel. The confirmation information indicates that other worker nodes have either updated their local data based on the operation log or discarded the operation log.

[0075] In addition, the related technologies use asynchronous notifications via message queues, which utilize Kafka (message queue) / RabbitMQ (open source message middleware) to transmit collaborative signals. However, additional handling is required for message ordering and duplicate consumption issues. For example, the synchronization of thread states (such as lock wait time and priority) between nodes depends on scheduled tasks, which can easily lead to inconsistent states (such as threads that have released the lock still being marked as holding it). Therefore, the related technologies suffer from untimely state synchronization.

[0076] In this embodiment, thread operation logs are broadcast in real time via a message queue, ensuring consistency of cross-node data updates based on the principle of distributed transactions, with a state synchronization delay of ≤10ms.

[0077] In the specific implementation, if a thread completes its operation on the shared resource within the lease expiration period, in addition to sending a release message (containing the lock ID, request version number, and lease ID) to the requesting worker node, the thread can also send an operation log (containing the lock ID, new data, request version number, second timestamp, and node ID) to the requesting worker node. After receiving the operation log, the requesting worker node can broadcast the operation log to other worker nodes (all worker nodes except the requesting worker node) in real time through a message queue.

[0078] After receiving the operation log, other worker nodes compare the local version number cached by the local lock manager with the request version number carried in the operation log: if the local version number is less than the request version number (for example, the request version number is V3 and the local version number is V2), then the resource data cached by the local lock manager is updated with the new data carried in the operation log, and the local version number cached by the local lock manager is updated with the request version number carried in the operation log; or, if the local version number is greater than or equal to the request version number (for example, the request version number is V1 and the local version number is V2; or, the request version number is V3 and the local version number is also V3), then the operation log is discarded to avoid dirty writes.

[0079] After consuming the operation logs, other worker nodes generate confirmation messages and send them to the coordinating node via NIO channels. The coordinating node records the consumption status of all worker nodes to ensure that the operation logs are not lost.

[0080] S260: If no renewal request is received from the requesting worker node after the lease expires, the coordinating node determines that the lease ID is invalid and releases the lock corresponding to the lease ID.

[0081] This step can be found in the description in S150, and will not be repeated here.

[0082] In one embodiment, the method may further include: Each worker node periodically sends a heartbeat detection message to the coordinating node. If the coordinating node fails to receive a heartbeat detection message from the same worker node for M consecutive times, it determines the worker node as an offline abnormal worker node; M is an integer greater than 1. The coordinating node extracts the lock ID associated with the abnormal worker node from the global lock registry and the thread state data associated with the abnormal worker node from the node topology table; the thread state data includes the thread ID and execution progress. Based on a consistent hashing algorithm, the coordinating node determines the target worker node from multiple worker nodes, and migrates the extracted lock ID and thread state data to the target worker node through the NIO channel; the hash factor of the consistent hashing algorithm is the lock ID and the thread ID. The target worker node reconstructs the thread using the thread state data to restore the execution progress. The target worker node generates a takeover request and sends it to the coordinating node through the NIO channel. In response to the takeover request, the coordinating node updates the information of the abnormal worker node in the global lock registry with the information of the target worker node, and updates the information of the abnormal worker node in the node topology table with the information of the target worker node.

[0083] Furthermore, in related technologies, when a node exits abnormally or a new node joins, the thread state (such as waiting queue or lock holding information) cannot be automatically migrated, requiring manual intervention to restore it. Therefore, related technologies suffer from poor adaptability of dynamic nodes.

[0084] In this embodiment, the worker nodes periodically send heartbeat detection messages to the coordinating node through the Java NIO timed task mechanism, enabling the coordinating node to monitor the online status of the worker nodes in real time and provide a triggering basis for dynamic migration. For example, when a worker node joins or leaves the cluster, the coordinating node can migrate the thread context information (such as lock holding status, execution progress, and data version number) on the worker node to the target worker node through the network to achieve thread reconstruction.

[0085] In the specific implementation, each worker node sends a heartbeat detection message to the coordinating node periodically (e.g., once per second). If the coordinating node does not receive a heartbeat detection message from the same worker node (e.g., worker node C) for M consecutive times (e.g., 3 consecutive times), the coordinating node determines that the worker node is offline (e.g., offline due to a system crash). To facilitate differentiation, worker nodes in the offline state are defined as abnormal worker nodes. The coordinating node triggers an automatic thread state transition strategy: the coordinating node queries the global lock registry for locks held by the abnormal worker node. For example, it filters the lease information in the global lock registry based on the node ID (WorkerC) of the abnormal worker node, i.e., it filters out lease information holding node ID=WorkerC. The coordinating node extracts the lock ID (e.g., lock ID=R, lock ID=S) from this lease information. At the same time, the coordinating node queries the node topology table for abnormal worker nodes. The coordinating node collects thread state data for currently running threads. This data can include thread ID, execution progress, request version number, and lease ID. For example, if an abnormal worker node is running thread T3, thread T3's thread state data could be: thread ID = T3, execution progress = 70%, request version number = V3, and lease ID = Lease002. The coordinating node uses a consistent hashing algorithm (hash factor: lock ID + thread ID) to determine the migration target from all worker nodes except the abnormal worker node. For example, the coordinating node selects a worker node from multiple worker nodes that matches the equipment type controlled by the abnormal worker node, has sufficient resources (e.g., CPU core count / remaining memory ≥ preset resource threshold), is online, and matches the abnormal worker node's local version number. This migration target is defined as the target worker node for easy differentiation. The coordinating node can then migrate the extracted lock ID and thread state data (after serialization) to the target worker node via an NIO channel. The target worker node can deserialize thread state data to reconstruct each thread, thereby restoring the execution progress of each thread. For example, target worker node D uses the thread state data of thread T3: thread ID=T3, execution progress=70%, request version number=V3, lease ID=Lease002, to reconstruct thread T3, thus restoring the execution progress of thread T3 to 70%. The target worker node generates a takeover request (including lock ID and request version number) and sends the takeover request to the coordinating node through the NIO channel.In response to the takeover request, the coordinating node updates the information of the abnormal worker node in the global lock registry to the information of the target worker node, and also updates the information of the abnormal worker node in the node topology table to the information of the target worker node. For example, the value of the lease information (holding node ID) of the lock held by the coordinating node in the lease information of the abnormal worker node is updated from the node ID (WorkerC) of the abnormal worker node to the node ID (WorkerD) of the target worker node, and the node ID in the node state data of the abnormal worker node is updated from the node ID (WorkerC) of the abnormal worker node to the node ID (WorkerD) of the target worker node, so that the lock holding state is updated from "thread T3@WorkerC" to "thread T3@WorkerD", completing the migration.

[0086] In one embodiment, the method may further include: When the coordinating node receives a registration message from a new worker node, it synchronizes the global lock registry and multiple historical operation logs within the second time period with the new worker node. The new worker node is a worker node newly added to the distributed thread management system. The registration message includes the node ID, number of CPU cores, remaining memory, and device type. The new worker node initializes the local lock manager to cache the global lock registry through the local lock manager. In addition, the new worker node initializes the message queue to cache multiple historical operation logs through the message queue. After receiving the synchronization completion message from the new worker node, the coordinating node updates the node topology table using the registration message and broadcasts the new worker node's online information to other worker nodes to trigger the establishment of NIO connections between the new worker node and other worker nodes.

[0087] To facilitate differentiation, newly added work nodes to the management system are defined as new work nodes. New work nodes (e.g., work node E) need to complete registration and local initialization: New work node E starts a SocketChannel connection to the coordinating node to send a registration message (including node ID=WorkerE, number of CPU cores, remaining memory, and device type such as "tower crane / elevator"); Since new work node E is added to the management system later than the time when work node A was requested to join in step S110 above, after receiving the registration message from new work node E, the coordinating node, while synchronizing the global lock registry to new work node E, can also synchronize multiple historical operation logs within the second time period; New work node E initializes the local lock manager to enable local... The lock manager caches multiple lock states within the first time period in the global lock registry (e.g., caching the most recent 100 lock states); simultaneously, the new worker node E initializes a message queue (with a capacity of 10,000 entries) to cache multiple historical operation logs within the second time period (e.g., historical operation logs from the last 5 minutes); also, the new worker node E initializes an NIO processing thread (binding a Selector); after data alignment is completed, the new worker node E sends a synchronization completion message to the coordinating node, causing the coordinating node to update the node topology table using a registration message and broadcast the new worker node E's online information to other worker nodes (e.g., requesting worker node A, requesting worker node B, and target worker node D), thereby triggering the establishment of NIO connections between the new worker node E and other worker nodes, enabling the new worker node E to participate in lock contention.

[0088] As can be seen from this example, the solution provided in this application has at least the following technical advantages: (1) Non-blocking lock message transmission mechanism based on Java NIO This application embodiment is based on Java NIO non-blocking communication and message queue buffering. It uses a Selector to manage multiple nodes' Channels in a single thread, and uses ByteBuffer (byte buffer) for non-blocking read and write of lock request / release messages. Combined with a message queue with a capacity of 10,000 messages, it implements asynchronous buffering to avoid thread blocking.

[0089] As can be seen, compared with the BIO (Blocking I / O) solution in related technologies, the embodiments of this application, in the same test environment (such as 10 nodes + 5000 QPS (Queries Per Second)), have an average lock request latency of ≤35ms in high-concurrency scenarios, and the lock request throughput is improved by more than 50% compared with the traditional blocking I / O solution, thereby solving the communication performance bottleneck in related technologies.

[0090] (2) Custom distributed lock mechanism with lease and version control In this embodiment of the application, the lock state is bound to the holding version number. Each lock request carries the request version number. The coordinating node prevents dirty writes by comparing the holding version number with the request version number. The lock token is bound to the lease period of TTL (e.g., 30s). The requesting worker node sends a renewal request to the coordinating node every 10s. The coordinating node monitors the lease status of the requesting worker node in real time so as to automatically release the lock when the lease expires and is not renewed.

[0091] As can be seen, under the same test scenario (such as a 10-minute network partition), compared with the ZooKeeper distributed lock in related technologies, the lock state conflict rate of this application embodiment can be reduced by 95.7% and the consistency guarantee rate is 100%, thereby solving the data consistency risks existing in related technologies.

[0092] (3) Automatic thread state transition strategy based on consistent hashing algorithm In this embodiment, migration is triggered by node heartbeat detection (1 time / second) and the target worker node is determined by a consistent hashing algorithm (thread ID + lock ID as hash factor) to minimize the amount of data migration. The migration snapshot includes lock holding information (lock ID), execution progress, request version number, etc. The thread is reconstructed after the target worker node is deserialized, and a "migration lock" is added during the migration process to prevent conflicts.

[0093] As can be seen, in the same test scenario (2 out of 10 nodes offline), compared with the manual intervention recovery in related technologies, the migration time of this application embodiment can be reduced by 96%, making the migration time ≤1.5s, and the recovery success rate can be improved by 9.8%, thereby solving the problem of poor dynamic node adaptability in related technologies.

[0094] (4) Data synchronization mechanism combining message queues and distributed transactions In this embodiment of the application, the thread operation log is broadcast in real time through a message queue, and the receiving node performs the update based on the version number verification; a "log broadcast + confirmation feedback" mechanism is adopted to coordinate the nodes to ensure that the operation log is delivered 100% and avoid some nodes from failing to update.

[0095] As can be seen, the state synchronization delay in this embodiment is ≤30ms; the entire cluster data view... Figure 1 The consistency guarantee rate is 100%, with no data gaps.

[0096] Corresponding to the aforementioned application function implementation method embodiments, this application also provides a distributed thread management system, an electronic device, and corresponding embodiments.

[0097] Figure 3 This is a schematic diagram of the structure of a distributed thread management system shown in an embodiment of this application.

[0098] See Figure 3 The distributed thread management system of this application may include a coordinating node 320 and multiple worker nodes 310. The coordinating node maintains a global lock registry, which includes lease information for all locks, wherein: Request worker node 311 is used to send the lock request initiated by the corresponding thread to the coordinating node; request worker node 311 is the worker node 310 among multiple worker nodes that received the lock request, and the lock request includes the lock ID; Coordination node 320 is used to obtain target lease information matching the lock ID from the global lock registry; the target lease information includes the lock status. The coordinating node 320 is also used to generate a lock token and send it to the requesting worker node 311 when the lock is in an idle state, and to update the lock state to a non-idle state; the lock token includes the lease ID and the lease expiration time; The request to worker node 311 is also used to generate an allow instruction in response to the lock token and send it to the corresponding thread; the allow instruction is used to instruct the corresponding thread to perform the corresponding operation on the shared resource associated with the lock ID; The coordinating node 320 is also used to determine that the lease ID is invalid and release the lock corresponding to the lease ID if it does not receive a renewal request from the requesting worker node 311 after the lease expires.

[0099] In one embodiment, the lock request also includes a thread ID and a request version number, and the requesting worker node 311 locally caches multiple lock states within a first time period; when the requesting worker node 311 executes the step of sending the lock request initiated by the corresponding thread to the coordinating node, it is specifically used for: Upon receiving a lock request from the corresponding thread, check the local cache to see if the lock state matching the lock ID is in an idle state. When the local query finds that the lock is not idle, the lock ID, its own node ID, thread ID, request version number, and first timestamp are encapsulated into a request message, and the request message is sent to the coordinating node 320 through the NIO channel; where the NIO channel is a non-blocking I / O channel built on JavaNIO.

[0100] In one embodiment, when the coordinating node 320 performs the steps of generating a lock token and issuing it to the requesting worker node 311, and updating the lock state to a non-idle state, it specifically performs the following: The target lease information is updated using a request message so that the lock state is updated to non-idle in the target lease information; the target lease information also includes lease ID and lease expiration time, the lease expiration time is generated based on the current time and the validity period; Encapsulate the lease ID and lease expiration time into a lock token and return it to the requesting worker node 311 via the NIO channel.

[0101] In one implementation, the target lease information also includes a holding version number; after performing the step of retrieving the target lease information matching the lock ID from the global lock registry, the coordinating node 320 can also be used for: When the lock is in a non-idle state, the held version number is compared with the requested version number; If the held version number is less than the requested version number, the request message is sorted by its first timestamp and stored in a waiting queue. A queuing notification is generated and returned to the requesting worker node via the NIO channel. The queuing notification instructs the requesting worker node 311 to wait in the queue. Alternatively, If the held version number is greater than or equal to the requested version number, a version error message is generated and returned to the requesting worker node 311 via the NIO channel; the version error message is used to instruct the requesting worker node 311 to reject the lock request of the corresponding thread.

[0102] In one embodiment, the coordination node 320 can also be used for: If a release message is received from worker node 311 during the lease expiration period, the target lease information is updated using the release message so that the lock state is updated to the idle state in the target lease information; the release message is used to indicate that the corresponding thread has completed the operation on the shared resource.

[0103] In one implementation, requesting worker node 311 can also be used for: If an operation log generated after the corresponding thread completes its operation is received within the lease expiration period, the operation log will be broadcast to other worker nodes 310 via a message queue. The operation log includes the lock ID, new data, request version number, second timestamp, and node ID. Other working nodes 310 can be used for: Compare the local version number with the requested version number; If the local version number is less than the requested version number, other worker nodes update the locally cached resource data and local version number based on the operation logs; or, If the local version number is greater than or equal to the requested version number, discard the operation log; A confirmation message is generated and sent to the coordinating node 320 via the NIO channel for recording; the confirmation message is used to indicate that other working nodes 310 have either updated the operation log locally or discarded the operation log.

[0104] In one embodiment, the coordinating node 320 also maintains a node topology table, which includes thread state data; each worker node 310 can be used for: Send heartbeat detection messages to coordinating node 320 periodically; Coordinating node 320 can also be used for: If a worker node fails to receive a heartbeat detection message from the same worker node for M consecutive times, then worker node 310 is determined to be an abnormal worker node 312 that is offline; M is an integer greater than 1. Extract the lock ID associated with the abnormal worker node 312 from the global lock registry, and extract the thread state data associated with the abnormal worker node from the node topology table; the thread state data includes the thread ID and execution progress. Based on the consistent hashing algorithm, the target worker node 313 is determined from multiple worker nodes 310, so that the extracted lock ID and thread state data can be migrated to the target worker node 313 through the NIO channel; wherein, the hash factor of the consistent hashing algorithm is the lock ID and the thread ID; Target worker node 313 can be used for: The thread is reconstructed using thread state data to restore execution progress; Generate a takeover request and send it to the coordinating node 320 via the NIO channel; Coordinating node 320 can also be used for: In response to the takeover request, the information of the abnormal worker node 312 is updated in the global lock registry to the information of the target worker node 313, and the information of the abnormal worker node 312 is updated in the node topology table to the information of the target worker node 313.

[0105] In one embodiment, the coordinating node 320 also maintains a node topology table; the coordinating node 320 can also be used for: Upon receiving the registration message from the new worker node 314, the global lock registry and multiple historical operation logs within the second time period are synchronized to the new worker node 314. The new worker node 314 is the worker node 310 that has just joined the distributed thread management system. The registration message includes the node ID, number of CPU cores, remaining memory, and device type. The new working node 314 can be used for: Initialize the local lock manager to cache the global lock registry; and, Initialize the message queue to cache multiple historical operation logs; Coordinating node 320 can also be used for: After receiving the synchronization completion message from the new worker node, the node topology table is updated using a registration message, and the online information of the new worker node 314 is broadcast to other worker nodes 310 to trigger the establishment of NIO connections between the new worker node 314 and other worker nodes 310.

[0106] As can be seen from this example, the solution provided in this application designs a custom distributed lock with a lease, binds the lease term to the lock token, and coordinates the nodes to monitor the lease status of the requesting worker nodes in real time. In this way, even if a network partition occurs, the lock is automatically released if the lease expires and is not renewed, ensuring that the lock state is eventually consistent and guaranteeing construction safety.

[0107] Regarding the system in the above embodiments, the specific ways in which each module performs operations have been described in detail in the embodiments related to the method, and will not be elaborated further here.

[0108] Figure 4 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application.

[0109] See Figure 4 The electronic device 400 includes a memory 410 and a processor 420.

[0110] The processor 420 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. Memory 410 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by processor 420 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 410 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 410 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, an ultra-high density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.

[0111] The memory 410 stores executable code, which, when processed by the processor 420, can cause the processor 420 to execute part or all of the methods described above.

[0112] Furthermore, the method according to this application can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing some or all of the steps in the method described above.

[0113] Alternatively, this application may be implemented as a computer-readable storage medium (or a non-transitory machine-readable storage medium or a machine-readable storage medium) storing executable code (or computer program or computer instruction code) that, when executed by a processor of an electronic device (or server, etc.), causes the processor to perform part or all of the steps of the methods described above according to this application.

[0114] This application also provides a computer program product, which includes computer instructions that, when executed by a processor, implement the method described above.

[0115] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A distributed thread management method, characterized in that, The method is applied to a distributed thread management system, which includes a coordinating node and multiple worker nodes. The coordinating node maintains a global lock registry, which includes lease information for all locks. The requesting worker node sends the lock request initiated by the corresponding thread to the coordinating node; the requesting worker node is the worker node among the plurality of worker nodes that receives the lock request, and the lock request includes a lock ID; The coordinating node obtains target lease information matching the lock ID from the global lock registry; the target lease information includes the lock status; When the lock is in an idle state, the coordinating node generates a lock token and sends it to the requesting worker node, and updates the lock state to a non-idle state; the lock token includes a lease ID and a lease expiration time; The requesting worker node responds to the lock token by generating an permission instruction and sending it to the corresponding thread; the permission instruction is used to instruct the corresponding thread to perform a corresponding operation on the shared resource associated with the lock ID; If no renewal request is received from the requesting worker node after the lease expires, the coordinating node determines that the lease ID is invalid and releases the lock corresponding to the lease ID.

2. The method according to claim 1, characterized in that, The lock request also includes a thread ID and a request version number, and the request worker node has multiple lock states cached locally within a first time period; The requesting worker node sends the lock request initiated by the corresponding thread to the coordinating node, including: After receiving a lock request initiated by the corresponding thread, the request worker node queries the local cache to see if the lock state matching the lock ID is in an idle state. When the local query finds that the lock is in a non-idle state, the requesting worker node encapsulates the lock ID, its own node ID, the thread ID, the request version number, and the first timestamp into a request message, and sends the request message to the coordinating node through the NIO channel; wherein, the NIO channel is a non-blocking I / O channel built on JavaNIO.

3. The method according to claim 2, characterized in that, The coordinating node generates a lock token and issues it to the requesting worker node, and updates the lock state to a non-idle state, including: The coordinating node updates the target lease information using the request message, so that the lock state is updated to a non-idle state in the target lease information; the target lease information also includes a lease ID and a lease expiration time, the lease expiration time being generated based on the current time and the valid time; The coordinating node encapsulates the lease ID and the lease expiration time into a lock token and returns it to the requesting worker node via the NIO channel.

4. The method according to claim 2, characterized in that, The target lease information also includes a holding version number; after the coordinating node obtains the target lease information matching the lock ID from the global lock registry, the method further includes: When the lock is in a non-idle state, the coordinating node compares the held version number with the requested version number; If the held version number is less than the requested version number, the coordinating node will sort the request message according to the first timestamp and store it in a waiting queue, and generate queuing notification information to return to the requesting worker node through the NIO channel; the queuing notification information is used to instruct the requesting worker node to wait in the queue; or... If the held version number is greater than or equal to the requested version number, the coordinating node generates a version error message to return to the requesting worker node through the NIO channel; the version error message is used to instruct the requesting worker node to reject the lock request of the corresponding thread.

5. The method according to claim 2, characterized in that, The method further includes: If a release message is received from the requesting worker node during the lease expiration period, the coordinating node uses the release message to update the target lease information so that the lock state is updated to an idle state in the target lease information; the release message is used to indicate that the corresponding thread has completed the operation on the shared resource.

6. The method according to claim 5, characterized in that, The method further includes: If, during the lease expiration period, an operation log generated by the corresponding thread after completing the operation is received, the requesting worker node will broadcast the operation log to other worker nodes through a message queue; the operation log includes the lock ID, new data, the request version number, the second timestamp, and the node ID; The other working nodes compare their local version number with the requested version number; If the local version number is less than the requested version number, then the other worker nodes update the locally cached resource data and the local version number based on the operation log; or, If the local version number is greater than or equal to the requested version number, then the other working nodes discard the operation log; The other working nodes generate confirmation information and send it to the coordinating node through the NIO channel for recording; the confirmation information is used to indicate that the other working nodes have performed local updates based on the operation log or have discarded the operation log.

7. The method according to claim 1, characterized in that, The coordinating node also maintains a node topology table, which includes thread state data; the method further includes: Each of the aforementioned working nodes periodically sends a heartbeat detection message to the coordinating node; If the coordinating node fails to receive a heartbeat detection message from the same working node for M consecutive times, it will determine the working node as an abnormal working node in an offline state; where M is an integer greater than 1. The coordinating node extracts the lock ID associated with the abnormal worker node from the global lock registry, and extracts the thread status data associated with the abnormal worker node from the node topology table; the thread status data includes the thread ID and execution progress. The coordinating node determines the target worker node from the plurality of worker nodes based on the consistent hashing algorithm, so as to migrate the extracted lock ID and thread state data to the target worker node through the NIO channel; wherein, the hash factor of the consistent hashing algorithm is the lock ID and the thread ID; The target worker node uses the thread state data to reconstruct the thread in order to restore the execution progress; The target working node generates a takeover request and sends it to the coordinating node via the NIO channel; In response to the takeover request, the coordinating node updates the information of the abnormal worker node in the global lock registry to the information of the target worker node, and updates the information of the abnormal worker node in the node topology table to the information of the target worker node.

8. The method according to claim 1, characterized in that, The coordinating node also maintains a node topology table; the method further includes: When the coordinating node receives a registration message from a new worker node, it synchronizes the global lock registry and multiple historical operation logs within the second time period with the new worker node; the new worker node is a worker node newly added to the distributed thread management system, and the registration message includes node ID, number of CPU cores, remaining memory, and device type; The new worker node initializes the local lock manager to cache the global lock registry; and, The new worker node initializes a message queue to cache the multiple historical operation logs. After receiving the synchronization completion message sent by the new worker node, the coordinating node updates the node topology table using the registration message and broadcasts the online information of the new worker node to other worker nodes to trigger the establishment of NIO connections between the new worker node and the other worker nodes.

9. A distributed thread management system, characterized in that, It includes a coordinating node and multiple worker nodes. The coordinating node maintains a global lock registry, which includes lease information for all locks, wherein: A requesting worker node is used to send a lock request initiated by the corresponding thread to the coordinating node; the requesting worker node is the worker node among the plurality of worker nodes that receives the lock request, and the lock request includes a lock ID; The coordination node is used to obtain target lease information matching the lock ID from the global lock registry; the target lease information includes the lock status; The coordinating node is also configured to generate a lock token and send it to the requesting worker node when the lock state is in an idle state, and update the lock state to a non-idle state; the lock token includes a lease ID and a lease expiration time; The requesting worker node is also configured to, in response to the lock token, generate an permission instruction and send it to the corresponding thread; the permission instruction is configured to instruct the corresponding thread to perform a corresponding operation on the shared resource associated with the lock ID; The coordinating node is also configured to determine that the lease ID has expired if it does not receive a renewal request from the requesting worker node after the lease expires, and release the lock corresponding to the lease ID.

10. An electronic device, characterized in that, include: processor; as well as A memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1-8.

Images