Apache Cassandra作为高可用分布式数据库，在生产环境部署前必须清楚集群能承受多大读写压力。cassandra-stress是官方随发行包提供的基准测试工具，无需额外安装即可通过命令行模拟大量客户端并发操作，帮助我们获得吞吐量、延迟分布与错误率等核心指标。理解它的运行模型和参数体系，是做科学容量规划的第一步。
工具基本架构与执行流程
cassandra-stress的本质是一个可分布式运行的Java客户端，它按照用户指定的线程数开启多个虚拟用户，每个虚拟用户循环执行插入或查询语句。工具内部通过定时采样记录每次操作的响应时间，并在测试结束时聚合为百分位延迟与每秒操作数。它既可以连接单节点也可以指向整个集群的 contact point，由驱动自动发现拓扑。
在命令执行上，最基础的形式是cassandra-stress write和cassandra-stress read。write阶段会先根据定义的schema建表并灌入数据，read阶段则在已有数据上做查询。若省略read，仅做写入基准，可用于评估初始加载性能。工具还提供mixed模式，允许按比例混合读写，更贴近真实业务。
值得注意的是，cassandra-stress自身也会消耗CPU和内存，尤其在超高并发时生成随机数据的开销不可忽视。因此压测机配置不能太差，最好与被测集群网络就近，避免网络瓶颈掩盖了数据库真实能力。一般建议压测机独立部署，并监控其负载。
核心参数与自定义Schema方法
通过-col可以设定列的数量与大小，例如-col 'n=5' -col 'size=fixed(64)'表示每行5列、每列64字节。使用-schema能指定复制策略与副本数，如-schema 'replication(factor=3)'。分区键和聚簇键的设计直接影响数据分布，工具默认用随机UUID做分区，但也可以借助-pop参数控制数据分布偏移，从而模拟热点。
当内置的默认表结构不满足需求时，可使用-insert和-mode结合YAML文件定制。在YAML里写明keyspace、表名及各类字段类型，cassandra-stress会按此建立schema并生成对应数据。这种方式适合验证自己真实业务表在Cassandra下的表现，比如宽行、静态列等复杂模型。
下面示例展示了一个简单的自定义写入压测命令，包含线程数与总量控制：
# 使用3个线程，每线程执行10000次写入，共3万次操作 cassandra-stress write n=30000 cl=QUORUM -schema 'replication(factor=3)' -col 'n=3' -col 'size=fixed(128)' -mode native cql3 user=cassandra password=cassandra -node 192.168.0.1
上面的命令中cl=QUORUM设定一致性级别，-node指向集群某个种子节点。执行后终端会周期性打印吞吐与延迟，最终给出详细报告。通过调整n和线程相关参数，可以观察不同并发下集群的拐点。
结果解读与常见性能陷阱
测试报告里最关键的几项是Op rate（每秒操作数）、Latency median（中位数延迟）以及95th、99th百分位延迟。若99th延迟远高于中位数，说明存在偶发长尾请求，常由GC停顿、磁盘抖动或热点分区引起。此时应结合Cassandra的nodetool tpstats查看各类线程池积压情况。
一个常见误区是用极小数据量做压测，例如只写几千行。由于Cassandra有memtable和缓存机制，小数据量可能完全命中内存，测出的性能远高于真实持久化场景。正确做法是以接近生产规模的数据量运行，并持续足够长时间让压缩（compaction）发生，观察稳态表现。
另一个陷阱是忽略分区键设计。若用递增时间戳做分区键，所有写都会落到同一节点同一分区，造成严重热点，压测曲线会呈现吞吐上不去、单节点负载飙高。借助cassandra-stress的-pop参数把数据倾斜到特定范围，可主动复现该问题，从而提前优化数据模型。以下代码演示了如何用YAML定义带哈希前缀的分区键来缓解热点：
keyspace: stress_keyspace table: user_events columns: > bucket int, user_id uuid, event_time timestamp, payload text partition key: (bucket, user_id) cluster columns: (event_time)
通过将数据打散到不同bucket，写入自然分布到集群各处。再用cassandra-stress载入等量数据，对比热点模型下的延迟，差异往往非常明显。这种基于工具的实验，比单纯理论分析更有说服力。
混合场景与持续集成中的运用
真实业务很少是纯写或纯读，cassandra-stress的mixed模式通过-ratio设置读写权重，例如(read=8,write=2)表示八成读两成写。配合-rate里的threads与throttle，可以模拟固定并发或固定目标速率，观察系统在受限资源下的行为。
在持续集成流水线中，可将标准压测作为性能门禁。每次表结构变更后自动跑一轮固定参数的cassandra-stress，若Op rate下降超过阈值则阻断合并。这样能防止慢查询模型悄悄进入生产。由于工具输出为文本，很容易用脚本解析关键指标并上报。
对于多数据中心部署，还可以通过-node指定远端DC地址，并设置cl=LOCAL_QUORUM，验证跨区写入的额外开销。这种测试能帮助团队决定哪些表适合本地读、哪些必须全局一致，从而细化一致性级别策略。
cassandra-stressCassandra压力测试修改时间：2026-08-16 12:42:13