INCRBY不能直接用作全局唯一ID，因其在主从复制延迟、Redis重启无持久化、分片集群跨slot等场景下会导致ID重复或跳变；可靠方案是时间戳+原子自增组合，并需开启AOF、Lua封装、slot标签等保障措施。
为什么 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 内是否出现重复或倒序 —— 这个点多数人根本想不到测。
