Cassandra的强相合性

时间:2018-01-08 13:03:50

标签: cassandra cassandra-3.0

根据datastax文章,可以保证强大的一致性 如果,R + W> ñ 哪里 R是读操作的一致性级别 W是写操作的一致性级别 N是副本的数量

强一致性意味着什么?这是否意味着“每次”从数据库给出查询的响应,响应将“始终”是最后更新的值?如果在cassandra中保持强一致性的条件,那么,是否存在返回的数据可能不一致的情况?简而言之,强一致性是否意味着100%的一致性?

修改1

在某些情况下添加一些其他材料,即使在R + W> RF

的情况下Cassandra可能不一致
  1. Write fails with Quorum CL
  2. Cassandra's eventual consistency

4 个答案:

答案 0 :(得分:3)

是。如果R + W一致性大于副本,那么您将始终获得一致的数据。 100%一致性。但是你必须交易可用性才能达到更高的一致性。

Cassandra具有可调整一致性的概念(基于查询设置一致性)。

答案 1 :(得分:3)

Cassandra具有可调整的一致性,您可以选择一些权衡。

R + W> N - 这只是意味着您的往返中必须有一个重叠节点,其中实际和最新数据可以保持一致。

例如,如果您在CL.ONE上书写,则需要在CL.ALL上阅读以确保获得一致的结果:N + 1> N - 但您可能不需要CL.ALL,因为您无法容忍群集中的单个节点发生故障。

通常,您可以在读取和写入时选择CL.QUORUM,以确保一致性并容忍节点故障。例如,在RF = 3时,QUORUM需要(3/2)+ 1 = 2个节点可用,因此R + W> N将是4> 3 - 您的请求是一致的并且您可以容忍单个节点故障。

要记住一件事 - 在所有节点(cassandra和应用程序)上同步时钟非常重要,您需要启动并运行ntp。

答案 2 :(得分:2)

对于读取和写入,ANY,ONE,TWO和THREE的一致性级别被认为是弱的,而QUORUM和ALL被认为是强大的。

答案 3 :(得分:-1)

虽然这是一个古老的问题,但我想我会努力保持纪录。

R + W> RF并不表示强一致性

具有** R + W> RF *的系统最终只会保持一致。强一致性保证的主张在节点故障期间或两次写入之间中断。例如,考虑以下情形:

假设有3个节点A,B,C,RF = 3,W = 3,R = 2(因此,R + W = 5> 3 = RF)

进一步假设密钥k与值v相关联,即(k,v)存储在数据库中。假设发生以下一系列操作:

  • t = 1 :(k,v1)写入请求已从用户发送到A,B,C
  • t = 2 :( k,v1)到达A,并写入存储在A中
  • t = 3 :读取器1发送对密钥k的读取请求,由A和B答复
  • t = 4 :阅读器1收到响应(k,v1)-根据最新的写入胜出规则
  • t = 5 :读取器1发送另一个读取请求,该请求由节点B和C服务
  • t = 6 :阅读器1收到的响应(k,v)是一个较旧的值 INCONSISTENCY
  • t = 7 :( k,v1)到达C,并写入存储在C中
  • t = 8 :(k,v1)到达B并写入存储在B处

这表明W + R> RF无法保证强一致性。为了确保强一致性,您可能希望使用其他算法,例如 paxos raft ,可以帮助确保写入是原子的。 您可以在同一here上阅读有趣的文章(请查看“常见问题”部分)


修改

Cassandra确实具有一些内部机制(称为阻塞读取修复)-在将来自数据库的响应发送回客户端之前触发同步写入。这种同步读取修复是在查询达到读取一致性级别的节点之间存在不一致的情况下发生的,并确保了称为单调读取一致性的内容[有关定义,请参见下文]。这导致在第一个读取请求的情况下,在上例中的(k,v1)在返回响应之前被写入节点B,因此第二个读取请求也将具有更新的值。 (感谢@Nadav Har'El指出这一点)

但是,这仍然不能保证强一致性。下面是一些清除它的定义:

顺序/强一致性:任何执行的结果都与读取和写入以某种顺序发生一样,并且每个单独的处理器的操作均按以下顺序指定:其程序[由Leslie Lamport定义]

单调阅读一致性:读取值后,所有后续读取将返回该值或更高版本

顺序一致性将要求客户端程序/读取器查看自从在程序指令序列中的read语句之前执行write语句以来所写入的最新值。