云原生环境下Redis Lua脚本须预加载至实例并用EVALSHA调用，确保集群KEY同槽、配置合理资源限制，并纳入GitOps版本管理。
云原生环境下，Redis Lua脚本不能直接“部署”，而是要随Redis服务一起容器化，并确保脚本执行逻辑适配动态伸缩与集群拓扑。 直接把本地写好的 EVAL 脚本硬编码进应用、或在K8s Pod里临时加载，大概率会在滚动更新、分片迁移、节点扩缩容时出问题。
脚本必须预加载到Redis实例，而非运行时传入
云原生环境（尤其是K8s）中Pod可能随时重建，EVAL 命令每次传脚本会导致：重复解析开销、SHA1缓存失效、集群节点间脚本不一致。正确做法是使用 SCRIPT LOAD 预加载，再用 EVALSHA 调用：
- 在Redis初始化阶段（如Init Container或ConfigMap挂载的启动脚本）执行
SCRIPT LOAD，获取返回的SHA1值 - 应用代码中统一使用该SHA1调用
EVALSHA，避免每次传输脚本内容 - 若脚本变更，需同步更新所有Redis节点——建议配合Operator（如Redis Operator）自动完成脚本同步
集群模式下，脚本涉及的KEY必须落在同一哈希槽
云原生Redis集群（如bitnami/redis-cluster Helm Chart）默认启用哈希槽分片。如果Lua脚本里同时操作 KEYS[1] 和 KEYS[2]，而它们哈希后落到不同槽位，会直接报错 CROSSSLOT Keys in request don't hash to the same slot：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 强制使用哈希标签：比如
user:{1001}:token和user:{1001}:quota，大括号内相同，保证同槽 - 避免跨KEY操作：像分布式锁+计数器这类需求，应合并为单KEY结构（如用Hash存储锁状态和计数值）
- 测试阶段用
redis-cli --cluster check验证脚本KEY是否合规，别等上线才暴露
Docker/K8s配置需显式放开Lua资源限制
默认Redis配置对Lua脚本执行时间极其保守，云原生场景下网络延迟波动大、容器CPU配额可能受限，容易触发 BUSY SCRIPT 错误：
- 在Redis配置中设置
lua-time-limit 5000（单位毫秒），比默认的5秒更宽松 - K8s Deployment里为Redis容器预留足够CPU：至少
100m，避免因CPU节流导致脚本超时 - 禁用
notify-keyspace-events等非必要功能，减少Lua执行期间的额外开销
最易被忽略的是脚本版本管理——云原生环境里，Redis镜像升级、Operator版本迭代、应用灰度发布，都可能让新旧脚本逻辑并存。不要依赖“脚本SHA1不变”就认为逻辑一致，必须把脚本内容纳入GitOps流水线，和Redis配置、应用代码一起做版本快照和回滚能力验证。
