Why Zookeeper Is Losing Favor: Consistency vs. Availability Trade‑offs

Zookeeper is an open‑source distributed coordination service, essentially an implementation of Google’s Chubby, providing strong consistency for distributed applications. It is commonly used as a registration center and a configuration center.

1. Understanding Zookeeper

Typical functions include:

In familiar middleware, Dubbo uses Zookeeper as a registry, early versions of Kafka use it as a configuration center, and RocketMQ also relies on it.

2. Reasons Zookeeper Is Losing Favor

(1) CP Mechanism

Zookeeper prioritizes strong consistency (CP), meaning if the leader and followers diverge, the whole service becomes unavailable. In scenarios like service discovery, occasional stale data is acceptable, so sacrificing availability is not ideal.

(2) Synchronous Master‑Slave Data Blocking

During replication, the leader sends a sync request to followers, which must respond; network latency and the CP nature cause performance bottlenecks under high concurrency.

(3) State‑Change Logging

Zookeeper records persistent logs for every state change to ensure reliability. For use‑cases like service discovery, this extra logging incurs unnecessary performance overhead.

(4) Health‑Check Mechanism

The health check is tied to Zookeeper’s session (TCP keep‑alive) and does not verify actual service availability, so it provides little practical value for business services.

As internet technologies evolve, these mechanisms become less suitable for some scenarios, prompting many large companies to seek alternatives. However, Zookeeper remains valuable for use‑cases such as publish/subscribe, leader election, and distributed locks.

Summary

Zookeeper offers strong consistency, but some scenarios prioritize availability.

Master‑slave synchronous replication can cause performance issues under high load.

Logging of state changes adds overhead when not needed.

Its health checks do not assess service usability.