ZooKeeper does not provide strong consistency, primarily to achieve high performance and higher availability.

While all writes must go through the current leader, the dissemination lag might mean that different clients can read stale or different values at some point. The state eventually becomes consistent if new writes are not pending.

Clients that need stronger consistency might do reads only at the leader. However, if many clients start doing so, it will impact the performance for everyone.

Clients can use the sync() method to enforce updates until a point in time. Calling the sync() method synchronizes all the write operations on all the servers.

If all replicas of ZooKeeper are physically nearby, e.g, in one data center where latency between any two nodes is ~ $1\ ms$ or less, clients might not see many consistency discrepancies. However, if some replicas are far away, e.g., in a different data center on the other coast, latency will be higher and consistency issues will be more visible.

Prologue

File Systems

Google File System (GFS)

Google Colossus File System

Facebook's Tectonic File System

Databases

Google Bigtable

Google Megastore

Google Spanner

Key-value Stores

Many-core Key-value Store

Scaling Memcache

SILT

Amazon DynamoDB

Concurrency Management

Two-phase Locking (2PL)

Google Chubby Locking Service

ZooKeeper

Big Data Processing: Batch to Stream Processing

MapReduce

Spark

Kafka

Consensus

Understanding Consensus: Two Generals, FLP, & Byzantine Generals

Two-phase Commit

State Machine Replication

Paxos

Raft

Epilogue

Quiz on ZooKeeper

1 of 7