Abstract:This paper describes PaxosLease, a distributed algorithm for lease negotiation. PaxosLease is based on Paxos, but does not require disk writes or clock synchrony. PaxosLease is used for master lease negotation in the open-source Keyspace and ScalienDB replicated key-value stores.
What problem does this paper attempt to address?
The problem that this paper attempts to solve is how to effectively conduct lease negotiation in a highly available distributed system to avoid the entire system from being blocked due to a single - node failure, and in the presence of multiple proposers, to avoid mutual blocking among proposers.
Specifically, the paper proposes a distributed algorithm named PaxosLease for lease negotiation. PaxosLease is based on the Paxos algorithm but does not require disk write operations or clock synchronization. This algorithm is mainly used for master - node lease negotiation in the open - source Keyspace and ScalienDB replicated key - value stores.
### Background and Problem Description
In concurrent programming, a lock is a basic primitive, and processes use it to synchronize access to shared resources. In a system without an expiration time (and no supervisory process), if the owner of the lock fails before releasing the lock, other processes may be blocked.
In a highly available distributed system, the failure of a single node should not cause the entire system to be blocked. Moreover, restarting a distributed system is much more difficult than restarting a multithreaded program. Therefore, in a distributed system, leases replace locks to avoid starvation. A lease is a lock with an expiration time. If the owner of the lock fails or disconnects, its lease will automatically expire, and other nodes can acquire the lease.
### Specific Manifestations of the Problem
Although a simple majority - voting algorithm can correctly solve the distributed lease problem (that is, only one node holds the lease at any time), in the presence of multiple proposers, this simple algorithm will be frequently blocked. For example, if there are three proposers 1, 2, and 3 and three acceptors A, B, and C, if A accepts the request of 1, B accepts the request of 2, and C accepts the request of 3, then no proposer can obtain a majority vote. The system must wait until the timeout expires, the acceptors discard their states, and the proposers try again. However, this situation is very likely to be blocked again.
### Solution
The solution proposed in the paper is to follow the Paxos pattern and introduce the prepare and propose phases, thereby completely avoiding this blocking. PaxosLease solves the above problems in the following ways:
1. **Not depending on clock synchronization**: Unlike previous Paxos - based lease algorithms (such as Fatlease), PaxosLease does not make time - synchronization assumptions about the local clocks of nodes, nor does it require global synchronization.
2. **Simplifying the algorithm**: Fatlease processes lease commands by continuously running multiple Paxos rounds, while PaxosLease takes advantage of the time nature of leases, avoids this complexity, and makes the algorithm more concise and elegant.
3. **Ensuring lease invariance**: PaxosLease ensures that at most only one proposer holds the lease at any given time.
### Algorithm Flow
1. **The proposer initiates a prepare request**: The proposer generates a ballot number and sends a prepare request to a majority of acceptors.
2. **The acceptor processes the prepare request**: The acceptor checks whether the received ballot number is higher than the highest ballot number recorded locally. If so, the acceptor constructs a prepare response containing the currently accepted proposals and sets its highest ballot number.
3. **The proposer processes the prepare response**: If the responses of a majority of acceptors are empty proposals, the proposer can propose itself as the lease holder and send a propose request.
4. **The acceptor processes the propose request**: The acceptor checks whether the received ballot number is higher than the highest ballot number recorded locally. If so, the acceptor accepts the proposal and sets a timer.
5. **The proposer processes the propose response**: If a majority of acceptors accept the proposal, the proposer holds the lease before the local timer expires.
In this way, PaxosLease ensures the correctness and high availability of leases while avoiding frequent blocking among multiple proposers.