-
不能。Redis6–7.0的ACL不支持Key前缀通配符（如~tenant:a:），仅支持字面Key名或~；7.0起虽有实验性前缀匹配，但生产未验证且不支持嵌套通配。
-
RedisLua脚本执行失败常因忽略redis.call()返回值，应检查是否为错误表；EVALSHA需确保脚本已重载；redis.log()日志需调高loglevel且查服务端文件；KEYS必须显式声明，禁用KEYS命令。
-
Redis集群不支持Pub/Sub跨节点广播，因设计上无全局频道路由机制，PUBLISH消息仅被本地订阅者接收；应改用单节点Redis+连接池，或升级至Kafka/Pulsar等专业消息中间件。
-
volatile-lru适合电商购物车场景，但需为每个购物车key显式设置TTL并定期刷新；它仅淘汰带过期时间的key，采样随机且保守，不适用于依赖访问频次的场景。
-
主库卡顿导致从库失联时，应先执行INFOreplication检查connected_slaves、master_repl_offset和repl_backlog_active状态，再调大repl-backlog-size和client-output-buffer-limit，接着用SLOWLOGGET定位慢命令，最后校准Lettuce超时配置并排查大key。
-
预热不充分指预热数据未覆盖真实热点、未执行完或未及时更新，导致上线后2–5分钟内缓存击穿；须用线上采样等动态数据源、分批超时控制、命中率校验及事件驱动机制。
-
RedisPub/Sub不支持优先级，仅为瞬时广播；真正优先级队列需用List+BRPOP多键轮询，按queue:high→queue:medium→queue:low顺序原子消费，Pub/Sub仅作轻量通知触发器。
-
volatile-ttl策略仅在内存达限且有写入时触发，随机采样已设TTL的key并淘汰其中剩余过期时间最短者，并非主动或精准清理“马上过期”的key。
-
RedisTemplate操作Hash返回null的主因是序列化器不一致：key、hashKey、value三者序列化方式必须匹配，尤其hashKey须用StringRedisSerializer，value推荐Jackson序列化，否则反序列化失败或读不到数据。
-
intset是Redis对全整数小集合的内存优化编码，将整数紧凑存储于连续内存，无指针和字符串头开销，比hashtable节省3–5倍内存；前提为元素均为合法64位有符号整数且数量不超set-max-intset-entries（默认512）。
-
直接看INFOclients的qbuf、qbuf-free、obl、oll、omem字段可判断单个客户端流量压力：qbuf高说明命令积压，omem>2MB或qbuf>1MB且持续高位表明高频写入或返回大数据；CLIENTLIST才能定位具体异常客户端，需重点关注qbuf与omem同时偏高、idle小但qbuf大的连接。
-
RedisLua脚本原生不支持复杂正则匹配，仅提供基础模式匹配（如%d+），不支持\d、(?i)、.*?、分组捕获等；禁止动态加载外部库（如lrexlib-pcre）；推荐在客户端处理或使用RediSearch的FT.SEARCHREGEX。
-
主节点磁盘满导致bgsave失败，进而使从节点全量同步卡在wait_bgsave状态；需通过df-h查Redis实际dir路径磁盘使用率、日志中“Nospaceleftondevice”报错及infopersistence中rdb_bgsave_in_progress异常确认。
-
Redis发布订阅怕大Key是因为PUBLISH不校验消息大小，大Payload会阻塞单线程主线程，导致延迟飙升、内存积压；应用层需在序列化后截断或拒绝超限消息（如>100KB），订阅端须预检长度并禁用自动解码，大Payload场景应改用SET+key事件、DB查询或Kafka等替代方案。
-
redis-cli--clusterfix并非万能修复器，仅解决Slot被多节点声明的明确冲突，对Slot丢失、元数据错乱、nodes.conf未刷新等问题无效；它只比对并修正冲突项，不处理“看似合理实则失效”的条目。
