ReadIndex Read and Local Read
Inspect: Determine the type of request and how to handle it. Let’s focus on read requests, which can be handled in two ways:
RequestPolicy::ReadLocal, which is local read, indicates that the Peer is the leader and within the lease, allowing direct data reading.
RequestPolicy::ReadIndex, which is read index, indicates that the Peer is the leader but not within the lease, or the request explicitly requires handling with read index.
self.read_local: Handles the request using local read, directly reading from RocksDB.
self.read_index: Handles the request using read index, querying the majority of nodes to ensure it is the legitimate leader, and then reading from RocksDB after reaching or exceeding the linearizability point (read index).
The inspect method is not complicated; let’s look at it line by line:
req.get_header().get_read_quorum(): The request explicitly requires handling with read index, so it returns ReadIndex.
self.has_applied_to_current_term(): If the leader has not yet applied to its own term, it uses ReadIndex for handling. The reason can be found in TiKV feature introduction - Lease Read.
self.raft_group.raft.in_lease(): If the leader is not within the raft lease, it indicates potential issues such as network instability or unsuccessful heartbeats. It uses ReadIndex for handling.
self.leader_lease.inspect(None): Uses the CPU clock to determine if the leader is within the lease. If it is, it handles using ReadLocal.
In summary, if it is not certain that RocksDB can be read safely, use read index; otherwise, boldly use local read.
|
username: alfred
|
username: 
|
username: 
|
username: 
|
username: