2/4 for write and 2/4 for read would not be sufficient to achieve strong consistency, as there is no overlap.
In your particular case you could potentially use QUORUM for write and TWO for read (or vice-versa) and still achieve strong consistency. If you add additional nodes in the future this would obviously no longer work. Also the benefit of this is dubious, since 3/4 nodes still need to be accessible to perform writes. I'd also guess that it's unlikely to provide any significant performance increase. Justin On Fri, 9 Jun 2017 at 12:29 Dikang Gu <dikan...@gmail.com> wrote: > Hello there, > > We have some use cases are doing consistent read/write requests, and we > have 4 replicas in that cluster, according to our setup. > > What's interesting to me is that, for both read and write quorum requests, > they are blocked for 4/2+1 = 3 replicas, so we are accessing 3 (for write) > + 3 (for reads) = 6 replicas in quorum requests, which is 2 replicas more > than 4. > > I think it's not necessary to have 2 overlap nodes in even replication > factor case. > > I suggest to change the `quorumFor(keyspace)` code, separate the case for > read and write requests, so that we can reduce one replica request in read > path. > > Any concerns? > > Thanks! > > > -- > Dikang > > -- *Justin Cameron*Senior Software Engineer <https://www.instaclustr.com/> This email has been sent on behalf of Instaclustr Pty. Limited (Australia) and Instaclustr Inc (USA). This email and any attachments may contain confidential and legally privileged information. If you are not the intended recipient, do not copy or disclose its content, but please reply to this email immediately and highlight the error to the sender and then immediately delete the message.
