As I understand, Zookeeper enforces "sequential consistency" which states any execution is the same as if all read/write ops were executed in some global ordering. Basically, a client may see stale data but it's guaranteed to see values in the order of the writes which are linearized.
I have two confusions
1. How is the ordering guarantee from sequential consistency preserved when a node goes down? For example, what happens in a following scenario?
- Write x=1
- Write x=2
- Node A has the most recent value x=2, Node B is still on old value x=1
- A client reads x=2 from Node A
- Node A goes down.
- A client is now connected to Node B.
- A client now reads x=1 from Node B.
Doesn't this break the ordering guarantee provided by the sequential consistency?
2. Am I correct in saying that all eventual consistency model provides an ordering guarantee as long as a client is always reading from the same node?
Is the lack of ordering guarantee in eventual consistency due to the fact that a client can read from any node and is not tied to a specific node when reading a value?
(Wouldn't systems that implement sequential consistency suffer from the same issue though in a scenario where a node goes down and a client is forced to read from a client with a stale data? Kinda goes back to my question #1)
Any clarification would be greatly appreciated. Thank you.
1条答案
按热度按时间c6ubokkw1#
What you are seeing is sequential consistency. That's it, no restrictions on the nodes going down/up or connecting to the same node. The question is, how we make sure the client handles the situation without reaching a wrong conclusion. Here is how:
Only with sequential consistency, the client can ignore redeliveries and avoid processing duplicate events. So the client avoids going back and forth in time.