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