手机号作为Scylla主键是否会引发集群节点读写操作倾斜？

核心结论 #

Scylla会先对**分区键（即你这里的long类型主键）**执行哈希运算，再将哈希结果映射到集群的token范围分配数据分片，因此理论上不会因原始主键值的分布倾斜直接导致节点间读写操作倾斜。

具体机制说明 #

Scylla采用MurmurHash3哈希函数处理分区键，生成64位token值。集群的整个token范围会被均匀分割给各个节点，每个节点负责处理落在自身token范围内的所有数据请求：

• 即便你的手机号主键集中在9-12位，只要这些数值本身具备足够多样性（比如手机号前缀、后缀的差异），MurmurHash3会将它们映射到均匀分布的token值上，最终数据和请求会均衡分散到3个节点。
• 只有当大量不同分区键哈希后恰好落到同一个token范围时，才会出现节点负载倾斜，但这种情况在手机号这类具备多样性的输入场景下概率极低。

节点操作突增的可能原因 #

你观察到的某节点操作量突增，更可能是以下因素导致：

• Spark作业写入分区不均：如果Spark任务的某个RDD/DataFrame分区包含远多于其他分区的数据，该分区的写入请求会集中发送到对应的Scylla节点，短期拉高操作量。
• 短期概率性波动：即使整体哈希分布均匀，某一时间段内的写入请求哈希结果可能偶然集中到某个节点的token范围，导致临时负载突增。
• 节点本地任务干扰：比如该节点正在执行compaction（数据压缩）、repair（数据修复）等后台任务，这些操作会占用节点资源，表现为操作量突增。
• 注意：由于你的集群是3节点+RF=3，每个分区的副本会分布在所有3个节点，正常情况下每个写入请求都会触发3个节点的写入操作，节点负载应该基本一致。若出现明显差异，更要优先排查上述非哈希分布的原因。

排查与验证步骤 #

• 查看Scylla监控面板，重点关注各节点的读写请求QPS、分区数量分布、pending compaction任务数，确认是持续性负载倾斜还是临时波动。
• 检查Spark作业的任务执行日志，查看各写入分区的数据量大小，判断是否存在Spark端的数据倾斜。
• 抽样一批实际使用的手机号，手动计算其MurmurHash3哈希值对应的token，对比集群各节点的token范围，验证哈希后的分布是否均匀。

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