-
Redis默认tcp-keepalive关闭（值为0），需主从双方redis.conf显式配置tcp-keepalive300并重启生效，且须与repl-timeout≥300协同调整，否则连接假活导致复制卡死。
-
sentinelmonitor三要素（master-name、IP、port）必须准确，缺一不可，否则哨兵无法发现主从拓扑；quorum是触发投票的最小同意数，非哨兵总数；密码需三端一致（requirepass/masterauth/auth-pass），ACL还需配置masteruser；down-after-milliseconds宜设3000–5000ms防误判；启动前须确保主从就绪，否则从节点被误标sdown。
-
无盘复制解决了传统主从全量同步中主节点fork+磁盘写入和从节点落盘加载的双重IO瓶颈；它跳过主节点落盘，由子进程直接通过socket发送RDB流，规避磁盘寻道与IO竞争。
-
大key在Redis主从同步中会触发复制断连，表现为从库state由online突变为offline、日志反复出现Connectionwithmasterlost和Resyncingfrommaster，根源是RDB/AOF传输超时或内存溢出。
-
哨兵故障转移实际耗时为2–30秒，并非毫秒级；“毫秒级”仅指心跳检测与投票过程。真实恢复时间受down-after-milliseconds配置（建议5000–10000ms）、哨兵多数派机制及客户端行为影响，需配合写前校验或代理层使用。
-
Redis大Value导致网卡打满的典型现象是业务延迟飙升、连接超时且网卡出向流量持续90%+，而CPU和内存正常；根本原因是GET/HGETALL返回几十MB未压缩value，在客户端与Redis间反复传输；Redis服务端不支持自动压缩，必须由客户端在序列化后、写入前用LZ4（推荐）或GZIP压缩，并在key中标记压缩方式，读取时依标识解压，否则易因误解bytes为str或跳过校验导致乱码或异常。
-
AOF重写加剧SSD寿命损耗，因其每次均全量生成新文件并原子替换，引发高频页擦除与搬移（写放大）；频繁触发（如每小时2–3次）使SSD磨损加速，实测寿命比纯RDB缩短30%+。
-
根本原因是客户端频繁新建并立即关闭TCP连接，导致Linux内核在主动关闭方维持TIME_WAIT状态（2×MSL，通常60秒），端口无法复用；Redis服务端不产生该状态，问题源于客户端未复用连接池、错误调用close()、配置不当或框架内重复初始化。
-
serverCron每100ms检查一次，仅当无RDB/AOF子进程时，才根据saveparams（dirty+lastsave）触发RDB，或根据AOF状态、大小及增长率触发AOF重写；改配置不重置计时/计数，故不立即生效。
-
Redis单个STRING超10MB必须拆分，建议512KB内切片并用GETRANGE/SETRANGE操作；BigHash应按访问频次和语义拆为小Hash，禁用HGETALL；一致性靠Lua脚本或状态字段+重试保障。
-
Redis集群中requirepass无效，因其仅作用于客户端端口（如6379），不约束集群总线端口（如16379）；节点间通信明文进行，需依赖网络隔离、ACL及正确配置cluster-announce-ip等措施保障安全。
-
用SETBIT而非SET存在线状态，因位图内存仅约12.5MB（1亿用户），支持秒级统计与集合运算；需确保用户ID为非负整数、key带日期并设过期，用BITFIELD批量操作，BITCOUNT统计时注意写入逻辑与精度。
-
ZREVRANK返回nil最常见的原因是key不存在或member不在ZSet中；它只对已存在的member生效，且返回0-based排名。
-
Redis7.0的String类型未新增任何操作指令，所有内存优化均源于SDS编码策略的自动演进，如按长度动态选用sdshdr8/sdshdr16及预分配冗余空间，无需用户干预。
-
最小可行路径是为每个用户创建独立Set键（如user:123:tags），用SADD添加标签、SMEMBERS查询，确保标签标准化；避免字符串拼接、KEYS扫描及反向索引维护，高频查询再引入RedisSearch或Elasticsearch。
