假设我有一个包含4个节点的集群。
我使用ConsistenyLevel.ALL
假设所有4个节点都已连接，它将按预期成功。
假设所有4个节点都已连接，但1由于某种原因而失败（主键已存在等）。它会失败。
我的问题是：
如果4个节点中有1个处于脱机状态，那么当使用ConsistentyLevel.ALL执行写入时，它会失败吗？
还是考虑到了“可达性”？ （即，如果节点离线，则有效簇大小为3而不是4）。
如果要成功，当4节点重新联机时，它会在接受新客户端请求之前同步吗？
PS。不确定这是否重要但我会使用Datastax Java Driver。
答案 0 :(得分：1)
如果指定一致性级别为ALL，则该请求将失败，并且群集已知的任何负责该查询的副本都未启动。一旦节点完成加入群集并且已经为其分配了令牌范围，就始终考虑CL保证和复制。只有在nodetool decommission运行时才从集群中删除它。
假设您有一个复制因子= 2的4节点集群。这意味着无论有多少节点向上或向下，集群的所有成员都知道每个数据块应该有2个副本。如果您在2个节点关闭时执行查询并且您的一致性级别为ALL，则如果其中任何一个节点负责您尝试写入或读取的信息的副本，则该查询将失败。
给定一个4节点集群，其职责如下
Node 1 { A, D }
Node 2 { B, A }
Node 3 { C, B }
Node 4 { D, C }
给定一致性等级
Select * where partition key hashes to range A
这将通过，因为节点1和2是唯一负责A数据的节点，它们是 两个都
Select * where partition key hashes to range B
这将失败，因为负责B的2个已知节点中只有1个启动（节点2向上但节点3已关闭）
答案 1 :(得分：1)
节点数量不是决定因素。复制因子起着更大的作用。即使这样，它也不是直截了当的：
假设复制因子为3，并且您已指定Quorum（或ALL ...）。处理请求的节点是请求的协调器。让我们假设请求是写入。
如果协调器知道节点已关闭以致请求一致性级别失败，则请求＆＃34;失败＆＃34;。协调员将会知道＆＃34;关于通过八卦传播的节点。
如果协调员知道有足够的节点，那么它将向所有副本发出写入。它将根据一致性级别等待所需数量的节点的响应。如果它收到足够的ack，请求成功。但是，如果它在超时内没有收到足够的确认，则请求＆＃34;超时＆＃34; （不是＆＃34;失败＆＃34;）。这意味着重新启动的节点将完成＆＃34;完成＆＃34;写入通过提示切换，或在下一个查询。这可能看起来很奇怪＆＃34;，但读了这个： http://www.datastax.com/dev/blog/how-cassandra-deals-with-replica-failure 更详细一点，这个： http://mail-archives.apache.org/mod_mbox/cassandra-user/201102.mbox/%3CAANLkTimEGp8H87mGs_BxZKNCk-A59whXF-Xx58HcAWZm@mail.gmail.com%3E
希望有所帮助。
答案 2 :(得分：0)
如果4个节点中有1个离线，当使用ConsistentyLevel.ALL执行写操作时，它会失败吗？ 还是考虑到了“可达性”？ （即，如果节点离线，则有效簇大小为3而不是4）。
是的，它会失败。 Cassandra具有可调整的一致性，但您的交易分区容差。使用CL.ALL时，您无法处理任何节点故障。您应该尽可能使用CL.ONE并在需要数据一致但仍希望能够处理某些节点故障时使用CL.QUORUM进行读/写（假设您应该运行复制因子＆gt; = 3） ）。在极少数情况下应该使用ALL。