我正在研究 Cassandra，我知道它是一个没有主从的对等数据库。
每个读/写都由一个协调器节点促进，然后协调器节点使用复制策略和 Snitch 将读/写请求转发到特定节点。
我的问题是关于此方法的性能问题。
- 没有额外的跃点吗？
- 写入是否经过缓冲然后转发到正确的副本？
- 性能如何随不同的复制而变化 策略？
- 我可以通过绕过协调器节点来提高性能吗？ 自己写入副本节点？
最佳答案
1) 偶尔会有一个额外的跃点，但您的驱动程序很可能有一个 TokenAware 策略来选择协调器，该策略将选择协调器作为给定分区的副本。
2) 写入被缓冲，并且根据您的一致性级别，您将不会收到写入的确认，直到它被多个节点接受。例如，对于一致性级别 1，您将在单个节点接受写入后立即收到 ACK。其他节点将有写入排队并交付，但您不会收到有关它们的任何信息。如果其中一个写入失败/无法交付，将在协调器上存储一个提示，以便在副本重新联机时交付。显然，可以保存的提示数量是有限制的，因此在长时间停机后您应该运行修复。
在一致性级别较高的情况下，在 CL 中的节点数量已接受写入之前，客户端不会收到确认。
3) 性能应与写入总数成比例。如果集群可以维持每秒 10k 的净写入但 RF = 2。您很可能每秒只能进行 5k 写入，因为每次写入实际上是 2。无论您的一致性级别如何，这都会发生，因为即使您发送了这些写入不等待他们的确认。
4) 真的没有办法绕过协调。 token 感知策略将选择一个好的协调器，这基本上是你能做的最好的。如果您手动尝试写入每个副本，您的写入仍会被接收请求的每个节点复制，因此您将得到 N 个协调事件而不是一个协调事件。这也很可能是一个坏主意，因为我假设您有更好的C* 节点之间的网络比从客户端到 c* 节点的网络。
关于database - 协调器节点及其对性能的影响，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26899632/