@Karolos Thanks for this interesting discussion.Let me quote some words from
the Book:《Designing Data-Intensive Applications》Martin Kleppmann. If you have
more interested in this topic, have a fun to read the CHAPTER 9:Consistency and
Consensus--->"While this procedure ensures linearizable writes, it doesn’t
guarantee linearizable
reads—if you read from a store that is asynchronously updated from the log, it
may
be stale. (To be precise, the procedure described here provides sequential
consistency
[47, 64], sometimes also known as timeline consistency [65, 66], a slightly
weaker
guarantee than linearizability.) To make reads linearizable, there are a few
options:
You can sequence reads
through the log by appending a message, reading the log,
and performing the actual read when the message is delivered back to you. The
message’s position in the log thus defines the point in time at which the read
happens. (Quorum reads in etcd work somewhat like this [16].)
If the log allows you
to fetch the position of the latest log message in a linearizable way, you can
query that position, wait for all entries up to that position to be
delivered to you, and then perform the read. (This is the idea behind Zoo‐
Keeper’s sync() operation [15].)
You can make your read
from a replica that is synchronously updated on writes,
and is thus sure to be up to date. (This technique is used in chain replication
[63]; see also “Research on Replication” on page 155.) "
----- Original Message -----
From: Karolos Antoniadis <karo...@gmail.com>
To: dev@zookeeper.apache.org
Subject: Re: Consistency Guarantees
Date: 2019-08-19 03:14
Hi Jordan,
When Aphyr tested ZooKeeper, he did not seem to know that it is not
linearizable. See here: https://github.com/jepsen-io/jepsen/issues/399, where
I pointed-out that even with *sync + read*, ZooKeeper might return stale
data.
ZooKeeper can only be considered linearizable if we assume that specific
timing constraints apply. Naturally, in a real system, we cannot make such
assumptions if we want to be 100% safe.
For instance, if the time(TCP timeout) > (syncLimit * tickTime), ZooKeeper
provides linearizable reads. However, if this does not hold (e..g, skewed
clocks), then ZooKeeper might return stale data.
To conclude, I do not think we can argue that ZooKeeper is linearizable.
Cheers,
Karolos
On Sun, 18 Aug 2019 at 11:34, Jordan Zimmerman <jor...@jordanzimmerman.com>
wrote:
> ZooKeeper _is_ linearizable. I’m pretty sure the ZAB paper talks about it.
> Aphyr does as well here: https://aphyr.com/posts/291-jepsen-zookeeper
>
> ====================
> Jordan Zimmerman
>
> > On Aug 18, 2019, at 1:23 PM, Karolos Antoniadis <karo...@gmail.com>
> wrote:
> >
> > Hello everyone,
> >
> > I was wondering on the exact consistency guarantees that ZooKeeper
> provides.
> > It seems that ZooKeeper does not provide strong consistency (i.e.,
> > linearizability) since reads could potentially return arbitrarily old
> > values.
> > On the other hand, ZooKeeper provides sequential consistency, since the
> > order of operations of a specific client is respected and all operations
> > appear to take place in some total order (
> > https://jepsen.io/consistency/models/sequential).
> > However, ZooKeeper provides linearizable writes, and therefore it
> provides
> > something stronger than sequential consistency, but still not as strong
> as
> > linearizability. In other words, ZooKeeper guarantees are somewhere
> between
> > sequential consistency and linearizability.
> > Is there a specific name for the specific consistency guarantees that
> > ZooKeeper provides?
> > What would the ZooKeeper community claim about the consistency guarantees
> > of ZooKeeper?
> >
> > Best Regards,
> > Karolos
>
