cassandra 读写Consistency level

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. A “quorum” of replicas is essentially a majority of replicas, or RF / 2 + 1 with any resulting fractions rounded down.

Write Consistency

 

Level

Description

ANY

Ensure that the write has been written to at least one node (can include hinted handoff recipients). Note that if all replica nodes are down at write time, an ANY write may not be readable until nodes have recovered.

ONE

Ensure that the write has been written to at least one replica’s commit log and memory table before responding to the client.

QUORUM

Ensure that the write has been written to a quorum of replicas before responding to the client.

LOCAL_QUORUM

Ensure that the write has been written to a quorum of replicas in the datacenter local to the coordinator before responding to the client. This setting avoids the latency of inter-data center communication.

EACH_QUORUM

Ensure that the write has been written to a quorum of replicas in each datacenter in the cluster before responding to the client.

ALL

All replicas must have received the write; otherwise the operation will fail.

 

Read Consistency

 

Level

Description

ONE

Returns the response from the closest replica, as determined by the snitch configured for the cluster. When read repair is enabled, Cassandra may perform a consistency check in a background thread.

QUORUM

Returns the record with the most recent timestamp once a quorum of replicas has reported.

LOCAL_QUORUM

Returns the record with the most recent timestamp once a quorum of replicas in the datacenter local to the coordinator has reported. This setting avoids the latency of inter-data center communication.

EACH_QUORUM

Returns the record with the most recent timestamp once a quorum of replicas in each datacenter in the cluster has reported.

ALL

Return the record with the most recent timestamp once all replicas have replied, failing the operation if any replicas are unresponsive.

 

Note

LOCAL_QUORUM and EACH_QUORUM are designed for use in clusters with rack-aware replica placement strategies such as NetworkTopologyStrategy. Used with SimpleStrategy, these consistency levels may lead to unpredictable results.

Choosing Consistency Levels

In choosing the consistency level for particular operations, developers should consider the relative importance of consistency, latency, and availability.

For instance, in a case where availability is top priority it may make sense to choose a level of ONE over QUORUM. If the replication factor for the cluster is 3, a QUORUM operation tolerates the loss of only one node (or, one copy of the data) while ONE allows the operation to complete even if two nodes are unavailable.

In cases where data consistency is top priority, you can ensure that reads always reflect the most recent write by using the following formula: W + R > RF, where W is the number of nodes to block for on write, and R the number to block for on reads. For example, at RF 3, QUORUM operations block for 2 nodes on both read and write, resulting in strong consistency.

Clusters spanning multiple data centers may present further questions regarding local latency and durability. For a examples of consistency level settings used in such scenarios, see Multiple Data Centers.

Note

For specialized cases where the replication factor is higher than three, Cassandra provides consistency levels of TWO and THREE for both read and write operations. These levels are considered experimental, and may be replaced in a future release by custom pluggable consistency levels.