缓存击穿本身不导致主从延迟，因其仅引发高并发get读请求，不产生写操作；但击穿后集中执行“查db→写缓存”的补救式set操作，若未限流、批量过大或value过大，会加剧主从延迟。
不会直接导致主从延迟，但可能间接加剧已有的主从延迟问题。
缓存击穿本身不写主节点，所以不触发同步流量
缓存击穿的本质是大量请求绕过 Redis 直接查 DB，Redis 实例本身没有新增写操作（比如 SET 或 DEL），自然不会产生新的主从复制数据流。主从延迟主要来自主节点的写命令同步压力，而击穿期间 Redis 通常只承受高并发 GET 请求——读操作不参与复制，对主从链路无直接影响。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
但击穿常伴随“补救式写缓存”，这才是延迟诱因
很多团队在发现击穿后会立刻执行“查 DB → 写缓存”逻辑，如果这个写操作集中在短时间内批量发生，就可能成为主从延迟的导火索。尤其当：
- 补救写入用的是 SET key value EX 3600 这类单 key 写，看似轻量，但并发高时仍会堆积在主节点的写队列
- 使用了大 value（比如序列化后的用户完整 profile），导致 SET 命令本身网络传输和序列化耗时上升
- 后台任务没做限流，多个热点 key 同时刷新，主节点 CPU 和网卡被打满
- 主从之间本就存在网络抖动或从节点磁盘慢（如 AOF fsync 阻塞），此时额外写入雪上加霜
真正该盯住的指标不是“是否击穿”，而是“击穿后有没有集中回填”
监控时别只看 redis_gets_total 和 DB 慢 SQL，必须叠加观察：
- 主节点 repl_backlog_active 是否长期 > 0
- 从节点 master_repl_offset - slave_repl_offset 差值是否持续扩大
- INFO replication 中 lag 字段是否频繁超 100ms
- 击穿窗口后 5 分钟内，redis_commands_total{cmd="set"} 是否出现尖峰
击穿修复策略里最容易被忽略的一点：异步更新缓存时，SET 操作本身也要走连接池限流 + 小批量拆分，否则你把数据库压力转嫁给了 Redis 主从链路。
