-
noeviction策略下写操作直接报错是因为内存达maxmemory后硬性拒绝所有写命令，不释放key也不等待，仅允许读操作，导致“能读不能写”现象。
-
通过Redisexporter采集Redis的指标数据，并配置Prometheus来抓取这些数据，同时设置合适的告警规则。1.安装并配置Redisexporter，使用Docker简化安装过程。2.在Prometheus配置文件中添加scrape配置以抓取Redisexporter数据。3.使用PromQL查询Redisexporter提供的指标，如内存使用率和连接数。4.通过Alertmanager设置告警规则，如内存使用率超过90%时触发告警。
-
LPUSH+LPOP无法自动限长，因LPOP删队首而新元素入队尾，导致长度持续增长；唯一可靠方式是LPUSH后立即LTRIM，或用Lua脚本原子执行推入与截断。
-
“永不过期”策略实质是Rediskey物理永存，逻辑过期时间嵌入value中；安全的get_with_logic_expire需用SETNX抢锁、双重检查、异步更新；必须搭配主动刷新机制防脏数据。
-
Redis自动RDB备份不能仅用crontab调用bgsave，因BGSAVE异步返回OK不保证写入完成，需校验rdb_last_save_time和文件非空，并动态获取路径、加超时、轮转清理。
-
AOF重写后文件变大是因为重写时仍会写入带过期时间但尚未过期的key，尤其高频短TTL的SET/EXPIREAT等指令堆积且无法压缩，导致AOF体积膨胀。
-
推荐用base64url编码6字节随机数生成短码，冲突概率低且不可预测；需先EXISTS校验再写入，跳转用Lua脚本原子读URL并INCR计数，Redis用String类型存short:{code}→URL，设EX过期，stat:{code}单独存访问量。
-
Redis“无条件刷新”实为业务代码显式执行SET/SETEX覆盖key，需确保写路径确定、key名准确、实例正确；禁用SETNX，慎用GETSET；批量操作须防pipeline/事务失败导致缓存未更新；穿透雪崩时应加空值缓存与随机TTL而非强行刷新。
-
Redis内存飙升多因bigkey，应优先在从节点用redis-cli--bigkeys扫描，避免主节点阻塞；它仅返回每类最大key且不反映真实内存，需结合MEMORYUSAGE和访问频次进一步分析。
-
RedisLua脚本中不能直接执行SET等命令，必须通过redis.call()或redis.pcall()调用；MULTI/EXEC等事务命令禁用；所有key需显式传入，集群下须同slot；返回值类型需手动判断，避免误判false/0。
-
缓存空值TTL推荐2–5分钟，用SETEX或set(key,"NULL",300,TimeUnit.SECONDS)，避免永不过期或24小时；内容用"NULL"等明确标记，前置参数校验更早拦截无效请求。
-
ZADD的score不能用时间戳，因同分排序不稳定且时间戳递增违背“分数越高名次越靠前”逻辑；应使用业务分数（如积分）并利用ZADD覆盖更新、ZINCRBY原子累加、ZREM安全删除。
-
RedisPub/Sub不适合异步任务处理，因其无确认机制、无持久化、不支持消费者组与积压缓冲；应选用LPUSH+BRPOP或XADD+XREADGROUP(Stream)实现可靠任务队列。
-
短连接在Redis中严重伤性能，因其每次需完整TCP握手、认证、DB切换与释放，局域网下单次开销达1–3ms，超GET命令5–10倍，并引发TIME_WAIT端口耗尽。
-
主从同步突然变成全量复制，大概率因从节点偏移量超出主节点复制积压缓冲区范围；可通过inforeplication比对master_repl_offset、repl_backlog_first_byte_offset和repl_backlog_size判断是否缓冲区循环覆盖，再结合run_id是否变更、是否首次连接等排查。
