假设：RF = 3
在 Internet 上的一些关于一致性级别的视频中，演讲者说 CL = ONE 比 CL = ANY 更好，因为当我们使用 CL = ANY 时，协调器会很乐意只存储提示（和数据）（我们在这里假设所有具有相应分区键范围的其他节点已关闭）并且由于协调器的故障，我们可能会丢失我们的数据。但是等一下....据我了解，如果我们使用 CL = ONE 并且例如我们只有一个（三个）可用节点用于此分区键，我们将只有一个节点插入数据。损失风险是一样的。
但我认为我们应该假设相同的情况 - 特定令牌的所有节点都消失了。那么最好还是放弃写操作，然后写这么大的coordinator丢失风险。
【问题讨论】：
标签： cassandra replication consistency
问题是，默认情况下，提示将仅存储 3 小时，并且比您必须运行修复的时间更长。如果您在集群中的某个节点上至少有一份此数据的副本，则可以修复（存储在协调器上的提示不计算在内）。
Consistency One 保证集群中至少有一个节点在提交日志中包含它，无论如何。 Any 在最坏的情况下存储在协调器的提示中（其他节点无法访问它），默认情况下存储在 3 小时的时间范围内。使用 ANY 3 小时后，如果其他两个实例关闭，您将丢失数据。
如果您担心风险，那么使用 quorum 和 2 个节点将必须保证保存数据。由应用程序开发人员/设计人员决定。 Quorum 的写入延迟通常比 One 稍大。但是如果负载急剧增加，您总是可以添加更多节点等。
还可以看看这个不错的工具，了解各种一致性和复制因素对应用程序的影响：
https://www.ecyrd.com/cassandracalculator/
使用 RF 3，集群中的 3 个节点实际上将获得写入。一致性就是您希望等待他们的响应多长时间......如果您使用 One，您将等到一个节点将其放入提交日志中。但是协调器实际上会将写入发送给所有 3 个。如果它们没有响应，协调器会将写入保存到提示中。
大多数情况下，生产中的任何东西都是一个坏主意。
【讨论】：
CL=ANY 可能永远不应该在生产服务器上使用。在将提示写入拥有该分区的节点之前，写入将不可用，因为在提示日志中时您无法读取数据。
在两个节点关闭的情况下使用 CL=ONE 和 RF=3，您可以将数据存储在 a) 节点上的提交日志和 memtable 以及 b) 提示日志中。这些可能是不同的节点，但它们可能有 1/3 的时间相同。所以，是的，如果使用 CL=ONE 和 CL=ANY，您可能会因单个节点故障而导致数据完全丢失。
使用 CL=QUORUM 或 CL=LOCAL_QUORUM 代替 ANY 或 ONE。
【讨论】：