Lock Server Fault Isolation in Distributed Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In distributed systems, when a lock server fails, all lock servers become silent, preventing them from processing locking requests and leading to service interruptions and reduced reliability.
Innovation Solution
A method where each lock server stores takeover relationship information, allowing non-takeover lock servers to process locking requests normally by determining a takeover lock server upon notification of a faulty server, using a consistent hashing ring to manage lock server relationships and allocate permissions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If all lock servers enter a silent state when one lock server fails, then the faulty lock server is isolated and prevented from causing further issues, but the distributed system loses the ability to process locking requests globally, causing service interruption
Solution Approach 1:
The patent segments the lock server functionality by introducing the concept of takeover relationship information that divides lock servers into different roles (takeover and non-takeover). When a lock server fails, only the designated takeover lock server enters a silent state, while other non-takeover lock servers continue to process locking requests. This segmentation allows the system to isolate the impact of a single failure to a specific subset of servers rather than affecting the entire system.
Solution Approach 2:
The patent applies local quality by making different lock servers have different operational states based on their relationship to the failed server. Non-takeover lock servers maintain normal locking request processing capabilities, while the takeover lock server enters a silent state. This creates localized quality differences in server behavior, allowing the system to maintain overall functionality while isolating the failure impact to a specific local component.
2Reliability
If a takeover lock server enters a silent state to handle lock reclaim requests, then lock permission consistency is maintained, but locking requests cannot be processed by any server in the distributed system
Solution Approach 1:
The patent segments lock request handling by directing different types of requests to different server groups. Lock reclaim requests are routed to the takeover lock server (which enters silent state), while locking requests are routed to non-takeover lock servers (which remain operational). This segmentation allows the system to maintain lock permission consistency through the takeover server while preserving locking request availability through non-takeover servers.
Solution Approach 2:
The patent introduces a routing mechanism that acts as an intermediary between clients and lock servers. This intermediary (protocol server or lock proxy) receives locking requests and intelligently routes them to appropriate non-takeover lock servers, while directing lock reclaim requests to the takeover lock server. This intermediary layer enables the system to maintain both consistency and availability simultaneously by mediating request distribution.
3Speed
If lock server takeover relationship information is stored in each lock server, then the system can quickly determine which server should enter silent state, but the system complexity increases due to the need to manage and synchronize this additional information
Solution Approach 1:
The patent applies preliminary action by pre-establishing takeover relationship information before any failure occurs. Each lock server is pre-configured with information about which servers are its takeover targets and which are its non-takeover peers. When a failure occurs, this pre-stored information enables immediate determination of the silent state requirement without complex real-time calculations or queries, thus achieving fast fault response while keeping the information management structure relatively simple.
Data Source
Figure 1
Figure 2
Figure 3-1~3-2
AI summary
A method for processing a fault of a lock server in a distributed system is disclosed, where the distributed system includes m lock servers, each lock server locally stores same lock server takeover relationship information, and m is a natural number greater than 2. Lock servers in the distributed system that are not faulty receive a first notification message, where the first notification message carries information about a fault of a first lock server; after receiving the first notification message, a second lock server in the distributed system determines that the second lock server is a takeover lock server of the first lock server according to locally stored lock server takeover relationship information, and the takeover lock server enters a silent state; after receiving the first notification message, a third lock server in the distributed system determines that the third lock server is not the takeover lock server of the first lock server according to locally stored lock server takeover relationship information; and after receiving a locking request, the third lock server allocates lock permission information according to the locking request. In the present invention, an affected range of a faulty lock server can be minimized and stability of a distributed system is enhanced.