-
Redis主从同步中大Key会导致复制中断或延迟飙升，因其单次序列化传输阻塞复制流、触发超时断连及缓冲区溢出；需用渐进式扫描分批拆分并双写保障一致性。
-
不能。PSUBSCRIBE仅支持glob模式（、?、[abc]），不解析冒号分隔的层级语义，news::等多星写法无效；实际可行的是单通配符前缀匹配（如news:），依赖命名规范而非Redis自动路由。
-
空值缓存TTL应设为60s～180s并配合业务SLA，禁用null直存而用"__NULL__"等明确标记，且必须与接口层参数校验、限流及定期清理协同使用。
-
XDEL对已消费消息无效，因其仅逻辑删除未被任何消费者组读取的消息；已入PEL的消息调用XDEL会静默返回0，必须用XACK释放再XTRIM裁剪。
-
appendfsynceverysec仍可能阻塞主线程，是因为当后台fsync未完成而缓冲区有新数据时，主线程会同步等待；根本原因是磁盘慢导致单次fsync超1秒，触发安全兜底机制。
-
从订单历史表按月分区的慢查询切入，讲清 MySQL 8.x 分区裁剪的命中条件、失效写法、EXPLAIN PARTITIONS 验证、索引配合和上线检查。
-
LPUSH+BRPOP不能直接做可靠循环队列，因为BRPOP阻塞等待导致无法自动重入，需外部调度；且List缺乏状态跟踪、幂等支持和消费确认机制，易丢任务或重复消费。
-
RedisStream消费组重试需手动干预：XPENDING加范围与消费者参数定位卡点，XCLAIM配FORCE和MIN-IDLE-TIME安全转移消息，XACK须在业务真正成功后调用，Redis5.0.5需自行轮询XPENDING实现自动重试。
-
SENTINELFAILOVER无反应大概率因哨兵未达成共识或主节点状态不满足切换前提：需至少3个哨兵在线且通信正常，目标master必须存在于SENTINELMASTER列表且角色为master，quorum值不可高于实际哨兵数；命令返回OK不代表切换完成，须依次验证哨兵failover_in_progress标志、新主role:master且无master_host、旧主已变为slave并指向新主；手动触发不模拟真实故障路径，无法检测发现延迟、重连失败及客户端重定向问题；演练前须调大down-afte
-
主从复制必须开启AOF，否则从节点重启后数据丢失；从节点需配置appendonlyyes和appendfsynceverysec，主节点也建议开启AOF；切换前须等待aof_pending_bio_fsync为0再开放VIP。
-
不能直接用HGET+EXPIRE组合刷新TTL，因存在竞态条件：HGET后key可能立即过期导致EXPIRE失败，且并发时多个客户端执行EXPIRE仅首个成功；Lua脚本能原子执行“查+刷”，用HEXISTS和EXPIREAT确保安全续命。
-
不能直接用RedisPub/Sub做缓存一致性保障，因其不保证消息可达，订阅者离线时消息丢失，无重试、ACK或持久化机制；必须结合RedisStream落地事件+数据库状态校验实现最终一致。
-
MySQL数据归档主要有四种方式。1.使用SQL语句手动归档，通过INSERT和DELETE迁移历史数据，适合小规模场景但需注意事务控制、索引影响和备份确认；2.利用事件调度器实现定时自动归档，可设定周期任务并建议配合分区使用以减少性能影响；3.结合时间分区表进行归档，提升查询效率且操作整个分区更高效，但存在分区键设计限制；4.借助第三方工具如pt-archiver或mysqldump，前者支持边归档边删除并控制资源占用，后者适用于低频小规模归档。根据数据量和业务需求选择合适方法，小型项目可用SQL+事件
-
网卡PPS打满是吞吐量上不去的常见原因，尤其在小key/value场景下，单请求虽仅60–100字节却生成独立TCP包，易使网卡达到硬件上限。
-
Redis的WATCH+Lua无法实现可靠乐观锁，因WATCH不监控Lua脚本执行，脚本内读-改-写仍存在竞态；真正可靠的是将“读-校验-写”全部封装进单个原子Lua脚本中完成。
