不能直接用incr生成业务序列号，因其无法拼接前缀、日期等非数字部分，易导致格式不一致或重复；需用lua脚本原子执行读-算-存-返回，并由客户端传入日期参数以避免时钟偏差。
为什么不能直接用 INCR 生成业务序列号？
直接用 INCR 确实能原子自增，但多数业务序列号不是纯数字，比如「ORD2024052000001」或「PAY-SH-20240520-00001」——需要拼接前缀、日期、分片标识等。如果先 INCR 再拼字符串，中间可能被其他客户端插入，破坏格式一致性或导致重复。Lua 脚本能将“读+算+存+返回”打包成一个原子操作，避免竞态。
EVAL 中如何安全拼接带日期的序列号？
Redis 的 Lua 环境不支持 os.date，必须由客户端传入时间参数（如 YYYYMMDD），否则不同节点时钟偏差会导致同一天生成多个日期段。脚本里用 string.format 拼接，用 redis.call('INCR', KEYS[1]) 获取自增数，再补零对齐位数。
示例脚本（保存为 gen_seq.lua）：
local key = KEYS[1]
local prefix = ARGV[1]
local date_str = ARGV[2]
local width = tonumber(ARGV[3]) or 5
local seq = redis.call('INCR', key)
return prefix .. ':' .. date_str .. ':' .. string.format('%0'..width..'d', seq)
调用方式：
redis-cli --eval gen_seq.lua order_seq_key , PAY-SH 20240520 6
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
KEYS[1]必须是独立 key（如seq:order:shanghai），避免多租户冲突 -
ARGV[3]控制位宽，传6得到000001，别硬写死在脚本里 - 不要在 Lua 里用
redis.call('TIME')取时间——它返回的是 Redis 服务器时间，且精度只到秒，不可靠
高并发下 INCR key 热点与性能瓶颈怎么破？
单个 key 被高频 INCR 会成为性能瓶颈，尤其在集群模式下，该 key 落在某个分片上，其他分片空转。解决思路是分片：按业务维度（如商户 ID、地区码）生成不同 key，或者用「预分配段」方式——每次 INCRBY 1000 拿一段号，客户端本地缓存分配，用完再取下一段。
分片示例：
序列号规则为 PAY:{region}:{date}:{seq}，key 设为 seq:pay:{region}:{date}，region 从请求中提取（如 sh, bj），天然分散压力。
- 避免用用户 ID 做分片键——可能倾斜（某大客户占 80% 流量）
- 集群模式下，确保 key 的 hash tag（如
{sh}）包裹分片字段，让同一 region 落在同一 slot - 如果必须全局唯一且严格有序，分片后需额外加协调层（如用 ZSET 归并），此时 Lua 已不够用
脚本执行失败时，序列号跳号或重复的风险在哪？
Lua 脚本要么全成功，要么报错回滚，不会产生中间状态。但要注意两类隐性跳号：
- 客户端超时重试：脚本已执行成功，但网络断开没收到返回，客户端重发导致多增一次——需配合幂等 key（如用请求 ID + 时间戳做二次校验）
- 脚本逻辑错误（如传错
ARGV[2]格式），string.format报错，整个EVAL失败，但INCR已发生，下次调用就跳过这个值
真正难处理的是「业务侧误判失败后补偿」：比如你认为某次调用失败，手动补了一个号，结果原请求其实成功了。这种问题无法靠 Redis 单点解决，得靠下游系统校验或日志对账。
