Hi Boyang, Thanks for raising this up. I have a few thoughts about the "Non-leader Linearizable Read", and I think there are two goals we can consider achieving here from a user's perspective:
1) that each of your queries on the raft log is always going to return the latest committed result. 2) that your consecutive queries would not "go back". And as we can see 1) is a stronger guarantee than 2), meaning that achieving 1) would always guarantee 2) as well. In your football example, in order for Alice and Bob to agree on each other, we would have to achieve 1) above; but practically it may be okay for Alice and Bob to see different results temporarily. However, for a single user like Alice, it is usually required that if she issued the query twice, and the first returns "final result 1:0", the second should not return "no final result yet". And to achieve this only 2) is needed. And it is easier to achieve 2) without the proposed new request/resp, for example, we can let the client associate its query with an offset which it got from the previous query result, and require whoever is answering that query to have applied the state machine at least up to that offset. If we consider in Kafka's case, I feel that in most scenarios just achieving 2) is good enough, e.g. for querying metadata. Today many of the error cases actually come from the fact that if you query two different brokers, your results may actually "go back in time". So I'd like to play devil's advocate here and ask us if achieving a stronger semantics is indeed needed in Kafka. Guozhang On Wed, Dec 2, 2020 at 10:17 AM Boyang Chen <reluctanthero...@gmail.com> wrote: > Hey there, > > I would like to start a discussion thread for a KIP to improve on our > existing Kafka Raft semantics, specifically adding pre-vote and > linearizable read: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-650%3A+Enhance+Kafkaesque+Raft+semantics > > Let me know what you think, thank you! > -- -- Guozhang
