不能直接用 hash(key) % n 做加权分发,因为取模不支持权重比例,n 个节点权重不同时(如 3:2:1)会导致流量无法按比例分流;且客户端各自计算易因语言/版本差异结果不一致,而 redis 单实例执行 lua 脚本具有原子性,可规避并发竞争与逻辑漂移。

为什么不能直接用 hash(key) % N 做加权分发
因为取模本身不支持权重,N 个节点权重不同(比如 3:2:1)时,硬取模会把流量固定打到某几个槽位,完全无法按比例分流。更麻烦的是,客户端各自计算容易因版本/语言差异导致结果不一致,而 Redis 单实例执行 Lua 脚本是原子的,天然规避了并发竞争和逻辑漂移。
EVAL 脚本里怎么实现带权重的环形分发
核心思路是预构建一个「虚拟节点环」:每个物理节点按权重重复添加多次(权重为 3 就加 3 个虚拟节点),再对 key 做一致性哈希(如 crc32(KEY)),在环上二分查找最近的虚拟节点,最后映射回真实节点名。
- Redis 内置
crc32函数可用,无需 base64 或 md5 —— 后者在 Lua 中没原生支持,强塞会报attempt to call a nil value - 环必须预先排序(
table.sort),否则binary search失效;但注意redis.call()返回的数组不能直接 sort,得先unpack或逐个拷贝 - 权重总和不宜过大(建议 ≤ 1000),否则环表初始化慢,且
EVAL脚本有默认 5 秒超时限制
local weights = {["node-a"] = 3, ["node-b"] = 2, ["node-c"] = 1}
local ring = {}
for node, w in pairs(weights) do
for i = 1, w do
table.insert(ring, crc32(node .. ":" .. i))
end
end
table.sort(ring)
local key_hash = crc32(ARGV[1])
-- 二分查找略(需手写,Redis Lua 不支持内置 bisect)
如何让多个 Redis 实例共享同一套分发逻辑
不能每个实例都存一份 Lua 脚本,维护成本高。正确做法是用 SCRIPT LOAD 预加载,拿到 SHA1 校验和后,后续全用 EVALSHA 调用 —— 这样既避免重复传输脚本,又保证所有实例执行完全相同的逻辑。
- 首次加载:
redis-cli --eval script.lua , key或调用SCRIPT LOAD "$(cat script.lua)" - 后续调用:
EVALSHA <sha1> 0 <key></key></sha1>,其中0表示无 key 参数(脚本只读 ARGV) - 如果返回
NOSCRIPT,说明该实例没加载过,需 fallback 到EVAL并重试一次
权重变更时怎么平滑切换不丢请求
直接改 Lua 脚本再 SCRIPT FLUSH 会导致正在执行的请求失败,且新旧逻辑并存期无法控制。稳妥方式是把权重配置抽出来,存在 Redis 的一个 Hash 里(如 HGETALL loadbalance:weights),每次脚本运行时动态读取 —— 这样权重变更是热更新,只要保证 Hash 更新原子性(HSET 单命令)即可。
- 务必给权重 Hash 设置过期时间(
EXPIRE loadbalance:weights 86400),防配置残留 - 脚本内用
redis.call("HGETALL", "loadbalance:weights")拿最新值,别缓存到局部变量 - 如果某次读到空 Hash,应 fallback 到内置默认权重,而不是报错中断
环的构建和查找逻辑本身没问题,真正容易出问题的是权重数据源的时效性和容错——不是脚本写得不够短,而是忘了它跑在分布式环境里。











