-
Redis默认单线程设计，仅用一个CPU核，多核需通过部署多个实例分摊压力；Redis7.0的--server-workers仅加速网络I/O，不提升命令执行并发。
-
Redis延迟高但CPU正常通常是网络丢包或抖动所致，表现为redis-cli--latency毛刺飙升、ping标准差>10ms或丢包率>0.1%，需用tcpdump抓包分析重传与ACK丢弃，并排查云环境安全组、NAT会话老化及内核TCP参数配置。
-
Redis延迟高但CPU正常通常是网络丢包或抖动所致，表现为redis-cli--latency毛刺飙升、ping标准差>10ms或丢包率>0.1%，需用tcpdump抓包分析重传与ACK丢弃，并排查云环境安全组、NAT会话老化及内核TCP参数配置。
-
Redis通过硬编码魔数“REDIS”识别混合AOF中RDB段，匹配后切换至AOF解析模式；RDB损坏则直接报错不进入AOF阶段，且无法手动拼接或用redis-check-aof修复。
-
Host模式下Redis集群初始化失败，因节点默认上报127.0.0.1导致冲突，必须显式配置bind和cluster-announce-ip为宿主机真实IP，并开放客户端端口及对应+10000总线端口。
-
直接看INFOclients的qbuf、qbuf-free、obl、oll、omem字段可判断单个客户端流量压力：qbuf高说明命令积压，omem>2MB或qbuf>1MB且持续高位表明高频写入或返回大数据；CLIENTLIST才能定位具体异常客户端，需重点关注qbuf与omem同时偏高、idle小但qbuf大的连接。
-
生产环境必须组合使用RDB和AOF：RDB作冷备快照，AOF负责实时写入；仅用AOF有崩溃导致启动失败、重放慢、数据丢失风险；仅用RDB则丢失窗口大、fork开销高、无法增量修复。
-
根本原因是sentineldown-after-milliseconds阈值过短，而主库执行耗时Lua脚本导致PING响应超时，哨兵误判为主观下线；典型表现为INFOreplication正常但日志频繁出现+sdown又快速恢复。
-
可行但仅适用于轻量场景；必须用EVAL执行Lua脚本原子完成“取+删”或“取+标记”，避免LPOP+DEL竞态导致重复消费或消息丢失。
-
replica-priority为0表示从库禁止被选为新主，即使唯一存活也会导致故障转移失败；哨兵依据从库INFOREPLICATION中上报的值决策，而非本地配置。
-
String类型在LRU驱逐场景下内存效率低，因其每个key和value均独立占用redisObject+SDS结构，导致对象头冗余高、驱逐粒度粗；而Hash等结构共享key对象头、支持ziplist压缩，内存利用率高40%~60%。
-
LPUSH+BRPOP构成FIFO阻塞队列，兼容Redis2.0+；但消费失败会导致消息丢失，适合允许少量丢失的场景，强可靠性需求应改用Stream。
-
Redis集群启动失败、节点无法握手、CLUSTERNODES显示fail或connecting，大概率是Bus端口（clientport+10000）被占用；需确保各节点clientport与其对应bus端口区间互不重叠，如7000→17000，则下一节点clientport至少为17001。
-
Redis卡顿主因是内存满时同步驱逐bigkey，导致主线程阻塞；应启用lazyfree-lazy-eviction、改DEL为UNLINK、用--bigkeys定位大key，并依访问模式选allkeys-random或allkeys-lfu淘汰策略。
-
Redis的String类型加剧内存碎片是因为频繁SET/GET/APPEND导致jemalloc中大小不一的内存块反复分配释放，旧块无法复用而残留为碎片，表现为mem_fragmentation_ratio>1.5且used_memory_rss远大于used_memory。
