Cassandra 之所以能够在生产环境中执行扩容和缩容而不中断请求，根源在于它没有主从结构，也没有中心节点。集群里的每个节点在数据读写路径上都是对等的，数据通过分区键经过 MurmurHash 计算后落到一个 64 位哈希值，再映射到令牌环上的某个区间。新节点加入时，并不会影响整个集群的元数据，只会从相邻节点拉取属于自己令牌区间的数据；客户端驱动通过查询系统表感知拓扑变化，后续请求会自动路由到新节点。因此，不停机扩缩容不是某个特殊开关，而是一套由架构特性和运维命令共同支撑的常规动作。
一、不停机扩容的核心依据：令牌环与vnode
理解扩缩容为什么可以在线进行，首先要看 Cassandra 的数据分布方式。集群使用一致性哈希把整个哈希值空间组织成一个环形，每个节点负责环上的一段区间。客户端写入时，协调节点根据分区键的哈希值找到第一个副本所在的节点，并按照复制策略把数据同步到其他副本节点。这种设计意味着，当集群成员发生变化时，只有与新增或移除节点相邻的令牌区间需要重新分配数据，其余大部分节点完全不受影响。
早期 Cassandra 默认每个节点只有一个令牌，新增物理节点需要重新计算连续区间，容易造成数据倾斜和迁移压力集中。vnode 机制改变了这一局面，它把每个物理节点划分为多个虚拟节点，例如 num_tokens: 16，这些虚拟节点随机分布在整个令牌空间。新节点加入后，多个现有节点可以同时向它传输数据，迁移任务被拆得很细，吞吐更高，同时对正常请求的干扰更小。生产环境建议保持 num_tokens 为 16 或根据节点规模调优，不要频繁修改，否则会触发不必要的令牌重分配。
需要注意的是，vnode 并不改变数据副本数量，它只是影响令牌分配粒度。副本数量仍然由 replication_factor 决定，扩缩容时如果副本策略没有变化，每个分区的副本份数不变，只是副本所在的物理节点发生了转移。因此正确设置客户端一致性级别，比如使用 QUORUM 或 LOCAL_QUORUM，可以在迁移期间继续获得一致且可用的读写结果。
二、在线扩容的标准操作流程
扩容操作并不复杂，但要求准备充分。新节点需要安装与集群完全相同的 Cassandra 版本，避免因版本差异导致流式传输协议不兼容。系统层面要配置好主机名解析、防火墙放行 7000 和 7001 端口用于节点间通信，放行 9042 端口用于客户端访问，放行 7199 端口用于 JMX 管理。磁盘、内存和 JVM 堆设置也应与现有节点保持一致，否则容易出现数据分布正常但性能明显偏慢的情况。
接下来修改新节点的 cassandra.yaml，关键是 cluster_name、种子节点、监听地址和 snitch 必须正确。下面是一个典型配置片段：
cluster_name: 'CassandraCluster'
num_tokens: 16
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "10.0.0.11,10.0.0.12"
listen_address: 10.0.0.13
broadcast_address: 10.0.0.13
rpc_address: 0.0.0.0
endpoint_snitch: GossipingPropertyFileSnitch
listen_address 和 broadcast_address 要填节点自己的 IP，seeds 中至少保留两个现有集群种子节点，但不能把所有节点都写成种子，否则拓扑信息传播会变得混乱。启动前先清理数据目录，确保没有残留的 system 表，然后执行启动命令，例如 sudo systemctl start cassandra。启动后运行 nodetool status 可以看到新节点的状态先变为 UJ，表示正在加入集群，随后数据开始流式传输。
nodetool status nodetool ring nodetool netstats
迁移期间可以通过 nodetool netstats 查看流式传输会话和进度，正常情况下会有多个会话并行搬运数据。不要在迁移未完成时重复执行其他变更操作。当新节点状态变为 UN 后，还需要在旧节点上执行 nodetool cleanup。因为扩容过程中旧节点不再负责的令牌区间上的数据副本不会自动删除，cleanup 会清除这些冗余数据，避免磁盘膨胀和后续读修复负担。如果漏掉 cleanup，集群不会报错，但会长期保留多余副本，浪费存储空间。
三、在线缩容：decommission与removenode
缩容相比扩容更需要注意数据安全。Cassandra 提供两种主要方式：decommission 和 removenode。当节点状态正常，只是计划内下线时，应该优先使用 decommission。它会先把这个节点负责的令牌区间迁移到其他副本节点，等所有数据搬完以后再让节点退出集群。整个过程对客户端是透明的，读写请求会被协调节点转发到新的副本位置。
执行方式是在要下线的节点上运行：
nodetool decommission
如果数据量较大，这个过程可能持续数小时。期间该节点的状态会从 UN 变为 UL，表示正在离开集群。不要在同一个集群同时执行多个节点的 decommission，否则可能因为副本迁移目标不足而降低可用性。等待 nodetool status 中该节点消失或状态变为 DN 后，就可以关闭进程并回收机器。
如果节点已经故障，无法正常执行 decommission，则需要使用 removenode。先通过 nodetool status 找到故障节点的 Host ID，然后在任意健康节点上执行：
nodetool status nodetool removenode <host_id>
removenode 会从集群中强制摘除指定节点，并安排其他节点补齐副本。之所以强调要确认 Host ID 而不是 IP，是因为 IP 可能被新节点复用，而 Host ID 是每个节点的唯一标识。不到万不得已不要使用 assassinate，它会绕过一些安全步骤，只在节点处于异常且 removenode 长期卡住时考虑。缩容完成后同样需要在剩余节点执行 nodetool cleanup，清理不再需要的旧副本。
四、扩缩容期间的监控与验证
不停机扩缩容成功与否，取决于操作过程中对集群状态的持续观察。最常用的命令是 nodetool netstats，它显示当前节点正在进行的流式传输会话、已传输字节数和进度。如果长时间没有进度，可能是网络带宽限制、磁盘 IO 打满或跨机房延迟导致，需要先排查基础资源。此外 nodetool tpstats 可以查看线程池的阻塞情况，nodetool compactionstats 可以确认压缩任务是否因为数据迁移大量堆积。
nodetool netstats nodetool tpstats nodetool compactionstats nodetool describecluster
从客户端角度看，扩缩容期间可能会出现少量请求超时，尤其是在副本数据正在搬移、读修复被触发时。此时不建议把一致性级别临时调低，例如从 QUORUM 降到 ONE，虽然能减少失败，但可能返回旧数据或造成数据不一致。更合理的做法是保持原有级别，并确认驱动配置了重试和节点状态刷新机制。多数驱动会定期读取系统表感知节点上下线，不会把请求持续发往已离线节点。
最终验证时，运行 nodetool ring 查看令牌分布是否均匀，确认没有节点负担明显过高；运行 nodetool status 确认所有节点状态为 UN，且没有异常状态。对于关键业务表，可以在扩缩容完成后做一次读写抽样检查，也可以使用 nodetool repair 对变化较大的表做修复，但要注意 repair 需要占用资源，建议低峰执行。只要配置正确、步骤完整，并保留操作前的快照或元数据备份，Cassandra 的扩缩容就能在业务无感知的情况下完成。
Cassandra扩缩容不停机方案nodetool修改时间：2026-09-24 04:12:58