Redis Lua脚本：解决高并发与缓存击穿的利器（深度解析+实战案例）-拾贝生活号

在当今高并发、高性能要求的互联网应用中，Redis 已成为不可或缺的高性能缓存与数据存储中间件。而 Lua 脚本 作为 Redis 提供的一项强大功能，更是被广泛应用于秒杀、库存扣减、分布式锁、限流等复杂业务场景中。

Redis Lua脚本：解决高并发与缓存击穿的利器（深度解析+实战案例）

本文将带你深入理解 Redis Lua 脚本的核心原理，剖析其在实际项目中的经典应用场景，并提供可落地的代码示例，助你彻底掌握这一“性能优化核武器”。

什么是Redis Lua脚本？为什么它如此重要？

Redis 自 2.6 版本起引入了对 Lua 脚本 的支持。你可以将其理解为 Redis 内置的“存储过程”。通过 EVAL 或 EVALSHA 命令，开发者可以将一段 Lua 代码直接发送到 Redis 服务器执行。

✅ 核心优势：

原子性（Atomicity）

Redis 是单线程模型，Lua 脚本在执行时会阻塞其他所有命令，直到脚本执行完毕。
这意味着脚本内的所有操作是不可分割的整体，天然避免了竞态条件（Race Condition），确保数据一致性。

减少网络开销

多个 Redis 命令可以在一次网络请求中完成，极大减少了客户端与服务端之间的往返通信（RTT），显著提升性能。

支持复杂逻辑

相比于简单的 MULTI/EXEC 事务，Lua 脚本支持 if-else 判断、循环、函数调用等编程结构，能够实现复杂的业务逻辑。

📌 一句话总结：
Redis + Lua = 在内存中执行的、具备原子性的、轻量级“微服务”，专治各种高并发下的数据一致性难题。

经典应用场景1：防止秒杀超卖（库存扣减）

在电商大促或秒杀活动中，“超卖”是最典型的并发问题——商品只有10件库存，却有100人同时下单成功。

传统做法是先查库存再扣减，但在高并发下，多个线程可能同时读取到“库存 > 0”，然后都执行扣减，导致库存变为负数。

🔧 解决方案：使用 Lua 脚本实现原子化库存检查与扣减

1-- stock_decr.lua
2local key = KEYS[1]        -- 库存Key，如 "stock:product_1001"
3local user_key = KEYS[2]   -- 用户购买记录Set，如 "users:product_1001"
4local uid = ARGV[1]        -- 当前用户ID
5
6-- 1. 检查库存是否存在且大于0
7local stock = tonumber(redis.call('GET', key))
8if not stock or stock <= 0 then
9    return {err = "out_of_stock"}
10end
11
12-- 2. 检查该用户是否已购买过（防重复抢购）
13if redis.call('SISMEMBER', user_key, uid) == 1 then
14    return {err = "already_bought"}
15end
16
17-- 3. 执行扣减 & 记录用户购买行为
18redis.call('DECR', key)
19redis.call('SADD', user_key, uid)
20
21return {success = true, left = stock - 1}

✅ Java (Spring Boot) 调用示例：

1@Autowired
2private StringRedisTemplate redisTemplate;
3
4public Map<String, Object> tryBuy(String productId, String userId) {
5    String stockKey = "stock:" + productId;
6    String userKey = "users:" + productId;
7
8    // 定义Lua脚本
9    String script = "...上面的Lua代码...";
10
11    // 执行脚本
12    List<String> keys = Arrays.asList(stockKey, userKey);
13    List<String> args = Arrays.asList(userId);
14
15    Object result = redisTemplate.execute(
16        (RedisCallback<Object>) connection -> 
17            connection.eval(script.getBytes(),
18                           ReturnType.MULTI,
19                           2,
20                           keys.toArray(new byte[0][0]),
21                           args.toArray(new byte[0][0]))
22    );
23
24    // 解析返回结果...
25    return parseResult(result);
26}

💡 效果： 即使每秒上万次请求涌入，Redis 也会按顺序逐个执行 Lua 脚本，从根本上杜绝超卖和重复购买问题。

经典应用场景2：解决缓存击穿（热点Key失效）

当一个高访问量的缓存 Key（如爆款商品详情）过期瞬间，大量请求直接打到数据库，造成“缓存击穿”，可能导致数据库雪崩。

🔧 传统方案缺陷：

双重检查锁定（Double Check Locking）在分布式环境下难以保证一致性。
使用独立的分布式锁（如 Redlock）会增加系统复杂度。

✅ 最佳实践：Lua 脚本实现“获取锁-查询-释放锁”原子操作

1-- get_or_update.lua
2local cache_key = KEYS[1]
3local lock_key = KEYS[2]
4local lock_timeout = tonumber(ARGV[1])  -- 锁超时时间（毫秒）
5local cache_timeout = tonumber(ARGV[2]) -- 缓存过期时间（毫秒）
6
7-- 1. 先尝试从缓存获取
8local cached_value = redis.call('GET', cache_key)
9if cached_value then
10    return cached_value
11end
12
13-- 2. 缓存未命中，尝试获取分布式锁
14local lock_acquired = redis.call('SET', lock_key, '1', 'NX', 'PX', lock_timeout)
15if not lock_acquired then
16    -- 锁已被其他线程持有，等待并重试
17    return 'WAIT'
18end
19
20-- 3. 成功获得锁，返回标记，由客户端去数据库加载数据
21return 'ACQUIRED'

✅ Python 后端调用逻辑：

1def get_product_info(product_id):
2    cache_key = f"product:{product_id}"
3    lock_key = f"lock:{cache_key}"
4
5    while True:
6        result = redis.eval(lua_script, 2, cache_key, lock_key, 5000, 3600000)
7
8        if isinstance(result, str) and result != 'WAIT':
9            # 缓存命中，直接返回
10            return json.loads(result)
11        
12        elif result == 'WAIT':
13            # 等待持有锁的线程更新缓存
14            time.sleep(0.05)
15            continue  # 重试
16        
17        elif result == 'ACQUIRED':
18            # 获得锁，从DB加载数据
19            try:
20                product = db.query(product_id)
21                # 更新缓存
22                redis.setex(cache_key, 3600, json.dumps(product))
23                return product
24            finally:
25                # 无论成功失败都释放锁
26                redis.delete(lock_key)

✅ 配合策略：

缓存预热： 定时任务提前加载热门商品。
随机过期时间： 避免大量缓存同时失效（防雪崩）。

📊 优化效果：

指标	优化前	优化后
平均响应时间	3000ms	8ms
数据库QPS	5000+	<50
缓存命中率	78%	99.8%

最佳实践与避坑指南

✅ 推荐做法：

预加载脚本（Script Caching）

使用 SCRIPT LOAD 预先加载脚本，后续用 EVALSHA 执行，避免重复传输脚本内容。

轻量化设计

避免在 Lua 脚本中执行耗时操作（如遍历大集合），防止长时间阻塞 Redis 主线程。

错误处理机制

使用 pcall() 捕获异常，返回结构化错误信息给客户端。

参数校验

在脚本开头验证 KEYS 和 ARGV 的合法性。

版本控制

将 Lua 脚本文件纳入代码仓库管理，便于追踪变更。

⚠️ 注意事项：

不要执行阻塞命令：如 BLPOP、BRPOP 等，会导致整个 Redis 阻塞。
避免无限循环：可能导致 Redis 完全不可用。
合理设置 lua-time-limit：默认5秒，超时后可通过 SCRIPT KILL 终止只读脚本。

Lua 脚本 vs Redis 事务（MULTI/EXEC）

特性	Lua 脚本	Redis 事务
原子性	✅ 强原子性（阻塞执行）	✅ 命令打包执行
复杂逻辑	✅ 支持 if/for/函数	❌ 仅支持命令序列
网络开销	✅ 一次请求	❌ 多次交互（PIPELINE可优化）
错误处理	✅ 可自定义返回值	⚠️ 不支持回滚
适用场景	复杂业务逻辑	简单命令组合