不能直接用 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>，其中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 到内置默认权重，而不是报错中断
环的构建和查找逻辑本身没问题，真正容易出问题的是权重数据源的时效性和容错——不是脚本写得不够短，而是忘了它跑在分布式环境里。
