4) 现在如果我关闭节点 60，Cassandra 需要转移
现有数据到 '1,'ram', 9003934069' 到剩余节点（到
61 或 63) 将 RF 保持为“3”？
这不是 Cassandra 的工作方式 - 复制因子“仅”声明要在不同节点的磁盘上存储 Cassandra 的数据副本数。 Cassandra 在数学上从您的节点中形成一个环。每个节点负责一系列所谓的令牌（基本上是分区键组件的哈希）。您的复制因子为 3 意味着数据将存储在处理您的数据令牌的节点和环中接下来的两个节点上。
（快速谷歌图片https://image.slidesharecdn.com/cassandratraining-161104131405/95/cassandra-training-19-638.jpg?cb=1478265472）
更改环形拓扑非常复杂，根本不会自动完成。
1) 我有 5 个节点的集群（172.30.56.60、172.30.56.61、172.30.56.62、172.30.56.63、172.30.56.129）
2) 我创建了一个复制因子为 3 的键空间
写一致性为 3，我在表中插入了一行，分区为“1”，如下所示，
INSERT INTO user (user_id, user_name, user_phone) VALUES(1,'ram', 9003934069);
3) 我使用 nodetool getendpoints 实用程序验证了数据的位置，并观察到数据被复制到三个节点 60、129 和 62 中。
./nodetool getendpoints keyspacetest user 1
172.30.56.60
172.30.36.129
172.30.56.62
4) 现在如果我关闭节点 60，Cassandra 需要将现有数据传输到 '1,'ram', 9003934069' 到剩余节点（到 61 或 63）以保持 RF 为 '3'？
但是 Cassandra 没有这样做，这是否意味着如果节点 60、129 和 62 关闭，我将无法读取/写入表 'user' 中分区 '1' 下的任何数据？
问题 1：所以即使我有 5 个节点集群，如果数据 / 分区
所在的地方宕机了，集群就没用了？
没有。另一方面，有一致性级别 - 您可以在其中定义必须有多少节点确认您的写入和读取请求才能被视为成功。上面您还采用了 CL=3 和 RF=3 - 这意味着所有持有副本的节点都必须响应并且需要在线。如果一个节点宕机，您的请求将一直失败（如果您的集群更大，比如 6 个节点，那么在线的三个节点可能是某些写入的“正确”节点）。
但 Cassandra 具有可调整的一致性（请参阅http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/dml/dml_config_consistency_c.html 的文档）。
例如，您可以选择 QUORUM。然后查询需要 (replication factor/2)+1 个节点。在你的情况下 (3/2)+1=1+1=2 个节点。如果您确实需要一致的数据，QUORUM 是完美的，因为在任何情况下，参与您的请求的至少一个节点将在写入和读取之间重叠并拥有最新数据。现在一个节点可以关闭，一切仍然可以工作。
但是：
问题 2：如果两个节点已关闭（示例：60 和 129 已关闭）仍然
61,62 和 63 已启动并运行，但我无法写入任何数据
在写一致性= 3的分区'1'中，为什么会这样？
因为我能够以写一致性 = 1 写入数据所以
这再次表明该分区的数据将仅在
集群中预定义的节点，不可能重新分区？
看上面 - 这就是解释。写入一致性的 CL=1 将成功，因为一个节点仍然在线并且您只请求一个节点来确认您的写入。
当然复制因子也不是没用的。即使选择了较低的一致性级别，写入也会复制到所有可用节点，但您不必在客户端等待它。如果一个节点在短时间内（默认 3 小时）关闭，协调器将存储错过的写入，并在节点再次出现并且您的数据再次完全复制时重播它们。
如果一个节点宕机时间较长，就需要运行nodetool repair，让集群重建一个一致的状态。无论如何，这应该作为维护任务定期完成，以保持集群的健康 - 由于网络/负载问题可能会丢失写入，并且删除墓碑可能会很痛苦。
您可以删除或添加节点到您的集群（如果这样做，只需一次添加一个），Cassandra 将为您重新分区您的环。
如果删除在线节点可以将其上的数据流式传输给其他节点，则可以删除离线节点但其上的数据将没有足够的副本，因此必须运行nodetool repair。
添加节点会将新的令牌范围分配给新节点，并自动将数据流式传输到您的新节点。但是不会为您删除源节点的现有数据（确保您的安全），因此添加节点后nodetool cleanup是您的朋友。
Cassandra 根据 CAP 定理选择 A（可用）和 P（分区容忍）。
（见https://en.wikipedia.org/wiki/CAP_theorem）。因此，您无法随时保持一致性 - 但 QUORUM 通常就足够了。
保持对节点的监控，不要太害怕节点故障 - 它只会在磁盘死机或网络丢失时发生，但要为它设计应用程序。
更新：在丢失数据或查询之前，用户可以选择集群会发生什么。如果需要，您可以使用更高的复制因子（RF=7 和 CL.QUROUM 允许丢失 3）和/或甚至在不同位置使用多个数据中心，以防丢失整个数据中心（这在现实生活中发生，想想网络丢失）。
对于下面关于https://www.ecyrd.com/cassandracalculator/的评论：
集群大小 3
复制因子 2
编写级别 2
阅读级别 1
您的读取是一致的：当然，您请求写入需要得到所有副本的确认。
在不影响应用程序的情况下，您可以在没有节点丢失的情况下幸存下来：见上文，RF=2 和 WC=2 请求任何时候所有节点都需要响应写入。因此，对于写入，您的应用程序将受到影响，对于读取，一个节点可能会关闭。
您可以在丢失 1 个节点的情况下幸存下来而不会丢失数据：因为数据被写入 2 个副本，并且如果一个节点出现故障，您只能从其中一个节点读取，您仍然可以从另一个节点读取。
您实际上每次都从 1 个节点读取数据：RC=1 请求您的读取由一个副本提供服务 - 所以第一个 ack 的读取将执行，如果一个节点关闭没关系，因为另一个可以确认您的阅读。
您实际上每次都在写入 2 个节点：WC=2 请求每次写入都将由两个副本确认 - 这也是您示例中的副本数。所以写数据的时候所有节点都需要在线。
每个节点包含 67% 的数据：只是一些数学运算；）
使用这些设置，在写入集群时，您无法在节点丢失的情况下幸免于难。但是您的数据会写入两个副本上的磁盘 - 因此，如果您丢失一个副本，您仍然可以在另一个副本上保留数据并从死节点中恢复。