为何MongoDB一致但不可用、Cassandra可用但不一致？

MongoDB #

1. Availability, Consistency During Primary Election, and Related Behaviors #

You nailed the core CAP tradeoff here: MongoDB's single-primary replica set does sacrifice availability (A) to maintain consistency (C) when the primary fails. During the 10-40 second election window, the cluster can't process write requests—there's no active primary to accept them, so no new data is being written, keeping the existing data consistent.

For reads during election: It depends on your read preference configuration. If you allow reads from secondary nodes, those nodes will still respond normally with the latest data they have (consistent up to the last replication from the old primary). If you force all reads to the primary, reads will fail until the new primary is elected. Most production setups enable secondary reads to keep read availability intact during failover.

As for writes after a new primary is elected: Yes, your application will need to retry failed writes. Any write attempts during election will throw errors like PrimaryNotFound, and you'll want to handle these with retry logic—many MongoDB drivers have built-in features for this scenario.

2. Why MongoDB is Labeled "Highly Consistent" & the Purpose of Secondary Nodes #

The key here is MongoDB's default behavior: out of the box, all reads and writes go to the primary. This guarantees strong consistency (consistent) because every read gets the latest committed data, and every write is confirmed by the single source of truth before returning to the client.

Secondary nodes aren't just redundant—they serve critical roles:

• Failover Candidates: They're the pool the cluster draws from to elect a new primary if the current one fails.
• Read Scaling: Offload read traffic from the primary to handle high-volume read workloads (you can configure read preferences to route some or all reads to secondaries).
• Offline Operations: Run backups, analytics, or reporting tasks on secondaries without impacting the primary's performance.

When you enable secondary reads, MongoDB shifts to eventual consistency—since replication from primary to secondary takes time, a secondary might return stale data until it catches up.

As for your Cassandra comparison: Cassandra's default configuration prioritizes availability and partition tolerance over strong consistency. To get strong consistency in Cassandra, you have to explicitly set higher consistency levels (like QUORUM), whereas MongoDB gives you strong consistency by default. That's a fundamental difference in their design priorities.

Cassandra #

Why Cassandra is Highly Available but Not Strongly Consistent #

Cassandra's multi-primary model delivers 100% write availability because any node can accept writes, and a single node failure doesn't stop the cluster. But this high availability comes at the cost of strong consistency for two main reasons:

• Eventual Consistency by Default: Cassandra replicates writes to multiple nodes (default 3), but only requires confirmation from a subset (default 1) to return success. This means some replicas might not have the latest data yet. If you read from an unsynced replica, you'll get stale data until replication completes.
• Partition Tolerance & Decentralized Writes: Cassandra is built to handle network partitions seamlessly—if the cluster splits into separate groups, each group can still process reads and writes independently. However, this leads to temporary inconsistencies between partitions until the cluster reconnects and syncs data via repair processes. Since there's no single primary, multiple nodes can accept writes for the same data, and conflicts are resolved later using timestamps—this can create short-term inconsistencies.

内容的提问来源于stack exchange，提问作者user3198603