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

["shenxingwuying (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KUDU-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

shenxingwuying reassigned KUDU-3382:
------------------------------------

    Assignee: shenxingwuying

> About strong consistency read
> -----------------------------
>
>                 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:
>  
> {{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.



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