因为zrandmember不支持按score权重采样，需lua脚本实现加权随机：先获取有序集合成员及score，构建累积权重数组，再用math.random生成随机数并二分查找定位成员。
为什么直接用 redis.call("ZRANDMEMBER") 不行？
因为 ZRANDMEMBER 默认是均匀随机，无法按权重抽样。Redis 原生不支持带权重的随机选择（如按 score 比例采样），必须靠 Lua 脚本在服务端计算累积权重并二分查找——否则客户端做会引入竞态和网络延迟误差。
如何用 Lua 实现加权轮询（Weighted Random Sampling）？
核心思路：把有序集合 backend:weights 的成员按 score 当作权重，累加生成前缀和数组，在 Lua 中用二分查找定位目标节点。
- 先用
zrange backend:weights 0 -1 WITHSCORES拿到所有后端及其权重 - 在 Lua 中构建累积权重数组（例如权重 [2,3,5] → 前缀和 [2,5,10]）
- 生成
math.random(1, total_weight)，再二分查它落在哪个区间 - 返回对应 member，避免多次
zscore或zrank查询
示例脚本片段：
local members = redis.call("ZRANGE", KEYS[1], 0, -1, "WITHSCORES")
local weights = {}
local sum = 0
for i = 1, #members, 2 do
local score = tonumber(members[i+1])
sum = sum + score
table.insert(weights, {member = members[i], bound = sum})
end
if sum == 0 then return nil end
local rnd = math.random(1, sum)
for _, w in ipairs(weights) do
if rnd <h3>为什么不能用 <code>math.randomseed()</code>？</h3><p>Redis Lua 沙箱禁用了 <code>math.randomseed()</code>，且每次脚本执行都是独立环境，<code>math.random()</code> 默认种子固定——导致同一秒内多次调用返回相同结果。解决办法只有两种：</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2199" title="Redis 8.2.3"><img
src="https://img.php.cn/upload/manual/001/589/237/69f31fe8b56d4731.png" alt="Redis 8.2.3" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2199" title="Redis 8.2.3" class="overflowclass">Redis 8.2.3</a>
<p class="overflowclass">Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2199" title="Redis 8.2.3" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 让客户端传入一个变化的 seed（如毫秒时间戳）作为
ARGV[1]，再math.randomseed(ARGV[1]) - 更稳妥的做法：用
redis.call("TIME")获取微秒级时间戳，取其低 32 位做 seed（local ts = redis.call("TIME"); math.randomseed(ts[1] * 1000000 + ts[2])）
忽略这点会导致负载永远打到同一个后端上。
注意 EVAL 的 key 参数约束和原子性边界
EVAL 脚本只能访问显式声明的 KEYS，不能动态拼接 key 名；同时，整个脚本是原子执行的，但无法包含“先读权重、再更新权重”的复合逻辑——比如自动降权失败节点，必须拆成两步（先 EVAL 选节点，再单独 ZINCRBY 调整 score）。
- 若需实时权重反馈（如某后端连续超时则临时降权），得靠外部协调器异步写回 Redis，不能塞进同一个脚本
- 权重更新和选取必须分离，否则可能因脚本阻塞导致选取卡顿
- 测试时用
redis-cli --eval要严格对齐KEYS和ARGV顺序，错一位就报ERR Error running script
权重配置本身没缓存，每次选取都全量拉取有序集合，成员数超过 500 时延迟明显上升——真要高并发，得预计算好前缀和存在 HASH 里，用 Lua 维护一致性。
