如何用一致性哈希避免3台服务器扩展到100台的数据大迁移？

当你的系统从3台服务器扩展到100台，如何保证数据不会大规模迁移？一致性哈希给你答案。 🤔 从一个问题说起 假设你开了一家外卖店，有 3 个送餐员。每次来订单，你要决定让谁去送。 简单办法：订单号除以 3，余数是 0 给 1 号，余数是 1 给 2 号，余数是 2 给 3 号。 int serverIndex = key.GetHashCode() % 3; 看起来不错？但问题来了： 某天 3 号请假了，只剩 2 个人 当外卖单子增多，需要扩编到 4 个送餐员 这时几乎所有单子都需要重新分配！ 在计算机里也一样：你有3台服务器存数据,突然一台挂了，如果用简单取模的方法，几乎所有数据都要重新分配，非常麻烦。 💡 一致性哈希的优雅解决方案 一致性哈希通过一个简单而巧妙的思路解决了这个问题： 核心思想 想象一个圆形的钟表，但刻度不是 1-12，而是从 0 到 2³²-1 的一个巨大的数字： 把服务器放到环上：每个服务器通过哈希计算得到一个位置 把数据也放到环上：数据key也通过哈希得到一个位置 顺时针查找：从数据位置顺时针走，遇到的第一个服务器就负责存储这个数据 为什么这样好？ 当一台服务器下线： 只有这台服务器负责的数据需要迁移 其他数据完全不受影响 数据迁移量 ≈ 1/N（N为服务器总数） 当增加一台服务器： 只会分担相邻服务器的部分数据 影响范围可控 🎯 虚拟节点优化 直接使用一致性哈希有个问题：服务器在环上的分布可能不均匀，导致负载不均衡。 解决方案：为每个真实服务器创建多个虚拟节点（通常150-200个） 服务器A → 虚拟节点：A-VN0, A-VN1, A-VN2, ..., A-VN149 服务器B → 虚拟节点：B-VN0, B-VN1, B-VN2, ..., B-VN149 这样可以让节点在环上分布更加均匀，负载更加平衡。 👨‍💻 C#实现 下面是一个精简版的C#实现： 🚀 使用示例 📊 性能测试结果 对1000条数据进行测试： 初始分布（3台服务器）： NodeA : 125 条数据 (12.50%) ██████ NodeB : 255 条数据 (25.50%) ████████████ NodeC : 620 条数据 (62.00%) ███████████████████████████████ 移除服务器B后： 需要迁移的数据: 255/1000 (25.50%) 理论值: 约 33.33% (因为移除了1/3的节点) 添加服务器D扩容后（3台服务器）： NodeA : 237 条数据 (23.70%) ███████████ NodeC : 400 条数据 (40.00%) ████████████████████ NodeD : 363 条数据 (36.30%) ██████████████████ 🎓 应用场景 一致性哈希在以下场景中广泛应用： 分布式缓存：Redis、Memcached集群 分布式存储：Amazon DynamoDB、Cassandra 数据分片：数据库水平分表 🔗 完整代码 本文的完整示例代码已上传至GitHub。 GitHub地址： https://github.com/denglei1024/ConsistentHashingDemo.git 📝 总结 一致性哈希是分布式系统中的经典算法，通过"环+虚拟节点"的设计巧妙地解决了动态伸缩带来的数据迁移问题。 下次当你的系统需要扩容时，别忘了一致性哈希这个利器！ 💪 如果觉得有帮助，欢迎点赞！🙏