首页 / 文章 / 从模块化到哈希环：在风暴来袭时仍能扩展 Node.js 缓存集群

Node.jsSystem DesignCachingDistributed SystemsRedisPerformance

从模块化到哈希环：在风暴来袭时仍能扩展 Node.js 缓存集群

了解为何在节点发生变化时 hash-mod-N 分片会导致数据库崩溃，比较 rendezvous、jump 和 ring hashing 的差异，以及如何在 Node.js 中构建平衡的加权环结构。

4407 词

一个正常运行数月的缓存集群，在进行常规操作——比如添加一个节点后，几分钟内就可能让数据库瘫痪。问题的根源通常在于客户端代码中的一行代码，它通过hash(key) % N的方式来选择服务器。本指南将详细解释为何这行代码会出问题，对比四种可行的替代方案，展示如何在Node.js中构建具备生产级质量的一致性哈希环，并列出该算法本身无法防范的运营风险。

故障模式

想象有一组运行良好的四个缓存节点，其命中率为94%。由于即将迎来季节性流量高峰，一名工程师决定添加第五个节点。这项操作只需修改两行配置，并在工作日中间谨慎地部署。大约一分半钟后，数据库的CPU使用率就达到了100%，网站随之无法访问。

没有人犯下任何疏忽。客户端只是按照一贯的方式来分配密钥：

const node = nodes[hash(key) % nodes.length];

那种表达方式能非常均匀地分配密钥，因此看起来是正确的。问题在于当nodes.length发生变化时它会产生什么影响，而这正是本指南后续要探讨的内容。讨论将涵盖四个独立的问题，权衡各种可行的替代方案，然后在Node.js中构建并测试环形结构。

一个概念背后的四个问题

一致性哈希通常被当作一种简单的技巧来介绍。实际上它解决了四个不同的问题，而仅处理第一个问题的实现仍会因其他三个问题而在实际应用中失败。

问题1：改变N值几乎会移动所有密钥

使用hash(key) % N时，改变N的值不会只移动少数密钥，而是几乎会移动所有密钥。

通过具体数字来分析会有所帮助。哈希值为1,000,003的键在% 4运算下对应节点3，同时巧合地在% 5运算下也对应节点3。而哈希值为1,000,004的键在% 4运算下对应节点0，在% 5运算下对应节点4。这两种映射之间没有任何关联，因此一个键能保持在原位纯属偶然，概率大约为1/N。

在百万个键的测试中，这一规律十分明显：当节点数从8增加到9时，有88.93%的键会发生变化；在包含100个节点的集群中，增加一个节点就会使大约99%的缓存失效。

看看这一趋势的发展方向。系统规模越大，每次扩展带来的破坏性就越强。这是一种会在业务发展顺利时悄然出现的故障。

每次重新映射的键都是一次查找失败，每次失败都会触发一次数据库查询，而这些操作都在几秒内完成。原本只为那6%的查找失败情况而配置的数据库，突然要处理几乎所有的查询请求。

问题2：同样的重新映射，却毫无计划

至少第一个问题是在你决定扩展系统时才会出现。而第二个问题则是由故障引发的同样事件，只不过发生在最不合适的时机。

某个节点的内存耗尽，某台主机被终止，或者网络分区导致某个节点与一半的节点群隔离开来。此时节点数量从8个降至7个，每个客户端都会自行将其约87%的键重新映射到剩余的节点上。

目前的状况十分严峻：缓存容量已损失12.5%，数据库面临87%的查询失败率，剩下的七个节点在补充几乎所有键值的同时还要承担丢失节点的流量。这常常导致第二个节点也崩溃，进而需要再次进行完整重映射，最终使第三个节点也无法正常工作。

模块化路由机制会将单个节点的故障转化为在整个集群中相互关联、不断恶化的故障。这种级联效应，而非冷缓存问题，才是真正的危险。

问题3：简单的环形结构严重失衡

针对问题1，显而易见的解决方案是将节点和键值映射到同一个数值空间中，并按顺时针方向将每个键值分配给下一个节点。这正是一致性哈希的精髓，它确实能够避免大规模的数据重排。

然而，若以简单方式实现的话，其负载均衡效果很差。节点会随机分布在哈希值对应的位置，因此它们之间的间距是随机的，而随机间距很少会相等。当每个哈希值对应四个节点时，有次测试中一个节点占据了45%的键空间，另一个则仅占13%，两者差距达3.4倍，且代码中并无任何错误。

这种不平衡状况还会持续存在。它源于节点名称本身，比如cache-04这个节点会在被重命名之前一直处于高负载状态，而任何检查代码的人都会发现其运行方式完全符合设计。

在更大规模的情况下，情况会更糟。8个节点各有一个环点时，负载最重的节点承担了其应分担量的434%，而负载最轻的节点仅承担了3.7%。实际上这就相当于有一台服务器超负荷运转，另外七台则处于空闲状态。

问题4：所有客户端必须达成一致

最容易被忽视的问题是权限问题。必须有某种机制将键映射到节点上，而且它在每台发起查询的机器上都必须给出相同的答案。

一种解决方案是使用负责维护权威性分片映射的协调服务。但这样一来，每次查询都需要进行一次网络往返，或者客户端需要缓存该映射，而这时又需要一种方法来使缓存失效。如果两个客户端哪怕只有一瞬间持有不同版本的映射，其中一个可能会将user:42写入节点A，而另一个则从节点B读取该值。虽然数据没有丢失，但这反而更糟糕：现在出现了两个可能的正确值。

你所需要的是一种映射关系，它应是键值与当前成员列表的纯函数。无需协调器、无需查询服务、也无需共享状态：每个客户端执行相同的计算即可得到相同的结果。一致性哈希正是实现了这一点，这也是尽管查询表具有更高的灵活性，它仍更受青睐的原因。

具体场景与可选方案

为使比较更具实际意义，我们来考虑这样一个系统。

系统架构。该电子商务API将会话数据和用户资料数据缓存到Redis节点池中。在2500万个键的情况下，峰值查询量约为每秒40,000次，命中率为94%。数据库之所以能正常运行，只是因为还有6%的查询会失败。（如需了解缓存模式的详细内容，请参阅Redis缓存基础。）

需求要求：

    在促销活动开始前将节点数量从8个增加到12个，且不会引发查询失败风暴
  1. 能够承受单个节点故障的影响，且故障波及范围需控制在可接受范围内
  2. 保持负载均衡，任何节点的负载都不应超过其合理份额的120%左右
  3. 确保协调节点不会参与读取操作
  4. 需要适配不同的硬件配置：部分节点拥有64GB内存，另一部分为16GB，且它们的负载不应相同

有多种算法能够满足这些要求中的一部分或全部。它们之间存在显著差异，选择不当将会带来高昂代价。

选项A：模运算哈希

hash(key) % N 能实现完美的平衡，仅需一条指令且不占用内存。

但它完全无法满足第1和第2项要求。尽管如此仍需提及，因为这是人们首先想到的方法，而且在出问题之前表现一直很好。

仅在 N确实永远不变的情况下才选择此方法，例如将批处理任务分配给固定数量的处理器，或在一个进程内进行分片处理。

选项B：协调器与查找表

在etcd或ZooKeeper等存储系统中维护键范围到节点的显式映射关系。Vitess和HBase等系统大致也是采用这种方式工作的。

其优势确实显著：完全控制。你可以移动单个热点分片，一边监控指标一边逐步重新平衡某个范围的数据，或将特定租户绑定到特定的硬件上。基于哈希的方法无法实现这些功能，而当系统规模超过一定程度时，你就会迫切需要这样的能力。

其代价也同样真实：需要运行共识机制，要确保地图的每个缓存副本始终是最新的，同时还必须依赖读取路径。

何时选择它？当你处理的是持久性数据而非可丢弃的缓存条目，且需要控制迁移过程而非让所有数据一次性转移时。

选项C：会合哈希（HRW）

该算法为每个键针对所有节点计算随机权重哈希值，进而选出最优节点：

function rendezvous(key, nodes) {
  let best = null, bestScore = -1;
  for (const node of nodes) {
    const score = mix(hash(key), hash(node));
    if (score > bestScore) { bestScore = score; best = node; }
  }
  return best;
}

这就是整个算法的原理。它没有环结构、虚拟节点，也没有排序机制，当成员发生变化时无需重新构建任何内容。

在最重要的两项指标上，它甚至优于环结构。从8个节点增加到9个节点时，只有11.09%的键被移动，而理论上的最小值应为11.11%；而且无需任何调整就能实现近乎完美的负载均衡。

其缺点是每次查询都需要O(N)的时间复杂度，因为每个键都要与每个节点进行哈希计算，而随着节点数量的增加，这一成本会迅速上升。

何时选择它：当节点数量少于30个左右时。许多团队使用的缓存节点数约为8个，此时使用会合哈希会更合适——它更易于编写和理解，也能实现更好的负载均衡。环结构虽然更为人熟知，但并不一定就是最佳选择。

选项D：跳跃一致性哈希

该算法由谷歌于2014年发布，仅用约十行代码即可实现，无需内存占用，平衡性几乎完美，并且只需移动最少的键。

它的局限性在于结构设计。它将键映射到[0, N)范围内的桶编号，但不具备节点“身份”的概念。桶只能在该范围的末端添加或删除；无法在保持其他部分稳定的前提下将中间的节点3移除。

何时选择它：当桶之间可以互换且仅有数量变化时，例如将数据集分配到可扩展的工作者池中。而当有特定命名的服务器加入或离开时——这正是缓存节点的运作方式——则不适合使用该算法。

选项E：带有虚拟节点的哈希环

这是经典设计。节点与键共享同一个循环地址空间，某个键属于顺时针方向上第一个找到的节点。

何时选择此设计：当节点数量多到使得线性查找成本过高时，且你需要带权重的节点以及移除任意节点的功能。

为该场景选择方案

以一百万个键对应8到9个节点的变化情况来衡量，除取模法之外的其他方法其性能都接近理论最小值，而环结构的平衡性在很大程度上取决于每台服务器分配到的虚拟节点数量。对于这个硬件配置多样、节点可能失效、且预计节点总数会超过30个的电子商务系统，环结构是最佳选择。本指南的后续内容将介绍如何正确实现它。

环结构的工作原理

先暂且不考虑数组和余数问题。想象一个从0到2³² − 1编号的圆圈，其在顶部处会循环连接。

整个算法由两条规则构成：

  1. 将每个节点名称进行哈希处理，使其落在圆圈上的某个位置，这样cache-01就会出现在其哈希值对应的地点。
  2. 将每个键也进行哈希处理，然后沿顺时针方向移动；首先到达的节点便拥有该键。

关键在于节点与键共享同一个地址空间，其他所有原理都由此衍生而来，包括为何添加节点的成本很低。

为何成员变化仅限于局部范围

当在圆圈上添加新节点时，它会被置于两个现有节点之间，仅负责管理从自身到其逆时针方向相邻节点之间的那段区域。

位于该弧线之外的密钥不会受到影响，会像以前一样回到原来的所有者手中。新加入的节点平均占据圆周的 1/(N+1) 部分，因此这些密钥的分布会随之改变。在节点数量从8变为9的情况下，这一比例为 11.06%，下限为11.11%；而在相同的节点数量变化和密钥集合下，模运算方式的这一比例则为88.93%。

移除节点的效果则相反：被移除节点的弧线会传递给其顺时针方向的后续节点。当节点数量从8减少到7时，有 12.60% 的密钥发生了转移，这一数值接近理论值12.50%。其影响是有限的且可承受的，其余六个节点则不会受到影响。

虚拟节点可解决失衡问题

回到问题3：四个位于随机位置的节点会形成非常不均匀的弧线。

解决办法出奇地简单：不要只放置每个节点一次。应使用160个不同的名称，如cache-01#0和cache-01#1，将节点放置160次。由于每个名称对应的位置都不同，因此每个物理节点会拥有160个分散的小弧段而非一个大的弧段，而大数定律会让情况趋于平衡。

在8个节点上对100万个键进行测试后发现，随着副本数量的增加，平衡性会持续提升。160通常是默认值，因为此时改进曲线大致趋于平缓，但500的平衡性依然明显更好。一个环节点大约需要12字节（4字节的定位信息加上8字节的所有者引用），因此8个节点配置500个副本时的总内存消耗还不到50KB。如果对平衡性的要求高于内存限制，可以进一步提高副本数量；不过很少有团队会去进行这样的计算。

虚拟节点还使得权重分配几乎无需成本。内存容量是其他节点两倍的节点会获得两倍的分数，因此流量也大致是两倍。在4:4:1:1的权重设置下，实际分配比例分别为40.6%、41.1%、9.4%和9.0%，而理想比例应为40/40/10/10。

在Node.js中实现环结构

实现过程可分为四步：对虚拟节点名称进行哈希处理、定位这些节点、对它们进行排序，然后使用二分搜索来查找某个键的所属节点。下面的类将节点成员关系存储在Map中，当成员关系发生变化时会重新构建排序数组，并提供get(key)方法用于查询。

export class ConsistentHashRing {
  #positions = new Uint32Array(0); // sorted ring positions
  #owners = []; // owners[i] owns #positions[i]
  #nodes = new Map(); // id -> { weight, points }

  constructor({ replicas = 160, hash = defaultHash } = {}) {
    if (replicas < 1) throw new RangeError("replicas must be >= 1");
    this.replicas = replicas;
    this.hash = hash;
  }

  addNode(id, weight = 1) {
    if (typeof id !== "string" || id.length === 0)
      throw new TypeError("node id must be a non-empty string");
    if (weight <= 0) throw new RangeError("weight must be > 0");
    if (this.#nodes.has(id)) return this;
    this.#nodes.set(id, {
      weight,
      points: Math.max(1, Math.round(this.replicas * weight)),
    });
    this.#rebuild();
    return this;
  }

  removeNode(id) {
    if (this.#nodes.delete(id)) this.#rebuild();
    return this;
  }

  #rebuild() {
    const pairs = [];
    for (const [id, { points }] of this.#nodes) {
      for (let i = 0; i < points; i++)
        pairs.push([this.hash(`${id}#${i}`), id]);
    }
    pairs.sort((a, b) => a[0] - b[0]);
    this.#positions = Uint32Array.from(pairs, (p) => p[0]);
    this.#owners = pairs.map((p) => p[1]);
  }

  /** Index of the first ring point >= h, wrapping to 0. */
  #successor(h) {
    const pos = this.#positions;
    let lo = 0,
      hi = pos.length;
    while (lo < hi) {
      const mid = (lo + hi) >>> 1;
      if (pos[mid] < h) lo = mid + 1;
      else hi = mid;
    }
    return lo === pos.length ? 0 : lo;
  }

  get(key) {
    if (this.#positions.length === 0) return null;
    return this.#owners[this.#successor(this.hash(key))];
  }
}

有三个设计选择值得注意。

使用并行数组而非对象数组。将位置存储在Uint32Array中，可使二分搜索在紧凑且连续的内存上运行，这类内存会保留在CPU缓存中。拥有8个节点和160个副本时，共有1,280个数据点，大小约为5KB，一次查找大约需要11次比较。

lo === pos.length ? 0 : lo中的循环处理问题。哈希值超出最后一个数据点的键属于圆环上的第一个节点。忽略这一条件是自制环形结构中最常见的错误：几乎所有键的查询结果都是正确的，但范围顶端的少数键却会莫名其妙地出现错误。

在成员状态变化时重新构建，而非在查询时。由于成员状态变化极为罕见，而查询每秒会发生数万次，因此偶尔对1,280个条目进行排序并不会带来实质性的成本。

复制过程，即为某个密钥寻找后续的几个持有者，实际上是一种顺时针遍历，旨在收集不同的物理节点。“不同”这一概念很重要，因为环上的相邻节点往往属于同一台服务器：

getReplicas(key, count = 1) {
  const n = this.#positions.length;
  if (n === 0) return [];
  const wanted = Math.min(count, this.#nodes.size);
  const out = [];
  const start = this.#successor(this.hash(key));
  for (let step = 0; step < n && out.length < wanted; step++) {
    const owner = this.#owners[(start + step) % n];
    if (!out.includes(owner)) out.push(owner);
  }
  return out;
}

请注意，wanted的值被限制在物理节点的数量之内，因此请求的复制副本数量若超过服务器数量，则无法无限循环，无论如何都会在完成一次完整遍历后停止。

谨慎选择哈希函数

许多教程会跳过这一部分，但它却蕴含着整个练习中最有价值的结论。

大多数环结构实现默认使用MD5算法。虽然该算法可行，但速度较慢：使用它的环结构每秒仅能完成423,000次查询，而且性能分析显示几乎所有时间都耗费在MD5运算上。

用快速的非加密哈希函数FNV-1a替代后，处理效率提升了约15倍。然而平衡性却严重下降：每个节点的负载标准差从10.4%上升到了30.7%。

查看几个虚拟节点的计算结果就能找到原因：

cache-01#0 → 4037809751
cache-01#1 → 4021032132
cache-01#2 → 4071364989
cache-01#3 → 4054587370
cache-01#4 → 3970699275

所有这些值都集中在40亿左右的一个狭窄区间内。FNV-1a的雪崩效应较弱，即相似的输入会产生相似的输出。由于虚拟节点名称仅相差后缀，这些点并没有分散在圆周上，而是每个节点都将它们聚集在一个紧密的群集中。为追求速度而进行的优化反而让问题3再次出现。

解决办法是将FNV的输出通过位混合处理函数进行处理，该函数是MurmurHash3的最后一步：

function fnv1a(str) {
  let h = 0x811c9dc5;
  for (let i = 0; i < str.length; i++) {
    h ^= str.charCodeAt(i);
    h = Math.imul(h, 0x01000193);
  }
  return h >>> 0;
}

// Scrambles the bits so near-identical inputs land far apart.
function fmix32(h) {
  h ^= h >>> 16;
  h = Math.imul(h, 0x85ebca6b);
  h ^= h >>> 13;
  h = Math.imul(h, 0xc2b2ae35);
  h ^= h >>> 16;
  return h >>> 0;
}

export const defaultHash = (str) => fmix32(fnv1a(str));

fmix32通过交替使用移位、异或和乘法操作，使得任意输入位的变化会影响到所有输出位。Math.imul能够执行真正的32位整数乘法，而>>> 0则将结果转换回适合存储在Uint32Array中的无符号32位数值。尽管多出了大约十次操作，这种组合方式的哈希值分布比MD5更均匀，且运行速度大约快13倍。

这一经验不仅适用于哈希算法：当用更快的组件替换现有组件时，还需检测那些未被优化的属性。FNV-1a本身是一种相当不错的哈希算法，只是它并不适合这项任务，而其描述中也并未给出相关提示。

将环形结构转换为缓存客户端

仅一个节点无法构成缓存客户端。生产环境代码必须能够处理故障，而这种环形结构提供了一种简洁的解决方案：顺时针方向切换到下一个节点。

下面的封装代码会接收一个包含命名客户端的映射表，据此构建环形结构，在每次执行get操作时按顺序尝试前failoverDepth个节点。出现异常的节点会被标记为不可用downtimeMs时间，并从环形结构中移除，待其惩罚时间结束后再重新加入。

export class ShardedCache {
  #ring; #clients; #down = new Map();

  constructor(clients, { replicas = 160, failoverDepth = 2, downtimeMs = 10_000 } = {}) {
    this.#clients = new Map(Object.entries(clients));
    this.#ring = new ConsistentHashRing({ replicas });
    for (const id of this.#clients.keys()) this.#ring.addNode(id);
    this.failoverDepth = failoverDepth;
    this.downtimeMs = downtimeMs;
  }

  #markDown(id) {
    this.#down.set(id, Date.now() + this.downtimeMs);
    this.#ring.removeNode(id);
  }

  #reviveExpired() {
    const now = Date.now();
    for (const [id, until] of this.#down) {
      if (now >= until) { this.#down.delete(id); this.#ring.addNode(id); }
    }
  }

  async get(key) {
    this.#reviveExpired();
    for (const id of this.#ring.getReplicas(key, this.failoverDepth)) {
      try {
        return { value: await this.#clients.get(id).get(key), node: id };
      } catch {
        this.#markDown(id);
      }
    }
    return { value: null, node: null, allDown: true };
  }
}

在四个模拟节点上运行该代码，这些节点各持有10,000个键，随后杀死其中一个节点，得到了如下结果：

Keys per node:  cache-01 2213 | cache-02 2462 | cache-03 2923 | cache-04 2402

Killing cache-02...
  served from cache: 7538
  cache misses:      2462
  hard failures:     0
  healthy nodes:     cache-01, cache-03, cache-04

  24.6% of traffic became a miss.

那个数值就是你的容量规划值。在由四个节点组成的集群中，一旦某个节点出现故障，会有额外的24.6%的读取请求转嫁到数据库上；而八节点集群则可将这一比例控制在12.5%。如果数据库无法承受所有读取负载同时以1/N的强度涌入，那么问题实际上出在数据库容量而非缓存机制上，而一致性哈希则让这个问题从致命缺陷变成了可观察的现象。另外需要注意的是，没有发生任何硬件故障：针对已失效节点的键的请求会自动转发到下一个节点，从而变成普通的未找到情况。

算法未能覆盖的生产环境隐患

仍有若干问题不在该算法的解决范围内，无论如何都会对系统造成影响。

环版本差异

只有当所有客户端计算出相同的结果时，该机制才能发挥作用。应逐步推进成员资格变更，在几分钟内让一半的节点群看到8个节点，而另一半看到9个节点。这样两半节点群在大约11%的密钥上会产生分歧。对于缓存系统而言，这意味着命中率会短暂下降；而对于任何支持写入操作的系统来说，则意味着数据会出现不一致。应对成员资格集合进行版本控制，通过单一渠道分发，并在指标中报告版本信息，这样就能实际观察到数据偏差而非仅凭猜测。

过于仓促地移除节点

在超时后不要立即移除节点。那些不断离开又重新加入的节点会引发严重的流量波动，因为每次状态切换都会导致 1/N 的键被移动。应在时间窗口内出现多次连续故障后才将其移除，并谨慎地重新接纳该节点。上述示例使用了固定的十秒惩罚时间；实际生产代码应在允许节点重新加入之前采用指数退避策略并进行健康检查。

热点键未实现均衡分布

一致性哈希能够均匀分布键值，但对请求并无约束。当某款产品突然变得极为流行时，其条目会集中在某一台服务器上，即便哈希环仍在正常工作，该服务器仍可能过热。有两种解决方案：一是在哈希环前端为最热门的键值设置小型进程内缓存；二是采用谷歌研究提出的带负载限制的一致性哈希方案，通过限制每个节点的处理量并将多余请求顺时针方向传递。

重新映射并非迁移

上述所有内容都假设丢失密钥仅会导致缓存未命中。如果环结构用于传输持久性数据，那么“11%的密钥被移动”意味着有11%的数据必须先被物理复制到新节点上，之后才能在该节点读取，通常在复制完成之前，读写操作仍需同时发送到两个位置。环结构仅能确定需要移动什么数据，而无法执行实际的移动操作。这正是像Vitess这样的系统依赖协调器的原因：它们需要控制数据的迁移过程，而不仅仅是计算迁移量。

副本数量实际上是不可更改的

将replicas的值从160改为500会改变每个环节点的位置，并重新分配几乎所有的密钥，其带来的破坏性等同于模运算值的改变。应将其视为在数据正式上线之前做出的一次性设计决策，若不确定的话，选择较高的数值即可。

何时环结构不是合适的选择

工程判断的一部分在于能够识别出那些看似出色的解决方案其实是不正确的。

  • 节点数少于30个：使用会合哈希。它需要的代码更少，平衡性更好，且无需调整副本数量。该结构的唯一优势是O(log N)的查找时间，但在如此小的规模下这一优势其实并无实际意义。
  • 桶可互换且仅计数值会变化：使用跳跃哈希，仅需10行代码且不占用内存。
  • 需要可控移动的持久数据：使用协调器。只有通过显式的映射关系，才能在监控其影响的同时移动单个分片，这是哈希算法无法实现的。
  • N值确实永远不变：使用% N即可。无需为永远不会发生的变化设计复杂的机制。

当节点具有名称、类型多样、数量众多且容易发生故障时，环结构才能发挥其作用。这几乎完美地描述了缓存集群的特点，也正是如此，许多分布式缓存都是基于环结构构建的。

核心要点

  • 其核心思想很简单：将键和服务器置于同一个地址空间中，这样成员变化只会影响周边节点，而不会波及整个系统。
  • 模运算路由机制会导致每次规模扩展或节点故障几乎引发整个缓存的清除，且集群规模越大，造成的损失越严重。
  • 对于小型缓存集群，汇合哈希通常是更好的选择；而当需要考虑规模、权重以及节点的任意移除时，则应选用环结构。
  • 如果没有虚拟节点，一台服务器承担的负载可能会是其合理负荷的数倍。应提前确定副本数量，因为之后更改会打乱整个系统的结构。
  • 具有较弱雪崩效应的快速哈希函数可能会悄悄导致失衡；应始终关注数据分布情况，而不仅仅是速度。
  • 当一个节点失效时，大约有 1/N 的读取请求会转发到数据库。因此需根据这一比例来设计数据库规模，谨慎处理节点加入或移除的情况，并单独管理热点键。

    • 环形结构本身仅由几十行代码构成。确保其在生产环境中保持可靠性的关键在于其周围的各项工程措施。

    相关阅读

    全部文章发送简报