Question

根据有关datastax（https://docs.datastax.com/en/cassandra/2.1/cassandra/dml/dml_about_hh_c.html）的在线文档，说明如下：

在写入操作期间，当启用提示切换并且可以满足一致性时，协调器会在以下任一条件下在本地system.hints表中存储有关死副本的提示：

已知该行的副本节点已提前关闭。
副本节点不响应写入请求。

我感到困惑的是，为什么第一个项目符号点是一个条件，如果协调员已经提前知道它已经知道了，那么为什么协调员会存储提示。

根据这里的文档（https://www.datastax.com/dev/blog/how-cassandra-deals-with-replica-failure），它声明： Cassandra唯一一次写入失败的时候，当协调员收到请求时，只有太少的副本存活。 < / p>

根据我到目前为止所读到的内容，只有在收到请求时所需的副本处于活动状态并且一个或多个副本变得无响应时才会使用提示。第一个要点是当副本节点已经关闭时使用提示。如果只有太少的副本存活时，Cassandra会自动失败写入，那么存储已经被视为失败的写入提示的重点是什么？

Answer 1

在Cassandra世界中，通常期望处于“向下”状态的节点最终会恢复。否则，作为操作员，您将退役。

Cassandra不知道该节点是否会重新启动，因此它会存储该提示，以防节点在提示窗口到期之前出现。从Cassandra的修复过程中恢复过来的速度更快（应始终保持运行）。

Answer 2

在Cassandra中，有一个称为一致性级别（CL）的东西，它是为每个请求设置的。 CL定义了多少节点必须响应请求才能成功。

例如，假设您复制了3.您不一定需要所有3个节点才能知道您获得了正确的响应。大多数（称为法定人数）就足够了。不要误解这一点。如果请求是写入，您仍然会写入所有3个副本，因为您希望在所有节点上复制数据。但是，由于您仅指定了CL quorum，因此只有大多数节点必须响应协调器才能使客户端请求成功。

因此，具有CL仲裁的客户端请求的完整写入路径可能如下：

                                      --write--> Node 1
Client --write request--> Coordinator --write--> Node 2
                                      --write--> Node 3

                                <--success-- Node 1
Client <--success-- Coordinator <--success-- Node 2
                                <--success-- Node 3

这是因为所有3个节点都响应协调器成功。

我们也可以从其中一个节点获得超时：

                                      --write--> Node 1
Client --write request--> Coordinator --write--> Node 2
                                      --write--> Node 3

                                <--success-- Node 1
Client <--success-- Coordinator <--success-- Node 2
                                <--timeout-- Node 3

由于我们只需要大多数节点的成功，因此请求仍然会成功。在这种情况下，提示将存储在协调器上。一旦节点3再次响应，它将尝试重放（再次发送写入）。

如果已知节点已关闭或无响应，则会发生同样的事情。协调器只关心是否有足够的节点响应以满足一致性级别。

如果已知该行的副本节点提前关闭，协调器为什么会存储有关死副本的提示？

2 个答案: