You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "shenxingwuying (Jira)" <ji...@apache.org> on 2022/07/20 04:03:00 UTC

[jira] [Created] (KUDU-3382) About strong consistency read

shenxingwuying created KUDU-3382:
------------------------------------

             Summary: About strong consistency read
                 Key: KUDU-3382
                 URL: https://issues.apache.org/jira/browse/KUDU-3382
             Project: Kudu
          Issue Type: Improvement
            Reporter: shenxingwuying


h1. Background && Motivation

Java client has supported two replica selective strategies:

 

{{public enum ReplicaSelection {  LEADER_ONLY,
  CLOSEST_REPLICA
}}}

LEADER_ONLY can provide a strong consistency read.

Closest replica can reduce brandwidth cost and speed scan but the data may be not the latest. Some users may want to both advantages.
h1. Problem Analysis
h2. linearizability read

If kudu need linearizability read, read leader is not enough, because double leader may be exist at a very small period time. During that time, it's not liearizability read. So kudu should avoid double leader at any time, pay the corresponding cost is no leader at a small time. Kudu should make a choice. For user usally need linearizability, so I think kudu should support it. During a very small time no leader's unavailability can avoid by client's fault tolerance.

 

{{The problem can talk about at another issue, that's a sub problem.}}

{{At this I view it no problem by read leader.}}
h2. 
h1. Solution

At Raft, there is a scheme for the scene.

Kudu's raft implements is a strong leader, leader's state machine is not older than followers, and only timeout/ leader transfer can switch leader. About this, someone can make sure it or I can do a experiment to prove it.

Suppose kudu read leader is linearizability, we can trust the leader's result.
 # Read Log, read request is also duriable to wal by raft. The method can solve the problem but it's performance (read and write) is worse.
 # Read Index. If leader, scan directly. If follower, follower should request to leader to get last_committed_opid then wait local replica's apply opid(committed_opid) >= the opid.

At follower, I want to use Read Index.
h1. My conclusions

Kudu can support read followers and keep strong consistency(linearizability).

 

I will create another issue to talk about linearizability read from leader.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)