redis主从复制延迟无法避免，其业务影响取决于是否读取“刚写完就查”的数据；电商支付后订单查不到、过期键在从节点仍可读、监控误判延迟等均源于异步复制特性与从节点不主动删除过期键的设计。
Redis主从复制数据延迟无法避免，但业务是否受影响，取决于你读的是不是「刚写完就查」的数据。
电商支付后订单查不到
用户支付成功，主节点写入 order:123 并返回；前端立刻跳转到订单页，从从节点读取该订单——此时可能还没同步过来，页面显示「订单不存在」。这不是 bug，是异步复制的天然表现。
常见于：支付回调、秒杀下单、评论提交后立即刷新列表。
这类场景必须强制读主或加兜底逻辑（如轮询、重试、前端延时提示）。
过期键在从节点上还能读到
主节点设了 SET user:1001 "xxx" EX 60，60 秒后没被访问，惰性删除没触发；主节点也没做定时采样，DEL 命令根本没发给从节点。结果从节点上仍能 GET user:1001 成功，返回已过期数据。
影响典型场景：
• 登录态 token 校验失效
• 库存缓存未及时失效导致超卖
• 用户权限变更延迟生效
根本原因：从节点永不主动删过期键，只等主节点发 DEL ——而这个命令可能永远不来。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
监控报警误判从节点状态
用 INFO replication 查 slave0:offset 和 master_repl_offset 差值判断延迟，但容易踩坑：
• 差值单位是字节，不是毫秒，1MB 偏移差 ≠ 1 秒延迟（取决于命令大小和网络吞吐）
• 从节点重启后首次全量同步期间，slave_repl_offset 是 0，差值极大，但这是正常过程，不该直接切流量
• repl_backlog_hislen 小于差值时，说明缓冲区已滚动丢弃旧命令，从节点必须全量重同步——这时延迟已不可控，不是“慢”，而是“断连后重建”
延迟本身不致命，致命的是把「从节点」当成「强一致副本」来用。真正要盯住的不是延迟数字，而是业务读操作是否落在了「写后紧邻的读窗口」里——这个窗口往往只有几百毫秒，却最容易出问题。
