浅析Cassandra扩容

浅析Cassandra扩容

前言

Cassandra是一款非常优秀的分布式数据库，可以灵活的在线扩容，满足业务水平扩展的需求。本文将会详细阐述扩容中可能遇到的问题，帮助Cassandra用户更好的管理Cassandra。

扩容原理

Cassandra采用一致性Hash算法对数据进行分区打散。

上图不同颜色代表不同节点，每个节点会有虚拟节点在环上(图示每个节点有3个)，具体有多少个虚拟节点，取决于这个配置：

num_tokens: 256

这个值不能调得太低，不然虚拟节点不够容易出现数据倾斜。

Cassandra称这些虚拟节点为Token，Token就是一个长整型数。2个Token之间构成一个左开右闭的区间（Range），落在这个区间内的数据都归右边界的Token所对应的节点管理（数据会用同样的Hash算法得到一个长整型值映射到环上）。比如:(100，200]，200这个Token属于NodeA，那么(100，200]上的数据都归NodeA管理。

数据迁移

很明显扩容后加入了新的Token，会产生新的Range，这些Range中的一部分会归新节点管理。那么就需要把数据从旧节点迁移到新节点上去。

新节点会从旧节点上去拖数据过来，这时候节点状态会处于JOINING。可以通通过nodetool netstats查看到节点状态。更准确的开始标志可以通过搜索日志，日志中会出现如下这么一行内容：

Starting to bootstrap...

整个迁移过程完成后，节点会进入NORMAL状态，同样可以通过上述命令查看。整个数据传输过程，是通过Cassandra点对点之间的Streaming传输协议进行数据流传输。这里主要有2个参数控制传输速度，大家可以根据实际硬件&业务情况配置，避免影响在线服务。

# 控制整体数据流速度 200MB/S

stream_throughput_outbound_megabits_per_sec: 200

 

# 控制数据中心间的数据流速度。这个配置超过上面那个没有作用，因为上面是整体控制，也就是上界。

inter_dc_stream_throughput_outbound_megabits_per_sec: 200

扩容操作建议

扩容过程需要一台一台操作，并通过nodetool netstats确认进入NORMAL状态后，再操作下一台，不然你可以会遇到下面这个异常，导致启动失败。

Other bootstrapping/leaving/moving nodes detected, cannot bootstrap while cassandra.consistent