Scylla/Cassandra/CockroachDB中LWT对集群吞吐量的影响及疑问

1. 单个热键LWT无法扩展，为何整个集群吞吐量也难提升？ #

• 核心原因：单个热键的LWT吞吐量由共识协议（Paxos/Raft）的副本同步开销决定。这类数据库的副本数通常固定（比如默认3个），不管集群总节点数多少，热键的副本只会分布在这3个节点上。加更多节点不会增加该热键的副本数量，因此单热键的处理能力上限是固定的。
• 如果工作负载中热键占比极高（比如超过整体负载的30%），整个集群的吞吐量会被这个热键的上限卡住——冷键的吞吐量再高也拉不动整体指标。但如果热键占比低，加节点仍能提升冷键部分的吞吐量，整体集群吞吐量会上升。

2. 热键的共识阻塞为何波及其他键？ #

• 共识协议需要副本节点消耗CPU、网络、磁盘资源处理投票、日志同步。如果热键的LWT请求持续占满这些节点的资源（比如CPU跑满、网络带宽耗尽），节点上其他键的副本处理请求时会因资源争抢排队，导致整个集群延迟上升、吞吐量下降。
• 比如Cassandra/Scylla的节点可能同时负责多个键的副本，热键请求占满线程池或IO后，其他键的读写都会受影响；CockroachDB的Raft组按范围拆分，但热键所在范围的副本节点资源被占满时，该节点上的其他Raft组也会被拖累。

3. 水平扩展的意义何在？CockroachDB是否有同样问题？ #

• 水平扩展的核心价值是处理均匀分布的多键负载：当工作负载分散在大量键上时，加节点可以把负载分摊到更多节点，每个节点处理的键副本更少，整体吞吐量能线性提升。
• 只有负载集中在少数热键时，水平扩展才无法提升整体吞吐量——这是共识协议的本质限制，而非数据库设计缺陷。
• CockroachDB同样存在这个问题：单个热键的线性化事务吞吐量不会随节点数增加而提升，因为副本数固定，共识开销只和副本数相关。但对于均匀分布的多键负载，它的水平扩展能力依然很强。

4. 单个键LWT/线性化事务的基准测试 #

• 这类基准测试普遍存在：
  • Scylla官方测试显示，RF=3时单键LWT的单节点吞吐量约为数千TPS，加节点后无明显提升。
  • Cassandra社区测试结果类似，单键LWT的TPS上限由副本间同步延迟决定，与集群总节点数无关。
  • CockroachDB官方文档提到，单个热点范围的线性化事务吞吐量上限约为每秒几百到几千次，不会随集群节点数增加而提升。
• 你提到的视频中吞吐量恒定、未测试节点数，是因为单键LWT的性能瓶颈不在集群节点总数，而在副本数和节点间网络延迟——加更多节点不会改变这两个变量，因此吞吐量不会变化，测试无需将节点数作为变量。

5. 为什么预期集群LWT吞吐量随节点提升，但实际不是？ #

• 你的预期仅在负载均匀分布、无热键的场景下成立：此时每个节点处理不同的键，每个键的LWT请求分散在不同副本组，加节点能增加更多副本组，整体吞吐量线性提升。
• 如果存在热键，热键的吞吐量上限会成为集群的瓶颈，此时加节点无法突破这个瓶颈，整体吞吐量就不会提升。
• 总结：集群LWT吞吐量是否随节点提升，完全取决于负载分布——均匀负载下可线性扩展，热键主导的负载下则不行。

内容的提问来源于stack exchange，提问作者siddharthabhi30