无论是网关层还是微服务内部调用，把请求稳定地路由到同一台后端节点，对缓存友好性和会话保持都很重要。取模哈希在节点数固定时简单有效，但自动化扩容或故障摘除节点后，原本的映射关系会大面积失效。一致性哈希把节点和请求都映射到一个固定范围的哈希环上，通过顺时针查找确定目标节点。这样节点增减只影响相邻区间，大幅降低重新映射的比例。Node.js可以借助内置crypto模块快速实现哈希环，配合定时健康检查动态调整节点集合，形成一套轻量自动化负载均衡方案。

从取模到哈希环：为什么节点扩缩容会引发雪崩

传统负载均衡常用hash(key) % N来确定请求落入哪个节点，其中N是后端节点数量。当N不变时，每个key的映射结果是确定的，这对本地缓存、会话粘滞都很有利。但问题在节点数量一旦发生变化，N从3变成4，所有缓存的分布规则都会被改写。举个简单例子，假设请求标识经过哈希后得到1001，在3个节点下取模得到2，路由到第三台节点；扩容到4台后，1001对4取模变成1，请求被送到第二台节点。绝大多数key都会发生类似漂移，缓存命中率可能从接近100%骤降至接近1/N。

一致性哈希的思路是抛弃变化的分母N，把整个哈希值空间固定为一个环，通常用0到2的32次方减1这个整数区间。节点通过哈希函数映射到环上的某个位置，请求的key同样映射到环上，然后沿着顺时针方向查找第一个遇到的节点。节点下线时，原本归属它的请求会自动顺时针流向下一个节点，其他区间的请求完全不受影响。新增节点时也只会接管逆时针方向上一段区间的请求，重映射范围被限制在局部。

这种局部调整的特性非常适合自动化场景。当服务注册中心发现某个API节点不健康或被手动缩容，只需要从哈希环中移除对应节点，流量自动被相邻节点接手。相比重新计算所有请求的取模结果，一致性哈希可以避免大量请求同时打到新节点造成的瞬时压力，也能保护已有缓存不失效。

Node.js实现一致性哈希环：虚拟节点与二分查找

要在Node.js中实现一个可用的一致性哈希环，核心组件包括哈希函数、有序环、虚拟节点和查找逻辑。哈希函数可以直接使用内置的crypto模块，MD5计算速度快且分布足够均匀，也可以换成SHA1。把MD5摘要的前8位十六进制转成整数，就得到一个落在0到2的32次方减1之间的哈希值。节点初始加入时，不直接使用真实节点名做一次哈希，而是为每个真实节点生成多个虚拟节点，例如给同一个节点加上#vnode0到#vnode149的后缀分别计算哈希。

虚拟节点的作用是缓解数据倾斜。如果只用真实节点本身哈希，节点在环上的位置可能非常集中，导致某些节点承担过多请求，另一些节点几乎没有流量。通过增加大量虚拟副本，可以让节点在环上的分布更加均匀，节点之间的负载差异显著缩小。虚拟节点数量通常选择100到200之间，太少平衡效果不足，太多会增大排序和内存开销。

下面是一个完整的哈希环实现，使用Map保存虚拟节点哈希到真实节点的映射，使用有序数组支持二分查找。

const crypto = require('crypto');
class ConsistentHashRing {
  constructor(nodes = [], virtualNodes = 150) {
    this.virtualNodes = virtualNodes;
    this.ring = new Map(); // hash -> realNode
    this.sortedHashes = [];
    for (const node of nodes) {
      this.addNode(node);
    }
  }
  hash(key) {
    return parseInt(
      crypto.createHash('md5').update(String(key)).digest('hex').slice(0, 8),
      16
    );
  }
  addNode(node) {
    for (let i = 0; i < this.virtualNodes; i++) {
      const vnodeKey = `${node}#vnode${i}`;
      const hash = this.hash(vnodeKey);
      this.ring.set(hash, node);
      this.sortedHashes.push(hash);
    }
    this.sortedHashes.sort((a, b) => a - b);
  }
  removeNode(node) {
    for (let i = 0; i < this.virtualNodes; i++) {
      const vnodeKey = `${node}#vnode${i}`;
      const hash = this.hash(vnodeKey);
      this.ring.delete(hash);
    }
    this.sortedHashes = Array.from(this.ring.keys()).sort((a, b) => a - b);
  }
  getNode(key) {
    if (this.ring.size === 0) return null;
    const keyHash = this.hash(key);
    let left = 0;
    let right = this.sortedHashes.length - 1;
    while (left <= right) {
      const mid = (left + right) >> 1;
      if (this.sortedHashes[mid] >= keyHash) {
        right = mid - 1;
      } else {
        left = mid + 1;
      }
    }
    const targetHash = this.sortedHashes[left] ?? this.sortedHashes[0];
    return this.ring.get(targetHash);
  }
}
module.exports = ConsistentHashRing;

代码中getNode方法先计算请求key的哈希值，然后在有序数组里通过二分查找定位第一个大于等于该哈希的位置。如果越过数组末尾，说明请求哈希比环上所有虚拟节点都大，此时回到索引0处的第一个节点，形成闭环。移除节点时需要重新构建有序数组，虽然复杂度略高，但节点变更通常不是高频操作，在实现自动化负载均衡时完全可以接受。

实际项目中也可以使用现成的hashring等npm包，但自己实现的好处是可以根据业务定制虚拟节点数量、哈希函数以及节点权重策略。比如给高配置节点分配更多虚拟节点，让它承接更多请求，这就是加权一致性哈希的雏形。

把健康检查与动态扩缩容接入自动化负载均衡

一致性哈希本身只解决映射稳定性问题，自动化负载均衡还必须处理节点的健康状态变化。常见的做法是为每个后端API节点暴露一个/health接口，网关进程定时请求该接口，如果连续失败或者超时，就把节点从哈希环中移除。移除后，原本路由到该节点的请求会自动顺时针漂移到下一个健康节点，无需人工介入。

下面示例展示如何把健康检查与哈希环联动。每5秒检查一次所有真实节点，发现不健康就移除，恢复健康后重新加入环。

const ConsistentHashRing = require('./consistent-hash-ring');
const ring = new ConsistentHashRing(['api-1', 'api-2', 'api-3'], 120);
const unhealthy = new Set();
async function checkNode(node) {
  const url = `http://${node}:3000/health`;
  try {
    const res = await fetch(url, { signal: AbortSignal.timeout(2000) });
    return res.ok;
  } catch (err) {
    return false;
  }
}
setInterval(async () => {
  const nodes = Array.from(new Set(ring.ring.values()));
  for (const node of nodes) {
    const healthy = await checkNode(node);
    if (!healthy && !unhealthy.has(node)) {
      unhealthy.add(node);
      ring.removeNode(node);
      console.log(`节点 ${node} 已从哈希环移除`);
    } else if (healthy && unhealthy.has(node)) {
      unhealthy.delete(node);
      ring.addNode(node);
      console.log(`节点 ${node} 已恢复并加入哈希环`);
    }
  }
}, 5000);
const requestKey = 'user:10086:profile';
const targetNode = ring.getNode(requestKey);
console.log(`请求 ${requestKey} 路由到 ${targetNode}`);

这段代码用unhealthy集合避免重复移除或重复添加。健康检查失败时执行removeNode，恢复后执行addNode。生产环境中如果部署了多个网关实例，节点状态应放在Redis或etcd等共享存储中，避免单实例视角不一致。也可以由服务注册中心直接推送节点上下线事件，网关监听事件后更新哈希环，这样自动化程度更高，延迟也更低。

动态扩缩容方面，新增节点时调用addNode即可。由于一致性哈希的局部调整特性，新节点上线后只会从相邻节点分担一部分流量，不会瞬间打满，有利于缓存预热。缩容时从注册中心移除节点，再调用removeNode，流量平滑迁移。整个过程中哈希环始终保持可用，不会出现全量重映射造成的缓存雪崩。

一致性哈希的边界与替代方案：何时该用，何时不要用

一致性哈希最大的优势是缓存友好和节点变更影响小，但它并不感知节点的实时负载。假设某个key哈希后落在两个虚拟节点之间，这两个虚拟节点恰好属于同一台真实节点，就可能造成热点。如果API本身无状态、响应时间均匀且缓存诉求不高，使用轮询或最少连接策略反而更简单，也更容易达到实时均衡。一致性哈希更适合请求需要粘滞、后端有本地缓存或分片状态的场景。

下表对比了几种常见负载均衡策略在节点变化影响、缓存友好性和实现复杂度上的差异。

实现一致性哈希时还要注意哈希函数的选择。MD5碰撞概率在一般API路由中可忽略，但如果key数量极大或安全性要求高，可以考虑xxhash或MurmurHash等更快的非加密哈希。环的查找使用有序数组加二分在数千个虚拟节点规模下性能足够，如果虚拟节点达到几十万级别，应改用跳表或平衡树结构。虚拟节点数量也不是越多越好，在150个左右时平衡效果已经很好，过多只会增加内存和维护成本。

简单来说，Node.js配合一致性哈希可以很快搭建一套对缓存友好、支持自动化扩缩容的API负载均衡组件。只要理解哈希环的局部迁移特性，并用健康检查和虚拟节点补齐自动化与均衡性短板，它就能在微服务网关、消息路由、分布式缓存等场景中发挥稳定作用。