[jira] [Commented] (KUDU-3383) About strong consistency read from leader

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

    [ https://issues.apache.org/jira/browse/KUDU-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17575701#comment-17575701 ] 

shenxingwuying commented on KUDU-3383:
--------------------------------------

Thanks you replay. I'll study yugabyte-db' approach.

> About strong consistency read from leader
> -----------------------------------------
>
>                 Key: KUDU-3383
>                 URL: https://issues.apache.org/jira/browse/KUDU-3383
>             Project: Kudu
>          Issue Type: Improvement
>            Reporter: shenxingwuying
>            Assignee: shenxingwuying
>            Priority: Major
>         Attachments: image-2022-07-20-23-14-34-519.png, image-2022-07-20-23-17-40-718.png
>
>
> As describe as https://issues.apache.org/jira/browse/KUDU-3382.
> I am talking about linearizability read.
> h1. Background && Motivation
> Linearizability read is a very friendly feature for developers, kudu can support it. Now I find kudu may be implements yet.
> h1. Issue of linearizability read from leader
> We need talk about the issue.
> The feture is especially important for kv system, and kudu is mainly olap oriented. But in some scenaios, the feature also privide advantages.
> Kudu's read implements by Scan, event though read one row. It send a ScanRequest with NewScanRequest and then send ContinueScanRequest. The feature will be aimed at NewScanRequest.
> Kudu's raft implements is a strong leader, leader's state machine is not older than followers, and followers heartbeat timeout or receives leader election request(leader transfer) can elect leader and switch leader.
> If kudu need linearizability read, read leader is not enough, because double leader may be exist at a very small period time.
> I provide two scenarios. The first one:
>  
> !image-2022-07-20-23-17-40-718.png!
>  
>  # A raft group has 3 replicas, L1, F2, F3. Their states is steady during term 1.
>  # If network parition, F2 and F3 loss leader's heartbeat, F3 start election, F2 vote it.
>  # F3 become Leader, we can call it L3. At this moment, there are 2 leaders: L1(1) and L3(2).
>  # The state will be continued until the network partition recover. The time may be short or long.
> During double leader, it's not liearizability read. So kudu should avoid double leader at any time, pay the corresponding cost is no leader at a small period 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.
> Whether read leader is linearizability read, someone can make sure it or I can do a experiment.
> kudu should avoid double leaders at a very small period time and network fault happens . I review the codes, and think now the problem is exist.
> h1. Solution
> To avoid the double leader's trouble，leader should be keep alive. If a leader receives no enough heartbeats in a period of time, it shoud be leader down and and then start another election just like follower does. Leader's timeout should be less than follower's election.
> Another scheme: Read should send heartbeat to two follow to make sure it is valid leader.



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