Understanding Distributed Consistency: CAP, BASE, 2PC, 3PC, Paxos, Raft, ZAB, and NWR Model

Background

In typical distributed systems, machine crashes or network anomalies (delays, loss, duplication, reordering, partitions) occur frequently.

Consistency algorithms aim to quickly and correctly achieve agreement on data values across a cluster despite these failures.

CAP Theorem

The CAP theorem states that a distributed system cannot simultaneously guarantee Consistency, Availability, and Partition tolerance; at most two can be satisfied.

BASE Theory

BASE stands for Basically Available, Soft state, and Eventually consistent, describing a practical compromise derived from CAP for large‑scale internet systems.

Soft state allows intermediate data states without affecting overall availability, tolerating delayed replicas.

Two‑Phase Commit (2PC)

Phase 1

The coordinator asks all participants if they are ready to commit; participants log undo/redo information and respond Yes or No.

Phase 2

If all participants responded Yes, the coordinator sends a commit request; otherwise it sends a rollback request. Participants execute the corresponding action and acknowledge.

2PC suffers from synchronous blocking, single‑point coordinator failure, and potential data inconsistency.

Three‑Phase Commit (3PC)

3PC improves on 2PC by adding timeout mechanisms and an extra preparation phase, resulting in CanCommit, PreCommit, and DoCommit stages.

CanCommit

Coordinator sends CanCommit requests; participants reply Yes if they can commit.

PreCommit

If all replies are Yes, the coordinator sends PreCommit requests, participants execute the transaction and log undo/redo, then acknowledge.

DoCommit

The coordinator sends DoCommit requests; participants finalize the commit or abort based on earlier responses.

Paxos Algorithm

Paxos is a fundamental consensus algorithm based on two‑phase commit, involving proposers, acceptors, and learners.

It guarantees that once a value is chosen, all subsequent chosen values are identical, ensuring eventual consistency.

Raft Consensus Algorithm

Raft simplifies Paxos by using a single leader to manage log replication.

Roles: leader, candidate, follower. The algorithm includes leader election and log replication, handling normal operation, network partitions, and leader failures.

ZAB Protocol

Zookeeper Atomic Broadcast (ZAB) provides crash recovery and atomic broadcast for Zookeeper.

It uses a leader‑follower model, quorum‑based acknowledgments, and a zxid (transaction ID) to order operations.

Key steps: client writes to leader, leader assigns zxid, broadcasts proposals, followers ack, leader commits after quorum, and followers apply commits.

NWR Model (Amazon Dynamo)

The NWR model lets users configure N (replicas), W (writes required), and R (reads required) with the constraint W+R > N to balance consistency, availability, and partition tolerance.

Versioning via vector clocks resolves write conflicts, delegating conflict resolution to the application.

Conclusion

The article provides a comprehensive overview of consistency protocols and their trade‑offs, helping readers understand how distributed systems achieve reliability and consistency.

For further reading, see the author's other columns Mybatis 进阶 and Spring Boot 进阶 .