Redis用INCRBY生成全局唯一ID方法

Redis的INCRBY命令看似能生成递增ID，实则无法满足全局唯一性要求——在主从复制延迟、实例重启无持久化、分片集群跨slot等真实生产场景下极易导致ID重复或跳变；真正可靠的方案是采用“毫秒级时间戳+原子自增序号”双段结构，通过Lua脚本封装、强制开启AOF持久化、按时间戳动态分key并设置自动过期，兼顾唯一性、有序性与高并发安全性，让ID生成既稳定又可扩展。

为什么 INCRBY 不能直接当全局唯一 ID 用

直接对一个 key 执行 INCRBY 1 确实能返回递增整数，但「全局唯一」不只看数字不重复——它还要求高并发下不冲突、重启后不回退、跨集群不重复。单靠 INCRBY 在 Redis 单实例上勉强可用，一旦加了主从、分片或哨兵切换，就可能因复制延迟或 failover 导致 ID 重复或跳变。

• 主从同步异步时，从节点短暂升主，两个主同时 INCRBY，ID 就撞车
• Redis 重启后若没开 AOF 或 RDB 持久化，计数器直接归零
• 分片集群（如 Redis Cluster）里，不同 slot 的 key 无法原子递增，没法靠一个命令撑起全局

真正可用的方案：带时间戳前缀 + 原子自增

把 ID 拆成两段：高位是毫秒级时间戳（保证趋势递增），低位是该毫秒内的自增序号。这样既避免纯自增的单点瓶颈，又保留全局有序性。关键在于「同一毫秒内」的序号必须由 Redis 原子保证不重复。

• 用 INCRBY 操作一个带时间戳的 key，比如 id:20240520142305123，每次请求先取当前毫秒，再对该 key 自增
• 如果毫秒变了，就换新 key；如果没变，继续用老 key 自增 —— 这样每个 key 实际只承担极短时间内的并发压力
• 必须开启 appendonly yes，否则宕机后序号丢失，下一毫秒可能生成重复 ID

示例逻辑（伪代码）：

ts = current_timestamp_ms()
key = "id:" + ts
seq = redis.INCRBY(key, 1)
if seq == 1:
    redis.EXPIRE(key, 60)  # 防 key 泛滥，60 秒后自动清理
id = (ts << 20) | (seq & 0xFFFFF)

用 INCRBY 时最容易踩的三个坑

INCRBY 看似简单，但和 ID 生成强绑定时，边界条件特别敏感。

• 初始值没设好：INCRBY 对不存在的 key 默认从 0 开始加，但如果你期望 ID 从 1 起始，得先 SET id:xxx 0，否则第一次 INCRBY 1 得到的是 1，第二次才是 2 —— 表面没问题，但中间若有人 GET 到空值就崩了
• 整数溢出不处理：INCRBY 结果超过 64 位有符号整数（9223372036854775807）会绕回负数，ID 突然变负极其难排查
• 没配 maxmemory-policy：大量时间戳 key 积压，内存爆掉，Redis 直接 OOM 退出

比 INCRBY 更稳的选择：Lua 脚本封装原子逻辑

单纯靠客户端拼时间戳 + 多次网络往返，还是可能在“读时间戳”和“调 INCRBY”之间被其他客户端插队。用 Lua 把整个判断+自增逻辑塞进 Redis 服务端执行，才能真正原子。

• 脚本里用 redis.call("TIME") 拿毫秒，再拼 key，再 INCRBY，全程无竞态
• 注意 Lua 中 redis.call() 报错会中断整个脚本，别在脚本里做复杂计算或网络请求
• Redis Cluster 下，所有 key 必须落在同一个 slot，所以 key 名里得加 {xxx} 标签强制路由，比如 id:{20240520142305123}

示例 Lua（精简版）：

local ts = tonumber(ARGV[1])
local key = "id:{" .. ts .. "}"
local seq = redis.call("INCRBY", key, 1)
redis.call("EXPIRE", key, 60)
return (ts * 1000000) + seq

事情说清了就结束。真正上线时，ID 生成模块的压测重点不是吞吐量，而是 failover 后 100ms 内是否出现重复或倒序 —— 这个点多数人根本想不到测。

今天关于《Redis用INCRBY生成全局唯一ID方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！