Redis如何高效执行Lua脚本？避免每次传输完整代码的优化方案
核心方案：使用 EVALSHA 替代 EVAL，实现脚本缓存复用
在Redis中频繁通过EVAL命令发送完整的Lua脚本内容，会在高并发场景下产生显著的开销，包括网络传输负载和序列化成本。为了提升性能，Redis提供了EVALSHA命令，其核心原理是让服务端“记住”脚本内容，客户端后续只需传递一个固定的SHA1哈希值即可调用。
但必须注意一个关键前提：脚本必须预先通过SCRIPT LOAD命令在Redis服务端完成加载和注册。如果未加载直接调用EVALSHA，会收到NOSCRIPT错误，此时需要回退到EVAL。
- 最佳实践建议：在应用程序初始化或建立Redis连接池后，主动执行
SCRIPT LOAD，将高频使用的Lua脚本预加载至服务端缓存中。 - 重要提醒：脚本内容的任何微小变动（包括空格、注释、换行符）都会导致其SHA1哈希值彻底改变，从而使之前缓存的
EVALSHA调用失效。 - 版本说明：自Redis 4.0起，
SCRIPT LOAD命令会直接返回脚本的SHA1值，便于客户端存储和使用。更早版本需要客户端自行计算哈希，容易引入错误。
自动化方案：利用 redis-cli --eval 或客户端库的智能封装
手动组合SCRIPT LOAD和EVALSHA不仅操作繁琐，且维护成本高。在实际生产环境中，推荐使用成熟的Redis客户端库，它们通常内置了脚本缓存与自动回退机制。例如Jedis的evalSha、redis-py的evalsha等方法，会在服务端返回NOSCRIPT时自动降级为发送完整的EVAL命令。
对于本地测试和调试，可以直接使用redis-cli工具的--eval选项。该命令会自动计算脚本SHA1并尝试EVALSHA，失败时无缝切换至EVAL：
redis-cli --eval myscript.lua key1 key2 , arg1 arg2
- 语法细节：键（keys）与参数（args）之间的逗号前后必须保留空格，否则命令解析会失败。
- 路径限制：脚本文件必须位于本地文件系统，不支持远程URL加载。
- 作用域说明：通过
--eval加载的脚本仅对当前连接会话有效，不会持久化。Redis服务重启后，脚本仍需重新加载。
脚本编写规范：保持脚本内容稳定，避免动态拼接导致哈希变化
若Lua脚本内容因外部变量或动态逻辑而发生改变，其SHA1哈希值就会失效，迫使EVALSHA降级为全量传输。一个典型的错误模式是在脚本内部拼接字符串来构造Redis命令：
local cmd = "redis.call('incr', '" .. KEYS[1] .. "')" -- ❌ 危险！KEYS 内容变化会导致脚本整体变化
正确的做法是严格遵循Redis脚本规范，将固定的业务逻辑写在脚本内，变动的数据通过KEYS和ARGV参数传入，从而确保脚本本体稳定：
local val = redis.call('incr', KEYS[1]) -- ✅ 逻辑固定，SHA1 值稳定
- 禁止使用
loadstring等函数动态执行代码，或通过字符串拼接生成新的函数体。 - 尽量避免在脚本中引入不确定性因素，如读取外部配置、获取当前时间戳、生成随机数等，这些都会实质改变脚本行为或内容。
- 若需条件分支，应使用Lua原生的
if ... then ... else结构实现，而非通过字符串拼接动态生成逻辑。
集群环境注意事项：SCRIPT LOAD 的作用域与节点限制
在Redis Cluster分布式集群模式下，SCRIPT LOAD命令的作用范围仅限于当前连接的节点，不会自动同步到集群所有实例。如果Lua脚本涉及多个键的操作，且这些键分布在不同哈希槽（slot）对应的节点上，则必须确保脚本在所有这些节点上均已加载，否则EVALSHA会在部分节点上执行失败。
- 单键操作相对安全，因为请求会被路由到同一个节点执行。
- 多键操作时，需主动在相关所有节点上执行
SCRIPT LOAD。部分高级客户端（如Lettuce）支持向多个节点分发加载脚本，但通常需额外配置。 - 在复杂的集群部署中，有时直接使用
EVAL并配合连接池复用，其稳定性和简易性可能优于手动维护多节点脚本版本的一致性。
最后需要明确：脚本的哈希缓存是节点级别的，不在集群实例间共享。切勿误以为一次SCRIPT LOAD即可全局生效，实际上仅当前节点会缓存该脚本。
