Cassandra中的摘要请求

关于摘要请求，我没有什么问题，我通读了文档，以下信息不符合要点

1） 假设我有10个节点的集群，RF=3，RC=2

同样为了理解，让副本为节点1、节点2和节点3，协调器为节点4

对于读取请求，根据我的理解，第一协调器（节点4）将直接请求发送到延迟较低的节点之一（动态告密），比如节点1，并获取数据，然后，在接收到数据之后，它将摘要请求发送到下一个延迟节点（如节点2）中的一个，并仅获取哈希值，并与直接请求计算的哈希值进行比较

问题1：摘要请求是否与直接请求并行发送（到节点2）或在接收到直接请求后发送摘要请求

问题2:我知道节点3的摘要请求也将被发送以确保数据一致性，但是协调器（节点4）何时将摘要请求发送到第三个副本（节点3）？是在协调员回复客户之后

问题3:文件中也提到了这一点，只有在完成读取修复后，协调员才会回复客户

问题4:除了跟踪，有人能解释一下实时识别读写请求流的方法吗

这将是伟大的，如果你们可以解释这些问题的工作流程，这将是有益的每个人

---

我通读视频也是为了参考：

我假设你的情况。这里N4是协调器节点。您向N2（副本）发送了直接请求。在接收到来自N2的响应后，协调器节点（N4）将向包含其他副本的任何节点（N3或N1）发送摘要请求。假设N3离节点更近。因此，摘要请求将被发送到N3以满足一致性级别。在收到N3的响应后，N4将比较N2和N3的数据，并将更新后的数据返回给客户端

N1节点中有另一个副本。现在，协调器节点向所有其他副本发送摘要请求。（在本例中为N1）。如果N4发现，任何节点（N1、N2、N3）都不会更新，它将运行读取修复请求

p、 s:我不知道答案4

---

对于第四个问题，您可以启用cass_log_set_level并将日志级别设置为debug info，您可以获得实时调试信息。

我对您的答案很满意，因此要解释一下，一切都是顺序的，1）直接请求，然后在收到响应后，2）然后只有协调器发送摘要请求并接收哈希，3）考虑到它响应客户端的哈希值相同4）在响应客户端之后，它将请求发送到剩余副本，并基于该请求更新读取修复。是否正确？让我等待另一位能够回答问题4的ppl，如果他们无法回答，我将接受您的回答。另一个注意事项是，每次读取请求后都不会触发读取修复，而是可以自行调整。有关详细信息，请参见。Q4：您可以将日志级别设置为“一般跟踪”和“所有节点上的非编辑cassandra日志”，但这并不有趣。@Mandraenke我在本博客中不理解这一点：“这意味着一致性级别为1时，不会修复任何数据，因为不会进行比较。对于QUORUM，只修复查询所涉及的节点，而不是修复所有节点。“如何设置此cass\u log\u set\u级别？”？我无法在cassandra conf folder@chakri中的任何文件中找到它，您必须在datastax驱动程序中设置它，然后通过程序执行查询。也许，您可以从日志文件中获取日志信息，如果您不想使用apache Cassandray编程，您必须使用c或python（由datastax提供）等驱动程序通过程序访问cassandra