-
单靠DECR会超卖，因其校验库存是否>0与扣减是两步非原子操作，高并发下多个客户端可能同时读到库存=1后均执行DECR导致负数；必须用Lua脚本将判断与扣减封装为单次原子执行。
-
Redis集群原生不支持灰度发布，需通过Proxy（如Predixy）或客户端SDK实现key前缀路由，注意代理高可用、跨集群事务拦截、连接池隔离及日志打标。
-
Redis集群写入失败需先确认是否真不可写：常见原因是客户端连只读节点或未处理ASK/MOVED重定向；检查CLUSTERNODES中fail?（疑似下线）或fail（客观下线）状态；CLUSTERFAILOVER仅在从节点、主节点在线、偏移量合规且非CLUSTERDOWN时生效；主节点宕机且无自动转移时，才需在健康从节点执行CLUSTERFAILOVERFORCE，并对旧主执行CLUSTERRESETHARD。
-
双重检查是为防缓存击穿：第一次检查过滤命中请求，第二次检查在锁内确认避免重复查库；必须配合空值缓存防穿透、Lua脚本删锁保原子性。
-
先看INFOCPU中used_cpu_sys是否单独飙升，若是则为连接层压力；若user和sys同步涨，再查cluster中migrating_slots/importing_slots是否非零，并结合客户端重试日志与抓包定位根因。
-
RedisPubSub不支持批量publish，因协议层限制且pipeline无法减少网络往返；可行方案是业务层聚合消息为结构化数据（如JSON数组）后单次发送，并合理控制聚合窗口与消息体积。
-
allkeys-lru可能导致主线程卡顿，因其在内存达maxmemory时需同步遍历键空间淘汰key，在千万级实例下耗时数十毫秒；启用lazyfree-lazy-evictionyes可将释放操作异步化，显著降低延迟。
-
应先用EXISTS检查key存在，再用TYPE校验类型是否为string，因GET对非string类型会直接报错且无法捕获；TYPE返回值严格区分大小写和拼写，须用==全等比较。
-
GEOPOS查不到数据主因是GEOADD未成功：参数顺序错误（须经度在前）、成员名不一致、或pipeline/事务中未等命令执行完；返回值为二维数组，含字符串型经纬度及null，需显式转换且验证存在性。
-
RedisRDB快照生成失败时bgsave返回ERR，主因是fork()系统调用失败，典型表现为日志中出现“Failedtofork()forRDB:Cannotallocatememory”或“Resourcetemporarilyunavailable”，根本原因在于Linux的vm.overcommit_memory设置不当（默认0易拒绝fork）、内存压力过大、ulimit-u或pid_max耗尽，或cgroup内存限制过严；应将vm.overcommit_memory设为1并检查cgroup限制
-
不会阻塞。RDB持久化由fork()子进程执行，主线程继续处理请求；依赖Linux内核写时复制（COW）机制，fork后父子进程共享物理内存页，仅在修改时才复制对应页，保证子进程读取fork时刻快照，但高写入会加剧COW开销。
-
Redis分布式锁高并发下饿死请求的根本原因是续期机制与过期时间不匹配、客户端异常未释放锁，且重试无退避和超时兜底；须用随机退避、总等待超时、Lua原子删锁，单节点自动续期锁比Redlock更稳。
-
Redis集群无法在入口统一配置slowlog，因其去中心化架构决定slowlog是节点级内存缓冲区，仅记录本节点命令，CONFIGSET等配置不跨节点生效，必须逐节点独立启用、采集和聚合。
-
Redis6.0+才正式支持volatile-lfu和allkeys-lfu，低版本会静默降级为LRU；需通过CONFIGGET/SET确认并热生效策略，商品Key须按粒度命名（如prod:sku:10086）并用INCR+EXPIRE维护热度，OBJECTFREQ返回0–255近似值仅适用于相对排序，不反映真实访问次数。
-
redis-cli--hotkeys是基于LFU采样的轻量热Key发现工具，需启用allkeys-lfu/volatile-lfu策略，返回最多32个相对高频key，frequency为归一化值，非实时精确计数，须结合objectfreq、monitor等交叉验证。
