Lua脚本导致主从同步延迟飙升，是因为其原子执行但内部命令逐条写入复制缓冲区，大循环产生海量小命令拖慢从节点CPU处理；同时从节点AOF刷盘策略、缓冲区限制、无磁盘同步未启用等隐性配置也会加剧延迟。
为什么Lua脚本会导致主从同步延迟飙升
Redis 主节点执行 EVAL 或 EVALSHA 时，整个脚本是原子执行的；但脚本里每条命令（比如 HSET、LPUSH）仍会逐条写入复制缓冲区（repl-backlog），再由从节点顺序重放。一旦脚本内含大循环（如 for i=1,10000 do redis.call("HSET", key, i, val) end），就会产生海量小命令，严重拖慢从节点解析+执行速度——这不是网络问题，而是从节点 CPU 和单线程处理瓶颈。
避免在Lua中遍历大集合写入
常见错误是用 Lua 脚本批量写入大量字段或元素，误以为“一次发过去就快”。实际效果相反：
-
HGETALL返回结果过大时，不要在 Lua 里for k,v in pairs(res) do redis.call("SET", ...) end—— 改为服务端预聚合（如用HSCAN分页 + 客户端分批调用） - 需要写入上万键值对？直接放弃 Lua，改用客户端分批发送
PIPELINE，并控制每批 ≤500 条，避免单次网络包过大或阻塞主线程 - 若必须用 Lua（比如需原子性校验），把写操作收敛为单条命令：例如用
HMSET替代多次HSET，用LPUSH多参数一次推多个值
从节点 AOF 刷盘策略对同步进度的影响
当从节点开启 appendonly yes 且配置 appendfsync always，每条重放命令都强制落盘，slave_repl_offset 推进速度会断崖式下降。此时即使主节点流量正常，INFO replication 中看到的 master_repl_offset - slave_repl_offset 差值也会持续扩大。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
解决办法：
- 从节点应设为
appendfsync no或appendfsync everysec（前提是能接受秒级数据丢失风险） - 确认
slave_read_only yes已启用，防止业务误写污染复制流 - 用
redis-cli --stat观察从节点的in=流量是否持续接近网卡上限；若是，说明网络已成瓶颈，Lua 优化只是治标
真正卡住同步的，往往是那些不报错的隐性配置
调大 repl-backlog-size 后延迟仍高，大概率不是 backlog 不够，而是以下几处被忽略：
-
client-output-buffer-limit slave没同步放大，导致从节点接收积压命令时缓冲区溢出，主节点静默断连 -
repl-diskless-sync yes未启用，主节点每次全量同步都触发bgsave，磁盘 IO 抢占 CPU，间接拖慢增量命令写入 backlog - 跨机房场景下
repl-timeout仍为默认 60 秒，网络抖动即触发重连，反复全量同步
这些配置不报错、不告警，但会让任何 Lua 优化失效——先查 INFO replication 里的 repl_backlog_histlen 是否长期逼近 repl_backlog_size，再顺藤摸瓜看配套参数。
