Redis 怎么读取后立即删除一次性令牌

Redis 中的一次性登录令牌、找回密码令牌或短时确认码，常见要求是“成功读取一次，之后不能再读到”。如果 Redis Open Source 版本不低于 6.2，直接使用 GETDEL key：它在 Redis 内完成读取并删除，第一次返回字符串，之后返回空值，避免应用层先 GET、再 DEL 产生竞态。

把令牌存成字符串后，用 GETDEL 做单次消费；命中、空值和命令错误要分别处理。Redis 低于 6.2 时，用 Lua 把读取与删除放进同一个脚本。

用 GETDEL 把一次性令牌变成单次消费

先把令牌写入字符串键，并给它设置一个短 TTL。下面的键名只用于演示，真实项目中应把业务、用户或流程标识纳入命名，避免不同用途共用一个键。

# 写入一个 5 分钟后自动失效的一次性令牌
redis-cli SET auth:token:8f31 "u_2048:confirm" EX 300

# 第一次读取并删除，返回令牌内容
redis-cli GETDEL auth:token:8f31

# 第二次读取，键已经不存在，返回 (nil)
redis-cli GETDEL auth:token:8f31

GETDEL 的关键不是“少写了一条命令”，而是把读取和删除放在 Redis 的一次命令处理里。两个消费者同时请求同一个键时，只有一个能拿到字符串；另一个得到空值。该命令的复杂度是 O(1)，但它只适用于字符串值。

在客户端处理命中、缺失和类型错误

应用端不要只判断“返回字符串就是成功”。空值可能代表令牌过期、已经被消费或键根本不存在；命令错误则通常是连接问题、权限问题，或者键类型与 GETDEL 不匹配。

package main

import (
    "context"
    "errors"
    "fmt"

    "github.com/redis/go-redis/v9"
)

func consumeToken(ctx context.Context, rdb *redis.Client, key string) (string, error) {
    // GETDEL 只取字符串并删除键，命中后不会留下可重复消费的值。
    value, err := rdb.GetDel(ctx, key).Result()
    if errors.Is(err, redis.Nil) {
        // 空值表示令牌不存在、过期或已被其他请求消费。
        return "", fmt.Errorf("token unavailable: %w", err)
    }
    if err != nil {
        // 网络、权限和 WRONGTYPE 等命令错误要进入独立的故障路径。
        return "", fmt.Errorf("consume token: %w", err)
    }
    return value, nil
}

如果项目使用其他客户端，保持同样的三分法即可：字符串值进入校验和业务处理，空值返回“不可用”，其他错误进入重试或告警。不要因为空值而无限重试，否则一个已经成功消费的令牌会被误判成暂时故障。

旧版本 Redis 用 Lua 保住原子性

GETDEL 的官方命令页标记为 Redis Open Source 6.2.0 起可用。如果环境更旧，不能简单地在应用代码里连续发送 GET 和 DEL：两个请求之间，另一个消费者可能已经读取了同一个令牌。

-- 在 Redis 内部一次完成读取和删除，避免两个客户端插队
local value = redis.call('GET', KEYS[1])
if value then
    -- 只有确实读到值时才删除，便于区分空键
    redis.call('DEL', KEYS[1])
end
return value

调用脚本时只传一个键，并让脚本保持短小。对于 Redis Cluster，单键脚本更容易满足路由要求；不要在脚本中随意访问多个未做哈希标签规划的键。升级到支持 GETDEL 的版本后，可以再把兼容脚本收敛为原生命令，但客户端仍要保留空值和错误分支。

给一次性令牌补上 TTL、命名和回滚边界

GETDEL 只能保证 Redis 键的单次取用，不能替你决定“消费后业务失败怎么办”。令牌写入时仍应使用 TTL，避免用户永远不提交导致垃圾键积累；消费成功后，再把业务结果写入订单、登录会话或确认记录。

• TTL：按业务窗口设置，例如几分钟，而不是依赖定时清理。
• 键名：区分用途，如 auth:token:{id}、reset:token:{id}，不要让不同流程误取。
• 回滚：若取出令牌后下游失败，先判断是否允许重新签发新令牌；不要把旧值盲目写回，避免并发请求重新获得已消费凭据。
• 安全：令牌本身应足够随机，日志只记录业务流水号或哈希摘要，不打印完整凭据。

常见问题

GETDEL 能读取 Hash、List 或 Set 吗？

不能把它当成通用删除命令。它面向字符串值；不存在或值类型不是字符串时返回空值，复杂结构应按自身命令设计消费逻辑。

GETDEL 返回空值是不是 Redis 连接失败？

不一定。空值通常是键不存在、TTL 已到期或已被其他消费者取走；连接和权限问题应从客户端错误分支判断。

GETDEL 能替代数据库事务吗？

不能。它只定义令牌键的单次消费边界，后续数据库写入仍需自己的事务、幂等键或补偿策略。

实际落地时，先确认 Redis 版本和键类型，再选择原生命令或 Lua 兼容路径；最后用 TTL、唯一命名和业务幂等把“只消费一次”补成完整流程。