[
https://issues.apache.org/jira/browse/KUDU-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shenxingwuying updated KUDU-3382:
---------------------------------
Description:
h1. Background && Motivation
Java client has supported two replica selective strategies:
{code:java}
public enum ReplicaSelection {
LEADER_ONLY,
CLOSEST_REPLICA
} {code}
LEADER_ONLY can provide a strong consistency read.
Closest replica can reduce brandwidth cost and speeding up scan, corresponding
to the data may be not the latest. Some users may want to both advantages.
h1. Solution
We can achieve the aim by read follower, reach the effect as read leader.
At Raft, there is serveral schemes for this. For examples:
# 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, so we abandon it.
# 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 reach
the opid, of course the wait time should be a limited time.
At followers, Read Index is better. More details can be talk.
Another issue will talk about read leaders to achieve the linearizability read.
was:
The next 3 days, I'll fix the idea of the issue.
h1.
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 strong consistency read(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.
> About strong consistency read from followers
> ---------------------------------------------
>
> Key: KUDU-3382
> URL: https://issues.apache.org/jira/browse/KUDU-3382
> Project: Kudu
> Issue Type: Improvement
> Reporter: shenxingwuying
> Assignee: shenxingwuying
> Priority: Major
>
> h1. Background && Motivation
> Java client has supported two replica selective strategies:
> {code:java}
> public enum ReplicaSelection {
> LEADER_ONLY,
> CLOSEST_REPLICA
> } {code}
> LEADER_ONLY can provide a strong consistency read.
> Closest replica can reduce brandwidth cost and speeding up scan,
> corresponding to the data may be not the latest. Some users may want to both
> advantages.
> h1. Solution
> We can achieve the aim by read follower, reach the effect as read leader.
> At Raft, there is serveral schemes for this. For examples:
> # 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, so we
> abandon it.
> # 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
> reach the opid, of course the wait time should be a limited time.
> At followers, Read Index is better. More details can be talk.
> Another issue will talk about read leaders to achieve the linearizability
> read.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
