The ability to tune consistency levels per query is a powerful feature of Cassandra because it gives the developer complete control of managing the trade-off of availability versus consistency. This means that Cassandra queries can be configured to exhibit strongly consistent behavior (but there is no row-level locking) if the developer is willing to sacrifice latency.
The consistency levels offered by Cassandra, which have different meanings for reads and writes, are detailed in the tables below.
|ZERO||Ensure nothing. A write happens asynchronously in background. Using this carries the risk of exhausting the messaging service queue.|
|ANY||A write must have been written to at least one node (can include hinted handoff recipients)|
|ONE||A write has been written to at least 1 replica’s commit log and memory table before responding to the client.|
|QUORUM||Ensure that the write has been written to N / 2 + 1 replicas before responding to the client.|
|DCQUORUM||Similar to QUORUM but uses RackAwareStrategy|
|ALL||All replicas must have received the write otherwise the operation will fail.|
|ONE||Returns the response from the first replica causing a consistency check in a background thread. This check ensures that subsequent calls will eventually have correct data even if the initial read gets an older value.|
|QUORUM||Returns the record with the most recent timestamp once a majority of replicas (N / 2 + 1) has reported. Similarly to ONE, remaining replicas will be checked in the background.|
|DCQUORUM||Keeps the reads within a data center via RackAwareStrategy to avoid the latency of inter-data center communication.|
|ALL||Return the record with the most recent timestamp once all replicas have replied, failing the operation if any replicas are unresponsive.|