您的问题有点不清楚，因为我认为您没有正确构建问题。但我会尝试解释一些有助于您理解它的要点。
Nodes = 4，提供两个节点故障，RF为'3'是有好处的
- 节点数不是读/写失败的计数因素。 RF（复制因子）和 CL（一致性级别）是读/写失败的决定因素（如果需要的副本或节点已关闭）。
RF -> 将保留多少份数据（行）。 （有多少服务器或节点将保留相同的行/数据）。
CL -> 确认需要多少个节点才能让客户端知道/通知写/读操作成功。这意味着至少提到的节点数量为 CL（例如：如果 CL 为 2，则至少 2 个节点）必须确认/确保它们已成功写入数据或从这些副本中读取数据（等到所有必需的副本返回结果到协调器节点）并合并结果（如果不同节点对相同数据的更新不同，则保留最新数据）并成功将结果返回给客户端。
注意：如果 RF = CL，那么您使用的 CL 等同于 ALL。
ALL 是最高级别的一致性级别（数据肯定是最新的，但如果单个副本宕机则不可用）
场景 1：
Nodes = 3, Replication Factor = 2, Write Consistency = 2, Read Consistency = 1
对于写操作：
由于您使用了最高级别的写入CL（RF和写入CL值相同），那么这将是单点故障的情况。所有必需的副本都必须处于活动状态才能确认客户端数据已成功写入两个节点。
对于读操作：
读取 CL 为 ONE。因此，如果一个副本出现故障，它可以生存。因为只有一个副本需要将结果返回给客户端。可能是旧数据（如果更新的数据还没有传播到这个节点，但最终还是一致的），但是读取会成功。
场景 2：
Nodes = 3, Replication Factor = 3, Write Consistency = 2, Read Consistency = 1
对于写操作：
由于节点数 = RF，所有数据都将复制到所有节点（100% 拥有）。它将在一个节点/副本关闭时存活下来。
对于读操作：
如果两个副本都down了，它可以生存。
场景 3：
Nodes = 4, Replication Factor = 2, Write Consistency = 2, Read Consistency = 1
对于写操作：
与场景 1 相同。
对于读操作：
与场景 1 相同。
场景 4：
Nodes = 4, Replication Factor = 3, Write Consistency = 3, Read Consistency = 1
对于写操作：
与场景 1 相同。
对于读操作：
与场景 2 相同。
相关链接：
Understand cassandra replication factor versus consistency level
详情请关注DataStax Doc。
已编辑
如果您担心节点故障情况（读取或写入请求失败），节点数量无关紧要。
假设你有 3/4/5 个节点，如果 RF 为 3，CL 为 QUORUM (3/2 + 1 ~ 2)，集群可以容忍 1 个副本节点宕机。请阅读以上链接中的About the QUORUM level 部分。
如果您有更多节点，则集群可以处理更多数据或在节点之间正确加载和分配数据。但是请求故障转移场景将是相同的。
节点 = 3，复制因子 = 3，写入一致性 = 2，读取
一致性 = 1
节点 = 4，复制因子 = 3，写入一致性 = 2，读取
一致性 = 1
节点 = 5，复制因子 = 3，写入一致性 = 2，读取
一致性 = 1
由于 RF 为 3，Write 和 Read CL 分别为 2 和 1，集群可以容忍一个副本宕机进行写操作，两个副本宕机进行读操作。希望对您有所帮助。