Cassandra中数据一致性指的是数据行在各个复制节点（replicas）上的更新和同步程度。通过提供tunable consistency，Cassandra扩展了eventual consistency的概念。针对任何读或写操作，客户端根据对反应时间和数据准确性的要求来决定数据的一致性程度(Per-Request Consistency)。
除了tunable consistency，Cassandra也提供若干built-in repair mechanisms以确保数据在各replicas上保持一致。
CAP定理(THEOREM)
• Consistency：所有节点在同一时间看到的是同样的数据
• Availability：确保每个请求收到成功还是失败的回应
• Partition Tolerance：系统无视偶然的消息丢失持续运行
在分布式存储系统中，同时满足所有的特性是不可能的，最多能达到3个中的两个。Cassandra允许用户来决定每个请求的CAP特性，在一致性、性能和错误容忍度之间做出选择。
写操作一致性ABOUT WRITE CONSISTENCY）
写操作一致性决定了在向客户端确认写操作成功之前，多少个节点必须被成功写入（Commitlog and Memtable）。
假设：R=Nodes Read, W=Node Written, N=Replication Factor，Q=QUORUM=N/2+1。
ANY： 至少成功写入一个节点，即使是一个Hinted Handoff
ONE： 至少成功写入一个复制节点（replica node）
QUORUM： 至少成功写入Q个复制节点（Q=N/2+1）
LOCAL_QUORUM： 至少在coordinator node所在的当前DC成功写入Q个复制节点
EACH_QUORUM： 在每个DC成功写入Q个复制节点
ALL： 成功写入集群中的每个复制节点
ANY提供了绝对的write availability，但是是以牺牲一致性为代价（具有最差的一致性），因为不能保证被写入的数据什么时候才可读（取决于replicas当机了多长时间）。ANY只能用于写操作。写操作被发送到任何一个节点，随后通过hinted handoff机制被重送到目的节点。ANY适用于不想丢失写操作、不关心数据一致性和发送延迟的数据程序。
ALL具有最强的一致性，但最低的availability。
QUORUM是一种折中，具有强的一致性，但同时也容许一定程度的失败。例如，如果replication_factor是3，Quorum就是2（允许在一个replica上失败）。如果replication_factor是6，Quorum就是4（允许在二个replicas上失败）。
不同于正常的Column，对Counter的写操作需要在后台做一次读操作以确保分布式的Counter值在各个replicas上保持一致。如果使用的是Consistency level = ONE的写操作，则隐含的读操作不会对写操作造成延迟。因此，Counter通常使用consistency level是ONE.
读操作一致性（ABOUT READ CONSISTENCY）
读操作一致性程度决定了在将结果返回到客户端之前，多少个replicas必须返回结果。
假设：假设：R=Nodes Read, W=Node Written, N=Replication Factor，Q=QUORUM=N/2+1。
ONE： 从最近的复制节点返回结果（由snitch决定）。默认情况下Read Repair会在后台运行使其他节点保持一致。
QUORUM： 在Q（（Q=N/2+1））个复制节点返回数据后，返回具有最新时间戳的记录给客户端
LOCAL_QUORUM： 在coordinator node所在的当前DC的Q个复制节点返回数据后，返回具有最新时间戳的记录给客户端
EACH_QUORUM： 在每个DC返回Q个复制节点的数据后，返回具有最新时间戳的记录给客户端
ALL： 在集群中的每个复制节点返回数据后，返回具有最新时间戳的记录给客户端。任何一个节点失败都会导致读操作失败