Redis如何实现复杂的计数器逻辑_利用Lua脚本实现带条件的自增

Redis如何实现复杂的计数器逻辑：利用Lua脚本实现带条件的自增

Redis的INCR不支持条件自增，因其仅对单key原子操作，无法实现“满足条件才执行”的分支逻辑；并发下GET+INCR组合会超限，需用Lua脚本将判断与修改封装为原子操作。

Redis的INCR命令为何无法直接实现条件自增

核心问题在于：INCR命令本身是原子操作，但仅保证对单个键的数值增减是原子的。它不具备“满足特定条件才执行自增”的分支判断能力。例如，要实现“用户今日点赞数不超过5次才允许+1”，若简单组合GET和INCR，在并发场景下会产生错误。两个请求可能同时读取到当前值为5，均判断为“未超限”，然后各自执行INCR，最终结果变为7，导致业务规则被破坏。

此类场景下常见两种错误现象：一是客户端收到(integer) 6的返回值，误以为操作成功，但数据库中实际存储的值为7；二是尝试使用WATCH配合MULTI事务实现乐观锁，但在高并发下，大量请求因冲突而失败重试，导致系统吞吐量显著下降。

根本原因在于Redis命令的原子性是“单指令”级别的。一旦业务逻辑需要跨多个指令（如先读后改），就必须确保这一系列操作在服务端以一次性、不可分割的方式执行——这正是Lua脚本的核心价值所在。

使用EVAL执行Lua脚本实现条件自增

Redis内置了Lua解释器。关键在于：所有Redis命令在同一个Lua脚本内执行时，会作为一个整体具备原子性，且脚本能直接访问执行时刻的数据库状态。因此，重点不在于“是否会编写Lua”，而在于如何将“条件判断”与“数据修改”无缝封装为一个不可拆分的原子操作。

实际操作中需注意以下细节：

• 在脚本中获取键值，建议使用redis.call(“GET”, KEYS[1])。除非明确需要捕获并处理异常，否则避免使用redis.pcall。
• 进行数值比较前，务必使用tonumber()函数进行转换。否则，字符串比较如“5” > “10”在字典序下成立，会导致逻辑错误。
• 脚本返回值建议统一使用return输出整数，便于客户端解析。尽量避免返回table或nil等复杂或空值。
• 必须警惕：避免在脚本中执行耗时操作，例如循环上万次或调用外部API，这会阻塞整个Redis实例，影响其他所有请求。

以下是一个具体示例，实现限制单日点赞上限为5次：

redis-cli --eval /dev/stdin user:123:likes:20240520 <

EVALSHA与脚本缓存的常见问题
每次使用EVAL命令发送完整脚本内容，不仅增加网络开销，Redis服务器也需要重复解析。正确做法是：先使用SCRIPT LOAD命令将脚本加载到Redis缓存中，获取对应的SHA1哈希值，后续通过EVALSHA命令配合该哈希值调用脚本。
但需注意以下几个易错点：

脚本内容的任何微小改动（如增加一个空格），SCRIPT LOAD生成的SHA1值都会不同。若使用旧的哈希值执行EVALSHA，将收到(error) NOSCRIPT No matching script. Please use EVAL.错误。
在Redis集群模式下，传递给脚本的KEYS参数中的所有键，必须通过哈希计算后落在同一个slot中。否则，EVALSHA会直接报错：CROSSSLOT Keys in request don‘t hash to the same slot。
Redis服务重启后，脚本缓存会全部丢失。在生产环境中需有相应预案，例如在应用启动时预加载关键脚本，或设置兜底逻辑，在脚本不存在时自动回退至使用EVAL。

一个实用建议是：在执行EVALSHA前，先通过SCRIPT EXISTS 命令检查脚本是否已加载，不应默认其必然存在。

Lua脚本中如何安全处理不存在的键
这是另一个高频错误点。Redis的GET命令在键不存在时会返回nil，而该nil值在Lua中直接参与算术运算会立即抛出运行时错误：attempt to perform arithmetic on a nil value。
安全的处理方法通常有两种：

显式判断：if current == nil then current = 0 end
使用默认值：local current = tonumber(redis.call(“GET”, KEYS[1])) or 0

需特别注意：切勿写成tonumber(redis.call(“GET”, KEYS[1])) + 0这种形式——当键不存在时，此代码将直接导致脚本执行崩溃。
此外，虽然INCR命令本身具备“若键不存在则先初始化为0再+1”的特性，但当需要在自增前加入任何条件判断时，就无法绕过先执行GET这一步，因此处理键不存在的情况成为必要环节。
最后，必须强调一个原则：脚本逻辑越复杂，越需警惕Redis单线程模型可能带来的阻塞风险。即使只是获取时间或遍历小数组，也建议在上线前使用接近真实的数据量和并发量进行压测，观察是否存在延迟毛刺。线上无小事，任何脚本在生产环境部署前，都必须经过“压力测试”这一关。