我们有一个 6 节点的 cassandra 集群，每秒读取次数非常多，写入次数很少。整个应用程序包括：
- 使用一个 cassandra 节点的 Web 应用服务器
- 5 x web 服务机器，每台使用自己的 cassandra 节点（pycassa 的 Pool server_list 始终是一个节点）
与 cassandra 对话的 Web 应用程序正在执行读写操作（但很少，只有当有人实际使用应用程序 UI 时，这种情况并不经常发生）。然而，Web 服务的负载非常重，来自 3rd 方服务的流量。负载均衡器将流量引导到所有 5 台服务器，每台服务器用大量 get() 和 multiget() 请求轰炸自己的 cassandra 节点（物理上位于另一台服务器中）。偶尔会使用 set() ，但这就像每 10000 次读取或其他东西一样。
有了这种用法，我们决定使用 6 的复制因子。如果每个 cassandra 都有 100% 的数据，那么读取应该更快，负载应该更均衡。我们更新了 keyspace strategy_options 并在每个节点上运行 nodetool repair 来传输数据。一切顺利。
现在很奇怪的是：所有六个 cassandra 节点的 CPU 使用率都很高。在 web 服务使用的五个节点的情况下可以理解，但我们无法解释为什么 webapp cassandra 节点也消耗那么多 CPU，就好像它正在执行大量读取一样。就好像复制根本不起作用 - 看起来每个 cassandra 节点都会在 get() 发生并且整个环受到极大压力时与所有其他节点进行通信。
我做了另一个实验来证明这一点，我关闭了其中一个 Web 服务器，我正在查看相应的 cassandra 节点。服务器宕机后，我预计这个 cassandra 节点上的 CPU 使用率接近于零，因为没有其他机器指向它。但它不是零，略有下降，但仍处于非常高的水平（60% 的 CPU 使用率）。
我们正在使用 pycassa，我们没有操纵一致性级别，所以它是默认的 ConsistencyLevel.ONE
我希望你明白我的意思......如果复制因子等于环中的节点数，并且读取一致性级别是默认值（ONE），那么每个节点在读取方面应该是独立的：如果没有人在做来自给定节点的任何读取，该节点上的 CPU 使用率应该是最小的，对吗？然而，即使我们断开唯一看到该节点的客户端，我们仍然会观察到 CPU 使用率很高，就好像有人仍在继续读取它一样。这个负载来自哪里，怎么可能调查发生了什么？