Redis如何实现复杂的计数器逻辑：利用Lua脚本实现带条件的自增
Redis的INCR命令本身不支持条件判断，仅能保证对单个键的原子递增，无法实现“满足特定条件才自增”的业务逻辑。在并发场景下，组合使用GET和INCR会导致数据超限。解决方案是使用Lua脚本，将条件判断与数据修改封装为一个原子操作，确保数据一致性。
Redis 的 INCR 为什么不能直接做带条件的自增
核心问题在于：INCR 命令虽然是原子操作，但其原子性仅限于对单个键值的数值增减。它本身不具备“条件判断”的能力。例如，要实现“用户当日点赞数不超过5次才允许增加”这类业务规则，如果仅通过客户端顺序调用 GET 和 INCR，在高并发下必然产生竞态条件。两个请求可能同时读取到当前值为5，均判断为“未超限”，然后各自执行 INCR，最终结果变为7，业务规则被破坏。
常见的错误实践包括：一是客户端收到成功响应（如 (integer) 6），但实际数据已超限；二是尝试使用 WATCH 配合 MULTI 事务实现乐观锁，但在高并发场景下，大量事务因冲突而失败重试，导致系统吞吐量急剧下降。
根本原因在于，Redis 命令的原子性是“单指令”级别的。任何需要“先读后改”或包含分支判断的多步骤业务逻辑，都必须确保这些操作在服务端作为一个不可分割的整体执行。这正是引入 Lua 脚本的核心价值所在。
用 EVAL 执行 Lua 脚本实现条件自增
Redis 内置了 Lua 解释器。关键特性是：在同一个 Lua 脚本中执行的所有 Redis 命令，会作为一个整体具备原子性，并且脚本能直接访问执行时刻的数据库快照。因此，技术重点不在于 Lua 语法本身，而在于如何将“条件判断”与“数据修改”无缝封装成一个原子操作单元。
在编写脚本时，需注意以下关键细节：
- 脚本内获取键值，推荐使用
redis.call(“GET”, KEYS[1])。除非需要显式捕获并处理异常，否则避免使用redis.pcall。 - 进行数值比较前，必须使用
tonumber()函数进行类型转换。否则，字符串比较（如 “5” > “10”）会按字典序进行，导致逻辑错误。 - 脚本返回值建议统一使用
return输出整数（如1代表成功，0代表失败），便于客户端解析。应避免返回 table 或 nil 等复杂或空值。 - 重要警告：严禁在脚本中执行耗时操作，例如大循环或调用外部服务，这会阻塞 Redis 单线程，影响整个实例的性能。
以下是一个实现“单日用户点赞上限5次”的 Lua 脚本示例：
redis-cli --eval /dev/stdin user:123:likes:20240520 <
EVALSHA和脚本缓存的坑频繁使用
EVAL命令发送完整脚本，会产生较大的网络开销，且 Redis 需重复解析脚本。最佳实践是：先通过SCRIPT LOAD命令将脚本加载到 Redis 缓存，获取其 SHA1 哈希值，后续调用则使用EVALSHA命令配合此哈希值执行。使用
EVALSHA时，需警惕以下常见问题：
- 脚本内容的任何微小变更（包括空格、换行），都会导致其 SHA1 值彻底改变。若使用旧的哈希值执行
EVALSHA，将返回(error) NOSCRIPT No matching script. Please use EVAL.错误。- 在 Redis 集群模式下，传递给脚本的
KEYS参数中的所有键，必须通过哈希计算后落在同一个槽（slot）中。否则会报错：CROSSSLOT Keys in request don‘t hash to the same slot。- Redis 服务重启后，脚本缓存会全部丢失。生产环境必须有应对预案，例如在应用启动时预加载关键脚本，或在客户端实现降级逻辑（脚本不存在时自动回退到
EVAL）。一个实用的安全建议是：在执行
EVALSHA前，先通过SCRIPT EXISTS命令检查脚本是否已加载，不要默认其一定存在。Lua 脚本里怎么安全处理不存在的 key
这是 Lua 脚本编程中的一个高频错误点。当键不存在时，Redis 的
GET命令会返回nil。若在 Lua 中直接对nil进行算术运算，会立即抛出运行时错误：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再递增”的特性，但一旦需要在递增前加入任何条件判断（如检查上限），就必须先执行GET操作。因此，处理键不存在的情况是编写健壮脚本的必备环节。最后，必须强调一个核心原则：脚本逻辑越复杂，对 Redis 单线程模型的潜在阻塞风险就越大。即使只是获取时间戳或遍历小型集合，也应在上线前使用接近真实数据量和并发压力的场景进行充分压测，观察是否存在延迟毛刺。生产环境无小事，任何 Lua 脚本在部署前都必须通过严格的性能测试验证。
