不能直接用incr生成全局唯一有序id，因其仅保证单调递增，缺乏时间信息与结构化特征，且存在重启重复、扩缩容乱序、单点故障及无时钟回拨处理等问题。
直接用 INCR 生成 ID 是最常见也最容易翻车的做法——它能保证单调递增，但不能保证全局唯一、有序、可读，更扛不住时钟回拨、服务重启或 Redis 主从切换。跨服务场景下，必须把时间戳、实例标识、毫秒内序列号三者拼装，并靠 Lua 脚本在 Redis 端原子执行。
为什么不能只用 redisTemplate.opsForValue().increment()
这个调用看似简洁，实则埋了三个硬伤：
- 客户端生成时间戳再传入，网络延迟或本地时钟漂移会导致同一毫秒内多个服务写入相同 key，
INCR会返回不同值，但拼出的 ID 可能重复或乱序 - 没做 key 过期控制，每毫秒一个 key（如
id:seq:202609051302）长期累积会撑爆内存 - 没嵌入实例标识（比如机器 IP 或服务名），扩缩容后新实例从 0 开始计数，ID 失去“大致有序”特性，影响分库分表路由和日志排查
必须用 Lua 脚本封装时间戳 + INCR + EXPIRE
Redis 的 TIME 命令返回服务端当前秒和微秒，比客户端时间可靠；Lua 脚本在服务端原子执行，避免竞态。关键逻辑是：
- 调用
redis.call('TIME')拿服务端时间，转成毫秒级时间戳 - 构造 key：比如
id:seq:+math.floor(ts / 1000)（保留到秒，降低 key 数量） - 对 key 执行
INCR，再立刻EXPIRE86400 秒（一天），防止 key 泛滥 - 返回值拼装为
ts * 10000 + seq，预留 4 位给序列号（单秒最多 9999 个 ID）
示例脚本（供 redisTemplate.execute() 调用）：
local ts = math.floor(tonumber(redis.call('TIME')[1]) * 1000 + tonumber(redis.call('TIME')[2]) / 1000)
local key = 'id:seq:' .. math.floor(ts / 1000)
local seq = redis.call('INCR', key)
redis.call('EXPIRE', key, 86400)
return ts * 10000 + seq
RedisTemplate 调用 Lua 的三个避坑点
Spring Boot 默认配置下，RedisTemplate 对 Lua 支持不友好，容易报错或返回类型错乱：
- 别用
StringRedisTemplate直接执行 Lua —— 它默认返回String，而脚本返回的是数字，会抛ClassCastException - 必须显式指定
RedisCallback或用execute(RedisScript, keys, args)形式，并确保 script 的setValueSerializer能反序列化 Long - 若用 Lettuce（Spring Boot 2.3+ 默认），要确认连接工厂已启用
setUseSsl(false)或正确配置 TLS，否则 EVAL 可能超时静默失败
跨服务 ID 必须带实例标识，不能只靠时间戳
纯时间戳 + 序列号在单实例下够用，但跨服务部署时，多个服务同时写同一个 key（如 id:seq:202609051302），INCR 返回的只是该 key 的全局计数，无法区分来源。解决办法是：
- key 中加入服务标识：比如
id:seq:order-service:202609051302，但要注意 key 长度和数量爆炸风险 - 更稳妥的是在最终 ID 里嵌入标识：取本机 IP 后两位或服务名 hash 后 2 字节，左移到高位，例如
(ipHash - 如果用 Redisson，直接上
RedissonIdGenerator，它底层用setnx+ 预分配段机制，天然支持多实例，但要注意allocationSize别设太大（默认 1000），否则 ID 跳变明显
真正难的不是写脚本，而是让所有服务共享同一套时间基准、key 生命周期策略和溢出兜底逻辑——这些细节一旦不统一，ID 就会在某个凌晨三点开始重复或倒流。
