让我们说，我们有一个cassandra部署，其复制因子为2。通过这种方式，我的意思是我们可以忍受一个永久性存储节点的全部丢失而不会造成整体数据丢失。我理解这意味着每个值在任何给定时间都存储在至少两个不同的节点上。因此，所需的总存储量至少为值x 2的总数据。即，如果我们需要在集群中存储100TB，则在节点之间至少需要200TB的持久性存储。
但是，随着节点数的增加，一个以上节点发生故障的可能性也会增加。因此，随着节点数量的增加，我们是否需要增加复制因子？
例如：
让我们假设所有组件都是100％可靠的，除了我的节点本地存储控制器外，该控制器有时会完全破坏所有本地存储而无法恢复（即，数据丢失）。所有机架设备，开关，电源，冷却装置等都是完美的。我知道这是不现实的。
假设我的节点每个都有1TB的存储空间。对于100TB的值，我将需要200台计算机来实现2的复制因子（即，我可以丢失任何一个节点并仍然保留数据）。但是，如果我认为200个集合中的2个节点同时失败，则需要将复制因子提高到3。因此，现在我需要每个值三个副本（在三个不同的节点上），现在需要300个节点。我现在感觉可能同时丢失3个或更多节点，因此我必须再次添加更多节点，等等...
当然，这实际上不是如何缩放？我的逻辑有什么问题？
有几种类型的故障需要考虑：
复制有助于避免完全的数据不可用，但它也可能取决于部署策略。
例如，如果您的所有服务器都在一个数据中心中，则如果不可用，您将失去对数据的访问权限。或者，如果您没有将群集设置为具有可感知机架的数据放置，则可以将副本放置在同一机架中，如果副本出现故障，则会丢失副本。
通常，建议使用复制因子3，并且如果您打算进行大型部署，则一定要使用机架感知的数据放置-但是您应该小心，因此机架数应与RF匹配（在云部署中，通常是机架映射到可用区）。
可用性还取决于您的业务需求-在最简单的情况下，如果使用一致性级别ONE或LOCAL_ONE，则即使只有一个副本可用，您的数据仍然可用，但是如果您的业务逻辑需要更强的一致性，则需要具有更多可用副本。复制因子也会影响一致性级别-如果您使用RF = 2，并且要求CL = QUORUM，则您不能容忍单节点故障，而可以通过RF = 3来实现CL且一个节点发生故障。