Introduction to the lease mechanism

Background and introduction

caching is a widely used technology in computers, which is very effective for reducing read latency, network traffic, and server load, but it also brings consistency (consistency) problems. The so-called consistent is that the client can always read the latest data , the use of the cache may have the server side of the data has been modified, but the client still read stale data from the cache. To ensure consistency, there are two common solutions, the first of which is polling (Polling), which is to ask the server whether the data is up-to-date each time it is read, and if it is not to transfer new data from the server, this method needs to communicate with the server every time the data is read. Another approach is to call back (Callback) or invalidate (invalidation), that is, the server remembers which clients read the data, make changes to the data first notify all of these client data has been invalidated, The problem with this approach is that the server needs to remember all the clients that have read the data, which is a big burden, and more seriously, once the client is not contacted or the client's information is lost, the modification cannot continue.

Cary G. Gray and David R. Cheriton of Stanford University in 1989 proposed the use LeasesMethods to maintain cache consistency. The so-called lease, is actually a contract, that is, the server gives the client A certain periodInside can Controlling modification Operationsof power. If the server wants to modify the data, it must first solicit the consent of the client that owns the lease for the data before it can be modified. When the client reads the data from the server, it often acquires the lease, and during the lease period, if the server's modification request is not received, the contents of the current cache are guaranteed to be up to date. If you receive a request to modify data within the lease term and agree, you need to clear the cache. After the lease expires, the client must re-obtain the lease if it also reads the data from the cache, which we call the operation " Renewal”。

During the lease term, the client can guarantee that the data in its cache is up-to-date. At the same time, leases can tolerate various non-Byzantine failures (machine crashes, network segmentation, etc.). If the client crashes or the network is interrupted, the server can modify it only by waiting for its lease to expire. If a server error has lost all of the client's information, it only needs to know the maximum duration of the lease and can safely modify the data after that period. The server simply remembers the client that also owns the lease, compared to the callback method.

A lease is very similar to a lock with a period of time, but more flexible because the lease also provides a "seek consent" mechanism (which I think can be referred to as "a lock with a term compromise"). The server can also implement a variety of leases, such as "Write a lease" and "read a lease", and guarantee that there is only one write lease or multiple read lease in a time period, which is equivalent to the single writer multi-reader lock protocol. Because leases are time-based, their effectiveness requires system time to be guaranteed. If the server's clock is fast and the client clock is slow, it is possible that the server thinks that a lease has expired and the client still considers it to be valid, which can result in an error. This is a situation that must be resolved through a clock synchronization protocol, but this is rare. In general, we can assume that the time of a distributed system is synchronized within a very small difference in E, just take this e for the duration of the lease. Lease Properties and Management

There are many options for the properties and management of leases, and the first consideration is the length of the lease term.

In general, a shorter lease term should be chosen. A short lease has three advantages over a long lease. First, in the case of failure, the modification operation often waits for the lease to expire, so a short lease means a shorter Failure Delay。 Second, even if a client no longer needs to read the data, but before its lease expires, any modification operation still needs to ask for its consent, which is called " Fake Share"Obviously, the longer the lease term, the more serious the problem is." Finally, short leases also allow fewer client information to be maintained by the server. Short leases, however, also mean larger Renewal costs, long leases can be more efficient for data that is rarely modified while being read repeatedly. Therefore, the choice of the lease period to weigh the failure delay, false sharing costs and renewal costs, and other factors, the server can be based on the data access characteristics and the nature of the client flexibility to set deadlines. In fact, if we set the lease term to zero, it would be quite a poll, at which time the modification operation could be made, and the data would always be contacted by the server. If the lease term is set to an infinite length, it is equivalent to a callback. In addition to the term selection, there are many management options. For clients, it is possible to choose whether to renew, renew and agree to modify. For example, to reduce the read latency, the client can renew the lease before it expires, but this can add to the burden on the server. For the server, you can choose whether to issue leases, lease coverage granularity, and how to modify them. For example, after receiving a modification request, the server can simply wait for all leases to expire without asking for consent from the client (no new leases are released to avoid an indefinite delay). For installation Files", that is, modify very few files (such as header files, library files), the server can use a lease to overwrite a batch of files, while periodically broadcast renewal notification to save overhead, if you need to modify the data, stop the broadcast and wait for the lease expires. On the consistency of the Internet

In the Internet environment, the consistency problem is more complex, because the network latency is much larger than the LAN, the client invalidation and the network segmentation are very common. Therefore, in many cases, we only guarantee the weak consistency of the cache, that is, there is no guarantee that the client can always read the latest data, just try to ensure that the data they read is not very lag. Accordingly, we refer to the consistency used earlier as strong consistency . The most commonly used method of guaranteeing weak consistency is the lifetime (TTL), which specifies the lifetime when the data is read, the client reads the data directly from the cache during the lifetime, and then must communicate with the server to verify the cache validity or get the latest data. Obviously, we can allocate shorter lifetimes to more variable data to minimize the chance of clients reading out-of-date data, while allocating longer lifetimes to less variable data to reduce read latency and server load.

The 1992 Vincent Gate in CMU implemented the variable lifetime (Adaptive TTL)in the Alex Project, which is based on the observation that new data is easier to modify than old data . In Alex, the concept of update threshold (updated threshold) was used to set the lifetime to a percentage of its cache time. Suppose that a data that has just been validated against the server already has 10 headers in the cache with an update threshold of 20%, then its lifetime is 2. Using variable lifetime technology does not reduce network traffic, but can reduce server load compared to normal lifetime technology.

Although the weak consistency model has met the needs of our daily web browsing, there are some applications that require strong consistency. The method of local area network is difficult to extend directly to the Internet environment. The read delay for the polling method is too large. The callback method not only records all the clients, but also makes the server unbearable, and the frequent network segmentation makes the modification operation impossible to continue. Short leases cause network traffic and server load to be too large, and if the lease duration is less than the network latency, there is nothing to do but increase the server load. The long lease also makes the problem of failure delay and false sharing more serious, and the server records a large number of client data. Since there are variable lifetimes, it's natural. variable leases (variable leases)The idea. The Pei Cao and Chengjue Liu of the University of Wisconsin-Madison in 1998 put forward a call for Two-tierScheme is to differentiate between a client that only accidentally reads data and a client that really needs strong consistency, only the latter to issue a lease (a request presented by the client). Further, they analyzed how to adjust the lease properties according to different circumstances, such as increasing the lease duration when data modification was reduced, shortening the lease duration when storage space was insufficient, or even requiring the client to abandon the lease.
Volume leases in a 1999 paper, Jian Yin, of the University of Texas at Austin, presented a system of volume leases guaranteeing strong consistency in the Internet environment. Called Volume Lease (volume leases), as mentioned above for the "installation file" of the lease is a bit similar, that is, a lease will cover multiple related files, the term is short, usually 10 seconds, generally to be renewed before expiration. Volume leases because of the short term, the renewal operation is more frequent, but the user will often read a volume under the multiple files, so this cost spread to multiple files, is still acceptable. If the light is in a volume lease, it can cause a very serious false sharing problem because the clients that own the volume lease may have very different data. The server also provides additional objects lease (object leases)is a general lease that covers only one file, usually longer, and can be hours or even days to obtain a smaller renewal cost. To ensure that the cache is valid, the client must owning both object leases and volume leases。 The modification requires the consent of the client that owns both the volume lease and the object lease, and if the client machine fails or the network is partitioned, it can safely modify the data by waiting for the volume lease to expire.

Once the volume lease expires, the server considers that the corresponding object lease also expires, and when the client re-acquires the volume lease, it checks the validity of the corresponding object lease and empties the cache if the data is not modified. In fact, volume leases and object leases are similar to Heartbeat and callbacks, the former is used primarily to determine the state of the client, which is used to locate clients interested in the data. By combining the two leases, the failure delay and communication overhead can be well balanced. Experimental data show that the same Failure delay Time, the volume lease mechanism can reduce the number of messages by 30% to 40% compared to the normal lease mechanism. It might be strange to think that adding a lease could reduce communication. This is because in order to achieve the same failure delay, the ordinary lease must set the lease term within the delay period (for example, 20 seconds), and if the volume lease is used, only the duration of the volume lease is set to the delay period, and the time of the object lease can be set very long. Because the communication overhead of a volume lease has several object allocations, and the overhead of object leases is very small in fact, the total overhead is less than using only ordinary leases. Other applications for leases above we discussed only how to use leases to maintain cache consistency, in fact, the scope of application of leases is very extensive. A distributed lock is implemented in the Frangipani Distributed File System, in which the client obtains a lease before acquiring the lock, and must renew it before the lease expires. The locks acquired by this client are associated with the lease, and if the lease expires, the lock server automatically releases the locks. The lease here is a guarantee of the validity of the lock, which avoids the overhead of maintaining the duration for each lock by maintaining the client lease. The lease here is equivalent to a heartbeat. In GFs, each file block has multiple copies distributed across multiple chunkserver, and there must be a globally uniform append order when appending in parallel. Of course this order can be determined by master, but this will greatly increase the load on master. Another method can be achieved by multiple chunkserver through a consistency protocol (such as Paxos), but this is too expensive. GFS uses the lease mechanism, which is to issue leases to a chunkserver for each file block, which is responsible for the order of parallel append operations within the lease term. Chunkserver can be renewed in normal operation, if there is a machine failure or network segmentation, Master will give the lease to another chunkserver after the lease expires. In some cases, master will also contact the Chunkserver that owns the lease, and ask them to release the lease in advance.

In many cases, the system already has a central service that guarantees consistency, such as a Single Serveror a a set of servers that implement the Paxos protocol, but if all of the features need to be serviced by this hub, it can easily lead to performance bottlenecks. To improve efficiency and scalability, you can use leases to consistency extends to more servicesOn In fact, using leases to maintain cache consistency is also equivalent to extending the consistency of data on the server to the client.

What exactly is a lease? In many cases, the definition of a lease seems vague, sometimes the lease is like a heartbeat, sometimes it is similar to a lock. What is the nature of the lease?
Back to the original definition of the lease: the lease is within a certain period of timeGiven to the holder Specific PowersThe agreement. I think the term here is the fundamental nature of the lease, which allows the lease to tolerate machine failure and network segmentation. Within the term, the lease is actually a protocol between the server and the client, and the content of this protocol can be varied. If the protocol content is the server confirms that the client also survives, then the function of the lease is the heartbeat, if the protocol content is the server to ensure that the content will not be modified, then this lease is equivalent to read lock, if the protocol content is the server to ensure that content can only be modified by this client, then this lease is equivalent to write lock. The flexibility and fault tolerance of leases make them an effective tool for maintaining the consistency of distributed systems.

Introduction to the lease mechanism