数据库哈希怎么扩容

数据库“哈希扩容”通常指 基于哈希的分区 / 分片（Hash Partitioning / Sharding）在节点或容量不足时，如何平滑扩展。这是分布式数据库和大规模存储系统里非常经典的问题。

下面按 常见场景 → 核心问题 → 主流方案 来讲。

一、为什么哈希扩容难？

如果是简单的 取模哈希：

hash(key) % N

一旦节点数 N 从 4 变成 5：

• 绝大多数 key 的映射位置都会变
• 大量数据需要迁移
• 扩容成本高、容易出现抖动

所以核心目标是：

扩容时尽量少迁移数据，并且系统能持续服务

二、常见哈希扩容方案

1️⃣ 一致性哈希（Consistent Hashing）✅ 最常用

原理

• 把哈希空间看成一个 0 ~ 2^32 的环
• 节点和数据都映射到环上
• 数据归属：顺时针找到的第一个节点

扩容时

• 只影响 新节点到前一节点之间的数据
• 其他节点数据不动

优点

• 扩容/缩容只迁移少量数据
• 工程上非常成熟（Redis、Cassandra、Dynamo）

缺点

• 数据可能不均匀
• 常配合 虚拟节点（Virtual Node） 解决

Node A → 100 个虚拟节点
Node B → 100 个虚拟节点

2️⃣ 哈希 + 映射表（目录层）✅ 可控性强

原理

key → hash → 逻辑桶(bucket)
bucket → 物理节点（查表）

扩容时：

• 只把部分 bucket 迁移到新节点
• 映射表更新即可

优点

• 扩容灵活、可控
• 适合企业级数据库

例子

• HBase（Region 分裂）
• TiDB（Region + PD）
• MongoDB（chunk 迁移）

3️⃣ 范围哈希 / 组合哈希

hash(key) → range → node

• 哈希只是为了减少热点
• 实际用 范围分片
• 扩容时按 range 切分

适合：

• 时间序列数据
• 日志类数据

4️⃣ 预分区（提前留余量）

做法

• 一开始分 1024 / 4096 个槽（slot）
• 节点只是“认领”槽

扩容

• 把部分 slot 迁移过去

典型例子

• Redis Cluster（16384 slots）
• Kafka partition

✅ 这是目前最推荐的做法之一

5️⃣ 在线重哈希（不推荐但存在）

• 双写新旧哈希
• 逐步迁移
• 读时兼容

缺点：

• 实现复杂
• 容易出一致性问题

三、扩容时的关键问题

✅ 数据迁移

• 增量 + 存量
• 限速、限流
• 避免影响线上

✅ 一致性

• 迁移中读旧还是新？
• 是否允许短暂不一致？

✅ 热点

• 某些 key 特别热
• 需要 二级哈希 / 局部打散

四、选型建议（直接结论）

五、一句话总结

数据库哈希扩容，不要直接改 % N，要用一致性哈希、slot 或映射表，做到“少迁移、可在线、可控”。

如果你能告诉我：

• 用的是哪种数据库（MySQL / Redis / 自研）
• 是单表分区还是分布式

我可以直接给你 具体扩容方案 + 示例。