-
哨兵通过“客观下线”（ODOWN）判断主节点真挂了：单个哨兵连不上仅为主观下线（SDOWN），需至少quorum个哨兵达成一致才触发ODOWN；哨兵间用SENTINELis-master-down-by-addr命令确认，非心跳广播，网络分区可能导致结论不一。
-
DEL命令清空List最快，时间复杂度O(1)，原子且单次往返；LTRIM仅在小List中可用，O(N)且保留key；禁用LPOP循环，避免阻塞与残留；清空前需TYPE校验类型。
-
LATENCYDOCTOR无法诊断atop导致的毛刺，因其只监控Redis内部延迟（如事件循环、命令执行、AOF写入），而atop-R读取/proc/pid/smaps触发的内核页表锁争用发生在内核态，Redis用户态线程无法感知。
-
Redis客户端重连易打挂新主库，因默认“失败即重试”导致连接风暴；需配置指数退避+随机抖动（如Lettuce用ExponentialBackoffRetry.withJitter）、Go端自定义DialContext重试逻辑，并控制初始延迟50–100ms、最大延迟≤3s、重试8–12次。
-
Redis发布订阅卡顿主因是客户端消费能力不足或连接资源耗尽，而非Redis服务端性能瓶颈；需隔离连接池、改用异步驱动+批处理+超时熔断，并在需可靠性时迁移到Stream。
-
RedisPub/Sub不适用于金融交易场景，因其纯内存、无持久化、无确认机制，导致消息必然丢失；集群下无全局顺序且不支持事务，应改用Streams或Kafka。
-
Redis内存未立即下降是因为采用惰性+定期双机制清理过期key，定期清理受hz参数控制；hz越大扫描越频繁但CPU开销越高，默认10，调至100可加速清理，超100收益递减且可能引发高CPU。
-
会，Redis主从同步常打爆网卡，尤其跨机房、大key迁移或全量复制时；因Redis无带宽限速参数，需用tc对主节点6379端口出向流量限速，并调大repl-timeout防超时断连。
-
RedisAOF是将写命令追加到文件以实现持久化，但并非所有场景都适用：appendfsync配置影响安全性与性能，everysec是线上折中选择，always性能差，no不可靠；AOF重写可能耗资源，切换时需检查文件完整性、路径及时间戳。
-
OBJECTFREQ返回key的LFU近似频次（0–255），多次GET后应上升；频次非线性增长、有衰减、依赖serverCron更新，需确认Redis≥4.0、maxmemory-policy正确配置且内存压力存在。
-
单靠Redis命令无法保证双写缓存原子性，因SET和DEL是两个独立命令，中间可能被其他客户端插入操作，导致缓存与DB不一致；Lua脚本在服务端单线程原子执行，可规避竞态。
-
Redis性能瓶颈主要出现在硬件、配置和应用层面。1.硬件层面：内存不足和CPU性能低下可能导致性能问题。2.配置层面：不当的持久化和网络配置会影响性能。3.应用层面：大Key、大Value和不合理缓存策略是常见问题。通过监控和优化，可以有效提升Redis性能。
-
布隆过滤器必须前置到请求入口，如Web中间件或API网关，在接触Redis或数据库前完成校验；冷启动需预热合法ID，误判率宜设为1%；空值缓存须存"NULL"字符串并设5–300秒短过期；参数校验需在网关/Controller层强校验；需监控空值占比与误判率并告警。
-
RedisBitmap更新必须用Pipeline，因单次SETBIT网络开销大，10万次独立调用耗时超8秒，Pipeline可压至300ms内，并需显式execute()提交；offset须紧凑映射，key命名要可排序，BITOP前应校验长度，回滚靠双写+原子RENAME。
-
RedisPub/Sub不适合生产实时报警系统，因其消息零持久化、无消费确认与重试机制，订阅者断线或处理失败即导致报警永久丢失。
