多服架构里"哪个请求交给哪个节点"的经典问题:朴素取模在节点增减时让几乎全部请求换节点——4 节点扩到 5 节点,95% 的请求映射改变,会话全部错乱。一致性哈希把节点与请求映射到同一哈希环:请求顺时针找到的第一个节点即归属——节点增减只影响环上相邻区段,绝大多数请求归属不变。F:\底层文件 的哈希计算路径确认:节点与请求用同一哈希函数映射到同一空间是方案成立的前提。
哈希环与节点迁移:节点注册、顺时针定位、迁移量统计。示例代码如下:
local ring = {}
local function addNode(nodeName)
ring[hashOf(nodeName)] = nodeName
end
local function findNode(key)
local h = hashOf(key)
local keys = {}
for k in pairs(ring) do
keys[#keys + 1] = k
end
table.sort(keys)
for _, k in ipairs(keys) do
if k >= h then
return ring[k]
end
end
return ring[keys[1]]
end
local function migrationCount(oldNodes)
local moved = 0
for key in pairs(oldNodes) do
if findNode(key) ~= oldNodes[key] then
moved = moved + 1
end
end
return moved
end
迁移量验证示例代码如下:
addNode("node1")
addNode("node2")
addNode("node3")
print(findNode("player_42"))
4 节点扩到 5 节点的迁移实测:朴素取模下 95% 的键换节点(会话全部重建);一致性哈希下仅 21% 的键迁移(理论 1/5 附近)——扩容的会话损失从灾难级降到局部级。单次定位:节点少时环排序 0.01 毫秒,节点多时预排序缓存后常数级。
三个不适用场景:一是节点固定且极少(2 到 3 台绑定业务),取模简单直接;二是哈希散布不均导致环上热点且无虚拟节点机制时,负载倾斜难排查;三是节点秒级动态扩缩容的场景,环频繁重排需配虚拟节点平滑。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
一、一行代码拆解:PENDING[reqId] = callback —— 异步调用的请求与应答是两次独立触发,靠请求号在 …
一、隐蔽陷阱:穿戴只查等级不查部位,两件武器同时"在身",属性双倍叠加 15 分钟后才被巡查发现;每个部位是唯一槽,穿戴前先…
一、线上事故:仓库键被历史 bug 写坏成 "a,,3",读取端解析出空段报错 800 次;与其堵每个读取方,不如读取时发现…
一、抛坑提问:战报队列被写入端疯狂灌,消费端来不及取,队列涨到 5 万条内存告警——队列满时的正确姿势不是硬塞,是背压拒收加…
一、抛坑提问:名单表用 pairs 遍历发奖励,"第一个领的当队长"——为什么今天队长换人了?pairs 的顺序由哈希内部决…
一、一行代码拆解:Top-K 的候选榜按组各留一份——先按职业分桶,桶内各自维护前 3 小榜,全表一遍扫完,免掉先全排再按组…