Database 协调器节点及其对性能的影响

我在研究卡桑德拉，我知道这是一个没有主从的对等数据库

每个读/写操作都由一个协调器节点来完成，然后协调器节点使用复制策略和Snitch将读/写请求转发给特定节点

我的问题是关于这种方法的性能问题

没有额外的跳跃吗

写入是否已缓冲，然后转发到正确的副本

不同的复制会如何改变性能 策略

我是否可以通过绕过协调器节点和 自己写副本节点

---

我没有关于2和3的答案，但是关于1和4

1） 是的，这会导致额外的跳跃

---

4） 是的，有点。Datastax驱动程序以及Netflix Astynax驱动程序可以设置为，这意味着它将监听环的流言，以了解哪些节点具有哪些令牌范围，并将插入发送到将存储它的节点上的协调器。消除额外的网络跃点

要添加到Andrew的响应中，不要假设协调器跃点将导致显著的延迟。进行查询和测量。考虑一致性级别而不是额外的跃点。调整一致性以获得更高的读写速度，或两者之间的平衡。然后测量。如果发现延迟不可接受，则可能需要调整一致性级别和/或更改数据模型。

1）偶尔会有一个额外的跃点，但您的驱动程序很可能会有一个令牌感知策略来选择协调器，它将选择协调器作为给定分区的副本

2） 写入是缓冲的，根据您的一致性级别，在多个节点上接受写入之前，您不会收到写入确认。例如，对于一致性级别1，您将在单个节点接受写入后立即收到ACK。其他节点的写入将排队并传递，但您将不会收到任何有关它们的信息。如果其中一次写入失败/无法传递，则将在复制副本恢复联机时在要传递的协调器上存储一条提示。显然，可以保存的提示数量是有限制的，因此在长时间停机后，您应该运行修复

对于更高的一致性级别，在CL中的节点数接受写入之前，客户端将不会收到确认

3） 性能应随写入的总数而扩展。如果一个集群能够维持每秒净10k写入，但RF=2。你很可能每秒只能写5k次，因为每次写实际上是2次。这种情况的发生与您的一致性级别无关，因为即使您没有等待它们的确认，这些写入也会被发送

4） 真的没有办法绕过协调。令牌感知策略将选择一个好的协调器，这基本上是您所能做的最好的。如果您手动尝试写入每个副本，您的写入操作仍将由接收到请求的每个节点复制，因此您将获得N，而不是一个协调事件。这也很可能是一个坏主意，因为我假设您的C*节点之间的网络比从客户端到C*节点之间的网络更好