4.1 部署与配置
4.1 部署与配置
本节摘要：生产部署核心：GossipingPropertyFileSnitch + NTS、每 DC 2–3 seed、堆内存通常 ≤8GB 并配 G1GC、数据与 CommitLog 分盘。SOURCE 4.1 强调
endpoint_snitch与cassandra-rackdc.properties必须一致。
本节目标
阅读完本节，你应当能够：
- 列出
cassandra.yaml中 10 个关键参数及含义 - 配置多 rack/DC 的 rackdc 文件
- 说明 seed 节点数量与放置原则
- 对比 K8ssandra/VM 裸机部署差异
一、问题与直觉
开发环境 SimpleSnitch + 单节点能跑；上生产后跨 AZ 副本全落同一 logical rack——一次交换机故障丢 QUORUM。Mongo replica set 也要配 priority 与 zone；HBase 需 rack-awareness。Cassandra 把拓扑感知放在 Snitch + yaml/properties 双文件，漏配一行，复制策略就是假的。
二、核心原理
最小生产清单：
| 参数 | 建议 | 说明 |
|---|---|---|
cluster_name |
唯一 | 防误 join |
seeds |
每 DC 2–3 固定 IP | 非 Master |
endpoint_snitch |
GossipingPropertyFileSnitch | 生产默认 |
num_tokens |
256 vnodes | 4.x 默认 |
commitlog_directory |
独立 SSD | 与 data 分盘 |
data_file_directories |
多磁盘 JBOD | 提高顺序写 |
concurrent_reads/writes |
按核数调 | 默认 32/32 |
# cassandra-rackdc.properties（每节点） dc=dc-east rack=rack2 prefer_local=true
# cassandra.yaml 片段 endpoint_snitch: GossipingPropertyFileSnitch seed_provider: - class_name: org.apache.cassandra.locator.SimpleSeedProvider parameters: - seeds: "10.0.1.10,10.0.1.11"
JVM：Cassandra 4.x 官方推荐 G1GC，堆 不超过 8GB（更大堆 → GC 停顿伤 Gossip/CL 超时）。堆外承担 Bloom、Key Cache、CommitLog buffer。
容器：K8ssandra Operator 注入 rack/zone label 映射 Snitch；注意 StatefulSet 稳定 network ID 与 persistent volume。
三、工程实践要点
操作系统：nofile ≥ 100000；禁用 swap 或 memlock_all: true。
防火墙：7000（internode）、9042（CQL）、9160（legacy）策略化开放。
与 MongoDB：mongod 同样要 replica set name、oplog 尺寸；Cassandra 无 oplog，靠 CommitLog + repair。
⚠️ 常见坑：克隆 VM 不改
cluster_name与listen_address——两集群 Gossip 互串。
💡 关键直觉：部署文件是复制策略的物理实现——Snitch 错 = NTS 假。
本章回顾
- Snitch + rackdc + NTS 三位一体
- seed 仅 bootstrap，2–3/DC
- CommitLog/data 分盘，JVM 堆克制
- G1GC + 4.x 是现行 baseline
- K8ssandra 需显式 zone→rack 映射
下一节讨论加节点 streaming 与 repair 周期。
演练：最小生产集群部署
以 3 节点单 DC 为例，从配置到验收的完整步骤：
# 三个节点分别配置，cluster_name 必须完全一致 cluster_name: 'prod-sensor' listen_address: 10.0.1.10 # 本节点 IP，节点间通信用 rpc_address: 10.0.1.10 # 客户端连接地址 seed_provider: - class_name: org.apache.cassandra.locator.SimpleSeedProvider parameters: - seeds: "10.0.1.10,10.0.1.11" endpoint_snitch: GossipingPropertyFileSnitch
# 每节点 cassandra-rackdc.properties dc=dc-east rack=rack1
# 全部启动后，在任意节点验收 nodetool status # 三个节点均为 UN，Load 基本均匀 → 部署成功
部署顺序注意事项：先启动 seed 节点，等它进入 UN；再逐个启动其余节点。若新节点始终处于 BN（Bootstrap）状态，检查 Gossip 端口是否互通、seed 列表是否一致。
关键 yaml 参数详解
| 参数 | 默认 | 说明 | 典型调整 |
|---|---|---|---|
concurrent_reads |
32 | 读线程池 | 按 CPU 核数上调 |
concurrent_writes |
32 | 写线程池 | 高写入集群调大 |
commitlog_sync |
periodic | 日志落盘策略 | 追求低丢可改 batch |
memtable_heap_space_in_mb |
2048 | 堆内 MemTable 预算 | 与堆大小联动 |
auto_snapshot |
true | 变更前自动快照 | 大变更建议开启 |
stream_throughput_outbound_megabits_per_sec |
200 | 出站 streaming 限速 | 扩容时调低保业务 |
# 高写入 IoT 场景的典型调优片段 concurrent_writes: 128 concurrent_reads: 64 compaction_throughput_mb_per_sec: 32
部署后健康检查清单
# 六连检查，一次跑完 nodetool status # 1. 全 UN nodetool ring # 2. token 均匀 nodetool describecluster # 3. 各节点 schema/版本一致 nodetool gossipinfo # 4. Gossip 视图正常 nodetool tpstats | head -20 # 5. 无 Dropped Mutations cqlsh -e "SELECT * FROM system.local" # 6. CQL 端口可达
这六项覆盖了 Gossip（控制平面）、ring（数据平面）、schema（元数据）、线程池（负载平面）四个维度。任何一项异常都应在接流量前修复——上线后再修，就是带着故障救火。
磁盘与操作系统层
# 检查文件句柄与调度器（部署前置条件） ulimit -n # 应 >= 100000 cat /sys/block/nvme0n1/queue/scheduler # 现代 NVMe 用 none
# fstab / 挂载选项：noatime 减少元数据写 /dev/nvme0n1 /var/lib/cassandra xfs defaults,noatime 0 0
| 层 | 推荐 | 理由 |
|---|---|---|
| 文件系统 | XFS / ext4（noatime） | 适配大文件顺序写 |
| 调度器 | none / noop | 避免重排序延迟 |
| CommitLog 盘 | 独立 SSD | 与 data 分离防争抢 |
| swap | 关闭或 memlock | 避免 JVM 堆换页 |
# 验证 swap 状态 free -h | grep -i swap # 关闭 swap（如需永久关闭改 /etc/fstab） swapoff -a
磁盘是 Cassandra 最容易被低估的组件：SSTable 顺序写、Compaction 随机归并、CommitLog 顺序 append，三种 I/O 模式混在同一盘上会互相拖累。生产标准做法是 CommitLog 与 data 物理隔离，条件允许时把 compaction 目录单独挂载。