【实战解析】Redis Lua脚本：从原子操作到复杂业务逻辑的架构实践
1. Redis Lua脚本的核心价值
第一次接触Redis Lua脚本是在2015年做电商秒杀系统时遇到的。当时用Java代码实现的库存扣减在高并发下总是出现超卖问题，直到发现Redis的EVAL命令才真正解决了这个痛点。Lua脚本最吸引我的地方在于它完美结合了原子性操作和复杂逻辑处理能力，这在分布式系统中简直是救命稻草。
Lua脚本在Redis中执行时具有天然的原子性，这意味着脚本中的所有操作要么全部成功，要么全部失败。这与Redis事务的原子性不同，Lua脚本在执行期间不会被其他命令打断，而Redis事务只是保证命令按顺序执行。举个例子，在实现分布式锁时，用Lua脚本实现的锁获取和释放操作可以确保判断锁持有者和删除锁这两个动作不会被拆分开执行。
另一个关键优势是减少网络开销。在微服务架构中，服务间调用产生的网络延迟往往是性能瓶颈。通过Lua脚本，我们可以把原本需要多次网络往返的操作合并成一次调用。实测下来，一个包含5个Redis操作的业务逻辑，用Lua脚本实现比单独发送5条命令要快3-5倍，这在QPS过万的场景下差异非常明显。
2. Lua脚本执行机制深度解析
2.1 脚本加载与缓存
Redis处理Lua脚本的第一个阶段是脚本加载。当我们执行EVAL命令时，Redis会先计算脚本的SHA1哈希值，然后在脚本缓存中查找是否已有相同内容。这个缓存机制对性能影响很大，我曾在压测时发现，直接使用EVAL命令比用EVALSHA慢20%左右，因为前者每次都要传输完整脚本。
脚本缓存有个容易踩坑的地方：缓存不会持久化。Redis重启后所有脚本缓存都会丢失，所以生产环境一定要实现脚本预加载机制。我的做法是在应用启动时，通过SCRIPT LOAD命令把所有用到的脚本预先加载到Redis中，并保存返回的SHA1值。Spring Boot项目中可以用@PostConstruct注解实现这个逻辑：
@Bean public RedisScript<Long> stockScript() { String script = "local stock = tonumber(redis.call('get', KEYS[1]))..."; return RedisScript.of(script, Long.class); }2.2 脚本编译与执行
加载后的Lua脚本会被Redis编译成字节码。这里有个性能优化点：Lua脚本中应尽量避免使用全局变量。我曾调试过一个性能问题，发现脚本中意外使用了全局变量导致每次执行都要重新编译。正确的做法是使用local关键字声明所有变量：
-- 错误示范：使用全局变量 counter = 0 -- 正确做法：使用局部变量 local counter = 0脚本执行阶段最需要关注的是超时处理。Redis默认配置下，Lua脚本执行超过5秒就会被强制终止。对于复杂运算，一定要用redis.break_timeout()定期检查执行时间。去年我们有个排行榜计算脚本就因为这个配置导致超时，后来优化为分批次处理数据才解决。
3. 企业级应用场景实践
3.1 秒杀库存扣减
电商秒杀是最典型的Lua脚本应用场景。传统方案先用DECR命令扣减库存，再判断结果是否大于等于0，这在并发下会产生竞态条件。用Lua脚本实现可以完美解决：
local stock = tonumber(redis.call('GET', KEYS[1])) if stock > 0 then redis.call('DECR', KEYS[1]) return 1 -- 扣减成功 else return 0 -- 库存不足 end这个脚本要注意两个细节：一是用tonumber()显式转换类型，避免字符串比较的问题；二是返回值设计要区分成功/失败状态。在实际项目中，我们还会在脚本中加入限流逻辑，比如同一用户5秒内只能抢购一次。
3.2 分布式锁进阶实现
Redisson的分布式锁内部就是基于Lua脚本实现的。相比简单的SETNX方案，生产级实现要考虑锁续期、可重入等特性。这是我优化过的锁实现脚本：
local lockKey = KEYS[1] local clientId = ARGV[1] local leaseTime = ARGV[2] -- 判断是否可重入 if redis.call('exists', lockKey) == 0 then redis.call('hset', lockKey, clientId, 1) redis.call('pexpire', lockKey, leaseTime) return 1 elseif redis.call('hexists', lockKey, clientId) == 1 then redis.call('hincrby', lockKey, clientId, 1) redis.call('pexpire', lockKey, leaseTime) return 1 else return 0 end这个脚本使用Hash结构存储锁信息，value记录重入次数。相比String结构，Hash可以更灵活地存储元数据。解锁脚本也要对应处理重入计数，只有计数归零时才真正删除key。
4. 性能优化与避坑指南
4.1 脚本性能调优
Lua脚本虽然高效，但编写不当也会成为性能瓶颈。以下是几个关键优化点：
避免大Key操作：操作大List或Hash时，应该用SCAN代替直接获取全部元素。有次我们有个脚本处理10万成员的Set导致Redis阻塞，改成游标分批处理后才恢复。
控制脚本复杂度：Redis是单线程模型，长时间运行的脚本会阻塞其他请求。建议将复杂脚本拆分为多个短小脚本，用管道(pipeline)组合执行。
合理使用缓存：对高频执行的脚本，客户端应该缓存SHA1值而不是每次发送完整脚本。Spring Data Redis的RedisScript接口就自动实现了这个优化。
4.2 常见问题排查
调试Lua脚本比调试普通代码更困难。我总结了几种实用方法：
- 日志调试法：在脚本中用redis.log()输出日志，记得设置Redis的loglevel为verbose才能看到：
redis.log(redis.LOG_NOTICE, "Current stock:"..tostring(stock))慢查询监控：用SLOWLOG GET命令查看执行时间过长的脚本，配合redis-cli --latency检测网络延迟。
内存分析：对于内存异常增长的情况，可以用MEMORY USAGE命令检查脚本创建的临时变量是否及时释放。
曾经遇到一个内存泄漏问题，最后发现是脚本中循环内没有及时清理局部变量导致的。在Lua中，用collectgarbage()可以主动触发垃圾回收，但更好的做法是控制变量的作用域范围。