Linux Cassandra集群规划与硬件、网络、系统调优最佳实践

一、集群规模规划：从业务需求到节点数计算

1.1 规划核心输入指标

集群规划前，必须收集以下业务指标（建议与开发、产品共同评估）：

• 当前/峰值数据量：总存储大小（含副本）
• 预计增长率：年增长倍数或每日增量
• 读写QPS：峰值读/写比例（Cassandra写强于读）
• 行大小与查询模式：平均行宽（宽表常见数百KB）、热点比例
• 一致性要求：QUORUM还是ONE
• TTL与删除频率：影响墓碑与Compaction
• 多DC需求：跨区域复制流量

1.2 容量规划公式

单节点有效存储容量 = 物理磁盘容量 × (1 - 预留比例) / RF（复制因子）

• 预留比例：50%（Compaction、临时空间、OS）
• 示例：单节点3×10TB HDD，RF=3 → 有效容量 ≈ 30TB × 0.5 / 3 = 5TB

集群节点数 ≈ (总数据量 × RF × 1.5安全系数) / 单节点有效容量

• 安全系数1.5-2：考虑增长、Compaction峰值

性能维度节点数 ≈ max(容量需求节点数, QPS需求节点数)

• 单节点写QPS基准：NVMe环境 5-10w QPS（简单键值）
• 读QPS：取决于Compaction策略，LCS下更稳定

生产案例：

• 业务：日志系统，日增1TB，RF=3，保留30天，总数据30TB
• 硬件：每节点20TB有效（40TB原料）
• 节点数：30TB × 3 × 1.5 / 20TB ≈ 7节点（起步）

1.3 集群规模分级建议

建议：从奇数节点起步（QUORUM=(RF//2)+1 更易达成）

二、硬件选型最佳实践

Cassandra对硬件敏感度：磁盘 > CPU > 内存 > 网络

2.1 CPU选型

• 推荐：AMD EPYC 或 Intel Xeon Scalable（高主频、高缓存）
• 核心数：32-64核/节点（Compaction、Streaming多线程）
• 避免低频节能CPU（GC与协调延迟敏感）

5.0 Trie结构下，CPU利用率更低，可适当降低核心数节省成本。

2.2 内存选型

• 容量：64-256GB/节点
• Heap分配：不超过32GB（推荐16-24GB）
• 剩余内存：留给OS Page Cache（SSTable读取）、offheap Memtable

公式：总内存 ≥ Heap + offheap_memtable + OS(10GB+) + 缓冲

2.3 磁盘选型（最关键）

Cassandra顺序写+随机读，磁盘决定上限。

黄金方案：

• CommitLog：2-4块NVMe RAID0（纯顺序写）
• Data：8-16块NVMe/SATA JBOD（不RAID，Cassandra自管理故障）
• 避免RAID5/6（写惩罚大）

生产推荐配置（单节点）：

• 高性能：64核CPU + 128GB内存 + 8×3.84TB NVMe（有效~15TB）
• 性价比：32核 + 64GB + 12×4TB SATA SSD

2.4 网络选型

• 带宽：万兆必备，25G/100G更佳（Streaming、Repair流量大）
• 延迟：<1ms（同DC）
• 双网卡Bonding（bond0）

云环境：

• AWS：i4i/m6i实例 + EBS gp3
• GCP：n2-highmem + Local SSD
• 阿里云：i3实例 + ESSD PL3

三、网络规划与调优

3.1 网络流量估算

• 正常读写：客户端流量
• 内部流量：
• Gossip：微量
• Repair：峰值数百MB/s
• Streaming（扩容）：GB/s级
• Hinted Handoff：宕机时爆发

估算：内部流量 ≈ 正常流量 × 2-5

3.2 网络调优实践

• 启用Jumbo Frame（MTU 9000）
• TCP调优（在sysctl.conf）：

net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.optmem_max = 16777216
net.core.somaxconn = 65535

• 云环境关闭Offload（TSO/GRO有时bug）

3.3 多DC网络注意

• 跨DC带宽评估：复制流量 = 写QPS × 行大小 × (DC数-1)
• 使用LOCAL_QUORUM降低跨DC读

四、Linux系统调优完整指南

4.1 文件系统选择

• XFS（生产首选）：支持reflink（Snapshot快）、高性能
• ext4：兼容性好，但大文件慢
• 挂载选项：

noatime,nodiratime,barrier=0

4.2 内核参数完整模板（/etc/sysctl.conf）

# 文件句柄
fs.file-max = 2097152
fs.nr_open = 2097152

# 内存管理
vm.swappiness = 1          # 几乎禁用swap
vm.zone_reclaim_mode = 0
vm.overcommit_memory = 1
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
vm.dirty_expire_centisecs = 3000

# 关闭透明大页（Cassandra GC敏感）
vm.transparent_hugepage = never

# 网络
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_congestion_control = htcc
net.ipv4.tcp_max_syn_backlog = 65536

# IO调度
# NVMe用none，SATA用mq-deadline

执行 sysctl -p

4.3 limits.conf

cassandra soft nofile 2097152
cassandra hard nofile 2097152
cassandra soft nproc 65536
cassandra hard nproc 65536
cassandra soft memlock unlimited
cassandra hard memlock unlimited

4.4 其他系统调优

• 关闭NUMA balancing：echo 0 > /proc/sys/kernel/numa_balancing
• 时间同步：chronyd + 内网NTP
• 禁用SELinux/AppArmor（或自定义规则）

五、JVM调优（cassandra-env.sh补充）

MAX_HEAP_SIZE="16G"
HEAP_NEWSIZE="4G"

JVM_OPTS="$JVM_OPTS -XX:+UseG1GC"
JVM_OPTS="$JVM_OPTS -XX:G1RSetUpdatingPauseTimePercent=5"
JVM_OPTS="$JVM_OPTS -XX:+ParallelRefProcEnabled"
JVM_OPTS="$JVM_OPTS -XX:+UnlockExperimentalVMOptions"
JVM_OPTS="$JVM_OPTS -XX:InitiatingHeapOccupancyPercent=45"

# 5.0推荐
JVM_OPTS="$JVM_OPTS -Dcassandra.memtable_offheap_space=24G"

监控GC：nodetool proxyhistograms + jstat

六、生产常见坑

1. IO瓶颈 → 原因：CommitLog与Data同盘 → 解决方案：分离NVMe
2. GC暂停长 → 原因：Heap>31GB + THP启用 → 解决方案：限16G + disable THP
3. 网络风暴 → 原因：Repair不限速 → 解决方案：nodetool setcompactionthroughput白天限64MB/s
4. 容量预估不足 → 墓碑/Compaction临时空间爆炸 → 预留50%+