Redis Lua脚本通过原子执行避免并发冲突，但频繁redis.call会放大RTT和锁竞争；应合并操作、禁用JSON解析、避免KEY拼接，以降低延迟并防止集群哈希倾斜。
Redis Lua 脚本能显著降低即时通讯系统中「消息写入 + 会话元数据更新」的延迟和并发冲突，但前提是必须规避 redis.call 频繁调用、避免在脚本里做 JSON 解析、且不能把用户 ID 或消息体当 KEY 直接拼接——否则会触发 Redis 集群 KEY 哈希倾斜或 SCRIPT ERROR。
为什么不能用多个 redis.call 写一条消息？
典型错误是：先 LPUSH 消息到用户收件箱，再 HINCRBY 更新未读数，再 ZADD 更新会话时间戳——这 3 次 redis.call 在高并发下会成倍放大 RTT 和锁竞争。Lua 脚本虽原子，但每次 redis.call 都要走一遍命令解析、ACL 校验、数据结构查找，开销远高于纯 Lua 运算。
实操建议：
- 把「消息内容序列化」和「元数据变更」合并进单次
LPUSH或RPUSH，例如用LPUSH msg:u123 "{\"id\":\"m456\",\"from\":101,\"ts\":1720865678000}" - 未读数、最后消息 ID、会话时间戳等，全部用
HSET一次写入，而不是分多次HINCRBY/HSET/HSET - 如果需要按时间范围查消息，优先用
ZADD把消息 ID 存入时间索引（如zset:conv:u123），而非在脚本里遍历 list
如何安全地批量写入多用户消息？
IM 场景常见「群发」或「广播」，比如一个运营消息推给 500 个用户。若逐个调用 Lua 脚本，网络往返和脚本加载开销巨大；若全塞进一个脚本，又可能超时或内存溢出。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
实操建议：
- 拆成固定大小批次（如每批 50 个用户），每个批次传入
KEYS数组（["msg:u1","msg:u2",...]）和ARGV数组（["{...}","{...}",...]） - 脚本内用
for i = 1, #KEYS do redis.call("LPUSH", KEYS[i], ARGV[i]) end，避免动态拼接 KEY - 不要在脚本里做
json.decode—— 序列化工作交给客户端，Lua 只负责透传字符串；Redis 6.2+ 虽支持JSON.GET，但调用开销比原生 string 操作高 3–5 倍 - 对超大群组（>5000 人），改用
PUBLISH+ 订阅者异步写入，Lua 脚本只负责轻量预处理（如检查发送权限、截断超长文本）
怎样避免消息去重和幂等写入失败？
客户端重试、网络分区、SDK 重复提交都可能导致同一条消息被多次写入。单纯靠客户端生成唯一 ID 并用 SETNX 不够——因为消息体和元数据需一起原子写入，而 SETNX 只能保护单 key。
实操建议：
- 用
HSET的XX选项配合消息 ID 作为 field：先HSET msg_id:xxx "body" "{...}" "ts" "1720865678"，再用HEXISTS判断是否已存在，但注意这仍是两次redis.call - 更优解：把消息 ID 和接收方组合为唯一 KEY，如
msg:u123:m456，用SET msg:u123:m456 "{...}" EX 86400 NX，成功即写入，失败直接跳过 —— 这样只需一次redis.call - 若必须保留 list 结构（如兼容老客户端），可在写入前用
LINDEX查最后几条，做简单 ID 匹配（仅限低频场景），但别用LRANGE全量扫描
最易被忽略的是：Redis Lua 环境不共享变量，每次执行都是干净沙箱，所以没法靠全局缓存加速；所有中间状态必须显式存到 Redis key 或 Lua table 里，而 table 大小超过几 MB 就会明显拖慢脚本执行——这意味着「预聚合未读数」「合并连续消息」这类逻辑，得提前在应用层做完，别指望 Lua 替你算。
