geosearch + hgetall 循环因n+1查询导致高延迟，核心瓶颈是201次网络rtt（如跨机房单次5–10ms，累计1–2秒），而redis命令本身执行仅微秒级；改用eval将geosearch、批量hgetall及加权计算全下推至服务端，仅需1次rtt并返回单一结果，彻底消除客户端解析、连接池压力与序列化开销。
因为 Lua 脚本把原本要分 N 次发给 Redis 的命令，压缩成一次请求执行，直接砍掉 N−1 次网络 RTT。
为什么 GEOSEARCH + HGETALL 循环会卡在 RTT 上
典型场景：客户端调用 GEOSEARCH 返回 200 个 ID，再对每个 ID 单独发 HGETALL —— 这就是 201 次独立请求。跨机房时单次 RTT 常达 5–10ms，光等待就吃掉 1–2 秒，还不算序列化、连接复用开销。
- Redis 本身执行
GEOSEARCH或HGETALL都很快（微秒级），瓶颈纯在网络 - 客户端 CPU 和内存还要反复解析、拼装、收包，负载被额外拉高
- 连接池可能因高频短请求打满，触发新建连接或超时重试
EVAL 把逻辑下推到服务端的关键动作
脚本里不是“拼字符串找 key”，而是让 Redis 自己查、取、算，最后只吐一个结果回来。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
redis.call("GEOSEARCH", KEYS[1], "FROMLONLAT", ARGV[1], ARGV[2], "BYRADIUS", ARGV[3], "m", "WITHDIST")—— 第一步拿到带距离的原始结果 - 遍历结果数组时，对每个成员名
res[i][0]调用redis.call("HGETALL", res[i][0])—— 注意：这个成员名必须提前放进KEYS数组，否则集群路由失败 - 所有数值计算（比如加权求和）都在 Lua 里用
tonumber()转换后完成，不传回客户端 - 最终
return weightedSum，客户端只收一个数字，不是 200 个哈希结构
集群环境下 EVALSHA 容易踩的坑
EVALSHA 看似省流量，但上线前不处理好路由和预热，反而更慢甚至报错。
-
SCRIPT LOAD必须发到KEYS[1]所在 slot 的节点，否则集群返回(error) NOSCRIPT No matching script - Spring Boot + Lettuce 要确认启用了
ScriptExecutor，否则每次重启都重新LOAD，初始化压力翻倍 - 脚本内容哪怕多一个空格，
SHA1就不同，EVALSHA直接失败 —— 构建时必须固化脚本内容，不能靠运行时读文件 - 错误写法：
redis.call("HGETALL", "member:"..ARGV[1])→ 集群无法提取 key，报(error) ERR EvalSha is not supported in cluster mode
真正难的不是写脚本，而是让每个 redis.call 都落在正确的 slot 上，且不因参数动态拼接破坏集群路由规则 —— 这一点在批量地理查询、去重过滤、计费扣减等场景里，稍不注意就全量失败。
