我目前正在使用 CassandraSharp 对具有 3 个节点的 Cassandra 进行基准测试。 我主要关心的是延迟多于吞吐量，所以经过一些 GC 调整后，这里是我的数字（100 000K 插入，单线程）：
我的问题是，有时我会遇到“糟糕”的延迟（50 毫秒），我的目标是保持一致的延迟，即使以更高的平均值为代价。
我认为这是由 GC 引起的，我想知道是否可以避免。
（顺便说一句，向一个节点发送大量插入并让它处理它是一种好习惯，还是应该在客户端“负载平衡”它？）
【问题讨论】：
50ms 在年轻代垃圾回收的正常范围内。您可以在 cassandra-env.sh 中通过取消注释底部的相应行来启用 GC 日志记录，以验证这是问题所在。
（刷新不会阻止插入，除非您的磁盘速度太慢以至于无法跟上插入量，这是不寻常的，因为刷新是顺序 i/o。）
如果年轻代集合确实与更高的延迟相关，您可以减少尝试使年轻代更小（也在 cassandra-env.sh 中配置），但可能会以延迟换取吞吐量为代价。
【讨论】：
我认为您无法偶尔摆脱糟糕的延迟问题。它最有可能是您提到的 GC，或者当它从 Memtables 执行刷新到磁盘时。
50ms 的错误插入真的有问题吗？ Cassandra 支持批量修改器，允许您将插入操作排队在一个长修改器中，然后在稍后执行批量插入，这样您的主线程就不需要被同步插入阻塞，同步插入可能需要更长的时间预期的。我没用过CassandarSharp所以不知道它是否暴露了这个功能。
此外，跨 cassandra 节点的负载平衡会略微缩短您的导入时间，但请记住，幕后发生的事情是您提供导入的节点会将其交给正确的节点进行存储（所以你给它的节点真的充当代理）所以我不会想象在一般边缘情况下会有多大改进。如果由于某种原因该节点开始做其他事情并且其性能受到影响，它将对您有所帮助。
【讨论】：
如果您对可靠的插入时间感兴趣，您可能想查看 Cassandra 的 Acunu 发行版，它在插入时提供了 100 倍的稳定延迟：Cassandra under Heavy Write Load（特别注意第二张图片）。
【讨论】：