-
应优先使用pipeline批量发命令替代单条轮询，避免高RTT开销；对计数类操作用INCR/DECR原子增减；设值带过期统一用SET的EX/PX/NX参数；高频读不变Key应加客户端本地缓存。
-
不能。volatile-ttl仅在内存不足时随机采样少量带过期时间的key淘汰TTL最小者，并非定时批量清理；高QPS下写入快于淘汰易致OOM，需配合随机偏移、调优采样数、限流及兜底策略。
-
RedisCommandTimeoutException本质是命令执行完成但客户端未及时收到响应，与连接池大小无关；应优先调整command-timeout、keepalive及tcpUserTimeout等网络层参数。
-
根本原因是客户端频繁新建并立即关闭TCP连接，导致Linux内核在主动关闭方维持TIME_WAIT状态（2×MSL，通常60秒），端口无法复用；Redis服务端不产生该状态，问题源于客户端未复用连接池、错误调用close()、配置不当或框架内重复初始化。
-
volatile-lru是仅对设置了TTL的key生效的近似LRU淘汰策略，不淘汰无过期时间的key；必须显式配置maxmemory-policy且配合EXPIRE或SETEX使用，否则无效。
-
是，HLL适合统计日活UV，但需接受约0.81%误差且不支持成员查询与精确交集；按日期分key（如uv:20240520）、设过期、统一用户标识方可稳健使用。
-
发布订阅模式适合实时性要求极高、可容忍消息丢失、一对多广播型通知场景，如服务状态广播、实时日志分发、WebSocket用户事件广播；Stream适合需持久化、至少一次投递、支持消费者组与重试的场景，如订单异步处理、用户行为埋点、审计日志归档。
-
不能。Redis6–7.0的ACL不支持Key前缀通配符（如~tenant:a:），仅支持字面Key名或~；7.0起虽有实验性前缀匹配，但生产未验证且不支持嵌套通配。
-
RedisLua脚本执行失败常因忽略redis.call()返回值，应检查是否为错误表；EVALSHA需确保脚本已重载；redis.log()日志需调高loglevel且查服务端文件；KEYS必须显式声明，禁用KEYS命令。
-
volatile-lru适合电商购物车场景，但需为每个购物车key显式设置TTL并定期刷新；它仅淘汰带过期时间的key，采样随机且保守，不适用于依赖访问频次的场景。
-
主库卡顿导致从库失联时，应先执行INFOreplication检查connected_slaves、master_repl_offset和repl_backlog_active状态，再调大repl-backlog-size和client-output-buffer-limit，接着用SLOWLOGGET定位慢命令，最后校准Lettuce超时配置并排查大key。
-
RedisPub/Sub不支持优先级，仅为瞬时广播；真正优先级队列需用List+BRPOP多键轮询，按queue:high→queue:medium→queue:low顺序原子消费，Pub/Sub仅作轻量通知触发器。
-
volatile-ttl策略仅在内存达限且有写入时触发，随机采样已设TTL的key并淘汰其中剩余过期时间最短者，并非主动或精准清理“马上过期”的key。
-
主节点磁盘满导致bgsave失败，进而使从节点全量同步卡在wait_bgsave状态；需通过df-h查Redis实际dir路径磁盘使用率、日志中“Nospaceleftondevice”报错及infopersistence中rdb_bgsave_in_progress异常确认。
-
Redis发布订阅怕大Key是因为PUBLISH不校验消息大小，大Payload会阻塞单线程主线程，导致延迟飙升、内存积压；应用层需在序列化后截断或拒绝超限消息（如>100KB），订阅端须预检长度并禁用自动解码，大Payload场景应改用SET+key事件、DB查询或Kafka等替代方案。
