[ 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)