一致性哈希通过固定哈希空间（如2^32）构建环形结构，节点和数据映射其上并顺时针就近分配；增删节点仅影响邻近区间，大幅减少数据迁移；引入虚拟节点可缓解物理节点分布不均问题，提升负载均衡性。
直接用 hash_ring 库最省事，但真要自己写、调参或排查分布不均问题，必须理解虚拟节点数量、哈希函数输出范围、环结构更新时机这三个关键点。
为什么简单取模（hash(key) % N）在节点变动时会崩
节点从 3 台扩到 4 台，所有 key 的余数结果几乎全变——原来落在节点 0 的 key，现在可能落到 1、2、3 任意一个。缓存命中率瞬间归零，DB 瞬间被打爆。一致性哈希把“除数”固定为 2**32 或 2**160，节点只是环上的几个点，增减只影响邻近一小段 key 的归属。
- 实际影响范围 ≈
（被移除/新增节点的哈希值区间长度） / 2^32 - 没加虚拟节点时，3 台物理节点在环上可能挤在同一个象限，导致 90% 的 key 全打到一台机器上
- 只要哈希函数输出不是均匀分布（比如用
hash()内置函数，Python 3.3+ 默认启用 hash 随机化），环就天然倾斜
hashlib.sha1 和 hashlib.md5 在一致性哈希中的实际差异
两者都输出 160 位或 128 位整数，足够覆盖 2**32 环；但真正影响分布的是「截断方式」和「字节序处理」。别直接用 int(hashlib.sha1(b'node1').hexdigest()[:8], 16) ——前 8 位十六进制刚好是 32 位，但 hexdigest() 是大端，而很多 C 实现默认小端，混用会导致环上节点扎堆。
- 推荐统一用
int.from_bytes(hashlib.sha1(b'node1').digest()[:4], 'big')，明确取前 4 字节、大端解析 - 避免用
hash()：它在不同 Python 进程/版本中结果不一致，跨服务无法对齐哈希环 - MD5 虽快一点，但 SHA1 抗碰撞更强；不过在内部服务调度场景，二者实际效果差别极小
虚拟节点数量（replicas）设多少才不浪费又不倾斜
Temporal SDK 默认用 100，Redis 官方客户端常见设 160，但这个数不是越大越好：每增一个 replica 就多一次哈希计算 + 环上一次插入，100 个 replica 对 10 个物理节点，环大小就是 1000，二分查找开销可控；但设到 1000，环大小破万，bisect 查找变慢，内存占用翻倍，而分布改善几乎停滞。
Python 3.14.3
微软官方的 Python 扩展，是 VS Code 安装量最高的扩展（209M+）。集成 IntelliSense（通过 Pylance）、调试（通过 Python Debugger）、代码检查、格式化、重构和单元测试等功能。支持 Jupyter Notebook、虚拟环境管理和多 Python 版本切换。
- 经验公式：
replicas ≥ 3 × 物理节点数，最低不低于 32（3 节点起步） - 节点数 ≤ 5 时，设 64～128 最平衡；节点数 ≥ 50 后，32～64 就够用
- 别用动态 replica 数：不同节点配不同 replica 数会让环失去单调性，get_node 逻辑必须假设所有节点权重可比
环结构必须支持运行时增删，且不能阻塞查询
你不能每次 add_node 都重建整个 sorted list；也不能让 get_node 拿锁遍历。典型错误是把节点列表存成普通 list，然后每次查都 for 循环找顺时针第一个——O(N) 复杂度，1000 个节点时延迟飙升。
- 必须用
bisect维护有序哈希值列表：self._ring_keys = sorted([h1, h2, ...]) -
add_node时用bisect.insort(self._ring_keys, new_hash)，O(log N) -
get_node时先bisect.bisect_left(self._ring_keys, key_hash)，再取模索引，O(log N) - 删除节点要同步删掉它所有 replica 的哈希值，否则残留点会持续导流
最容易被忽略的是：哈希环本身无状态，但业务要求「相同 key 永远路由到同一节点」——这意味着所有服务实例必须加载完全一致的节点列表和 replica 数，配置不一致时，环就分裂了，数据开始乱跳。
