CAP Theory in Action: Choosing Consistency or Availability for Your Database

First, let's clarify the principles behind relational and non‑relational databases.

RDBMS (MySQL, Oracle, SQL Server, etc.) follows the ACID principles: Atomicity, Consistency, Isolation, and Durability.

NoSQL databases (Redis, MongoDB, etc.) adhere to the CAP principles: Consistency, Availability, and Partition tolerance.

In distributed systems, the well‑known CAP theorem states that a system can guarantee at most two of the three properties: consistency, availability, and partition tolerance.

Thus, a distributed storage system can implement only two of these guarantees. Because network latency and packet loss are inevitable, partition tolerance (P) must be ensured, leaving a trade‑off between consistency (C) and availability (A). NoSQL databases therefore provide either AP or CP configurations.

When handling massive traffic spikes such as the Double‑11 shopping festival, which side of the trade‑off should you choose?

My view is to prioritize availability (AP) during the peak, ensuring the service remains up, and then reconcile data for consistency after the event.

Eureka and Zookeeper are concrete implementations of the CAP theorem: Eureka emphasizes AP, while Zookeeper emphasizes CP.

Zookeeper is designed as a distributed coordination service that guarantees data (configuration and state) consistency across multiple nodes, embodying the CP characteristic; its core algorithm Zab ensures synchronized data in a distributed environment. Eureka was created to address Zookeeper's limitations by first ensuring availability.

Source: https://blog.csdn.net/java_xth/article/details/82621776