Lease of Distributed system design

basic architecture for distributed Systems
in today's Distributed system architecture, the vast majority of these are master/slave architectures, with very few of them using peer-to architecture. That is, Master manages each slave, including metadata, load, and so on, and master determines which slave nodes the client can access. The
Access general flow is as follows:
1.Client sends a request to master and needs to read the data.
2.Master selects the slave that can be accessed based on information such as metadata, load, and so on. The address information for the slave is then returned to the client.
3.Client accesses the corresponding slave, reads the data
, responds to the client's request, and returns the data to the client based on the information returned by master. Figure below.
from the above schema, all client requests need to go through master before they can access the corresponding slave. So when the client request volume is very large, it can cause the master pressure is very big, may even cause the outage. If the client is able to use the cache, it can greatly reduce the master request and relieve the pressure on the server. But how does the cache guarantee consistency? Next, share the lease mechanism used by Google's chubby.

The basic principle of

leases
Chubby the way the lease is implemented.
1. When master initiates a response to the client, client caches the corresponding slave information on the clients and sets the expiration time, while the client initiates a request to master requesting a lease renewal with a timestamp. The
2.Master maintains a clock for each client. When Master detects that slave can provide access normally, it responds to client requests as soon as it expires. This is when the client receives the request, updates the expiration time, and re-sends the renewal request to master.
3. When Master determines that slave is unreachable or the load is too high to switch, master responds to the client with the new slave address, which is the client that updates the cache and the expiration time, and then repeats step 1 above.
4. If the client does not receive a successful response to master renewal, the cache timeout expires. The client waits for a certain amount of time, such as 1s. If a master response is received during this period, the renewal is considered to be successful and the cache is in effect. Otherwise, the request will be re-requested.
through the above lease, the client can guarantee the consistency of the cache. This allows the client to maximize the use of the local cache without having to request master.