Cassandra Nodetool Status显示Owns为?的原因及数据分片疑问

首先把你执行nodetool status的输出整理成清晰的代码块：

Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address       Load       Tokens  Owns (effective)  Host ID                               Rack
UN  10.30.27.172  202.52 KiB  1       ?                 2300ea95-9114-4c03-819e-2c738de50824  rack1
UN  10.30.27.173  205.97 KiB  1       ?                 d35063fe-2e81-4ab0-95ec-7024c9606b51  rack1
UN  10.30.27.171  222.02 KiB  1       ?                 0f96a91b-77fb-4d49-ae87-ad9f61facb6b  rack1

Note: Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless

一、为什么Owns列显示为? #

你看输出末尾的提示已经点明了核心原因：非系统keyspace的复制配置不一致。

Cassandra的Owns列本应显示节点对集群数据的有效所有权比例，但这个计算有个前提——所有keyspace使用相同的复制策略和复制因子。当你创建的多个自定义keyspace，有的用SimpleStrategy、有的用NetworkTopologyStrategy，或者同策略但复制因子不同时，每个keyspace的数据分布逻辑完全不一样，Cassandra没法生成一个统一的所有权比例，只能用?表示这个值无意义。

哪怕你能在其他节点看到数据，这只是说明复制机制在正常工作，但所有权比例的计算因为多keyspace配置差异而无法完成。如果想看到正常的Owns值，要么统一所有非系统keyspace的复制配置，要么针对单个keyspace查看，比如执行nodetool status <你的keyspace名称>，就能看到该keyspace下每个节点的有效所有权了。

二、Cassandra集群的数据分片机制 #

Cassandra的分片逻辑核心是Token范围划分和Partition Key哈希路由，具体流程可以拆解为这几步：

• Token分配：整个集群的哈希空间是-2^63到2^63-1的64位整数范围（默认用Murmur3哈希生成），每个节点会被分配一段或几段连续的Token范围。你这里每个节点只有1个Token，属于小集群常用的单Token配置。
• 数据路由：写入数据时，Cassandra会对数据的Partition Key做哈希计算，得到一个对应Token。这个Token会落在某个节点负责的范围内，这个节点就是该数据的协调器节点。
• 复制存储：协调器节点会根据当前keyspace的复制策略，把数据复制到指定数量的节点上（比如复制因子为3时，会存到Token对应的主节点以及后续的两个节点，具体节点选择由复制策略决定）。
• 数据读取：读取时，协调器同样通过Partition Key的哈希找到对应Token范围，从负责该范围的节点（或其副本）获取数据后返回给客户端。

简单来说，Cassandra用Token把整个数据哈希空间切成不同片段，每个节点负责一部分片段，数据根据Partition Key的哈希值被分配到对应片段的节点，再通过复制策略保证数据的高可用性。

内容的提问来源于stack exchange，提问作者Mahesh Patil