Google Cloud 提供了多种计算实例类型和持久化磁盘选项，但 Cassandra 这类分布式数据库对 IO 延迟、网络带宽和内存管理非常敏感，单纯套用默认配置往往会导致性能不及预期。为了摸清 Google Cloud 云服务器运行 Cassandra 的真实水平，我们在一组 n2-standard-8 实例上部署了 Apache Cassandra 4.1，并使用 cassandra-stress 工具进行多轮压测，重点关注读写延迟分位数、吞吐量拐点以及跨可用区的网络抖动影响。
测试环境与部署方式
测试集群由三个位于同一区域不同可用区的节点组成，实例规格为 n2-standard-8，即 8 个 vCPU、32 GB 内存。系统盘使用 20 GB 的标准持久化磁盘，数据盘则分别测试了 pd-standard、pd-balanced 和 pd-ssd 三种类型，容量统一为 500 GB。每个节点关闭了透明大页，并将 Cassandra 的堆内存设置为 16 GB，剩余内存留给页缓存和 JVM 堆外开销。网络方面开启了 VPC 原生路由，并启用了内部 IP 通信，确保节点间流量不经过公网。
Cassandra 的配置文件中有几个关键参数直接影响性能表现。首先是 concurrent_reads 和 concurrent_writes，默认值分别是 32 和 32，对于 8 核实例可以适当调高到 64。其次是 file_cache_size_in_mb，我们将其设置为 4096，以充分利用剩余内存缓存 SSTable 索引。另外 commitlog_segment_size_in_mb 保持默认 32，但在使用 pd-ssd 时调整到 64 可以降低 commitlog 刷盘的频率。下面是部署时使用的核心配置片段：
# cassandra.yaml 关键参数调整 cluster_name: 'gcp-cassandra-cluster' num_tokens: 16 allocate_tokens_for_keyspace: true concurrent_reads: 64 concurrent_writes: 64 file_cache_size_in_mb: 4096 commitlog_segment_size_in_mb: 64 commitlog_sync: periodic commitlog_sync_period_in_ms: 10000 endpoint_snitch: GossipingPropertyFileSnitch
三个节点使用 gcloud compute instances create 命令创建，并通过启动脚本自动安装 JDK 11 和 Cassandra 4.1。为了确保各节点时钟同步，所有实例都启用了 NTP 服务。安装完成后修改 cassandra-rackdc.properties 中的 dc_suffix 和 rack 字段，将三个节点分别放在三个不同的 rack 中，以模拟跨机架部署的高可用场景。
由于 Google Cloud 的持久化磁盘本身是网络存储，IO 延迟会比本地 NVMe 磁盘高一些，但 pd-ssd 的随机读 IOPS 可以达到 15000 以上，对于中等规模 Cassandra 集群已经足够。实际测试中发现，将 commitlog 目录和数据目录都放在同一块 pd-ssd 上时，写路径延迟比分开挂载低约 12%，因为避免了跨磁盘的元数据竞争。因此我们在最终测试中统一使用单块大容量 pd-ssd 承载所有数据目录。
读写性能与延迟分析
使用 cassandra-stress 进行写入测试，工作负载为 100 万条记录，每条记录约 1 KB，副本因子 3，一致性级别为 QUORUM。测试结果显示，在 pd-ssd 磁盘上，写入吞吐量稳定在 28,000 至 32,000 ops/sec 之间，p99 写延迟约为 18 ms，p999 延迟达到 65 ms。当切换到 pd-balanced 磁盘时，吞吐量下降了约 35%，p99 延迟上升到 35 ms，说明磁盘 IO 能力是写入路径的主要瓶颈。pd-standard 磁盘则几乎无法满足持续写入需求，压测 10 分钟后延迟开始剧烈抖动，甚至出现大量超时。
读测试采用均匀分布的主键查询，数据总量同样为 100 万条，每条记录 1 KB。在 pd-ssd 环境下，读吞吐量峰值约为 45,000 ops/sec，p99 读延迟为 9 ms，p999 为 22 ms。由于 Cassandra 的读路径需要合并 MemTable 和多个 SSTable，内存缓存命中率对性能影响很大。我们将 row_cache_size_in_mb 设置为 1024，并开启 row_cache_save_period 为 30 秒，使得热点数据的重复读取延迟进一步降低到 p99 4 ms 左右。
网络层面，节点间复制流量在写入过程中非常可观。三个节点分布在 us-central1 的三个可用区，跨可用区之间的网络延迟平均在 0.3 至 0.8 ms 之间，带宽充足，未出现明显的复制积压。不过当所有节点同时进行压缩任务时，网络流量会出现周期性峰值，建议在业务低峰期执行压缩，或者使用 nodetool compactionstats 监控压缩进度。另外 Google Cloud 的 VPC 网络支持 Jumbo Frame，开启后 MTU 可达 8896 字节，能够减少分片带来的 CPU 开销，我们实测开启 Jumbo Frame 后吞吐量提升了约 8%。
故障恢复与高可用验证
为了验证 Google Cloud 环境下 Cassandra 的故障转移能力，我们模拟了单节点宕机和磁盘满两种故障场景。首先使用 gcloud compute instances stop 强制关闭其中一个节点，观察集群状态。在默认的 phi_convict_threshold 为 8 的情况下，其余节点约在 15 秒后将该节点标记为 down，客户端写请求在短暂的重试后全部成功，没有丢失数据。重新启动节点后，Hinted Handoff 机制自动补发了停机期间错过的写入，数据最终一致。
磁盘满测试则通过向数据目录写入大量无关文件模拟。当磁盘使用率达到 90% 时，Cassandra 仍能正常处理读请求，但写入会被拒绝并抛出 NoSpaceLeftOnDevice 异常。清除文件后集群自动恢复，但需要手动执行 nodetool repair 来修复可能的不一致数据。这个测试暴露出 Google Cloud pd-ssd 磁盘在容量告警方面不如本地磁盘直观，建议配置 Stackdriver 监控磁盘使用率并设置 85% 的告警阈值。
跨区域灾备方面，Google Cloud 提供了区域持久化磁盘和快照功能。我们使用 gcloud compute disks snapshot 对数据盘进行每日快照，并将快照复制到另一个区域。恢复时从快照创建新磁盘挂载到新节点，再通过 nodetool removenode 移除旧节点即可完成整个集群的迁移。整个演练过程在 1 小时内完成，数据丢失为 0，证明 Google Cloud 的底层存储快照与 Cassandra 的分布式架构可以很好地配合。
成本评估与优化建议
从成本角度看，运行三节点 n2-standard-8 集群，每台实例按需价格约为 0.388 美元/小时，合计每月约 840 美元；三块 500 GB 的 pd-ssd 磁盘每月约 255 美元；网络出口流量和其他杂项费用约 50 美元。总成本约 1145 美元/月。如果使用承诺使用折扣或抢占式实例（仅适用于非生产环境），成本可以降低 40% 至 60%。对于数据量不超过 500 GB 的中型应用，这个成本与托管的 Cloud Bigtable 基本持平，但 Cassandra 提供了更灵活的数据模型和本地部署的可移植性。
为了进一步优化成本，建议采用分层存储策略。将 commitlog 放在 pd-ssd 上，而将不常访问的旧 SSTable 迁移到 pd-balanced 或 Cloud Storage 的冷存储层。Cassandra 4.1 支持 tiered_storage 扩展，可以通过配置不同的存储策略实现冷热数据分离，但需要评估读取路径的复杂度。另外关闭 incremental_backups 改用定期快照可以减少约 10% 的存储写入放大。
监控方面，Google Cloud 的 Monitoring 服务可以采集 Cassandra 的 JMX 指标。我们部署了 jmx_exporter 将指标导出到 Prometheus，再通过 Google Cloud Monitoring 展示，重点监控 org.apache.cassandra.metrics:type=ClientRequest,scope=Write,name=Latency 和 org.apache.cassandra.metrics:type=Storage,name=Load。当 p99 写延迟连续 5 分钟超过 50 ms 或磁盘使用率超过 85% 时触发告警，确保运维人员能及时介入。
Google CloudCassandra云服务器修改时间：2026-09-22 02:14:57